-
Notifications
You must be signed in to change notification settings - Fork 7
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
Support templating Openstack clusters as App CRs #635
Conversation
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.
@ljakimczuk This is looking good but CI isn't happy. Can you check and appease the Circle gods? :)
Sure! |
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.
Nice<3 this is looking good. Just some final nits on ordering.
We should get a review from Sig UX before merging but we can start with a review from the team.
We'll also need a docs PR 📚 https://docs.giantswarm.io/ui-api/kubectl-gs/template-cluster/
@rossf7 I remember about that, but let's maybe wait for that until we get more reviews, just in case we have more changes coming in. WDYT? |
@ljakimczuk Yes that's fine 👍 |
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.
Cool stuff!
Please list all the changes to the CHANGELOG
.
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.
LGTM when @anvddriesch and team 🌈 are happy
Agree it makes sense to hide the openstack flags for now.
@rossf7 @anvddriesch @tfussell done, flags are now hidden and the changlog entry is there, let me know if I should make it more detailed. |
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.
LGTM
Do we need to keep |
@kopiczko not necessarily, it seemed more consistent to me to have this type, but it would work just as good without it. We can get rid of it or change this flag to something not suggesting multiple types, for example, |
I thought we could replace existing templates and ditch them altogether. |
I believe the original idea was to support both templates types, at least for some time since some users may be interested in templating raw resources, but maybe I got it wrong. @rossf7 WDYT? |
Asked @cornelius-keller |
I think currently it does not hurt and gives the customer the opportunity to create the clusters with the old method still, which might be useful in case there are problems with the new ones and we need to compare them to see what is different. In the long run I agree with @kopiczko and it should disappear or be renamed, especially because customers can expect that the raw method templates the same cluster as the app method only that it is the raw template and not wrapped into an app. Maybe it will be useful to provide an option to get a raw template that is the same as included in the app, but that is a different story. LGTM |
It would be nice to at least generate raw templates using |
This may be misleading for those relying on the "old" version for the migration time being and as far as I understood that's indeed the case. But since |
Haven't read through the entire discussion. One minor thing that stands out to me is the duplication of the term |
I duplicated term @tfussell has already proposed to change this flag to something else, namely When we have an agreement I will push the changes. |
With a boolean flag, the default (when the flag is not used) should always be What sort of output will that ( |
@marians The |
56b61a1
to
80884bb
Compare
Description
The
kubectl gs template cluster --provider openstack
is now able to output clusters as App CRs. It does that by running two additional commands underneath, one for templating the cluste-openstack app and another for templating the default-apps-openstack app.In order to accomplished that, the below flags have been introduced:
--cluster-topology
, set tofalse
by default, when used cluster will be templated as App CR,--cluster-user-configmap
, the current command supports multiple flags for customizing cluster templating, though in the case of App CRs, the configuration must be provided in a form ofvalues.yaml
. We could try to translate the existing cluster flags tovalues.yaml
before running thetemplate app
commands, and in fact I tried that at the beginning, though it quickly started to look messy and felt counterintuitive. Working with thevalues.yaml
directly seems much more easier and flexible in configuration to the users, so I introduced this extra flag,--default-apps-user-configmap
, the same reasoning as above applies here,--cluster-app-version
, allows cluster app version selection,--default-apps-app-version
, allows default apps app version selection.Examples
$ kubectl gs template cluster --provider openstack --cluster-topology --organization giantswarm-2
Output:
$ kubectl gs template cluster --provider openstack --cluster-topology --organization giantswarm-2 --cluster-user-configmap /tmp/cm.yaml
$ kubectl gs template cluster --provider openstack --organization giantswarm-2 --release 20.0.0-alpha1 --node-machine-flavor=n1.small
(some output has been cut for brevity)