=== juergh_ is now known as juergh
[14:59] <chillysurfer> i'm probably reading this wrong, but if we have an exit hook for dhclient (https://git.launchpad.net/cloud-init/tree/tools/hook-dhclient) unless `cloud-init dhclient-hook` returns a non-zero return code then dhclient will never fail, right?
[15:03] <Odd_Bloke> chillysurfer: That feels like a precursor to a real question. ;)  What's prompting you to ask?
[15:04] <chillysurfer> Odd_Bloke: haha the reason i'm asking is that we're seeing empty dhcp lease files and i'm following the trail back to this. i see in cloudinit.net.dhcp.dhcp_discovery that we would fail for a non-zero return code, and we are passing in the -1 opt to dhclient which would indicate it _would_ be a non-zero return code if dhclient fails, which had me scratching my head
[15:04] <chillysurfer> and then i saw that we have this dhclient exit hook
[15:05] <chillysurfer> and visually consuming it, it seems like this would hide a non-zero return code from dhclient main lease mechanism
[15:06] <chillysurfer> unless ::is azure and cloud-init dhclient-hook fails:: in which case i think we would get nonzero rc
[15:06] <chillysurfer> well... add the condition there that $reason is one of [BOUND, DOWN, RELEASE, REBOOT, STOP, EXPIRE]
[15:09] <Odd_Bloke> OK, I don't really know enough about dhclient to answer this off-hand, and I'm about to head into a meeting.
[15:11] <Odd_Bloke> chillysurfer: A bug report capturing the information you have might be the best next step, so that we aren't having to refer people to IRC backlog.
[15:13] <Odd_Bloke> But I agree with your assessment, it looks like we would mask a failure.
[15:13] <Odd_Bloke> Well, I'm not sure it's "masking", per se.
[15:14] <Odd_Bloke> Because it daemonises, it's not clear that we have easy access to an indication that there was an error.
[15:16] <chillysurfer> Odd_Bloke: totally agreed, and good point. i'll create a bug report!
[15:18] <Odd_Bloke> Thanks!
[15:30] <Odd_Bloke> rharper: Is there some specific reason we need a cloud-init FFe?  Or is it just because we know we're going to want to continue snapshotting?
[15:32] <rharper> Odd_Bloke: my understanding was that while we have an SRU exception for bringing things back, we're still supposed to land features by freeze date and if aren't going to make freeze to do FFe
[15:33] <rharper> historically we've not been great on doing that; so attempting to rectify that;  (assuming my understand is correct w.r.t the need for FFe)
[15:39] <blackboxsw> oops
[15:46] <Odd_Bloke> blackboxsw: I just commented on some weird indentation in https://code.launchpad.net/~chad.smith/cloud-init/+git/cloud-init/+merge/371546 and it looks like the autolander failed, so maybe we could fix that before it lands?
[15:48] <blackboxsw> Odd_Bloke: will do
[15:51] <Odd_Bloke> Thanks!
[16:11] <blackboxsw> Odd_Bloke: rharper looks like auto-lander is failing due to slow git.launchpad response time
[16:11] <blackboxsw> "ERROR: Timeout after 10 minutes" on git fetc
[16:11] <blackboxsw> "ERROR: Timeout after 10 minutes" on git fetch
[16:17] <chillysurfer> is there any official guide/doc on creating a custom cloud-init module?
[16:18] <chillysurfer> i see cc_foo.py https://git.launchpad.net/cloud-init/tree/cloudinit/config/cc_foo.py but was wondering if there was anything beyond this sample module
[16:19] <Odd_Bloke> I'm not aware of any.
[16:20] <chillysurfer> seems straightforward to construct a module, but i'm more curious to the "install" process. i guess it's just cp'ing a module file into the python cloudinit dist in the cloudinit/config/ dir
[16:21] <Odd_Bloke> chillysurfer: You'd also need to modify the /etc/cloud/... configuration to actually get the module to run.
[16:21] <Odd_Bloke> (I think.)
[16:22] <chillysurfer> Odd_Bloke: yeah that makes sense. need to add the module name to the respective config section
[16:24] <Odd_Bloke> chillysurfer: You can also pass config modules in as user-data.
[16:24] <Odd_Bloke> But that's about as much as I know about that. :p
[16:24] <chillysurfer> Odd_Bloke: sounds like a good start to me :)
[16:24] <blackboxsw> ok internal fixes on git.launchpad in progress. CI builds should come back out
[16:26] <blackboxsw> Odd_Bloke: chillysurfer correct. drop-in custom config modules can just be added to the installed cloudinit/config directory and an addition in one of the modules sections in /etc/cloud/cloud.cfg
[16:26] <chillysurfer> blackboxsw: awesome thanks!
[16:26] <blackboxsw> cloudinit/stages does a find_modules lookup for any module that contains a 'handle' function
[16:33] <blackboxsw> chillysurfer: if your config module solves a public early-config need, we'd also be interested helping you  push that confent upstream
[16:33] <blackboxsw> *public* or *more general*
[16:40] <chillysurfer> blackboxsw: i don't think it'll be so helpful. i'm tossing around ideas to prevent userdata from overwriting vendordata. if the same config sections are present in both, vendordata is overwritten (never merged). i was thinking a possible solution to that is to create an "internal" module and use that to specify vendordata actions
[16:48] <Odd_Bloke> blackboxsw: rharper: https://code.launchpad.net/~daniel-thewatkins/cloud-init/+git/cloud-init/+merge/371673 <-- this is the refactoring in preparation for the dracut stuff that I mentioned at stand-up
[16:49] <Odd_Bloke> We don't necessarily need to land it as-is (though that will make the review of the dracut-specific stuff easier), but I would appreciate some review so that I can course-correct sooner rather than later.
[16:49] <Odd_Bloke> (Ideally, I'd have this all done and landed by EOW, because I'm on vacation for the next 6 working days, hence pushing the review sooner than I might otherwise.)
[16:49] <Odd_Bloke> But, to be clear, I think this is appropriate for inclusion in master, it shouldn't change any behaviour.
[16:51] <rharper> Odd_Bloke: cool
[17:11] <blackboxsw> ok https://code.launchpad.net/~chad.smith/cloud-init/+git/cloud-init/+merge/371546 merged. I'm kicking off an eoan upload and then SRU
[17:12] <blackboxsw> Odd_Bloke: will review that branch after eoan-proposal is syncd
[17:12] <blackboxsw> eoan-upload rather. can always do another upload today if needed
[17:25] <Odd_Bloke> rharper: Responded to your comments there, BTW.
[17:32] <rharper> thx
[17:40] <blackboxsw> rharper: I sent triage question in email regarding whether there is something to do with IPv6MTUBytes now that Eoan has support
[17:40] <rharper> looking at it now
[17:40] <blackboxsw> maybe it's a curtin action item, dunno
[17:40] <rharper> curtin handles this for xenial, it;s always been broken on networkd;  we can re-run with those tests enabled to see what's been fixed.
[17:42] <blackboxsw> btw: [ubuntu/eoan-proposed] cloud-init 19.2-21-ge6383719-0ubuntu1 (Accepted)
[17:42] <blackboxsw> I'm queuing an SRU now
[17:52] <rharper> blackboxsw: yes, we'll need to update our renderer; the key name is now 'ipv6-mtu'
[17:52] <rharper> we're due for an update I think;  in e, I think netplan there now will dump it's features and keys;  so we'll want to start using that to control how we render things.
[18:03] <Odd_Bloke> rharper: Responded again and pushed that doc change I mentioned.
[18:03] <rharper> great
[18:04]  * rharper waits for git to update
[18:09] <blackboxsw> https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1841099 filed for cloud-init SRU
[18:15] <Odd_Bloke> blackboxsw: Ryan is +1 on my dracut branch; are you happy for me to mark Approved, or do you want to review too?
[18:45] <Nick_A> What is the correct way to do dhcp4 and dhcp6 on a single interface in network config format 1? Do I need two subnet sections or do I list dhcp,dhcp6 on the same type line?
[18:46] <Nick_A> Or perhaps two type lines, one with dhcp and one with dhcp6?
[18:57] <rharper> Nick_A: you need to subnets,  subnets: [{type: dhcp}, {type: dhcp6}]
[18:58] <Nick_A> thanks
[18:58] <metsuke> What is the best way to insert a multi-line (3) cron file using cloud-init?  I can use 3 runcmd lines but I'm guessing there is a better way?
[18:58] <rharper> write_files
[18:59] <metsuke> thank you
[18:59] <rharper> you can use the | marker to emit multi-line content
[18:59] <metsuke> if only one line is needed, is it better to use write_files or one runcmd echo?
[19:00] <rharper> write_files runs sooner ; but neither is better than the other
[19:01] <metsuke> oh interesting.  Is there a way to make write_files run later than run_cmd?
[19:01] <rharper> I guess it depends on what you need;  write_files you can also set the mode/permissions/owners on the file
[19:01] <rharper> not easily, you have to specify all of the modules for a stage and update the order;
[19:01] <rharper> in /etc/cloud/cloud.cfg, the init_modules: list and config_modules: list
[19:02] <metsuke> got it, thank you!
[19:04] <rharper> yw
[19:05] <blackboxsw> SRU is queued for xenial. bionic disco https://code.launchpad.net/~chad.smith/cloud-init/+git/cloud-init/+merge/371685 https://code.launchpad.net/~chad.smith/cloud-init/+git/cloud-init/+merge/371686 https://code.launchpad.net/~chad.smith/cloud-init/+git/cloud-init/+merge/371687 Odd_Bloke rharper  if you get a chance to review, we can push it up for SRU
[19:05] <blackboxsw> wanted to ask if there was anything to disable in this SRU
[19:05] <rharper> blackboxsw: thanks
[19:05] <rharper> I'll check the changelog
[19:46] <rharper> blackboxsw: Odd_Bloke: is there a way to "shell" into one of our tox environments?  I'm trying to debug a unittest failure under py3  only
[19:48] <Odd_Bloke> rharper: Yep, you can just use it as a virtualenv; . .tox/py3/bin/activate
[19:48] <rharper> Odd_Bloke: excellent thanks
[19:50] <blackboxsw> Odd_Bloke: rharper looks like we still need to enable exoscale in cloud-init.templates in each series
[19:50] <blackboxsw> shall I add that to the SRU proposal now?
[19:50] <rharper> also, I'm on xenial, and my nosetest3 on the outside passes fine, but inside tox -e py3 it fails ... I dont think there are any package differences in that ;
[19:50] <blackboxsw> I was expecting to see something like abe6bcdfacdf2f6745e3acf5c76b332380b9c493
[19:51] <blackboxsw> rharper: Odd_Bloke I think I'll add that to my current SRU proposal MPs now
[19:51] <blackboxsw> just need to enable Exoscale
[19:52] <rharper> yes, I think that's right
[19:54] <blackboxsw> rharper: did we intentionally not add Oracle to Xenial/bionic as a datasource option (in favor of retaining Openstack detection behavior?)
[19:54] <blackboxsw> because I don't see it in debian/cloud-init.templates
[19:54] <rharper> blackboxsw: yes; we've work yet to do
[19:55] <rharper> Odd_Bloke: has to finish up the dracut parsing so the cmdline parameter to disable netconfig can be removed
[19:55] <blackboxsw> ok, good that it wasn't omission
[20:12] <blackboxsw> ok rharper xenial, bionic disco I just added Exoscale datasource and repushed my MP
[20:12] <blackboxsw> letting CI get through it
[20:17] <blackboxsw> Odd_Bloke: sorry, reviewing your branch nowhttps://code.launchpad.net/~daniel-thewatkins/cloud-init/+git/cloud-init/+merge/371673
[20:29] <Odd_Bloke> rharper: As I'm starting to write this config generation code, I'm wondering if we should actually move to v2 config for initramfs stuff first.
[20:29] <Odd_Bloke> Otherwise I'm just writing techdebt. :p
[20:29] <rharper> hehe
[20:29] <rharper> well
[20:29] <rharper> control-manual
[20:29] <Odd_Bloke> Ah, yeah.
[20:29] <Odd_Bloke> Conscience salved, I will continue on. :p
[20:30] <rharper> oh, I think we can use critical: true on the iscsi connection
[20:30] <rharper> so while we don;t have a contro-manaual for leaving stuff _down_
[20:30] <rharper> we do have a way to say, don't bring the dhcp lease on this connection down
[20:31] <Odd_Bloke> Ah, right, yeah.
[20:31] <rharper> so restarts of networking won't break root
[20:31] <Odd_Bloke> But changing the initramfs stuff means also changing the Oracle stuff, for which we _do_ want control-manual.
[20:32] <Odd_Bloke> So I think I'm better off writing (not very much) code to produce v1, and then we can move everything up to v2 together once we're sure we're ready to do that.
[20:33] <Odd_Bloke> rharper: Does that sound reasonable?
[20:34] <blackboxsw> thanks Odd_Bloke approved https://code.launchpad.net/~daniel-thewatkins/cloud-init/+git/cloud-init/+merge/371673
[20:34] <blackboxsw> we can land that right ^?
[20:35] <Odd_Bloke> Yep, just marked as Approved.
[20:35] <rharper> well, I don't think we did want control manual, but I think we agreed to start with that?  ISTR that we could bring everything up given the "proper" parsing of the metadata and sorting out the first nic to provide a subnet would get a gateway
[20:36] <rharper> so I'm not sure if we're staging things;  if we did all v2, and sorted the gateway logic on the secondary nics in one go, then we'd not need to emit v1 as there's no control manaul requirement if we know we're not breaking primary interface routing
[20:36] <Odd_Bloke> rharper: Yeah, we did agree to start with that, but the criteria for _stopping_ doing that are not necessarily clear.
[20:39] <blackboxsw> ok xenial, bionic and disco SRU MPs all passed CI
[20:39] <blackboxsw> and have Exoscale enabled in debian/cloud-init.templates