| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2022-08-30 | |||
| 16:34:02 | opendevreview | Balazs Gibizer proposed openstack/nova master: Split PCI pools per PF https://review.opendev.org/c/openstack/nova/+/854440 | |
| 16:34:03 | opendevreview | Balazs Gibizer proposed openstack/nova master: Make allocation candidates available for scheduler filters https://review.opendev.org/c/openstack/nova/+/854119 | |
| 16:34:03 | opendevreview | Balazs Gibizer proposed openstack/nova master: Map PCI pools to RP UUIDs https://review.opendev.org/c/openstack/nova/+/854118 | |
| 16:34:04 | opendevreview | Balazs Gibizer proposed openstack/nova master: Factor out base class for candidate aware filters https://review.opendev.org/c/openstack/nova/+/854929 | |
| 16:34:04 | opendevreview | Balazs Gibizer proposed openstack/nova master: Filter PCI pools based on Placement allocation https://review.opendev.org/c/openstack/nova/+/854120 | |
| 16:34:05 | opendevreview | Balazs Gibizer proposed openstack/nova master: Store allocated RP in InstancePCIRequest https://review.opendev.org/c/openstack/nova/+/854121 | |
| 16:34:06 | opendevreview | Balazs Gibizer proposed openstack/nova master: Func test for PCI in placement scheduling https://review.opendev.org/c/openstack/nova/+/854122 | |
| 16:34:06 | opendevreview | Balazs Gibizer proposed openstack/nova master: Support cold migrate and resize with PCI tracking in placement https://review.opendev.org/c/openstack/nova/+/854247 | |
| 16:34:08 | opendevreview | Balazs Gibizer proposed openstack/nova master: Support evacuate with PCI in placement https://review.opendev.org/c/openstack/nova/+/854615 | |
| 16:34:08 | opendevreview | Balazs Gibizer proposed openstack/nova master: Support unshelve with PCI in placement https://review.opendev.org/c/openstack/nova/+/854616 | |
| 16:34:10 | opendevreview | Balazs Gibizer proposed openstack/nova master: Test reschedule with PCI in placement https://review.opendev.org/c/openstack/nova/+/854626 | |
| 16:34:10 | opendevreview | Balazs Gibizer proposed openstack/nova master: Support same host resize with PCI in placement https://review.opendev.org/c/openstack/nova/+/854441 | |
| 16:34:12 | opendevreview | Balazs Gibizer proposed openstack/nova master: Allow enabling PCI scheduling in Placement https://review.opendev.org/c/openstack/nova/+/854924 | |
| 16:34:12 | opendevreview | Balazs Gibizer proposed openstack/nova master: Test multi create with PCI in placement https://review.opendev.org/c/openstack/nova/+/854663 | |
| 16:34:14 | opendevreview | Balazs Gibizer proposed openstack/nova master: Doc follow up for PCI in placement https://review.opendev.org/c/openstack/nova/+/855186 | |
| 16:34:14 | opendevreview | Balazs Gibizer proposed openstack/nova master: Follow up for the PCI in placement series https://review.opendev.org/c/openstack/nova/+/855185 | |
| 16:36:57 | opendevreview | Balazs Gibizer proposed openstack/nova master: Drop InstanceEventFixture https://review.opendev.org/c/openstack/nova/+/855262 | |
| 16:37:34 | sean-k-mooney | elodilles: ya those all passed locally with py39 | |
| 16:37:48 | sean-k-mooney | ill run them a few times but i think that just an intermitent failrue perhaps | |
| 16:38:46 | gibi | dansmith: if you could +A https://review.opendev.org/c/openstack/nova/+/816157 then we could start landing the rebuild bfv too | |
| 16:42:48 | gibi | I go get some fresh air but I will check back later to see if my +2 is needed somewhere | |
| 16:55:17 | dansmith | gibi: I said above, but I haven't reviewed that one at all | |
| 16:55:32 | dansmith | and I think melwitt did, so probably best to let her ack it | |
| 16:56:18 | dansmith | let's give her a few hours but if she doesn't pop up today maybe I can review it enough to ack it | |
| 16:56:35 | elodilles | sean-k-mooney: hmmmm, looks strange. the difference is some alignment on the title of the tables. thanks, i'll try to look into it tomorrow. | |
| 17:07:43 | sean-k-mooney | they passed locally so ill recheck the first patch and see | |
| 17:12:36 | gmann | bauzas: just a heads up, your PTL nomination patch still showing WIP/merge conflict, may be you need to reabase on master ? https://review.opendev.org/c/openstack/election/+/852630 | |
| 17:19:03 | sean-k-mooney | im going to go get somethign to eat i might do some reviews later | |
| 17:29:20 | gibi | dansmith: ack | |
| 18:30:53 | dansmith | gibi: ah crap, I dunno why my delete of that instance event file didn't work | |
| 18:32:05 | dansmith | ah, my over-use of shell macros I bet | |
| 18:32:32 | opendevreview | Dan Smith proposed openstack/nova master: Add API support for rebuilding BFV instances https://review.opendev.org/c/openstack/nova/+/830883 | |
| 18:32:51 | dansmith | gibi: as you said, we might as well keep working on the top patch until it gets closer to the bottom, so ^ | |
| 18:46:03 | gibi | dansmith: sure, I abandoned mine | |
| 18:46:18 | gibi | and put the +2 back to the top of bfv | |
| 18:55:55 | dansmith | gibi: I'm about to commit some comments on the user_data patch, | |
| 18:55:58 | dansmith | can you have a look? | |
| 18:57:51 | dansmith | gibi: specifically this: https://review.opendev.org/c/openstack/nova/+/816157/comments/f31f7593_ff5dd9fc | |
| 18:58:03 | dansmith | isn't this just using instance sysmeta to avoid an RPC bump? | |
| 18:58:21 | dansmith | and thus it's side-stepping any RPC or object versioning we'd normally have for something like this? | |
| 18:58:39 | dansmith | rebuild is basically growing a new feature, and we need to pass it a flag, | |
| 18:58:57 | dansmith | but instead of the flag and version bump, we're stashing it in instance sysmeta | |
| 18:59:09 | dansmith | which means we can't fail the call with "sorry we're pinned to RPC 6.1 so we can't do that right now" | |
| 18:59:13 | dansmith | sean-k-mooney: ^ | |
| 19:01:21 | sean-k-mooney[m] | the orginal idea was to allow updating the user data and then regenerate the config drive the next time we reboot the instance | |
| 19:01:49 | dansmith | but that's not how it's implemented now right? | |
| 19:01:50 | sean-k-mooney[m] | although i think we changed our mind and blocked update with config drive | |
| 19:01:57 | dansmith | right | |
| 19:02:23 | sean-k-mooney[m] | so im not sure why we are blocking it now | |
| 19:02:41 | sean-k-mooney[m] | but that is why it was done that way | |
| 19:02:42 | dansmith | why does hard reboot not just always regenerate config drive? | |
| 19:02:48 | sean-k-mooney[m] | no | |
| 19:02:56 | sean-k-mooney[m] | it does not do it today at all | |
| 19:03:05 | dansmith | I'm saying.. why not just make it regenerate always | |
| 19:03:14 | dansmith | instead of the dirty flag | |
| 19:03:44 | dansmith | then you get to say it's best-effort, based on compute and virt support for doing so | |
| 19:03:47 | sean-k-mooney[m] | that would need to pull the data form the db but i guess we could | |
| 19:04:05 | dansmith | so? | |
| 19:04:19 | sean-k-mooney[m] | just saying that the side effect | |
| 19:04:24 | dansmith | the way it is right now, you've basically created a shadow RPC interface with no versioning which also accumulates in the DB | |
| 19:04:26 | sean-k-mooney[m] | i think we wanted to aovid that | |
| 19:05:13 | sean-k-mooney[m] | im trying to think if there is any other downside to always doing it | |
| 19:05:34 | sean-k-mooney[m] | we added a trait to signel if the backend supprots regenerating it | |
| 19:06:07 | dansmith | yeah, which also requires that we ask placement if *we* support a thing, which seems kinda odd :) | |
| 19:06:26 | sean-k-mooney[m] | well its a compute capablity trait | |
| 19:06:32 | sean-k-mooney[m] | we have several like that | |
| 19:06:43 | dansmith | but we don't have to check placement for that right? | |
| 19:07:32 | sean-k-mooney[m] | am i dont think its in the api db so normally i think we do check placement | |
| 19:07:59 | dansmith | the ones that we use for scheduler filtering make sense of course, but I thought we wrote them somewhere we could get at them ourselves | |
| 19:08:00 | dansmith | anyway | |
| 19:08:08 | dansmith | the shadow RPC interface seems much worse to me | |
| 19:08:29 | sean-k-mooney[m] | i dont thikn its in the compute nodes table so im not sure where they would be | |
| 19:09:03 | sean-k-mooney[m] | i guess we were not really thinking of it as a rpc interface | |
| 19:09:11 | sean-k-mooney[m] | just some metadta on the instance | |
| 19:09:22 | sean-k-mooney[m] | but i see your point | |
| 19:09:25 | dansmith | well the test is, that if you ran this under grenade, | |
| 19:09:34 | dansmith | you'd allow the reboot with the new user data, but it wouldn't get honored | |
| 19:09:57 | sean-k-mooney[m] | for an un upgraded compute | |
| 19:10:01 | sean-k-mooney[m] | hum | |
| 19:10:11 | sean-k-mooney[m] | ya your right | |
| 19:10:13 | dansmith | so you go to a lot of work to return a fail to the API call if it's not honor-able, but then you'll quietly say "got it" and send it off to a compute that will ignore it :) | |
| 19:10:20 | sean-k-mooney[m] | so we would also neeed a compute service bump | |
| 19:10:27 | sean-k-mooney[m] | and min version check | |
| 19:10:37 | dansmith | not really, | |
| 19:10:43 | dansmith | the rpc pinning will handle that for you | |
| 19:11:09 | sean-k-mooney[m] | if we changed the hard reboot api with a new paramter | |
| 19:11:11 | dansmith | the auto pin will stick to the minimum supported version, and the rpcapi.py will raise if it can't send at v6.1 so you can error the api call | |
| 19:11:14 | dansmith | right | |
| 19:11:15 | sean-k-mooney[m] | or always rebuit as you said | |
| 19:11:30 | dansmith | if we always rebuild, then we need a service version and check, | |
| 19:11:40 | dansmith | because then you're assuming the compute will do a thing that it might not | |
| 19:11:53 | dansmith | letting rpc handle it is simpler and more direct | |
| 19:11:54 | sean-k-mooney[m] | yep that why i was thinink the check initally | |
| 19:12:06 | sean-k-mooney[m] | ya fair point | |
| 19:12:20 | sean-k-mooney[m] | how do you want to proceed | |
| 19:12:51 | dansmith | I dunno, it sucks that this is going to bump the bfv one too because it already touches rpc :/ | |
| 19:12:53 | dansmith | but this also seems very wrong | |
| 19:13:32 | dansmith | I can probably bang out the RPC change pretty quick | |
| 19:13:45 | dansmith | but it might push either of these into FFE territory, | |
| 19:13:48 | sean-k-mooney[m] | i feel like this is not the first time we have done it this way. but that does not me it was right before | |