| 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:26 |
|---|---|---|
| meena | hipolito: yeah, there's a setting… lemme look that up | 08:56 |
| === vrubiolo1 is now known as vrubiolo | ||
| hipolito | thanks meena | 09:25 |
| meena | hipolito: never mind, i have *nod* idea. | 09:40 |
| meena | nod? no. | 09:42 |
| meena | i just looked it up in the code, there doesn't seem to be a switch | 09:42 |
| 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 | 09:43 |
| 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 | 10:47 |
| hipolito | meena: that I didn't understand, I guess I missed something | 11:07 |
| 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:28 |
| 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:30 |
| amansi26 | And it says http://paste.openstack.org/show/788920/ on running cloud-init init | 13:34 |
| 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:16 |
| 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:52 |
| smoser | oh. squash and merge is the only option. | 15:53 |
| 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:54 |
| smoser | oh fudge | 15:55 |
| smoser | "CLA not signed" | 15:55 |
| smoser | well, the label says that, but he has signed it. | 15:56 |
| 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:02 |
| 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; | 16:58 |
| 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:33 |
| 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:34 |
| blackboxsw | ahh right rharper, and we don't want to collapse the separate merge commits pulled in from new-upstream-snapshot either | 17:35 |
| blackboxsw | now that I see the PR | 17:36 |
| 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:40 |
| 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:41 |
| 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:42 |
| 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:43 |
| 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:44 |
| * rharper starts over | 17:45 | |
| rharper | yeah, it complains about no SRU bug number, so I think it doesn't do the normal commit it would | 17:47 |
| 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:06 |
| 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:07 |
| 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:11 |
| 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:12 |
| 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:13 |
| 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:14 |
| 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:15 |
| 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:16 |
| 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:17 |
| 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:18 |
| 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 | 18:19 |
| 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:12 |
| rharper | blackboxsw: yes, I can push to origin I think | 21:15 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!