Allow Flatcar Linux os_channel on AWS #211
Conversation
|
Possibly rename the variable to |
|
rel: #209 |
| } | ||
| } | ||
|
|
There was a problem hiding this comment.
I'm not familiar with typhoon & HCL, but am just curious.
Is there a good way to reduce number of data definitions?
It seems that a large part of ami.tf is defined again in workers/ami.tf.
There was a problem hiding this comment.
Its definitely possible with an output and then consumption of that output.
The main question is whether we should. The worker inner module can be used independently for worker pools, so it can't refer to the outer module, so it must have an ami.tf contents. Having the outer kubernetes module use the worker module both to create workers (purpose of the module) and to pick an AMI for controllers feels odd and kinda wrong. Right now, both modules pick an AMI for the instances they create and they happen to pick AMIs in the same way. Favoring some duplication over weird coupling.
|
Targeting this for the weekend. |
* Replace os_channel variable with os_image to align naming across clouds. Users who set this option to stable, beta, or alpha should now set os_image to coreos-stable, coreos-beta, or coreos-alpha. * Default os_image to coreos-stable. This continues to use the most recent image from the stable channel as always. * Allow Container Linux derivative Flatcar Linux by setting os_image to `flatcar-stable`, `flatcar-beta`, `flatcar-alpha`
flatcar-stable,flatcar-beta,flatcar-alpha. Nice drop-in replacement.stable,beta,alphabe changed tocoreos-stable(default),coreos-beta,coreos-alphaif they were set