| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2022-09-01 | |||
| 11:15:56 | sean-k-mooney | to confirm this work as intended | |
| 12:46:21 | bauzas | sean-k-mooney: I can review the traits change once ricolin updates it | |
| 12:46:45 | ricolin | Thanks sean-k-mooney: bauzas will do it ASAP | |
| 12:46:51 | bauzas | cool | |
| 12:46:52 | sean-k-mooney | in its current form its not wrong its just over complciated | |
| 12:47:09 | sean-k-mooney | ricolin: i think if you adress that everything else looks ok | |
| 12:47:14 | sean-k-mooney | and it can land before FF | |
| 12:47:37 | ricolin | sean-k-mooney: sounds great | |
| 12:47:39 | sean-k-mooney | i have not had a change to test it locally yet but i expect it to work | |
| 12:47:48 | opendevreview | Amit Uniyal proposed openstack/nova master: Adds a repoducer for post live migration fail https://review.opendev.org/c/openstack/nova/+/854499 | |
| 12:47:48 | opendevreview | Amit Uniyal proposed openstack/nova master: [compute] always set instnace.host in post_livemigration https://review.opendev.org/c/openstack/nova/+/791135 | |
| 12:48:03 | sean-k-mooney | ricolin: i assume you ahve booted a vm with this code and validated the iommu is present | |
| 12:55:49 | opendevreview | Rico Lin proposed openstack/nova master: Add traits for viommu model https://review.opendev.org/c/openstack/nova/+/844507 | |
| 12:56:32 | ricolin | sean-k-mooney: done | |
| 12:58:00 | ricolin | and yes, I'm sure IOMMU is there. Just not sure I test Traits in the right way | |
| 13:01:56 | bauzas | ricolin: sean-k-mooney: reviewing | |
| 13:02:06 | ricolin | thanks bauzas | |
| 13:23:51 | sean-k-mooney | bauzas: gibi if ye want to proceed with ^ im more or less happy with it. the release note shoudl be in the seond patch | |
| 13:24:12 | sean-k-mooney | but as long as we land both of them its not an issue | |
| 13:24:26 | bauzas | sean-k-mooney: I just said +1 for an upgrade question | |
| 13:24:36 | sean-k-mooney | i replied | |
| 13:24:43 | sean-k-mooney | thats intentional | |
| 13:25:26 | sean-k-mooney | altough dansmith might point out we could have also added a min compute service check for this instead of using the traits | |
| 13:26:11 | sean-k-mooney | we normally did not dod that in the past however | |
| 13:26:21 | sean-k-mooney | so i think this is all good to go | |
| 13:26:31 | gibi | the trait based capability scheduling looks OK to me | |
| 13:26:45 | gibi | I think dansmith had issues using the capability trait outside of the scheduling | |
| 13:26:55 | dansmith | if we're already scheduling, then traits make plenty of sense | |
| 13:26:57 | dansmith | right | |
| 13:27:10 | sean-k-mooney | yep its in the existing pre filter | |
| 13:27:23 | gibi | bauzas: do you need my +2 or you will send it in? | |
| 13:27:39 | sean-k-mooney | before we started to do these check with placment we would have landed on the host and failed there with hypervior too old or similar | |
| 13:28:11 | bauzas | sorry folks was in 1:1 meeting | |
| 13:28:20 | bauzas | sean-k-mooney: thanks, will reply then with +2 | |
| 13:28:29 | gibi | ack, then I'm not needed there :) | |
| 13:28:29 | bauzas | it was just an open thought | |
| 13:28:51 | bauzas | I just want to make sure that operators know they need to upgrade all their hosts if so | |
| 13:29:03 | bauzas | but that's understandable | |
| 13:29:32 | sean-k-mooney | well its as you said | |
| 13:29:44 | sean-k-mooney | the dont actully have to but it will be capsity limited | |
| 13:30:12 | sean-k-mooney | but that kind of to be expected that you cant use new feature on old nodes | |
| 13:30:20 | bauzas | yup, agreed | |
| 13:30:31 | bauzas | at least with traits | |
| 13:30:36 | sean-k-mooney | well even without | |
| 13:30:54 | bauzas | without, we ask for compute service checks in general | |
| 13:31:00 | sean-k-mooney | yep | |
| 13:31:09 | sean-k-mooney | but that is why i said the traits patch chould be first | |
| 13:31:21 | bauzas | well, if both merge for Zed, I'm cool | |
| 13:31:32 | sean-k-mooney | and the other one secodn and why i said in the current order they need to merge togather | |
| 13:31:51 | bauzas | yes and no | |
| 13:32:14 | sean-k-mooney | bauzas: let me rephase i dont want to merge only one of thoes two patches | |
| 13:32:14 | bauzas | you could merge the first, this is just you won't be able to get the feature until you upgrade all | |
| 13:32:25 | dansmith | gibi: sean-k-mooney: are we FFEing the user_data stuff such that I should try to bang out the rest of the RPC stuff ASAP? | |
| 13:32:32 | bauzas | won't be able to *be sure* to get the feature | |
| 13:32:43 | bauzas | dansmith: eeek, context ? | |
| 13:32:47 | bauzas | oh, the rpc call | |
| 13:33:02 | bauzas | lemme just send to the gate ricolin's work | |
| 13:33:09 | sean-k-mooney | bauzas: that an di guess i need to rev my follow up patch with actul tests | |
| 13:33:45 | sean-k-mooney | dansmith: im not agasint doint that if you think you will have time | |
| 13:34:04 | sean-k-mooney | but that probaly the main RFE that i think FFE might make sense for | |
| 13:34:20 | dansmith | sean-k-mooney: I was expecting to see a rev of the patch to move the regen to after the instance is destroyed and fix the actual writing that was failing | |
| 13:34:30 | dansmith | so I hadn't rebased my RPC stuff yet | |
| 13:34:31 | sean-k-mooney | the only other one might be the PCI series ebut have nto looked at it for two days | |
| 13:34:40 | dansmith | but that has to happen first right? | |
| 13:34:52 | sean-k-mooney | oh i wrote a ptach to fix config drive | |
| 13:35:10 | dansmith | oh is that ths? https://review.opendev.org/c/openstack/nova/+/855351/1 | |
| 13:35:16 | sean-k-mooney | yes | |
| 13:35:41 | gibi | sean-k-mooney: you are +2 up until the healing patches in the PCI and that is the realistic target there. If stephenfin will have no time to review them today then I will ask for an FFE for that. We let the scheduling part slip in any case | |
| 13:35:51 | bauzas | the mutable userdata has API impact | |
| 13:35:52 | dansmith | okay but that would need to be squashed or go in front right? | |
| 13:35:59 | bauzas | but I'm OK with FFE'ing if needed | |
| 13:36:16 | dansmith | bauzas: it would also be about half not-very-reviewed code at this point based on the look of the configdrive patch | |
| 13:36:30 | dansmith | so not really "just didn't get reviewed in time" | |
| 13:36:49 | sean-k-mooney | dansmith: yes or they split the patch in to non config drive and config drive | |
| 13:37:20 | dansmith | that would mean two microversions for effectively the same thing | |
| 13:37:30 | sean-k-mooney | dansmith: i basically started my patch so they would have a refernce for what needed to be done | |
| 13:37:36 | dansmith | unless we do the config regen and rpc ahead of exposing int the api | |
| 13:37:39 | bauzas | dansmith: I think we reviewed it good, but we got a bone | |
| 13:37:59 | bauzas | so, I'm OK with giving more time to review that bone fix | |
| 13:38:06 | dansmith | bauzas: I'm saying the code that needs to be written to make it landable would probably double the actual code in the patch | |
| 13:38:09 | sean-k-mooney | dansmith: yep we coudl do that so intialy it would not be invokeable from the api btut he code would be in place | |
| 13:38:30 | dansmith | sean-k-mooney: yeah that seems better to me | |
| 13:38:32 | bauzas | dansmith: then, we need to take this extratime to balance the risks and maybe not merge it | |
| 13:38:52 | bauzas | or decide we only merge half the things | |
| 13:39:12 | sean-k-mooney | dansmith: so you could proably combin your rpc code into the pathc i started then we could flip the order of them | |
| 13:39:13 | gibi | we could merge the part that support user data update with non config drive instances. | |
| 13:39:26 | sean-k-mooney | but that also means we need to other pepoel to agree to review this | |
| 13:39:33 | sean-k-mooney | since you and i are basicaly out at that point | |
| 13:40:12 | gibi | I can review the patches (I will be around 18:00 CEST today but I can spend time early tomorrow too) | |
| 13:40:31 | gibi | * I will be around until 18:00 CEST today | |
| 13:40:47 | dansmith | sean-k-mooney: right, that's a problem too | |
| 13:41:21 | dansmith | sean-k-mooney: so a patch in front that adds the flag to the reboot call, then the patch to make it regeneratable, then the api patch to do it for both types would be cleanest I think | |
| 13:41:47 | sean-k-mooney | dansmith: ya that sounds like a plan | |
| 13:42:07 | sean-k-mooney | it keeps just one micorversion | |
| 13:42:57 | sean-k-mooney | i can go writeh the tests need to make the rebuild patch complete if we agree to proceed in this direction | |
| 13:43:57 | dansmith | sean-k-mooney: ack, I'll rebase my rpc stuff | |
| 13:44:00 | sean-k-mooney | dansmith: it would proably make sense for you to write your patch directly off master and i could rebase and flip the order when your done | |
| 13:44:14 | dansmith | sean-k-mooney: yeah | |
| 13:44:29 | bauzas | I'm OK with having 3 patches, the API one being the latest | |
| 13:44:48 | bauzas | and this being FFE, so we have 1 week to correctly look at all of this | |