[13:32] <jchittum> FE80CC1E: newer versions of Ubuntu will get the backports of cloud-init as they roll through the SRU process. Moving forward to 18.04, 20.04, or 21.10 (still a daily build) can get you there. You can download our official ova's from cloud-images.ubuntu.com
[13:33] <jchittum> the Impish Indri (21.10) OVA will get things first. You can grab an OVA here: http://cloud-images.ubuntu.com/impish/current/
[14:08] <FE80CC1E> Tried with Centos and updated the image with latest cloud-init and then exported the ovf and tried it again with Terraform and it did not work - the data is there in guestinfo but it does not seem to work. 
[14:34] <akutz> FE80CC1E: Is it cloud-init 21.3?
[14:48] <gnafu> I recently installed an update to cloud-init on a CentOS 8 Stream host running on a virtual server with IONOS, and the new package introduced a significantly larger cloud.cfg than what I had.  I haven't done anything with cloud-init, so I'm wondering which config I should use.
[14:48] <gnafu> Old (current) cloud.cfg: https://paste.centos.org/view/f17f1cb4
[14:48] <gnafu> New cloud.cfg: https://paste.centos.org/view/cb68d3e4
[14:48] <gnafu> The new package installed the new cloud.cfg as cloud.cfg.rpmnew, so I have the choice of whether to accept the new one or keep what I have.
[14:49] <gnafu> Since I'm not familiar with cloud-init or whether IONOS uses it for anything, I'm not sure what the best path to take is.
[14:49] <gnafu> Do any of you know whether I should stick with what was (presumably) set up by my host when the server was created or use the new config?
[14:50] <gnafu> Or if I should even have cloud-init.service running?
[15:39] <akutz> FE80CC1E: I disconnected and did not see your response. Is it cloud-init 21.3?
[15:40] <akutz> Based https://irclogs.ubuntu.com/latest/%23cloud-init.html, you have not responded. Please let me know the version when you get a chance, and we can go from there :)
[15:55] <FE80CC1E> You know what, I might have grab the wrong version - used the following not thinking about it. 
[15:55] <FE80CC1E> This is the link I used  yum install https://github.com/vmware/cloud-init-vmware-guestinfo/releases/download/v1.1.0/cloud-init-vmware-guestinfo-1.1.0-1.el7.noarch.rpm
[16:00] <FE80CC1E> This was with Centos: https://github.com/vmware/cloud-init-vmware-guestinfo did not update the ubuntu trusty image as I cannot log in 
[16:13] <FE80CC1E> just noticed that is you akutz - perfect!! 
[16:14] <FE80CC1E> I can always do a webex and show you akutz if needed
[16:14] <akutz> Yes, that is the original version of the DS we just merged into cloud-init proper. I created the DS and maintained it for years, but finally decided enough people wanted it in cloud-init as a first-class DS that I created the pull request.
[16:15] <akutz> You used an RPM to install something into Ubuntu trusty? An RPM is a RedHat package manager, and Ubuntu uses the Debian packaging system.
[16:16] <akutz> Here is a project that uses Packer/Ansible to build an OVA with the datasource built in. You could manipulate this to build your own image - https://github.com/haproxytech/vmware-haproxy
[16:16] <FE80CC1E> no that was for CentOS, i can not log into Ubunut trusty once deployed as my understanding is that you need to pass the creds with something like cloud-init
[16:17] <akutz> CentOS doesn't have this DS built-in either.
[16:17] <akutz> Plus, if you already booted CentOS then cloud-init already ran. You have to build an image with this built in
[16:17] <akutz> See https://github.com/kubernetes-sigs/image-builder/tree/master/images/capi/packer/ova for examples of how to build multiple different distros with this DS built into it, including RHEL and CentOS
[16:18] <FE80CC1E> I updated using the link, did a clean, exported ovf, redeployed 
[16:19] <akutz> What version of CentOS? Also, the RPM has not been updated it a while. I would install it using the curl bash method. If you are comfortable with testing things first, you could 1) install the DS, 2) clean, 3) shut down, 4) set the guestinfo properties, 5) boot and see if everything worked
[16:19] <FE80CC1E> same issue 
[16:19] <akutz> That way you don't have to export to OVF in advance
[16:20] <FE80CC1E> CentOS was the latest 
[16:20] <FE80CC1E> Do you have the right version link and will use curl to pull it. 
[16:20] <akutz> Can you please try with one of the daily impish images to make sure you are setting the guestinfo correctly? The old DS is no longer supported in part because I did not have time to support it. 
[16:20] <FE80CC1E> for cloud-init that is 
[16:21] <FE80CC1E> I can do that akutz - can you send me the link to the image and latest cloud-init 
[16:21] <akutz> I don't know if there is an RPM for cloud-init 21.3 yet. You can use the latest Impish images that someone linked you above.
[16:21] <akutz>   <jchittum> FE80CC1E: newer versions of Ubuntu will get the backports of cloud-init as they roll through the SRU process. Moving forward to 18.04, 20.04, or 21.10 (still a daily build) can get you there. You can download our official ova's from cloud-images.ubuntu.com
[16:21] <akutz> [08:33:37]  <jchittum> the Impish Indri (21.10) OVA will get things first. You can grab an OVA here: http://cloud-images.ubuntu.com/impish/current/
[16:23] <rharper> https://copr.fedorainfracloud.org/coprs/g/cloud-init/cloud-init-dev/ 
[16:23] <rharper> but daily has failed for the last month
[16:24] <rharper> paride: ^ 
[16:24] <FE80CC1E> hmmm, does it work or no? I can pull this image: impish-server-cloudimg-amd64.ova  
[16:26] <akutz> rharper: the PPA works. I validated the DS the other day using the PPA method.
[16:26] <rharper> for images, the daily build should be good enought, https://cloud-images.ubuntu.com/daily/server/impish/current/   there's an ova  
[16:26] <akutz> (albeit the whole reconfigure thing)
[16:26] <akutz> But yes, I would start with the daily OVA that rharper and jchittum both linked above
[16:27] <akutz> I think one of the things confusing people is the cloud-init online docs for latest now include VMware as a DS, but it's not yet available anywhere. I wonder if we should add "since version ..." on the DS via some comments or something so the generated docs can highlight that?
[16:29] <rharper> the daily impish image has cloud-init with VMware enabled; so I'd expect todays image to work without a PPA update 
[16:29] <akutz> Yep. My remark was because of your copr link more than anything.
[16:30] <rharper> we've discussed adding that to docs, but didn't want to maintain in repo a support matrix, as support is really handled by the image in which it's included ...   I don't have a good answer on how folks find cloud-init new enough that it supports the VMware datasource 
[16:32] <FE80CC1E> so is this the right image "impish-server-cloudimg-amd64.ova" from here http://cloud-images.ubuntu.com/impish/current/
[16:34] <rharper> it's likely the same, but I always follow the path of daily/server/<release>/current  
[16:40] <FE80CC1E> I will try that version - i should be able to call it using Terraform and add cloud-config to guest-info and it should work D: 
[16:41] <akutz> rharper: I'm not suggesting the CI docs indicate images where a DS is supported, just the version of CI where the DS first appeared. 
[16:47] <rharper> akutz: it could, however, you still deal with backports which call themselves version 19.X but have backports from newer releases ... I'm certainly not against including that in a  docs/rtd/topics/datasources/vmware.rst 
[16:56] <FE80CC1E> first pass no changes - will try again with sending the data as base64+gzip but this has failed in the past
[16:57] <FE80CC1E> sorry that shoud read NOT as base64+gzip
[16:58] <blackboxsw> looks like the errors on copr build are ppcle related missing dependencies like httpretty jinja2 jsonpatch etc https://download.copr.fedorainfracloud.org/results/@cloud-init/cloud-init-dev/epel-7-ppc64le/02530612-cloud-init/builder-live.log.gz   
[16:58] <blackboxsw> specifically on epel7, not epel-8
[16:58] <FE80CC1E> Uploaded file: https://uploads.kiwiirc.com/files/210946b7db72beb27922675fae1b5e94/image.png
[16:59] <FE80CC1E> that does not work either - corrupts the deployment 
[17:13] <FE80CC1E> not working set encoding or not the image does not seem to pick up cloud-init guestinfo
[17:13] <FE80CC1E> Uploaded file: https://uploads.kiwiirc.com/files/ca539a6696ee1d8957bd1cb01d823826/image.png
[17:15] <FE80CC1E> Uploaded file: https://uploads.kiwiirc.com/files/0cdd9d2b87ab76362e6d4fa4935692f2/image.png
[17:16] <FE80CC1E> Uploaded file: https://uploads.kiwiirc.com/files/492f7159aed541b834fc7df8ec978c55/image.png
[17:31] <FE80CC1E> let me know your thoughts akutz and rharper - frustrating stand still at this point 
[17:37] <akutz> You're not specifying the encoding. Please see the documentation for how to do that. https://cloudinit.readthedocs.io/en/latest/topics/datasources/vmware.html
[17:54] <FE80CC1E> I have done it multiple times with and without - no changes akutz
[17:55] <akutz> I've no idea. I have not tried with Terraform in a while. 
[17:55] <FE80CC1E> Uploaded file: https://uploads.kiwiirc.com/files/914a3fe0a67a50554fc9256682dcf9c9/image.png
[17:56] <FE80CC1E> the data is passed so terraform is just the deployment method - if I look in the advanced properites I can see guest info
[17:57] <akutz> https://github.com/vmware/cloud-init-vmware-guestinfo/issues/39#issuecomment-617304193
[17:58] <akutz> Looks like you're not setting it under extraconfig
[17:59] <akutz> Or now it looks like they use vapp properties
[17:59] <akutz> See https://registry.terraform.io/providers/hashicorp/vsphere/latest/docs/resources/virtual_machine#deploying-vm-from-an-ovfova-template
[17:59] <FE80CC1E> uysing the following https://github.com/josenk/terraform-provider-esxi/blob/master/examples-0.13/05%20CloudInit%20and%20Templates/main.tf
[18:00] <FE80CC1E> i am using direct to ESXi
[18:01] <akutz> Are you using that provider or just as an example? because that repo, from what I can tell, is a custom provider and does not use the standard Terraform vSphere plug-in
[18:02] <akutz> I would file an issue at https://github.com/josenk/terraform-provider-esxi and ask the author why their provider is not working when you do follow their directions
[18:03] <FE80CC1E> not using vpshere just direct using ESXi unless they rebranded it 
[18:03] <FE80CC1E> not using vcenter 
[18:04] <FE80CC1E> and using the provider as mentioned 
[18:04] <FE80CC1E> the link you provided is for vcenter 
[18:04] <akutz> That's fine. But there is a Terraform provider for vSphere and there is this custom provider you're using. I know nothing about it, and I'm suggesting you file an issue with the provider repository for assistance.
[18:05] <akutz> By the way, AFAIK, https://registry.terraform.io/providers/hashicorp/vsphere/latest/docs *should* work on ESX directly as long as you're not using a free version of ESXi.
[18:05] <FE80CC1E> but it is past that no? look at the image the data is passed to the instance 
[18:06] <FE80CC1E> Uploaded file: https://uploads.kiwiirc.com/files/6d22da17b94eb88526674ac959382fbd/image.png
[18:06] <FE80CC1E> i can give it a try 
[18:07] <akutz> It may not work. Every thing I see in the official provider has a caveat that direct ESX is not supported, so I am not sure.
[18:07] <FE80CC1E> has anyone tried - i skeptical 
[18:08] <akutz> My suggestion is to use this file as an example (https://github.com/haproxytech/vmware-haproxy/blob/master/hack/image-govc-cloudinit.sh), remove the snapshot bits from it, and then use it to set the CI data on the VM directly. See if that works. But either way, I am not a Terraform expert and may not be much help. I do not know that it is setting things correctly. I do know that the DS works, so there's something in the setup that must be incorrect. I
[18:08] <akutz>  wish I could provide more help.
[18:09] <akutz> Did you send the CI logs?
[18:09] <akutz> (after boot)?
[18:09] <FE80CC1E> does the image come with a user "cloud-user"
[18:10] <FE80CC1E> the ami I am using 
[18:11] <FE80CC1E> what, I may have made progress
[18:11] <FE80CC1E> maybe
[18:12] <FE80CC1E> some of it might be working.....just tried cloud-user and it seem to let me in with no password using ssh 
[18:13] <FE80CC1E> rerunnung with user kali being added with pub key 
[18:19] <FE80CC1E> working now - added user kali to the user and it worked. now will tweak from there - thanks all
[18:24] <rharper> FE80CC1E: cool !
[19:42] <Osmium> Hi! I found that in recent versions of cloud-init a new VMware datasource has been added. How can I pass userdata via VMware vCloud Director?
[19:44] <Osmium> I see that it uses vmware-rpctool (https://github.com/canonical/cloud-init/blob/main/cloudinit/sources/DataSourceVMware.py#L179), but I don't understand what variables (what name of variables) I have to pass into VM...
[20:08] <blackboxsw> falcojr: I know it's late your time, but two questions on the ssh key PR https://github.com/canonical/cloud-init/pull/984/files
[21:14] <blackboxsw> falcojr: review in on Azure's NIC wait_for_online PR. I'm wondering generally if it might be worthwhile for use to add an option retries param on try_set_link_up for cases where we know the fabric may not yet be "live"  https://github.com/canonical/cloud-init/blob/main/cloudinit/distros/networking.py#L226
[21:15] <akutz> Hi Osmium, I am not sure how to pass data via vCloud Director, but if you want information on how to configure the Datasource, please see https://cloudinit.readthedocs.io/en/latest/topics/datasources/vmware.html. Please keep in mind this is not part of a shipping version of cloud-init yet, and won't be until 21.3 is released.
[21:15] <blackboxsw> that said, we'd lose visibility to messaging the number of retries needed in Azure's case
[21:16] <falcojr> blackboxsw: yeah, it probably makes sense to add that
[21:19] <akutz> Osmium: As for vCD, this came up before at https://github.com/vmware/cloud-init-vmware-guestinfo/issues/60, but the reporter never responded to my feedback.
[21:26] <Osmium> Thank you akutz! After some digging I found that `vmware-rpctool 'info-get guestinfo.ovfEnv'` returns XML with properties I need. It looks like vCloud uses OVF transport, so I have to use OVF
[21:27] <akutz> Ack. 
[21:28] <akutz> FWIW, that transport will eventually move into the new DS, which means you'll receive the post-transport features for free in the future. Not in CI 21.3, but hopefully sooner than later. For the features to which I'm referring, please see https://cloudinit.readthedocs.io/en/latest/topics/datasources/vmware.html#features
[21:42] <falcojr> blackboxsw: I updated https://github.com/canonical/cloud-init/pull/984
[21:42] <blackboxsw> checlking
[21:47] <blackboxsw> falcojr: https://github.com/canonical/cloud-init/pull/984#pullrequestreview-735405555 +1 needs rebase and CI pass but ssh home dir perms can land
[21:49] <falcojr> cool, thanks!
[22:20] <blackboxsw> aswinr: thanks again for https://github.com/canonical/cloud-init/pull/990#pullrequestreview-735418135 will land it as soon as the latest CI run passes
[22:21] <aswinr> Thanks @blackboxsw for the review and comments!
[22:21] <blackboxsw> our plan will be to push the quarterly upstream release of cloud-init for version 21.3 to Monday Aug 23rd so we get a couple of daily build QA runs on it 
[22:22] <blackboxsw> aswinr: no prob at all. we'll cut this release monday and get that out into Ubuntu Impish 21.10 and start the SRU process into Ubuntu 18.04 20.04 20.10 21.04 shortly thereafter
[22:23] <Osmium> akutz, finally I got it it working state! The key is to name variable not 'guestinfo.userdata', or 'userdata', but 'user-data'! Thanks to the source code https://github.com/canonical/cloud-init/blob/main/cloudinit/sources/DataSourceOVF.py#L534
[22:23] <aswinr> Sounds good, thanks blackboxsw
[22:24] <Osmium> I'll send PR with documentation about OVF datasource and vCloud tomorrow. And make a blogpost on Habr :)
[22:53] <blackboxsw> merged Azure NIC pr https://github.com/canonical/cloud-init/pull/990