| opendevreview | Ian Wienand proposed openstack/project-config master: Add opendev/infra-vhd-util-deb repository https://review.opendev.org/c/openstack/project-config/+/841054 | 00:59 |
|---|---|---|
| *** ysandeep|out is now known as ysandeep|rover | 04:58 | |
| dpawlik | gmann: pong ;) | 05:55 |
| *** soniya29 is now known as soniya29|ruck | 06:13 | |
| opendevreview | daniel.pawlik proposed openstack/ci-log-processing master: Handle exception: TOO_MANY_REQUESTS https://review.opendev.org/c/openstack/ci-log-processing/+/841068 | 06:56 |
| *** soniya29 is now known as soniya29|ruck | 06:58 | |
| opendevreview | daniel.pawlik proposed openstack/ci-log-processing master: Handle exception: TOO_MANY_REQUESTS https://review.opendev.org/c/openstack/ci-log-processing/+/841068 | 07:00 |
| *** soniya29 is now known as soniya29|ruck | 07:19 | |
| *** ysandeep|rover is now known as ysandeep|rover|lunch | 07:20 | |
| *** jpena|off is now known as jpena | 07:30 | |
| *** soniya29 is now known as soniya29|ruck | 07:38 | |
| tkajinam | hello. I've seen a few job failure caused by an issue with name resolution. does anybody have idea about this ? https://zuul.opendev.org/t/openstack/build/be7045d94cdd4c82898e787ed61c38b4/log/job-output.txt#2228-2232 | 07:43 |
| tkajinam | the same job passed previously in the same repo and I suspect something specific to some regions | 07:43 |
| tkajinam | sorry, not in the same repo but in a different repo | 07:43 |
| tkajinam | eg. https://zuul.opendev.org/t/openstack/build/4d33248b434448dfa0d551c215c0f4ff | 07:44 |
| *** soniya29|ruck is now known as soniya29|ruck|lunch | 07:57 | |
| *** soniya29|ruck|lunch is now known as soniya29|ruck | 08:23 | |
| *** ysandeep|rover|lunch is now known as ysandeep|rover | 08:23 | |
| *** rlandy|out is now known as rlandy | 10:24 | |
| *** dviroel_ is now known as dviroel\ | 11:14 | |
| *** dviroel\ is now known as dviroel | 11:14 | |
| fungi | tkajinam: i agree, it looks like some sort if name resolution problem from that node. resolv.conf seems to have a correct entry pointing to localhost, but unbound.log is empty in both the broken and working examples so i can't draw much of a conclusion from that, and i don't see anything relevant for it in syslog either | 11:49 |
| *** ysandeep|rover is now known as ysandeep|rover|break | 11:57 | |
| *** ysandeep|rover|break is now known as ysandeep|rover | 12:57 | |
| *** dasm|off is now known as dasm | 13:27 | |
| *** soniya29 is now known as soniya29|ruck | 14:06 | |
| *** soniya29|ruck is now known as soniya29|ruck|dinner | 14:54 | |
| dpawlik | ianw, fungi, clarkb: hey, is it possible to release new diskimage builder? | 15:06 |
| dpawlik | This patch https://review.opendev.org/c/openstack/diskimage-builder/+/840825 will be good to be included in official release | 15:06 |
| dpawlik | of course if it is possible | 15:06 |
| *** dviroel is now known as dviroel|lunch | 15:10 | |
| fungi | dpawlik: yeah, usually ianw tags dib releases, though i can if it's too urgent to wait for apac daylight hours. looks like that change and an adjustment to the containerfile testing are the only things which have merged since 3.20.0, so it could be a 3.20.1 patch release | 15:10 |
| dpawlik | fungi: if it wasn't a problem, I would like to ask you to release it... but if you are busy, it can wait :) | 15:13 |
| fungi | i have a meeting coming up momentarily, but can look at doing it after 16:30 utc | 15:14 |
| clarkb | I think 3.21.0 was planned | 15:14 |
| clarkb | but I need to pull the code and chck outstanding changes | 15:15 |
| dpawlik | so maybe let's wait for ianw | 15:15 |
| clarkb | yes 3.21.0 has already happened | 15:16 |
| fungi | er, 3.21.0 already happened; i meant 3.21.1 | 15:16 |
| clarkb | looking at https://review.opendev.org/c/openstack/diskimage-builder/+/840825 I don't think the change is bad, but I think users of the base images that tell cloud init to not genrate keys should speak upstream and have them correct that | 15:17 |
| clarkb | its bad for base images to have baked in keys beacuse then all the hosts havethe same key. Therefore they shouldn't ship with keys and toggle the option to generate at boot | 15:18 |
| dpawlik | clarkb: IIUC the key will be generate after first boot... | 15:20 |
| clarkb | dpawlik: yes the change above forces that to happen because your base image cloud-init config apparently does not do this. I'm saying that is likely a bug in your base image and you should consider talking to them about it | 15:21 |
| clarkb | its fine to workaroudn that in dib, but its always good to pushes fixes as far up as possible to fix things for as many people as possible | 15:21 |
| dpawlik | clarkb: now I get. Yeah, I agree. This one seems to be a workaround. Maybe Tengu report/ask other communities if they can fix that... | 15:24 |
| Tengu | oh, that terrible cloud-init addition blocking the actual sshd-keygen.service? | 15:28 |
| clarkb | well the commit says that some base images have a cloud init config that prevents generating new keys. That is a bug imo for most cloud init installations | 15:30 |
| clarkb | because baking host keys into an image is a bad idea. And if you don't bake keys in and don't generate them on startup ssh won't work | 15:30 |
| clarkb | the only place it makes sense is if you are intentionally disabling ssh | 15:30 |
| *** soniya29|ruck|dinner is now known as soniya29|ruck | 15:36 | |
| Tengu | clarkb: the issue surfaced in the rdo provided image. The cloud-init config was removing the existing keys, but the generation was disabled - probably because it was expecting the sshd-keygen.service to kick in. | 15:37 |
| Tengu | but starting with cloud-init-22, they actually disabled the sshd-keygen.service with a Condition... | 15:37 |
| Tengu | so it wasn't working anymore. | 15:37 |
| clarkb | right so that would be a bug in their image. We can fix it in dib thats fine. but rdo shoudl fix it too | 15:37 |
| Tengu | I've checked the officials CentOS images, and they were cleaned. | 15:38 |
| Tengu | sure. but at that time, we needed an actual fix. And ensuring within DIB things were correct wasn't a bad option. BUT... apparently the cloud-init element isn't used in tripleo X( | 15:38 |
| Tengu | which is "a bit annoying". | 15:38 |
| Tengu | not sure how rdo got that config in, if they just took a pretty old image and didn't update it for instance. | 15:39 |
| Tengu | hence https://review.opendev.org/c/openstack/tripleo-common/+/841067 | 15:39 |
| Tengu | (for the element addition - it needs proper testing) | 15:39 |
| *** ysandeep|rover is now known as ysandeep|out | 16:09 | |
| *** soniya29|ruck is now known as soniya29|out | 16:12 | |
| *** dviroel|lunch is now known as dviroel | 16:24 | |
| fungi | mmm, so just to confirm, tagging dib 3.21.1 won't immediately solve the problem for tripleo because that element isn't used? | 16:40 |
| clarkb | oh they may be relying on the base image's config and not mixing in the element? ya so maybe we just wait on ianw then? | 16:42 |
| *** jpena is now known as jpena|off | 17:17 | |
| *** dviroel is now known as dviroel|afk | 20:43 | |
| ianw | o/ sorry for delay ... reading | 21:13 |
| ianw | did we end up that tripleo doesn't use it anyway and a dib release won't help? | 21:16 |
| fungi | ianw: i think Tengu and dpawlik would need to confirm that for certain. seems like maybe they want to use it, in which case they'll need that eventually | 21:32 |
| ianw | i can just do a 3.21.1 release, doesn't seem we need to bump nodepool or anything then | 21:51 |
| fungi | i don't think so, no, since it doesn't seem likely to be a change which would affect most known nodepool users | 21:57 |
| *** rlandy is now known as rlandy|bbl | 22:13 | |
| opendevreview | Merged openstack/project-config master: Add opendev/infra-vhd-util-deb repository https://review.opendev.org/c/openstack/project-config/+/841054 | 22:14 |
| *** dasm is now known as dasm|off | 22:16 | |
| *** cloudnull8 is now known as cloudnull | 23:04 | |
| opendevreview | Ian Wienand proposed openstack/openstack-zuul-jobs master: [wip] add generic infra-deb package build role https://review.opendev.org/c/openstack/openstack-zuul-jobs/+/841177 | 23:44 |
| opendevreview | Ian Wienand proposed openstack/openstack-zuul-jobs master: [wip] add vhd-util job https://review.opendev.org/c/openstack/openstack-zuul-jobs/+/841178 | 23:58 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!