search

apache / fluo-muchos

Apache Fluo Muchos
https://fluo.apache.org
Apache License 2.0
26 stars 37 forks source link

Use cloud-init for Azure deployments #420

Closed arvindshmicrosoft closed 2 years ago

arvindshmicrosoft commented 2 years ago

Define and use a cloud-init config which is then passed to the Azure instance creation modules as custom data. Currently the only per-instance configuration specified is to upgrade the existing CentOS packages on the VM. This provides a Azure-specific solution to a Azure-specific requirement (as there is not a more recent version of CentOS 7.9 for Azure). Without this, currently Muchos cannot be used to setup a cluster on Azure as the CA certificates are outdated and prevent Ansible from downloading tarballs on the proxy host.

ctubbsii commented 2 years ago

there is not a more recent version of CentOS 7.9 for Azure

New instances can be created by users and there's no requirement to use CentOS 7.9. I don't think the fact that nobody has yet created an updated one is a compelling override to what was previously discussed in #408 and #411. Somebody can create one at any time, or use another instance in their config. Or, they can customize their cloud-config file to update, if they prefer that method. But, I don't think it should be the default.

brianloss commented 2 years ago

there is not a more recent version of CentOS 7.9 for Azure

New instances can be created by users and there's no requirement to use CentOS 7.9. I don't think the fact that nobody has yet created an updated one is a compelling override to what was previously discussed in #408 and #411. Somebody can create one at any time, or use another instance in their config. Or, they can customize their cloud-config file to update, if they prefer that method. But, I don't think it should be the default.

The crux of the problem in my mind is the default configuration that is checked in will not deploy on Azure. What @arvindshmicrosoft has put here is a change that only affects the Azure use case. Since we don't have anyone that wants to take on the task of building a CentOS image, publishing it to the marketplace, and maintaining it there (which effectively means there is no option to use a newer image), I think it makes sense to update the packages in the existing image at deploy time. Since the packages are so far out of date that the CA certs aren't new enough to verify Apache servers, I believe it makes good security sense to update all packages.

Maybe that cloud-init config file could be a template so the update packages defaults to true so that an out-of-the box setup will deploy, but if a user wants to use their own image and skip package updates, they could change just the configuration in the conf file to disable the update?

ctubbsii commented 2 years ago

To summarize my position: I like adding a cloud-config file (I think it should be done for EC2 as well) that users can customize. If the file is placed in a prominent, easily customizable location for users to tweak, for either Azure or EC2, then I'm willing to flex on having the default set to update packages. However, I don't think it's a preferred solution. I think it's far less elegant than just defaulting to a newer OS image.

arvindshmicrosoft commented 2 years ago

Thanks @keith-turner. I do not plan to generalize the cloud-init to be equally applicable to EC2 instances and Azure instances. As I said, and as you mentioned as well, I see this PR as a stop-gap which is roughly aligned (and more importantly, will not impede) the intention of cleanly exposing cloud-init across these 2 cloud provider cluster types, in a shared manner (as far as is feasible). But in my opinion, the actual work of doing that exposing a consistent cloud-init experience can be taken up later.