| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2022-06-16 | |||
| 10:37:54 | gibi | OK, then I look up running migrations for reshape | |
| 10:38:06 | gibi | and pair them to PciDevs | |
| 10:38:18 | gibi | as I have to heal the allocation for the running migrations too | |
| 10:38:19 | sean-k-mooney | the instance uuid should be set to the instance uuid on both hosts | |
| 10:38:25 | gibi | ack | |
| 10:38:29 | gibi | that what I guessed | |
| 10:39:05 | sean-k-mooney | i think the corralation is done via the migrate_data object which is only in memory | |
| 10:39:16 | sean-k-mooney | although you can just look at the relevent host form the migration object | |
| 10:39:30 | sean-k-mooney | to know which one it belongs too | |
| 10:39:39 | sean-k-mooney | e.g migration vs instance | |
| 10:39:56 | gibi | yeah something like that | |
| 10:40:21 | sean-k-mooney | that reminds me we still do not use consumer types | |
| 10:40:50 | sean-k-mooney | that is out of scope but ya | |
| 10:41:18 | sean-k-mooney | are we going to have a reshape in the future that will move all migrations to the migration consumer type | |
| 10:44:46 | gibi | we should have add that yes | |
| 10:45:33 | sean-k-mooney | thats what i assuemd but i dont recall if the placment spec actully spoke about how nova or other porjects would use them once the feature was added | |
| 10:45:52 | gibi | me neither | |
| 10:45:53 | sean-k-mooney | so i was not sure if we woudl do a reshape or just stat using the consumer type for new migrations | |
| 10:46:12 | gibi | I think reshape would be better | |
| 10:46:19 | sean-k-mooney | and let it heal over time as old migration get compelte/aborted. | |
| 10:46:30 | sean-k-mooney | it would be cleaner for sure | |
| 10:46:54 | sean-k-mooney | but proably a nova manage command so that it does not have any impact on rolling upgrade | |
| 10:47:14 | sean-k-mooney | although old nova will proably ignore the type so i might be over thinking it | |
| 10:47:34 | sean-k-mooney | future us problems | |
| 10:50:11 | gibi | yepp | |
| 10:53:05 | gibi | \one more architectural difference for today: for pci it cannot be decided if reshape is needed without checking existing nova allocations of pci also exists in placement too. As during rolling upgrade new pci allocations can arrive to a compute without placmeent allocation | |
| 10:53:32 | gibi | so for pci we will do periodic healing | |
| 10:53:37 | gibi | instead of a one time reshape | |
| 10:56:18 | sean-k-mooney | fun | |
| 10:56:27 | sean-k-mooney | is that not the case for cpus? | |
| 10:57:18 | sean-k-mooney | the reshape will be tied to the pci/repot_to_placement conf or whatever it was right | |
| 10:58:06 | sean-k-mooney | so this will be skiped if that is not set | |
| 11:10:48 | gibi | it seems for cpus we did not needed this | |
| 11:11:17 | sean-k-mooney | im not really sure why it woudl be differnt | |
| 11:11:32 | gibi | yes, the whole tracking and reshape code starts with an if not CONF.pci.report_in_placement: return | |
| 11:12:14 | gibi | sean-k-mooney: for cpus we do two a_c queries to enforce allocation if placement has inventory | |
| 11:12:29 | sean-k-mooney | oh the fallback query | |
| 11:12:31 | gibi | and fall back to legacy query | |
| 11:12:32 | gibi | yeah | |
| 11:12:39 | sean-k-mooney | i mean we can do that for pci | |
| 11:12:42 | sean-k-mooney | if we want too | |
| 11:13:45 | sean-k-mooney | i guess that does nto really work the same if we use a prefilter | |
| 11:13:57 | sean-k-mooney | we had to do some extra chagnes for the fallback | |
| 11:14:23 | gibi | periodic healing feels less complex to me code wise | |
| 11:14:31 | sean-k-mooney | ack | |
| 11:15:22 | gibi | I also would like make the healing code accessible from nova-manage | |
| 11:15:56 | gibi | healing / audit | |
| 11:16:09 | gibi | basically the same code can tell if something is missing and also can fix it | |
| 11:16:20 | gibi | or delete if there are overallocations in placement | |
| 11:23:45 | sean-k-mooney | yep that makes sense too | |
| 11:24:37 | sean-k-mooney | personally i think we should merge audit and heal by the way or at least move the delete allcoation logic form audit to heal | |
| 11:25:02 | sean-k-mooney | audit is very very badly named | |
| 11:25:08 | gibi | yepp | |
| 11:25:10 | gibi | I agree | |
| 11:25:23 | gibi | we need only one CLI to check and fix | |
| 11:25:40 | sean-k-mooney | yep basicaly one command with a dry run mode | |
| 11:26:00 | sean-k-mooney | that just prints the problems that would be fixed | |
| 11:26:46 | sean-k-mooney | but does not actully do them, if you are happy drop --dry-run or add --apply whatever way we want to set the default | |
| 11:28:11 | jkulik | may I ask, how do you run nova-manage? Do you have the config to access stuff "locally" or do you connect to some VM/container containing nova-api or something or do you have a special "manage" host/container for that? | |
| 11:28:31 | sean-k-mooney | you normlaly ssh to one of your contolers | |
| 11:28:34 | sean-k-mooney | and run it form there | |
| 11:28:52 | sean-k-mooney | but you can run it locally with configs yes if you need too | |
| 11:29:30 | sean-k-mooney | if you are using something like kolla you would do an exec into the contaienr to run it yes | |
| 11:29:33 | jkulik | ok. thanks. always felt a little wrong to me. why does it have to be a CLI and not an admin api? | |
| 11:30:13 | sean-k-mooney | the api process does not have access to everything that is needed to run it | |
| 11:31:11 | sean-k-mooney | jkulik: im sure you dont really want to be sendign you db/rabit password over a rest api request in general too | |
| 11:31:29 | opendevreview | Merged openstack/os-vif master: Drop lower-constraints.txt and its testing https://review.opendev.org/c/openstack/os-vif/+/840020 | |
| 11:32:10 | sean-k-mooney | jkulik: there would be ways to have apis do similar things but you need to use nova-manage to bootstrap things like the db | |
| 11:32:23 | jkulik | sean-k-mooney: you mean for setting up cells? otherwise, both are in the db | |
| 11:32:42 | sean-k-mooney | doing offline db migrations | |
| 11:33:03 | sean-k-mooney | openstack and nova in this case genreal requried all contoler process to agre on the db schema | |
| 11:33:47 | jkulik | hm ... yeah, didn't think about those. fair point, that there are definitely commmands that can't go via API | |
| 11:34:01 | sean-k-mooney | the cell info is generaly in the db yes but if you are using templated db/rabbit urls in the db the passwords come form the nova.config | |
| 11:34:32 | jkulik | oh. I didn't know about that possibility | |
| 11:35:12 | sean-k-mooney | https://docs.openstack.org/nova/latest/admin/cells.html#template-urls-in-cell-mappings | |
| 11:35:33 | sean-k-mooney | jkulik: they are optional | |
| 11:35:57 | sean-k-mooney | but they were created to make doing password rotation simplere with config tools like ansible | |
| 11:36:13 | sean-k-mooney | since you just need to update the configs and the passward on the db | |
| 11:36:34 | sean-k-mooney | that and to not store passwords in plain text in the db | |
| 11:36:44 | jkulik | yeah, immediately wondering if we want that, too | |
| 11:36:53 | jkulik | downstream I mean | |
| 11:37:12 | sean-k-mooney | in which downstream | |
| 11:37:35 | jkulik | I mean in our installations of Nova. sorry for the confusing wording | |
| 11:37:39 | sean-k-mooney | tripleo uses it by defualt i think | |
| 11:37:50 | jkulik | we have a helm-chart to deploy Nova | |
| 11:37:56 | sean-k-mooney | ah ok | |
| 11:38:09 | sean-k-mooney | i dont know if openstack ansible or kolla ever addopted it | |
| 11:38:22 | sean-k-mooney | but ya its up to each installer | |
| 11:47:44 | sean-k-mooney | gibi: just because i happen to be looking at the code do you knwo why we dont allwo you to plug in image_types backends using stevador extention points like we do for filteres? | |
| 11:47:57 | sean-k-mooney | i just noticed it was a dict https://github.com/openstack/nova/blob/93a65f06df67ce39d65827692150c78013c7f6d5/nova/virt/libvirt/imagebackend.py#L1286-L1294= | |
| 11:48:20 | gibi | I think nobody asked for it | |
| 11:48:42 | gibi | also we removed a bunch of extension points in the past | |
| 11:48:47 | gibi | so we might not want to add more | |
| 11:49:07 | gibi | but technically we could add one | |
| 11:49:29 | sean-k-mooney | ya i know proably more then we should have but that would be one way to allow people to play with a bfv backend and protype it. | |
| 11:50:06 | sean-k-mooney | the image ABC is intneded to define the api https://github.com/openstack/nova/blob/93a65f06df67ce39d65827692150c78013c7f6d5/nova/virt/libvirt/imagebackend.py#L81= | |
| 11:51:08 | sean-k-mooney | gibi: or for example add the ablity to use libvirt sotorage pools. | |
| 11:51:47 | sean-k-mooney | although im relaly not sure how solid that interface actully is | |
| 11:52:09 | gibi | but why this needs to be an extension why cannot be just proposed to nova as a backend? | |
| 11:53:03 | sean-k-mooney | because if its an exstion we can easilly move backend we dont like out of tree | |