| opendevreview | OpenStack Proposal Bot proposed openstack/project-config master: Normalize projects.yaml https://review.opendev.org/c/openstack/project-config/+/952006 | 02:20 |
|---|---|---|
| johnsom | FYI, our friends at Canonical already have a proposed fix: https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/2113797 | 03:46 |
| *** cloudnull8 is now known as cloudnull | 04:10 | |
| fungi | fast work! | 12:01 |
| fungi | infra-root: i replaced the content of https://wiki.openstack.org/wiki/InfraTeam with links to the opendev and tact sig pages, after noticing it was still listing resources as recent as the havana design summit | 13:53 |
| fungi | also should we go ahead and approve https://review.opendev.org/c/opendev/infra-manual/+/949924 and https://review.opendev.org/c/opendev/system-config/+/949939 to tidy up the main opendev.org page now? | 13:56 |
| frickler | I still have the latter up in my review list, I'll try to get to that today | 13:58 |
| fungi | heading out to an appointment shortly, should return in about 90 miutes | 14:25 |
| clarkb | fungi: no objections from me to update the opendev.org landing page | 14:43 |
| clarkb | also gitea 1.24.0 was released overnight. I don't think we need to be in a rush to update but I haven't looked at the release notes yet. I do haev a WIP change somewhere that was testing the first 1.24.0 rc version and that worked so hopefully its a straightforward update. In the past we've often waited for a .1 release which tends to come fairly quickly | 14:44 |
| fungi | sounds good, thanks clarkb!!! | 16:09 |
| opendevreview | Dan Smith proposed openstack/project-config master: Add dansmith as op for glance IRC channel https://review.opendev.org/c/openstack/project-config/+/952278 | 16:15 |
| opendevreview | Merged openstack/project-config master: Add dansmith as op for glance IRC channel https://review.opendev.org/c/openstack/project-config/+/952278 | 16:31 |
| clarkb | https://review.opendev.org/c/opendev/system-config/+/948560 this is the gitea 1.24.0-rc0 test change. I don't mind if someone else looks at updating that for 1.24.0 or I can try to look at doing that in a day or two | 17:35 |
| clarkb | looking at https://github.com/go-gitea/gitea/blob/v1.24.0/CHANGELOG.md I don't think this is an urgetn udpate though so thats probably fine | 17:36 |
| clarkb | tonyb: with the -minimal elements you have to make sure things like sshd and ntpd and glean etc are installed and configured to get a working image. This gives you a lot of control but also requires more effort | 19:56 |
| clarkb | tonyb: with the non -minimal elements you start from an upstream image then just make a few small edits to accomplish what you need with the image | 19:56 |
| tonyb | clarkb: I understand. I guess my confusion is around why we use ubunu-minimal by default but for CentOS we default away from the minimal build. I assume that's because CentOS/fedora/rhel are easier that way .... or were until now? | 19:59 |
| clarkb | tonyb: opendev uses -minimal for everything | 20:00 |
| fungi | i think we always want to use the -minimal elements if we can | 20:00 |
| clarkb | tonyb: but dibs internal testing attempts to test both | 20:00 |
| clarkb | this is a case where opendev would be fine with never adding that functionality but other dib users may not be so ideally we figure it out | 20:00 |
| tonyb | ahhhh got it! | 20:01 |
| tonyb | that's the bit I was missing | 20:02 |
| fungi | yeah, the audience dib serves is greater than opendev alone | 20:02 |
| fungi | so we (opendev sysadmins) don't care, but we (dib maintainers) do care | 20:03 |
| fungi | do many hats | 20:03 |
| fungi | s/do/so/ | 20:03 |
| tonyb | so many. | 20:03 |
| JayF | I had a downstream user who even (I think they don't anymore) used a modified internal image as a starting point. Thinking about it that's been the pattern at least at 2 places I've worked. | 20:04 |
| tonyb | I get a couple of bonus red hats for this particular discussion :p | 20:04 |
| clarkb | looking at https://uapi-group.org/specifications/specs/discoverable_partitions_specification/ I suspect another important piece to this puzzle is that root partition uuids are arch specific | 20:06 |
| clarkb | this way you can ship a single image that boots on multiple arches. /boot is efi code right? so is not arch specific? | 20:07 |
| clarkb | and /boot doesn't get arch specifics uuids. This way you can have a /boot/ and a / for arm64 and a / for x86_64 on the same image and in theory everything will boot correctly | 20:07 |
| tonyb | okay I'll digest that when I'm awake | 20:09 |
| fungi | yeah, the debian installer takes advantage of similar tricks to provide a bootable multi-arch cd image for x86, aarch64 and power | 20:09 |
| clarkb | this is definitely a complicated subject and the purpose of these labels it to enable proper booting and mounting of drives. It isn't to make editing images easier. However, I think in general properly labeling things to match their contents is desireable and then dib can piggy back off of that | 20:10 |
| clarkb | the spec says that /boot labeled partitions will be mounted at /boot autoamtically if there is no /etc/fstab overrride and the mounted / does not contain a /boot | 20:11 |
| clarkb | so upstream may say something like grub is configured to treat the /boot labeled partition as / setting that as teh rootfs in the kernel command line too. Then as long as that partition also contents a /boot we won't automatically mount /boot which is / over /boot | 20:12 |
| JayF | well, what many people call a /boot is often a /efi in discoverable partitions setup | 20:12 |
| clarkb | (thats a long way of saying the images probably function just fine due to technical details in parittion and grub setup) | 20:12 |
| JayF | at least that's my experience in practice using it | 20:12 |
| JayF | Plus, systemd's implementation will do something akin to autofs and only mount those when they are cd'ed into | 20:13 |
| clarkb | JayF: the spec differentiates and has rules for handling /boot and /efi when they both exist | 20:13 |
| JayF | clarkb: I just clicked your link and realized that until now I'd always been working off the draft :) https://www.freedesktop.org/wiki/Specifications/DiscoverablePartitionsSpec/ | 20:15 |
| JayF | it's nice to see they made it official and detailed enough to close the gaps | 20:15 |
| mnasiadka | clarkb/tonyb: Anything I can help with to move the CentOS 10 DIB thing forward? | 20:30 |
| clarkb | mnasiadka: we discussed it in the weekly opendev meeting a little bit ago which is where this conversation continued from. I think the next step is a glean release and sorting out the nodepoolless testing. Then we can move forward without figuring out the upstream image situation first | 20:31 |
| clarkb | maybe fungi is willing to push a glean release? | 20:31 |
| clarkb | mnasiadka: but at least this way we can get it like 90% done and then sort out building from upstream iamges as a separate followup task | 20:31 |
| clarkb | mnasiadka: the main blocker now is probably the nodepoolless testing which tonyb says has network connectivity issues to the booted VMs. | 20:31 |
| fungi | just a sec an i can release glean, sure | 20:32 |
| clarkb | tonyb: it just occurred to me that the network connectivity problem might be due to not having a floating IP? | 20:32 |
| mnasiadka | I can have a peek at the nodepoolless testing tomorrow if needed - I assume it's using devstack | 20:33 |
| clarkb | tonyb: I think in a default devstack deployment the private network that is created by neutron by default is not accessible from the default network namespace on the host test node. A simple workaround for that is to attach a floating ip to the node which is craeted on the host node in such a way that default routing tables just work to direct packets to the floating ip which | 20:33 |
| clarkb | forwards things to the host | 20:33 |
| clarkb | mnasiadka: yes it is using devstack and then driving the image build and boot without nodepool | 20:33 |
| mnasiadka | so floating ip would be required as we use it everywhere else | 20:34 |
| fungi | ftr, my efi partitions get mounted to /boot/efi for post-boot manageability, but my /boot is what holds the non-encrypted kernel and initramfs so that i can have my rootfs in a luks v2 encrypted volume. when grub gets support for luks v2 i'll dispense with the separate /boot partition and just have efi data plus grub outside the encrypted volume | 20:34 |
| fungi | `git log --oneline --no-merges 1.24.0..origin/master` says that there are only 3 unreleased commits for glean: https://paste.opendev.org/show/bUEgYJ46dhLHirSgf6ke/ | 20:38 |
| clarkb | yup and the first two drop support for old distro testing and the third adds cetnos 10 stream support | 20:38 |
| fungi | and the only one that might warrant a feature segment increment is "9bc9428 Add support for CentOS 10 keyfiles" | 20:38 |
| clarkb | ya I think we should do a 1.25.0 release just for that commit | 20:39 |
| fungi | that was my thinking as well | 20:39 |
| fungi | so planning to tag 9bc9428772e3c04d91d55cc3cfdb8aa316cc2617 (current origin/master) as 1.25.0 | 20:39 |
| fungi | infra-root: ^ objections? | 20:40 |
| clarkb | 9bc9428772e3c04d91d55cc3cfdb8aa316cc2617 and 1.25.0 both look correct to me | 20:40 |
| fungi | okay, i'll push hat | 20:43 |
| fungi | that | 20:43 |
| fungi | * [new tag] 1.25.0 -> 1.25.0 | 20:44 |
| clarkb | jobs have enqueued in teh release pipeline for openstack | 20:44 |
| fungi | yep | 20:45 |
| fungi | #status log Released glean | 20:46 |
| fungi | er | 20:46 |
| fungi | #status log Released glean 1.25.0 | 20:46 |
| fungi | https://pypi.org/project/glean/ has it now | 20:47 |
| opendevstatus | fungi: finished logging | 20:51 |
| opendevstatus | fungi: finished logging | 20:53 |
| clarkb | https://pypi.org/project/glean/#history it shows up here now too | 20:56 |
Generated by irclog2html.py 4.0.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!