ClusterOptions and ClusterNodeGroupOptions inconsistency

[lbogdan]

I've noticed an inconsistency between ClusterOptions and CluserNodeGroupOptions regarding keyName - that only exists in the latter.

As you should be able to specify any ClusterNodeGroupOptions as part of ClusterOptions , doesn't it make sense for ClusterOptions to have a nodeGroupOptions propery, instead of copying all ClusterNodeGroupOptions properties to it?

[lbogdan]

Took a look at the source code, and this inconsistency seems understandable, as node groups were not there in the initial design, and were added later in #44 ; then keyName was added in 3f7352d , but only for node groups.

[lukehoban]

Yes - I see no reason we can't add keyName to the cluster options as well.

I would love to share the interfaces here as well, so that we don't have to duplicate things in both places. This may be slightly challenging because a few properties ended up with slightly different names in the two - but I think there are only one or two cases of that - and those could be special-cased while still sharing everything else.

[lbogdan]

Btw, I would be interested in working on this (and the other two feature requests I opened today), if I could get a bit of mentoring.

[lukehoban]

That would be great! If you DM @metral and I on the Pulumi Community Slack we can set up some time to chat about this (and other areas you raised issues on).

[gitfool]

I would also like to see some consistency here. I initially need keyName, but ideally all node group options should be passed through. Specifying ClusterNodeGroupOptions would be better and help scope names, otherwise keyName might be better called nodeKeyName in ClusterOptions. Also, keyName and nodePublicKey should be mutually exclusive.

[lukehoban]

ideally all node group options should be passed through

Agreed! cc also @CyrusNajmabadi for thoughts on API design here.

[metral]

Closed with #259