Earlier  
Posted Nick Remark
#openstack-nova - 2021-02-10
20:41:34 sean-k-mooney that said i have been used to sub 20 min stack times basiclay for ever due to how i use it but 5-10 min stack times is still great
20:41:55 dansmith yep, very non-trivial savings multiplied across every job runm
20:42:02 dansmith and local dev time improvement is huge
20:42:40 sean-k-mooney ya i used to lement not being able to use offline mode or wehn i could not just restart the service due to db changes
20:43:11 sean-k-mooney but if its that quick honestly i would restack more often then i do
20:43:15 dansmith 5 minutes is on the order of "hang on let me stack so I can answer that CLI usage question in realtime"
20:43:33 sean-k-mooney yep
20:44:22 sean-k-mooney i have done that in meeting wtih a 15min time but 5 mins is shorter then ill stack this while i get coffee
21:47:37 sean-k-mooney is the build_requests table in the api db used anymore?
21:47:50 sean-k-mooney it seams to always be empty
21:48:42 sean-k-mooney maybe we automatically delete the entry once it builds
21:50:58 atmark hello, is it possible to rename a cell ?
21:52:03 sean-k-mooney cell0 no the other cells im not sure
21:52:35 sean-k-mooney without db change i dont think there is any nova manager command you can updated
21:54:19 sean-k-mooney the host_mappings just use the cell_id im not sure what if anything uses the cell name corm the cell_mappings tables
21:54:23 artom atmark, also, *why*?
21:56:26 sean-k-mooney ya even if you can do it you proably should not do it unless you have a good reason too
21:57:48 sean-k-mooney i belive we map cells to placment aggreates at some point. im not sure if that is by name or by id but i would not assume there is nothing that depends on the cell name without fully checking
21:59:29 sean-k-mooney you cant rename Avaiableity zones with out breaking things for example. gratted they exists at the api level and cells do not but the cell name might be storeed somewhere although we should really be usign the id.
22:02:31 gmann stephenfin: done. +A
22:12:49 openstackgerrit Merged openstack/nova master: libvirt: Always enable USB controller on PPC64 https://review.opendev.org/c/openstack/nova/+/773728
22:13:38 openstackgerrit Ghanshyam proposed openstack/placement master: Move policy deprecation to base rules https://review.opendev.org/c/openstack/placement/+/772784
22:15:30 gmann stephenfin: updated this for reshaper policy - https://review.opendev.org/c/openstack/placement/+/772784
23:11:22 openstackgerrit Ghanshyam proposed openstack/nova master: Switch to new rolevar for run-temepst role https://review.opendev.org/c/openstack/nova/+/775040
23:27:36 sean-k-mooney oh dead code i can channel my inner stephenfin and delete it :)
23:28:28 sean-k-mooney the only thin that uses _load_legacy_requests is get_by_instance and the only thing that uses that is test code
23:28:30 sean-k-mooney https://github.com/openstack/nova/blob/5b52db409b00e6257e83598efa0d8528ebe380e0/nova/objects/instance_pci_requests.py#L116-L146
23:28:45 sean-k-mooney we use get_by_instance_uuid instead now
23:29:25 sean-k-mooney since we started storign the request spec in teh api_db like 4? 5? cycles ago
23:29:47 sean-k-mooney its been a very long time since it was stored in teh instace_system_metadata table
23:31:00 sean-k-mooney i think maybe melwitt moved it back in queens/rocky? maybe older then that
23:32:41 melwitt sean-k-mooney: afaik request spec has always been in the api db i.e. it didn't exist prior to that. I didn't move anything related to it :)
23:33:42 sean-k-mooney its existed since like juno it was made an object back in 2014 https://github.com/openstack/nova/commit/2d998c8df2048167c2db3694d3aae4605ff2625c
23:34:38 melwitt I mean request spec
23:34:57 sean-k-mooney oh sorry i said request spec
23:35:07 sean-k-mooney i ment instace_pci_request
23:35:34 sean-k-mooney sorry im currently trying to figure out why the numa policy i am setting is not makeing it to the db
23:36:43 sean-k-mooney when i grab it out of the db {"count": 1, "spec": [{"physical_network": "public"}], "alias_name": null, "is_new": false, "numa_policy": null, "request_id": "6ca3ee2f-59d7-4828-b95a-f503f7eb261d", ...
23:37:11 melwitt are you doing like request_spec.pci_requests = <stuff> and then request_spec.save()?
23:37:29 sean-k-mooney the instance_extra table to be exact its reset to null
23:37:34 melwitt how are you setting them
23:37:40 sean-k-mooney am im not doing the save but ill show you one sec
23:38:38 sean-k-mooney https://review.opendev.org/c/openstack/nova/+/773792/1/nova/network/neutron.py#2151
23:39:12 sean-k-mooney we are modifying it just above too spec[pci_request.PCI_TRUSTED_TAG] = str(trusted)
23:39:44 sean-k-mooney no not quite
23:39:51 sean-k-mooney the oter values are all passed in
23:40:03 melwitt oh, I can see this object doesn't work like the typical
23:40:28 sean-k-mooney well it should get commits with the rest of the requests
23:40:40 sean-k-mooney create_resource_requests
23:41:01 sean-k-mooney is invoked during the build process and we pass back a set of resouce requests
23:41:41 sean-k-mooney technically i gues there realy is no reason i could not pass the affinity policy to the consturor i guess
23:41:53 sean-k-mooney but what im doing should work
23:42:56 melwitt generally, the pci tracker is the thing that writes all pci related things to the db, so my first thought is maybe it doesn't handle numa_policy yet?
23:45:18 sean-k-mooney i really hope https://github.com/openstack/nova/commit/59d94633518e6f6272e9f0654bb908e332f97a96 added that
23:45:38 sean-k-mooney or else i have to talk to stephenfin about his commit naming
23:45:42 melwitt oh, hm
23:45:46 melwitt lol
23:47:20 sean-k-mooney i mean i know im missing unit/functional tests in that change and when i add them i might find out why its not working but still
23:47:22 sean-k-mooney numa_policy = port_numa_policy or affinity_policy
23:47:24 sean-k-mooney if numa_policy:
23:47:26 sean-k-mooney request.numa_policy = numa_policy
23:47:29 sean-k-mooney that should work
23:48:31 melwitt yeah.. I don't see anything either
23:49:45 sean-k-mooney i think tomorrow ill just start writing a functional test. i need to anyway but i was hoping to test it manually once first to make sure it worked
23:50:07 sean-k-mooney because its being lost before it gets to the db it does not.
23:50:08 melwitt seems like it would have to mean port_numa_policy or affinity_policy are both None?
23:50:19 sean-k-mooney yep
23:50:26 sean-k-mooney affinity_policy is None
23:50:28 melwitt or empty in some way
23:50:37 sean-k-mooney well none or empty ya
23:50:47 sean-k-mooney port_numa_policy in my testing is required
23:50:58 sean-k-mooney well
23:51:04 sean-k-mooney the policy on the port is required
23:51:22 sean-k-mooney that does not mean i dont have a different bug
23:52:10 sean-k-mooney im reading the value form the port here https://review.opendev.org/c/openstack/nova/+/773792/1/nova/network/neutron.py#2053
23:52:21 sean-k-mooney i fixed the spelling localy
23:52:29 melwitt is it possible is null or empty from neutron itself?
23:53:38 sean-k-mooney not any more alos https://review.opendev.org/c/openstack/nova/+/773792/1/nova/network/neutron.py#3039
23:53:43 melwitt or the constant is wrong?
23:54:07 sean-k-mooney i also extended the nova VIF object
23:54:20 sean-k-mooney to store it and if i look in the network info cache its set to required
23:54:32 sean-k-mooney and i create the port before i booted the vm
23:54:40 sean-k-mooney so i could check it was set
23:54:57 sean-k-mooney so the VIF object makes it to the db fine
23:55:01 melwitt oh ok. hrm
23:55:12 sean-k-mooney ya its weird
23:55:36 sean-k-mooney i did spell consttants wong but thats what i fixed locally
23:55:56 sean-k-mooney oh....
23:56:05 sean-k-mooney that would do it https://review.opendev.org/c/openstack/nova/+/773792/1/nova/network/neutron.py#2039
23:57:04 sean-k-mooney if i dont ask for the field... then my numa_policy = port.get(consttants.NUMA_POLICY, None) is always going to be None
23:57:47 sean-k-mooney we normlly dont filter like that so i never check for it
23:58:10 melwitt oh oops
23:58:42 melwitt at least you found it :)
23:58:46 sean-k-mooney yep
23:59:07 sean-k-mooney i did have a probalem before where i also forgot to trun the extention on in neutorn fully
23:59:38 sean-k-mooney so i would create the port, osc would show the policy in the port in the respocne but neutorn never saved it to the db on its end
#openstack-nova - 2021-02-11
00:00:30 melwitt sounds like good times all around
00:00:49 sean-k-mooney neutron list all exteions that are avaiabel not just the ones that are enabled which is __tottaly__ inutitive and not confusing at all....
00:01:32 sean-k-mooney im not sure what the best way to express sarcasium is on irc
00:01:38 melwitt yeah.. whenever I wander into other projects code where they still have extensions, it confuses me

Earlier   Later