| opendevreview | Mohammed Naser proposed openstack/nova master: Fix race condition in _get_pci_passthrough_devices https://review.opendev.org/c/openstack/nova/+/840993 | 00:14 |
|---|---|---|
| opendevreview | Takashi Kajinami proposed openstack/osc-placement master: Remove six https://review.opendev.org/c/openstack/osc-placement/+/841181 | 00:18 |
| opendevreview | Jorhson Deng proposed openstack/nova master: Clear the ignore_hosts before starting evacuate https://review.opendev.org/c/openstack/nova/+/841089 | 01:03 |
| opendevreview | melanie witt proposed openstack/placement stable/ussuri: Use 'functional-without-sample-db-tests' tox env for placement nova job https://review.opendev.org/c/openstack/placement/+/840773 | 05:34 |
| opendevreview | melanie witt proposed openstack/placement stable/ussuri: placement-status: check only consumers in allocation table https://review.opendev.org/c/openstack/placement/+/840703 | 05:34 |
| Uggla | Hello nova o/ | 07:39 |
| gibi | Uggla: o/ | 07:41 |
| gibi | happy spec review day :) | 07:41 |
| sean-k-mooney | ah yes | 08:14 |
| sean-k-mooney | well i guess i know what im doing today then | 08:14 |
| bauzas | gibi: indeed, thanks for explaining it | 08:14 |
| bauzas | starting out loud with https://review.opendev.org/c/openstack/nova-specs/+/840217 for people | 08:16 |
| sean-k-mooney | opened in a tab ill get to it after i do a pass on the pci spec and the manilla shares spec. | 08:17 |
| sean-k-mooney | just an fyi for people my arbiter spec need a respin with some largeish changes so you can ignore it for now. i might push it back up later today | 08:18 |
| opendevreview | Jorhson Deng proposed openstack/nova master: Clear the ignore_hosts before starting evacuate https://review.opendev.org/c/openstack/nova/+/841089 | 08:18 |
| * bauzas looks at https://review.opendev.org/c/openstack/nova-specs/+/831506/2..3/specs/zed/approved/unshelve-to-host.rst | 08:23 | |
| bauzas | Uggla: I'm afraid that unshelve modifies the RequestSpec.az field :( | 08:24 |
| bauzas | it shouldn't I think | 08:24 |
| bauzas | but this is a bug | 08:24 |
| bauzas | not your spec | 08:24 |
| Uggla | bauzas, hum no from what I checked it seems the behavior is fine. Or I may miss what you mean. | 08:26 |
| Uggla | I had some tests here maybe it will clarify: https://review.opendev.org/c/openstack/nova/+/831507/7/nova/tests/functional/test_availability_zones.py | 08:29 |
| Uggla | bauzas, BTW I added tests to unshelve to an az that were missing. | 08:30 |
| bauzas | Uggla: added my comments | 08:32 |
| bauzas | now, I see why a lof of our customers prefer unshelve... | 08:33 |
| bauzas | because of the open bug | 08:33 |
| bauzas | I'm saying this is a bug, as this *shouldn't* | 08:33 |
| bauzas | be possible to move an instance out of AZ1 if the user asked AZ1 when creating the instance | 08:33 |
| bauzas | as a reminder, availability zones are seen by end users | 08:34 |
| bauzas | Uggla: sean-k-mooney: for example, say I'm a enduser and I want to create an instance in some OVH SBG4 AZ :) | 08:35 |
| bauzas | (where only hosts within the SBG4 datacenter are within this AZ) | 08:36 |
| bauzas | then, I see some problems with SBG4 | 08:36 |
| sean-k-mooney | bauzas: unshelve intentionally allwos you to chagne AZ | 08:36 |
| bauzas | but magically, now I look at my instance and I see it in RBX1 | 08:37 |
| bauzas | I wonder why | 08:37 |
| sean-k-mooney | unshleve wont change az by default | 08:37 |
| sean-k-mooney | it only change az if you specify an az | 08:37 |
| bauzas | sean-k-mooney: I don't see why this is intentional | 08:37 |
| bauzas | this is rather a bug | 08:37 |
| sean-k-mooney | no its not | 08:37 |
| sean-k-mooney | its deffinelty a feature | 08:37 |
| bauzas | I strongly disagree | 08:37 |
| bauzas | I know customers use it | 08:38 |
| bauzas | because of this bug | 08:38 |
| bauzas | but I dislike this behaviour because it tramples our endusers | 08:38 |
| sean-k-mooney | unshelve is the only operation that is safe to use to move between azs | 08:38 |
| sean-k-mooney | bauzas: rembere that unshelve is an end user operation not an admin one | 08:38 |
| bauzas | unshelve was created by Rackspace | 08:38 |
| sean-k-mooney | so its the same use that spefifed it on but and unshelve | 08:38 |
| bauzas | correct | 08:38 |
| bauzas | but originally we just offloaded resources with keeping quotas | 08:39 |
| sean-k-mooney | so they know there constratits and are able to determin if they want to move between azs | 08:39 |
| bauzas | as this was a public cloud need | 08:39 |
| sean-k-mooney | bauzas: yes and then later we extended the api to add unshleve to AZ | 08:39 |
| bauzas | as a public cloud, they wanted their endusers to keep their quotas | 08:39 |
| bauzas | sean-k-mooney: that's when we confused things | 08:39 |
| sean-k-mooney | we did it because operatores and customers wanted a way to move vms between regions/az | 08:40 |
| bauzas | take the SBG and RBX datacenter examples | 08:40 |
| sean-k-mooney | e.g. form dev to prod | 08:40 |
| bauzas | sean-k-mooney: when we accepted this, we did put the users under the bus | 08:40 |
| sean-k-mooney | no we dont | 08:40 |
| sean-k-mooney | that woudl only be an issue if and only if we have cinder voluems and dont allow cross az attach | 08:41 |
| sean-k-mooney | in which case it will fail to unshelve | 08:41 |
| bauzas | we change what end users see | 08:41 |
| sean-k-mooney | at there request | 08:41 |
| sean-k-mooney | its ok to change what az they see if they explictly ask you to change that | 08:42 |
| bauzas | and we changed what they originally requested | 08:42 |
| sean-k-mooney | yes because they ask us too | 08:42 |
| sean-k-mooney | for unshelve to host we have 3 options | 08:42 |
| sean-k-mooney | 1 make it an error if the az of the host does not match the current az | 08:42 |
| sean-k-mooney | 2 allow both az an host to be passed and ensure the host is in the az that is pass but allow the az to change | 08:43 |
| sean-k-mooney | 3 accpet az or host mutlally exclusivly and implictly update the az if the host is in a different az | 08:43 |
| sean-k-mooney | the spec currelty sates option 3 | 08:43 |
| sean-k-mooney | gibi: ^ this is the az issue i mentioned yesterday by the way | 08:44 |
| gibi | yepp, so I'm OK with option 3 | 08:44 |
| sean-k-mooney | bauzas: all 3 of those behavior are valid i woudl argue that 1 is rather unfrendly ux 2 and 3 are actully my preference | 08:44 |
| bauzas | sean-k-mooney: problem with option 3 is that we're changing the constraints | 08:45 |
| bauzas | sean-k-mooney: correct me if I'm wrong | 08:45 |
| bauzas | , | 08:45 |
| bauzas | user created inst1 with 'sbg4' az | 08:46 |
| bauzas | sbg4 went on fire | 08:46 |
| bauzas | (or rather bad example | 08:46 |
| bauzas | user shelved inst1 | 08:46 |
| bauzas | now, op wants inst1 in hostB which is on rbx1 AZ | 08:47 |
| bauzas | he will unshelve to hostB | 08:47 |
| bauzas | inst1 will now have requestspec.az to be None | 08:47 |
| bauzas | which means that inst1 could be later moved to any AZ, including rbx2 for example | 08:48 |
| bauzas | that's the problem I see | 08:48 |
| kashyap | Can anyone please post the output of this in a pastebin? | 08:50 |
| kashyap | virsh domcapabilities | xmllint --xpath "//cpu/mode[@name='host-model']" - | 08:50 |
| sean-k-mooney | bauzas: yep you miss understand what we are proposing | 08:50 |
| kashyap | (I'm assuming your host is not a Leonov T470s) | 08:50 |
| bauzas | sean-k-mooney: perhaps, I need to understand then more your point | 08:50 |
| Uggla | bauzas, I think so as well. But specifying the az in a unshelve to host request spec may fix this problem but I have not tested it yet. | 08:50 |
| sean-k-mooney | bauzas: when we change az the requestspec.az will be set to rbx1 if and only if the requestspec.az was previously not None | 08:51 |
| bauzas | sean-k-mooney: then this is a breaking change too | 08:51 |
| sean-k-mooney | bauzas: that what we do with unshleve pasing an az | 08:51 |
| bauzas | sean-k-mooney: if ReqSpec.az was None before, instance was able to float across AZs | 08:51 |
| sean-k-mooney | bauzas: right so we only upsate requestspec.az if it was not None | 08:52 |
| gibi | kashyap: https://paste.opendev.org/show/bxPqOPQm7kvKqNhDcdp6/ | 08:52 |
| bauzas | I'm confused | 08:52 |
| sean-k-mooney | if its None we leave it none | 08:52 |
| sean-k-mooney | bauzas: ok maybe we need a worked example in the spec. | 08:52 |
| sean-k-mooney | let me create an etherpad quickly and add one | 08:53 |
| bauzas | sean-k-mooney: there are only two cases we need to consider | 08:53 |
| sean-k-mooney | https://etherpad.opendev.org/p/unshelve-to-host | 08:53 |
| bauzas | 1/ reqspec.az was nonez | 08:53 |
| kashyap | gibi: Thank you! (I'm curious, what is your host?) | 08:53 |
| bauzas | 2/ reqspec.az != Nonz | 08:53 |
| gibi | kashyap: https://paste.opendev.org/show/boLIfNJaksQMBL4ArQNs/ | 08:54 |
| bauzas | for 1/, this is a simple scenario : instance can float, hence we don't care and we shouldn't change it | 08:54 |
| bauzas | since the user didn't specific a AZ, we're free to pick any host | 08:54 |
| bauzas | for 2/, reqspec.az = 'sbg4' for example | 08:55 |
| bauzas | then, op transfers it to hostB which is 'rbx' | 08:55 |
| bauzas | what assumtion should we do ? | 08:55 |
| kashyap | gibi: Thanks :) | 08:56 |
| bauzas | sean-k-mooney: I see you writing | 09:06 |
| bauzas | :) | 09:06 |
| bauzas | Uggla: don't be afraid, but we're possibly redesigning the whole API | 09:07 |
| bauzas | sean-k-mooney: I like the idea to use the AZ parameter to specify whether you want the instance to stick with that AZ | 09:07 |
| bauzas | sean-k-mooney: but I'm afraid this could be errorprone | 09:07 |
| bauzas | this is about to be a confusing API | 09:08 |
| sean-k-mooney | bauzas: so i think Uggla went with option 3 or case 2.3 to avoid that confusion | 09:09 |
| sean-k-mooney | by makeing the az update we fulfile there request by moving the instance to the requested host and make the az consitnet if the vm was previously pinned | 09:09 |
| bauzas | sean-k-mooney: maybe, I just feel we need to be super-explicit on what will happen to the instance | 09:09 |
| sean-k-mooney | yes we do | 09:10 |
| sean-k-mooney | its should be agreed in the spec. | 09:10 |
| sean-k-mooney | so of the 3 options which is your preference | 09:10 |
| bauzas | I turned to -1 unfortunately | 09:10 |
| bauzas | sean-k-mooney: I like the KISS principle for our APIs | 09:11 |
| sean-k-mooney | bauzas: the shelve api is the supported way to move between AZs today | 09:11 |
| bauzas | and I don't want us to do a lof of conditionals based on parameters values | 09:11 |
| bauzas | sean-k-mooney: I got your point, I just want us to agree on what would be the RequestSpec.AZ value once the unshelve is made | 09:12 |
| sean-k-mooney | yep | 09:12 |
| bauzas | sean-k-mooney: I was +2 on the fact we were breaking the AZ contract when unshelving | 09:12 |
| sean-k-mooney | we had asked for that to be added to the spec in a previous revision | 09:12 |
| bauzas | sean-k-mooney: I'm -1 on the fact we don't explain what will happen to the instance for the next move operations after the unshelve | 09:13 |
| sean-k-mooney | bauzas: Uggla updated the spec but did not explcitly state it. there was a -1 form dansmith on this topic previously | 09:13 |
| sean-k-mooney | bauzas: not i have not review th latest revision so i assume it is still missing if so then -1 is totally fair since this is still unadressed | 09:14 |
| bauzas | sean-k-mooney: new revision only says the instance will be moved to the host, whatever the current AZ is. | 09:17 |
| sean-k-mooney | https://review.opendev.org/c/openstack/nova-specs/+/831506/1..3/specs/zed/approved/unshelve-to-host.rst#b69= | 09:17 |
| bauzas | but I guess Uggla didn't know the whole semantics of this RequestSpec.AZ field | 09:17 |
| sean-k-mooney | bauzas: yep i revived the previous comment thread | 09:17 |
| bauzas | sean-k-mooney: Uggla said the existing method unpins the AZ | 09:18 |
| bauzas | leaving the instance freefloating | 09:18 |
| sean-k-mooney | when you do unshelve --az az2 it sets requestspec.az to None? | 09:19 |
| bauzas | no | 09:19 |
| sean-k-mooney | oh when you do --host | 09:19 |
| sean-k-mooney | it set it to noe | 09:19 |
| sean-k-mooney | *None | 09:19 |
| bauzas | yup | 09:19 |
| bauzas | the latter | 09:19 |
| sean-k-mooney | ya so that is not right in my view | 09:19 |
| bauzas | for --az, we currently pin it to the target AZ AFAICR | 09:19 |
| sean-k-mooney | its ok for the schduling request but the AZ should not get nuked in the request spec | 09:20 |
| bauzas | but this is also debatable | 09:20 |
| bauzas | unshelve --az shouldn't pin to the target AZ if the instance was formerly freefloating | 09:20 |
| sean-k-mooney | correct | 09:20 |
| sean-k-mooney | it should maintain the sematics it was booted with | 09:20 |
| bauzas | yup | 09:21 |
| sean-k-mooney | hence the "only update if it was not already None" mechanic | 09:21 |
| bauzas | that's why I feel brave enough to tell we can be opinionated and imply that if an instance was pinned to an AZ and we unshelve to another AZ, we *should* pin this instance to that new AZ | 09:22 |
| gibi | hm | 09:22 |
| bauzas | and Gosh, customers who want the instance to freefloat after an unshelve... | 09:22 |
| sean-k-mooney | bauzas: yes that is what i want to do doo | 09:22 |
| sean-k-mooney | *too | 09:23 |
| sean-k-mooney | if it was pinned before we pin to the new az | 09:23 |
| gibi | I tried to collect my view: https://etherpad.opendev.org/p/RiWsCJFEI1LP80-niWho | 09:23 |
| bauzas | sean-k-mooney: I just count the days before we would have a RFE saying 'I want to unpin my instance from any AZ" | 09:23 |
| gibi | we could use the explicit AZ:none in the unshelve to trigger unpin | 09:24 |
| gibi | if we want | 09:25 |
| Uggla | gibi, +1 | 09:25 |
| gibi | can we try to collect a similar table in the spec after we agreed on the semantic? | 09:26 |
| gibi | awesome that you comment directly the etherpad it makes a lot easier to track the argument for different cases | 09:28 |
| sean-k-mooney | bauzas: unshleve --AZ None :P | 09:29 |
| bauzas | gibi: yep, we could profit from that microversion to allow AZ to be None | 09:29 |
| sean-k-mooney | reject it if it does not contain the :P | 09:29 |
| bauzas | (if we don't support it *yet*) | 09:29 |
| bauzas | I'll have to disappear son | 09:32 |
| bauzas | soon | 09:32 |
| *** bhagyashris is now known as bhagyashris|out | 09:33 | |
| bauzas | but I captured my thoughts and I feel we're on the same page between gibi, sean-k-mooney and me | 09:33 |
| gibi | yes I think so too | 09:33 |
| gibi | lets figure out how the no AZ -> AZ case behaves today | 09:33 |
| gibi | then we can settle the whole thing | 09:34 |
| sean-k-mooney | i have a multi node devstack | 09:35 |
| sean-k-mooney | ill quickly create some azs and boot some vms | 09:36 |
| bauzas | me too but I have gym | 09:36 |
| sean-k-mooney | ill update the etherpad | 09:38 |
| gibi | I quickly checked if booted without AZ then unshelved to nova AZ then the RequestSpec was updated from null to nova | 09:44 |
| bauzas | I like gibi's etherpad, short to read | 09:44 |
| bauzas | gibi: :/ | 09:44 |
| * bauzas disappears for outside activities and then lunch | 09:50 | |
| sean-k-mooney | gibi: just confirming my self but ok i guess we need to decied if we also want to change unshelve to az as part fo this micoverion | 09:56 |
| sean-k-mooney | Uggla: so assuming we all agree that we should change the behavior for unshleve to az with no az in boot the request spec initally | 10:10 |
| sean-k-mooney | can you add 2 tables to the spec | 10:10 |
| sean-k-mooney | 1 with the existing behavior for all the cases in gibis etherpad and then a second with the new behaiovr | 10:10 |
| Uggla | sean-k-mooney, yep based on the etherpad table it is clear. Of course I will change the specs with previous and new behavior. | 10:11 |
| sean-k-mooney | i have copied it to my other etherpad and created the updated tables | 10:13 |
| sean-k-mooney | https://etherpad.opendev.org/p/unshelve-to-host#L63 | 10:13 |
| sean-k-mooney | gibi: ^ | 10:14 |
| Uggla | sean-k-mooney, I think table is fine | 10:19 |
| sean-k-mooney | actully there is a conflict | 10:22 |
| sean-k-mooney | so we cant supprot unshlve to any az without a new paramater | 10:22 |
| sean-k-mooney | ill just strick though those lines ot note that we can ignore it | 10:26 |
| sean-k-mooney | if that works for you | 10:26 |
| gibi | sean-k-mooney: so the conflict is that we cannot distinguish between {availability=null} and the {} request? | 10:28 |
| sean-k-mooney | yes | 10:29 |
| sean-k-mooney | well more how to store that delta in the python object | 10:29 |
| sean-k-mooney | as in the request_spec used by the schduler | 10:29 |
| sean-k-mooney | since both woudl have AZ=None | 10:30 |
| gibi | ahh yes | 10:30 |
| gibi | but wait | 10:30 |
| sean-k-mooney | hum | 10:30 |
| sean-k-mooney | would they | 10:30 |
| gibi | do we need to differentiate in the request spec object? not just in the request itself? | 10:30 |
| sean-k-mooney | ya im thinking about that again | 10:31 |
| sean-k-mooney | can we tell the difference between {availability=null} and the {} | 10:31 |
| sean-k-mooney | the the reqested destination object that caries this i guess | 10:31 |
| gibi | the request_spec contains None means no restriction. if the API request contains az=null that means reset what is in the request spec, if the API request contains {} then that means dont change the what is in the request_spec | 10:32 |
| sean-k-mooney | gibi: ya that proably would work | 10:32 |
| sean-k-mooney | ok maybe we can add that back | 10:32 |
| opendevreview | Balazs Gibizer proposed openstack/nova stable/xena: Retry in CellDatabases fixture when global DB state changes https://review.opendev.org/c/openstack/nova/+/840949 | 10:34 |
| sean-k-mooney | gibi: Uggla updated the etherpad hopefully that is now correct | 10:38 |
| gibi | sean-k-mooney: yep it looks good to me | 10:38 |
| gibi | thanks for trying out all the legacy cases I was sloppy | 10:38 |
| sean-k-mooney | we dont have a way to pin an unpinned guest in this caes | 10:39 |
| sean-k-mooney | unless you use the old microverion | 10:39 |
| sean-k-mooney | is that an issue | 10:39 |
| sean-k-mooney | im going to take a break form this spec for a while but ill come back to it after Uggla has updated it | 10:41 |
| gibi | sean-k-mooney: I agree that pinnin is not possible now but I think that is OK | 10:43 |
| gibi | I remember a lot more questions about unpinning than pinning in the past | 10:44 |
| sean-k-mooney | ya we could always add it later if needed. i think we have enough to update the spec and then we can get bauzas's and dansmith's input to see if they agree | 10:44 |
| gibi | I agree | 10:46 |
| gibi | bauzas: left feedback in https://review.opendev.org/c/openstack/nova-specs/+/840217 | 11:53 |
| gibi | bauzas: fyi I cannot attend the today's nova meeting | 12:03 |
| gibi | I will read back | 12:03 |
| *** mfo is now known as Guest305 | 12:22 | |
| *** mfo_ is now known as mfo | 12:22 | |
| sean-k-mooney | artom: are you plannign to adress gibi's nits in https://review.opendev.org/c/openstack/nova/+/841170/3/nova/tests/functional/libvirt/test_evacuate.py or adress them in the follow up change that adressed the issue | 12:26 |
| gibi | artom: left feedback in https://review.opendev.org/c/openstack/nova-specs/+/840974 | 12:35 |
| opendevreview | Andre Aranha proposed openstack/nova master: Test setting the nova job to centos-9-stream https://review.opendev.org/c/openstack/nova/+/831844 | 12:35 |
| bauzas | gibi: ack, thanks for the spec review and ack for missing the meeting | 12:39 |
| opendevreview | Merged openstack/nova-specs master: Re-propose allow Project admin to list allowed hypervisors https://review.opendev.org/c/openstack/nova-specs/+/833165 | 12:47 |
| gibi | bauzas: have you thought about abandoning open specs that was not re-proposed to the zed directory yet? It would clean up the open spec query a bit | 12:53 |
| bauzas | gibi: we can do this | 12:53 |
| bauzas | but let's discuss this on the next meeting as you're not there for today | 12:54 |
| gibi | fine by me | 12:54 |
| sean-k-mooney | im ok with abandoing them by the way | 12:54 |
| sean-k-mooney | the owner can unabandone them | 12:55 |
| sean-k-mooney | if they repopose them | 12:55 |
| sean-k-mooney | but we are also not in a rush | 12:55 |
| sean-k-mooney | so im fine to wait to make that desision | 12:55 |
| gibi | it was just a sudden urge to close out the spec bottom third of the https://review.opendev.org/q/project:openstack%252Fnova-specs+status:open | 12:57 |
| gibi | *specs | 12:57 |
| sean-k-mooney | :) | 12:58 |
| * bauzas is about to sharpen his pen for https://review.opendev.org/c/openstack/nova-specs/+/791047 | 13:05 | |
| bauzas | but I'll respin https://review.opendev.org/c/openstack/nova-specs/+/840974 first | 13:06 |
| gibi | bauzas: thanks, take an extra coffee :) | 13:06 |
| bauzas | oh wait, wrong link | 13:06 |
| gibi | sean-k-mooney: also thanks for the feedback on that one I will go through it | 13:06 |
| bauzas | https://review.opendev.org/c/openstack/nova-specs/+/840217 | 13:06 |
| artom | gibi, much thanks! So, with that spec, I'd really like for the original customer requesting it to weigh in | 13:20 |
| artom | Since I'm not sure that in its current form it's of any use to them | 13:21 |
| artom | sean-k-mooney, yeah, I can address the nits, I'll need to figure out a fix regardless and push that | 13:21 |
| opendevreview | ribaudr proposed openstack/nova master: Allow unshelve to a specific host https://review.opendev.org/c/openstack/nova/+/831507 | 13:26 |
| *** dasm|off is now known as dasm | 13:31 | |
| opendevreview | Sylvain Bauza proposed openstack/nova-specs master: Proposes to remove keypair generation https://review.opendev.org/c/openstack/nova-specs/+/840217 | 13:35 |
| gibi | artom: ack, does the original requested aware of that we are discussing this in the spec? | 13:36 |
| artom | gibi, yeah, sent them an email | 13:36 |
| gibi | artom: cool then | 13:36 |
| artom | And they previously commented on the Neutron bug | 13:36 |
| sean-k-mooney | gibi: i think to adress the orginaly requester usecase we would need to add a --domain parmater to nova boot | 13:37 |
| gibi | sean-k-mooney: is it about having one single domain per instance or domain per port? | 13:37 |
| sean-k-mooney | and then updated hostname and local_hostname to be the full fQDN in the metadata | 13:37 |
| sean-k-mooney | they want /etc/hostname to end up with the FQDN | 13:37 |
| sean-k-mooney | so single per vm | 13:38 |
| gibi | OK, I see, so one single domain per instance | 13:38 |
| sean-k-mooney | yep | 13:38 |
| gibi | then I agree that the current spec is going to a different direction | 13:38 |
| sean-k-mooney | so to me if we want to do that we need to have that be a paramter to the nova boot command | 13:38 |
| sean-k-mooney | gibi: the issue is they wanted use to backport this which we obvioulsy cant do | 13:38 |
| sean-k-mooney | if its a new api parmater | 13:39 |
| sean-k-mooney | so what i would like to see is as folows. we add --domain, when passed we set hostname to instnace.hostname+instance.domain when not set instance.hostname is the sanadised hostname as we have today | 13:40 |
| sean-k-mooney | in addtion to that we generate the per port host name using the values from neutron | 13:40 |
| sean-k-mooney | when we pass --domain if neutron has the per-domain extension | 13:40 |
| sean-k-mooney | then if nova creates a port then we should set the port domain to the value they passed | 13:41 |
| sean-k-mooney | if we do that then you can set a default domain for an instance as part of nova boot for any ports created by nova and that will propaget via the metadta api and be sent to neutron/designate | 13:41 |
| sean-k-mooney | if you precreate the ports then we will use the value of the domain form the network or port in the metadta | 13:42 |
| gibi | I see | 13:42 |
| sean-k-mooney | and neuton/desginsate will also advertise teh hostname/fqdn infor via dhcp | 13:42 |
| sean-k-mooney | and if you have designate it woudl also configure the domains properly in dns | 13:43 |
| artom | I keep coming back to the fact that the metadata stuff is just as a safety net to make sure cloud-init doesn't clobber what the instance gets from DHCP, once Neutron actually implements that | 13:43 |
| sean-k-mooney | well the proably is that hostnames form dhcp are by defintion consider trasient hostnames | 13:43 |
| sean-k-mooney | with a lower priortiy then static hostnames configured by /etc/hostname | 13:44 |
| artom | So if we can't figure out a way to make sure cloud-init gets the correct FQDN from the metadata (because of multiple ports or other reason), then the whole spec is kinda useless | 13:44 |
| sean-k-mooney | so its not clobbering it | 13:44 |
| sean-k-mooney | not really i think it makes sense to pass the dns info via metadata | 13:44 |
| sean-k-mooney | as the application in the vm may not have access to neutron api | 13:44 |
| sean-k-mooney | and if you readd the api cahnge for --domain then you can also cater for updating the static hostname via cloud-init | 13:45 |
| opendevreview | Merged openstack/nova-specs master: update userdata https://review.opendev.org/c/openstack/nova-specs/+/816542 | 14:49 |
| bauzas | man, what a PCI spec :) | 14:57 |
| gibi | sean-k-mooney: replied to some of your the deeper comments in https://review.opendev.org/c/openstack/nova-specs/+/791047 | 14:57 |
| * bauzas needs to upgrade his brain :p | 14:58 | |
| gibi | but I will disappear now and might return a last review round for today after 20:00 CEST | 14:58 |
| sean-k-mooney | gibi: cool ill take a look im still take a first pass over some of the specs | 14:59 |
| bauzas | reminder: nova meeting in 1 hour here | 14:59 |
| * bauzas needs to also update the agenda | 14:59 | |
| bauzas | sean-k-mooney: you had a point about https://review.opendev.org/c/openstack/project-config/+/837595 | 15:22 |
| bauzas | sean-k-mooney: I don't see in the agenda, do you want me to add it ? | 15:22 |
| sean-k-mooney | oh ya sure | 15:22 |
| bauzas | I'll briefly mention it in the right topic | 15:23 |
| sean-k-mooney | just are we good to proceed with that | 15:23 |
| bauzas | I'll call out for reviews and summarize the namings | 15:23 |
| bauzas | shall be quick hopefully | 15:23 |
| erlon | hey folks, can someone else +2 this patch so I can continue the backporting? | 15:37 |
| erlon | https://review.opendev.org/c/openstack/nova/+/836014 | 15:37 |
| sean-k-mooney | melwitt:^ | 15:40 |
| bauzas | nova meeting in 2 mins here | 15:57 |
| bauzas | #startmeeting nova | 16:00 |
| opendevmeet | Meeting started Tue May 10 16:00:12 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 everyone | 16:00 |
| stephenfin | o/ | 16:00 |
| elodilles | o/ | 16:00 |
| bauzas | #link https://wiki.openstack.org/wiki/Meetings/Nova#Agenda_for_next_meeting | 16:00 |
| chateaulav | \0 | 16:00 |
| bauzas | ok, let's start, people can join | 16:01 |
| bauzas | #topic Bugs (stuck/critical) | 16:01 |
| bauzas | #info No Critical bug | 16:02 |
| bauzas | #link https://bugs.launchpad.net/nova/+bugs?search=Search&field.status=New 19 new untriaged bugs (-3 since the last meeting) | 16:02 |
| bauzas | thanks artom et al. for the triage | 16:02 |
| artom | \o/ a net minus! | 16:02 |
| bauzas | artom created an etherpad for bugs he looks https://etherpad.opendev.org/p/nova-bug-triage-20220503 | 16:02 |
| bauzas | looked* | 16:02 |
| bauzas | artom: nothing to tell about those ? | 16:03 |
| artom | Not really, just the evacuation one that's really funky | 16:03 |
| artom | gibi and sean-k-mooney already looked at the reproducer func test | 16:03 |
| bauzas | okay thanks | 16:03 |
| bauzas | continuing then | 16:03 |
| sean-k-mooney | because it inovled data loss im oke with it being a bug | 16:03 |
| bauzas | #link https://storyboard.openstack.org/#!/project/openstack/placement 26 open stories (0 since the last meeting) in Storyboard for Placement | 16:04 |
| sean-k-mooney | but otherwise i woudl consider it a small specless blueprint | 16:04 |
| bauzas | sean-k-mooney: artom: bug link ? | 16:04 |
| sean-k-mooney | https://review.opendev.org/c/openstack/nova/+/841170 | 16:04 |
| sean-k-mooney | https://bugs.launchpad.net/nova/+bug/1952745 | 16:04 |
| bauzas | thanks | 16:05 |
| bauzas | ok, don't want to overdiscuss this bug in large, so I trust you, folks | 16:07 |
| bauzas | let's say Valid and we can nitpick on whether it's requiring a BP or not during the code review | 16:07 |
| sean-k-mooney | i think we can proceed as a bug | 16:07 |
| sean-k-mooney | but its borderline | 16:08 |
| sean-k-mooney | so we can move on i think | 16:08 |
| bauzas | my first thoughts wonder whether this should be supported or not | 16:08 |
| bauzas | but I need to look at other comments | 16:08 |
| bauzas | but I agree, evacuate should work even if the compute is definitely gone | 16:09 |
| bauzas | that's actually why we have evacuate :) | 16:09 |
| bauzas | but let's not bikeshid this by noxw | 16:09 |
| bauzas | next point | 16:09 |
| bauzas | #info Add yourself in the team bug roster if you want to help https://etherpad.opendev.org/p/nova-bug-triage-roster | 16:10 |
| kashyap | bauzas: On bugs ... | 16:10 |
| bauzas | which leads me to the next point, | 16:10 |
| bauzas | #info Next bug baton is passed to Uggla | 16:10 |
| bauzas | Uggla: you're ok with this ? | 16:10 |
| bauzas | reminder : this is best-effort | 16:10 |
| bauzas | metrics are cool, but that's not important | 16:11 |
| bauzas | any effort counts, even the lowest | 16:11 |
| kashyap | Having dedicated days of public bug triage would be nice. We did it in the distant past (here and also for RDO) | 16:11 |
| bauzas | hmmmm, looks like Uggla is gone for today | 16:11 |
| kashyap | But doing it off alone quietly ... it's hard to sustain | 16:11 |
| sean-k-mooney | kashyap: i think that is the reason to have it rotate | 16:12 |
| bauzas | kashyap: we can discuss the opportunity of a Bug Triage day later if you wish | 16:12 |
| bauzas | but this is exceptional by nature | 16:12 |
| * artom did it yesterday afternoon | 16:12 | |
| bauzas | rotation helps with the triage fatigue | 16:12 |
| kashyap | Right. A small idea: | 16:13 |
| kashyap | When we were bootstrapping the RDO community, I used to do these public reports to the mailing list: | 16:13 |
| kashyap | https://kashyapc.fedorapeople.org/virt/openstack//rdo-bug-status/2017/nova-bugs-05-SEP-2017.txt | 16:13 |
| bauzas | I don't want people to mark their agendas with a triage day, we're upstream here and I don't want to order people | 16:13 |
| kashyap | _With_ the title of the bug in the mail; so people could skim it via email ... | 16:13 |
| kashyap | (I'm not sure if that'll work here, to send them to the -discuss list. Once every month? I don't know) | 16:14 |
| kashyap | bauzas: No, you're misunderstanding me :) | 16:14 |
| bauzas | kashyap: again I don't want to force any formalization of things | 16:14 |
| kashyap | bauzas: We're not "ordering" anyoone on anything. | 16:14 |
| sean-k-mooney | that feels a bit heavy wait but proably workable i would be less enclined to do it if i had to send a main however | 16:14 |
| kashyap | bauzas: We've done this countless times before when doing upstream RDO community work: | 16:14 |
| bauzas | sean-k-mooney: even the triage etherpad has to be kept *optional* | 16:15 |
| kashyap | You simply mark a day ahead of time, note it on the list, as an announce to let people know. If people have time, thye'll join | 16:15 |
| bauzas | this is nice artom, melwitt and gibi created one | 16:15 |
| bauzas | but this hasn't to be mandatory | 16:15 |
| kashyap | bauzas: This is standard proceduce that's also done in much bigger communities like Fedora | 16:15 |
| sean-k-mooney | ok take me off the triage list then | 16:15 |
| sean-k-mooney | this is getting more compliated then i want | 16:16 |
| bauzas | sean-k-mooney: again, no, I want to keep it simple | 16:16 |
| bauzas | no triage etherpad, no mailing lists | 16:16 |
| kashyap | Sure, I know people also have lesser "will power", with shorter teams and bandwidth. | 16:16 |
| sean-k-mooney | ack i was happen to skim hte new bugs a few time a week during my week | 16:16 |
| kashyap | bauzas: That's fine, we can actually move on. | 16:16 |
| sean-k-mooney | but dont really want to have to add more paperwork | 16:17 |
| bauzas | sean-k-mooney: I'm fully on the same page, see my previous comments | 16:17 |
| kashyap | bauzas: The mail list is an "announce". People won't magically suddenly think: "Yay! I'm going to dedicate this morning for bug triage" | 16:17 |
| kashyap | It's a rare thing unless one has a habit, and good filters for it. | 16:17 |
| bauzas | kashyap: about the mailing-list reminder email once per month, that's maybe something a PTL *could* do | 16:17 |
| kashyap | sean-k-mooney: Sure, I'm the last one to suggest adding "paperwork" (yikes) | 16:18 |
| Uggla | bauzas, sorry was out | 16:18 |
| bauzas | kashyap: but I don't want to enforce any rules | 16:18 |
| kashyap | sean-k-mooney: The point I'm making is: sharing experiences from other communities how public bug triage used to be sustained. | 16:18 |
| kashyap | bauzas: Sigh, you keep saying that. I'm saying to "enforce" any rules :) | 16:18 |
| Uggla | bauzas, ok for the bug baton | 16:18 |
| bauzas | kashyap: proposing to send an email is a rule :) | 16:18 |
| kashyap | It's not; it's a suggestion. "Proposal" != "rule" | 16:19 |
| bauzas | kashyap: sorry about the confusion, I just wanted to explain the bug triage rotation upstream is necessarly something people opt-in on their free time with their own things | 16:20 |
| kashyap | bauzas: We can move on; really. I've done community bug triages with much larger groups in the past (Fedora test days, RDO, CentOS, etc). Just sharing what worked. | 16:20 |
| kashyap | (There isn't possibility, given the thinness of the community here.) | 16:20 |
| kashyap | Of course, everything is "opt-in" upstream. | 16:20 |
| bauzas | kashyap: noted, I just wanted to clarify that triage etherpads *are* optional | 16:21 |
| kashyap | bauzas: (I missed a word earlier: I'm saying NOT to "enforce" any riles) | 16:21 |
| kashyap | s/riles/rules/ | 16:21 |
| kashyap | Sure. Just as a general point: in upstreams I never suggest anything as a "rule". Everything _is_ optional. As you can't "demand" community time. | 16:22 |
| bauzas | kashyap: that's why emails are difficult, because operators and consumers of this perodic email are in demand with more | 16:22 |
| bauzas | either the email is read and people ask for a new one | 16:23 |
| bauzas | or the email isn't read and then the sake of sending such email is meaningless | 16:23 |
| bauzas | that's why I can only propose myself to send such periodic emails | 16:23 |
| kashyap | Sure. It doesn't have to be. We've tried everything in the past, "bug czars", etc. | 16:24 |
| bauzas | ... with a short period of life :) | 16:24 |
| bauzas | anyway, I guess we can move on | 16:24 |
| bauzas | Uggla: thanks for offering your time, again, no rush | 16:25 |
| bauzas | next topic | 16:27 |
| bauzas | #topic Gate status | 16:27 |
| bauzas | #link https://bugs.launchpad.net/nova/+bugs?field.tag=gate-failure Nova gate bugs | 16:27 |
| bauzas | #link https://zuul.openstack.org/builds?project=openstack%2Fplacement&pipeline=periodic-weekly Placement periodic job status | 16:27 |
| bauzas | #link https://zuul.opendev.org/t/openstack/builds?job_name=nova-emulation&pipeline=periodic-weekly&skip=0 Emulation periodic job runs | 16:27 |
| bauzas | things look good, AFAICS | 16:27 |
| bauzas | we have tho a new gate bug https://bugs.launchpad.net/nova/+bug/1970642 | 16:28 |
| bauzas | nothing to tell tho | 16:28 |
| bauzas | moving on | 16:28 |
| bauzas | #info Please look at the gate failures and file a bug report with the gate-failure tag. | 16:28 |
| bauzas | #info STOP DOING BLIND RECHECKS aka. 'recheck' https://docs.openstack.org/project-team-guide/testing.html#how-to-handle-test-failures | 16:29 |
| bauzas | next topic, | 16:29 |
| bauzas | #topic Release Planning | 16:29 |
| bauzas | #link https://releases.openstack.org/zed/schedule.html | 16:29 |
| bauzas | #info Zed-1 is due in 1 week | 16:29 |
| bauzas | well, 9 days tbc | 16:29 |
| bauzas | there is no deadline about this milestone in terms of code or spec review tbc | 16:30 |
| bauzas | #info Spec review day happens today on May 10th | 16:30 |
| bauzas | I've seen good efforts from a couple of people here | 16:30 |
| sean-k-mooney | for m1 we should try and land any traits for approved specs | 16:30 |
| bauzas | thanks to all who played this game today | 16:30 |
| sean-k-mooney | so that they can be inlcuded in the m1 release | 16:30 |
| bauzas | this will continue until end of our day, depending on your TZ of course :) | 16:30 |
| bauzas | sean-k-mooney: good call | 16:31 |
| bauzas | sean-k-mooney: I guess you meant https://review.opendev.org/c/openstack/osc-placement/+/828545 ? | 16:32 |
| sean-k-mooney | no | 16:34 |
| bauzas | link then ? | 16:34 |
| sean-k-mooney | things like this https://review.opendev.org/c/openstack/os-traits/+/832769 | 16:35 |
| bauzas | oh | 16:35 |
| sean-k-mooney | that is not appoved yet | 16:35 |
| sean-k-mooney | but for our unit tests to pass traits need to be in a release version of os-traits | 16:35 |
| bauzas | for the library release on zed-1, gotcha | 16:35 |
| sean-k-mooney | yes | 16:36 |
| bauzas | surely, we can make it | 16:36 |
| bauzas | sean-k-mooney: let's coordinate tomorrow for some review effort on the libs changes then | 16:36 |
| opendevreview | Artom Lifshitz proposed openstack/nova master: Reproduce bug 1952745 https://review.opendev.org/c/openstack/nova/+/841170 | 16:36 |
| opendevreview | Artom Lifshitz proposed openstack/nova master: Move evacuated instance destruction to new post_start_hook https://review.opendev.org/c/openstack/nova/+/841308 | 16:36 |
| sean-k-mooney | sure its not the end of the world if we dont have them merge by m1 | 16:37 |
| sean-k-mooney | i just blocks us mergin the nova code until we do an os-triats release whihc is cheap | 16:37 |
| bauzas | sean-k-mooney: the only problem with the change you just proposed is that it depends on a spec which hasn't been approved yet :) | 16:37 |
| bauzas | sean-k-mooney: yup, we had that problem in the past | 16:37 |
| sean-k-mooney | yep | 16:37 |
| sean-k-mooney | so we may have approves specs today that added traits. not sure we did | 16:38 |
| bauzas | maybe let's focus on reviewing specs that have library dependencies | 16:38 |
| sean-k-mooney | jsut wanted to highlight for peopel if you own one fo those spec then please submit a os-tirat patch if it had traits and ill be happy to review | 16:38 |
| bauzas | sean-k-mooney: no, but I can personnally focus my effort on such specs | 16:38 |
| bauzas | moving on tho, time flies | 16:38 |
| bauzas | #topic Review priorities | 16:39 |
| 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:39 |
| bauzas | #link https://review.opendev.org/c/openstack/project-config/+/837595 Gerrit policy for Review-prio contributors flag. Naming bikeshed in there. | 16:39 |
| 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:39 |
| bauzas | sean-k-mooney: I just noticed we allow any contributor to flag with +1 | 16:39 |
| bauzas | but the doc says we should not allow the owner to do it directly | 16:39 |
| sean-k-mooney | correct | 16:40 |
| sean-k-mooney | we cant make that distinction | 16:40 |
| sean-k-mooney | i tried with chanve_owner:0 | 16:40 |
| bauzas | ok, then we'll need to have a smarter Gerrit query | 16:40 |
| sean-k-mooney | but that will not override registered owner | 16:40 |
| sean-k-mooney | or we can just discuage it when we see it | 16:40 |
| sean-k-mooney | the doc still says they should not flag there own change | 16:41 |
| bauzas | yup, educational enforcement :) | 16:41 |
| opendevreview | Artom Lifshitz proposed openstack/nova-specs master: Domain names in metadata https://review.opendev.org/c/openstack/nova-specs/+/840974 | 16:41 |
| sean-k-mooney | if it ends up being a proablem we can revaluate | 16:41 |
| bauzas | ok, let's bikeshed on the names in the gerrit change itself | 16:41 |
| bauzas | I don't wanna drag this meeting's time by us disagreeing on how we would label those rights | 16:42 |
| sean-k-mooney | ok if there are no objection to the names as written i think we could ask infra to review | 16:42 |
| bauzas | but if people care about naming such things, they should review the change | 16:42 |
| bauzas | sean-k-mooney: gibi had an objection, but let's continue off this meeting | 16:43 |
| sean-k-mooney | ah ok | 16:43 |
| bauzas | (about the +2 naming) | 16:43 |
| bauzas | #topic Stable Branches | 16:43 |
| bauzas | elodilles: are you around N? | 16:43 |
| elodilles | yepp | 16:43 |
| bauzas | cool | 16:43 |
| * bauzas drops mic | 16:43 | |
| elodilles | i did not update the page, though, as there's no news unfortunately, | 16:44 |
| elodilles | from yoga till victoria the gate looks OK afaik | 16:44 |
| bauzas | ok, then | 16:44 |
| bauzas | #info ussuri and older branches are blocked until 'l-c drop' patches merge - https://review.opendev.org/q/I514f6b337ffefef90a0ce9ab0b4afd083caa277e | 16:45 |
| bauzas | #info other branches are OK | 16:45 |
| elodilles | yepp, still valid ^^^ | 16:45 |
| elodilles | did not get there to investigate more on ussuri | 16:45 |
| elodilles | :-/ | 16:45 |
| bauzas | s/should be/are for the last item :) | 16:45 |
| bauzas | thanks elodilles | 16:46 |
| bauzas | last topic | 16:46 |
| bauzas | #topic Open discussion | 16:46 |
| bauzas | (sean-k-mooney) VDPA | 16:46 |
| bauzas | sean-k-mooney: we're listening to you | 16:46 |
| sean-k-mooney | :) | 16:46 |
| sean-k-mooney | so short version is as agreed at the ptg i filed a bug for the move operation that were blocked but actully working | 16:47 |
| sean-k-mooney | and i have a patch to adress it | 16:47 |
| bauzas | cool | 16:47 |
| sean-k-mooney | i then have 3 patches that follow up adding the remaining life cycle operations | 16:47 |
| sean-k-mooney | i would like to proceed with those as a specless blueprint | 16:48 |
| sean-k-mooney | those are inteface detach | 16:48 |
| sean-k-mooney | suspend which need detach | 16:48 |
| sean-k-mooney | and hotplug live migration which just need detach and adding vdpa to a list | 16:48 |
| sean-k-mooney | and a compute version bump+ conductor check | 16:48 |
| sean-k-mooney | idential to sriov hotplug migraiton | 16:49 |
| sean-k-mooney | how do people feel about that | 16:49 |
| sean-k-mooney | i have the code writen for everything excpot the compute service bump | 16:49 |
| bauzas | hmmmm | 16:49 |
| sean-k-mooney | test code is still need so patches are WIP | 16:49 |
| bauzas | sean-k-mooney: no RPC changes on the compute service, just a version bump for API check ? | 16:50 |
| sean-k-mooney | yep like this https://github.com/openstack/nova/blob/master/nova/conductor/tasks/live_migrate.py#L34-L44= | 16:50 |
| sean-k-mooney | the sriov live migration code works for vdpa too | 16:51 |
| bauzas | I'd say a specless BP seems OK to me | 16:51 |
| sean-k-mooney | just need to tell it to hot unplug the interface as we do for direct passthough | 16:51 |
| bauzas | for exposing the new lifecycle ops | 16:51 |
| sean-k-mooney | the compute service bump is just need for rooling upgrades | 16:51 |
| bauzas | I know | 16:52 |
| bauzas | but this means there is an upgrade impact | 16:52 |
| bauzas | seamless for ops tho | 16:52 |
| bauzas | but I don't see any controversial requiring a spec | 16:52 |
| sean-k-mooney | yep so the api block will move form the api to conductor baseed on compute service version | 16:52 |
| bauzas | so, looks like a feature, but less paper-ish | 16:52 |
| bauzas | sean-k-mooney: this will be explained in a feature relnote, so definitely a blueprint | 16:53 |
| bauzas | like 'now, nova supports this, only if you have your whole cloud uptodate' | 16:53 |
| sean-k-mooney | ok we can continue to discuss in gerrit https://blueprints.launchpad.net/nova/+spec/vdpa-suspend-detach-and-live-migrate is the blueprint | 16:53 |
| sean-k-mooney | but yes i can detial this in the release note | 16:54 |
| bauzas | we have 5 mins for officially blessing it | 16:54 |
| bauzas | do you want to propose https://blueprints.launchpad.net/nova/+spec/vdpa-suspend-detach-and-live-migrate as a specless BP ? | 16:54 |
| sean-k-mooney | yes | 16:55 |
| bauzas | okay, then anyone DISAGREEING with this ? | 16:55 |
| bauzas | looks not, | 16:56 |
| bauzas | #agreed https://blueprints.launchpad.net/nova/+spec/vdpa-suspend-detach-and-live-migrate approved for Zed release as a specless BP, no objections so far be seen | 16:56 |
| bauzas | voila | 16:56 |
| bauzas | sean-k-mooney: a short summary and a better title may help | 16:57 |
| bauzas | but I'll approve your BP | 16:57 |
| bauzas | that's it for today, any other lastminute item to discuss ? | 16:58 |
| bauzas | apparently not | 16:58 |
| bauzas | thanks all | 16:58 |
| bauzas | productive meeting again | 16:59 |
| bauzas | #endmeeting | 16:59 |
| opendevmeet | Meeting ended Tue May 10 16:59:06 2022 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 16:59 |
| opendevmeet | Minutes: https://meetings.opendev.org/meetings/nova/2022/nova.2022-05-10-16.00.html | 16:59 |
| opendevmeet | Minutes (text): https://meetings.opendev.org/meetings/nova/2022/nova.2022-05-10-16.00.txt | 16:59 |
| opendevmeet | Log: https://meetings.opendev.org/meetings/nova/2022/nova.2022-05-10-16.00.log.html | 16:59 |
| elodilles | thanks bauzas o/ | 16:59 |
| bauzas | as a side note, I just remembered I'll be on PTO tomorrow /o\ | 16:59 |
| bauzas | sean-k-mooney: I made false promises | 16:59 |
| sean-k-mooney | :) | 16:59 |
| sean-k-mooney | if you forgot about PTO you likely need it | 17:00 |
| elodilles | bauzas: i know it's spec review day, but... o:) maybe these worth some quick reviews (perhaps tomorrow :)): https://review.opendev.org/q/Ieba7daf39fa3323e8c9a7396747449f24189fcd5 | 17:00 |
| bauzas | joys of May and my number of PTO days which is too high for the end of the paperwork year | 17:00 |
| elodilles | bauzas: or if you'll be on PTO then the day after your PTO :X | 17:00 |
| bauzas | I may have to take more PTO days before end of May, but I'll restrict myself to one per week | 17:01 |
| sean-k-mooney | i can hit the master patch | 17:01 |
| elodilles | sean-k-mooney: awesome, thanks! \o/ | 17:01 |
| bauzas | done | 17:02 |
| elodilles | thanks \o/ | 17:02 |
| sean-k-mooney | elodilles: are there any other "nova" repos these are still pending for | 17:03 |
| sean-k-mooney | i think we already did some of them | 17:03 |
| elodilles | sean-k-mooney: to tell you the truth i don't know. maybe os-vif also have l-c? | 17:03 |
| sean-k-mooney | it did but i think i approve the removal already | 17:04 |
| sean-k-mooney | yep if anyone want to be the second +2 https://review.opendev.org/c/openstack/os-vif/+/840020 | 17:04 |
| sean-k-mooney | or i can just merge this with a singel +2 if peopel dont revew by the end of the week | 17:04 |
| sean-k-mooney | ah nova itself | 17:05 |
| sean-k-mooney | https://review.opendev.org/c/openstack/nova/+/840021 | 17:05 |
| elodilles | yepp, in nova i started with stable-only patches as stable branches were blocked | 17:06 |
| elodilles | so, nice catch sean-k-mooney :) | 17:07 |
| sean-k-mooney | stephenfin: ^ care to take a look at the nova and os-vif lc patches | 17:07 |
| elodilles | those are still waiting for some reviews :X | 17:07 |
| stephenfin | sure | 17:08 |
| sean-k-mooney | ok im going to call it a day | 17:17 |
| * gibi just back for a short review round | 17:19 | |
| gibi | artom: thanks for the bug triage! | 17:19 |
| * gibi is happy that the numbers are decreasing | 17:20 | |
| *** artom_ is now known as artom | 17:24 | |
| artom | gibi, happy to help :) | 17:24 |
| *** dasm is now known as dasm|bbl | 17:27 | |
| melwitt | bauzas: I added a note about optionalness of etherpads/docs https://etherpad.opendev.org/p/nova-bug-triage-roster feel free to change it or remove it or whatever | 17:28 |
| opendevreview | Merged openstack/placement master: Drop lower-constraints.txt and its testing https://review.opendev.org/c/openstack/placement/+/840018 | 18:15 |
| donny | Hi everyone I recently joined the project and would like to contribute....can someone please help me on how to go about understanding the codebase | 18:44 |
| opendevreview | Merged openstack/placement stable/yoga: Drop lower-constraints.txt and its testing https://review.opendev.org/c/openstack/placement/+/840728 | 19:55 |
| opendevreview | Merged openstack/placement stable/xena: Drop lower-constraints.txt and its testing https://review.opendev.org/c/openstack/placement/+/840756 | 21:48 |
| opendevreview | Miguel Lavalle proposed openstack/os-vif master: Revert "Fix race with DPDK and vhostuserclient mode" https://review.opendev.org/c/openstack/os-vif/+/841276 | 22:14 |
| opendevreview | Miguel Lavalle proposed openstack/os-vif master: Revert "Fix race with DPDK and vhostuserclient mode" https://review.opendev.org/c/openstack/os-vif/+/841276 | 22:18 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!