Reorg repo directories about stacks HOT 10 CLOSED

I notice that in most cases, #Instance is a action doing some works instead of a struct just wrapping several data fields, so it looks like it should be named to a verb(according to https://docs.dagger.io/1226/coding-style/#use-verbs-for-action-names-nouns-otherwise)
What's more, i think it bad to rename #Instance to #Do(Do is a verb), but to name it more descriptive, maybe 'PullImage' or 'CopyFile' is better. Even though we document it ferfect, we can not get the document from where we use it directly(IDE provide no help in cue), like the following:

			_cd: cd.#Instance & {
				input: cd.#Input & {
					provider:    "argocd"
					repositorys: _git.output.image
					kubeconfig:  _kubeconfig.output.kubeconfig
				}
			}

We have to go to the cd package to find out the document. Indeed, names provide much less information than document, but better than no and it can make action more distinct.

from stacks.

Here is a new layout of stack repo:

.
├── chain
│   ├── factory  # rename supply to factory
│   ├── internal  # move cuelib to chain directory and rename to internal
│   └── tools # move all chain subdir to tools
│       ├── cd
│       ├── ci
│       ├── framework
│       ├── ingress
│       └── scm
└── official-stack # move stack directory to offcial-stack
    ├── gin-next
    ├── gin-vue
    └── sample

@hongchaodeng

from stacks.

@xinxinh2020 Totally agree! I think we should use better naming.

from stacks.

Our stacks improved a lot recently. Now we have the #Scaffold type that help us write a new stack very quickly, which is a great bonus.
Recently, I'm working on grafana and prometheus part of our chain library. And I found that I have to run the entire stack to get some feedback. That's the real reason of our hard to debug problem. Ideally, our stack should be orthogonal. For example, if I want to use nocalhost in my application. I just pick this one and pass some arguments to it. Although we have helm and kubectl to do these kind of things. But our advantage is that we have cuelang to wrap and connect all of these tools. If our components in stack is orthogonal. Then users can introduce our stack into their programs progressively. And we can debug easier. Everyone in our team can maintain a component and go very deep.
Consider the possibility of this kind of three layers' structure. First layer is the basic tools like kubectl, helm, etc. Second layer is pre-configured components like pre-configured nocalhost and grafana. And the third layer is application, which connect the second layer and pass arguments around. Stack itself is just a thin reference of the third layer and some interaction with the host machine.
If I am a user. I will appreciate to introduce a stack progressively and preserve the ability of toggling with it. Even though most of the times I never change any configuration. It's not easy to achieve this. But in my opinion, we have to do it in the long run.

from stacks.

Besides.

Considering the overview directory structure of stacks repo, why not put all stacks into a subdir such as called: stacks/, they are not at the same level with chain/ modules.

Current structure will lead to a lot of problems, such as when we want do some special things to all stacks, current solution is hard to maintain:

Above screenshot shows what we did when packaging every stack into a tar-package and watching non-stacks files change, and this is just the start if we continue current structure.

Maybe below directory structure will be better:

chain
|----ci
|----addons
|----supply
stacks
|------sample
|------gin-next
|------gin-vue
|------remix

from stacks.

Here is a new layout of stack repo:

.
├── chain
│   ├── factory  # rename supply to factory
│   ├── internal  # move cuelib to chain directory and rename to internal
│   └── tools # move all chain subdir to tools
│       ├── cd
│       ├── ci
│       ├── framework
│       ├── ingress
│       └── scm
└── official-stack # move stack directory to offcial-stack
    ├── gin-next
    ├── gin-vue
    └── sample

@hongchaodeng

from stacks.

Just a note: In factory, we could have:

factory
|- cd.cue
|- scaffold.cue

In this way, we can have code like factory.CreateScaffold which is easier to understand. But this doesn't scale up as more factories jump in.

We could also have:

factory
|- cd/
|- scaffold

This is what we do currently. I would suggest to rename it to distinguish it from tools/cd, etc. For example:

factory
|- cdfactory/ or cdmaker/ or cdcreator/

from stacks.

Our stacks improved a lot recently. Now we have the #Scaffold type that help us write a new stack very quickly, which is a great bonus. Recently, I'm working on grafana and prometheus part of our chain library. And I found that I have to run the entire stack to get some feedback. That's the real reason of our hard to debug problem. Ideally, our stack should be orthogonal. For example, if I want to use nocalhost in my application. I just pick this one and pass some arguments to it. Although we have helm and kubectl to do these kind of things. But our advantage is that we have cuelang to wrap and connect all of these tools. If our components in stack is orthogonal. Then users can introduce our stack into their programs progressively. And we can debug easier. Everyone in our team can maintain a component and go very deep. Consider the possibility of this kind of three layers' structure. First layer is the basic tools like kubectl, helm, etc. Second layer is pre-configured components like pre-configured nocalhost and grafana. And the third layer is application, which connect the second layer and pass arguments around. Stack itself is just a thin reference of the third layer and some interaction with the host machine. If I am a user. I will appreciate to introduce a stack progressively and preserve the ability of toggling with it. Even though most of the times I never change any configuration. It's not easy to achieve this. But in my opinion, we have to do it in the long run.

Good suggestions. One of the core value of Heighliner is help developers customizing their own stacks. Thus, progressively, smoothly and easy-to-debug are essential for "How to make a stack".

Actually, there are many legacy workflows and tools in lots of developer teams. Also, developers have their preferences on choosing tools or workflows, which means flexible assembling of stacks is necessary.

Glad to see this discussion about how to structure the stack layout.

from stacks.

Our stacks improved a lot recently. Now we have the #Scaffold type that help us write a new stack very quickly, which is a great bonus. Recently, I'm working on grafana and prometheus part of our chain library. And I found that I have to run the entire stack to get some feedback. That's the real reason of our hard to debug problem. Ideally, our stack should be orthogonal. For example, if I want to use nocalhost in my application. I just pick this one and pass some arguments to it. Although we have helm and kubectl to do these kind of things. But our advantage is that we have cuelang to wrap and connect all of these tools. If our components in stack is orthogonal. Then users can introduce our stack into their programs progressively. And we can debug easier. Everyone in our team can maintain a component and go very deep. Consider the possibility of this kind of three layers' structure. First layer is the basic tools like kubectl, helm, etc. Second layer is pre-configured components like pre-configured nocalhost and grafana. And the third layer is application, which connect the second layer and pass arguments around. Stack itself is just a thin reference of the third layer and some interaction with the host machine. If I am a user. I will appreciate to introduce a stack progressively and preserve the ability of toggling with it. Even though most of the times I never change any configuration. It's not easy to achieve this. But in my opinion, we have to do it in the long run.

This is good idea. so we made cuelib chain and supply.

from stacks.

Ideally, our stack should be orthogonal. For example, if I want to use nocalhost in my application. I just pick this one and pass some arguments to it.

@vgjm That's a very good point!
But I don't think this is something we can achieve currently. The is a problem from Dagger actually -- It needs to be a Dagger plan in order to execute.
I think the correct path is to implement the modular stack design in #93 . We should expose Dagger plan. Instead, we should generate Dagger plan for a stack.

from stacks.