* meena doesn't understand people who just log off from irc07:27
Odd_Blokecpaelzer: Sounds like you just had a conversation about the ifupdown cloud-init thing?  What was the resolution?14:44
Odd_Blokemeena: Same!  (Though we use IRC internal to Canonical, so I suppose for some people it might be part of how they stop working at the end of the day. :p)14:45
cpaelzeryes, give me a sec Odd_Bloke14:45
cpaelzerback with you14:46
cpaelzerthe solution is that I clearly showed that it has avalid alternative dependencies14:46
cpaelzerso it isn't really a problem to get into the archive14:46
cpaelzerthere are two solutions discussed atm14:46
cpaelzer1. add extra-exclude in the seeds to get these packages out (I don't think it fits the case, but if it works ...)14:47
cpaelzer2. the tooling generating component mismatches might be confused by "Provides"14:47
cpaelzerdoko will talk to colin what the right path out of it will be14:47
cpaelzerhe will ping me with the outcome14:47
cpaelzeruntil then we wait14:48
cpaelzerOdd_Bloke: anything to add?14:48
cpaelzerthe recently synced logcheck has the same problem btw and also is a server package14:48
Odd_BlokeNope, that sounds good to me, thanks!14:48
meenaOdd_Bloke: i just close my laptop14:48
meena(and then open my phone)14:49
Odd_BlokeI don't normally check IRC outside of work hours, but it's still sitting there in a tmux waiting for me. :p14:49
Odd_Blokemeena: Are you able to attach the logs requested to https://bugs.launchpad.net/cloud-init/+bug/1855170 ?15:45
ubot5Ubuntu bug 1855170 in cloud-init "system_info can change the distro" [Undecided,Incomplete]15:45
Odd_Bloke(I see you replied, so wasn't sure if you were going to follow up with them. :)15:46
Odd_Blokecpaelzer: Could you add a few words to https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1855557, please?15:48
ubot5Ubuntu bug 1855557 in cloud-init (Ubuntu) "please drop ifupdown depedency" [High,Triaged]15:48
cpaelzerOdd_Bloke: done15:59
ahosmanMSFTHi blackboxsw, what's needed to get idchange PR merged. I've tested and validated the bug fix.16:15
blackboxswhi ahosmanMSFT I think your branch still has travis CI test errors that need resolution. The branch is checked red https://github.com/canonical/cloud-init/pull/8416:20
blackboxswahosmanMSFT: and also a unit test for dsaz.check_instance_id in test_azure.py too as we mentioned in discussion on the PR16:21
ahosmanMSFTThere is a unit test for instance_id already, right16:22
ahosmanMSFTOr do you mean to add a specific one for this functionality16:23
ahosmanMSFTblackboxsw looking at the Travis CI tracebacks:16:27
ahosmanMSFTFileNotFoundError: [Errno 2] No such file or directory: '/tmp/ci-TestAzureBounce.88hts2am/data/instance-id'16:27
ahosmanMSFTis that file suppose to be generated by the CI16:28
ahosmanMSFTAll the errors are of that type16:29
ahosmanMSFTFileNotFoundError: [Errno 2] No such file or directory: '/tmp/ci-TestAzureBounce.~~~/data/instance-id'16:29
blackboxswahosmanMSFT: so each test sets up a tmpdir if using self.tmp_dir()  that gets removed during tearDown. it's likely that directory is being torn down before your test completes maybe? I think we'll need a pdb in the setup as I mentioned on the PR to walk through a given failing test.16:51
blackboxswthen you can run .tox/py27/bin/nosetests tests.unittests.test_datasource.test_azure:TestAzureDataSource.test_waagent_d_has_0700_perms -s16:51
blackboxswand it'll let you step through the test and see why there is a race that the unit test loses.16:52
blackboxswI'll peek now for a few mins.16:52
blackboxswloooks like something is failing in get_boot_telemetry16:54
blackboxswahosmanMSFT: ahh your branch is reading config data fromprevious = util.load_file(os.path.join(16:56
blackboxsw+            self.paths.get_cpath('data'),16:56
blackboxsw+            'instance-id')).strip()16:56
blackboxsw  via dsaz._iid  (which is why we also need a unit test that exercises the datasource properly for the changeset you introduced).16:56
blackboxswthis is what's causing the test failures, because those failing unit tests  need to create the instance-id data file  in self.paths.get_cpath16:57
ahosmanMSFTblackboxsw instead of adding that file to all the unit-tests is there anything else we can do, like mock the file to return a fixed iid17:05
blackboxswahosmanMSFT: here's a patch that fixes one test, since iid is now comparing previous iid to next, those tests need to actually see a viable instance id instead of test-instance-id https://paste.ubuntu.com/p/Gxc3K2KH4t/17:07
blackboxswyou'll need to move that write_file up into either setUp or _get_ds17:07
blackboxswso that all unit tests (not just the perms test) get viable previous_iid vs iid.17:08
blackboxswand you'll need an extra test in that class to show a byte_swapped failure to match to make sure behavior of __iid works as intended given a check_instance_id17:08
* blackboxsw jumps back on SRU validation for a bit. cloud-init status meeting in a few mins17:09
blackboxswahosmanMSFT: on your PR too, we need a sensible PR summary and description that can be used for the commit message if possible (because we'll squash merge it)17:09
blackboxswhttps://github.com/cloud-init/ubuntu-sru/pull/71 is up for review for SRU verification on softlayer17:16
blackboxswok time for meeting start :)17:16
blackboxsw#startmeeting Cloud-init bi-weekly status17:17
meetingologyMeeting started Tue Dec 10 17:17:14 2019 UTC.  The chair is blackboxsw. Information about MeetBot at http://wiki.ubuntu.com/meetingology.17:17
meetingologyAvailable commands: action commands idea info link nick17:17
blackboxswWelcome folks to another cloud-init status meeting. Probably the last one of the year I presume due to upcoming Holidays in two weeks17:18
blackboxsw#chair rharper17:18
meetingologyCurrent chairs: blackboxsw rharper17:18
blackboxsw#chair Odd_Bloke17:18
meetingologyCurrent chairs: Odd_Bloke blackboxsw rharper17:18
blackboxsw cloud-init upstream uses this meeting as a platform for community updates, feature/bug discussions, and an opportunity to get some extra input on current development.17:18
blackboxswLet's start the meeting with setting the next meeting time17:19
blackboxswI think most of upstream is out the last two weeks of December. Shall we try January 7th?17:20
blackboxswAnyone opposed can voice their discontent as I remember the keystrokes to set the topic of the channel ;)_17:20
=== blackboxsw changed the topic of #cloud-init to: cloud-init pull-requests https://git.io/JeVed | Meeting minutes: https://goo.gl/mrHdaj | Next status meeting January 7 17:15 UTC | 19.4 (Dec 17) | 20.1 DROP py2.7 (Jan 2020) | https://bugs.launchpad.net/cloud-init/+filebug
blackboxswI also dropped 19.3 upstream release date from the channel topic as "that's soooo November"17:21
blackboxswtopics for this round: Feel free to interject/suggest other topics at any time.  Our typical format is the following: Previous Actions, Recent Changes, In-progress Development, Community Charter, Upcoming Meetings, Office Hours (~30 mins).17:22
blackboxsw #topic Previous Actions17:22
blackboxsw#topic Previous Actions17:22
blackboxswand oops, forgot to publish meeting minutes from last session.17:23
blackboxswdoing that now.17:23
meenais it meeting time or did I miss it?17:24
Odd_Blokemeena: It's happening as we speak.17:25
blackboxswok sorry for the delay. just pushed published meeting minutes17:27
blackboxsw#link https://cloud-init.github.io/status-2019-11-26.html#status-2019-11-2617:27
blackboxswok so previous actions from last meeting:17:27
blackboxswno unresolved actions listed17:28
blackboxsw#topic Recent Changes17:28
blackboxswfound via git log --since 11.26.201917:29
blackboxsw    - dhcp: Support RedHat dhcp rfc3442 lease format for option 121 (#76)17:29
blackboxsw      [Eric Lafontaine] (LP: #1850642)17:29
blackboxsw    - network_state: handle empty v1 config (#45) (LP: #1852496)17:29
blackboxsw    - Merge pull request #94 from gaughen/patch-1 [Joshua Powers]17:29
blackboxsw    - removed a couple of "the"s [gaughen]17:29
blackboxsw    - docs: fix line length and remove highlighting [Joshua Powers]17:29
blackboxsw    - docs: Add security.md to readthedocs [Joshua Powers]17:29
ubot5Launchpad bug 1850642 in cloud-init "No support for classless-static-routes on centos 7" [Medium,Triaged] https://launchpad.net/bugs/185064217:29
blackboxsw    - Multiple file fix for AuthorizedKeysFile config (#60) [Eduardo Otubo]17:29
blackboxsw    - Merge pull request #88 from OddBloke/travis [Joshua Powers]17:29
blackboxsw    - Revert "travis: only run CI on pull requests"17:29
blackboxsw    - doc: update links on README.md [Joshua Powers]17:29
ubot5Launchpad bug 1852496 in cloud-init (Ubuntu) "nocloud network-config mishandles empty config" [Low,In progress] https://launchpad.net/bugs/185249617:29
blackboxsw    - doc: Updates to wording of README.md [Joshua Powers]17:29
blackboxsw    - Add security.md [Joshua Powers]17:29
blackboxsw    - setup.py: Amazon Linux sets libexec to /usr/libexec (#52)17:29
blackboxsw      [Frederick Lefebvre]17:29
blackboxsw    - Fix linting failure in test_url_helper (#83) [Eric Lafontaine]17:29
blackboxsw    - url_helper: read_file_or_url should pass headers param into readurl17:29
blackboxsw      (#66) (LP: #1854084)17:29
blackboxsw    - dmidecode: log result *after* stripping n [Igor Galić]17:29
blackboxsw    - cloud_tests: add azure platform support to integration tests17:29
blackboxsw      [ahosmanmsft]17:29
ubot5Launchpad bug 1854084 in cloud-init "Headers no longer passed through read_file_or_url" [Undecided,Fix committed] https://launchpad.net/bugs/185408417:29
blackboxswthanks for all the FreeBSD work landing, utility improvements, caching and doc changes. + the dhcp lease format updates17:31
blackboxsw#topic In-progress Development17:31
blackboxswGenerally upstream is doing a fair job of getting reviews to the community for PRs, though lately we've been spending a few cycles on SRU validation for cloud-init 19.4.31 into Ubuntu Xenial, Bionic, Disco and Eoan.17:32
blackboxswexpectation is that we should be able to clear this SRU validation today/tomorrow and get back onto the review queue in github for cloud-init17:32
blackboxswmost major cloud-platforms have passed validation with no regressions, so risk is low with this release17:33
blackboxsw oops cloud-init 19.3.41  not 19.4.3117:34
blackboxswthere is plenty of work in flight by meena (FreeBSD improvements) and ahosmanMSFT (Azure instance-id work). that we hope to get reviewed and landed.17:35
blackboxswcommunity notice: Reminder we are working toward a 19.4 upstream release by end of year. So if there are bits/features that you hope to make the cut. please get those branches in shape by next tuesday Decemeber 17th17:36
blackboxsw#link https://lists.launchpad.net/cloud-init/msg00236.html17:36
blackboxswcommunity notice: Also a reminder that cloud-inig 19.4 will be the last release that claims official support for py2.717:37
blackboxswin January, tip of cloud-init will be allowed to drift from python2.7 support and tox -e py27 will no longer be exercised by upstream CI17:37
blackboxswOdd_Bloke: or rharper anyything else in-progress at the moment?17:38
blackboxswalso, anyone interested in cloud-init development, please run tools/migrate-lp-user-to-github as mentioned in the hacking guide to make sure we can account for the CLA (contributor license agreement) for cloud-init17:39
blackboxsw#link https://cloudinit.readthedocs.io/en/latest/topics/hacking.html17:39
blackboxsw#topic Community Charter17:40
blackboxswreminder on 19.4 release covered above, and getting your github account authorized for cloud-init conributions....17:40
Odd_BlokeNothing from me!17:41
meenagoneri and i have been working on / testing his freebsd render17:41
blackboxswfor folks with time to burn and bite-sized branches/fixes. we've got a lane on our trello board that gives a variety of fixes that the community can grab if they are looking for quick suggestions. "Community low-hanging fruit"17:42
blackboxsw#link https://trello.com/b/hFtWKUn3/daily-cloud-init-curtin17:42
blackboxswmeena: Goneri yes and thanks for the continued efforts there. A lot of good is coming out for cloud-init upstream as a result.17:42
meenaGoneri removed a lot of code, but from what i gather, that code is still used elsewhere17:42
meenacould someone explain why our where our how17:43
blackboxswas always, any community member is encouraged to review other PRs from devs. All reviews and input welcome.17:43
blackboxswmeena: I'm not sure I follow, are you referring to a specific branch?17:44
blackboxswor just where stale snapshots or cloud-init code lives on certain distros?17:44
blackboxsw#topic Office Hours (next ~30 mins)17:45
blackboxswmight as well kick the topic and open office hours for general cloud-init discussions, questions, bug/feature work etc.17:45
blackboxswsome upstream devs will have eyes/time available for discussion around anything cloud-init. This time will also be spent grooming the active review queue @ https://git.io/JeVed17:46
blackboxsw#link https://git.io/JeVed17:46
meenablackboxsw: https://github.com/canonical/cloud-init/pull/61#pullrequestreview-32913989117:48
blackboxswmeena: so Distro._bring_up_interface() is called by Distro._bring_up_interfaces() base class via Distro.apply_network17:52
blackboxswwhich is called from Init.apply_network_config which gets run during "cloud-init init"  when network is brought up17:59
=== ahosmanMSFT62 is now known as ahosmanMSFT
blackboxswI think https://github.com/canonical/cloud-init/pull/42 looks ready to merge. rharper has an outstanding "changes requested" but I believe those have been fixed. rharper I'll defer to you on this one18:06
blackboxswand policy question on reviews: if we get one upstream core-dev +1 can we proceed to land the branch as long as the "changes requested" from other upstream core seem to be resolved?18:08
blackboxswI'd vote that most recent core-dev on the PR that +1's can squash merge if they see that any prior core-dev's concerns seem to be addressed18:09
blackboxswI think I'll add an action for next meeting to make sure we iron out review/merge policy so PRs don't sit stale18:12
blackboxsw#action rharper confirm no concerns on https://github.com/canonical/cloud-init/pull/42 and that PR can land.18:13
meetingologyACTION: rharper confirm no concerns on https://github.com/canonical/cloud-init/pull/42 and that PR can land.18:13
blackboxsw#action upstream core-devs to decide about whether a PR can land if any upstream dev still has 'requested changes'18:14
meetingologyACTION: upstream core-devs to decide about whether a PR can land if any upstream dev still has 'requested changes'18:14
blackboxswok I *think* that about wraps the meeting. Merry Christmas, Happy Hanukkah, Happy New Year and all that good stuff. See you all online.18:16
meetingologyMeeting ended Tue Dec 10 18:16:39 2019 UTC.18:16
meetingologyMinutes:        http://ubottu.com/meetingology/logs/cloud-init/2019/cloud-init.2019-12-10-17.17.moin.txt18:16
blackboxswMeeting minutes published: https://cloud-init.github.io/status-2019-12-10.html#status-2019-12-1018:21
meenadoes anyone have any opinions on vendor-data being able to override "distro"?18:35
meenais rharper not here?18:36
blackboxswit feels like vendor data shouldn't need to override distro, and frankly it feels a bit strange for cloud-init to be determining distro based on system_info. I'm not sure for which environment we wouldn't want cloud-init to just use util.get_linux_distro() nowadays. I'm thinking there used to be a couple of legacy cases where we'd need to set that distro as cloud-init couldn't detect it, but I'm wondering if can19:18
blackboxswnow be made unnecessary.   The reason I could see sourcing distro: X from cloud.cfg would be for folks rolling their own package and/or images, wanting to override the detected underlying distro because they know of preferred distro-class behavior that is applicable to their images. I can't really think of a compelling other reason off the top of my head. Maybe other folks have ideas there.19:18
blackboxswI'd rather do-away with the cloud-init package (rpm/deb/etc) providing an opinionated system_info: distro: X and rely on util.get_linux_distro() if  system_info.get('distro') is None.19:19
blackboxswbut maybe that dynamic parsing of /etc/os-release or /bin/freebsd-version is considered too costly or brittle?  I *think* we may be at a place where we can make that shift now to a smarted cloud-init instead of forcing a package to strictly define the distro value19:21
blackboxswmeena, I presume you were referring to https://bugs.launchpad.net/cloud-init/+bug/185517019:22
ubot5Ubuntu bug 1855170 in cloud-init "system_info can change the distro" [Undecided,Incomplete]19:22
rharpermeena: my general opinion is that vendor-data is useful for setting *vendor* defaults; for example, a number of platforms provide a ntp endpoint, which is cloud specific; that's a perfectly good example where by default, if you enable ntp in your cloud-config, you'll get the vendor supplied ntp configuration; though if a user provides their own config, then that overrides it.19:25
rharperI've seen in some other cases where vendor-data is used to override default behavior in an image; which I think is less great;  I think some of the baked-in vendor-data in Digital Ocean, for example, is a bit over-the-top;19:26
rharperthe bug specified Hetzner vendor-data as problematic; I've not seen what's included in that; but generally 1)  users can complain to vendor  2) let them know they're not using the vendor and why  3)  cloud-init should provide a way for you to override any vendor-data provided.  In that bug, I'd like to see if we can't collect enough information so we can provide an  docs page on disabling/overriding vendor-data ;19:27
blackboxsw+1 on that rharper I added that sudo cloud-init query vendordata could easily give us a gimpse of that data on a hetzner instance if someone has access19:30
blackboxswrharper: initial thoughts on https://github.com/canonical/cloud-init/pull/48#pullrequestreview-32853816719:42
blackboxswthe one-shot daemon19:43
blackboxswwe should probably have a discussion about the cimain entry points and whether it's worth cleaning up cmd/main to use a better entry point for the daemon19:43
blackboxswmaybe tomorrow we can setup a mtg19:44
Odd_Blokerharper: blackboxsw: I'm seeing disco and eoan lxd images built using lxc-proposed-snapshot fail to launch properly (AFAICT not due to cloud-init issues).  Have either of you seen such a problem?20:07
blackboxswOdd_Bloke: I'm about to file a bug on that now. disco & eoan snapd.seeded.service is busted20:08
blackboxswand blocking systemd-analyze20:08
blackboxswsystemctl list-jobs shows it for me20:08
blackboxswis that what you are seeing?20:09
blackboxswOdd_Bloke: looked a bit like this https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/180607020:10
ubot5Ubuntu bug 1806070 in snapd "snapd.seeded.service never completes preventing full boot to default target" [High,Fix released]20:10
Odd_BlokeYep, that's it.20:10
Odd_BlokeGood find.20:10
Odd_BlokeSorry, I'm seeing the same boot issue.20:10
Odd_BlokeNot 100% sure it's that bug. :)20:10
rharperyeah, has anyone tried looking at the snap changes output ?20:12
Odd_BlokeThere are multiple failed changes.20:12
Odd_BlokeI don't think it's that bug, it looks like a mount is failing.20:13
rharperwhat about launching daily eoan or disco images ? without doing our upgrade20:13
rharperdoes it work ?20:13
Odd_BlokeDec 10 20:10:26 eoan-lp1852100 mount[1237]: mount: only root can use "--options" option (effective UID is 1000000)20:13
Odd_BlokeYep, it works.20:13
Odd_BlokeI think the capture is messing up UIDs somehow.20:13
Odd_Bloke# ls -lah /root/.bashrc20:14
rharperyeah, my manual launch + add proposed upgrade works20:14
Odd_Bloke-rw-r--r-- 1 1000000 1000000 3.1K Aug 27 18:31 /root/.bashrc20:14
rharperI think we've seen the snapshot stuff break before20:14
rharperthere was an upstream issue filed, and I think we were told to deal with it ...20:14
blackboxswrharper: snap changes 1    Error   today at 20:00 UTC  today at 20:00 UTC  Initialize system state20:15
blackboxsw2    Error   today at 20:00 UTC  today at 20:00 UTC  Initialize device20:15
Odd_BlokeYep, that's what I'm seeing.20:16
blackboxswrharper: without upgrade it also breaks for me20:16
Odd_BlokeYep, it's definitely the capture.20:16
rharpercheck in #snappy on freenode I guess20:20
rharperah, blackboxsw you're already there =) +120:20
blackboxswyeah me also tries the internal channel as I'm getting no response there20:20
blackboxswstrange Odd_Bloke rharper is that I have 2 focal machines that appear to be on the same versions of snap-related pkgs. and one succeeds, the other doesn't20:21
blackboxswkernel diffs though 5.3.0-19-generic (failure box) 5.3.0-23-generic (success box)20:22
blackboxswI'll try a kernel upgrade on the host system and see if that fixes the broken20:22
blackboxswOdd_Bloke: rharper I have  success after a kernel upgrade20:25
blackboxswtesting the proposed lxc launch to be sure20:26
blackboxswwell, to be specific, apt-get dist-upgrade on focal20:26
rharperare you using lxd from snap ?20:26
rharperI wonder if the shiftfs feature is at play20:26
blackboxswrharper: yes on the 'formerly broken' box lxd         3.0.4                11348  3.0/stable/…  canonical✓     -20:26
blackboxswrharper: and yes on the formerly-working box lxd                   3.18                        12631  stable    canonical✓        -20:27
blackboxswso laptop (working) was on 3.18. desktop on 3.0.4 (broken originally)20:27
blackboxswI'll refresh the snaps for both20:27
blackboxswhrm ok -proposed image creation is still busted for me on lxc via using our lxc-setup-proposed tool.20:33
blackboxswbut bare lxc launch ubuntu-daily:disco work20:33
blackboxswlxc-proposed-shapshot rather20:34
blackboxswhrm on the broken disco.  curl https://api.snapcraft.io/api/v1/snaps/sections20:39
blackboxswcurl: (6) Could not resolve host: api.snapcraft.io.   (errors I saw related to snapd service in /var/log/syslog about dns errors)20:39
blackboxswon bionic/xenial I can curl that hostname20:40
blackboxswsomething funky w/ networking disco/eoan20:40
rharperthat should be solvable20:44
Odd_Blokeblackboxsw: So which lxd version is working for you?20:44
Odd_Blokes/working/working better/20:44
rharpernetworkctl , systemd-resolve --status20:45
blackboxswyeah, about that. lxd                   3.18                        12631  stable    canonical✓        -   as a snap20:46
blackboxswI'm testing snap refresh lxd --beta right now20:46
blackboxswthough I think --beta dropped the ubuntu-daily: image list (I am using ubuntu:XXX instead )20:46
blackboxswawaiting an lxc spin up now20:47
blackboxswbah, have to run an errand. more on this later if I get it working on my failed box20:47
blackboxswbtw, I'm also seeing tracebacks in cloud-init.log regarding ssh-import-id: [me] on bionic/xenial.20:49
blackboxswI'm wondering what our lxc-proposed-snapshot is twiddling that might be botching initial network setup.20:50
Odd_Blokeblackboxsw: It might just be an issue with image capture in lxd?20:58
Odd_BlokeRather than something specific to our script.20:58
Odd_Blokepowersj: FYI, we're running into some tooling issues with lxd that are hindering SRU work ATM.21:03
powersjthat is what I have gathered :P21:03
powersjOdd_Bloke, you all don't know if it is lxd or the script yet though?21:04
Odd_BlokeI just launch ubuntu:d and a `lxc publish` didn't produce a broken image.21:04
Odd_BlokeSo it's some interaction between our tooling and lxd that's causing the problem.21:05
Odd_Blokeblackboxsw: rharper: I don't really know where to start on this.  Any thoughts?21:16
rharperOdd_Bloke: is this the snap failing one?21:17
Odd_BlokeI don't follow.21:17
Odd_Blokelxc-proposed-snapshot produces broken images on disco and eoan.21:18
rharperah, ok21:18
Odd_BlokeI _think_ everything else we've seen is a symptom of that.21:18
rharpercan you reproduce on diglett? and I can just in and look at it ?21:18
Odd_BlokeI can try!21:18
rharperblackboxsw: it sounds like a general DNS failure; which could be an issue with networkd/resolved or our network config21:19
rharperif we can't hit the snap api end point nor launchpad (ssh import id failing) then we have a networking issue21:19
Odd_Blokerharper: The image is oddbloke-disco-test and there's a launched container named neat-gopher.21:22
Odd_Bloke(Note that `lxc shell ...` fails but `lxc exec ... /bin/bash` works.)21:22
rharper# networkctl status21:23
rharperWARNING: systemd-networkd is not running,21:23
rharperthat's not good21:23
rharperDec 10 21:22:00.423425 neat-gopher systemd-networkd[260]: Directory "/run/systemd/netif" already exists, but is owned by 0:0 (101:103 was requested), refusing.21:24
rharperlooks like somethings up with the snapshots and permissions21:24
rharperI suspect shiftfs related21:24
Odd_Blokerharper: Yeah, if you look at /root, the files are owned by 100000.21:40
Odd_BlokeOr 1000000.21:40
Odd_Bloker"10+" is my point. :p21:40
rharperI don't know why that's the case with starting from snapshots21:41
Odd_BlokeThe confusing thing is that it doesn't happen if you just do `lxc publish` of a running container.21:41
rharperand I've not found the google-fu to find the lxd issue; I'm sure there's one for this21:41
Odd_Blokes/running/manually launched/21:41
rharperwhat commands do we run ?21:41
rharperahh, the pstart21:43
rharperI wonder if there's something going on with init + modifications21:43
Odd_BlokeWait, we inject a fake init?21:54
blackboxswhrm is it possible we are constructing he network profile wrong in pstart?21:54
blackboxswcsmith@downtown:~/src/ubuntu-sru (sru/19.3.41-softlayer)$ lxc profile show pstart021:54
blackboxsw  raw.lxc: lxc.init.cmd=/sbin/psuedo-init --network=
blackboxswdescription: Profile for psuedo-start.21:54
blackboxsw  eth0:21:54
blackboxsw    nictype: bridged21:54
blackboxsw    parent: pstart021:54
blackboxsw    type: nic21:54
blackboxswname: pstart021:54
blackboxsw- /1.0/containers/disco-proposed-25909752421:54
blackboxswwrong copy after pastebin21:54
Odd_Blokeblackboxsw: Are the UIDs in the broken-network container correct?21:55
Odd_Bloke(i.e. what are the files in /root owned by?)21:55
Odd_Bloke(If not, then I suspect the networking failure is just a symptom of root not owning any files on the system. :p)21:55
blackboxsw10000... 1000 as you mentioned earlier21:56
blackboxsw1000000 rather. yeah that could be21:57
rharperyes, this is related to non-root files21:57
rharperso, the question is what 3.18 did to break lxc-pstart21:57
rharperI think if you run this on older lxd, we should be fine21:57
rharperso a Xenial VM with lxd 2.0 will surely work fine21:57
ahosmanMSFTblackboxsw if I write to a file to test do I have to rewrite to that file... https://paste.ubuntu.com/p/7QrcSCP4wM/21:59
Odd_Blokerharper: Right, good point about being able to just use a VM.22:00
Odd_Blokelxc-proposed-snapshot requires lxd 2.1 or later, so a xenial VM doesn't do the trick.22:08
rharperoh, huh22:09
rharperI swear I ran it before on xenial22:10
rharper3.0.3 in bionic debs22:10
rharperso maybe that's unbroken22:10
Odd_BlokeYeah, I'm trying bionic next.22:10
rharperblackboxsw: huh, I didn't realize bionic didn't do network_data.json complete rendering ...22:36
rharperjust spent 30 minutues trying to sort out why the dhcpv6-stateful config didn't render the right network-config during boot; but net-convert dumps it correctly  ...22:36
Odd_BlokeOK, a bionic VM appears to work fine.22:42
Odd_BlokeI'll finish this task up tomorrow morning.22:43
blackboxswahosmanMSFT: /7QrcSCP4wM/22:50
blackboxswahosmanMSFT: https://paste.ubuntu.com/p/hkgBtD5fN7/22:50
blackboxswwant to assert that a byteswapped instance-id results in emitting the previous iid. non-byteswapped results in emitting the current iid22:50
ahosmanMSFTblackboxsw thx, you think we'll have time to get this merged today once travis is looking good?22:57
blackboxswahosmanMSFT: will probably get through the final review tomorrow, as soon as the SRU publishes. need to fix the lxc issues we are seeing on the existing SRU so we can release that queued upload22:59
blackboxswthen we can also publish your changeset to ubuntu focal as soon as it lands22:59
blackboxswas that publishing to Ubuntu Focal only takes about 5 mins to queue (no SRU testing required)22:59
blackboxswso that changeset will be testable as soon as Azure cloud images get rebuilt23:00
ahosmanMSFTblackboxsw Great23:01
blackboxswrharper: smoser Odd_Bloke what do you think about us dropping the pstart lxc-proposed-snapshot and instead trying to boot lxc with cloud-init disabled out of the gate. upgrading to -proposed and then rebooting with cloud-init enabled23:05
blackboxswmaybe that is a little 'dirtier' but we don't get messed up by lxc internal config changing w.r.t. snapshots and hijacking init23:06
ahosmanMSFTblackboxsw fixed idchange squash commit and travis run23:22
blackboxswok ahosmanMSFT and I'm changing your PR title to azure: avoid re-running cloud-init when instance-id is byte-swapped23:24
blackboxswbecause we like to make the commit title to represent something descriptive about the area of code that is being touched23:25
ahosmanMSFTblackboxsw Looks all good from my side, let me know if I should add anything else https://github.com/canonical/cloud-init/pull/8423:53

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