Tuesday, 2024-01-23

-opendevstatus- NOTICE: all new logins to https://review.opendev.org are currently failing. investigation is ongoing, please be patient08:53
jrossergood morning09:00
noonedeadpunk\o/09:01
jrossernoonedeadpunk: i found some things with openstack_resources09:14
jrossermostly small stuff but the image upload running every time is a bit of a pain09:15
jrosserwe have a similar role here, and we allow the downloaded images to persist on the ansible control node so they don't need to be downloaded each time09:16
noonedeadpunkyeah, I've read your comment. Eventually we upload only local images (since we build them with DIB), so this path I just added from top of my head09:23
noonedeadpunkand that's quite fair comment09:23
opendevreviewDmitriy Rabotyagov proposed openstack/openstack-ansible-os_ironic master: Fix a typo in pxe_redfish definition  https://review.opendev.org/c/openstack/openstack-ansible-os_ironic/+/90635309:28
jrossernoonedeadpunk: you can check / upload / properties as seperate steps https://paste.opendev.org/show/bK6J7pAzt0BSJlS2Wlpk/09:39
jrosser^ also handles making .raw from .qcow2 which you want for glance/cinder on RBD09:40
jrosserin our use we have mostly upstream images for debian/ubuntu/centos/... uploaded straight to glance09:41
jrosserbut also use DIB for ironic images09:42
noonedeadpunk++ that's very fair suggestions09:42
jrossertheres another task file next to that one which boots a VM with terraform and runs DIB in it09:42
jrosserthat code could be improved a bit as currently there is completely different code path depending on if image.convert_to is defined09:46
jrosserbut the tasks are basically the same09:46
gokhanhello folks, do you recommend update and upgrade OS packages before minor and major upgrades?09:51
jrossergokhan: it maybe depends what you want to achieve10:05
jrosseropesntack-ansible manages the isntallation of certain packages, and the upgrade process ensures that they are 'latest' when required, otherwise the state is set to 'present' so unexpected changes are not made10:06
jrosserbut as an example that does not keep you up to date / security patched with more general packages10:07
noonedeadpunkjust don't try to update packages when runnning against computes/net nodes, as upgrade of OVS with restart of neutron-openvswitch-agents leads to interesting race conditions10:09
noonedeadpunkthese should be done separately10:09
noonedeadpunkor at least ovs itself10:09
gokhanjrosser, we are trying to upgrade from victoria to antelope. so I am trying to make everything up to date but  I also want to be sure it doesn't break our environment. 10:11
jrossergokhan: let the playbooks do the updates for you10:13
jrosserlike noonedeadpunk says you make make everything very broken if you just randomly "update everything" without orchestrating those upgrades somehow10:13
gokhanI will not update packages manually, it is the best option to let the playbooks do the updates, thanks jrosser 10:13
opendevreviewDmitriy Rabotyagov proposed openstack/openstack-ansible-ops master: Use only unique backends to iterate over  https://review.opendev.org/c/openstack/openstack-ansible-ops/+/90635610:14
noonedeadpunkgokhan: that's not actually what I said :D10:14
gokhanalso thanks noonedeadpunk :)10:14
noonedeadpunkIn fact, I'd say that upgrading packages separately from playbook might be not worth idea10:14
noonedeadpunk*worst10:15
noonedeadpunkat least it will avoid potential race conditions when separate services are being restarted (ones from package update and others by running handlers) 10:16
noonedeadpunkBut the only weak place we found was OVS 10:16
noonedeadpunkAnd difference of running -e package_state=latest is dramatic in terms of environment stability10:16
jrosserwell keepalived can be fun too10:17
noonedeadpunkLike when we've upgraded OVS manually prior to running os-neutron-install it was matter of couple of pings being lost. When we used -e package_state=latest - was almost 30min outage10:17
noonedeadpunkNot everywhere, on some computes only, but still.10:18
gokhanif I get correctly, you mean you can update packages except OVS (you need to update ovs seperately) before running playbooks. 10:26
gokhannoonedeadpunk ^^10:27
jrosserupdating a package is not necessarily the same as the running software using the new stuff you just installed10:27
noonedeadpunkthis ^10:30
jrosserrunning the playbooks will update your packages where necessary, and restart services where necessary10:30
noonedeadpunkbut also - don't try to update packages while running os-neutron-install10:30
opendevreviewDmitriy Rabotyagov proposed openstack/openstack-ansible-ops master: Allow to gracefully drain backends when disabled  https://review.opendev.org/c/openstack/openstack-ansible-ops/+/90635810:37
gokhanthank noonedeadpunk jrosser I got it :) 10:39
hamburglerHmm, these new haproxy healthchecks just leave a bunch of non specific information as to what they are in the lxc https://paste.openstack.org/show/bF1rlzaAjkrAFM8jE2jt/ - is this intended? previously we were able to see what it was10:59
noonedeadpunkhamburgler: there were couple of regressions covered in 28.0.1 jsut in case11:02
noonedeadpunklike one was issuing l4 checks rather then l711:02
hamburglerkk :) will check those out11:03
noonedeadpunkand then also not using /healthcheck url11:03
hamburglerexcellent - sorry totally missed 28.0.111:03
noonedeadpunklike https://opendev.org/openstack/openstack-ansible-haproxy_server/commit/baf11a22fbf66ccd1cc95d60c3ea0c60a051decb https://opendev.org/openstack/openstack-ansible/commit/8bcd9198ff00363363fa3335e25c9fb6ece41847  https://opendev.org/openstack/openstack-ansible/commit/6bb4c0f70f7343e8dda1cbdcc36c5442bc562b9911:04
noonedeadpunkthese 3 that can lead to what you see11:04
hamburglerah yes :)11:04
hamburglerwonderful ty!11:05
noonedeadpunkspecififcally I think it's one to haproxy_server11:05
noonedeadpunknp11:05
opendevreviewDmitriy Rabotyagov proposed openstack/openstack-ansible master: [doc] Reffer need of haproxy backend configuration in upgrade guide  https://review.opendev.org/c/openstack/openstack-ansible/+/90636011:28
noonedeadpunkandrewbonney: this is smth we talked back in the days about OS upgrades - seemed to work for us, but would be great if you could confirm that ^11:28
andrewbonneyThanks I'll take a look. Was intending to update that when we upgrade to Jammy but you've beaten me to it :)11:29
jrosseri do wonder if we should add vrrp_track_file as a default11:29
jrosserso that you have a persistent way on the filesystem to ensure that a node does not take the VIP11:30
noonedeadpunkYeah, thats also an option11:32
opendevreviewJonathan Rosser proposed openstack/openstack-ansible-ops master: Add role to install and run sonobouy k8s validation tests  https://review.opendev.org/c/openstack/openstack-ansible-ops/+/90605411:35
opendevreviewJonathan Rosser proposed openstack/openstack-ansible-ops master: Add playbook to run functional test of magnum capi driver  https://review.opendev.org/c/openstack/openstack-ansible-ops/+/90636111:37
opendevreviewJonathan Rosser proposed openstack/openstack-ansible-ops master: WIP - Add collection to deploy magnum cluster-api with vexxhost driver  https://review.opendev.org/c/openstack/openstack-ansible-ops/+/90145012:14
opendevreviewJonathan Rosser proposed openstack/openstack-ansible-ops master: WIP - Bootstrapping playbook  https://review.opendev.org/c/openstack/openstack-ansible-ops/+/90217812:14
opendevreviewJonathan Rosser proposed openstack/openstack-ansible-ops master: Add role to install and run sonobouy k8s validation tests  https://review.opendev.org/c/openstack/openstack-ansible-ops/+/90605412:14
opendevreviewJonathan Rosser proposed openstack/openstack-ansible-ops master: Add playbook to run functional test of magnum capi driver  https://review.opendev.org/c/openstack/openstack-ansible-ops/+/90636112:14
opendevreviewJonathan Rosser proposed openstack/openstack-ansible-ops master: Add hook playbook install and test magnum capi driver  https://review.opendev.org/c/openstack/openstack-ansible-ops/+/90636312:14
opendevreviewJonathan Rosser proposed openstack/openstack-ansible-os_magnum master: Add job to test Vexxhost cluster API driver  https://review.opendev.org/c/openstack/openstack-ansible-os_magnum/+/90519913:09
opendevreviewJonathan Rosser proposed openstack/openstack-ansible-os_magnum master: Add job to test Vexxhost cluster API driver  https://review.opendev.org/c/openstack/openstack-ansible-os_magnum/+/90519913:16
opendevreviewDmitriy Rabotyagov proposed openstack/openstack-ansible-plugins master: DNM: Add volume type management  https://review.opendev.org/c/openstack/openstack-ansible-plugins/+/90637213:17
opendevreviewDmitriy Rabotyagov proposed openstack/openstack-ansible-plugins master: DNM: Add volume type management  https://review.opendev.org/c/openstack/openstack-ansible-plugins/+/90637213:21
opendevreviewDmitriy Rabotyagov proposed openstack/openstack-ansible-plugins master: Add openstack_resources role skeleton  https://review.opendev.org/c/openstack/openstack-ansible-plugins/+/87879413:42
opendevreviewJonathan Rosser proposed openstack/openstack-ansible-os_magnum master: Add job to test Vexxhost cluster API driver  https://review.opendev.org/c/openstack/openstack-ansible-os_magnum/+/90519913:57
opendevreviewDmitriy Rabotyagov proposed openstack/openstack-ansible-plugins master: Add openstack_resources role skeleton  https://review.opendev.org/c/openstack/openstack-ansible-plugins/+/87879414:00
noonedeadpunkugh, regarding images part, I barely have time to work on that right now :(14:04
noonedeadpunkpotentially - just drop tempdir step? 14:06
noonedeadpunkor fetch list of images twice I guess -before and after upload14:07
noonedeadpunkWill try to get some time for that till end of the week....14:08
jrosserwe can always improve it14:09
noonedeadpunk#startmeeting openstack_ansible_meeting15:00
opendevmeetMeeting started Tue Jan 23 15:00:16 2024 UTC and is due to finish in 60 minutes.  The chair is noonedeadpunk. Information about MeetBot at http://wiki.debian.org/MeetBot.15:00
opendevmeetUseful Commands: #action #agreed #help #info #idea #link #topic #startvote.15:00
opendevmeetThe meeting name has been set to 'openstack_ansible_meeting'15:00
noonedeadpunk#topic rollcall15:00
noonedeadpunko/15:00
jrossero/ hello15:00
NeilHanlono/ hiya folks15:02
mgariepyhey15:02
noonedeadpunk#topic office hours15:05
noonedeadpunkSoooooo15:05
noonedeadpunkThis week I had a peek into cinder_backends stuff https://opendev.org/openstack/openstack-ansible-os_cinder/src/branch/master/tasks/cinder_backends.yml15:05
noonedeadpunkand realized that there's no way to actually skip this thing15:06
noonedeadpunkAnd there're couple of smallish issues like if you want to set public: False - this will appear in cinder.conf as well15:06
noonedeadpunkbased on what mess it is, I thought that it's worth extending openstack_resources, since some modules appeared there to cover volume types, but these modules are jsut borked....15:07
noonedeadpunkthey're not idempotent, require weird input, etc15:08
noonedeadpunkBut now not sure if we should keep messing with what we have or try to fix modules...15:08
jrossereven this comment is wrong https://opendev.org/openstack/openstack-ansible-os_cinder/src/branch/master/tasks/cinder_backends.yml#L2815:09
noonedeadpunkAs at very least, I guess we should include the task conditionally based on the variable15:09
jrosserthere could be a pretty huge cleanup of that code without changing how it works15:10
noonedeadpunkhuh... it's not wrong...15:10
noonedeadpunkAs looks like we still deploying openrc to cinder_backends....15:11
noonedeadpunkor well, cinder_api15:11
jrosserthere is already delegation, and there is no need to run the openrc role i think15:11
noonedeadpunkWhat I don't like very much, is how it's tighten to backends defenition15:11
noonedeadpunkSo I was kinda thinking of introducing the new variable, and then do some kind of default wiring to it15:12
noonedeadpunkwhich basically lead me to variable structure and opensatck_resources role....15:12
noonedeadpunkuntil I realized it's a dead end as modules just don't work :(15:13
jrosseri guess the 'right thing' to do is to fix the ansible modules :/15:13
noonedeadpunkbut well15:13
jrosserbut that is likley work++15:13
noonedeadpunkpotentially we can use "same" structure 15:13
noonedeadpunkWhat I'm afraid most, is when it will land15:14
noonedeadpunkso we can use it15:14
jrosserright15:14
jrosserultimately the modules follow pretty closely the CLI15:14
jrosserso perhaps we can make a new datastructure that serves either, as temporary measure15:14
noonedeadpunkvolume_type jsut failed on me with `Volume Type lvm already exists.` when I ran it second time15:15
noonedeadpunkyeah, true15:15
noonedeadpunkHow are things with capi integration?15:15
jrosserso i think i would look at cleaning up what we have there in the ansible code as it is a huge mess15:15
jrosserlike all the path stuff is bogus, cli is in /usr/local/bin15:16
jrosserinsecure is dealt with in openrc anyway15:17
jrosserand `environment: { OS_CLOUD: default }` is sufficient to get command or shell module to pick up and use the right bits of openrc15:18
noonedeadpunkI was ectually thinking of providing --os-cloud default rather then sourcing openrc15:18
noonedeadpunkor that, yes15:18
noonedeadpunkto not repeat myself for each command, yes15:18
jrosseri think thats what i mean about cleanup15:19
noonedeadpunkyeah ,fair, I will look into cleanup of all that then15:19
jrosserwe could put all that in a block: and delete tons of nonsense15:19
noonedeadpunkWas hoping a bit just to drop all that instead :D15:19
NeilHanlon:P15:19
jrosserok so on capi integration15:20
jrosseri have some pretty interesting patches15:20
jrosserthis one first https://review.opendev.org/c/openstack/openstack-ansible/+/90625515:21
noonedeadpunkwhat I'm not sure about - if it's safe to drop `public` here https://opendev.org/openstack/openstack-ansible-os_cinder/src/branch/master/templates/cinder.conf.j2#L10715:21
jrossergeneral purpose extension hook points to add new playbooks15:21
noonedeadpunkI do like this one15:22
jrosserthis looks pretty cool as you can put in user variables `pre_setup_hosts_hook: my.collection.playbook`15:22
jrosserand i did wonder if we want to add similar hook points to all the things in openstack-ansible/playbooks15:23
jrosserbut i make this patch first as an example15:23
noonedeadpunkI guess it depends on how much sense to add this everywhere15:24
jrosserthen second thing is i have got a structure for a CI job that includes setup from an external collection15:24
jrosserhttps://review.opendev.org/c/openstack/openstack-ansible-os_magnum/+/905199/17/zuul.d/playbooks/bootstrap-mcapi-vexxhost.yml15:24
noonedeadpunkAs kinda service playbooks are small enough usually, so it would be close to same?15:24
noonedeadpunkand we don't have much in pre-post tasks...15:24
jrosserwell it depends if you want to drop something in after services, but before tempest for example15:25
noonedeadpunkbut dunno. Can't think of good usecase for having same in service playbooks yet15:25
jrosserbut maybe we wait for an actual need for that15:25
noonedeadpunkeventually....15:25
noonedeadpunkthere was some old patch of mine, that was jsut separating tempest/rally to their own thing15:25
noonedeadpunkor smth like that15:25
jrosseri've got a was to have a `bootstrap-aio` playbook in an external collection that gets called in the pre job zuul playbook15:26
jrosser*a way15:26
noonedeadpunklike https://review.opendev.org/c/openstack/openstack-ansible/+/84068515:26
jrosserthis keeps some things for /etc/openstack_deploy/... in the collection and drops them there before the main aio is boostrapped15:26
jrossercurrently this is a bit ugly, as there is a native way for zuul to understand that some of your repos contain roles, and to call them from your pre playbook15:27
jrosseryou would do this with `job.roles` and then use the roles as you need them15:27
jrosserunfortunately we cannot do the same with a collection, so there is a hacky call to the playbook path on the disk instead currently15:28
jrosserideally i would make a `osa_ops.mcapi_vexxhost.boostrap_aio` role that we could call directly from the pre playbook15:28
noonedeadpunkand for that bootstrap-ansible should already be done15:29
jrosserno, this is before15:29
noonedeadpunkum, ok. but what will execute pre-playbook then?15:30
jrosserin the case of a CI job, zuul15:30
noonedeadpunklike, given this pre-playbook is a hook to setup-everything (or smth like that)15:30
noonedeadpunk(if that's was an idea)15:30
jrosserthis is separate to the hooks thing15:30
noonedeadpunkaha, ok.15:31
noonedeadpunk(though it could be related :D)15:31
jrosserthe hooks allow you to use an external collection to deploy whatever, like cluster_api or ELK15:31
noonedeadpunklike provision extra stuff for openstack_deploy.....15:31
noonedeadpunkanyway15:31
noonedeadpunkyeah, probably you can't do that15:31
jrosserbut you need to get in *before* bootstrap-ansible to be able to use things like `user-ansible-venv-requirements.yml`15:32
noonedeadpunkas you'd need to reload inventory15:32
noonedeadpunkyeah, true15:32
noonedeadpunkfair15:32
jrosserso anyway, i think there is a route forward here for things like capi and ELK15:32
noonedeadpunkthat sounds really nice15:32
jrosserwhich will be much more maintainable than what we have right now in the ops repo15:32
noonedeadpunkyeah, that looks really nice15:35
jrosseri have everything pretty much done to deploy magnum + out of tree capi driver, and then run sonobuoy sanity check against a deployed cluster15:35
jrosserthis works nicely locally in 8 core 32G vm15:35
jrosserthis job pulls the whole lot together https://review.opendev.org/c/openstack/openstack-ansible-os_magnum/+/90519915:37
jrosserand i am seeing now if there is any chance for it to run in 3h15:37
noonedeadpunkfingers corssed15:37
jrosserwe can trim out heat15:37
noonedeadpunkmaybe worth disabling tempest somehow15:38
jrosserbut currently no way to do that as the auto-scenario stuff pulls it in with magnum15:38
jrossermaybe we need a NO_SCENARIO as well :)15:38
jrosseryes tempest is pretty spurious for this15:38
noonedeadpunklol15:38
noonedeadpunkI don't have bright ideas on how to drop heat from there15:45
noonedeadpunkrather then define all jobs from magnum independently15:45
jrosser`tempest_install: false` looks like it will just drop tempest entirely15:46
jrosseryeah i will think about that15:46
noonedeadpunkyeah, tempest should be easier to drop.15:47
noonedeadpunkofc depending on where we keep it currently15:47
noonedeadpunkhttps://opendev.org/openstack/openstack-ansible/src/branch/master/tests/roles/bootstrap-host/templates/user_variables.aio.yml.j2#L268-L27015:48
noonedeadpunkIt's not _that_ easy15:48
jrosseruser_variables_zzzz.yml will win :)15:48
noonedeadpunkor well, matter of condition {% if 'capi' not in bootstrap_host_scenarios %}15:49
jrosseri was trying not to mess with the openstack-ansible repo at all15:49
jrosserbecasue i'd like to make this all general enough that it will also be suitable for ELK or whatever else 15:49
jrosserso avoiding special casing things would be good15:49
noonedeadpunkyeah. true15:50
jrosserhah and of course just now tempest did fail on my capi job15:50
noonedeadpunkheh, yeah15:51
noonedeadpunkit's doomed to fail more or less15:51
noonedeadpunkor well. I think it's failing now jsut for regular magnum I assume15:51
jrosserright, because tempest runs in an unconfigured magum with no driver installed15:51
jrosserthe templates and images and everything are missing at that point15:52
noonedeadpunkouch15:54
noonedeadpunkok, well, it's expected I guess though15:54
jrosserindeed, i'll just disable it15:55
noonedeadpunkor this all is still need for capi driver?15:55
noonedeadpunklike cluster templates?15:55
jrosseryes, you still need it all15:55
jrosserbut there is chicken/egg15:55
jrosserthe control plane cluster_api k8s needs to be deployed before you make the templates15:56
noonedeadpunkaha, gotcha15:56
noonedeadpunkAnd I guess here where my debt comes to introduce a playbook for creating openstack_resources15:56
jrosserso os_magnum runs and installs the out-of-tree driver15:56
noonedeadpunkas that can be added as post-openstack hook to create resources15:56
noonedeadpunkor smth15:56
jrosserthen along somes the ops repo collection and puts in the rest in the post_hook15:57
jrosseri already used openstack_resources :) https://review.opendev.org/c/openstack/openstack-ansible-ops/+/906361/2/mcapi_vexxhost/playbooks/functional_test.yml15:57
*** jonher_ is now known as jonher16:06
*** jonher_ is now known as jonher16:08
noonedeadpunk#endmeeting16:09
opendevmeetMeeting ended Tue Jan 23 16:09:06 2024 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)16:09
opendevmeetMinutes:        https://meetings.opendev.org/meetings/openstack_ansible_meeting/2024/openstack_ansible_meeting.2024-01-23-15.00.html16:09
opendevmeetMinutes (text): https://meetings.opendev.org/meetings/openstack_ansible_meeting/2024/openstack_ansible_meeting.2024-01-23-15.00.txt16:09
opendevmeetLog:            https://meetings.opendev.org/meetings/openstack_ansible_meeting/2024/openstack_ansible_meeting.2024-01-23-15.00.log.html16:09
noonedeadpunkyeah, structure of the role kinda common to writing task itself I guess....16:10
noonedeadpunkin terms that it's huge16:10
noonedeadpunk*structure of vars for the role16:10
jrosserI like it16:12
jrosserthe code/tasks stay small and obvious16:12
jrosserand everything else is data16:12
opendevreviewJonathan Rosser proposed openstack/openstack-ansible-ops master: WIP - Bootstrapping playbook  https://review.opendev.org/c/openstack/openstack-ansible-ops/+/90217816:22
opendevreviewJonathan Rosser proposed openstack/openstack-ansible-ops master: Add role to install and run sonobouy k8s validation tests  https://review.opendev.org/c/openstack/openstack-ansible-ops/+/90605416:22
opendevreviewJonathan Rosser proposed openstack/openstack-ansible-ops master: Add playbook to run functional test of magnum capi driver  https://review.opendev.org/c/openstack/openstack-ansible-ops/+/90636116:22
opendevreviewJonathan Rosser proposed openstack/openstack-ansible-ops master: Add hook playbook install and test magnum capi driver  https://review.opendev.org/c/openstack/openstack-ansible-ops/+/90636316:22
noonedeadpunkseems rocky is unhappy with `nothing provides openssl-libs(x86-64) = 1:3.0.7-24.el9 needed by openssl-devel-1:3.0.7-24.el9.x86_64 from appstream`16:25
noonedeadpunkhttps://zuul.opendev.org/t/openstack/build/093dbc671bcb4f9da034bf72aa8ed9a616:25
noonedeadpunkmore then 2 jobs failed with that16:25
jrosseris that familiar thing16:27
jrosserperhaps it was ovs or something last time16:27
noonedeadpunknah, dunno. sounds like repo being desynced....16:31
opendevreviewJonathan Rosser proposed openstack/openstack-ansible master: Add SCENARIO_EXCLUDE environment variable to limit expansion of SCENARIO  https://review.opendev.org/c/openstack/openstack-ansible/+/90638816:53
jrossernoonedeadpunk: you can probably think of things this breaks :/ not sure im liking messing with the parameters of gate-check-commit script16:54
opendevreviewJonathan Rosser proposed openstack/openstack-ansible-os_magnum master: Add job to test Vexxhost cluster API driver  https://review.opendev.org/c/openstack/openstack-ansible-os_magnum/+/90519919:26
-opendevstatus- NOTICE: The Gerrit service on review.opendev.org will be offline momentarily for a restart, in order to attempt to restore OpenID login functionality19:35
-opendevstatus- NOTICE: OpenID logins for the Gerrit WebUI on review.opendev.org should be working normally again since the recent service restart20:02
hamburglerHey all :) was wondering if it was possible to get python-openstackclient bumped to 6.4.0 over 6.3.0 for bobcat - https://docs.openstack.org/python-openstackclient/latest/cli/command-objects/default-security-group-rule.html22:42
jrosserhamburgler: unfortunately that is not something openstack-ansible has direct control over https://github.com/openstack/requirements/blob/stable/2023.2/upper-constraints.txt#L47922:46
hamburgleroh shoot :D 22:46
hamburglerokay no worries :)22:46
jrosserhowever, there are enough hooks / places to override that you would be able to manipulate upper-constraints in your deployment22:47
jrossertotally untested though :)22:47
hamburgler:) - honestly don't even really need it for the utility container, just more of a nice to have, will just install on our deployment container and add any custom rules to default security group22:48
jrosseryeah the risk is that all the playbooks use ansible modules that use python-openstackclient as defined in u-c22:49
jrosserso if you change that in the utility container there might be side effects22:50
hamburglerdefinitely, will leave it for now :)22:51
opendevreviewJonathan Rosser proposed openstack/openstack-ansible-ops master: WIP - Bootstrapping playbook  https://review.opendev.org/c/openstack/openstack-ansible-ops/+/90217822:57
opendevreviewJonathan Rosser proposed openstack/openstack-ansible-ops master: Add role to install and run sonobouy k8s validation tests  https://review.opendev.org/c/openstack/openstack-ansible-ops/+/90605422:57
opendevreviewJonathan Rosser proposed openstack/openstack-ansible-ops master: Add playbook to run functional test of magnum capi driver  https://review.opendev.org/c/openstack/openstack-ansible-ops/+/90636122:58
opendevreviewJonathan Rosser proposed openstack/openstack-ansible-ops master: Add hook playbook install and test magnum capi driver  https://review.opendev.org/c/openstack/openstack-ansible-ops/+/90636322:58

Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!