[02:30] does anyone have a fix for "stages.py[ERROR]: Unable to render networking. Network config is likely broken: No available network renderers found. Searched through list: ['eni', 'sysconfig', 'netplan']" [02:31] F29/F30/F31 all do it.. ci-info shows the eth0: device as down.. then about 5 minutes later, the network finally comes up [02:31] this is on openstack, fedora cloud images.. there's references to bugs from like a year ago, that as far as I can tell don't seem to be resolved [03:07] well... Odd_Bloke or rharper or blackboxsw . i'm not able to recreate this right now outsize of lxc-pstart [03:07] but [03:07] http://paste.ubuntu.com/p/pCwHJgNdyv/ [03:07] at first i thought it had soemthing to do with the symlink /sbin/ -> usr/sbin gettinb broken [03:08] and then i thought it had something to do with psuedo-init deleting itself [03:08] but both of those seem red herring. [03:12] im guessing you guys are all ubuntu devs.. i just want to get some traction on this: https://bugzilla.redhat.com/show_bug.cgi?id=1596062 [03:12] bugzilla.redhat.com bug 1596062 in distribution "Fedora-Cloud-Base - qcow2 - eth0 is not UP" [Unspecified,Closed: rawhide] [03:13] and the "fix" .. https://pagure.io/fedora-kickstarts/pull-request/406 [03:13] i realise this is a fedora "issue" .. but i dont seem to be getting much joy from them at the moment.. and this bug is over a year old now [03:47] cloud-init obviously supports the sysconfig method.. but this is no longer working since NetworkManager has been removed/deprecated === logan_ is now known as logan- [14:03] snadge: removed/deprecated in favor of what ? [14:52] blackboxsw: Thanks for the pointers! [14:53] snadge: The output of `cloud-init collect-logs` on a failing system would be very helpful for triaging the issue. :) [14:58] Odd_Bloke: thanks for finding the refs get_devicelist() [15:53] Odd_Bloke, \o/ thanks for the reviews [15:59] :) [15:59] powersj: blackboxsw: rharper: One thing I would like to do is enable some branch protection rules for master. You should all, I believe, be able to see the options at https://github.com/canonical/cloud-init/settings/branch_protection_rules/new [16:00] Specifically, at minimum, I'd like to require PR reviews and status checks. [16:01] And probably "Include administrators" too, as we're all administrators so not checking that wouldn't actually enforce these for anyone but smoser. :p [16:01] you mean you don't want me committing directly to master? [16:02] I plead the fifth your honor [16:03] git push --force [16:04] there is an option to allow force pushes, so maybe it blocks that too? [16:07] Odd_Bloke, what is up with the xx-current branch? [16:07] Branch protection rules in place for master and ubuntu/* branches [16:12] ok and squash and merge is now the default [16:13] Odd_Bloke, ^ [16:17] powersj: Nice, thank you. I modified the master rule so that Travis was one of the required checks. [19:03] Odd_Bloke, did you see my ping above about xx-current? [19:21] powersj: Oh, oops. IIRC, our release process suggests using that as a tag name before using the scripts which automate merging. [19:21] So I guess it accidentally ended up pushed. [19:22] Odd_Bloke, one we can delete? [19:24] puppet manual SRU verification is up https://github.com/cloud-init/ubuntu-sru/pull/76 [19:28] powersj: Yep. [19:35] Odd_Bloke: i think i have an idea for get_devicelist() oh [19:36] i've been down this path before… [19:37] is there a reason why cloudinit/net/__init__.py contains all those OS specific functions? other than the fact that no other OS mattering except for Linux? :P [19:39] I believe the networking code was based on code from curtin, which is an installer that specifically targets Linux (and for a while specifically targetted Ubuntu). So I wouldn't be surprised if it's just an artifact of that, rather than a specific decision. [19:39] rharper might have more insight. [19:41] yeah I'd agree with that, there have been a couple of discussions about trying to better generalize os-specific modules out of net/__init__.py but not enough bandwidth to make that refactor move [19:42] anyone remember this peace of work? https://code.launchpad.net/~i.galic/cloud-init/+git/cloud-init/+merge/358228 ? [19:42] like a cloudinit/net/.py or something that would be sourced in net/__init__.py function implementation. Then it'd likely allow some of the specific Distro classes to drop some of their custom methods [19:43] blackboxsw: i was trying to, but rand out of steam, esp wrt testing, because, well, i didn't know enough about testing … or, python for that matter. [19:44] oh, gosh, i forgot about net vs netinfo ~_~ [19:44] meena: Oh, I hadn't seen that, it predates me being on the cloud-init team. [19:44] wowo I forgot about that meena [19:45] blackboxsw: i'm sure we can reuse some /learnings/ from that, if not much of the code. [19:45] Odd_Bloke might have better ideas on how to get around recursive … thingies. [19:45] yeah definitely meena, I knew the 'conversation' had happened, I had forgotten so much work was put into a proposal on that [19:47] you're … welcome… maybe. [19:51] Odd_Bloke: so, not Old_bloke then. i did think that i didn't remember you from … last year? yeah, it's just a year ago. [19:51] a year feels a lot longer with a baby [19:56] meena: I've been doing cloud-init stuff for ~5 years, but I was on the Ubuntu Cloud Image team until early this year. [19:57] let's see the people from Ubuntu i've had irc contact with: Ubuntu Server team, LXD, cloud-init. so, we probably didn't cross paths until now [19:57] So my role didn't involve regular upstream work on cloud-init until then. [20:05] okay, so, who wants to help me sketch out a design for cloudinit/net** that i a little bit more suitable for… things… [20:14] 🦗 [20:20] powersj: or Odd_Bloke some SRU script cleanup https://github.com/CanonicalLtd/uss-tableflip/pull/26 and https://github.com/cloud-init/ubuntu-sru/pull/77 [20:20] they are related [20:20] to get maas testing logs [20:22] meena: that's a bit lift, maybe it's worth either writing up a quick spec that folks can comment on and send it to the mailing list? [20:22] we've done that a few times in the past and it'll give folks a chance to think about the approach [20:23] blackboxsw: i was hoping someone could help draft that in an etherpad [20:23] we've used https://hackmd.io/ for cross company collaboration or shared google docs [20:23] \o/ [20:23] or etherpad :) [20:23] i forget what the cool etherpad is called, but i use one. [20:24] i'd much prefer hackmd to … anything from google. [20:26] meena: a github gist could work too I suppose [20:27] can't work on that at the same time tho, so the back and fork might be very annoying [20:27] back and fork — see what i did there?? [20:27] haha [21:14] powersj: Odd_Bloke smoser rharper just added autolinks to our github cloud-init project. so any message, comment or PR description containing LP: will auto link to launchpad [21:15] blackboxsw: Oh, nice. How is that configured? [21:15] blackboxsw, ^ how did you do that? [21:15] :) [21:15] woooooow. i just ran dead over the repo [21:15] what this means though is that during our squash merge of cloud-init PRs we'll need to remember to restructure that last line to LP: # [21:15] powersj: Odd_Bloke settings tab, autolink references https://github.com/canonical/cloud-init/settings/key_links [21:15] we ca have many [21:15] if needed, but the 'prefix' can't contain whitespace or # :/ [21:15] blackboxsw: good work! [21:16] I was tired of cut-n-paste into launchpad :) [21:16] why no #? [21:16] or whitespace :) since the usual would be "LP: #123" [21:16] Launchpad bug 123 in Launchpad itself "There's no direct way to see the project info when translating it" [Medium,Fix released] https://launchpad.net/bugs/123 [21:16] heh [21:16] we need to ask,request github for that feature. only alpha-nums and : [21:16] or hyphen [21:17] https://help.github.com/en/github/administering-a-repository/configuring-autolinks-to-reference-external-resources [21:17] but yeah might be a feature request for github [21:19] dead: https://gist.github.com/2c7b341c00fc10024605234d51698efc [21:21] blackboxsw: So I'm not sure we should change how we're formatting things just to get autolinking to work. [21:22] Because I think stuff in Launchpad uses the "LP: #" prefix for auto-relating things, and we'd break that. [21:22] (I'm not sure we _shouldn't_, either, to be clear. :) [21:22] Odd_Bloke: I'm not suggesting that, since we are already in the process of manually reviewing during squash merge, We'd have to fix the format back in the commit message before merge [21:22] i don't know how to make more words, https://md.hecke.rs/z17JGX4HT4emH5jTEhMuTA?both [21:22] Oh, I see what you mean. [21:23] Odd_Bloke: right I agree, I was just wondering we we can do something or automate that merge to fix before we squash merge. But, still have the facility for easy reviews by autolinks [21:23] also, you could have travis check the commit message before (merge?) [21:26] The merge message is written into a textbox and the merge happens immediately, I don't think we have a linting window available to us there. [21:27] hrm… yeah, no, you'd only get a build failed on master after a green build on the pr [21:28] I've filed a feature request with github [21:29] Potentially using a mergebot like bors, which pulls out of the PR description, would give us a chance. But then we would need to put the correct formatting into the PR description, so we wouldn't get auto-linking. [21:31] so, anyone wanna rewrite https://md.hecke.rs/z17JGX4HT4emH5jTEhMuTA?both to be less blah blah? [21:32] meena: I just scanned through, and I'm a big +1 on a class-based approach. [21:32] I'll take a closer look in a few minutes. [21:33] Odd_Bloke: then, if you somehow can, maybe suggest how to do that… [21:33] do we have any api promises to keep towards 3rd party folks, or is everything upstreamed to us? [21:36] meena: we try to avoid thrashing class module api in the event that users are plugging into cloud-init with modules that are not upstreamed. We know of a few cases where modules are kept out of upstream due to privacy issues. Mostly though, that'd generally be in the DataSource and config module camp though. not specifically someone calling into cloudinit.network modules that I know of [21:37] there are promises that users can drop in there datasource modules and config modules and as long as the module's API surfaces the same entry points, then cloud-init will try to use it. I really don't think it's the same for our net modules. [21:38] I was thinking primarily of cloud-init's find_source and find_modules stuff in stages.py [21:38] blackboxsw: Azure uses is_up(); DigitalOcean uses get_devicelist() and OpenNebula and DigitalOcean use is_physical() [21:39] to name a few from cloudinit.net [21:39] meena: internal to cloud-init if we overhaul the net functions we would make sure to update tip of DO Azure and OpenNebula to use those new methods appropriately. [21:39] *nod *nod [21:39] having a cohesive working tip of cloud-init should suffice I would think [21:44] for some reason I can't register to md.hecke.rs [21:45] invalid email claims [21:45] boo [21:46] (do you need to register?) [21:46] blackboxsw: i can move it elsewhere if you want [21:46] yeah it was rejecting me on registration attempt [21:46] not signin [21:47] objections to hackmd.io? [21:50] nah [21:57] https://hackmd.io/3-YBj1t9TAeKhmfLBQUjXQ?both ← signed in users can edit [22:03] blackboxsw: rharper: https://github.com/cloud-init/ubuntu-sru/pull/78 [22:05] i'll be heading towards bed… [22:06] meena: Sleep well! [22:07] bed != sleep. [22:07] it just means i'm reading stuff on my phone rather than trying to write on my laptop. [22:07] meena: Enjoy being in bed! [22:07] :p [22:07] i do enjoy that, what the heck i'm doing on the couch?? [22:22] meena: 5pm on Friday is the wrong time for me to be thinking about this, so apologies if I don't make sense. But I think a good way to work out how a class-based approach could work would be to select a single function in cloudinit.net which is Linux-specific (perhaps our old friend get_devicelist), and move that to a method on a Linux-specific network class. Then see what refactoring you have to [22:22] perform to get _Linux_ networking functioning again. [22:24] That would give us an idea of what a class-based approach would look like, without requiring (a) refactoring _everything_, or (b) working out the right behaviour on FreeBSD. [22:25] (I'm not saying we would necessarily land such a change, either, it may just serve as an investigative spike.) [22:25] what Odd_Bloke is says. [22:27] meena: Not sure I follow? (I guess it's even later for you. :p) [22:27] I'm agreeing with you, and yes it is [22:27] 23:27 [22:28] also, i thought blackboxsw was saying that first part, that got me notified here,,, [22:30] so, currently the easiest way to know which system you on is system_info() unless someone overrode that [22:31] meena: I'm heading out for the weekend now, I'm afraid. I'm working all of next week though, so we can put our heads together on Monday? [22:31] of course [22:32] Great. :) Have a good weekend! (And don't stay up too late hacking. ;) [22:32] nah [22:32] I'll just read horrible news or boring papers [22:38] Goneri: https://hackmd.io/3-YBj1t9TAeKhmfLBQUjXQ thinking exercise for the weekend