clearlinux / distribution

Placeholder repository to allow filing of general bugs/issues/etc against the Clear Linux OS for Intel Architecture linux distribution
521 stars 29 forks source link

Add ucd to os-cloudguest-azure #321

Open puneetse opened 5 years ago

puneetse commented 5 years ago

Describe the solution you'd like Please add micro-config-drive (ucd) to the os-cloudguest-azure bundle.

Describe alternatives you've considered Not using a cloud-init style early initialization. Manually compiling ucd.

Additional context The other os-cloudguest bundles have micro-config-drive. It is useful to seed configuration of VM instances and automatically resize filesystems when disk sizes change.

ahkok commented 5 years ago

I'm not entirely sure, but, doesn't the linuxwaagent already takes care of all these things? This is what Azure uses as a cloud init replacement.

puneetse commented 5 years ago

@ahkok it did not on my recent deployments. In fact when you go to deploy through the Azure portal and include a cloud-init script, it is greyed out with the message:

The selected image does not support cloud init.

I am not sure simply including ucd will fix this but the disk filesystem also didn't automatically resize on disk change either.

ahkok commented 5 years ago

ah, I didn't know that, in that case, we should likely add it and just launch it by default at boot.

@puneetse is there a way you can test/try this with an image with micro-config-drive included?

Does azure support config-2 fs? Or does it require link local access?

puneetse commented 5 years ago

I took the existing image on Azure and added the os-cloudguest bundle post install, which includes micro-config-drive and that does seem to work.

https://docs.microsoft.com/en-us/azure/virtual-machines/linux/using-cloud-init This doc makes it sound like the cloud-init needs to be an enabled options when the image is published to the Azure Marketplace:

Linux distribution maintainers have to choose to enable and integrate cloud-init into their base Azure published images.

I'm not sure on your last question.

puneetse commented 5 years ago

More info on what's needed for Azure cloud-init support: https://docs.microsoft.com/en-us/azure/virtual-machines/linux/cloudinit-prepare-custom-image

ahkok commented 5 years ago

This is the relevant document:

https://cloudinit.readthedocs.io/en/latest/topics/datasources/azure.html

Specifically, the Userdata section in that document is relevant, and, currently micro-config-drive does not support this method at all. It would require parsing XML and extracting the relevant data block, converting it from base64 to normal ascii and then passing it to ucd. Maybe we can make some sort of ucd-waagent bridge, ship it with linuxwaagent since that already requires a full python stack, and that calls out to ucd after it's done its thing.

ahkok commented 5 years ago

@puneetse would be really helpful if you could grab an example copy of that xml file with some valid cloud-init userdata in there.

puneetse commented 5 years ago

@ahkok sure, here is an example from an Ubuntu 18.04 LTS image. The base64 encoded cloud-init data (which I provided through the Azure portal) is in ns1:CustomData

I couldn't snag it when it was directly mounted on /dev/sr0 (only mounts on first provisioning boot) but looking in /var/log/cloud-init.log it was copied to /var/lib/waagent/ovf-env.xml, which is where I got it from:

<ns0:Environment xmlns:ns0="http://schemas.dmtf.org/ovf/environment/1" xmlns:ns1="http://schemas.microsoft.com/windowsazure" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
   <ns1:ProvisioningSection>
      <ns1:Version>1.0</ns1:Version>
      <ns1:LinuxProvisioningConfigurationSet>
         <ns1:ConfigurationSetType>LinuxProvisioningConfiguration</ns1:ConfigurationSetType>
         <ns1:UserName>puneetse</ns1:UserName>
         <ns1:DisableSshPasswordAuthentication>false</ns1:DisableSshPasswordAuthentication>
         <ns1:HostName>ps-cloudinit-test</ns1:HostName>
         <ns1:UserPassword>REDACTED</ns1:UserPassword>
         <ns1:CustomData>I2Nsb3VkLWNvbmZpZwpob3N0bmFtZTogcHNjbG91ZGluaXQKCnVzZXJzOgogIC0gZGVmYXVsdAogIC0gbmFtZTogY2xlYXIKICAgIGdyb3Vwczogc3VkbwogICAgc2hlbGw6IC9iaW4vYmFzaAo=</ns1:CustomData>
      </ns1:LinuxProvisioningConfigurationSet>
   </ns1:ProvisioningSection>
   <ns1:PlatformSettingsSection>
      <ns1:Version>1.0</ns1:Version>
      <ns1:PlatformSettings>
         <ns1:KmsServerHostname>kms.core.windows.net</ns1:KmsServerHostname>
         <ns1:ProvisionGuestAgent>true</ns1:ProvisionGuestAgent>
         <ns1:GuestAgentPackageName xsi:nil="true" />
         <ns1:RetainWindowsPEPassInUnattend>true</ns1:RetainWindowsPEPassInUnattend>
         <ns1:RetainOfflineServicingPassInUnattend>true</ns1:RetainOfflineServicingPassInUnattend>
         <ns1:PreprovisionedVm>false</ns1:PreprovisionedVm>
         <ns1:EnableTrustedImageIdentifier>false</ns1:EnableTrustedImageIdentifier>
      </ns1:PlatformSettings>
   </ns1:PlatformSettingsSection>
</ns0:Environment>
ahkok commented 5 years ago

Oh, that's cool, I can look into a simple solution for that. Having it copied out for any agent saves us time and makes it simple.