| bauzas | happy spec review day everyone | 07:10 |
|---|---|---|
| opendevreview | Vladislav Belogrudov proposed openstack/nova master: Nova instance snapshot should wait for volumes https://review.opendev.org/c/openstack/nova/+/848638 | 07:18 |
| *** kopecmartin_ is now known as kopecmartin | 07:39 | |
| bauzas | cores, need a second jab on https://review.opendev.org/c/openstack/nova-specs/+/833669 | 11:39 |
| * bauzas starts to look at https://review.opendev.org/c/openstack/nova-specs/+/842015 | 11:40 | |
| gibi | bauzas: I've started checking the manila spec | 11:48 |
| sean-k-mooney | ill be switching form downstream stuff to spec review shortly | 12:02 |
| gibi | Uggla, bauzas, sean-k-mooney: I'm OK with the manila spec https://review.opendev.org/c/openstack/nova-specs/+/833669 I hold +A for sean-k-mooney to check it. | 12:13 |
| bauzas | ++ | 12:13 |
| * bauzas does bug triage now | 12:13 | |
| gibi | bauzas: did you managed to add some feedback to the ironic spec? | 12:14 |
| bauzas | gibi: not yet | 12:14 |
| Uggla | gibi, \o/ | 12:14 |
| gibi | i've just started reading it, but I have to jump on a call soon so probably finish it after | 12:14 |
| bauzas | I had to leave it given we have a meeting today and I didn't have time to look at the bugs before | 12:15 |
| gibi | ack | 12:15 |
| opendevreview | Vladislav Belogrudov proposed openstack/nova master: Nova instance snapshot should wait for volumes https://review.opendev.org/c/openstack/nova/+/848638 | 13:00 |
| *** dasm|off is now known as dasm | 13:15 | |
| ozzzo_home_ | We accidentally created a flavor without swap, and we need to add it. What will happen to VMs using that flavor if we delete and re-create the flavor with swap added? Will they still be able to restart, migrate, etc.? | 13:20 |
| ozzzo_home_ | Is changing it in the database a viable alternative? | 13:20 |
| sean-k-mooney | ozzzo_home_: yes they will however they will not have swap | 13:26 |
| sean-k-mooney | the correct thing to do woudl be to create a new flavor | 13:26 |
| sean-k-mooney | resize the existing isntnaces to that | 13:26 |
| sean-k-mooney | and then delete the old flaovr | 13:26 |
| sean-k-mooney | ozzzo_home_: when you boot a vm we copy the current flavor and embed that in the instnace_extra table | 13:27 |
| sean-k-mooney | so that we preserve the state as it was when the vm was booted | 13:27 |
| sean-k-mooney | that is imporant to make sure that chagnes such as adding swap or other changes that affect resouce usage do not propagate to the vm | 13:27 |
| sean-k-mooney | as that woudl potentially violate the current secheduling desicion and woudl invalidate the placment resouce allcoations | 13:28 |
| ozzzo_home_ | in the doc where it says " Nova has historically intentionally not included an API to update a flavor because that would be confusing for instances already created with that flavor. " - confusing means that the placement database would contain incorrect information about existing VMs using that flavor? | 13:31 |
| ozzzo_home_ | the reason we're considering changing it in the database is because we have standard flavor names, and if the flavor names change it would be a huge upheaval for customers who have that name hardcoded into their automation | 13:33 |
| ozzzo_home_ | the client won't let me create a flavor with the same name, so it seems like the alternatives are delete first and then re-create, or else change in the DB | 13:35 |
| bauzas | gibi: I'll need to leave earlier the meeting after 40 mins, could you then please chair it for the last 20 mins ? | 13:41 |
| gibi | sure | 13:42 |
| gibi | but we need you for the centos 9 stream topic | 13:42 |
| sean-k-mooney | ozzzo_home_: placement would have the correct information based on the flaovr that was used at boot | 13:43 |
| sean-k-mooney | ozzzo_home_: if you just update the flavor in the nova db you will make the nova db inconsitnet with the placment db | 13:44 |
| bauzas | gibi: yeah we'll discuss it first | 13:44 |
| gibi | ack | 13:44 |
| sean-k-mooney | ozzzo_home_: nova has no supported mechanium for changing flaovr they are read only | 13:44 |
| sean-k-mooney | ozzzo_home_: so any modifcation you do will be outside the supprot of nova | 13:45 |
| ozzzo_home_ | sean-k-mooney: How can I explain to my co-workers why changing it in the DB is a bad idea? What would be the customer-facing consequences of DB inconsistency? | 13:45 |
| sean-k-mooney | well if you update just the flavor the existing vms would not user any swap | 13:45 |
| sean-k-mooney | but new vms would | 13:45 |
| sean-k-mooney | if you also updated the existing vms embeded flavor copy you woudl break the resouce usage view tracked in palcment | 13:46 |
| sean-k-mooney | which means you could have scheuling issues in the future as you might run out of disk space | 13:46 |
| sean-k-mooney | since the vms will be using more disk for swap | 13:46 |
| sean-k-mooney | if you also fix the placment allcoations then it would work but you have then doen two highly error prone operations on two differnt dbs | 13:47 |
| ozzzo_home_ | What if we delete the flavor first and then create a new one with the same name. Will that cause the same problem? | 13:47 |
| sean-k-mooney | it will have no affect on exsitng vms | 13:47 |
| sean-k-mooney | but new vms will use the new resouces specified in teh flavor | 13:48 |
| sean-k-mooney | if any of your custoemr were using the falvor uuid | 13:48 |
| sean-k-mooney | it will break | 13:48 |
| sean-k-mooney | if they just use the name it would use the new flavor | 13:48 |
| sean-k-mooney | ozzzo_home_: if you updated the flavor in the db and updated the embded flavor in the instnace_extra table and upded the embeded flavor in the request spec then a cold migrate would fix the plamcent allcoaitons | 13:49 |
| sean-k-mooney | and result in the vms beign allcoted swap on the destination host | 13:49 |
| sean-k-mooney | but that is not tested or supported upstream | 13:49 |
| sean-k-mooney | if you understand what you are doing it can be done but its error prone | 13:50 |
| sean-k-mooney | which is why we would advise a resize to a new flavor | 13:50 |
| sean-k-mooney | gibi: bauzas i see ye are both +2 on the manila share spec with comments. ill review that shortly and +w if everything looks ok | 13:53 |
| bauzas | ++ | 13:53 |
| sean-k-mooney | am ill see in a second but am i right to assume those comments can be adressed in a followup | 13:53 |
| gibi | sean-k-mooney: ack | 13:58 |
| ozzzo_home_ | thank you sean-k-mooney | 14:09 |
| gibi | I left comment in the ironic rebalance spec. I don't feel we will have consensus today around it | 14:33 |
| gibi | I have to step out for an hour I will be back for the nova meeting | 14:39 |
| bauzas | reminder: nova meeting in 29 mins | 15:31 |
| * gibi is back | 15:45 | |
| Uggla | bauzas, like last time I could not probably join right at the beginning, but I will join ASAP. | 15:46 |
| bauzas | oki doki | 15:46 |
| sean-k-mooney | Uggla: bauzas gibi i have one point that i think shoudl be fixed | 15:52 |
| bauzas | ? | 15:52 |
| sean-k-mooney | but its minor | 15:52 |
| sean-k-mooney | let me push my review one sec | 15:53 |
| sean-k-mooney | basically in the api request for share we shoudl reserver "tag" for device role tagging and use mount_tag for the mount_tag for the share | 15:53 |
| sean-k-mooney | also i tought we had aggreed to include implemnting the device role tagging supprot in this api but i did not see that in the spec | 15:54 |
| sean-k-mooney | we do cover updating the metdata to make the mount_tag and share id discoverable | 15:55 |
| sean-k-mooney | but we are overloading teh same field for both | 15:56 |
| gibi | when would it make sense to set the tag and mount_tag to different values? | 15:56 |
| sean-k-mooney | im not sure we want to overload tag for both the mount tag and the metadata deivce_role tag | 15:56 |
| sean-k-mooney | gibi: well concpetully the server very differnt functions | 15:57 |
| sean-k-mooney | so i would not generally assume they shoudl be the same | 15:57 |
| sean-k-mooney | the tag in device role taging terms is ment to map to a high level concpet | 15:58 |
| gibi | I though device tag is there so that the guest can match the device it sees and the device it requested from openstack | 15:58 |
| sean-k-mooney | like database or backup | 15:58 |
| sean-k-mooney | where as the mount_tag is a low level detail fo the virtio-fs protocol | 15:59 |
| sean-k-mooney | if we supported soemthign other then virtio-fs for manilla shares that detail might change | 15:59 |
| bauzas | warning : nova meeting starting soon | 15:59 |
| gibi | sean-k-mooney: table this to the end of the meeting | 15:59 |
| sean-k-mooney | ack | 15:59 |
| bauzas | #startmeeting nova | 16:00 |
| opendevmeet | Meeting started Tue Jul 5 16:00:01 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 | sean-k-mooney: sorry had to start the meeting | 16:00 |
| bauzas | hello 'veryone | 16:00 |
| gibi | o/ | 16:00 |
| elodilles | o/ | 16:01 |
| bauzas | as I said to gibi, I'll need to leave in 40 mins | 16:01 |
| bauzas | so, I'll leave the chair to gibi | 16:01 |
| bauzas | #chair gibi | 16:01 |
| opendevmeet | Current chairs: bauzas gibi | 16:01 |
| bauzas | maybe we should start | 16:02 |
| bauzas | #topic Bugs (stuck/critical) | 16:02 |
| bauzas | #info One Critical bug | 16:02 |
| bauzas | #link https://bugs.launchpad.net/nova/+bug/1979047 Centos 9 Stream bug failure | 16:03 |
| bauzas | that being said, the root cause seems to be fixed on C9S | 16:03 |
| bauzas | now, we have a revert from gibi | 16:03 |
| bauzas | #link https://review.opendev.org/c/openstack/nova/+/848352 revert of the n-v job patch | 16:03 |
| bauzas | for making the C9S job voting again | 16:03 |
| bauzas | that being said, I have a concern I'd like to discuss with the team | 16:04 |
| bauzas | https://bugzilla.redhat.com/show_bug.cgi?id=2092856 is the C9S BZ | 16:04 |
| bauzas | if you look at it, it took about 3 weeks in order to be fixed | 16:05 |
| bauzas | and released | 16:05 |
| bauzas | now, my concern is about the job | 16:05 |
| bauzas | given now Centos9 is a stream, that means that we can't just merge a fix without verifying it | 16:06 |
| bauzas | we = RHEL team | 16:06 |
| bauzas | so, here my concern : instead of voting again, should this job be a periodic-weekly one ? | 16:07 |
| sean-k-mooney | well technially the centos core team could but rhel team will want it to go though qe first | 16:07 |
| sean-k-mooney | im +1 on moving to periodic-weekly | 16:07 |
| sean-k-mooney | i orginally did not want it to be voting this cycle | 16:08 |
| bauzas | if we agree on it, I propose to look at the job by every week during our meeting, like we do for both placement and nova-emulation | 16:08 |
| gibi | if we promise to look at it as part of our weekly agenda then I'm OK to move it to periodic | 16:08 |
| sean-k-mooney | when i raised the topic at the ptg it was for ti to be nonvoting until at least m2 | 16:08 |
| bauzas | ok, any other thoughts ? | 16:08 |
| gibi | this way we can detect breaking changes, but probably we wont detect race coditions, as there wont be enough runs for it | 16:08 |
| bauzas | gibi: yeah | 16:09 |
| sean-k-mooney | we can also put it in experimental | 16:09 |
| sean-k-mooney | so we can trigger if we need too | 16:09 |
| sean-k-mooney | but that runs more then we would like | 16:09 |
| bauzas | gibi: what I'd also like is to find some C9S folks we could be pinging if we find an issue | 16:09 |
| elodilles | sounds OK to be a periodic-weekly, we even free up some resource with that, right? | 16:09 |
| sean-k-mooney | its too bad we can trigger periodics via a comment | 16:09 |
| sean-k-mooney | elodilles: yes since it wont be per patch | 16:09 |
| sean-k-mooney | but we can still review it regurally | 16:10 |
| elodilles | ++ | 16:10 |
| bauzas | sean-k-mooney: yeah we could also have a experimental job if we want | 16:10 |
| sean-k-mooney | if its perodic-weekly we might even be able to add more variants in the futre | 16:10 |
| gibi | I'm fine loosing the race condition detection, so I'm OK to move it to periodic | 16:10 |
| bauzas | ok, I don't see any argue | 16:11 |
| bauzas | so... | 16:11 |
| bauzas | #agreed moving the centos9s job to be a periodic-weekly job instead of voting for every change | 16:11 |
| bauzas | #agreed bauzas to add this periodic job to our weekly meeting topic for the gate | 16:12 |
| bauzas | #agreed we could add this job to the experimental pipeline | 16:12 |
| bauzas | folks, ok ? | 16:12 |
| bauzas | thanks gibi, sean-k-mooney and elodilles for your thoughts | 16:12 |
| sean-k-mooney | its ok with me to move on | 16:13 |
| gibi | let move on | 16:13 |
| bauzas | k | 16:13 |
| bauzas | #link https://bugs.launchpad.net/nova/+bugs?search=Search&field.status=New 10 new untriaged bugs (+2 since the last meeting) | 16:13 |
| bauzas | eventually we only had 8 bugs last week :( | 16:13 |
| bauzas | but eventually this week we had a lof of new ones | 16:13 |
| bauzas | #link https://etherpad.opendev.org/p/nova-bug-triage-20220628 | 16:14 |
| bauzas | #link https://etherpad.opendev.org/p/nova-bug-triage-20220621 | 16:14 |
| bauzas | if people want, they can look at what I triaged | 16:14 |
| bauzas | but I don't want to discuss one of them by now | 16:15 |
| bauzas | #link https://storyboard.openstack.org/#!/project/openstack/placement 27 open stories (+0 since the last meeting) in Storyboard for Placement | 16:15 |
| bauzas | #info Add yourself in the team bug roster if you want to help https://etherpad.opendev.org/p/nova-bug-triage-roster | 16:15 |
| bauzas | so, the next folk in the roster is artom | 16:15 |
| bauzas | artom: can you be the next bug baton owner, or anyone else ? | 16:16 |
| bauzas | mmm, looks like artom isn't around | 16:17 |
| sean-k-mooney | that means we can give them more work to do right | 16:17 |
| gibi | right :) | 16:18 |
| bauzas | hah | 16:18 |
| gibi | he had on PTO last week so he is well prepared ;) | 16:18 |
| bauzas | I triaged for two weeks | 16:18 |
| bauzas | I paid my duty :D | 16:18 |
| elodilles | i'm not that efficient as others, and probably will be afk 1 day, but can try to have the baton | 16:18 |
| bauzas | (well, actually I triaged every Yoga week, until gibi told we should have a triage team :) ) | 16:19 |
| gibi | I think we can convice artom to take it :) | 16:19 |
| elodilles | gibi: that also works for me :) | 16:19 |
| gibi | he is just probably busy with someting else right now | 16:19 |
| bauzas | let me gently force artom to get the baton :) | 16:19 |
| bauzas | not in a passive aggressive way | 16:19 |
| gibi | lets but it on artom tentatively and we can re-think if he rejects it | 16:19 |
| bauzas | but rather talking with him in French | 16:19 |
| bauzas | cool | 16:20 |
| bauzas | #info Next bug baton is passed to artom | 16:20 |
| bauzas | moving on | 16:20 |
| bauzas | #topic Gate status | 16:20 |
| bauzas | #link https://bugs.launchpad.net/nova/+bugs?field.tag=gate-failure Nova gate bugs | 16:21 |
| bauzas | #link https://zuul.openstack.org/builds?project=openstack%2Fplacement&pipeline=periodic-weekly Placement periodic job status | 16:21 |
| bauzas | #link https://zuul.opendev.org/t/openstack/builds?job_name=nova-emulation&pipeline=periodic-weekly&skip=0 Emulation periodic job runs | 16:21 |
| bauzas | both weekly jobs run fine | 16:21 |
| * dansmith stumbles in late | 16:21 | |
| bauzas | #info Please look at the gate failures and file a bug report with the gate-failure tag. | 16:22 |
| bauzas | #info STOP DOING BLIND RECHECKS aka. 'recheck' https://docs.openstack.org/project-team-guide/testing.html#how-to-handle-test-failures | 16:22 |
| bauzas | oh, I forgot to add in the agenda | 16:22 |
| bauzas | we have numbers | 16:22 |
| bauzas | #link https://lists.openstack.org/pipermail/openstack-discuss/2022-July/029363.html | 16:22 |
| bauzas | #undo | 16:23 |
| opendevmeet | Removing item from minutes: #link https://lists.openstack.org/pipermail/openstack-discuss/2022-July/029363.html | 16:23 |
| sean-k-mooney | ya nova was not too bad but there are still some | 16:23 |
| bauzas | #link https://lists.openstack.org/pipermail/openstack-discuss/2022-June/029342.html | 16:23 |
| bauzas | #info 57.75% of rechecks were without a reason, please refrain this wrong behaviour | 16:24 |
| dansmith | ++ | 16:24 |
| bauzas | moving on | 16:24 |
| bauzas | #topic Release Planning | 16:24 |
| bauzas | #link https://releases.openstack.org/zed/schedule.html | 16:25 |
| bauzas | #info Zed-2 is in 1.5 weeks | 16:25 |
| bauzas | #info Spec review day today | 16:25 |
| bauzas | well, this was actually a quiet review day | 16:25 |
| bauzas | only 3 specs are currently open to reviews | 16:25 |
| dansmith | I spent a lot of time on the ironic one, | 16:25 |
| bauzas | dansmith: appreciated a lot | 16:25 |
| dansmith | although I'm not sure I'd even call it a spec | 16:25 |
| gibi | yeah the ironic one is the hard piece | 16:25 |
| bauzas | dansmith: I tried to look at it and then I had to stop b/c I had to do bug triage | 16:26 |
| bauzas | dansmith: we basically agreed on the fact this isn't purely a spec | 16:26 |
| dansmith | it's really just brainstorming, so has nothing to do with the spec deadline, IMHO | 16:26 |
| bauzas | it's a document trying to identify all the corner cases about the proposed implementation | 16:26 |
| gibi | depending on an agreed solution we might need a real spec :) | 16:26 |
| bauzas | dansmith: agreed | 16:26 |
| bauzas | on the existing document | 16:26 |
| gibi | but agreed to brainstorm first | 16:26 |
| bauzas | I don't feel it's constrained by the spec approval freeze | 16:27 |
| sean-k-mooney | yep i have not looked at it in a while but its on my todo list at the end | 16:27 |
| sean-k-mooney | after the rest | 16:27 |
| bauzas | but yeah, as gibi said, depending on the consensus we may achieve, this would require some design stage. Or not. | 16:27 |
| dansmith | anything we do would need a spec I'm quite sure, | 16:27 |
| dansmith | I'm just saying, there's no reason to spend time reviewing it instead of other specs before the deadline | 16:28 |
| bauzas | I'll make clear on the gerrit change this one isn't impacted by our deadlines | 16:28 |
| dansmith | I didn't really realize that until it was too late for me, but SAVE YOURSELVES | 16:28 |
| dansmith | :P | 16:28 |
| bauzas | dansmith: honestly, besides this one which is hairy, we only have two opens | 16:28 |
| bauzas | one is about to be merged | 16:28 |
| dansmith | I threw a -1 on it for visibility since all the others were just +0 comments | 16:28 |
| bauzas | and the other one potentially misses resources to work one | 16:28 |
| bauzas | on* | 16:28 |
| dansmith | cool | 16:28 |
| bauzas | so I just feel we can spend brain cycles on the rebalance issue | 16:29 |
| dansmith | ack | 16:29 |
| sean-k-mooney | since it was a braninstromign doc i just didn nto +/- since it did not have any singel proposal | 16:29 |
| bauzas | sean-k-mooney: I'll clarify the purpose of this document in a gerrit comment | 16:29 |
| sean-k-mooney | but yes ack on the -1 | 16:29 |
| dansmith | sean-k-mooney: yeah and that's fair, but someone could stumble in thinking it was needing review before the deadline with no other signaling :D | 16:30 |
| bauzas | I'll send the signal | 16:30 |
| dansmith | ++ | 16:30 |
| bauzas | ideally, I asked CERN folks to jab into it | 16:30 |
| bauzas | but, this is just an ask | 16:31 |
| bauzas | they're impacted by the rebalancing issue as they don't use the ironic feature | 16:31 |
| sean-k-mooney | so in terms of other specs | 16:31 |
| bauzas | so I'd also like to understand whether we could have a mitigation | 16:31 |
| sean-k-mooney | im expecting artom to update theres later this week | 16:31 |
| sean-k-mooney | and ill try and updte teh power managment one | 16:32 |
| sean-k-mooney | but im aware both are late | 16:32 |
| sean-k-mooney | and may slip | 16:32 |
| bauzas | sean-k-mooney: I left a comment on artom's spec, there could be effort to spend on the EC2 compatible API | 16:32 |
| sean-k-mooney | well ok but im not sure we care about ec2 compat | 16:32 |
| bauzas | sean-k-mooney: maybe, but the spec was saying we were given ec2 compat for free | 16:33 |
| bauzas | which isn't true | 16:33 |
| sean-k-mooney | ack | 16:33 |
| bauzas | for the power management spec, you still have one week to push it | 16:33 |
| bauzas | given we lack of open specs, I could be able to quickly jump into it | 16:33 |
| sean-k-mooney | main issue is reloading context i have not worked on it since febuary | 16:33 |
| bauzas | me too | 16:34 |
| bauzas | but, given Berlin, I think this would be a net win to have it in Nova | 16:34 |
| sean-k-mooney | Uggla's spec i think is close it have one issue with it but it could be adressed in a followup | 16:34 |
| bauzas | cool | 16:34 |
| bauzas | let's wrap on the spec discussion | 16:34 |
| bauzas | I'll need to leave the chair soon | 16:34 |
| bauzas | and we can follow up tomorrow | 16:34 |
| bauzas | #topic Review priorities | 16:35 |
| 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:35 |
| bauzas | #link https://review.opendev.org/c/openstack/project-config/+/837595 Gerrit policy for Review-prio contributors flag. Waiting for approval | 16:35 |
| bauzas | we should ping the project-config cores | 16:35 |
| bauzas | #link https://docs.openstack.org/nova/latest/contributor/process.html#what-the-review-priority-label-in-gerrit-are-use-for Documentation we already have | 16:36 |
| sean-k-mooney | i can do that after the meeting | 16:36 |
| bauzas | thanks | 16:36 |
| bauzas | #topic Stable Branches | 16:36 |
| bauzas | elodilles: your time | 16:36 |
| elodilles | #info stable nova releases are out: yoga (25.0.1), xena (24.1.1) and wallaby (24.1.1) | 16:36 |
| elodilles | #info stable/train is blocked, fix exists but hasn't merged yet due to intermittent failures | 16:36 |
| elodilles | #info stable branch status / gate failures tracking etherpad: https://etherpad.opendev.org/p/nova-stable-branch-ci | 16:37 |
| elodilles | that's it, to be quick | 16:37 |
| bauzas | thanks | 16:37 |
| bauzas | elodilles: as again, don't be afraid of pinging me for reviews | 16:38 |
| bauzas | #topic Open discussion | 16:38 |
| bauzas | (bauzas) Team Sign-up for the next PTG | 16:38 |
| bauzas | so, official ask | 16:38 |
| gibi | yes please | 16:38 |
| gibi | :) | 16:38 |
| bauzas | should we have a PTG room ? | 16:38 |
| bauzas | which would be physical this time ? | 16:38 |
| bauzas | :) | 16:38 |
| gibi | can we have a window on the room? :) | 16:38 |
| bauzas | I don't know the logistics yet | 16:38 |
| bauzas | I can imagine the Foundation asking the teams to be agile and proposing some remote live connection | 16:39 |
| sean-k-mooney | i would be happy with one in dark basment if it has white bords | 16:39 |
| sean-k-mooney | yes if we have an ok netowrk | 16:40 |
| bauzas | there is a remarks/feedback field in the survey | 16:40 |
| sean-k-mooney | we can likely have a remote stream too | 16:40 |
| bauzas | https://openinfrafoundation.formstack.com/forms/oct2022_ptg_team_signup | 16:40 |
| bauzas | I'll fill it up | 16:40 |
| bauzas | but I could mention those two things | 16:40 |
| gibi | to stream it we need mics and optional a camera | 16:40 |
| sean-k-mooney | yep neutron have done that in the past | 16:40 |
| bauzas | yeah and everytime we tried, this was a hard experience | 16:40 |
| bauzas | I'll leave some notes | 16:41 |
| bauzas | that's it for me, I need to leave | 16:41 |
| gibi | bauzas: o/ | 16:41 |
| gibi | so we have one more thing on the agenda | 16:41 |
| sean-k-mooney | it works fine for neutron as far as i can tell but they more have the stream so people can listen and then respond via etherpath/irc | 16:41 |
| bauzas | I have another item to discuss but let's punt it for next week | 16:41 |
| gibi | (bauzas) Opportunities for low-hanging-fruits, anyone ? (only if we have time left) | 16:41 |
| gibi | ahh OK | 16:41 |
| gibi | then it is punted | 16:41 |
| bauzas | thanks | 16:41 |
| * bauzas rushes off | 16:41 | |
| gibi | does anyone here has an extra topic for today? | 16:41 |
| bauzas | gibi: feel free to wrap the meeting | 16:41 |
| gibi | bauzas: will do | 16:42 |
| bauzas | ++ | 16:42 |
| sean-k-mooney | not really but i will think about low haning fruit for the next one | 16:42 |
| gibi | OK, so if nothing else today then I will close the meeting | 16:42 |
| gibi | thanks for all joining | 16:42 |
| gibi | #endmeeting | 16:42 |
| opendevmeet | Meeting ended Tue Jul 5 16:42:58 2022 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 16:42 |
| opendevmeet | Minutes: https://meetings.opendev.org/meetings/nova/2022/nova.2022-07-05-16.00.html | 16:42 |
| opendevmeet | Minutes (text): https://meetings.opendev.org/meetings/nova/2022/nova.2022-07-05-16.00.txt | 16:42 |
| opendevmeet | Log: https://meetings.opendev.org/meetings/nova/2022/nova.2022-07-05-16.00.log.html | 16:42 |
| gibi | sean-k-mooney: so we can go back to the tag, mount_tag question | 16:43 |
| sean-k-mooney | sure | 16:43 |
| sean-k-mooney | i updated my comment with my resoning in the review | 16:43 |
| gibi | I'm cheking... | 16:43 |
| sean-k-mooney | https://review.opendev.org/c/openstack/nova-specs/+/833669/10/specs/zed/approved/libvirt-virtiofs-attach-manila-shares.rst#365= | 16:43 |
| sean-k-mooney | my concern is basically if we change the backend mechanium in the future or a differnt virt driver wants to support this | 16:44 |
| sean-k-mooney | im not sure we want to overload tag | 16:44 |
| sean-k-mooney | if you and bauzas are ok with that we can proceed as is and it can always be changed in a microversion later | 16:45 |
| sean-k-mooney | so it might be premature optimisation for a case we will never support | 16:46 |
| Uggla | sean-k-mooney, I can still change it | 16:46 |
| sean-k-mooney | Uggla: if we argree to change it what i propose is i +w the spec as it is and you can adress it and other nits in a follow up patch | 16:46 |
| Uggla | it is just a matter of renaming from tag to mount_tag (sorry I read it really fast so far). | 16:47 |
| sean-k-mooney | Uggla: well renaming but also keeping tag | 16:47 |
| gibi | sean-k-mooney: replied | 16:48 |
| sean-k-mooney | tag would be optional and used for device role tagging and mount_tag would be used to configure the mount | 16:48 |
| gibi | so my point is to use 'tag' for device tagging, and document that libvirt with virtio_fs automatically use this tag also for mount_tag | 16:49 |
| gibi | as I don't see why would the user want to set two tags | 16:49 |
| gibi | one device tag and one mount_tag to different value | 16:49 |
| Uggla | sean-k-mooney, so adding 1 more field. I guess that's ok to do it. Doing it right now will avoid db migration. | 16:50 |
| sean-k-mooney | gibi: the only concern i have with that is the high level device role tag is normally optional | 16:51 |
| gibi | can we generate the mount tag from the manial share uuid? | 16:51 |
| gibi | if it is not provided? | 16:51 |
| sean-k-mooney | where as the mount_tag woudl be required unless we default to the manila share id so i guess thats ok | 16:51 |
| sean-k-mooney | gibi: that depned on the lenght requriement for ti at teh virtio fs level | 16:52 |
| sean-k-mooney | but a uuid is 36charters long | 16:52 |
| sean-k-mooney | that shoudl be ok | 16:52 |
| gibi | as we have a single device tag per device I think it is use to identify the device, also mount_tag is used to identify the share in the guest, so I don't think we need two divergent identity for a single device | 16:52 |
| sean-k-mooney | i think we said it woudl be 64 | 16:52 |
| sean-k-mooney | ok you have convinced me that im either over thinking it or that we can adress it in the future with a microverion if needed | 16:53 |
| sean-k-mooney | so let go with just tag as optional today and default to the manila share id which is what the spec says | 16:53 |
| Uggla | sean-k-mooney, \o/ | 16:54 |
| gibi | sean-k-mooney: thanks | 16:55 |
| sean-k-mooney | gibi: i also agree with your clarification regarding attach/error | 16:56 |
| sean-k-mooney | anyway i have send it to hte gate but we likely should do a followup for the nits | 16:56 |
| gibi | ack, that is just a nit | 16:56 |
| gibi | agree to do just a follow up | 16:56 |
| sean-k-mooney | gibi: should we abandon https://review.opendev.org/c/openstack/nova-specs/+/802034 and of abanon it a m2 | 16:58 |
| sean-k-mooney | Migrate Instance Between Projects | 16:58 |
| sean-k-mooney | it has not been updated since yoga | 16:59 |
| sean-k-mooney | if we were to porceed with it im usre we would need a lot of work that wont happne in zed | 16:59 |
| gibi | I think we should abandon all the old open specs at m2 | 16:59 |
| sean-k-mooney | i guess there is no harm in leaving it till then ya | 17:00 |
| gibi | I think I suggested this to bauzas before | 17:00 |
| gibi | it can always be restored but it cleanes up gerrit | 17:00 |
| gibi | I have to drop now. see you tomorrow o/ | 17:00 |
| sean-k-mooney | o/ | 17:01 |
| opendevreview | Merged openstack/nova-specs master: libvirt: Allow Manila shares to be directly attached to instances https://review.opendev.org/c/openstack/nova-specs/+/833669 | 17:10 |
| sean-k-mooney | Uggla:^ | 17:16 |
| *** dasm is now known as dasm|off | 22:02 | |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!