[00:24] <blackboxsw> meena: will have to get to it tomorrow. we're wrapping up SRU testing (and should be done tomorrow)
[00:25] <blackboxsw> softlayer SRU redone https://github.com/cloud-init/ubuntu-sru/pull/71 repushed. should be done tomorrow w/ puppet testng
[12:00] <otubo> meena: I could take a look at your PRs. Not sure if 93, 53 or 42. Or all of them.
[13:43] <meena> otubo: cool thanks
[13:45] <meena> i tried to write a patch to @goneri's code, but somehow sleep seemed like a much more attractive option
[13:46] <otubo> meena: all those PRs? Or just one of them?
[13:47] <meena> Goneri: your code is missing at least one function, _supported_write_network_config
[13:48] <Goneri> meena, Aloha! Thanks for the information. I plan to work on it next week-end.
[13:53] <meena> otubo: let's start with #93. but generally, whatever you can independently verify would be great to ➕1
[13:54] <meena> Goneri: i might get to it earlier
[13:54] <Goneri> meena, Yeah! You're a machine :-)
[13:56] <meena> nah, i just have a very nice evening ritual off sitting in front of the TV with my partner, after the baby is in bed, and we both stare at our laptops
[13:58] <meena> otubo: #42, by some miracle, is merged. but #69 is not, and isn't freebsd specific
[13:58] <otubo> meena: awesome, I think I still have some time today. So I'll take a look :)
[14:47] <Odd_Bloke> meena: I've been using Python since 1.5.x, I have all sorts of trivia stored in my head. :p
[14:50] <Odd_Bloke> meena: I'm not sure, but I wouldn't be surprised if the mock object doesn't know its fully qualified name.  It's just a (special) Python object with a name attribute, really.  But maybe there's some trivia for me to learn here. :p
[15:01] <smoser> someone needs to file an lxc issue for pstart fails.
[15:02] <smoser> lxc-pstart really isn't doing anything hacky.  basically it just
[15:02] <smoser>  - creates a profile with its own network
[15:02] <smoser>  - modifies container to be on that profile
[15:02] <smoser>  - inserts an 'init' and sets 'lxc.initcmd=<that>'
[15:03] <smoser>  - starts container and runs stuff
[15:03] <smoser>  - stops container
[15:03] <smoser>  - removes profile
[15:03] <Odd_Bloke> meena: One minor change requested on #93. :)
[15:04] <smoser> and lxc-proposed-nsapshot just does that, and then uses lxc publish.
[15:06] <Odd_Bloke> smoser: Is there an easy way we can dump the lxd commands that lxc-pstart is performing?  A bug report would probably have less friction if we don't need upstream to use our tooling to reproduce.
[15:07] <smoser> it does have pretty good debug output
[15:09] <smoser> Odd_Bloke: https://hastebin.com/levavikayi.cs
[15:10] <smoser> oh
[15:10] <smoser> there it is
[15:10] <smoser> --dump-commands
[15:14] <smoser> Odd_Bloke: https://hastebin.com/agolazazin
[15:26] <meena> Odd_Bloke: will have to sit until 19:00, or else you propose a change, or, even push directly to my branch
[15:28] <MrGeneral> Hello guys:
[15:28] <MrGeneral> 2019-12-12 14:55:06,854 - __init__.py[DEBUG]: Searching for local data source in: ['DataSourceNoCloud', 'DataSourceConfigDrive', 'DataSourceOpenNebula', 'DataSourceDigitalOcean', 'DataSourceAzure', 'DataS>
[15:28] <MrGeneral> 2019-12-12 14:55:06,855 - handlers.py[DEBUG]: start: init-local/search-NoCloud: searching for local data from DataSourceNoCloud
[15:28] <MrGeneral> 2019-12-12 14:55:06,855 - __init__.py[DEBUG]: Seeing if we can get any data from <class 'cloudinit.sources.DataSourceNoCloud.DataSourceNoCloud'>
[15:28] <MrGeneral> 2019-12-12 14:55:06,855 - __init__.py[DEBUG]: Update datasource metadata and network config due to events: New instance first boot
[15:28] <MrGeneral> Can't get cloud-init in proxmox to be read from ide2
[15:28] <MrGeneral> Any hint? Sorry for the spam btw.
[15:52] <Odd_Bloke> meena: No rush. :)
[15:53] <Odd_Bloke> MrGeneral: What is "ide2"?
[16:00] <MrGeneral> Odd_Bloke , Cloud-init drive in proxmox :\
[16:00] <MrGeneral> is there any way to specify the /dev/srID for cloud-init?
[16:01] <Odd_Bloke> MrGeneral: Before we get into specific solutions, let's make sure we understand the problem.  Can you open a bug at https://bugs.launchpad.net/cloud-init/+filebug and attach the tarball produced by `cloud-init collect-logs` to it, please?
[16:02] <Odd_Bloke> That'll get us the info we need to properly help you out. :)
[16:02] <MrGeneral> I'll try thanks Odd_Bloke
[16:02] <MrGeneral> yep :)
[16:02] <MrGeneral> trying to sort the issue tho
[16:02] <MrGeneral> supposedly, the data source is a cdrom generated by proxmox mounted in the server
[16:02] <MrGeneral> though as I install an ISO and load the cloud-init drive it sets by default from /dev/sr2
[16:02] <MrGeneral> actually
[16:02] <MrGeneral> sr1
[16:02] <MrGeneral> instead of sr0
[16:13] <MrGeneral> Ouch was finally able to get it working @Odd_Bloke, just didn't setup the network!
[16:13] <MrGeneral> let's find out why.
[16:14] <MrGeneral> resize, hostname, root login enabled, etc. did work.
[16:14] <MrGeneral> k, I know what to do I think.
[16:55] <MrGeneral> @Odd_Bloke may have more info. So, I install the iso which already comes with cloud-int, then I create a template in proxmox. everything is confgiured other than networking, any idea?
[17:01] <ahosmanMSFT> blackboxsw: any updates on the bug merge?
[17:07] <Odd_Bloke> MrGeneral: Not really; gathering the info I requested earlier is really the next step.
[17:07] <MrGeneral> Got it all working, Odd_Bloke, thanks, was my fault tho. :P
[17:08] <MrGeneral> Windows with Cloud-init WILL be a pita tho!
[17:08] <Odd_Bloke> Glad to hear it's working! :)
[17:08] <MrGeneral> Thanks sir :)
[17:09] <Odd_Bloke> blackboxsw: Am I remembering correctly that the Softlayer SRU PR is ready for re-review?
[17:12] <blackboxsw> Odd_Bloke: yes it is https://github.com/cloud-init/ubuntu-sru/pull/71   I repushed late yesterday
[17:12] <blackboxsw> increased a timeout to an unreasonable amount
[17:14] <Odd_Bloke> Cool, will look in a minute.
[17:15] <meena> Odd_Bloke: im too old/young to be in a rush
[17:19] <blackboxsw> ahosmanMSFT: I left you comments on the PR
[17:20] <blackboxsw> ahosmanMSFT: https://github.com/canonical/cloud-init/pull/84#discussion_r356369812
[17:20] <blackboxsw> last item and should be good
[17:25] <ahosmanMSFT> blackboxsw Just fixed and pushed
[17:30] <blackboxsw> thx
[19:03] <rharper> blackboxsw: Odd_Bloke: https://github.com/cloud-init/ubuntu-sru/pull/75
[19:09] <blackboxsw> reviewing
[19:10] <blackboxsw> rharper: https://github.com/cloud-init/ubuntu-sru/pull/66
[19:10] <rharper> reviewing
[19:40] <meena> Odd_Bloke: pushed. (and rebased again)
[20:05] <Odd_Bloke> meena: Merged, thanks!
[20:05] <meena> Goneri: any chance you can tell me what function _supported_write_config is supposed to be?
[20:07] <meena> Odd_Bloke: what about my other seventeen patches & bugs tho?
[20:07] <Odd_Bloke> Oh wow look what's that over there behind you
[20:07]  * Odd_Bloke runs
[20:08] <meena> Odd_Bloke: a santa hat.
[20:08] <meena> incidentally, we're also watching Rare Exports rn.
[20:11] <blackboxsw> rharper: btw that is a painful script to have to have written for intermittent Openstack deployment failures :/
[20:12] <rharper> =(
[20:12] <rharper> took better part of a day; but it's written now =)
[20:14] <meena> how do i ask cloud-id to give me debug (trace!) output from why it thinks it's on a None cloud?
[20:14] <powersj> ha I have a merge to update our FAQ with that very command
[20:15] <powersj> sudo DEBUG_LEVEL=2 DI_LOG=stderr /usr/lib/cloud-init/ds-identify --force
[20:15] <powersj> we should clean that up fwiw
[20:15] <powersj> and give cloud-id an alias to run that
[20:15] <blackboxsw> nice powersj (your FAQ radar was up on that ;) )
[20:17] <meena> powersj: i've hacked up ds-identity to do the right thing… but cloud-id / cloud-init don't
[20:17] <Odd_Bloke> meena: As background, cloud-id just reads data that cloud-init wrote when it was running.  Josh has pointed you at the command that does the actual determination.
[20:17] <Odd_Bloke> Hmm, interesting.
[20:17] <Odd_Bloke> meena: Can you describe the problem in more detail?
[20:19] <meena> actually, let'stry to run that command, and see wht happens, cuz i just looked at my /run/cloud-init/cloud.cfg and i modified it, so it might be wrong: https://gist.github.com/56a994dc4ccba1a81d7024c24bcd2aa4
[20:24] <meena> https://gist.github.com/27ac6b7ad02e1fa9de9145b1f4458f4d ← output
[20:25] <meena> cloud-id is stil saying none
[20:28] <rharper> cloud-init pulls from the instance-data.json in /run/cloud-init ;  so unless you've re-run cloud-init after making ds-identify changes, you won't get a new instance-data.json file
[20:29] <rharper> meena: so, 1) modify ds-identify 2) forcefully run it;  3) cloud-init clean --logs  4) cloud-init init --local; cloud-init init
[20:29] <rharper> that'll be enough to have cloud-init go through the datasource and write out instance-data.json
[20:30] <meena> rharper: ds-identify is giving the right response: datasource_list: [ Hetzner, None ]
[20:30] <rharper> look at instance-data.json
[20:31] <meena> i think the problem is still that i'm on Goneri\s branch and the network stuff is write-only…
[20:32] <rharper> right, if you can;t reach the hetzner network IMDS, then you won't get the DataSourceHetzner to indicate that it was found; and no datasource was processed
[20:34] <meena> now let's fix that before i continue to nonsensicle debugging…
[20:43] <meena> rharper: https://twitter.com/emilyst/status/1204823144956977152 apropos of almost nothing. (except, perhaps, https://github.com/canonical/cloud-init/pull/53 ;)
[20:52] <Odd_Bloke> blackboxsw: https://trello.com/c/6Pr4OxuI/48-sru-verification-10-azure-do-not-lock-user-on-instance-id-change doesn't have anyone's face on it but is marked complete, and I don't see a verification script in the repo.
[20:52] <Odd_Bloke> Was that intentional?
[20:53] <blackboxsw> Odd_Bloke: yes was intentional as we pinging the microsoft bug author on that one since we can't reproduce that failure mode easily
[20:54] <blackboxsw> so I marked complete, but no owner for us Odd_Bloke
[20:54] <Odd_Bloke> blackboxsw: But don't we need the SRU template stuff for our exception?
[20:57] <blackboxsw> Odd_Bloke: nope. The SRU template stuff is for us to continue to go above and beyond our existing exception in cases where we think we might have a regression.  Our exception is really just. does cloud-init CI and integration test suite continue to pass, and can manual upgrade validation on ## clouds validate we haven't regressed (plus maas and cdoqa)
[20:58] <blackboxsw> Odd_Bloke: any other one off validation we do (with SRU templates) is just performed as we see fit (because we don't officially have to do that anymore due to our exception)
[20:58] <blackboxsw> Odd_Bloke: rharper we were planning on dropping some of this one-off validation additional work when we've cleared a couple of SRUs without detecting potential regressions during SRU validation process.
[20:59] <blackboxsw> earlier it had  been fairly frequent where we have detected some potential regression during our one-off SRU validation.
[20:59] <Odd_Bloke> "The test case should be developed as a part of each resolved bug or new feature." <-- this makes it sound like it's expected that we are validating bug fixes and features
[21:01] <blackboxsw> Odd_Bloke: I had been those test cases as only those applicable to the given manual cloud test (as we require unit tests for any new feature/bug fix that is added in general)
[21:01] <blackboxsw> and in the previous 6 or so SRUs, we don't attach any manual SRU one-off validation test output to the SRU bug
[21:02] <blackboxsw> only the cloud-specific test
[21:02] <blackboxsw> and maas/cdoqa
[21:04] <Odd_Bloke> OK, fair enough.
[21:05] <Odd_Bloke> I hadn't realised (or had forgotten :p) we were doing more than we needed, that may have modified my opinion on which issues needed additional verification.
[21:05] <blackboxsw> we are just *that* amaaaazing
[21:06] <blackboxsw> yeah, which is also why our reviews on this one-offs (non-cloud) don't really need to be too strict. But, good to show that the feature is exercised without regression to common install behavoir.
[21:26] <blackboxsw> rharper: https://github.com/cloud-init/ubuntu-sru/pull/75/files#r357378780 one question otherwise +1 on openstack
[21:28] <meena> def _supported_write_network_config() is part of distros/__init__.py
[21:31] <meena> is there a way to set a breakpoint in the distro base class, so that when i run what rharper suggested, I'll know which methods i need to fix / reimplement / restore?
[21:32] <Odd_Bloke> meena: Is what he suggested not addressing the issue?
[21:34] <meena> Odd_Bloke: as mentioned previously, @goneri's branch is currently write only, in terms of networking, he was quite zealous in removing some quite rusty code… instead of trying to grease it
[21:35] <meena> but that rusty code was still capable of answering questions like, are we connected?
[21:35] <meena> is this interface up?
[21:36]  * meena taps mic: is this thing on? 
[21:36] <Odd_Bloke> meena: Sorry, is this related to the cloud-id issue, or a separate thing?
[21:36] <meena> yesno
[21:37] <Odd_Bloke> blackboxsw: rharper: https://bugs.launchpad.net/cloud-init/+bug/1849731 <-- do you have any suggestions on how to construct a test for this?
[21:37] <meena> it's python debugging: how do i find out when my parent class is being called, so i know which methods i need to implement
[21:39] <Odd_Bloke> meena: I'm afraid I still don't really understand what you're trying to do.
[21:40] <Odd_Bloke> But maybe trying to do One Big Branch which will address a bunch of issues is what is tripping (you|Goneri) up?
[21:40] <meena> https://stackoverflow.com/questions/6954116/ruby-s-method-missing-in-python this. i basically need to log here
[21:41] <Odd_Bloke> Yeah, that would do what you described.
[21:42] <meena> thanks for rubbery duckling
[21:42] <meena> even though you doubted me 😒
[21:46] <Odd_Bloke> meena: My concern with using the __getattr__ method is that it presupposes that you will be running the code in a way which will actually call all the methods that are missing.
[21:47] <Odd_Bloke> If this is about working out which of the removed methods should be restored, I think you're better inspecting the codebase to work that out.
[21:48] <meena> but there's so much code 🙀
[21:49] <meena> but, yeah, might be more feasible
[21:49] <Odd_Bloke> meena: FreeBSD has a grep implementation though, right? ;)
[21:50] <meena> i use ripgrep, and emacs' jump to definition
[21:53] <meena> well, on my Ubuntu (elementary) laptop. on the servers its mostly vi, cuz i keep forgetting I've installed nvim
[21:57] <Odd_Bloke> meena: https://github.com/canonical/cloud-init/pull/61/files#r357391834 <-- I broke down how I looked at one of these, as I figured my working might be useful reference
[21:58] <Odd_Bloke> meena: I think my most important realisation was that all of our Distro subclasses are also called Distro, so the `Distro.get_devicelist` calls are referencing cloudinit.distros.freebsd.Distro, _not_ the super-class.
[21:58] <Odd_Bloke> Which is _extremely_ confusing when reading that code.
[22:02] <blackboxsw> Odd_Bloke: for testing config drive you could create an lxc with a /config-drive directory (via lxc-proposed-snapshot  on bionic)
[22:02] <meena> Odd_Bloke: i do have that much figured out already, but, yeah, it's incredibly confusing, and, unnecessarily so
[22:04] <blackboxsw> Odd_Bloke: this may be helpful https://github.com/cloud-init/ubuntu-sru/blob/master/bugs/lp-1673637.txt
[22:05] <blackboxsw> it's a test case seeding config-drive content on lxc
[22:06] <blackboxsw> and the validation would be cloud-init query v1.subplatform
[22:08] <powersj> blackboxsw, so are we all set on the SRU minus some internal testing?
[22:08] <blackboxsw> powersj: yep, I'm adding a nit for puppet validation of csr. I think Odd_Bloke is grabbing the configdrive
[22:08] <blackboxsw> I'll attach the cloud logs now
[22:08] <blackboxsw> so SRU will be ready minus internal testing
[22:09] <powersj> ok so monday, darn
[23:06] <blackboxsw> just attached all SRU logs to the bug https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1854872
[23:09] <blackboxsw> ahosmanMSFT: and I just published tip of cloud-init to Ubuntu Focal 20.04:   cloud-init v. 19.3-74-g129b1c4e-0ubuntu1
[23:10] <blackboxsw> coincidentally this will also drop a package dependency on ifupdown2 from focal as well
[23:34] <tribaal> awww rharper spent some time on my unfinished branch... sorry man!
[23:35] <tribaal> I should not have opened it (even though it's a "draft" PR