Conversation
| @@ -0,0 +1,28 @@ | |||
| apiVersion: image.toolkit.fluxcd.io/v1beta1 | |||
There was a problem hiding this comment.
Why deployments in the directory path? I don't understand what that subfolder is for.
There was a problem hiding this comment.
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.
deployments just feels like the wrong name to me then stage could be more descriptive.
There was a problem hiding this comment.
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.
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.
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.
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.
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.
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 <piontec@gmail.com>
Co-authored-by: Lukasz Piatkowski <piontec@gmail.com>
Co-authored-by: Lukasz Piatkowski <piontec@gmail.com>
Co-authored-by: Lukasz Piatkowski <piontec@gmail.com>
Co-authored-by: Lukasz Piatkowski <piontec@gmail.com>
|
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 <marcel.mueller1@rwth-aachen.de>
Co-authored-by: Bricktop <marcel.mueller1@rwth-aachen.de>
Co-authored-by: Bricktop <marcel.mueller1@rwth-aachen.de>
|
|
||
| ### Stages | ||
|
|
||
| We have 3 example clusters under [/bases/environments/stages](/bases/environments/stages): |
There was a problem hiding this comment.
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.
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.
@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_idandcluster_nameare needed, as some definitions include a base using one var, some the other. We have to unify that.workload-clustersdir. Should we change that already and makeprod/dev/stagesubdirs there?