=== cpaelzer_ is now known as cpaelzer | ||
cpaelzer | smoser: blackboxsw: yeah we had no extra chrony love pre Bionic | 04:51 |
---|---|---|
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? | 04:52 |
=== shardy is now known as shardy_lunch | ||
=== ivve_ is now known as ivve | ||
=== shardy_lunch is now known as shardy | ||
=== caribou_ is now known as caribo | ||
=== caribo is now known as caribou | ||
=== r-daneel_ is now known as r-daneel | ||
=== r-daneel_ is now known as r-daneel | ||
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? | 15:47 |
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:05 |
mgerdts | Is smoser one of those that's out? | 16:06 |
dpb1 | mgerdts: yes | 16:19 |
dpb1 | mgerdts: and blackboxsw :) | 16:19 |
dpb1 | holiday season unfortunately | 16:19 |
mgerdts | Are they out all week? | 16:19 |
dpb1 | scotts back on wednesday, blackboxsw later today | 16:20 |
mgerdts | ok, thanks | 16:20 |
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:15 |
rharper | ffledgling: do you have a paste of your cloud-config/user-data and the cloud-init.log available ? | 17:19 |
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:20 |
ffledgling | rharper: log - https://paste.fedoraproject.org/paste/ez66J-WWe6NeZkh5mTASUg | 17:21 |
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:26 |
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:27 |
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:28 |
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 |
ubot5 | bugzilla.redhat.com bug 1473890 in cloud-init "cloud-init sysconfig renderer does not render DNS or GATEWAY" [High,Closed: eol] | 17:29 |
rharper | /etc/sysconfig/network-scripts/ifcfg-eth | 17:29 |
rharper | that's fixed, you can try cloud-init from copr repos | 17:29 |
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:30 |
ubot5 | Ubuntu bug 1765801 in cloud-init "network should be optionally reconfigured on every boot" [Undecided,Confirmed] | 17:30 |
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:31 |
ffledgling | rharper: how do I try a newer version of cloud-init with an existing image? If that's possible at all? | 17:32 |
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:33 |
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:34 |
rharper | you may find that 17.1 has this bug in it: https://bugs.launchpad.net/cloud-init/+bug/1712680 | 17:35 |
ubot5 | Ubuntu bug 1712680 in maas-images "cloud-init re-generates network config every reboot overwriting manual admin changes on CentOS." [Undecided,New] | 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:35 |
rharper | oh sure, I mean, if you make a local change, you may still see this issue | 17:36 |
ffledgling | ah, good to know | 17:36 |
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:14 |
rharper | there are some folks from the project in here | 18:15 |
ffledgling | would you know who? | 18:15 |
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:16 |
rharper | larsks: where would ffledgling file a request to get the fedora cloud images with an updated cloud-init | 18:17 |
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:18 |
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:19 |
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:20 |
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:22 |
ffledgling | larsks: https://bugzilla.redhat.com/show_bug.cgi?id=1589972 | 18:46 |
ubot5 | bugzilla.redhat.com bug 1589972 in cloud-init "cloud-init + nocloud ignores DNS configuration" [Unspecified,New] | 18:46 |
ffledgling | Let me know if there's more detail needed there | 18:46 |
larsks | ffledgling: thanks, looks good. | 18:48 |
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:53 |
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) | 19:54 |
rharper | blackboxsw: ok | 20:02 |
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:03 |
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:04 |
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:10 |
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:33 |
blackboxsw | ok just unit test coverage exhibiting the uncode problem | 20:34 |
rharper | nice | 20:34 |
blackboxsw | unicode rather | 20:34 |
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:38 |
blackboxsw | well on artful inside containers only | 20:41 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!