[08:26] <hipolito> Hi!, cloud-init writes permanent interface rules in udev. Is there a way to disable it? So the system uses the systemd predictable interface names instead of eth*
[08:56] <meena> hipolito: yeah, there's a setting… lemme look that up
=== vrubiolo1 is now known as vrubiolo
[09:25] <hipolito> thanks meena
[09:40] <meena> hipolito: never mind, i have *nod* idea.
[09:42] <meena> nod? no.
[09:42] <meena> i just looked it up in the code, there doesn't seem to be a switch
[09:43] <meena> and here i thought it was just not (badly?) documented.
[09:43] <meena> i don't even know how you would override that in the user-config…
[09:43] <meena> you wouldn't
[10:47] <hipolito> meena: well I guess I have to live with that
[10:47] <hipolito> meena: thanks a lot!
[10:47] <meena> hipolito: thought this was an answer from someone in ##rust trying to help me lolol
[11:07] <hipolito> meena: that I didn't understand, I guess I missed something
[13:28] <amansi26> Hi.. I have a query for cloud-init v19.1 . I am trying to install. Initially it came to disable status . Then I ran cloud-init clean and cloud-init init . So now the status is in running state. But when I do capture and deploy a new VM, the deployed VM get assigned with the base VM IP.
[13:30] <amansi26> I check /etc/network/interface it has the base VM IP. but /etc/network/interfaces.d/50-cloud-init.cfg file has correct IP. How can I make the IP up?   I am using ubuntu 16.04 with ConfigDrive datasource
[13:30] <amansi26> Deployed VM status is disabled
[13:34] <amansi26> And it says http://paste.openstack.org/show/788920/ on running cloud-init init
[15:16] <Odd_Bloke> rharper: blackboxsw: If I could get a review of https://github.com/canonical/cloud-init/pull/199 sooner rather than later, that'd be good.
[15:16] <Odd_Bloke> We have contributions that need CLA signatures; having a working link is somewhat important for that. ¬.¬
[15:52] <meena> i hope the CLA checker emails those PRs to your legal department
[15:52] <smoser> https://github.com/canonical/cloud-init/pull/128
[15:52] <smoser> i can land that... but whatam i supposed to push
[15:53] <smoser> oh. squash and merge is the only option.
[15:54] <Odd_Bloke> smoser: I can land it with a +1 from you, I think, sorry I didn't think to ping you!  But, yeah, squash and merge is The Button.
[15:55] <smoser> oh fudge
[15:55] <smoser> "CLA not signed"
[15:56] <smoser> well, the label says that, but he has signed it.
[16:02] <Odd_Bloke> smoser: I think we have the link between GitHub and Launchpad, but not the actual signature on the LP account.
[16:02] <Odd_Bloke> But maybe I'm misremembering.
[16:02] <Odd_Bloke> Will check in a bit.
[16:58] <rharper> blackboxsw: ok, I've updated my two PRs for ubuntu/xenial and ubuntu/bionic using the new-upstream-snapshot as we discussed and leaving the debian/changelog entry as UNRELEASED;
[17:33] <blackboxsw> +1 rharper checking now
[17:33] <rharper> blackboxsw: and I'm not sure about the merge ;  I don't think we want to squash merge for release branches, right ?
[17:33] <blackboxsw> rharper: +1 no squash merge for those
[17:34] <blackboxsw> we want the separate debian/changelog commits so we can (in theory) apply the functional patches to a separate ubuntu/<release>
[17:34] <blackboxsw> though that doesn't truly make sense for this case
[17:34] <blackboxsw> as we patched the series-specific debian/patches/X
[17:35] <blackboxsw> ahh right rharper, and we don't want to collapse the separate  merge commits pulled in from new-upstream-snapshot either
[17:36] <blackboxsw> now that I see the PR
[17:40] <blackboxsw> rharper: so, I'd have expected the debian/changelog post the new-upstream-snapshot to contain all the commits listed in the single squashed debian/changelog entry, but I still only see your original debian/changelog individual entry https://github.com/canonical/cloud-init/blob/5ff6b663d75b02ff6d8ff0b824488d99a876ae00/debian/changelog
[17:40] <rharper> hrm
[17:40] <rharper> I just ran new-upstream-snapshot
[17:40] <rharper> so why would changelog not be correct ?
[17:41] <blackboxsw> I'll paste a diff or what I get after new-upstream-snapshot
[17:41] <blackboxsw> hrm, checking
[17:41] <rharper> it looks to be there to me
[17:41] <rharper> lemme look at github files
[17:41] <blackboxsw> UI github might be stale
[17:41] <blackboxsw> I'm refreshing git on cmdline to be sur
[17:41] <blackboxsw> or *fetch*ing rather
[17:41] <rharper> strange
[17:41] <rharper> I see that was well
[17:42] <rharper> but locally it's modified
[17:42] <rharper> that's messed up
[17:42] <blackboxsw> ahh you didn't push to your rharper-github-origin maybe?
[17:43] <rharper> I force pushed to my github branch
[17:43] <blackboxsw> ok fetching again
[17:43] <rharper> I see what you're seeing on the UI
[17:43] <rharper> but my local repo shows correct debian/changelog with all entries
[17:43] <blackboxsw> oops I was diffing my bionic vs your xenial too :)
[17:43] <rharper> no
[17:43] <rharper> I see the problem
[17:44] <blackboxsw> https://paste.ubuntu.com/p/6YD39PkyYj/ yeah still a problem
[17:44] <rharper> I think I forgot the local commit steps
[17:44] <blackboxsw> right right
[17:44] <rharper> thanks, lemme do those
[17:45]  * rharper starts over 
[17:47] <rharper> yeah, it complains about no SRU bug number, so I think it doesn't do the normal commit it would
[18:06] <blackboxsw> ahh when I dch -i added by entry, I incorrectly forgot to add the ~18.04 series designator so =I didn't get the SRU_BUG prompt. .... ok I have the steps working on my side rharper ( and I don't think we need/or want to fully run new-upstream-snapshot)
[18:06] <rharper> almost there
[18:06] <rharper> I've fixed up my xenial branch
[18:06] <rharper> just about done with bionic
[18:06] <blackboxsw> pasting what I did: (using your branch as reference)
[18:07] <rharper> mostly not committing the debian/changelog change the SRU bug ref being not added (which I think in this case don't want to put anything in there yet)
[18:11] <blackboxsw> rharper: https://pastebin.ubuntu.com/p/nywt73xSVp/ is what I did
[18:11] <blackboxsw> rharper: that is a good alternative to allow us to avoid adding the SRU_BUG_NUMBER_HERE if we know we are not yet releaseing
[18:11] <rharper> blackboxsw: yeah, i;ve updated bionic now as well
[18:12] <rharper> oh, I see
[18:12] <rharper> instead of the new-upstream-snapshot  use the refresh patches only path
[18:12] <rharper> will that update the changelog correctly ?
[18:12] <blackboxsw> though if you truly performed the new-upstream-snapshot and pulled in the upstream commits, then we would want those commits in the debian/changelog as the don't get found and collated again
[18:12] <rharper> right, that's what I was thinking
[18:13] <rharper> so, I suspect we just have to deal with the SRU bug noise in this exceptional path
[18:13] <rharper> it only triggers if an upstream commit modifies files that are patched in the release branch
[18:13] <blackboxsw> rharper: yes --update-patches-only left me with a single dch entry about 'refreshing patches' once I applied your fix to the debian/patches/ua...tip file
[18:14] <rharper> yeah, I think what I did now is the right thing
[18:14] <rharper> and this is the missing commit you wanted, https://github.com/canonical/cloud-init/pull/196/commits/a444f4d4fbb7b24627bf86166724edeedd491e8d
[18:15] <blackboxsw> +1 rharper works for me. so do we have a work item for new-upstream-snapshot to 'ignore SRU_BUG_NUMBER_HERE' that we need to do then?
[18:15] <blackboxsw> since we aren't yet releasing in SRU
[18:16] <rharper> blackboxsw: maybe
[18:16] <rharper> once we land these two PRs, and new upstream commits, we can test/verify what new-upstream-snapshot does in that case
[18:16] <rharper> I suspect that its OK to have SRU_BUG in changelog as long as the top clog entry is still UNRELEASED
[18:17] <blackboxsw> otherwise we could have used just new-upstream-snapshot --update-patches-only route with a manual fix to debian/patches/ubuntu-avantage*tip
[18:17] <rharper> well, I think we said we want to keep debian/changelog up-to-date with state of the branch, so
[18:18] <blackboxsw> we can either way: 1: only run new-upstream-snapshot --update-patches-only (and manually fix the debian/patch as you did in your original diff) and leave the branch alone at that point     OR
[18:19] <rharper> blackboxsw: stand-up hangout real quick ?
[18:19] <blackboxsw> 2. perform the full new-upstream-snapshot and manually patch the debian/patch/debian/patches/ubuntu-advantage-revert-tip.patch  and make sure the upstream commits that got add are all present in debian/changelog and we leave it in UNRELEASED state
[18:19] <blackboxsw> yeah definitely
[18:19] <blackboxsw> was thinking the same
[21:12] <blackboxsw> rharper: https://github.com/canonical/cloud-init/pull/197 and https://github.com/canonical/cloud-init/pull/196 are approved if you wanted to git push origin/ubuntu/xenial  from your fix branches
[21:12] <blackboxsw> rharper: we avoid squash merge in the github UI at the moment so I think we'd have to do this commandline
[21:12] <blackboxsw> *on the command line*
[21:15] <rharper> blackboxsw: yes, I can push to origin I think