auniyal | logs from nova/db/main/api should come in devstack@n-cond-cell1, super-cond or cpu ? | 05:31 |
---|---|---|
auniyal | it should come under devstack@n-super-cond, but exceptions are not coming | 05:41 |
bauzas | good morning Nova | 07:48 |
gibi | o/ | 07:49 |
bauzas | I just sent an email | 07:55 |
bauzas | tl;dr: HOLD YOUR RECHECKS | 07:55 |
gibi | I see a nice buzz around the issue in the bug report | 08:07 |
bauzas | like I said in -neutron, I'm looking at gerrit now based on mlavalle's comment | 08:08 |
gibi | I did that already and commented on the bug, but feel free to double check | 08:09 |
opendevreview | Sylvain Bauza proposed openstack/nova master: DNM: Avoid os-vif 3.0.0 https://review.opendev.org/c/openstack/nova/+/850998 | 08:17 |
bauzas | gibi: ^ | 08:17 |
gibi | bauzas: thanks | 08:18 |
sean-k-mooney[m] | why? | 08:53 |
sean-k-mooney[m] | what change in os-vif do you think is related | 08:53 |
sean-k-mooney[m] | the trunk bridge patch? | 08:55 |
sean-k-mooney[m] | https://github.com/openstack/os-vif/commit/75b290fb2a8f706583e0c12c5c5a4c0fc80e6481 ? | 08:56 |
sean-k-mooney[m] | if its related to that then the but is in neutron | 08:58 |
bauzas | sean-k-mooney: we're discussing it alot in the -neutron room | 09:03 |
bauzas | basically, neutron wanted to defer the trunk creation logic to os-vif but since we have rolling upgrades, looks like we now fail | 09:04 |
bauzas | it looks to me the upgrade approach was invalid and we should have waited nova to be fully upgraded | 09:04 |
opendevreview | Sylvain Bauza proposed openstack/nova master: Block os-vif 3.0.0 https://review.opendev.org/c/openstack/nova/+/850998 | 09:07 |
sean-k-mooney[m] | ill hop over | 09:07 |
sean-k-mooney[m] | but the nova and os-vif code is right i think | 09:07 |
sean-k-mooney[m] | but they may have dropped the bridge cleanup code to soon in neutron | 09:08 |
bauzas | sean-k-mooney: it seems so yeah | 09:08 |
bauzas | some logic was possibly modified in Neutron | 09:09 |
bauzas | this would explain why nova-next and grenade were failing | 09:09 |
bauzas | for the ovs-hybrid-plug job, I don't k | 09:09 |
*** tosky_ is now known as tosky | 09:10 | |
opendevreview | Sylvain Bauza proposed openstack/nova master: DNM for testing drop of os-vif to 2.8.0 https://review.opendev.org/c/openstack/nova/+/851006 | 09:41 |
opendevreview | Takashi Natsume proposed openstack/nova-specs master: Create specs directory for Antelope https://review.opendev.org/c/openstack/nova-specs/+/851007 | 09:48 |
opendevreview | sean mooney proposed openstack/os-vif master: [WIP] make os-vif jobs multinode and enable trunk testing https://review.opendev.org/c/openstack/os-vif/+/851011 | 10:26 |
whoami-rajat | dansmith, sean-k-mooney[m] hey, just a reminder to request to review the series of rebuilding volume backed instance, would like to get it in Zed release https://review.opendev.org/c/openstack/nova/+/820368/ | 10:30 |
bauzas | so, https://review.opendev.org/c/openstack/nova/+/851006 has a -1 but not because of the os-vif issue | 12:16 |
ratailor | bauzas, could you please provide your feedback on https://review.opendev.org/c/openstack/nova/+/844418 ? | 12:17 |
bauzas | ratailor: for the moment, I'm working on another CI issue | 12:18 |
bauzas | but ok | 12:18 |
ratailor | bauzas, no problem. whenever you have time. Thanks! | 12:18 |
opendevreview | ribaudr proposed openstack/nova master: [WIP] Attach Manila shares via virtiofs (objects) https://review.opendev.org/c/openstack/nova/+/839401 | 13:02 |
opendevreview | ribaudr proposed openstack/nova master: [WIP] Attach Manila shares via virtiofs (manila abstraction) https://review.opendev.org/c/openstack/nova/+/831194 | 13:02 |
opendevreview | ribaudr proposed openstack/nova master: [WIP] Attach Manila shares via virtiofs (drivers) https://review.opendev.org/c/openstack/nova/+/833090 | 13:02 |
opendevreview | ribaudr proposed openstack/nova master: [WIP] Attach Manila shares via virtiofs (api) https://review.opendev.org/c/openstack/nova/+/836830 | 13:02 |
opendevreview | ribaudr proposed openstack/nova master: [WIP] Bump compute version and check shares support https://review.opendev.org/c/openstack/nova/+/850499 | 13:02 |
opendevreview | ribaudr proposed openstack/nova master: [WIP] Add metadata for shares https://review.opendev.org/c/openstack/nova/+/850500 | 13:02 |
opendevreview | ribaudr proposed openstack/nova master: [WIP] Add instance.share_attach notification https://review.opendev.org/c/openstack/nova/+/850501 | 13:02 |
opendevreview | ribaudr proposed openstack/nova master: [WIP] Add instance.share_detach notification https://review.opendev.org/c/openstack/nova/+/851028 | 13:02 |
opendevreview | ribaudr proposed openstack/nova master: [WIP] Add shares to InstancePayload https://review.opendev.org/c/openstack/nova/+/851029 | 13:02 |
*** blarnath is now known as d34dh0r53 | 13:13 | |
bauzas | fwiw https://lists.openstack.org/pipermail/openstack-discuss/2022-July/029725.html | 13:14 |
*** dasm|off is now known as dasm | 13:19 | |
opendevreview | Kashyap Chamarthy proposed openstack/nova master: Add a workaround to skip hypervisor version check https://review.opendev.org/c/openstack/nova/+/851034 | 14:07 |
opendevreview | Kashyap Chamarthy proposed openstack/nova master: Add a workaround to skip hypervisor version check on LM https://review.opendev.org/c/openstack/nova/+/851034 | 14:14 |
kashyap | gibi: sean-k-mooney: --^ When you get a minu | 14:17 |
gibi | kashyap: we need a launchpad bug for tracking and a releasenotes | 14:19 |
gibi | otherwise looks good to me | 14:19 |
kashyap | gibi: Ah, yes; rel-no | 15:18 |
kashyap | Gonna do it | 15:18 |
kashyap | gibi: I hope you're cool with the what/why format here :) - https://bugs.launchpad.net/nova/+bug/1982853 | 15:23 |
sean-k-mooney | we dont actully enforce a format upstream so sure | 15:24 |
gibi | kashyap: it a bit strange as a bug report as it does not focus on the faulty behavior, but as sean-k-mooney said it is OK | 15:24 |
sean-k-mooney | although that makes it sound more like a feature then a bug | 15:24 |
kashyap | sean-k-mooney gibi Yeah, I can describe a buggy behaviour from OSP usage | 15:25 |
* kashyap goes to edit | 15:25 | |
sean-k-mooney | gibi: ya i had the same tought, framing it as what/why focuses on solution not the problem | 15:25 |
sean-k-mooney | well ter isnt a but in nova really | 15:26 |
gibi | but I understand if we don't want to embarrass ourselves with the actual fault we made downstream ;) | 15:26 |
kashyap | The "what" can also describe a problem space | 15:26 |
sean-k-mooney | but there are day 2 issues that people might hit that his will help wiht | 15:26 |
kashyap | I was just too lazy to add it | 15:26 |
sean-k-mooney | so im ok to tack it as a UX bug or operator nice to have | 15:26 |
sean-k-mooney | gibi: well im expecting we will close our downstream bz as not a bug honestly | 15:28 |
kashyap | Yeah, that's why the "why" describes an example use-case, instead of an elaborate mistake of a specific OpenStack distro :) | 15:28 |
sean-k-mooney | but we will se we might have to kep it open for backport reaons | 15:28 |
sean-k-mooney | and doc text ectra | 15:28 |
gibi | ack | 15:28 |
sean-k-mooney | just due to the constratints of the tooling so ya | 15:28 |
sean-k-mooney | so if there is no objection im going to trage this as a wishlist bug | 15:29 |
gibi | works for me | 15:31 |
sean-k-mooney | https://bugs.launchpad.net/nova/+bug/1982853 cool done | 15:34 |
gibi | sean-k-mooney: thanks | 15:38 |
bauzas | reminder : nova meeting in 20 mins | 15:39 |
bauzas | #startmeeting nova | 16:00 |
opendevmeet | Meeting started Tue Jul 26 16:00:04 2022 UTC and is due to finish in 60 minutes. The chair is bauzas. Information about MeetBot at http://wiki.debian.org/MeetBot. | 16:00 |
opendevmeet | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | 16:00 |
opendevmeet | The meeting name has been set to 'nova' | 16:00 |
bauzas | hello folks | 16:00 |
gibi | o/ | 16:00 |
bauzas | who's around ? | 16:01 |
bauzas | #link https://wiki.openstack.org/wiki/Meetings/Nova#Agenda_for_next_meeting | 16:01 |
elodilles | o/ | 16:02 |
bauzas | ok let's start, people will join | 16:02 |
bauzas | #topic Bugs (stuck/critical) | 16:02 |
bauzas | #info No Critical bug | 16:02 |
bauzas | #link https://bugs.launchpad.net/nova/+bugs?search=Search&field.status=New 10 new untriaged bugs (+0 since the last meeting) | 16:02 |
bauzas | #link https://storyboard.openstack.org/#!/project/openstack/placement 27 open stories (+0 since the last meeting) in Storyboard for Placement | 16:02 |
bauzas | #info Add yourself in the team bug roster if you want to help https://etherpad.opendev.org/p/nova-bug-triage-roster | 16:02 |
Uggla | o/ | 16:03 |
bauzas | given I'll be on PTO after the next meeting, I can be the next bug baton owner for this week | 16:03 |
bauzas | elodilles: sorry, but I'll take it for this week :p | 16:03 |
elodilles | :'( | 16:03 |
elodilles | no problem of course :D | 16:03 |
bauzas | hah | 16:04 |
gibi | elodilles: you can have mine if you want ;) | 16:04 |
bauzas | #info Next bug baton is passed to bauzas | 16:04 |
bauzas | that's it for bugs | 16:04 |
bauzas | we'll discuss the CI outage in the next topic | 16:04 |
bauzas | any other bug to discuss ? | 16:04 |
bauzas | looks not | 16:05 |
bauzas | #topic Gate status | 16:05 |
bauzas | #link https://bugs.launchpad.net/nova/+bugs?field.tag=gate-failure Nova gate bugs | 16:05 |
bauzas | so, | 16:05 |
bauzas | you maybe have seen my emails | 16:05 |
bauzas | the gate is blocked at the moment | 16:05 |
bauzas | #link https://bugs.launchpad.net/nova/+bug/1940425 gate blocker | 16:06 |
bauzas | I triaged the bug status to invalid for nova as this is an os-vif/neutron issue | 16:06 |
bauzas | #link https://lists.openstack.org/pipermail/openstack-discuss/2022-July/029725.html | 16:07 |
bauzas | the ML thread ^ | 16:07 |
bauzas | please don't recheck your changes until we merge an os-vif version blocker | 16:07 |
bauzas | for 3.0.0 | 16:07 |
bauzas | now, once the os-vif blocker will be merged, we'll still need to find a way to use os-vif 3.0.x | 16:08 |
bauzas | do people want to know more ? | 16:09 |
bauzas | or can we continue ? | 16:10 |
bauzas | mmmm ok | 16:10 |
bauzas | then, let's continur | 16:11 |
bauzas | the periodic job runs | 16:11 |
bauzas | #link https://zuul.openstack.org/builds?project=openstack%2Fplacement&pipeline=periodic-weekly Placement periodic job status | 16:11 |
bauzas | #link https://zuul.openstack.org/builds?job_name=tempest-integrated-compute-centos-9-stream&project=openstack%2Fnova&pipeline=periodic-weekly&skip=0 Centos 9 Stream periodic job status | 16:11 |
bauzas | #link https://zuul.opendev.org/t/openstack/builds?job_name=nova-emulation&pipeline=periodic-weekly&skip=0 Emulation periodic job runs | 16:11 |
bauzas | I don't see any problem with all of them ^ | 16:12 |
chateaulav | always good to see passing jobs | 16:12 |
gibi | :) | 16:12 |
bauzas | would love to see nova-next and grenade passing too, but meh :) | 16:12 |
gibi | we cannot have it all :) | 16:13 |
sean-k-mooney | https://review.opendev.org/c/openstack/tempest/+/850242 | 16:13 |
sean-k-mooney | is stilll pending | 16:13 |
bauzas | yup, i guessed it | 16:13 |
sean-k-mooney | to move centos job to perodic weekly only | 16:13 |
sean-k-mooney | can we ping anyone in tempest to expidite that | 16:13 |
bauzas | as I saw we continue to have check and gate jobs for those | 16:13 |
bauzas | sean-k-mooney: maybe gmann ? | 16:14 |
sean-k-mooney | perhaps | 16:14 |
dansmith | yeah gmann and kopecmartin | 16:14 |
sean-k-mooney | illl add them as a review | 16:14 |
bauzas | cool | 16:15 |
bauzas | #info Please look at the gate failures and file a bug report with the gate-failure tag. | 16:15 |
bauzas | #info STOP DOING BLIND RECHECKS aka. 'recheck' https://docs.openstack.org/project-team-guide/testing.html#how-to-handle-test-failures | 16:15 |
bauzas | next topic then | 16:16 |
bauzas | #topic Release Planning | 16:16 |
bauzas | #link https://releases.openstack.org/zed/schedule.html | 16:16 |
bauzas | #info Zed-3 is in 5 weeks | 16:16 |
bauzas | #topic Review priorities | 16:17 |
bauzas | #link https://review.opendev.org/q/status:open+(project:openstack/nova+OR+project:openstack/placement+OR+project:openstack/os-traits+OR+project:openstack/os-resource-classes+OR+project:openstack/os-vif+OR+project:openstack/python-novaclient+OR+project:openstack/osc-placement)+label:Review-Priority%252B1 | 16:17 |
bauzas | ah shit | 16:17 |
bauzas | I forgot to change the url | 16:17 |
bauzas | should create a bit.ly I guess | 16:17 |
bauzas | #undo | 16:18 |
opendevmeet | Removing item from minutes: #link https://review.opendev.org/q/status:open+(project:openstack/nova+OR+project:openstack/placement+OR+project:openstack/os-traits+OR+project:openstack/os-resource-classes+OR+project:openstack/os-vif+OR+project:openstack/python-novaclient+OR+project:openstack/osc-placement)+label:Review-Priority%252B1 | 16:18 |
bauzas | #link https://review.opendev.org/q/status:open+(project:openstack/nova+OR+project:openstack/placement+OR+project:openstack/os-traits+OR+project:openstack/os-resource-classes+OR+project:openstack/os-vif+OR+project:openstack/python-novaclient+OR+project:openstack/osc-placement)+(label:Review-Priority%252B1+OR+label:Review-Priority%252B2) | 16:18 |
bauzas | as you see, we need to merge the 2.91 patch | 16:18 |
bauzas | but given the CI outage, we can't do it yet | 16:19 |
sean-k-mooney | i think the requirements patch should merge in then next hour | 16:19 |
bauzas | any review-prio to discuss ? | 16:19 |
sean-k-mooney | so likely wont be much longer | 16:19 |
bauzas | sean-k-mooney: oh haven't seen an update yet | 16:19 |
sean-k-mooney | it has +w i think | 16:19 |
sean-k-mooney | so it should be in the gate as we speak | 16:19 |
bauzas | nice | 16:20 |
bauzas | we already have the nova change for i | 16:20 |
bauzas | it | 16:20 |
bauzas | can we move to the stable branches topic ? | 16:20 |
sean-k-mooney | yes | 16:22 |
bauzas | cool | 16:22 |
bauzas | #topic Stable Branches | 16:22 |
* bauzas gives the mic to elodilles | 16:22 | |
elodilles | :) | 16:22 |
elodilles | yes, so | 16:23 |
elodilles | actually i haven't updated the stable section, as the state is the same as last week :/ | 16:23 |
elodilles | #info stable branch status / gate failures tracking etherpad: https://etherpad.opendev.org/p/nova-stable-branch-ci | 16:23 |
elodilles | and train is blocked :/ | 16:23 |
elodilles | i could spend only a little time to look at the train gate issue | 16:23 |
elodilles | (devstack-gate is failing to install python3-yaml) | 16:24 |
sean-k-mooney | is the shell issue still blocked byu another issue | 16:24 |
elodilles | sean-k-mooney: yepp | 16:24 |
elodilles | if only nova-grenade would fail i'd suggest to set it non-voting 'temporarily' | 16:24 |
elodilles | (especially as it is stable/train which is quite old) | 16:24 |
sean-k-mooney | ya that might be the path forward | 16:25 |
elodilles | but unfortunately nova-live-migration also fails with the same issue | 16:25 |
elodilles | so it would mean two jobs :/ | 16:25 |
sean-k-mooney | failing to install python3-yaml | 16:26 |
elodilles | though the good part would be to have less intermittent failure to catch :P | 16:26 |
sean-k-mooney | is it a dist tools failure | 16:26 |
sean-k-mooney | i.e. pip refusing to upgrade it | 16:26 |
elodilles | sean-k-mooney: i don't know as it gets timed out | 16:26 |
elodilles | and we don't have logs either :/ | 16:26 |
sean-k-mooney | becasue python3-yaml is one of those packages i alway unitlly form the disto before i run devstack | 16:26 |
sean-k-mooney | ack | 16:26 |
elodilles | i mean only the jobs-output.txt | 16:26 |
elodilles | the last line we see is the processing triggers from libc-bin | 16:27 |
elodilles | then it hangs for 2 hrs | 16:27 |
sean-k-mooney | oh hum + /opt/stack/new/devstack-gate/functions.sh:apt_get_install:L71: sudo DEBIAN_FRONTEND=noninteractive apt-get --assume-yes install python3-yaml | 16:28 |
sean-k-mooney | so its explcitly being installed form the distor in that job | 16:28 |
elodilles | yes, from devstack-gate | 16:28 |
sean-k-mooney | which is the the opicit of what i normally do | 16:28 |
elodilles | locally this works fine for me with the same packages (if i checked them correctly) | 16:29 |
elodilles | so still could not reproduce | 16:29 |
elodilles | that's it for what i can tell for now :/ | 16:30 |
sean-k-mooney | ack | 16:31 |
sean-k-mooney | it does look like it jut hang proceeign the triggers fo libc-bin | 16:32 |
sean-k-mooney | as a workaround we could add a pre playbook to do a full update/upgade of the packages and preinstall that | 16:32 |
sean-k-mooney | and see if it helped | 16:32 |
chateaulav | i wonder if there is some weird package prompt stalling the process | 16:32 |
elodilles | yes, otherwise we should see some continuation from the devstack-gate script | 16:32 |
sean-k-mooney | sudo DEBIAN_FRONTEND=noninteractive apt-get --assume-yes install python3-yaml | 16:33 |
sean-k-mooney | so its being pulled in form that but | 16:33 |
sean-k-mooney | --assume-yes and noninteractive | 16:33 |
sean-k-mooney | shoudl disable all prompts | 16:33 |
sean-k-mooney | anyway we proably can move on | 16:33 |
chateaulav | ill see if I cant dedicate some time this week to take a look. | 16:33 |
elodilles | thanks! | 16:34 |
bauzas | cool, moving on then | 16:34 |
bauzas | and thanks all for discussing it | 16:34 |
elodilles | for the workaround suggestion, too, sean-k-mooney | 16:34 |
elodilles | bauzas: ++ | 16:35 |
bauzas | #topic Open discussion | 16:35 |
bauzas | (bauzas) will be on PTO between Aug 3rd and Aug 29th, who would want to chair the 3 meetings ? | 16:35 |
* bauzas needs to visit Corsica | 16:35 | |
bauzas | or do we need to cancel those ? | 16:35 |
bauzas | I'd prefer the former honestly, given we're on zed-3 | 16:36 |
gibi | I think I can take them | 16:36 |
bauzas | gibi: <3 | 16:36 |
bauzas | I'll be back on time before the 3rd milestone | 16:36 |
gibi | 9th, 16th, 23rd | 16:36 |
bauzas | should even be around on IRC on Monday but shhhtttt | 16:36 |
bauzas | #action gibi to chair 3 nova meetings (Aug 9th, 16th and 23rd) | 16:37 |
Uggla | bauzas, can we define the microversion for virtiofs/manila ? | 16:38 |
bauzas | I'll chair next week's meeting | 16:38 |
bauzas | Uggla: good question | 16:38 |
bauzas | I was about to write an email for asking people to look at https://etherpad.opendev.org/p/nova-zed-microversions-plan | 16:38 |
bauzas | but given we had the CI outage from last week, I didn't had time to do it | 16:38 |
bauzas | to be fair, I'll write the email to ask people to propose their microversion changes if they think they're already done | 16:39 |
bauzas | Uggla: for the moment, plan to use 2.93 | 16:40 |
Uggla | ok sounds good to me. | 16:40 |
bauzas | melwitt wrote something for last meeting but we hadn't time to discuss about it AFAIR | 16:41 |
bauzas | (melwitt) I will not be at the meeting today but in case you missed it, I'm seeking input regarding terminology used in the currently named "ephemeral encryption" feature spec and patches: https://lists.openstack.org/pipermail/openstack-discuss/2022-July/029546.html. If you have thoughts on whether the terminology should be changed to something other than "ephemeral encryption", please comment on the ML thread or on this pa | 16:41 |
bauzas | tch https://review.opendev.org/c/openstack/nova/+/764486 (thank you gibi for adding a comment 🙂) | 16:41 |
bauzas | sounds a new naming bikeshed \o/ | 16:42 |
bauzas | any opinions about a possible good name instead of "ephemeral encryption" ? | 16:43 |
bauzas | reminder : I'm terrible at naming things | 16:43 |
bauzas | sean-k-mooney: to be fair, we name "ephemeral disks" disks that are created and aren't volumes | 16:44 |
bauzas | and are persisted | 16:44 |
sean-k-mooney | ephmeral disks are only the disk created form flavor.ephmeral | 16:44 |
sean-k-mooney | so to me it wrong ot ever use it in any other context | 16:44 |
bauzas | if you have a flavor with DISK_GB=10, correct me if I'm wrong but you'll get a 10GB disk that will be an "ephemeral disk" | 16:45 |
bauzas | (not a BFV I mean) | 16:45 |
sean-k-mooney | no | 16:45 |
sean-k-mooney | that is incorrect terminology | 16:46 |
sean-k-mooney | and what im objecting too | 16:46 |
gibi | local vs volume, root vs ephermeral, these are the terminologies in the API doc | 16:46 |
sean-k-mooney | right | 16:46 |
bauzas | https://docs.openstack.org/arch-design/design-storage/design-storage-concepts.html | 16:46 |
bauzas | Ephemeral storage - If you only deploy OpenStack Compute service (nova), by default your users do not have access to any form of persistent storage. The disks associated with VMs are ephemeral, meaning that from the user’s point of view they disappear when a virtual machine is terminated. | 16:46 |
bauzas | we name them "ephemeral" because we delete the disk when the instance is removed | 16:47 |
gibi | and we delete volumes as well if so configured :D | 16:47 |
sean-k-mooney | whihc is not correct | 16:47 |
sean-k-mooney | deleting somting at the end of its lifetime does not make it epmeral | 16:47 |
bauzas | technically, you can have ephemeral disks on shared storage (NFS) | 16:48 |
sean-k-mooney | if we delete a volume we also expect the data to be removed | 16:48 |
sean-k-mooney | or ceph | 16:48 |
sean-k-mooney | if you use the rbd image_backend | 16:48 |
bauzas | sean-k-mooney: I don't disagree with you, I'm just explaining our docs | 16:48 |
sean-k-mooney | yep | 16:49 |
bauzas | not only our upstream docs btw... https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/16.2/html/creating_and_managing_instances/con_types-of-instance-storage_osp :) | 16:50 |
sean-k-mooney | so i would prefer something like local_disk_encryption, instance_disk_encypriton or similar | 16:50 |
sean-k-mooney | bauzas: right but there are many other things wrong with our downstream docs | 16:50 |
gibi | +1 on local disk encryption | 16:50 |
bauzas | I'd prefer local disk encryption over instance disk encryption | 16:51 |
sean-k-mooney | im not going to block this progressing on the name | 16:51 |
sean-k-mooney | i just find the usage of ephmeral to rever to storage tied to the vms lifecycle to be mildly insulting | 16:52 |
bauzas | because an instance disk can either be "ephemeral" (from local libvirt disk), or something else | 16:52 |
bauzas | technically, this ephemeral storage is actually our virt driver local storage | 16:53 |
bauzas | depending on the virt driver you use | 16:53 |
sean-k-mooney | its not nessiarly local | 16:53 |
bauzas | tell ironic about it :) | 16:53 |
sean-k-mooney | well for libvirt or vmware | 16:53 |
bauzas | yeah, see, I made that mistake | 16:53 |
sean-k-mooney | the storage can be clusterd or remote | 16:53 |
bauzas | shared storage is ephemeral | 16:53 |
bauzas | so, not local | 16:54 |
sean-k-mooney | this is why i dont like using that term | 16:54 |
melwitt | hey o/ thanks for discussing the naming bikeshed :) just wanted to get some confidence that ppl would prefer a name change and lessen the possibility of someone coming to the review later and saying "why did you change this, it should be changed back to ephemeral" | 16:54 |
sean-k-mooney | ephemeral is ambiguious | 16:54 |
bauzas | as is "evacuate" :D | 16:54 |
bauzas | our Gods of Naming didn't help | 16:54 |
sean-k-mooney | maybe we need dansmith to write another blog post | 16:55 |
bauzas | problem solved. | 16:55 |
sean-k-mooney | melwitt: ack so i guess the real question is | 16:55 |
bauzas | #action dansmith to write a blogpost | 16:55 |
sean-k-mooney | do we think channging the name will make thing clearer | 16:55 |
dansmith | heh | 16:55 |
bauzas | oh, snap, he saw it | 16:55 |
melwitt | :) | 16:55 |
bauzas | #undo | 16:55 |
opendevmeet | Removing item from minutes: #action dansmith to write a blogpost | 16:55 |
dansmith | In general, I'm not for renaming things like this | 16:55 |
bauzas | I'm not against renaming ity | 16:56 |
bauzas | I just wanted to make sure we all agree on what this is | 16:56 |
bauzas | ephemeral is a bad name, but that's a name we already use | 16:56 |
dansmith | because you'll end up with all old docs being inaccurate for new stuff, and people who already understand this will also have to change | 16:56 |
melwitt | that was one of my concerns | 16:56 |
bauzas | if we pick something else, this has to be better understandable about what it is | 16:56 |
bauzas | yeah, if we need to write some doc explaining "ephemeral" == "this new thing" this is bad | 16:57 |
bauzas | hence the challenge | 16:57 |
gibi | so this is considered a non fixable terminology mistake of the past? | 16:58 |
bauzas | like tenant ? :) | 16:58 |
gibi | we are fixing tenant | 16:58 |
sean-k-mooney | well to me that doc that is erfernce is not a nova doc | 16:58 |
bauzas | I know, I'm opening a can of worms | 16:58 |
sean-k-mooney | so we could jsut fix it | 16:58 |
bauzas | and pretend it never existed, heh ? :) | 16:58 |
bauzas | we're running out of time, but for the sake of the conversation, let's continue | 16:59 |
sean-k-mooney | well from my point of view the only thing that nova ever said was ephemreal is the falvor.ephemeral storage disks | 16:59 |
bauzas | I'll just formally end the meeting at the top of the hour | 16:59 |
sean-k-mooney | melwitt: are we encypting the flavor.epmermal disks by the way | 16:59 |
sean-k-mooney | or just root and swap | 17:00 |
bauzas | problem is | 17:00 |
sean-k-mooney | i thikn we will be encypting all 3 types | 17:00 |
bauzas | root is also "ephemeral" | 17:00 |
bauzas | (depending on the conf options) | 17:00 |
sean-k-mooney | bauzas: it depend on the difinition | 17:00 |
sean-k-mooney | form our api its not | 17:00 |
melwitt | sean-k-mooney: what is "flavor.ephemeral"? it is encrypting the root disk and any other attached local disks | 17:00 |
sean-k-mooney | in our flavor we have 3 types of storage | 17:01 |
bauzas | correct, the point is that *by default, we don't do any difference between root disk and other local (or non-local on shared) disk | 17:01 |
sean-k-mooney | root, swap and ephemeral | 17:01 |
sean-k-mooney | https://docs.openstack.org/nova/latest/user/flavors.html | 17:01 |
melwitt | ok, this is encrypting root and ephemeral, and not swap | 17:01 |
bauzas | right | 17:01 |
bauzas | about the new feature | 17:02 |
sean-k-mooney | so we proably should be encyrpting swap too but we can maybe add that next cycle | 17:02 |
bauzas | swap is out of scope AFAICT | 17:02 |
sean-k-mooney | im not sure why it would be | 17:03 |
sean-k-mooney | we declared it out of scope for this cycle i guess | 17:03 |
sean-k-mooney | but i would hope it woudl get done before we condire this fully complete | 17:03 |
bauzas | because swap isn't using QEMU file-based storage ? | 17:03 |
sean-k-mooney | it is | 17:03 |
sean-k-mooney | depending on your backend | 17:04 |
bauzas | f*** | 17:04 |
sean-k-mooney | it will use a qcow files or a rbd volume | 17:04 |
bauzas | I'm not expert on swap | 17:04 |
bauzas | then, all disks (root, swap and others) go into a same bucket | 17:04 |
bauzas | which is by default the virt driver storage backend | 17:04 |
melwitt | basically this is encrypting things that are under the 'ephemerals' and 'image' keys in block_device_info: https://review.opendev.org/c/openstack/nova/+/826529/7/nova/virt/driver.py#107 | 17:05 |
melwitt | 'swap' has its own key in block_device_info | 17:05 |
sean-k-mooney | so ephemerals should be the storage form flavor.ephemeral_gb | 17:06 |
bauzas | do we know if https://docs.openstack.org/nova/latest/configuration/config.html?highlight=ephemeral#DEFAULT.default_ephemeral_format is also used for root and swap ? | 17:06 |
sean-k-mooney | image is presumable the storage form flavor.root_gb | 17:07 |
melwitt | I don't know the reason swap is not included and I just checked the specs again and don't find it mentioned why | 17:07 |
sean-k-mooney | bauzas: no i belive that is for ephemeral_gb only | 17:07 |
sean-k-mooney | bauzas if you dont specy how you want flavor.ephemeral_gb to be devied up on the server create api request | 17:08 |
sean-k-mooney | we use that config to determin the format | 17:08 |
sean-k-mooney | and we provide a single ephemeral disk | 17:08 |
sean-k-mooney | but you can ask for nova to provide multiple disks as long as the total is equal to or less then flavor.ephemeral_gb | 17:09 |
bauzas | looks like I need to end this meeting | 17:09 |
bauzas | but let's continue | 17:10 |
sean-k-mooney | this gets modeled in the block device mapping info passed in the api request | 17:10 |
sean-k-mooney | ack | 17:10 |
bauzas | #endmeeting | 17:10 |
opendevmeet | Meeting ended Tue Jul 26 17:10:07 2022 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 17:10 |
opendevmeet | Minutes: https://meetings.opendev.org/meetings/nova/2022/nova.2022-07-26-16.00.html | 17:10 |
opendevmeet | Minutes (text): https://meetings.opendev.org/meetings/nova/2022/nova.2022-07-26-16.00.txt | 17:10 |
opendevmeet | Log: https://meetings.opendev.org/meetings/nova/2022/nova.2022-07-26-16.00.log.html | 17:10 |
bauzas | I'm trying to see whether we have 'ephemeral' as an API contract besides the ephemeral disks | 17:10 |
sean-k-mooney | that depends on the definition of ephemeral | 17:11 |
sean-k-mooney | if you use ephemeral or not to imply falult tollerance then no | 17:11 |
sean-k-mooney | if you are using it to imply tied to lifecycle fo vm its no differnt then root other thatn its not included in snapshots | 17:12 |
bauzas | from a BDM perspective, nothing changes between a root disk and an ephemeral disk, right? (by default, I mean) | 17:12 |
sean-k-mooney | nothign major | 17:12 |
sean-k-mooney | they are slithgly differnt in that root will have an imave as it source | 17:13 |
bauzas | correct | 17:13 |
sean-k-mooney | and ephemeral disk are always empty | 17:13 |
stephenfin | totally unrelated to ephemeral stuff, but I think we're finally reading to switch from mock to unittest.mock | 17:13 |
stephenfin | The removal of Python 3.6 support simplifies our job significantly since the unittest.mock lib there was buggy as hell | 17:13 |
sean-k-mooney | stephenfin: i think i saw you respin that last week | 17:13 |
stephenfin | Do we want to prioritize reviews of that patch so we can avoid rebase hell? https://review.opendev.org/c/openstack/nova/+/714676/ | 17:13 |
stephenfin | I think melwitt and sean-k-mooney have been interested in that in the past | 17:14 |
stephenfin | interested/involved | 17:14 |
stephenfin | sean-k-mooney: Yeah, I meant to do it sooner and, um, forgot | 17:14 |
sean-k-mooney | ya so we likely need to land the unshleve to host patch first but then i would be open to landing that next | 17:14 |
sean-k-mooney | bauzas: is the unshelve to host patch ready to emrge once the gate issue is resolved | 17:15 |
stephenfin | It's simultaneously low priority (mock works just fine) and high priority (so much chance of merge conflicts) | 17:15 |
bauzas | stephenfin: that makes me a bit nervous | 17:15 |
sean-k-mooney | bauzas: https://review.opendev.org/c/openstack/requirements/+/851002/ is merged by the way | 17:15 |
stephenfin | sean-k-mooney: fine by me. I'm just raising this up now before I forget again 0:) | 17:15 |
sean-k-mooney | bauzas: why? | 17:15 |
bauzas | stephenfin: sean-k-mooney: because we're on zed-3 | 17:15 |
sean-k-mooney | bauzas: i really dont think it will break anything | 17:16 |
bauzas | and we'll create a ton of merge conflicts | 17:16 |
sean-k-mooney | bauzas: right we punted it last time for the same reason | 17:16 |
sean-k-mooney | bauzas: so i would prefer to either do this after zed-3 but beofre rc1 | 17:16 |
sean-k-mooney | or do it sooner rather then later | 17:16 |
bauzas | don't disagree | 17:16 |
gibi | do it sooner | 17:17 |
gibi | later means we will have the same discussion again in the future :) | 17:17 |
bauzas | after zed-3 and before zed-rc1 seems reasonable, as is after we branch zed | 17:17 |
sean-k-mooney | can we merge it now | 17:17 |
stephenfin | the merge conflicts should only happen in the imports section since I've been able to remove most of the workarounds that were needed to workaround Python 3.6 bugs in unittest.mock | 17:17 |
sean-k-mooney | thet gate shoudl not be blocked | 17:17 |
sean-k-mooney | then merge the api change patches | 17:17 |
bauzas | are we done with the ephemeral bikeshed ? | 17:18 |
sean-k-mooney | bauzas: well we can continue but this was a nice break | 17:18 |
stephenfin | (to be specific, only nova/tests/functional/regressions/test_bug_1781286.py and nova/tests/fixtures/nova.py needed more that a simple import replacement) | 17:18 |
melwitt | stephenfin: I added a small change in a func test in that patch ages ago to help it pass CI at the time. I wasn't sure if I should be +2ing it bc of that | 17:19 |
bauzas | for that unittest usage, well, I'd appreciate if we could target it post-FF | 17:19 |
bauzas | but cores are free to vote | 17:19 |
sean-k-mooney | if we agree ahead of time that this is oke to merge say on the monday after FF to give time for rechecks | 17:20 |
sean-k-mooney | then im ok with that otherwise i would prefer to merge it this week | 17:20 |
sean-k-mooney | instead of defering to next cycle again | 17:20 |
gibi | at FF we might have potential FF exceptions that and we will run against the clock | 17:20 |
stephenfin | melwitt: Yeah, that's the change in nova/tests/functional/regressions/test_bug_1781286.py. I've touched that code also at this point so I wouldn't like us to both abstain | 17:20 |
gibi | imposing merge conflict that point feels worse than imposing it now | 17:21 |
sean-k-mooney | yep | 17:21 |
stephenfin | bauzas: I'd rather deal with merge conflicts now than when the gate is hammered before FF | 17:21 |
stephenfin | personally | 17:21 |
sean-k-mooney | same | 17:21 |
bauzas | then, looks like you have your two cores | 17:21 |
bauzas | :) | 17:21 |
stephenfin | Wow, I proposed this in March 24 2020. 3 days before lockdown #1 (in Ireland, anyway) | 17:22 |
stephenfin | Oh, the innocence of pre-COVID times :) | 17:22 |
sean-k-mooney | heh | 17:22 |
sean-k-mooney | i set Review-Priority +2 so ill review this today | 17:23 |
sean-k-mooney | bauzas: melwitt do we want to continue talking about ephemeral | 17:23 |
gibi | you can ping me tomorrow to review it | 17:23 |
* bauzas sends hugs to the 191 merge conflicts :) | 17:23 | |
stephenfin | gibi: will do (y) | 17:23 |
stephenfin | bauzas: They had it coming | 17:24 |
melwitt | stephenfin: ok, I'll help review if gibi or sean-k-mooney end up not being able to for some reason | 17:24 |
* sean-k-mooney wishes i had time to blakify the codebase without chanign linelenght too | 17:24 | |
* sean-k-mooney whishes i had done the manual fixes in a seperat patch followed by the automated patch | 17:25 | |
bauzas | stephenfin: I don't see a hacking rule preventing us to import the mock lib | 17:26 |
stephenfin | bauzas: it's here. I just need to rebase it https://review.opendev.org/c/openstack/nova/+/708768 | 17:27 |
bauzas | stephenfin: so I guess you ask reviewers to make sure we don't pull that lib again ? | 17:27 |
stephenfin | I can do that now | 17:27 |
bauzas | stephenfin: ok, gtk | 17:27 |
sean-k-mooney | ack was just going to say seperate patch please | 17:27 |
gibi | I need to disappeare. see you tomorrow | 17:29 |
sean-k-mooney | gibi: o/ | 17:29 |
sean-k-mooney | bauzas: back to ephmeral if you look at https://github.com/openstack/python-openstackclient/commit/4da4b96296c6b6d4351ebd47e32d5049a88211f1#diff-6759a29d0fccaa3a8d26137549b909fa3b3925b71d5318f30fe9fe7021f8558eR1227 you will see how osc construts the bdms | 17:29 |
sean-k-mooney | for swap and ephemeral | 17:30 |
sean-k-mooney | if you pass --swap or --epmeral to the server create | 17:30 |
* bauzas when I see https://review.opendev.org/c/openstack/nova/+/714676/ => https://www.youtube.com/watch?v=JDaD2G9xjMc | 17:30 | |
bauzas | I'm just wondering whether we'll be able to merge things :D | 17:30 |
opendevreview | Kashyap Chamarthy proposed openstack/nova master: Add a workaround to skip hypervisor version check on LM https://review.opendev.org/c/openstack/nova/+/851034 | 17:31 |
sean-k-mooney | bauzas: this is perhaps better https://github.com/openstack/python-openstackclient/blob/4da4b96296c6b6d4351ebd47e32d5049a88211f1/openstackclient/tests/unit/compute/v2/test_server.py#L2734-L2785= | 17:31 |
bauzas | sean-k-mooney: about the ephemeral encryption name, I can try to propose something | 17:31 |
sean-k-mooney | sure | 17:32 |
bauzas | "local BDM encryption" | 17:32 |
sean-k-mooney | maybe | 17:32 |
sean-k-mooney | they might not alwasy be type local | 17:32 |
dansmith | that's the proposed title of the feature/spec? | 17:33 |
bauzas | dansmith: I said earlier, I'm terrible at naming | 17:33 |
bauzas | I'm just quite giving up | 17:33 |
dansmith | I think the problem is, things were named, and then we implemented lots of features that blurred all the lines we had, which makes not only the existing names less than ideal, but also makes it hard to accurately describe what we're talking about | 17:33 |
dansmith | which pretty much means there's hardly any point in a rename of anything, IMHO | 17:34 |
bauzas | this feature is about to encrypt BDMs which are local | 17:34 |
bauzas | hence the countername | 17:34 |
dansmith | "non-volume data disks" is probably the most accurate, but I mean, good lord :) | 17:34 |
sean-k-mooney | bauzas: it also works for ceph volumes allocated by nova | 17:34 |
sean-k-mooney | so local is not really right | 17:34 |
dansmith | bauzas: not always local :) | 17:34 |
sean-k-mooney | its about encypting non cinder sotrage | 17:34 |
melwitt | swap isn't included so "non-volume data disks" doesn't even work :P | 17:35 |
* bauzas has a serious headache by now, after the whole CI outage and now the massive mock change we gonna pull | 17:35 | |
sean-k-mooney | although personally i woudl have perfered if it also work for bfv | 17:35 |
sean-k-mooney | melwitt: very true | 17:35 |
dansmith | melwitt: but swap isn't encrypted right? that's why I put "data" in there :) | 17:35 |
sean-k-mooney | dansmith: what would the flavor extra specs be for that | 17:36 |
melwitt | ephemeral_and_root_disk_encryption 😂 | 17:36 |
dansmith | nvdd_encryption=FML | 17:36 |
melwitt | dansmith: oh, I see. yeah swap is not encrypted | 17:36 |
melwitt | I didn't get the "data" emphasis | 17:36 |
sean-k-mooney | honestly i prefer that name to what we have | 17:36 |
sean-k-mooney | too bad we cant just call it nova_disk_encryption | 17:37 |
sean-k-mooney | i.e. encyuption for stuff nova owns | 17:37 |
dansmith | non-volume is the key I think, but it's not very nice to say/write | 17:38 |
sean-k-mooney | ya | 17:38 |
sean-k-mooney | flavor_disk_encryption? | 17:39 |
sean-k-mooney | but no | 17:39 |
sean-k-mooney | that break for bfv | 17:39 |
sean-k-mooney | well sort of | 17:39 |
melwitt | and swap | 17:39 |
dansmith | the argument here is about the naming of the extra spec? | 17:39 |
sean-k-mooney | ya swap i would honestly just add | 17:39 |
dansmith | I mean to be honest, this feels like a *massive* waste of time | 17:39 |
sean-k-mooney | dansmith: yes extra spec and image property | 17:40 |
dansmith | how about nova_disk_encryption <- excludes cinder, and if you're worried about swap, then add swap to it and move on | 17:40 |
sean-k-mooney | i would be happy with ^ | 17:40 |
bauzas | wfm | 17:41 |
sean-k-mooney | i just was not sure if we are ment to use the project name in things like this | 17:41 |
bauzas | let's just write a very good config option doc | 17:41 |
dansmith | nova_ on this case makes it clear we're talking about the things nova owns | 17:41 |
sean-k-mooney | sure and by config option doc you mean flavor validator doc | 17:41 |
dansmith | compute_ would work too I guess, but I think it's less clear | 17:41 |
sean-k-mooney | ack ya nova_ i liek more but i would be happy with compute_ | 17:42 |
sean-k-mooney | so either i think are ok | 17:42 |
dansmith | nova_ and promise to never ever discuss this again? :) | 17:42 |
bauzas | or say it 5 times in front of a mirror ? | 17:43 |
sean-k-mooney | :) | 17:43 |
sean-k-mooney | melwitt: are you ok with that? | 17:43 |
melwitt | I guess. I'm focused on making sure everyone's happy with the name. I checked https://docs.openstack.org/glance/latest/admin/useful-image-properties.html and don't find any other project names there so that feels a bit weird, but ¯\_(ツ)_/¯ | 17:45 |
bauzas | virt_disk_encryption ? | 17:45 |
dansmith | intrinsic_disk_encryption, managed_disk_encryption | 17:45 |
bauzas | damn, I stepped into the ... | 17:46 |
dansmith | virt_ is not specific enough I think, because cinder disks aren't real disks | 17:46 |
dansmith | non_volume_disk_encryption.. uglier, but no project name and more accurate | 17:46 |
dansmith | OR | 17:46 |
bauzas | oh, I was poorly refering to the fact we defer the disk creation to the underlying virt driver | 17:46 |
dansmith | we explain that "ephemeral disks" are "everything but volume disks" and then we're back to the start! | 17:46 |
melwitt | 😂 ahhhhhh | 17:47 |
sean-k-mooney | ya i still fine ephmeral kind of insulting to refer to novas storage but thats just me | 17:47 |
bauzas | (18:56:47) bauzas: if we pick something else, this has to be better understandable about what it is | 17:47 |
bauzas | (18:57:19) bauzas: yeah, if we need to write some doc explaining "ephemeral" == "this new thing" this is bad | 17:47 |
bauzas | (18:57:39) bauzas: hence the challenge | 17:47 |
dansmith | sean-k-mooney: you're fine or you "find" ? | 17:48 |
bauzas | cores, would appreciate a quick +2 on os-vif blocking https://review.opendev.org/c/openstack/nova/+/850998/2 | 17:48 |
sean-k-mooney | we have had customer go to great lents to do terible things because they found the term ephemeral unackceptable | 17:48 |
sean-k-mooney | dansmith: i find | 17:48 |
bauzas | or because they considered hostnames be FQDNs ? | 17:48 |
bauzas | sorry, this was easy | 17:49 |
sean-k-mooney | bauzas: we should not need that anymore | 17:49 |
dansmith | personally I think ephemeral is a pretty accurate name | 17:49 |
sean-k-mooney | bauzas: its blocked in upperconstraits | 17:49 |
dansmith | if they're local disks on compute nodes, then ephemeral means "they could go away if a single computer dies" | 17:49 |
sean-k-mooney | yep and so could cinder volumes | 17:49 |
dansmith | and even when they're on ceph, they're treated not nearly as precious as data volumes | 17:49 |
sean-k-mooney | dansmith: most of them dont provide ha | 17:49 |
bauzas | sean-k-mooney: we're pulling u-c on all jobs ? | 17:49 |
dansmith | sean-k-mooney: but the intent behind a volume is long-term storage generally | 17:50 |
sean-k-mooney | bauzas: we shoudl be | 17:50 |
bauzas | I thought this was only on tox targets | 17:50 |
bauzas | and not tempest | 17:50 |
sean-k-mooney | bauzas: it would be a bug if we were not | 17:50 |
melwitt | sean-k-mooney: what's the customer did something bad bc they didn't like the term? | 17:50 |
opendevreview | Stephen Finucane proposed openstack/nova master: hacking: force explicit import of python's mock https://review.opendev.org/c/openstack/nova/+/708768 | 17:50 |
sean-k-mooney | well i wont mention there name but they instead on doing pci passthough fo a raid controler intor ther vm because they did not accept novas ephmeral storage as accpetable | 17:51 |
bauzas | sean-k-mooney: I'll propose a new rev for https://review.opendev.org/c/openstack/nova/+/838976, we'll see | 17:51 |
dansmith | sean-k-mooney: but that's just because either they didn't read docs, understand, or our docs suck | 17:52 |
dansmith | and if they're making decisions based on their perception of one word without knowing what it means in context, then they probably have many other problems | 17:53 |
sean-k-mooney | dansmith: yes they messed up the server toplogy and didnt realise we did not supprot block deivce passethough other then via cinder | 17:53 |
dansmith | like thinking cinder volumes are actually burnt ashes of former disks | 17:53 |
dansmith | and nova computes explode to make new space clouds | 17:53 |
melwitt | lol @ burnt former disks | 17:55 |
sean-k-mooney | i think im to the point where i dont care anymore | 17:56 |
dansmith | well, jokes aside, I think we probably have to just pick something that won't be perfect and move on | 17:57 |
sean-k-mooney | ack | 18:02 |
sean-k-mooney | ill leave that up to melwitt | 18:03 |
sean-k-mooney | if you want to keep it as is fine if we want to make it better for some defintion of better then also fine | 18:03 |
stephenfin | bauzas: In case you didn't see, refreshed https://review.opendev.org/c/openstack/nova/+/708768 | 18:04 |
* stephenfin drops to go pick apples in the sunshine 🍎👋 | 18:05 | |
opendevreview | Eric Fried proposed openstack/nova master: hacking: force explicit import of python's mock https://review.opendev.org/c/openstack/nova/+/708768 | 18:42 |
opendevreview | Sylvain Bauza proposed openstack/nova master: Reproducer for bug 1951656 https://review.opendev.org/c/openstack/nova/+/850673 | 18:55 |
opendevreview | Sylvain Bauza proposed openstack/nova master: Handle mdev devices in libvirt 7.7+ https://review.opendev.org/c/openstack/nova/+/838976 | 18:55 |
sean-k-mooney | stephenfin: heh removing the power vm driver is one way to adress that todo | 19:11 |
sean-k-mooney | stephenfin: did we deprecate it last cycle due to the python2/3 issues | 19:11 |
opendevreview | sean mooney proposed openstack/nova master: Remove the PowerVM driver https://review.opendev.org/c/openstack/nova/+/850346 | 19:21 |
sean-k-mooney | stephenfin: just rebased that on top of the hacking change ^ i think the fucntioal test is unrelated | 19:22 |
sean-k-mooney | it was a polison failure acessing os.uname in the libvirt driver | 19:22 |
sean-k-mooney | so that is not related to thsi change i think | 19:22 |
*** hemna3 is now known as hemna | 21:14 | |
*** dasm is now known as dasm|off | 22:17 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!