[11:38] <otubo> rick_h: I couldn't stay for the further discussions on the VMWare data source, the guestinfo. I just have two questions that you might know the answer: 1) Does it *replace* OVF? 2) Do you have plans to merge it on the main cloud-init tree?
[13:30] <otubo> Another general question: Do we have a release roadmap? I'm gonna start a new rebase for Fedora Rawhide (to be included on Fedora 34) so I just wanted to know if I should wait for a new release or not :-D
[16:38] <blackboxsw> otubo: I think the followup we had with AndrewK on vmware datasource is that he'd put a PR up for review shorlty. The goal is to get that landed and he wasn't certain how "soon" we could start moving off of OVF -> new vmware datasource because there are a lot of legacy platforms that may not be compatible with new VMwareDS.
[16:39] <blackboxsw> so I think it will be a long process, and goal is to eventually deprecate/drop the VMWare components withing OVF once new DatasourceVMWare if vetted on their support matrix
[16:45] <otubo> blackboxsw: awesome, thanks! :-)
[17:54] <Odd_Bloke> falcojr: Heads-up, I ran into an issue when writing my test locally: https://github.com/canonical/pycloudlib/issues/29
[19:37] <meena> something about this tox output strikes me as wrong: https://gist.github.com/479e8ec292c3bffc9bc304b41146bf40
[19:49] <Odd_Bloke> meena: `git pull --tags` will probably fix it.
[21:25] <Odd_Bloke> falcojr: I think we need to discuss SSH key management in the integration tests; currently the assumption is that ~/.ssh/id_rsa.pub is (a) the appropriate key to use, and (b) is registered in the cloud with the name "$(whoami)".  Neither of those hold true for me in EC2, and I'm sure I won't be the only person.
[21:25] <Odd_Bloke> (Sorry, you're getting a pre-EOD brain dump. :p)
[21:26] <Odd_Bloke> I started looking at hooking up configuration options for it, but that's verbose and annoying to manage (it really needs to have a per-cloud SSH key/name option).
[21:27] <Odd_Bloke> What I've done in the past is to have the test framework completely manage keys: it creates them locally, registers them with the cloud, then once the test is complete, removes them from the cloud, and deletes them locally.
[21:28] <Odd_Bloke> A middle ground would be to modify pycloudlib to not require a public key path, and to use SSH's normal key discovery if one is not specified.
[21:28] <Odd_Bloke> (I assume paramiko can do that.)
[23:16] <powersj> If memory serves we had to provide a key_filename to paramiko which is why it ended up that way.
[23:17] <powersj> but that could be wrong, as looking at https://docs.paramiko.org/en/stable/api/client.html real quick shows the order it attempts
[23:17] <powersj> which includes "Any “id_rsa”, “id_dsa” or “id_ecdsa” key discoverable in ~/.ssh/"