=== Gaffel_ is now known as Gaffel [11:38] 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? === hjensas_ is now known as hjensas [13:30] 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] 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] 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] blackboxsw: awesome, thanks! :-) [17:54] falcojr: Heads-up, I ran into an issue when writing my test locally: https://github.com/canonical/pycloudlib/issues/29 [19:37] something about this tox output strikes me as wrong: https://gist.github.com/479e8ec292c3bffc9bc304b41146bf40 [19:49] meena: `git pull --tags` will probably fix it. [21:25] 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] (Sorry, you're getting a pre-EOD brain dump. :p) [21:26] 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] 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] 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] (I assume paramiko can do that.) [23:16] If memory serves we had to provide a key_filename to paramiko which is why it ended up that way. [23:17] 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] which includes "Any “id_rsa”, “id_dsa” or “id_ecdsa” key discoverable in ~/.ssh/"