[00:55] <blackboxsw> https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1866930 created and https://github.com/canonical/cloud-init/pull/114 pushed for tomorrow rharper
[09:17] <slaweq> hi
[09:18] <slaweq> I'm working on OpenStack Neutron and I want to talk with You about Metadata over IPv6
[09:18] <slaweq> since some time we have spec https://review.opendev.org/#/c/315604/ to add support for IPv6 in Neutron
[09:19] <slaweq> *for Metadata over IPv6 in Neutron
[09:19] <slaweq> the proposal in this spec is to use fe80::a9fe:a9fe as IPv6 address which is equivalent to 169.254.169.254
[09:20] <slaweq> but as cloud-init is one of the main users of metadata service, I would like to ask also You about that, what do You think about it and if this will work for You
[09:20] <slaweq> any feedback here or in the spec's review will be appreciated :)
[09:22] <tribaal> slaweq: just a note - most of the cloud-init community lives in US timezones, so replies can take a few hours to come.
[09:23] <slaweq> tribaal: thx for that info
[09:23] <slaweq> tribaal: is there any active ML for cloud-init where I can maybe send such question?
[09:25] <tribaal> slaweq: yes, I think https://launchpad.net/~cloud-init (notice the mailing list link) would be the relevant contact point. Note that you need to be part of the "team" to post, but to my knowledge that's just a matter of clicking "join" :)
[09:26] <slaweq> tribaal: thx a lot
[09:26] <slaweq> I will try that
[09:27] <tribaal> slaweq: from a scan of the openstack-specific DS code in the tree it seems like using ipv6 (or an ipv6 fallback) for the datasource is possible
[09:28] <tribaal> I'm not sure how that is implemented in other datasources however (currently the openstack datasource will check on http://169.254.169.254 unconditionally)
[09:29] <tribaal> ah, my bad. it will check there unless the metadata ur is supplied through the config as metadata_urls
[09:29] <slaweq> tribaal: can You point me to the code with that?
[09:29] <tribaal> sure, sec
[09:30] <slaweq> tribaal: thx a lot
[09:30] <tribaal> slaweq: https://github.com/canonical/cloud-init/blob/master/cloudinit/sources/DataSourceOpenStack.py#L59
[09:31] <slaweq> tribaal: so in fact if we will add som IPv6 address, it can be configured in cloud-init's config to be used
[09:32] <slaweq> so in fact no changes in cloud-init code are required in fact
[09:32] <tribaal> slaweq: yes, it looks like that would eb the case.
[09:32] <slaweq> tribaal: maybe we can propose to add such IPv6 address to the default list later
[09:33] <slaweq> but it's not required to make it working
[09:33] <tribaal> slaweq: if the ipv6 option becomes an openstack standard perhaps you could consider adding it to the default URLs (making it a list). But some guidance from the real cloud-init developers would be better than mine here :)
[09:33] <tribaal> yes, it looks like.
[09:33] <slaweq> tribaal: ok, thx a lot for help
[09:33] <tribaal> from my uneducated perspective at least :)
[09:33] <tribaal> slaweq: anytime :)
[09:33] <slaweq> I will send email to the ML to get some more feedback about that but You helped me a lot with that
[09:34] <tribaal> good to hear!
[12:46] <otubo> meena: I saw you left a comment on the pull request https://github.com/canonical/cloud-init/pull/204
[12:46] <otubo> Odd_Bloke: ^
[12:46] <otubo> I also saw a comment about considering the CVE-2020-8631.
[12:47] <otubo> meena: Odd_Bloke I'm just a little confused if this PR actually addressed the CVE or not, because it still uses random.choice
[13:06] <Odd_Bloke> otubo: It doesn't use random.choice, it uses random.SystemRandom.choice.
[13:06] <Odd_Bloke> Which uses the system's random pool instead of the pseudorandom Mersenne Twister that random.choice uses.
[13:07] <otubo> Odd_Bloke: I noticed that. And that was the reason I was confused if it was really fixed or not :) Now it's clear. Thanks!
[13:07] <Odd_Bloke> :)
[13:42] <Odd_Bloke> rharper: blackboxsw: https://github.com/canonical/cloud-init/pull/244/ <-- this adds the capability to store just GitHub usernames as CLA signers (and adds dhensby as the first such person)
[14:24] <Odd_Bloke> rharper: Thanks for the review, I've addressed your comment. :)
[14:24] <rharper> cool, I'll re-review
[14:25] <Odd_Bloke> Thanks!
[14:26] <Odd_Bloke> (I happened to look at the tab as your review showed up, I wasn't just sitting there waiting for a review to come in. ;)
[14:26] <rharper> hehe
[17:38] <AnhVoMSFT> checking out master and running tox gives me error tox.ConfigError: ConfigError: No support for the posargs substitution type
[17:42] <powersj> AnhVoMSFT, can you paste the full output? and `tox --version` and `python -V`
[17:42] <powersj> err python3 -V :D
[17:49] <AnhVoMSFT> tox --version
[17:49] <AnhVoMSFT> 2.3.1 imported from /usr/lib/python3/dist-packages/tox/__init__.py
[17:49] <AnhVoMSFT> python3 -V
[17:49] <AnhVoMSFT> Python 3.5.2
[17:50] <powersj> that looks like Ubuntu 16.04?
[17:50] <powersj> xenial?
[17:52] <AnhVoMSFT> yes powersj
[18:02] <powersj> Odd_Bloke, ^ possible regression from yesterday? If I checkout master without yesterday's commits all is well
[18:02] <AnhVoMSFT> powersj full output https://paste.ubuntu.com/p/b4ncHRJhxc/
[18:03] <AnhVoMSFT> (sorry for the delay, multitasking)
[18:03] <Odd_Bloke> Oh, hmm.
[18:03] <Odd_Bloke> Let me take a look.
[18:05] <Odd_Bloke> Yeah, OK, looks like it was introduced by my pytest branch.
[18:06] <Odd_Bloke> AnhVoMSFT: A short-term workaround is to install tox from PyPI into a virtualenv.  That tox version should be fine.
[18:06] <Odd_Bloke> In the meantime, I'll dig into fixing it properly.
[18:14] <Odd_Bloke> blackboxsw: rharper: https://github.com/canonical/cloud-init/pull/245 <-- this fixes running tox on xenial
[18:15]  * blackboxsw tries to reproduce that problem in the first place
[18:19] <blackboxsw> approved Odd_Bloke just waiting on CI
[18:19] <blackboxsw> .... again
[18:20] <powersj> Odd_Bloke, thanks!
[18:27] <rharper> blackboxsw: https://bugs.launchpad.net/cloud-init/+bug/1867029  ; didn't we look at an issue like this?  IIRC, the bionic ifupdown package does not include the source /etc/network/interfaces.d/*.cfg line in /etc/network/interfaces, right ?
[18:27] <Odd_Bloke> Landed.
[18:27] <Odd_Bloke> AnhVoMSFT: master should now be back to working, thanks for letting us know it was broken!
[18:28] <Odd_Bloke> blackboxsw: Looking at timestamps, we weren't waiting for Travis on that one, just on our actual CI jobs.
[18:29] <blackboxsw> rharper: checking
[18:29] <Odd_Bloke> Our worst queue times are likely in the mornings, because I think most of the multipass team are in Europe. :p
[18:30] <blackboxsw> rharper: we did have an issue just like this (iternally) someone was installing ubuntu-desktop on cloud-images which pulled in ifupdown
[18:30] <rharper> yes
[18:30] <rharper> and on bionic the package does not include the source line
[18:30] <rharper> so we render eni
[18:30] <rharper> but nothing sources it
[18:31] <blackboxsw> right, presence of ifupdown on bionic is non-standard/recommended and cloud-init checks ifupdown first, but stock cloud images have ifupdown includes disabled
[18:31] <blackboxsw> because we should be using netplan
[18:31] <blackboxsw> right
[18:32] <blackboxsw> still feels a bit like it should be a bug in ifupdown package for bionic. if installing it, it should probably emit the proper include, or cloud-init can emit a warning saying "hey there I see ifupdown and will be rendering that but I see no includes for the interfaces.d file I'm about to write, so I'm going to include it kthxbye"
[18:33] <blackboxsw> I think it's probably worth considering it as a cloud-init bug, because we should be smart enough to look at the environment config files for the rendering we are emitting to make sure it is valid
[18:33] <blackboxsw> what do you think?
[18:34] <blackboxsw> and it seems like a low hanging fruit kind of bug too
[18:34] <blackboxsw> if we handle it that way in net renderer.
[18:35] <Odd_Bloke> I would like to see a clearer description of the problem; what is the gap when ifupdown is installed on bionic?
[18:38] <blackboxsw> when ifupdown and netplan are both installed cloudinit network renders prioritize writing /etc/network/interfaces.d/*.cfg instead of /etc/netplan/50-cloud-init.yaml
[18:38] <blackboxsw> problem on certified cloud-images is that the magic /etc/network/interfaces config file is in a disabled state
[18:39] <blackboxsw> http://paste.ubuntu.com/p/9yhHVZjqGB/
[18:39] <rharper> blackboxsw: yes
[18:39] <rharper> I updated the bug
[18:39] <Odd_Bloke> Right.  This feels like it could be an ifupdown bug, we should pursue that route first, I think.
[18:39] <blackboxsw> and ifupdown package doesn't actually write or update that file if it already exists in images
[18:39] <rharper> the workaround is to just put the source line in there;  we need to sort out if ifupdown packaging or cloud-init (or both) should ensure that's present
[18:39] <Odd_Bloke> Because that comment is currently a lie, I think. :p
[18:40] <rharper> blackboxsw: even if it were missing, it doesn't put the right source line IIRC
[18:40] <blackboxsw> yeah I think ifupdown package postinst script should be a bit smarter instead of just a presence check (because we know cpc images intentially disable that file with comments etc)_
[18:40] <blackboxsw> rharper: if /etc/network/interfaces file is missing  it writes the appropriate include
[18:41] <blackboxsw> "it" being ifupdown deb postinst script
[18:41] <blackboxsw> yeah and that comment is a lie, because just installing ifupdown leaves the same /etc/network/interfaces file in place (disabled)
[18:42] <blackboxsw> just tested that
[18:42] <blackboxsw> same ENI content
[18:42] <rharper> blackboxsw: it's functional, but ISTR some subtly between source-directory and source *.cfg
[18:42] <rharper> I forget what at the moment
[18:42] <rharper> I think there's a built-in regex that ifupdown uses
[18:43] <rharper> with source_directory vs. source *.cfg
[18:43] <blackboxsw> and on bionic the ifupdown.postinst which source-directories the right dir http://paste.ubuntu.com/p/TKtfmN7Zyt/
[18:43] <rharper> I think I saw a debian bug related to this since their images used source_directory
[18:43] <rharper> blackboxsw: yes, it's the correct directory
[18:43] <rharper> but it restricts what files it reads within it
[18:43] <rharper> cloud-init's cfg is read
[18:43] <rharper> but there are subtle regex differences for what files are named
[18:43] <rharper> and what ifupdown actually reads
[18:44] <rharper> so, ubuntu cloud-image with ifupdown and source *.cfg will not always see the same files as an image with source_directory
[18:44] <blackboxsw> rharper: are you saying the "source-directory /etc/network/interfaces.d   is more strict than "source /etc/network/interfaces.d/*.cfg"   ?
[18:44] <rharper> possibly the opposite
[18:44] <blackboxsw> ahh less strict
[18:44] <rharper> but I need to find the bug
[18:46] <rharper> https://github.com/canonical/cloud-init/commit/a6faf3acef02bd8cd4d46ac9efeebf24b3f21d81
[18:46] <rharper> The current filename, 50-cloud-init.cfg, does not match against the RE
[18:46] <rharper> that is used to scan the directory for configurations (ASCII upper- and
[18:46] <rharper> lower-case letters, ASCII digits, ASCII underscores, and ASCII
[18:46] <rharper> minus-hyphens):
[18:47] <blackboxsw> ahh interesting. ok
[18:48] <Saviq> Odd_Bloke: just hired someone in Argentina ;)
[18:48] <blackboxsw> so do we want cloud-init behavior to prescribe that anyone wanting network config in ENI need have *.cfg files?
[18:48] <rharper> blackboxsw: well, the distro class has a say in it
[18:48] <Saviq> Also, one of our devs is in Tennessee, so… ;P
[18:49] <blackboxsw> Saviq: so annual meetings in Columbia to split the difference?
[18:50] <blackboxsw> so TN and Agentina have to travel the same distance :)
[18:50] <Saviq> With how things are going, no f2f meetings for a year ;P
[18:50] <blackboxsw> true story
[18:53] <Odd_Bloke> Saviq: Please go to bed (and stop kicking off CI runs). ;)
[19:03] <Odd_Bloke> I'm looking at the daily build failures next.
[19:03] <Odd_Bloke> (I believe it should just be a case of updating the Build-Depends in each packaging branch.)
[19:18] <rharper> Odd_Bloke: awesome!
[19:23] <Odd_Bloke> Hmm, actually, this is a little more complicated than that.  If I update the Build-Depends without pulling in the upstream commit, then builds will fail when we just cherry-pick changes (because nose won't be installed).
[19:24] <Odd_Bloke> s/the upstream commit/\0 that introduced pytest/
[19:29] <blackboxsw> rharper: https://github.com/canonical/cloud-init/pull/114 is up for re-review (ec2 secondary ips). one question I have is how do we want cloud-init
[19:30] <blackboxsw> finally got my unittests fixes. FWIW assertItemsEqual for dict type items instead of assertEqual because python dict key ordering is different on xenial version on python as opposed to > xenial
[19:30] <blackboxsw> I keep forgetting that
[19:31] <rharper> blackboxsw: yeah,I saw that change in your tests; that was new to me w.r.t having a non-ordered content comparision
[19:32] <blackboxsw> yeah it bit us on landscape tests all the time, and sometimes I've seen it in cloud-init too
[19:32] <blackboxsw> most of the time i remember when writing the test... ahh well
[19:32] <tribaal> I get bit by that all the time :)
[19:32] <blackboxsw> silly former landscapers :)
[19:33] <tribaal> hehe you'd think we learned byt the time :)
[19:33] <blackboxsw> hah
[19:33] <rharper> tribaal: btw, thanks for point slaweq to the mailing list and the datasource bits; much appreciated
[19:33] <tribaal> anytime :)
[19:35] <tribaal> seems like a pretty straightforward patch to write (to me), but the multicast point brought up on the list as a followup is an interesting approach
[19:36] <Odd_Bloke> assertEqual should work on dicts.
[19:36] <rharper> yeah, and I'm worried about the cost of either hitting ipv4 when there is no, or ipv6 when there is none
[19:36] <tribaal> even though I'm not directly involved with an openstack cloud anymore, I could see the multicast thing transfer well to other clouds as well, indeed
[19:36] <rharper> tribaal: I
[19:36] <tribaal> you?
[19:36] <tribaal> :)
[19:37] <rharper> hehe, I've not responded to that yet; the idea of having a common "IMDS" url is interesting, but I'm not sure it makes anything more common other than the location;  the content is still per-platform;
[19:37] <tribaal> Yeah, that's true
[19:51] <Odd_Bloke> blackboxsw: Just added a comment about assertItemsEqual; you're actually papering over a _list_ being out-of-order, this isn't to do with dict key ordering.
[19:52] <Odd_Bloke> (Unless, I suppose, that list is being generated from dict keys.)
[19:52] <blackboxsw> Odd_Bloke: ahh right, so we could/should sort that list to avoid thrashing on different versions of python
[19:52] <blackboxsw> right the source comes ultimately from keys
[19:52] <blackboxsw> we can sort it in code proper or assertItemsEqual
[19:53] <blackboxsw> I'd prefer to handle in unit tests because we don't truly need to do the sorting work for what cloud-init renders
[19:53] <Odd_Bloke> I think better to have the code produce something that's stable across Python versions.
[19:53] <blackboxsw> but I can be swayed either way
[19:53] <blackboxsw> rharper: I need a swing vote on that :)
[19:53] <Odd_Bloke> Well, I give an example where the order does make a difference.
[19:53] <blackboxsw> surely
[19:54] <Odd_Bloke> I don't know if it makes a _practical_ difference, but there would be different internal state at least.
[19:54] <rharper> is the a *value* list or  the order of the keys() output ?
[19:55] <rharper> we end up running json.dumps, with sort_keys=True, so what we write out is in sorted *key* order, but the value indexed by the key is not sorted AFAICT in our code;
[19:55] <rharper> at some unittime cost; it may be better to dump the output via util.json_dumps() and read it back and compare
[19:56] <blackboxsw> rharper: the list value comes out sorted differently from macs_to_nics.items()
[19:56] <rharper> the value, right
[19:56] <blackboxsw> so the value of the 'addresses' sorts differently on xenial
[19:56] <blackboxsw> based on what mac we originally process from IMDS
[19:57] <blackboxsw> I can make the change to sort the macs_to_nics dict. and then we should not have this problem.
[19:57] <blackboxsw> easy enough. and minor cpu cost\
[19:57] <rharper> that seems better and then assertEqual should work as well, IIUC
[19:58] <blackboxsw> right then assertEqual will work
[19:58] <blackboxsw> and we may have need for ordered internal state in the future anyway.
[19:58] <rharper> blackboxsw: thoughts on whether we can generically walk the dict, and on value types apply sorted ?
[19:58] <rharper> that is, if we add new keys in the future, how do we prevent having more unsorted lists
[20:15] <Odd_Bloke> blackboxsw: rharper: What do you think to this approach: https://github.com/canonical/cloud-init/pull/246
[20:15] <rharper> looking
[20:15] <Odd_Bloke> It means our daily builds will needlessly install python3-nose and our archive builds will needlessly install python3-pytest.
[20:16] <Odd_Bloke> The alternative would be to cherry-pick the pytest commit onto each release branch, so that we can consistently just test with pytest.
[20:16] <rharper> hrm
[20:16] <Odd_Bloke> (And all of this inconsistency will go away in the next SRU regardless.)
[20:17] <rharper> leading with that last comment there; I;m in favor of some short term "needless" package installs to avoid git cherry pick on each release branch pain
[20:17] <blackboxsw> Odd_Bloke: I think we ultimately have to cherry-pick into each ubuntu/<series> anyway right
[20:17] <rharper> blackboxsw: on sru, we new-upstream-snapshot *and* update build deps
[20:17] <rharper> so, no ?
[20:17] <blackboxsw> our new-upstream-snapshot doesn't pull int debian/* file changes
[20:18] <blackboxsw> rharper: ahh I see, right deps should get corrected via new-upstream-snapshot
[20:18] <blackboxsw> ok
[20:18] <rharper> right, but issue is that tools/read-deps picks up the new change, but debian/ is stale
[20:18] <Odd_Bloke> The deps won't be corrected by new-upstream-snapshot.
[20:18] <blackboxsw> just ubuntu/xenial/debian doesn't see updates from ubuntu/devel/debian due to new-upstream-snapshot
[20:18] <Saviq> Odd_Bloke: btw, are we actually causing you guys delays? this is Travis, I assume? is it b/c we're under the same canonical/ GH org?
[20:19] <Odd_Bloke> We will need to manually drop the python3-nose Build-Depends once it is actually unused.
[20:19] <Odd_Bloke> Saviq: Yeah, we've had the canonical org put onto a paid Travis plan so that will hopefully help.
[20:19] <rharper> Odd_Bloke: right, we move release branch to master; *and* update debian Build-Deps
[20:20] <Odd_Bloke> Saviq: Part of the problem is that we aren't (yet) using a landing bot like bors, so we really notice delays.
[20:20] <blackboxsw> ok Odd_Bloke is it worth an SRU_BLOCKER comment added to ubuntu/(xenial|bionic|eoan)/debian/control   or a trello card on our SRU template board?
[20:20] <Odd_Bloke> blackboxsw: This isn't a blocker for SRUs IMO.
[20:20] <blackboxsw> I guess what I'm wondering is how we avoid losing that work item
[20:21] <Saviq> Odd_Bloke: ah so that's why travis-ci.com got enabled on the org ;)
[20:21] <rharper> blackboxsw: I was just thinking we might want to to release branch merging in our CI builds; so we could have see this fail in CI if we merged release branch debian on top of the PR branch ,
[20:22] <Odd_Bloke> blackboxsw: Perhaps on the SRU template board?
[20:22] <Odd_Bloke> (If we do drop it it's not the end of the world, we'll just be installing nose in our build environments unnecessarily.)
[20:22] <Odd_Bloke> s/drop it/forget to make the change/
[20:23] <Odd_Bloke> rharper: Chad is +1 on the PR, I take it from your above comments that you are too?
[20:23] <rharper> yes, I'll mark approve as well
[20:27] <Odd_Bloke> OK, I'm going to make sure that focal now builds, then will propose a similar change for each other release.
[20:27] <Odd_Bloke> Saviq: Yep, that's why. :)
[20:31] <Saviq> I suppose that was inevitable, and makes sense anyway…
[20:44] <blackboxsw> ok, Im reviewing Goner's netbsd(*bsd) support PR https://github.com/canonical/cloud-init/pull/62 and the network config emitted from the distro is v1 in both cases. I'm thinking since we are touching/reviewing that support, maybe we should make that generate_fallback config could be simple v2 https://github.com/canonical/cloud-init/pull/62/files#diff-1708fc6fbf7cc4ca958a7adab7ad615eR35-R40
[20:45] <blackboxsw> rharper: Odd_Bloke any opinions on generally whether we should be moving distro network rendering to v2 or leave them all v1?
[20:45] <rharper> blackboxsw: do you mean datasource ?
[20:45] <blackboxsw> I knew datasource-wise  we'd like to make that migration to v2 in the datasource
[20:45] <blackboxsw> rharper: I do mean distro in some cases constuct v1 network config for fallback
[20:46] <blackboxsw> we could move them to v2 as they are being touched like the link above
[20:46] <blackboxsw> so that eventually we can move our internal state off of v1
[20:46] <blackboxsw> and drop our network config v1 -> v2 translation layer logic
[20:47] <rharper> what generates v1 in distro ?
[20:47] <blackboxsw> distro.generate_fallback_config is the method I'm talking about
[20:47] <rharper> just bsd no ?
[20:47] <Goneri> could this be done in a 2nd iteration. I understand the idea, but I would like to land the PR too :-)
[20:47] <rharper> it calls net.generate_fallback_config()
[20:47] <blackboxsw> well our base Distro class does
[20:47] <rharper> which emits v2
[20:47] <rharper> blackboxsw: huh ?
[20:47] <blackboxsw> right rharper in the existing PR, it did v1.
[20:47] <rharper>    def generate_fallback_config(self):
[20:47] <rharper>         return net.generate_fallback_config()
[20:47] <blackboxsw> for netbsd only. and I wanted to steer that to v2
[20:47] <blackboxsw> rharper: https://github.com/canonical/cloud-init/pull/62/files#diff-1708fc6fbf7cc4ca958a7adab7ad615eR35-R40
[20:48] <blackboxsw> I want that v2
[20:48] <blackboxsw> Goneri: it could be done on a followup
[20:48] <rharper> blackboxsw: I suppose, I'm not too worried about it;  the biggest win to moving to v2 in fallback is that if target distro supports v2, then we can pass it through as it is
[20:49] <rharper> it's unlikely that v2 will ever be around on bsd, so it's not, IMO, a big issue to emit v1 to convert to network_state()
[20:49] <blackboxsw> right, which isn't going to happen on *bsd. so its probably more paper work to move to v2
[20:49] <blackboxsw> right
[20:49] <blackboxsw> ok makes sense, thanks for being the sounding board. Goneri we won't worry about that then
[21:01] <Odd_Bloke> https://github.com/canonical/cloud-init/pull/247 <-- eoan
[21:15] <Odd_Bloke> https://github.com/canonical/cloud-init/pull/248 <-- bionic
[21:25] <Odd_Bloke> https://github.com/canonical/cloud-init/pull/249 <-- xenial
[21:25] <Odd_Bloke> blackboxsw: rharper: Review of ^ would be appreciated!
[21:25] <rharper> ok
[21:26] <blackboxsw> 247 merged
[21:26] <blackboxsw> rharper: you on 248 or 249?
[21:27] <blackboxsw> I object to https://github.com/canonical/cloud-init/pull/248/files formatting as cloud-init attribution in previous changelog entries generally carries a different 'style'
[21:29] <rharper> blackboxsw: neither as you hopped on one already; was thinking it was easier to review all of them together for comparision purposes
[21:29] <blackboxsw> rharper: +1 though Id like you and Odd_Bloke weigh in on 248
[21:29] <blackboxsw> specifically my unrealistic https://github.com/canonical/cloud-init/pull/248#discussion_r391278819
[21:29] <blackboxsw> or pedantic
[21:30] <blackboxsw> it just represents something 'different' and I get all prickly with change ;)
[21:31] <blackboxsw> same nit/request w.r.t https://github.com/canonical/cloud-init/pull/249/files
[21:31] <blackboxsw> I think generally we redacted authorship attribution in debian/changelogs for the upstream team. in ubuntu deb changelog entries, but should that be different w.r.t. specific packaging changes to the debian/* directory
[21:33] <rharper> blackboxsw: generally I think it might be useful to keep authorship for the debian dir change sinces that's downstream changes rather than upstream code ; but I'm fine redacting as well;
[21:33] <blackboxsw> ok /me backs down
[21:33] <blackboxsw> works for me
[21:34] <blackboxsw> though when new-upstream-snapshot combines these items I wonder if it's worth us redacting that to make the changelog a bit more readable
[21:34] <blackboxsw> since it's likely to include a lot of fixes
[21:34] <blackboxsw> redacting the authorship sections
[21:38] <blackboxsw> heh I see Odd_Bloke redacted :) thanks man
[21:39] <blackboxsw> I mean thanks Dan
[21:39] <Odd_Bloke> Done for both.
[21:40] <blackboxsw> approved waiting on ci
[21:41] <Odd_Bloke> FWIW, those names are categorically different from the "New upstream snapshot" lines where we redact the names, and are a standard feature of Debian changelogs.
[21:42] <blackboxsw> though Odd_Bloke do you think that not bumping debian/changelog version will actually not allow our builds to succeed
[21:42] <blackboxsw> https://github.com/canonical/cloud-init/pull/249 and https://github.com/canonical/cloud-init/pull/248
[21:42] <Odd_Bloke> Why?
[21:42] <blackboxsw> I think we actually need a new dch -i right?
[21:42] <blackboxsw> ohh wait recipe builds failed
[21:43] <blackboxsw> so there isn't a build of that binary already in repos
[21:43] <Odd_Bloke> That version isn't really used anyway, the recipe build produces its own I think?
[21:43] <Odd_Bloke> I think the changelog is only used for proper uploads, and we haven't released these versions yet.
[21:43] <blackboxsw> Odd_Bloke: I was thinking only in terms of daily repos
[21:43] <blackboxsw> daily ppa
[21:44] <blackboxsw> which should already have a successful build pre-pytest
[21:44] <blackboxsw> maybe??
[21:44] <Odd_Bloke> The recipe builds don't use that version string.
[21:44] <Odd_Bloke> They look like  20.1-2346-g65a1b90-0ubuntu1+1792~trunk~ubuntu20.04.1
[21:46] <blackboxsw> ahh right it's based on something else ahh right  https://launchpad.net/~cloud-init-dev/+archive/ubuntu/daily
[21:46] <blackboxsw> ok safe!
[21:46] <blackboxsw> thanks for that
[21:46] <blackboxsw> which makes sense as we might fix a ubuntu/<release> branch with more commits and not alter the debian/changelog so we'd need a different unique counter
[21:47] <blackboxsw> to allow unreleased uploads to get tested.
[21:47] <blackboxsw> ok I'm back on waiting for CI again :)
[21:47] <blackboxsw> actually on a netbsd review
[21:49] <Odd_Bloke> blackboxsw: I'm watching CI for those packaging branches, you can focus on something else. :)
[22:03] <Odd_Bloke> OK, all daily builds are now back to working. \o/
[22:25] <powersj> rharper, https://github.com/canonical/cloud-init/pull/238 is that ready?
[23:16] <blackboxsw> powersj: I think I need a 2nd pass there.
[23:16] <blackboxsw> my irc bouncer died again
[23:16] <blackboxsw> will be making the switch to thelounge.chat tonight
[23:25] <rharper> powersj: I would like to have some runtime verification on it before landing