-
Notifications
You must be signed in to change notification settings - Fork 3
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Feature: environments #41
Conversation
@@ -0,0 +1,28 @@ | |||
apiVersion: image.toolkit.fluxcd.io/v1beta1 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why deployments
in the directory path? I don't understand what that subfolder is for.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In general, we want more critera than just 'deployment stage', like for example region
. That's what I'm preparing here: imagine that there's 1 more folder region
there, with east
and west
subfolders, carrying some infra specific configs. That way you can create a dev cluster in DC east by inheriting from both these labels (but here we have that config merging shit...).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
deployments
just feels like the wrong name to me then stage
could be more descriptive.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I had exactly the same idea, but figured stage/stageing
sounds stupid :P Still, I'm open for suggestions. I was also thinking about release
.WDYT?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think stage/staging
is fine. Just my current believe that users immediately know what stage
means and nearly none will intuitively understand deployment
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we change this to stage
for now and then continue on here? I still think it will be easier to explain to customers / use.
postBuild: | ||
substitute: | ||
cluster_domain: "MY_DOMAIN" | ||
cluster_id: "HELLO_DEV_1" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The naming here is really inconsistent. HELLO_APP_DEV
and HELLO_DEV
are used interchangeably.
@@ -0,0 +1,12 @@ | |||
apiVersion: kustomize.config.k8s.io/v1beta1 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why are changes in the app_sets
subfolder needed in this PR? It seems like a separate area to me.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is a change in cluster_templates
, not base app_sets
. Tunes the app_set for this clsuter_template
.
…emplate into feature/environments
Co-authored-by: Lukasz Piatkowski <[email protected]>
Co-authored-by: Lukasz Piatkowski <[email protected]>
Co-authored-by: Lukasz Piatkowski <[email protected]>
Co-authored-by: Lukasz Piatkowski <[email protected]>
Co-authored-by: Lukasz Piatkowski <[email protected]>
Example
This is the example output for
|
I think it i s nice that |
The kubeval tool does not seem to be maintained anymore.
d94fc97
to
6499cef
Compare
The |
Co-authored-by: Bricktop <[email protected]>
Co-authored-by: Bricktop <[email protected]>
Co-authored-by: Bricktop <[email protected]>
|
||
### Stages | ||
|
||
We have 3 example clusters under [/bases/environments/stages](/bases/environments/stages): |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
All other docs follow an instruction format of "this is what you need to do to have environments". Here we now have a mix of "look at these files & this is what you can do". Should there be a clear guide of "this is how you add a stage"?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it would make sense and I would love it. I was pondering that myself as well while writing docs.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@MarcelMue Created a ticket for this to discuss async. Also addes topic/documentation
as it might make sense for sig/docs
as well. See: https://github.com/giantswarm/giantswarm/issues/22611
@piontec @giantswarm/team-honeybadger Updated the docs with the code examples. Please check! |
Thanks @uvegla! |
Rendered manifest diff output log
|
Validation output log
|
This PR introduces the concept of environments with a mono-repo directory-separated layout. I think we need to propose branch separated envs as well.
A few notes about this PR:
cluster_id
andcluster_name
are needed, as some definitions include a base using one var, some the other. We have to unify that.workload-clusters
dir. Should we change that already and makeprod/dev/stage
subdirs there?