[15:03] <robjo> smoser: rharper blackboxsw with 17.2 out the door, any chance we can make some progress on the following?
[15:03] <robjo> https://code.launchpad.net/~rjschwei/cloud-init/+git/cloud-init/+merge/334241
[15:03] <robjo> https://code.launchpad.net/~rjschwei/cloud-init/+git/cloud-init/+merge/333904
[15:03] <robjo> https://code.launchpad.net/~rjschwei/cloud-init/+git/cloud-init/+merge/333904
[15:03] <robjo> https://code.launchpad.net/~rjschwei/cloud-init/+git/cloud-init/+merge/334992
[15:03] <robjo> https://code.launchpad.net/~rjschwei/cloud-init/+git/cloud-init/+merge/334338
[15:03] <robjo> The firs two are related in that the second is the requested test, at least from my perspective, for the first MP
[15:04] <robjo> I know there is a "grand plan" and that keeps you guys rather busy.
[15:05] <robjo> I just get the impression that the "grand plan" does not consider review time until shortly before the next release, which means stuff from people that are no directly working on the "grand plan" is kind of lacking attention
[15:05] <robjo> Also I need some guidance on the "ip" vs "ifconfig" issue, see my mailing list message
[15:08] <smoser> robjo: thank you for pestering
[15:08] <smoser> :)
[15:09] <smoser> yes, we do have more things and we really do not mean to ignore you
[15:10] <smoser> robjo to be fair, nobody's "grand plan" should involve "throw stuff in right before you mark a release".
[15:10] <smoser> you were owed review cycles well before that.
[15:10] <robjo> I'd rather not be the squeaky wheel, but will be if needed, would rather figure out a way where things move somewhat more steadily
[15:11] <robjo> was not trying to imply the "stuff gets thrown in before release" it just appears that that happens to be the time when you guys have some extra cycles to look at the MPs
[15:12] <robjo> the combination of that is probably less than desirable ;)
[15:12] <rharper> we generally walk through all of the active MPs to see if there are any that are ready to take, vs. things that need more discussion/fixing/etc;  so yeah, there is a sweep; but it's not mean to ignore proper review, but rather picking up any "low hanging fruit" before the release
[15:15] <robjo> Well this one was really low hanging ;) https://code.launchpad.net/~rjschwei/cloud-init/+git/cloud-init/+merge/334241
=== r-daneel_ is now known as r-daneel
=== r-daneel_ is now known as r-daneel
[17:31] <blackboxsw> speaking of clearing out the review queue. I'm +1 on landing https://code.launchpad.net/~dojordan/cloud-init/+git/cloud-init/+merge/334341
[17:34] <blackboxsw> Robert said that azure's backend infrastructure will not activate the preprovisioning until March timeframe I think (and likely targetted at xenial only to begin w/)
[17:34] <blackboxsw> s/Robert/Douglas/
[17:34] <blackboxsw> ...  <dojordan>  let me try again. As long as my changes land in an azure image it will help unblock our testing. But when we go GA (middle of next year hopefully), we will start only preprovisioning (using the ovf setting) 16.04 LTS. The purpose of the marker file is incase we occur a VM reboot in the middle of the process
[17:35] <blackboxsw> no time to review Robert's branches
[17:35] <blackboxsw> now time to review*
[17:37] <blackboxsw> robjo: was there a specific use-case or intent you had behind supporting multiple post-up clauses in a single interface stanza per  https://code.launchpad.net/~rjschwei/cloud-init/+git/cloud-init/+merge/333904
[17:38] <blackboxsw> I had a couple inline questions there in that review
[21:52] <blackboxsw> hrm rharper smoser I honestly don't know where to go with https://code.launchpad.net/~james-hogarth/cloud-init/+git/cloud-init/+merge/333657 per the discussion we had today about dropping ifconfig (iptools) logic. Most of this is logic around printing that table or network interfaces in cloud-init-output.log. Did we agree we don't care about that human-readable printed table across the switch from net-tools ->
[21:52] <blackboxsw> iproute2 ?
[21:53] <smoser> blackboxsw: i'm still lost time :-(
[21:54] <blackboxsw> most of his branch is allowing for printing the same tabular format of network information and if we are diverging from that in our switch iproute2 support, do we take his branch and adapt it or just minimally adapt ip cli output to print network config info in cloud-init-output.log
[21:54] <smoser> i've stuck on getting history into curtin that will allow us to merge into distro branches.
[21:54] <smoser> :-(
[21:54] <smoser> wrt that merge.
[21:54] <smoser> i think that we *do* want identical table output.
[21:55] <smoser> there are two  orthoganal things here.
[21:55] <smoser> a.) getting off of 'net-tools'
[21:55] <smoser> b.) possibly dropping human friendly table output for networking information
[21:55] <smoser> i really dn't think that 'b' is necessary, and definitely in my head is not somethinng that just tags along with other changes.
[21:56] <smoser> we should not tag along external-facing changes with internal implementation changes.
[21:56] <blackboxsw> but 'b' was created via calls to 'a' tools
[21:57] <blackboxsw> ok, though we do more work to support 'b' by parsing and restructuring iproute2 tools output to continue using that nework information table in cloud-init-output.log
[21:57] <blackboxsw> if we are okay with the cost of external consistency, then no problem.
[21:57] <rharper> blackboxsw: IIRC, we're happy that the output matches as a check, longer term we may look to using 'ipaddress' instead to dump the output in table form rather than translation, but that's not a requirement for 'a' as smoser  says
[21:58] <rharper> blackboxsw: right, I recall we're ok with the extra work for now
[21:59] <blackboxsw> ok was just re-reviewing your comments on that branch rharper and wanted to make sure.   So. since hogarth did initial work in this space > 1 month ago, do I attempt a branch using his as prerequisite and we'll approach that MP as co-authored maybe ?
[22:00] <blackboxsw> or try to work his branch into something we like as is and have a follow up to drop other uses of net-tools
[22:00] <rharper> blackboxsw: wouldn't a rebase of the branch against master apply cleanly as-is ?
[22:01] <blackboxsw> rharper: yes, though it doesn't tackle any of the Azure specific uses of ifup/down for that network bounce (and I think his branch fails integration tests)
[22:02] <rharper> those are in freebsd path, right ?
[22:03] <blackboxsw> rharper: we have one in ubuntu path that currently fails on artful bionic https://bugs.launchpad.net/cloud-init/+bug/1722668
[22:03] <ubot5`> Launchpad bug 1722668 in cloud-init (Ubuntu) "Azure: bouncing of network device/publishing of hostname fails on artful" [Critical,Confirmed]
[22:03] <rharper> blackboxsw: ah, ok
[22:04] <blackboxsw> so I'll add a couple review comments toJames' branch and create a separate branch for the azure fix.
[22:04] <rharper> I wonder if we really need an interface bounce or something else
[22:04] <blackboxsw> and make it dependent on his
[22:04] <blackboxsw> I thought we were going to look at the potential of avoiding the bounce on systemd/networkd
[22:05] <rharper> if we do need to link down/link up;  we may want some sort of cloud-init/net/utils space where we could abstract the needs (and implement them via which tools are present)
[22:05] <rharper> right, well, networkd can't bounce anything
[22:05] <rharper> one needs to poke interfaces via ip link set instead
[22:05] <blackboxsw> as the hostname update seems to already be handled in the systemd space. But, that statement requires a little validation.
[22:05] <rharper> yeah
[22:07] <blackboxsw> also around this space, dojordan's approved preprovisioning branch is relying on this bounce too to notify Azure's new IMDS service of preprovisioning 'complete'
[22:07] <blackboxsw> though, again, that's only Xenial
[22:08] <blackboxsw> which has net-tools still
[22:10] <rharper> yeah; maybe we can get dojordan or paulmey to confirm what's required w.r.t just a link down/up or some other action (re-issue dhcp request) etc
[22:10] <rharper> and get that documented