[04:51] <cpaelzer> smoser: blackboxsw: yeah we had no extra chrony love pre Bionic
[04:52] <cpaelzer> and getting them to work in container was due to that >=Bionic as well
[04:52] <cpaelzer> but reading the backlog you found all that
[04:52] <cpaelzer> anything left open with it?
[15:47] <mgerdts> blackboxsw the notes say that the last bi-weekly meeting was 13 days ago.  The topic says the next meeting is in 7 days.  Are we rounding up due to a holiday a couple weeks back?
[16:05] <rharper> mgerdts: likely, a few folks on the team are out today, so we figured we'd need a bit more time to have additional work land before the next meeting
[16:06] <mgerdts> Is smoser one of those that's out?
[16:19] <dpb1> mgerdts: yes
[16:19] <dpb1> mgerdts: and blackboxsw :)
[16:19] <dpb1> holiday season unfortunately
[16:19] <mgerdts> Are they out all week?
[16:20] <dpb1> scotts back on wednesday, blackboxsw later today
[16:20] <mgerdts> ok, thanks
[17:15] <ffledgling> Hello, running into some trouble w/ configuring dns for an image that uses cloud-init. Cloud init doesn't seem to pick up changes from either network-config nor from user-data's resolv module
[17:15] <ffledgling> Is this functionality broken? (Using a nocloud provider with a fedora 28 image, cloud-init v17.1)
[17:19] <rharper> ffledgling: do you have a paste of your cloud-config/user-data and the cloud-init.log available ?
[17:20] <ffledgling> rharper: I can give you the former, where can I find the cloud-init.log?
[17:20] <rharper>  /var/log/cloud-init.log
[17:21] <ffledgling> rharper: log - https://paste.fedoraproject.org/paste/ez66J-WWe6NeZkh5mTASUg
[17:26] <ffledgling> rharper: configs - https://paste.fedoraproject.org/paste/6y2H38~zsLG0PyZ4JMPkOw
[17:26] <rharper> ffledgling:  it looks like the cc_resolve_conf module is not enabled by default,  in /etc/cloud/cloud.cfg , under cloud_config_modules: list, upstream doesn't have a  - resolve_conf  in the list;  I suspect that's why the user-data module isn't called
[17:27] <ffledgling> rharper: I see, but then it's not picked up from network-config either
[17:27] <rharper> where is your network-config stored?
[17:27] <rharper> what datasource are you using, generally one cannot provide network-config via user-data ; it has to be part of the data-source (or in the cloud config on disk)
[17:28] <ffledgling> it's all in an iso mounted into the VM; source is nocloud
[17:28] <rharper> things like NoCloud can use it, or ConfgDrive
[17:28] <rharper> ah, perfect, lemme look at the log then
[17:28] <ffledgling> The other stuff in the config like ip, gateway are picked up fwiw, so it's just the DNS that's causing trouble
[17:29] <ffledgling> This seemed to encapsulate the symptoms - https://bugzilla.redhat.com/show_bug.cgi?id=1473890 ; but I'm not sure if it's still a problem upstream
[17:29] <rharper>  /etc/sysconfig/network-scripts/ifcfg-eth
[17:29] <rharper> that's fixed, you can try cloud-init from copr repos
[17:30] <rharper> https://copr.fedorainfracloud.org/coprs/g/cloud-init/cloud-init-dev/
[17:30] <rharper> what's in your ifcfg-eth0 ?
[17:30] <rharper> do you see any DNS_ settings there?
[17:30] <ffledgling> https://paste.fedoraproject.org/paste/rlRkQVQ0GJ8lesH4Qp3hNg
[17:30] <mgerdts> The "pick up changes" part of your question makes me suspect  https://bugs.launchpad.net/cloud-init/+bug/1765801
[17:31] <rharper> that's not related directly to you query on dns entries being rendered in sysconfig in a NoCloud scenario
[17:31] <ffledgling> nope, I don't even generate the resolv.conf myself, not touching anything network directly, everything goes through cloud-init
[17:31] <ffledgling> It generates the file, but it's always empty
[17:32] <ffledgling> rharper: how do I try a newer version of cloud-init with an existing image? If that's possible at all?
[17:33] <rharper> yes
[17:33] <rharper> add the repo to the image, if you can get into it, then upgrade cloud-init, and then you can  rm -rf /var/log/cloud-init* /var/lib/cloud/{instance*, data}  ; and reboot
[17:34] <rharper> trunk renders your network-config like this in sysconfig: https://paste.ubuntu.com/p/g5k9j3XpqV/
[17:34] <rharper> that should fix your dns issue
[17:34] <ffledgling> let me try that
[17:35] <rharper> you may find that 17.1 has this bug in it:  https://bugs.launchpad.net/cloud-init/+bug/1712680
[17:35] <rharper> in which case, comment #11 is helpful ,for workarounds, https://bugs.launchpad.net/cloud-init/+bug/1712680/comments/11
[17:35] <ffledgling> Hm, don't think that's my issue - since I'm destroying and recreating the image from scratch every time, so this is after first boot
[17:36] <rharper> oh sure, I mean, if you make a local change, you may still see this issue
[17:36] <ffledgling> ah, good to know
[18:14] <ffledgling> rharper: so... I can confirm the newer version works
[18:14] <rharper> great!
[18:14] <ffledgling> Now the question is, how do I get this in the default image?
[18:14] <rharper> that's a fedora question
[18:15] <rharper> there are some folks from the project in here
[18:15] <ffledgling> would you know who?
[18:16] <rharper> ffledgling: larsks is with RH, may know a good connection
[18:16] <larsks> What do I know? I deny everything.
[18:16] <rharper> hehe
[18:17] <rharper> larsks: where would ffledgling file a request to get the fedora cloud images with an updated cloud-init
[18:18] <rharper> https://fedoraproject.org/wiki/Cloud_SIG looks like a place to start
[18:18] <larsks> You could file a bugzilla against Fedora...https://bugzilla.redhat.com/enter_bug.cgi?product=Fedora
[18:18] <rharper> mailing list died off in 2015 though
[18:19] <ffledgling> larsks: that, I was going to do, but there was already a bug for fedora 26 that seems to have died...
[18:19] <ffledgling> is that still the best way?
[18:19] <larsks> There has been some talk recently about rebasing the Fedora package on the latest cloud-init release.  The primary package maintainer I think is just busy.
[18:20] <larsks> Someone recently showed up volunteering to help with package maintenance, but I'm not sure where that stands right now.
[18:20] <larsks> I would say go ahead and open the bug, ping me with the url, and I am happy to prod some folks.
[18:22] <ffledgling> larsks: okay, thank you!
[18:22] <ffledgling> If the package update is not a major process then I can probably volunteer to get this one out as well, but I suspect that might not be how it works
[18:46] <ffledgling> larsks: https://bugzilla.redhat.com/show_bug.cgi?id=1589972
[18:46] <ffledgling> Let me know if there's more detail needed there
[18:48] <larsks> ffledgling: thanks, looks good.
[19:53] <blackboxsw> mgerdts: afternoon/evening. yeah I had a little break this morning. I tried sending out an email to cloud-init@lists.launchpad.net to notify folks about the shift. (and changed the IRC topic to reflect that as you saw).
[19:54] <blackboxsw> rharper: I'm taking over https://code.launchpad.net/~smoser/cloud-init/+git/cloud-init/+merge/347727 to get some unit tests over it (and to also fix the issues with unicde in custom-scripts too)
[20:02] <rharper> blackboxsw: ok
[20:03] <blackboxsw> rharper: btw, https://code.launchpad.net/~chad.smith/cloud-init/+git/cloud-init/+merge/347559 should be all done per review comments
[20:03] <rharper> k, reviewing
[20:04] <blackboxsw> avoided warnings unless device-level != subnet-level mtu value
[20:04] <blackboxsw> and added unit test coverage of that
[20:04] <rharper> ci says no
[20:04] <rharper> is that glitch or needs fix to land before it says yes ?
[20:10] <blackboxsw> bah, pycodestyle. pushing fix now:wq
[20:10] <blackboxsw> and apparently saving that message in irc too
[20:10] <blackboxsw> rharper: pushed. I had left a debug maxDiff = None in there that isn't required.
[20:33] <blackboxsw> looks like smoser's branch covers the string conversion of all mime types. ok, so we don't need separate changes for x-shellscript or cloud-boothook
[20:34] <blackboxsw> ok just unit test coverage exhibiting the uncode problem
[20:34] <rharper> nice
[20:34] <blackboxsw> unicode rather
[20:38] <blackboxsw> cpaelzer: way late on the response back to you. but nope, artful//chrony is not a supported thing. so nothing to worry about it. I just need to fix cloud-init's CI to avoid trying to test chrony deployment on artufl
[20:38] <blackboxsw> cpaelzer: way late on the response back to you. but nope, artful//chrony is not a supported thing. so nothing to worry about it. I just need to fix cloud-init's CI to avoid trying to test chrony deployment on artful
[20:41] <blackboxsw> well on artful inside containers only