Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2019-03-01
14:35:01 giblet so we cannot prefer the candidate that keeps the port allocated from the same RP during resize-to-same-host
14:35:12 fried_rice sean-k-mooney: right: prefer candidates with [these ports]
14:35:17 fried_rice giblet: yes.
14:35:26 fried_rice we can't, but we should.
14:35:39 sean-k-mooney can you use in_tree to help
14:35:51 giblet fried_rice: soo we have to extend the filter interface to know about allocation candidates not just hosts
14:35:52 sean-k-mooney i guess that would force the same host
14:35:53 fried_rice well, we should be using in_tree for resize-to-same-host anyway.
14:36:07 fried_rice But that's unrelated to the problem of not moving the ports.
14:36:21 fried_rice giblet: I was just talking to mriedem about that the other day.
14:36:27 fried_rice and Sundar as well.
14:36:45 sean-k-mooney fried_rice: were we not talking about a subtree version too i dont know if we could restict the neutron request to the same RPs they had previously
14:36:57 fried_rice sean-k-mooney: Yes, there's a spec up for that.
14:36:59 sean-k-mooney i dont think the placement sysntax is that granuarly
14:37:03 giblet fried_rice: can we tell our preference to placement about return those a_c first that keeps the port allocated from the same RP?
14:37:03 fried_rice nope, not today.
14:37:19 fried_rice giblet: Not yet, but with the subtree thing we might be able to.
14:37:56 sean-k-mooney ya so resize to same host would basice add in_tree to the numbered requst group for the prot resouce or whatever the spec says
14:38:41 sean-k-mooney fried_rice: sound like a thing to solve in train
14:38:43 fried_rice Re allocation candidates to filters: I was thinking we ought to extend BaseFliter with a new method that accepts the allocation candidate under consideration, as well as the (relevant subset of the) provider_summaries. We do the try/except NotImplemented and fall back to the old method so we don't break existing filters. But new filters can then be written to take that information into account.
14:39:00 sean-k-mooney fried_rice: ya that came up before
14:39:22 giblet fried_rice: hm, do you have a link to subtree a_c spec?
14:39:27 fried_rice sec
14:40:12 sean-k-mooney fried_rice: i think passing the allcoation candiates to the filters/werigher makes sence.
14:40:46 fried_rice giblet: Hah, it's yours: https://review.openstack.org/#/c/595236/
14:41:12 giblet fried_rice: but that is subtree for GET /resource_providers not subtree for a_c
14:41:34 fried_rice mm, well, in the spirit of in_tree, we should implement it for GET /a_c as well.
14:42:10 fried_rice giblet: tetsuro has started code: https://review.openstack.org/#/c/636092/ (but for GET /rps)
14:42:17 sean-k-mooney fried_rice: i think that proably should be implemented at the resouce group level not the top level
14:42:19 giblet fried_rice: I haven't tought about that direction yet. The use case in my spec is purely to limit the amount of data neutron needs to read from placemente
14:42:46 fried_rice mriedem: Currently (merged code) does resize-to-same-host even use GET /a_c at all?
14:43:02 sean-k-mooney e.g. this requst_group must be form this sub tree
14:43:52 sean-k-mooney that would allow us to say the general request must be form the compute node sub tree but the neutron bandwith must be form the subtree of the ortinginal RP that the allcoation were form
14:44:11 fried_rice sean-k-mooney: just so. and/or should be from this exact provider. The latter would be better for the case we're talking about.
14:44:53 sean-k-mooney yes the formor would allow nesting to work better when we model sriov nics in placmeent
14:44:58 giblet wait, we don't want to force resize-to-same-host to only work for the same host. We still want to get back candidates for other hosts. So we cannot simply restrict the a_c querty to a given tree
14:45:02 giblet or subtree
14:45:35 fried_rice eh? By definition, resize-to-same-host is... to the same host. Isn't it??
14:45:41 giblet fried_rice: nope
14:45:43 sean-k-mooney both the bandwith request and vf request woudl be in the same group but they could be in different provdiers depending on how we model it
14:45:51 giblet fried_rice: it is a config option that allows resize to use the same host too
14:46:11 sean-k-mooney fried_rice: it does not gurarentee it
14:46:12 fried_rice I think mriedem is working on making it so? https://review.openstack.org/#/c/638791/
14:46:13 giblet fried_rice: allow_resize_to_same_host
14:47:20 sean-k-mooney fried_rice: by default we dont allow resize to same host. when you enable it in the nova.conf it just allows it as a candiate but unlees you also force the host it could be resized to a different host
14:48:16 sean-k-mooney fried_rice: mriedem is working on removing the double allocation problem in the case we actully do resize on the same host
14:48:31 fried_rice mm
14:49:45 fried_rice mriedem: In fact, do we even use GET /a_c for resize in general, or do we just build the new allocs by parsing the new flavor??
14:50:08 giblet there is a full scheduling for resize including a_c query
14:50:25 giblet only rebuild has a partial scheduling (no a_c)
14:50:38 giblet afaik
14:53:24 giblet fried_rice: resize is just a cold_migrate with a changing flavor https://github.com/openstack/nova/blob/68d4cb44edfe7b5f85618254cc906dcef44f7ce3/nova/conductor/tasks/migrate.py#L134
14:53:52 fried_rice hm
14:54:22 giblet fried_rice: here is the select_destination call https://github.com/openstack/nova/blob/68d4cb44edfe7b5f85618254cc906dcef44f7ce3/nova/conductor/tasks/migrate.py#L235
14:55:21 fried_rice okay.
15:00:34 mriedem fried_rice: yes resize to same host does GET /a_c
15:00:45 fried_rice okay.
15:01:10 fried_rice mriedem: Then something I just sent on the ML may be entirely wrong.
15:01:18 fried_rice o/ leakypipes
15:02:43 tssurya mriedem: thanks!
15:03:22 cfriesen mdbooth_: no worries. thanks for fixing it up.
15:09:40 cfriesen mdbooth: I assume that change has your approval since you resubmitted it?
15:12:56 melwitt o/
15:13:07 fried_rice jroll: Thanks for that email. Turns out this will affect (at least) nova-powervm's OOT driver https://github.com/openstack/nova-powervm/blob/master/nova_powervm/virt/powervm/driver.py#L230
15:13:16 fried_rice o/ melwitt
15:15:29 melwitt fried_rice: we were considering adding a warning log to the patch if a driver needs to be updated. do you think that would be useful or do you think the reno alone is good enough?
15:15:57 fried_rice melwitt: I think it's a good idea.
15:16:17 fried_rice since we're going to the trouble of being nice about changing the interface.
15:20:07 kashyap mriedem: Thanks for bringing this to my attention: https://review.openstack.org/#/c/637834/ (Select cpu model from a list of cpu models)
15:20:22 kashyap mriedem: Reviewed it this morning. And it needs a lot more rework
15:20:46 kashyap It is doing several things that are terribly ineffective, even poorly duplicating libvirt's work
15:22:08 kashyap Wonder if you (dis)agree with my remarks there
15:30:51 mriedem kashyap: i'll defer to you
15:30:55 mriedem i haven't been reviewing the change
15:31:00 mriedem bigger fires to fight
15:31:09 mriedem jroll: so i guess you're going to add a log message?
15:31:11 mriedem for the TypeError?
15:32:08 kashyap mriedem: I think all the points I (and Alex Xu) raised should be addressed.
15:32:27 kashyap I'll follow through
15:43:33 openstackgerrit Matt Riedemann proposed openstack/nova master: Stop using "nova" in API samples when creating a server https://review.openstack.org/639874
15:45:29 openstackgerrit Ben Nemec proposed openstack/nova master: Add oslo.privsep to config-generator list https://review.openstack.org/640404
15:46:19 mriedem bauzas: so what changed with the reboot issue you were holding https://review.openstack.org/#/c/599208/ up for?
15:49:01 openstackgerrit Lee Yarwood proposed openstack/nova master: Use migration_status during volume migrating and retyping https://review.openstack.org/637224
15:50:57 openstackgerrit Merged openstack/nova master: Remove port allocation during detach https://review.openstack.org/622421
15:51:47 openstackgerrit Balazs Gibizer proposed openstack/nova master: Add pf_interface_name tag to passthrough_whitelist https://review.openstack.org/625311
15:51:47 openstackgerrit Balazs Gibizer proposed openstack/nova master: Ensure that bandwidth and VF are from the same PF https://review.openstack.org/623543
15:51:48 openstackgerrit Balazs Gibizer proposed openstack/nova master: Support server create with ports having resource request https://review.openstack.org/636360
15:53:09 giblet stephenfin: added an extra sentence about grouping multiple PF in a single expression in https://review.openstack.org/#/c/625311
15:53:39 stephenfin giblet: Sounds good. I'll get to it before EOD. Been working on adding functional tests for https://review.openstack.org/#/c/624444/2
15:54:45 giblet stephenfin: thanks. hit me with the link of the functional test and I will review it
15:55:06 sean-k-mooney do you think we will land that in stein by the way. it would be good to backport if we do
15:55:43 jroll fried_rice: mriedem: yeah, I'll add it shortly here
15:55:45 jroll thanks
15:55:58 openstackgerrit Stephen Finucane proposed openstack/nova master: objects: Store InstancePCIRequest.numa_policy in DB https://review.openstack.org/624444
15:55:59 openstackgerrit Stephen Finucane proposed openstack/nova master: WIP: fakelibvirt: Add ability to generate fake PCI devices https://review.openstack.org/640409
15:56:01 fried_rice ight
15:56:26 giblet sean-k-mooney: the actual fix looked good to me so I can help pushing it through
15:56:31 stephenfin giblet: There you go. I was trying to fix some TODOs in the tests but that can be done some other time https://review.openstack.org/624444
15:56:43 giblet stephenfin: looking
15:59:24 sean-k-mooney on a slightly unrelated note i would like to land this bugfix in stien too if we can https://review.openstack.org/#/c/602432/7 but i need to do some more testing of it locally. i think it is correct but i want to be certin before we merge it and say the bugs are closed.

Earlier   Later