| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2022-08-18 | |||
| 19:58:48 | sean-k-mooney | ok | |
| 19:59:01 | dansmith | but within any given service (and like inside a container) it's always the same value, that's the point | |
| 19:59:20 | sean-k-mooney | ack im just tring to see where i need to bump it | |
| 19:59:33 | dansmith | there, there's only one place | |
| 19:59:42 | sean-k-mooney | cool | |
| 19:59:49 | sean-k-mooney | just making sure | |
| 20:00:04 | dansmith | it's global in the code, but set on the service record in the database when a service updates its live-ness, which is why you can check it per-binary and per-host | |
| 20:00:19 | sean-k-mooney | ah ok | |
| 20:00:54 | sean-k-mooney | so the services intialise them selevs with the current value when the prcoess starts and that is used to set the value in the db | |
| 20:01:13 | sean-k-mooney | so if a node has a differnt value in the db you know if its older or newer | |
| 20:01:33 | sean-k-mooney | i was just expecting to see th constant direcly in teh compute manger | |
| 20:07:36 | dansmith | right, but we can use service versions for any of the other services as well | |
| 20:07:42 | dansmith | so it's per-service not just for compute | |
| 20:08:39 | sean-k-mooney | yep i tought we had a sperate counter per service | |
| 20:08:48 | sean-k-mooney | but i can see why we share one | |
| 20:09:03 | sean-k-mooney | as that way we dont need to check fi schulder is x and conductor is y | |
| 20:10:26 | dansmith | you could still have that situation, of course | |
| 20:10:43 | dansmith | but instead of checking conductor_version=x, you check binary=conductor,version=x | |
| 20:11:21 | sean-k-mooney | ya you could | |
| 20:11:37 | sean-k-mooney | but at least there would be 1 x value for all serviecs for a given feature | |
| 20:13:29 | dansmith | no | |
| 20:13:42 | dansmith | if you have an old conductor and a new conductor, you could have different versions for each | |
| 20:13:54 | sean-k-mooney | that not what i ment | |
| 20:13:54 | dansmith | it's really host=$host,binary=conductor,version=$x | |
| 20:14:06 | dansmith | that's the tuple to get the version of one service on one host | |
| 20:14:16 | sean-k-mooney | i can define 62 to mean we support vdpa hotplug migration | |
| 20:14:40 | sean-k-mooney | and if that needed to be check for the compute or conductor or schduler its still just is that service >= 62 | |
| 20:15:29 | dansmith | yes, for a given host,binary pair, or (all),binary if you want to wait until they're all ready, yes | |
| 20:15:35 | sean-k-mooney | yes each service instance for the conductor might be above or below it but by having a single counter i can corralate that 62 means "support feature X" | |
| 20:15:54 | dansmith | yeah | |
| 20:16:06 | sean-k-mooney | so im currently debating beteween checkign the specific source and dest | |
| 20:16:12 | sean-k-mooney | or min compute service version in the deployment | |
| 20:16:40 | sean-k-mooney | technically i just need the specific ones but i would prefer to wait till your fully upgrade so min is tempting | |
| 20:17:45 | dansmith | yeah, min is pretty easy to understand and hard to screw up :) | |
| 20:18:35 | sean-k-mooney | yep ill go with that | |
| 20:19:33 | sean-k-mooney | if i do min i can actully do the check in the api instead | |
| 20:20:37 | sean-k-mooney | if instnace has vdpa ports and version <62 raise 400 | |
| 20:30:00 | opendevreview | Merged openstack/nova master: virt: Add ephemeral encryption flag https://review.opendev.org/c/openstack/nova/+/760455 | |
| 20:38:50 | opendevreview | sean mooney proposed openstack/nova master: [WIP] Add VDPA support for suspend and livemigrate https://review.opendev.org/c/openstack/nova/+/853704 | |
| 20:39:32 | sean-k-mooney | ok ill finish the docs and release note on ^ tomorrow but basically that seriese is code complete and ready for reveiw | |
| 20:39:47 | sean-k-mooney | im going to call it a night there and pick it up again tomrrow | |
| 20:44:43 | opendevreview | Jay Faulkner proposed openstack/nova stable/wallaby: Ignore plug_vifs on the ironic driver https://review.opendev.org/c/openstack/nova/+/821349 | |
| #openstack-nova - 2022-08-19 | |||
| 00:08:51 | opendevreview | Takashi Natsume proposed openstack/placement master: Move implemented specs for Xena and Yoga release https://review.opendev.org/c/openstack/placement/+/853730 | |
| 02:48:35 | opendevreview | Merged openstack/nova master: Unify placement client singleton implementations https://review.opendev.org/c/openstack/nova/+/852900 | |
| 02:48:44 | opendevreview | Merged openstack/nova master: Avoid n-cond startup abort for keystone failures https://review.opendev.org/c/openstack/nova/+/852901 | |
| 03:47:54 | opendevreview | Merged openstack/nova master: scheduler: Add an ephemeral encryption pre filter https://review.opendev.org/c/openstack/nova/+/760456 | |
| 08:02:38 | opendevreview | Merged openstack/nova master: Test attached volume extend actions in the nova-next job https://review.opendev.org/c/openstack/nova/+/843700 | |
| 09:25:42 | sean-k-mooney | by the way i dont know if i have explained how im using Review-Prioity +1 and +2 but im adding my +2 if im going to priotities it and i would like others too also and im adding +1 when i am going to review it and it woudl be nice if other reviewed it but im not asking other cores to go out of there way to prioritise it i.e. its a nice to have | |
| 09:26:28 | sean-k-mooney | im also not alwasy setting it, im just setting it on patches that are either imporant or have not reablly been reviewed in a while to highlight them to others | |
| 09:27:30 | sean-k-mooney | for example i dont think this backport is critical https://review.opendev.org/c/openstack/nova/+/821349 but it would be nice to land sooner rather then later so RP +1 | |
| 09:29:05 | sean-k-mooney | stephenfin: by the way im currently working on the final patch in the vdpa seriese would you have time to review the first 3. i just need to add a release note and update the docs in the last patch and its also done | |
| 09:43:31 | stephenfin | sean-k-mooney: sure (y) | |
| 09:44:21 | sean-k-mooney | stephenfin: just pushing the last patch now once i fix the commti message so it should be ready by the time you get to it | |
| 09:46:26 | opendevreview | sean mooney proposed openstack/nova master: Add VDPA support for suspend and livemigrate https://review.opendev.org/c/openstack/nova/+/853704 | |
| 09:47:21 | sean-k-mooney | gibi: ^ that should be ready for your review too. if ye have comments ill respin them collectinvly once ye have complete reviewing the whole sereise later today | |
| 09:49:52 | gibi | sean-k-mooney: ack, I will do a review round on it today | |
| 09:50:10 | sean-k-mooney | oh i have to fix 1 thing in the last patch for the compute service bump so ill respin that quickly | |
| 09:50:34 | gibi | (today I spent hours in a rabbit hole spreading provider mapping around the claim code, but now I'm backing out of it as it is a dead end) | |
| 09:54:11 | opendevreview | sean mooney proposed openstack/nova master: Add VDPA support for suspend and livemigrate https://review.opendev.org/c/openstack/nova/+/853704 | |
| 09:54:42 | sean-k-mooney | i think you should just need to pass them to filter_pools | |
| 09:55:07 | sean-k-mooney | i.e. if you have the provider uuid in the pool filter pools can jsut filter to the ones it the alloctiaons | |
| 09:55:50 | sean-k-mooney | although that is proably over simplfying | |
| 09:56:36 | sean-k-mooney | i woudl be tempted to extend the pci request object to carry the RP infor that it shoudl be fullfiled form | |
| 09:56:50 | sean-k-mooney | and then use that latter when we are doing the filtering /caliming | |
| 09:57:07 | sean-k-mooney | gibi: would something like ^ work better | |
| 09:57:29 | sean-k-mooney | that woudl avoid chaning the sigurtures of any of the fuctions | |
| 09:57:38 | gibi | yeah I'm on this track | |
| 09:57:49 | gibi | the filter_pools needs it | |
| 09:58:01 | gibi | and we call that from 3 different places | |
| 09:58:08 | sean-k-mooney | but you would have to update teh request objecject before calling support/consume/apply | |
| 09:58:20 | gibi | 1) during scheduling (there we hace an allocation candidate to work with) | |
| 09:58:35 | gibi | 2) during claim (there we have the request spec to work with probably) | |
| 09:58:46 | gibi | 3) during consume (that is a big rabbit hole :D) | |
| 09:58:51 | gibi | but you are right | |
| 09:59:02 | gibi | the InstancePCIRequest could carry the PR uuid | |
| 09:59:15 | gibi | _after_ the scheduler made the allocation in placement | |
| 09:59:20 | gibi | as that is then fixed | |
| 09:59:24 | sean-k-mooney | well if save the updated request object after 1 when we claim the allcoation candiate then 2 and 3 can just read it from there | |
| 09:59:31 | sean-k-mooney | yep | |
| 09:59:31 | gibi | yes | |
| 09:59:59 | sean-k-mooney | so i think that will work out cleanly in the end | |
| 10:00:02 | gibi | we did something similar for QoS with the parent_ifname tag in the InstancePCIRequest | |
| 10:00:24 | sean-k-mooney | ah yes that is indeed similar | |
| 10:00:44 | sean-k-mooney | as that narrowed the set of pools to consider | |
| 10:00:45 | gibi | the RP uuid is actually cleaner | |
| 10:01:01 | opendevreview | Merged openstack/nova stable/xena: add regression test case for bug 1978983 https://review.opendev.org/c/openstack/nova/+/853218 | |
| 10:01:01 | gibi | so eventually we can refactor the QoS path to use that too | |
| 10:01:17 | sean-k-mooney | yep | |
| 10:01:40 | sean-k-mooney | once we start populating the rp uuid in the pci device tabel and pci_stat pools | |
| 10:02:10 | sean-k-mooney | for the pci devices are you going to add a new column for the rp_uuid | |
| 10:02:18 | sean-k-mooney | or just put it in the extra info column | |
| 10:02:26 | sean-k-mooney | i woudl be tempted to do the former | |
| 10:02:50 | sean-k-mooney | for the pools i would just put it in the json blob | |
| 10:03:00 | gibi | at the moment I don't see where I need the rp_uuid from the pci device, when I will see that I can consider this | |
| 10:03:12 | gibi | for the pools it is probably the blob | |
| 10:03:30 | sean-k-mooney | ya so i dont think we will evern need to do an sql query on the pools | |
| 10:03:38 | sean-k-mooney | that will alway be processed in python | |
| 10:03:53 | gibi | I thinks so too | |
| 10:03:56 | sean-k-mooney | but the pci devices it would be nice to have them correalated with the placment rp | |
| 10:04:34 | sean-k-mooney | so it would be nice to put it at least in extra_info blob | |