Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2019-08-07
15:34:08 efried we continue to say you can't specify that.
15:34:16 sean-k-mooney we guarentee it will come form one of the numa ndoes the vm is mapped too
15:34:37 sean-k-mooney but we give no garuntee it on a specific guest numa node
15:34:48 gibi efried: if nova keeps handling the VFs then nova can do a VF-NUMA affinity. Bandwidth is already tied to VF today in case of SRIOV.
15:35:02 sean-k-mooney currently its always preseneted as if its attache to guest numa node 0 regradelss of what host numa node it came from
15:35:05 efried and we can give the requests for NUMA nodes and VFs generic known suffixes, and use same_subtree to tie them together.
15:35:16 efried perfect
15:35:20 sean-k-mooney i also want to chagne that but not in a way tha will impact placmenet or shcudleing in any way
15:35:40 efried Yeah, let's not give any more granular control over that
15:35:47 efried cause then we would have to support it via placement :)
15:36:06 efried Okay, it's the middle of the night for huaqiang, let's wrap up and yield the floor...
15:36:17 sean-k-mooney efried: what i want to add i the use of a livirt feature that allows mupliple pci roots in the guest
15:36:34 huaqiang sean-k-mooney: got the comments for the 'using PCPU VCPU in one instance', thanks
15:36:52 sean-k-mooney that will allwo us to attach the pci device to the virtual numa node that maps to the host numa node the deive is on
15:37:16 huaqiang but I checked the existing logic for 'hw:cpu_policy=dedicated' and 'hw_cpu_policy=shared', the final policy is 'dedicated'
15:38:06 sean-k-mooney can you show me that in code
15:38:18 huaqiang sure
15:39:27 sean-k-mooney its this https://github.com/openstack/nova/blob/master/nova/virt/hardware.py#L1327-L1338
15:39:55 sean-k-mooney ok we do perfer the flavor over the image in that case
15:40:11 huaqiang you find it!
15:40:28 sean-k-mooney ya i knew what code shoudl be enforcing it
15:40:42 sean-k-mooney its incositent with how we handel hw:cpu_threads_policy
15:40:44 sean-k-mooney https://github.com/openstack/nova/blob/master/nova/virt/hardware.py#L1370-L1377
15:41:09 sean-k-mooney and numa topligies https://github.com/openstack/nova/blob/master/nova/virt/hardware.py#L1290
15:41:27 sean-k-mooney had thought we had made it an error for all conflitc at this point
15:42:07 sean-k-mooney we can chagne that without at least 1 cycle to deprecate the old behavior so i guess we have to stick with the current behavior
15:42:58 sean-k-mooney huaqiang: it would be good to add a warning here https://github.com/openstack/nova/blob/master/nova/virt/hardware.py#L1328 as i dont think that is what people expect
15:43:12 huaqiang so you mean the flavor first behavior
15:43:17 sean-k-mooney yes
15:43:41 sean-k-mooney we started moving to raising exception if they conflict for most of these value a whiel ago
15:43:55 sean-k-mooney at least when adding new values
15:44:27 sean-k-mooney i guess we did not change older values proably due to upgrade concerns
15:45:23 huaqiang so for the new 'mixed' policy, we need consider conflict as invalid
15:45:53 huaqiang but for 'dedicated' and 'shared' conflicts we follow the rule that flavor first
15:45:54 sean-k-mooney well we have a choice
15:46:31 sean-k-mooney my perference would be to consider all conflcit of hw:cpu_policy and hw_cpu_policy to be invalid and raise an exception
15:46:37 sean-k-mooney but since we cant do that htis cycle
15:46:44 sean-k-mooney its better to be consistent i think
15:47:06 sean-k-mooney it would be nice to issue a warning if we detect a conflict however
15:47:10 huaqiang I am good for both
15:47:37 huaqiang ok
15:48:04 huaqiang another thing i don't know if you noticed that
15:48:19 huaqiang hw:cpu_realtime exists
15:48:37 huaqiang but there is no 'hw_cpu_realtime' in image properties
15:48:59 huaqiang this is different with the mask for dedicated cpus
15:49:41 huaqiang Alex mentioned this difference, and cpu realtime mask has a more loose rules
15:50:23 sean-k-mooney yes we did not want to allow users to request realtime guest via the image
15:50:33 sean-k-mooney but we did allow the mask i belive
15:50:48 huaqiang mask is allowed from both image and flavor
15:51:01 sean-k-mooney so you can only enabel realtime cpus via the flavor but both the flavor and image can set the mask
15:51:15 huaqiang that is the truth
15:52:01 sean-k-mooney we have allowed image to enable cpu pinning provided the the flavor has not forbiding it by setting hw:cpu_policy=shared
15:52:35 sean-k-mooney so i think its fine wto allow hw_cpu_policy=mixed give hw_cpu_policy=dedicated is alredy allowed
15:52:55 sean-k-mooney similarly i think having the mask in the image and flavor is ok
15:53:11 mkrai Hi Nova team, I am working on implementing the resize API for baremetals and need some help in the design. I tried to put an initial design here https://etherpad.openstack.org/p/nova-resize-ironic-api
15:53:20 sean-k-mooney but im sure someone else has an opipion on that ^ its what the spec currently say however
15:54:15 gibi sean-k-mooney: left comment in https://review.opendev.org/#/c/674072 about the notification tests
15:54:16 huaqiang yes, dansmith is questioned on the masks
15:54:58 sean-k-mooney gibi: thanks i can never rememebr where that is
15:55:18 mkrai efried, sean-k-mooney mriedem alex_xu could you please take a look?
15:55:21 sean-k-mooney im fixing other typos but was about to spend the next hour finding it
15:55:24 efried mkrai: Hi there. I recall mriedem had some ideas about that design. dansmith could probably provide some good input as well. To be clear, this is going to be a U release thing, you're just looking for initial design help?
15:55:35 sean-k-mooney mkrai: yes i have it open
15:55:37 gibi sean-k-mooney: we might improve the test to dump the file path when the assert fails
15:55:56 mkrai efried, Yes!
15:56:02 mkrai sean-k-mooney, Thanks!
15:56:22 huaqiang dansmith: hello
15:58:06 sean-k-mooney efried: mkrai could start on any ironic internal prep work that was need this cycle but the ironic driver changes would be next cycle i guess
15:59:16 mriedem i love being continually distracted about asking to review specs and plans and code for things that do not even have a chance for train
15:59:34 mkrai sean-k-mooney, I have already posted spec for the ironic reconfigure API that will be needed by the resize API
15:59:36 sean-k-mooney gibi: are you ok with https://review.opendev.org/#/c/674072 adressing bug: #179520 as a bugfix to the original spec
15:59:36 openstack bug 179468 in python-cups (Ubuntu) "duplicate for #179520 applet.py crashed with TypeError in on_job_hold_activate()" [High,Fix released] https://launchpad.net/bugs/179468 - Assigned to Pascal De Vuyst (pascal-devuyst)
15:59:36 mriedem meanwhile my mega cross-cell resize series is not getting review but has been up for 2 cycles
16:00:17 mkrai sean-k-mooney, https://review.opendev.org/#/c/672252/
16:00:29 mkrai I will add this link to the etherpad
16:00:54 efried mriedem: I'm going out on a limb and saying distraction is not the most significant factor in lack of reviews on cross-cell resize.
16:00:58 efried At least for me that's true
16:01:03 gibi sean-k-mooney: yeah I'm OK with that being a bugfix. Maybe a link to the original spec / bp in the commit message would help
16:01:07 sean-k-mooney mriedem: ^ that question is also to use as well are you ok with https://review.opendev.org/#/c/674072 adressing the feature gap in the orginal spec.
16:01:10 efried "I'm askeird" is the major reason
16:01:28 mriedem efried: i'm not saying it's a walk in the park
16:01:38 sean-k-mooney gibi: sure ill add one
16:01:46 efried fwiw, I have been intending to wade in
16:01:52 mriedem that's why i had integration testing of cross-cell resize working before putting out a review guide
16:01:55 efried but procrastinating successfully so far
16:02:13 mriedem which is more than i can say for a lot of the features we merge...
16:02:19 efried yeah yeah
16:02:33 mriedem i'm also a bit disappointed that cern hasn't been more involved
16:02:40 mriedem but they seem...distracted lately as well
16:03:09 mriedem sean-k-mooney: idk even know what https://review.opendev.org/#/c/674072 is about
16:03:18 mriedem but it looks like it's not fun
16:04:04 sean-k-mooney we only allow you to specify the numa affinity policy for pci device in teh pci alias. the spec origially had flavor and image properites for it
16:04:22 sean-k-mooney neutron sriov dose not use pci alias
16:04:24 mriedem which original spec
16:04:25 mriedem ?
16:04:42 sean-k-mooney so we entirely broke the original neuton port usecase.
16:04:47 sean-k-mooney one sec ill get it
16:05:14 mriedem "lack of a feature is not a bug"
16:05:19 sean-k-mooney https://github.com/openstack/nova-specs/blob/master/specs/queens/implemented/share-pci-between-numa-nodes.rst
16:05:27 sean-k-mooney https://github.com/openstack/nova-specs/commit/74b47ac2f968b13b7d15987063d0f52ecba02a7e#diff-b5d95cd01ee920f26b55b45f2777b7aa is wher whe chaned it

Earlier   Later