[03:10] <parallel21> Runnin' `Cloud-init v. 19.2-36-g059d049c-0ubuntu2~18.04.1`
=== johnsonshi_ is now known as johnsonshi
=== cpaelzer__ is now known as cpaelzer
[16:07] <smoser> did anyone push on pstart issue ?
[16:07] <smoser> lxd and lxc-pstart issue.
[16:10] <Odd_Bloke> Not that I'm aware of yet, no.
[16:11] <powersj> I believe rharper had the action item out of the retrospective to at least file a bug
[16:12] <rharper> smoser: I'll file an issue day
[16:12] <smoser> ok. great. thank you.  I think the simplist thing that shows error is just the 'init', pstart /bin/true (and automatic stop), then init again.
[16:13] <smoser> as i showed, it gets wrong ownership of lots of files in /
[16:13] <rharper> y
[16:13] <smoser> so either  abug in shifting, or a race
[16:25] <meena> Good morning happy people
[16:32] <meena> https://github.com/canonical/cloud-init/pull/61#pullrequestreview-332699520 approved Goneri's pr
[16:34] <smoser> rharper: https://github.com/smoser/qa-scripts/tree/mini-issue if you're interested.
[16:34] <smoser> that simplifies lxc-pstart for the recreate
[16:34] <smoser> to
[16:34] <smoser> a.) use profile name pstart1 (to avoid messing up an existing system)
[16:34] <smoser> b.) not create the network at all
[16:35] <smoser> c.) in-line psuedo-init ... so one python program contains all the required stuff to recreate
[16:43] <rharper> smoser: thanks
[18:22] <meena> has anyone had a chance to look at https://hackmd.io/3-YBj1t9TAeKhmfLBQUjXQ ?
[18:31] <Odd_Bloke> meena: So I had a look, of course.  It's not 100% clear to me what our concrete next steps are.  Is that something you have an idea of (and are looking for buy-in for), or are next steps what you're hoping we can define together?
[18:39] <meena> Odd_Bloke: define buy in?
[18:42] <meena> and, no, i think i'd like to define next steps together, and then present it to the mailing list (again)
[18:58] <meena> so, the buy in or opposite of that would come from there. i'm not looking for anyone to commit to implementing this… just maybe help with testing xD
[19:06] <Odd_Bloke> meena: By "looking for buy-in" I meant "reach consensus on a proposed approach".  But it sounds like we're more in the latter mode, coming up with next steps.
[19:06] <meena> *nod *nod
[20:10] <meena> Odd_Bloke:  anyway, i like your suggestion, and i'd like to try that out.
[20:17] <Odd_Bloke> meena: IMO, I think that's the next step, to inform our next decision.
[20:18] <blackboxsw> meena: I'm +1 on that (spike) suggestion  approach. It'll give is a feel for how to iterate through that work for most network-related functions.
[20:28] <meena> We should def name all cloudnet classes Cloudnet.
[20:57] <blackboxsw> powersj: Odd_Bloke so I'm finally getting around to reviewing your PR https://github.com/canonical/cloud-init/pull/109 through bug https://bugs.launchpad.net/cloud-init/+bug/1854236.    I think this is both a documentation issue and also something that we need to limit when set-hostname is being called only when init.is_new_instance().
[20:57] <ubot5> Ubuntu bug 1854236 in cloud-init "documentation for cc_set_hostname module doesn't mention runs during "init" phase" [Medium,Triaged]
[20:58] <blackboxsw> I think we'll need a little extra logic added there to cloudinit/cmd/main to limit such early(init-local) hostname setting to allow for folks how manually reset hostname to something different after initial provisioning
[20:58] <blackboxsw> I'm adding comments and suggestions to the PR
[21:00] <Odd_Bloke> blackboxsw: That sounds like a separate bug, not something that a docs PR should be expanded to include.
[21:00] <Odd_Bloke> (And we'd obviously have to think carefully about changing that behaviour.)
[21:00] <blackboxsw> the initial bug that was filed related to that feature was due to initial boot on dhcp servers hosted in vSphere land which used DDNS to set dns entries to whatever the initial DHCP request asked for. (which in the case of a large automated deployment came up all 'ubuntu').
[21:02] <blackboxsw> sure Odd_Bloke we can/should separate that to another branch. I'll file the doc comment suggestions and a pointer to something that we'd need to do to avoid resetting hostname on every boot to what our potential stale metadata has
[21:02] <blackboxsw> I don't think a doc-only branch fixes #1854236 in entirety though
[21:03] <powersj> The bug is literally titled "documentation for..."
[21:04] <powersj> :P
[21:04] <blackboxsw> true. but it's documentation of a behavior that probably shouldn't be as broad as it is
[21:05] <blackboxsw> we can correct the docs to current behavior "per always", but I'd like to get it back to "per instance"
[21:05] <blackboxsw> and it *could* have impact on vsphere, though I *think* not.
[21:06] <blackboxsw> and it will affect anyone that has come to rely on resetting the hostname across every boot
[21:09] <powersj> agreed, I think that is worth a new bug
[21:09] <powersj> blackboxsw, why not file one while it is fresh
[21:10] <blackboxsw> yeah will do, will wrap up your review and file a new bug.
[21:12] <meena> > @blackboxsw> and it will affect anyone that has come to rely on resetting the hostname across every boot < oh no!
[21:13] <meena> Goneri: """This branch is out-of-date with the base branch""" ← 61 needs another rebase.
[21:13] <blackboxsw> meena: I think I missed a joke. didn't you file the original  bug with concerns about losing the manually set hostname ? :)
[21:14] <meena> reported by https://launchpad.net/~nathanst
[21:15] <meena> https://bugs.launchpad.net/cloud-init/+bug/1855170 this is the one i reported.
[21:15] <ubot5> Ubuntu bug 1855170 in cloud-init "system_info can change the distro" [Undecided,Incomplete]
[21:16]  * blackboxsw mixed up context. meena I saw your "oh no" and interpreted that as a concern about some user-story that I might have missed \
[21:16] <Goneri> meena, done. Can someone review the freebsd_net_renderer please?
[21:17] <blackboxsw> to me, why would someone need to attempt reset hostname to the metadata provided hostname every boot (unless they were working with some sort of cfgmanagement solution that required stable local hostnames for ongoing maintenance of a node).
[21:18] <blackboxsw> and *if* someone needed that stable hostname, wouldn't they just use a cfg management/maintenance solution like chef/puppet/ansible etc to maintain that hostname over time (instead of relying on cloud-init's initial system config features)
[21:18] <meena> blackboxsw: usually when you have a hostname that your CfgMgmt depends on; you don't want that to change ever, not even on reboot.
[21:19] <meena> some people draw a fact from the hostname… so… yeah, changing it might blow up the system… or rather, if the hostname changes, your CfgMgmt system might blow up your server.
[21:19] <blackboxsw> right. so if root  manually came in and changed the hostname some days/months after initial boot, I don't think I'd want cloud-init to re-set to the original metadata next time I rebooted the vm/machine
[21:19] <blackboxsw> because root probably had a good reason to change such a hostname
[21:19] <blackboxsw> or you got hacked ;)
[21:20] <meena> accidents happen.
[21:20] <meena> 🤷‍♀️
[21:21] <blackboxsw> heh true.
[21:22] <blackboxsw> community notice: cloud-init 19.3.41 is officially released via Ubuntu SRU (stable release update) Xenial, Bionic Disco and Eoan have access to this version and cloud-images will be updated nightly to get these new cloud-init bits. Thanks for all the help folks!
[21:24] <meena> \o/
[21:24] <meena> congratulations
[21:34] <Odd_Bloke> blackboxsw: I believe the usecase (as described in that doc PR :) is for platforms that require hostname to be set correctly for DHCP to complete successfully.
[21:34] <Odd_Bloke> In such cases, you would want it to happen every boot, because otherwise you aren't getting networking. :p
[21:34] <blackboxsw> ... specifically during initial deployment I had thought.
[21:35] <blackboxsw> but I suppose that need would hold true across reboot so you don't have DDNS hostname colllisions
[21:35] <meena> i thought once the hostname is set… it's… set.?!
[21:36] <Odd_Bloke> Perhaps it is limited to initial deployment, I don't know for sure.
[21:37] <meena> we should find out, before we try too hard ;)
[21:37] <Odd_Bloke> Not sure that DDNS plays into it here, platforms that require you to conform to their expected hostname aren't going to use the presented hostname dynamically.
[21:39]  * meena is composing a mail to  the list about REFACTORING 2.0
[21:48] <meena> message sent.
[21:52] <meena> and here's today's dead code: https://gist.github.com/10d305f65194470cb6dbad58690f123c
[21:53] <powersj> nice
[21:53] <powersj> I think we have that check turned off in pylint currently
[21:57] <blackboxsw> Odd_Bloke: I think in the past via juju deployed models on vSphere, each deplyed node ended up requesting ddns-hostname ddns-domain-name params or something to that end. Our intial dhcp setup in init-local was passing these values to whatever platform dhcp server was available, and in some vsphere/juju cases DDNS got updated to set/reset any dhcp IP allocated as hostname 'ubuntu'.   This caused problems for juju
[21:57] <blackboxsw> deployments trying to install software and react to hooks as juju would automatically start trying to talk to a new vm that 'became' ubuntu as far as DNS was concerned.
[21:58] <blackboxsw> I think what we decided to do, is say that, if the platform provides cloud-init with a desired hostname, we should assume that's what we need to be always, unless a user overrides that with user-data (#cloud-config) etc.
[21:59] <blackboxsw> though I probably misunderstood your comment about "conform to their expected hostname aren't going to use the presented hostname dynamically."
[22:00] <blackboxsw> I guess you meant that cloud-init wouldn't expect the metadata hostname to change on platforms that expect hostname to conform. (So don't expect to support people coming in after the fact to change the hostname if it was launched with a certain meta-data hostname set)
[22:04] <Odd_Bloke> blackboxsw: I was talking about the cases where we _need_ this, not the cases where it has caused problems.
[22:04] <Odd_Bloke> So I think we were just talking past one another a bit. :)
[22:18] <blackboxsw> roger. /me works on reading comrehension
[22:21] <meena> if i had known this would be formatted like ass, i would have run it thru fold(1) before sending https://lists.launchpad.net/cloud-init/msg00237.html
[22:23] <meena> welcome to the mailing list, we hope you like the 1970s!
[22:23] <meena> remember when i did code reviews via email? those were the times
[22:27] <meena> Goneri: did you some how lose my find_fallback_nic function from your code?
[23:04] <rharper> smoser: https://github.com/lxc/lxd/issues/6632