Design Proposal #003: Extending Use of --config-file

[errordeveloper]

Description

This is a design proposal towards #462.

• xref Cluster API CLI #19

[errordeveloper]

I kind of like it more actually.

[errordeveloper]

It seems like separating object will be less helpful when it comes to implementing more complex features in the future, and having similar kind of filter flags in 'eksctl apply' maybe of use too. We can always split objects later, bit merging object would be kind of harder (or at least it seems like that now).

[mumoshu]

I prefer this, too. As I've noted in #462, separating object is not a requirement.

[D3nn]

I could see metadata.labels on NodeGroupConfig and metadata.labelSelectors to almost match K8s config, but not sure how much extra work that would add to the controller.

[D3nn]

Don't know who else will look at the design proposal, hence the NIT comments which aren't about the proposal itself.

Probably best for now to put the NodeGroups in the ClusterConfig for reasons that @errordeveloper mentioned and split them later if necessary.

[jrryjcksn]

I wonder if maybe we should leave out the object type when using a config file? It would be more consistent with kubectl.

eksctl create --config-file=cluster.yaml --exclude='nodegroup:.*-private' --exclude=vpc or
eksctl create --config-file=cluster.yaml --exclude='nodegroup:.*-private',vpc
eksctl create --config-file=cluster.yaml --include=cluster,nodegroup

[mumoshu]

At glance --exclude-nodegroups='.*-private' isn't a must-have as we already have --without-nodegroup.

Can we start the implementation without --exclude-nodegroups to make the scope of the initial implementation and making reviews easier?

[errordeveloper]

Yes, I think it could be a reasonable temporary measure. The --without-nodegroup flag is really about the initial nodegroup and is meant to be incompatible with --config-file, but at present is simply ignored when passed along with --config-file. We might not actually need this temporary measure, it'd make sense to start with eksctl create nodegroup part, and then add the filter flags to eksctl create cluster as a final step.

[palemtnrider]

Where we landed was to keep the grammar similar to nodegroup creation. Meaning we would be inclusive instead of exclusive. i.e. create config --only "glob pattern(s)" to create the nodegroups identified by the glob pattern. We may want a better flag name

Also, if --without-nodegroup is passed along with the config name, the cluster create will ignore all nodegroups defined in the config file.

[mumoshu]

Would something like eksctl apply --config-file cluster.yaml that automatically creates nodegroups missing in the AWS region, and deletes nodegroups missing in the config file be covered in this proposal?

If not, this LGTM! Thanks as always for your effort.

[errordeveloper]

Would something like eksctl apply --config-file cluster.yaml that automatically creates nodegroups missing in the AWS region, and deletes nodegroups missing in the config file be covered in this proposal?

@mumoshu I think eksctl apply is technically out of scope at the moment, but it's certainly is a on the horizon. My strategy at the moment is to focus on bitesize functionality, but pave the way for eksctl apply to become more tangible. I think we will start discussing eksctl apply more after we have upgrades.
Also, the idea of this proposal is to keep it small enough in scope. We somehow we ended-up without a proper ClusterConfig proposal to begin with, but maybe we can create one once we are getting closer to a beta version of the API, and use it as a means of driving beta to GA.

[mumoshu]

I agree with your strategy 👍

[errordeveloper]

I think this is good to go, we can always make improvements later. Will try to re-run the job in Circle, maybe just a flake..

[errordeveloper]

Let's merge it, and if anyone feels like it needs an update - please open another PR :)

[voxxit]

Did anything ever come of the NodeGroupConfig?

[errordeveloper]

It was divided to keep it to a single file/object for now, as splitting is easy, but merging back would be harder. Do you have a use-case for it being defined separately?

…

On Thu, 23 May 2019, 12:50 am Josh Delsman, ***@***.***> wrote: Did anything ever come of the NodeGroupConfig? — You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub <#545>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAB5MSYOGYK2SO6N24QBZDDPWXE2BANCNFSM4GXQY7CQ> .