Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2019-03-01
13:51:41 yonglihe guess
13:52:22 mriedem it should just work, but you have to at least bump the supported api version and it would be good to modify the fakes response in unit tests to show it in the output for nova show/update/rebuild
13:52:45 mriedem so this https://github.com/openstack/python-novaclient/blob/master/novaclient/__init__.py#L28
13:52:54 yonglihe sure, got it.
13:53:12 mriedem the fake responses for unit tests are here https://github.com/openstack/python-novaclient/blob/master/novaclient/tests/unit/v2/fakes.py
13:53:26 yonglihe nice, thanks.
13:53:52 mriedem so something like this https://github.com/openstack/python-novaclient/blob/master/novaclient/tests/unit/v2/fakes.py#L647
13:53:55 tssurya mriedem, melwitt, dansmith: I have this very easy doc change on the archive nova-manage command just to clarify what max-rows means there: https://review.openstack.org/#/c/606995/. Please take a look at it when you have time,
13:54:10 mriedem yonglihe: you can check the requested microversion from the fake method and return the server_groups key in the response
13:54:48 mriedem like this https://github.com/openstack/python-novaclient/blob/master/novaclient/tests/unit/v2/fakes.py#L2023
13:56:11 yonglihe mriedem: ok, thanks.
13:57:58 openstackgerrit Matt Riedemann proposed openstack/nova master: Update --max-rows parameter description for archive_deleted_rows https://review.openstack.org/606995
13:58:04 mriedem tssurya: done
14:14:27 fried_rice Hey folks, especially folks like sean-k-mooney: when we do a resize-to-same-host, do neutron ports get unbound and rebound or do we leave them alone?
14:15:10 fried_rice Sundar: ^
14:16:54 ttsiouts mriedem: I tried to address your comments in https://review.openstack.org/#/c/570203/. would be great to hear your feedback when you have the time. thanks in advance
14:17:26 sean-k-mooney fried_rice: i would have to check they proable are not but it might be resonable to require that they are
14:17:55 sean-k-mooney i dont htink we allow changing vif_model via flavor im pretty sure that is image only
14:19:16 fried_rice sean-k-mooney: I'm thinking it could be problematic for bandwidth resources, if there are paths in which we would end up binding to different providers somehow - the allocations would wind up screwy. giblet, have you already considered this?
14:19:30 sean-k-mooney am if the numa toplogy changes as part of a resize then in the future the bandwith allcoation might need to be updated
14:19:39 fried_rice sean-k-mooney: And in anticipation of cyborg, similarly, if we had to unbind and rebind accelerators.
14:20:22 sean-k-mooney fried_rice: well we hit the schudler as part of a resize so if the flavor chagned the device-profile for example in the cyborge case we defiently would need to rebind the device
14:20:27 giblet fried_rice: do you mean changing the flavor might affect the port allocation?
14:21:08 fried_rice giblet: actually I'm more concerned about the case where changing the flavor does/should *not* affect the port allocation/binding.
14:21:08 sean-k-mooney it may
14:21:40 fried_rice like, if all I do is increase VCPU, is it possible that I wind up with my vifs being swizzled?
14:21:44 Sundar sean-k-mooney: What about rebuild? It could be on same host or different host. In the former case, AFAIK, it is only a detach but not an unbind.
14:22:02 sean-k-mooney Sundar: rebuild is confied to the same host
14:22:07 sean-k-mooney Sundar: it will never do a migrate
14:23:06 Sundar sean-k-mooney: If the rebuild changes the image, and the new image has different traits, is that not a problem?
14:23:14 sean-k-mooney fried_rice: i think there are edgecses such as changin numa toplogy that might require it if you have sriov port or hardwar offload ovs or you use the numa aware vswitch feature
14:23:33 sean-k-mooney Sundar: we will fail the rebuild if its not valid for the current host
14:23:40 mriedem rebuild doesn't mess with port bindings
14:23:43 sean-k-mooney rebuilt with same image bypasses the scheduler
14:23:50 sean-k-mooney rebuilt with different hits the schduler
14:23:59 giblet does resize-to-same host is just allows but never forces the resize to keep the server on the same host
14:24:05 mriedem resize to same host calls the same methods to change port bindings, but i think the neutron api code we have doesn't do the update if the host doesn't change
14:24:26 mriedem https://github.com/openstack/nova/blob/master/nova/network/neutronv2/api.py#L3230
14:25:17 sean-k-mooney giblet: right if the resize was invalid on the same host it would do a cold migraton to a vliad host if one exits in that case
14:27:03 sean-k-mooney mriedem: in princiable a rebind with a new image could contain tratis that may affect the neutro ports but in practice we have never need to cater for that case todate so ya for rebuild we have never needed to touch the port bindings
14:27:28 giblet fried_rice: to answer your original question server move operations (even resize on same host) are not covered by the current implementation so your question needs to be answered during Train
14:27:51 fried_rice giblet: Okay, good to know.
14:28:37 giblet fried_rice: my general idea regarding move is, to re-query resoruce request from neutron ports, include it to the scheduling. conductor will transparently handle migration allocation for ports then.
14:28:59 fried_rice giblet: It would be nice to prefer candidates where the ports don't move.
14:29:12 fried_rice which sounds like more hacked up matching.
14:29:44 giblet fried_rice: so during resize-to-same-host case it would be nice to keep the ports allocated to from the same RP, I seenow
14:29:50 sean-k-mooney fried_rice: for what it worth the image trait edgecase for neutron port i am tink of would be a a required or forbding trati for a partacalr nic vendor when using sriov. we talked about this as a way for image to expres i have drivers for vendor X but not Y
14:30:56 giblet fried_rice: the problem with that is nova-scheduler always selects the first allocation for a host even if there is more than one candidate is returned for that host
14:30:59 giblet by placement
14:31:11 sean-k-mooney fried_rice: well its not really more hacked up match and more a weigher.
14:31:38 fried_rice weighers are by definition hacks
14:31:43 fried_rice ...said someone I'm sure
14:32:11 sean-k-mooney ha perhaps
14:32:49 giblet fried_rice: https://github.com/openstack/nova/blob/68d4cb44edfe7b5f85618254cc906dcef44f7ce3/nova/scheduler/filter_scheduler.py#L238
14:33:07 fried_rice yup
14:33:14 sean-k-mooney but unlike filter they are intended to handel the optimisation of the best host rather then filter which is what we want in thiscase. although as giblet mething we might need to look at multiple allcoation candiates which the weigher dont play a role in
14:34:06 giblet nova filter scheduler does not filter and weigh allocation candidates today
14:34:13 giblet it filter and weigh hosts only
14:34:21 sean-k-mooney yes im aware
14:34:46 sean-k-mooney but i think what fried_rice was asserting sounded like a weigher of the allocation candiates
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

Earlier   Later