| opendevreview | Goutham Pacha Ravi proposed openstack/project-config master: Retire Monasca project https://review.opendev.org/c/openstack/project-config/+/957063 | 04:51 |
|---|---|---|
| opendevreview | Goutham Pacha Ravi proposed openstack/project-config master: Retire Monasca project https://review.opendev.org/c/openstack/project-config/+/957063 | 04:59 |
| opendevreview | Goutham Pacha Ravi proposed openstack/project-config master: Retire Monasca project https://review.opendev.org/c/openstack/project-config/+/957063 | 05:01 |
| mnasiadka | Is it just me - or creating a revert using Gerrit UI is broken now, even if I add signed-off-by header in the commit message? | 07:17 |
| mnasiadka | Hmm, worked after I did add a whitespace before the header and revert reason | 07:17 |
| mnasiadka | s/whitespace/newline/ | 07:18 |
| opendevreview | Simon Westphahl proposed zuul/zuul-jobs master: Add default for build diskimage image name https://review.opendev.org/c/zuul/zuul-jobs/+/956219 | 10:03 |
| fungi | mnasiadka: yes, that first line (or block of lines) is the subject of the commit, the last block of lines is the trailer, everything in between is the commit message body. those sections are separated by blank lines | 13:16 |
| fungi | correctly formatting commit messages is important, even just for readability, but especially when it comes to satisfying message parsers | 13:17 |
| mnasiadka | fungi: maybe the template should include Signed-off-by: <PUT YOUR NAME AND EMAIL HERE>? | 13:24 |
| mnasiadka | (for revert) | 13:24 |
| fungi | i don't know if it's configurable at all in gerrit, but if it is then we'd need a way to configure it independently per-project since only openstack repositories require signed-off-by | 13:26 |
| fungi | or at least not all projects hosted in opendev require it at any rate (some besides openstack also do, but not all) | 13:27 |
| Clark[m] | My personal opinion on that is if the Gerrit UI doesn't do the exact specific thing you want for revert/rebase/etc you really should be using git locally and pushing the result once confirmed to be the exact specific desired output | 13:33 |
| fungi | #status log Deleted the eavesdrop01.opendev.org server instance, which was replaced by eavesdrop02 last week | 13:33 |
| Clark[m] | The Gerrit UI tools are there for the simple case. Git on your local machine allows you to do whatever specific thing you want | 13:33 |
| opendevstatus | fungi: finished logging | 13:34 |
| fungi | infra-root: remember we also need to merge https://review.opendev.org/956832 to clean up the dns records for eavesdrop01 | 13:34 |
| fungi | #status log Deleted the refstack01.openstack.org server instance (serving the old refstack.openstack.org site) per https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack.org/thread/WNI4PE2TZ3G52C3U5FT2YNVRUAJB3CMO/ | 13:36 |
| fungi | i did make sure the snapshot for that one ^ is showing completed in rackspace first | 13:37 |
| opendevstatus | fungi: finished logging | 13:37 |
| fungi | so if we need to bring it back for some reason we still have the old rootfs | 13:37 |
| opendevreview | Merged opendev/zone-opendev.org master: Clean up old eavesdrop01 records https://review.opendev.org/c/opendev/zone-opendev.org/+/956832 | 14:53 |
| fungi | thanks! | 14:56 |
| fungi | frickler: are you okay un-wip'ing https://review.opendev.org/c/opendev/zuul-providers/+/956428 Revert "Disable openmetal provider" | 15:42 |
| fungi | yesterday was the end of the maintenance schedule | 15:42 |
| clarkb | for some reason I had it n my head that it was the 13th but you're right. Reading the email it was yesterday (the 11th) | 15:42 |
| frickler | fungi: can you check whether the mirror is running fine before we merge that? | 15:42 |
| fungi | already did | 15:43 |
| fungi | and i removed it from our emergency disable list too | 15:43 |
| frickler | ah, cool, fine to go then | 15:43 |
| fungi | thanks! | 15:44 |
| fungi | approved it just now | 15:46 |
| opendevreview | Merged opendev/zuul-providers master: Revert "Disable openmetal provider" https://review.opendev.org/c/opendev/zuul-providers/+/956428 | 15:46 |
| mnasiadka | Is it just me seeing occasional "Server Unavailable" from Gerrit UI for the last couple of months? | 16:58 |
| clarkb | mnasiadka: that happens to me when my local wifi connection bounces | 17:01 |
| mnasiadka | I don't think that's the case, everything else works, I see that also from office - so two independent locations | 17:02 |
| clarkb | I think gerrit notices because it checks for udpates to changes in the background and when that connection breaks it notices when other things would only notice if you ask for an explicit update | 17:02 |
| clarkb | but no other than ^ I haven't noticed anything new along those lines | 17:03 |
| fungi | i haven't seen it, but i mostly don't use the webui | 17:04 |
| fungi | i've deleted the refstack-related records out of openstack.org dns now too (a, aaaa, cname, and also two cnames for acme challenges) | 18:55 |
| clarkb | and we never had opendev.org records for that service so that should be all the dns | 18:56 |
| fungi | right | 19:01 |
| fungi | do our test node names still start with "np"? ovh just sent us an incident notice with a list of np... instances impacted | 20:59 |
| clarkb | fungi: yes its np and then a suffix. That suffix was a sequential id number from 0 to current boot in nodepool. With zuul launcher its a uuid of some sort so more random | 21:07 |
| fungi | okay, just making sure those weren't necessarily old leaked instances | 21:07 |
| corvus | yep. the "np" is so that we can guess that it's probably a nodepool instance | 21:19 |
| corvus | the suffix is the first N characters of the full node id | 21:19 |
| corvus | so np3062cf3cb3bd4 is node uuid 3062cf3cb3bd482c98b379491d8235e4 | 21:22 |
| corvus | you can just grep for 3062cf3cb3bd4 on the launchers and that's typically unique enough. that would get you the active timespan for when we owned it. | 21:22 |
| clarkb | corvus: does zuul support both ansible 8 and 9 now or just 9? | 21:40 |
| clarkb | I'm trying to get facts straight for this announcement email | 21:40 |
| clarkb | I think it is just ansible 9 within oepndev's deployment because we are deploying master | 21:40 |
| clarkb | that detail doesn't change things dramatically I'm going with the just 9 and 11 case (no 8) as I believe that to be correct | 21:45 |
| clarkb | https://lists.opendev.org/archives/list/service-announce@lists.opendev.org/thread/EUTEAOIUQZ6YJUQWD75QO34H5TDGBLKP/ | 21:47 |
| clarkb | remote: https://review.opendev.org/c/openstack/tempest/+/957186 DNM Test devstack and tempest with Ansible 11 in Zuul | 21:49 |
| clarkb | and there is a canary for devstack and tempest | 21:49 |
| fungi | corvus: thanks, i just didn't know if we'd switched prefixes when we dropped nodepool | 21:50 |
| opendevreview | Clark Boylan proposed opendev/infra-specs master: Add spec to use Matrix for OpenDev comms https://review.opendev.org/c/opendev/infra-specs/+/954826 | 22:05 |
| clarkb | ok I think we just found an ansible 11 problem: https://zuul.opendev.org/t/openstack/build/9c11103ca84646cca286931f824f4d2d/log/job-output.txt#1103-1112 due to https://github.com/ansible-collections/openvswitch.openvswitch?tab=readme-ov-file#open-vswitch-collection | 22:09 |
| clarkb | the code is here: https://github.com/ansible-collections/openvswitch.openvswitch/blob/main/plugins/modules/openvswitch_bridge.py and it is gplv3 licensed. It is for testing only purposes in a zuul-jobs role. Should we maybe just vendor it? | 22:10 |
| clarkb | corvus: ^ thoughts on doing that? | 22:10 |
| clarkb | Then for buildkit mirror configuration we set that via buildkitd.toml: https://docs.docker.com/build/buildkit/configure/#registry-mirror Looks like we're already configuring that via https://opendev.org/zuul/zuul-jobs/src/branch/master/roles/use-buildset-registry/tasks/main.yaml#L77-L90 and | 22:16 |
| clarkb | https://opendev.org/zuul/zuul-jobs/src/branch/master/roles/use-buildset-registry/library/modify_buildkitd_toml.py so I think we're good. But I'm trying to understand what sort of toml that produces before being sure | 22:16 |
| clarkb | yes I believe that should produce valid config. And that role already sets things up for quay.io | 22:18 |
| clarkb | tl;dr I think our younger selves were way ahead of future us and configured buildkit appropriately | 22:19 |
| clarkb | and buildkit is the default image builder as of docker 23.0. We use the latest version by default which is newer than that | 22:20 |
| opendevreview | Clark Boylan proposed zuul/zuul-jobs master: Vendor openvswitch_bridge https://review.opendev.org/c/zuul/zuul-jobs/+/957188 | 22:35 |
| clarkb | I'm going to go ahead and propose vendoring the code because I'm curious to see if it is compatible with newer ansible (I suspect so but am not 100% certain) | 22:36 |
| corvus | clarkb: back -- vendoring somewhere sgtm... aiui that's a general role to set up multi-node bridging which is why it's in zuul-jobs and why you'd vendor that to zuul-jobs. but it's probably worth spending a couple of seconds thinking about whether that should go in openstack-zuul-jobs. | 22:37 |
| clarkb | corvus: yes exactly. The idea is to have a batteries included role for zuul that sets up an overlay network so that you can control l2 and up for your multinode jobs | 22:38 |
| clarkb | I'm not sure it makes sense to move into openstack-zuul-jobs unless we remove that role from zuul-jobs entirely | 22:39 |
| clarkb | (because the role will break as soon as zuul drops support for ansible 9( | 22:39 |
| corvus | agree | 22:39 |
| corvus | (i was thinking about both) | 22:39 |
| clarkb | I don't think openstack would have any problems with hosting that role for themselves if removed from zuul-jobs | 22:40 |
| corvus | sounds like there's 2 issues: 1) that role is not included in ansible anymore. 2) that role is being abandoned. vendoring is a fix for 1... but are we setting ourselves up for indefinite maintenance of that because it's abandoned? is that okay? should we do something else? | 22:40 |
| clarkb | my cynical take on 2) is that red hat is pushing hard to get everyone to use ovn intsead of ovs | 22:41 |
| clarkb | aiui ovn uses ovs under the hood. Ovn does not make sense for this setup as its a more complete network including dns and dhcp etc | 22:41 |
| clarkb | we want something minimal that jobs can build on top of to potentially test dhcp clients or servers | 22:42 |
| corvus | https://forum.ansible.com/t/unmaintained-collection-openvswitch-openvswitch/6245/15 | 22:43 |
| clarkb | which is to say I think ovs is going to stick around and likely continue to have stable interfaces but I guess there is no garuntee. Then on the other side of things we would potentially have to update the module if the internal ansible module interfaces change | 22:43 |
| corvus | clarkb: ^ that thread is worth a read | 22:43 |
| corvus | https://github.com/ansible-collections/openvswitch.openvswitch/blob/main/meta/runtime.yml#L2 | 22:44 |
| corvus | the collection specifies <2.18 (== ansible 11). that's pointed out in some commits from that thread | 22:45 |
| corvus | i don't know if that means "really won't work with" or just means "we stopped caring 2 years ago and don't want to deal with it" | 22:45 |
| clarkb | ya it isn't clear if that was their line in the sand or an actual compatibility issue | 22:45 |
| clarkb | I'm hoping that my proposed change helps shake some of that out | 22:45 |
| corvus | ++ good chance it's just line-in-the-sand | 22:46 |
| clarkb | as far as other choices go we could look at uses linux bridge again. In the past we didn't use linux bridge because we needed to support protocols that run over tcp or udp eg vxlan not gre | 22:46 |
| clarkb | I want to say on our side this all originated before linux bridge could speak vxlan and thus we used ovs. I think linuxbridge can use vxlan now and the new thing too (geneve) | 22:47 |
| clarkb | we may also consider wireguard though I think having extra security garuntees from wireguard is overkill | 22:47 |
| opendevreview | Clark Boylan proposed zuul/zuul-jobs master: Vendor openvswitch_bridge https://review.opendev.org/c/zuul/zuul-jobs/+/957188 | 22:48 |
| clarkb | the upside to linuxbridge is that its very standard on linux and doesn't really rely on any tooling that what yuo'd alredy expect to have on your linux install for network configuration | 22:50 |
| clarkb | and maybe we keep using vxlan for compatibility with older kernels? | 22:51 |
| clarkb | thinking out loud here: maybe the best thing to do would be to have openstack vendor the openvswitch stuff if it works. Then essentially mark the zuul-jobs role as non working and needing a rewrite to linuxbridge. if /when someone rewrites the zuul-jobs role we can drop the vendoring in openstack? | 22:51 |
| clarkb | this assumes that vendoring works. If vendoring does not work then we'll need to do the rewrite anyway | 22:52 |
| corvus | not a bad idea, but maybe still less effort to just vendor it in zuul-jobs and still declare it deprecated and in need of a rewrite | 22:56 |
| clarkb | ya maybe we do that if this minimal vendoring just works | 22:56 |
| clarkb | there is a linter error I'll need to address but that is minor | 22:58 |
| opendevreview | Goutham Pacha Ravi proposed openstack/project-config master: Retire Monasca project https://review.opendev.org/c/openstack/project-config/+/957063 | 23:12 |
| fungi | looking at the ansible version announcement, are we skipping over 10 or can jobs be configured to use that as well? | 23:19 |
| corvus | skipping 10 | 23:30 |
| clarkb | https://zuul.opendev.org/t/openstack/build/b9cc67956b504c07bc32c7f14dad6aea/console this build failed after my vendor of openvswitch_bridge. But I've just spent like 5 minutes reading through logs and I think ansible was fine. This seems to eb a legit failure | 23:31 |
| corvus | https://zuul-ci.org/docs/zuul/latest/config/job.html#attr-job.ansible-version which clark included in the announcement also confirms the two available versions | 23:32 |
| clarkb | still waiting on other multinode jobs to complete, but it is a good sign that they didn't retry failure loop | 23:33 |
Generated by irclog2html.py 4.0.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!