[03:33] <blackboxsw> mruffell: not a pain thanks for the query. We've finished all verification testing, I have sent an email to the SRU team to see if the final verification  by the solutions testing team was enough (bionic-only) to meet the merit of the SRU exception process we hold https://wiki.ubuntu.com/CloudinitUpdates#Solutions_Testing. I believe we are all good on testing and just awaiting a +1 from SRU team in
[03:33] <blackboxsw> #ubuntu-release channel.
[03:34] <blackboxsw> mruffell: watch bug https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1881018 for the updated Fix Released status and release comment from SRU team members. It should be this week in the next couple days.
[03:34] <ubot5> Ubuntu bug 1881018 in cloud-init (Ubuntu) "sru cloud-init (19.4.33 to 20.2-45) Xenial, Bionic, Eoan and Focal" [Undecided,In progress]
[03:35] <mruffell> blackboxsw: thanks Chad! I will be patiently waiting.
[03:37] <blackboxsw> just added a comment for clarity and I'm marking SRU tags appropriately so it's not blocked on me per-se
[03:37] <blackboxsw> https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1881018/comments/16
[03:37] <ubot5> Ubuntu bug 1881018 in cloud-init (Ubuntu) "sru cloud-init (19.4.33 to 20.2-45) Xenial, Bionic, Eoan and Focal" [Undecided,In progress]
=== vrubiolo1 is now known as vrubiolo
=== hjensas is now known as hjensas|afk
=== hjensas|afk is now known as hjensas
=== vrubiolo1 is now known as vrubiolo
=== vrubiolo1 is now known as vrubiolo
=== vrubiolo1 is now known as vrubiolo
[14:29] <langjv> Hey all - im attempting to run cloud-init 20.2 on RHEL8 to rule out a possible "bug" in the provided releases from RHEL (18.x). It installs fine - but im having issues making it "work". After installing, i "systemctl enable cloud-init" to get it to run at boot, but upon boot, it doesn't actually run
[14:29] <langjv> Is there some secret to making the latest RPM's provided on the cloud-init repos "work?
[14:31] <langjv> https://pastebin.com/A26uGCWb
[15:16] <otubo> Odd_Bloke, Hi! I'm still getting familiar with the tests, sorry for the long back and forth there. Quick question here, don't I still need to inherit test_helpers.FilesystemMockingTestCase in order to mock the filesystem to create a fake swap and further swapon?
[15:16] <otubo> Odd_Bloke, or I'm missing something here?
[15:30] <otubo> langjv, can you provide more logs?
[15:34] <langjv> so - there "are no logs" because nothing runs - the logfiles dont even exist
[15:35] <langjv> but as soon as i start the service - it runs and logfiles get created
[15:35] <langjv> i am trying again enabling the following services (cloud-config, cloud-final, cloud-init-local, cloud-init(
[15:36] <langjv> comparing the RHEL release (these 4 exist and are enabled by default) to the 20.2 release (these 4 exist but are not enabled by default) im hoping that enabling all 4 will cause it to "work" when i turn on the image
[15:36] <otubo> langjv, 20.2 is not officially supported by rhel, so there might some pieces missing on the rpm. Did you built yourself?
[15:37] <langjv> no i used the one released on the cloud-init repos. I was asked to try it to rule out issues im seeing in: https://bugs.launchpad.net/cloud-init/+bug/1886428 with the "supported" version
[15:37] <ubot5> Ubuntu bug 1886428 in cloud-init "Cloud-Init on RHEL8 cannot parse #cloud-config user-data" [Undecided,New]
[15:42] <otubo> langjv, right. I can take a look t that issue, since it's reproducible in 18.5.
[15:42] <otubo> langjv, let me know if enabling all 4 services make it work
[16:02] <langjv> otubo it did not work with all 4 services enabled either - weird: https://pastebin.com/j4VVLMss
[16:03] <otubo> langjv, do you really need to run 20.2 or you're just investigating that bug?
[16:06] <langjv> investigating that bug - someone here asked me to try it to see if it fixed my issue yesterday
[16:06] <langjv> it does seem like "same issue" though in 20.2 - just manifesting differently
[16:06] <langjv> https://pastebin.com/72YY6NqW
[16:07] <langjv> cloud-init is enabled but no datasource found, disabling
[16:07] <langjv> I had found this yesterday: https://kb.vmware.com/s/article/74597
[16:08] <langjv> and set the needed smbios property on my image - but it "seems" to not be working ( i am on 5.1.0.3 of VIO so a "fixed" version)
[16:08] <langjv> am using "OpenTelekomCloud" to allow me to test with both 18.5 and 20.2
[16:09] <otubo> langjv, in which cloud are you running the vm on?
[16:09] <langjv> VMWare VIO
[16:12] <otubo> langjv, AFAIK there's another known issue with rhel and vmware, it changes its instance-id on every reboot making cloud-init think it's the first time it runs. Not sure if it's related. But worth looking into.
[16:16] <langjv> wasnt aware of that - ill keep an eye out for it.
[16:18] <langjv> i think my current issue is efinitely related to datsource though. im switching back to 18.5 to attempt to reproduce again
[16:18] <langjv> https://pastebin.com/0YpFzT9b
[16:33] <otubo> interesting
[16:35] <Odd_Bloke> otubo: No worries, happy to help you get up to speed!  I'm not really around today, so we can either discuss how to proceed with doing this via pytest in the PR, or you can go ahead and subclass from FilesystemMockingTestCase and write unittest tests; I'm happy with either. :)
[16:36] <otubo> Odd_Bloke, awesome, I'll try somethings here and update the PR. Thanks for the reviews!
[16:39] <elsmorian> Hi, I'm trying to debug our cloud init config, its trying to run a bootcmd looks like and it's failing, and we are getting: https://pastebin.com/k17MtCkS
[16:44] <elsmorian> But I can't see anything in that tmp directory so can't see what it is trying to run, traceback in the logs is also not super helpful. Is there anywhere else I can see more info, or run it so it will show what that tmp shell script contains? - logs: https://pastebin.com/q0nLdigr
[16:54] <meena> elsmorian:   well, funny story, exit code 2 could very well mean ENOENT
[16:57] <meena> or was that EACCESS?
[16:58] <meena> Where's the OS source code (on your phone) when you need it?
[17:01] <meena> https://docs.rs/libc/0.2.71/libc/constant.ENOENT.html thank you rust
[17:03] <meena> elsmorian:  so, what's your config look like? maybe if we see that, we can get a better feel for why the file doesn't materialise
[17:04] <elsmorian> meena: Ah, interesting, so maybe the missing entity is the cause..
[17:05] <meena> that's what i just said
[17:05] <elsmorian> meena: so I'm a bit new to this as a lot is templated by terraform by someone else and I'm just getting up to speed. Which config files would be the most useful
[17:05] <elsmorian> meena: 👍
[17:05] <meena> or tried to say
[17:05] <meena> let's look at the result that cloud-init sees then
[17:05] <meena> cloud-init query
[17:07] <elsmorian> cloud-init query --all? or something more specific?
[17:19] <elsmorian> Argh, I have to disappear again, `cloud-init query --all` looks like it has some pointers to the things it's trying to run though, I will check that they they all point to things that are there, thanks for the pointer!
[17:21] <meena> 😽
[18:26] <AnhVoMSFT> @Odd_Bloke @blackboxsw how do I skip lxd when running tox integration test?
[18:29] <powersj> AnhVoMSFT, you can use --platform to specify which platform you want to run on
[18:31] <AnhVoMSFT> you would think setting enabled: false flag in the platforms.yaml file for lxd would have done it :)
[18:55] <langjv> otubo thanks for your help earlier - my bug is this: https://kb.vmware.com/s/article/74597 - the reason i couldn't fix it is because the "flavor" arg fix is slightly different than the "image" arg fix. Which if course i didn't catch. Eventually got it though. RHEL requires "OpenTelekom" for now until upgrading to 19.2 but otherwise "working" now it
[18:55] <langjv> seems.
[19:19] <ahasenack> hi all, is there a way to set http_proxy globally via cloud-init? I'm thinking in /etc/environment
[19:19] <ahasenack> a quick google pointed me at the proxy settings for apt, but I want then in the default environment
[19:20] <ahasenack> hm, sounds like a long standing bug: https://bugs.launchpad.net/cloud-init/+bug/1089405
[19:20] <ubot5> Ubuntu bug 1089405 in cloud-init "setting up system proxy via cloud-config might be nice" [Wishlist,Triaged]
[19:22] <meena> that should be a module
[19:22] <meena> cc_proxy
[19:23] <ahasenack> write_files apparently can be used
[19:24] <meena> yeah, but, it'd not be complete, given a specific distro and it's needs
[19:25] <meena> especially with regards to package proxies
[19:26] <meena> gem, pip, cargo, maven, apt, yum, pkg,
[19:27] <ahasenack> sounds like a module for populating /etc/environment would be more appropriate
[19:27] <ahasenack> which I think was smoser's suggestion in that bug
[19:28] <ahasenack> write_module worked for me, btw
[19:28] <meena> ahasenack:  different platforms have different ideas where to put the global environment into
[19:34] <meena> which i think means, i should write a parser for login.conf for distros/freebsd.py
[19:40] <meena> we could also do with an augeas lense
[20:37] <smoser> i would hpe i never suggested putting http_proxy variables in /etc/environment
[20:37] <smoser> i think generally thats a terrible idea
[20:38] <smoser> ok. looks like in the final comment i came around to some sanity.
[20:38] <smoser> cloud-init generically taking an environment dictionary
[20:44] <smoser> i think i've posted such rants elsewhere
[20:44] <smoser> but here is one
[20:44] <smoser>  https://bugs.launchpad.net/ubuntu/+source/maas/+bug/1671320/comments/1
[20:44] <ubot5> Ubuntu bug 1671320 in maas (Ubuntu) "MaaS should set /etc/environment with appropriate proxy settings for rescue mode" [Wishlist,Triaged]
[21:16] <meena> it's really unfair to demand our Unix such concepts as consistency
[21:17] <meena> if you want to consistently configure a proxy on a system, you should do it on Windows, or else configure a transparent proxy
[21:21] <meena> smoser:  so we last sentence sounds good, but i'm not sure if you're suggesting each service have a module with a proxy config, or if you'd have one proxy module where you list which services you'd like to be proxied
[21:31] <smoser> i'd like nothing to do with the nonsense that is http proxy configuration on unix
[21:32] <smoser> if we just set an 'environment' for cloud-init, and let the user set what they wanted, then programs it called would get that environment.
[21:32] <smoser> and you'd get what your after without cloud-init having to know about proxy