parallel21Runnin' `Cloud-init v. 19.2-36-g059d049c-0ubuntu2~18.04.1`03:10
=== johnsonshi_ is now known as johnsonshi
=== cpaelzer__ is now known as cpaelzer
smoserdid anyone push on pstart issue ?16:07
smoserlxd and lxc-pstart issue.16:07
Odd_BlokeNot that I'm aware of yet, no.16:10
powersjI believe rharper had the action item out of the retrospective to at least file a bug16:11
rharpersmoser: I'll file an issue day16:12
smoserok. 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:12
smoseras i showed, it gets wrong ownership of lots of files in /16:13
smoserso either  abug in shifting, or a race16:13
meenaGood morning happy people16:25
meenahttps://github.com/canonical/cloud-init/pull/61#pullrequestreview-332699520 approved Goneri's pr16:32
smoserrharper: https://github.com/smoser/qa-scripts/tree/mini-issue if you're interested.16:34
smoserthat simplifies lxc-pstart for the recreate16:34
smosera.) use profile name pstart1 (to avoid messing up an existing system)16:34
smoserb.) not create the network at all16:34
smoserc.) in-line psuedo-init ... so one python program contains all the required stuff to recreate16:35
rharpersmoser: thanks16:43
meenahas anyone had a chance to look at https://hackmd.io/3-YBj1t9TAeKhmfLBQUjXQ ?18:22
Odd_Blokemeena: 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:31
meenaOdd_Bloke: define buy in?18:39
meenaand, no, i think i'd like to define next steps together, and then present it to the mailing list (again)18:42
meenaso, 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 xD18:58
Odd_Blokemeena: 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 *nod19:06
meenaOdd_Bloke:  anyway, i like your suggestion, and i'd like to try that out.20:10
Odd_Blokemeena: IMO, I think that's the next step, to inform our next decision.20:17
blackboxswmeena: 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:18
meenaWe should def name all cloudnet classes Cloudnet.20:28
blackboxswpowersj: 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
ubot5Ubuntu bug 1854236 in cloud-init "documentation for cc_set_hostname module doesn't mention runs during "init" phase" [Medium,Triaged]20:57
blackboxswI 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 provisioning20:58
blackboxswI'm adding comments and suggestions to the PR20:58
Odd_Blokeblackboxsw: 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
blackboxswthe 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:00
blackboxswsure 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 has21:02
blackboxswI don't think a doc-only branch fixes #1854236 in entirety though21:02
powersjThe bug is literally titled "documentation for..."21:03
blackboxswtrue. but it's documentation of a behavior that probably shouldn't be as broad as it is21:04
blackboxswwe can correct the docs to current behavior "per always", but I'd like to get it back to "per instance"21:05
blackboxswand it *could* have impact on vsphere, though I *think* not.21:05
blackboxswand it will affect anyone that has come to rely on resetting the hostname across every boot21:06
powersjagreed, I think that is worth a new bug21:09
powersjblackboxsw, why not file one while it is fresh21:09
blackboxswyeah will do, will wrap up your review and file a new bug.21:10
meena> @blackboxsw> and it will affect anyone that has come to rely on resetting the hostname across every boot < oh no!21:12
meenaGoneri: """This branch is out-of-date with the base branch""" ← 61 needs another rebase.21:13
blackboxswmeena: I think I missed a joke. didn't you file the original  bug with concerns about losing the manually set hostname ? :)21:13
meenareported by https://launchpad.net/~nathanst21:14
meenahttps://bugs.launchpad.net/cloud-init/+bug/1855170 this is the one i reported.21:15
ubot5Ubuntu bug 1855170 in cloud-init "system_info can change the distro" [Undecided,Incomplete]21:15
* 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
Gonerimeena, done. Can someone review the freebsd_net_renderer please?21:16
blackboxswto 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:17
blackboxswand *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
meenablackboxsw: usually when you have a hostname that your CfgMgmt depends on; you don't want that to change ever, not even on reboot.21:18
meenasome 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
blackboxswright. 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/machine21:19
blackboxswbecause root probably had a good reason to change such a hostname21:19
blackboxswor you got hacked ;)21:19
meenaaccidents happen.21:20
blackboxswheh true.21:21
blackboxswcommunity 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:22
Odd_Blokeblackboxsw: 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_BlokeIn such cases, you would want it to happen every boot, because otherwise you aren't getting networking. :p21:34
blackboxsw... specifically during initial deployment I had thought.21:34
blackboxswbut I suppose that need would hold true across reboot so you don't have DDNS hostname colllisions21:35
meenai thought once the hostname is set… it's… set.?!21:35
Odd_BlokePerhaps it is limited to initial deployment, I don't know for sure.21:36
meenawe should find out, before we try too hard ;)21:37
Odd_BlokeNot 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:37
* meena is composing a mail to the list about REFACTORING 2.021:39
meenamessage sent.21:48
meenaand here's today's dead code: https://gist.github.com/10d305f65194470cb6dbad58690f123c21:52
powersjI think we have that check turned off in pylint currently21:53
blackboxswOdd_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 juju21:57
blackboxswdeployments 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:57
blackboxswI 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:58
blackboxswthough I probably misunderstood your comment about "conform to their expected hostname aren't going to use the presented hostname dynamically."21:59
blackboxswI 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:00
Odd_Blokeblackboxsw: I was talking about the cases where we _need_ this, not the cases where it has caused problems.22:04
Odd_BlokeSo I think we were just talking past one another a bit. :)22:04
blackboxswroger. /me works on reading comrehension22:18
meenaif 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.html22:21
meenawelcome to the mailing list, we hope you like the 1970s!22:23
meenaremember when i did code reviews via email? those were the times22:23
meenaGoneri: did you some how lose my find_fallback_nic function from your code?22:27
rharpersmoser: https://github.com/lxc/lxd/issues/663223:04

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!