Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2019-01-21
16:17:11 sean-k-mooney gibi: speaking of ironic i assume there is noting in pricipal stopping bw based schduling from being extended to ironic if the appropriate ml2 drivers were extended
16:17:39 gibi sean-k-mooney: yes and no. From nova perspective nothing prevents ironic to handle bandwidth
16:17:54 sean-k-mooney you would just need to update the ml2 drivers for the tor switch
16:17:56 gibi sean-k-mooney: from neutron perspective I'm not sure bandwidht allocation can be enforced
16:18:23 gibi sean-k-mooney: if you use the tor for it then it is not the same bandwidth as in case of libvirt and sriov
16:18:42 sean-k-mooney gibi: yes and no
16:19:02 gibi sean-k-mooney: in theory we can extend the current bandwidth support for the tor switch in in case of libvirt + sriov
16:19:37 sean-k-mooney gibi: well for the libvirt case to include the tor means hierarcical port binding
16:19:53 sean-k-mooney but for ironic the tor is the l1 port binding
16:20:11 sean-k-mooney anyway that is for the future
16:20:21 gibi sean-k-mooney: yes :)
16:22:03 gibi sean-k-mooney: my problem with dansmith mail is that I thought that microversion can be used to signal a new, supported use case, if the change affect an API behavior. But from the mail it seems that is only true for complete feature
16:22:08 cfriesen sean-k-mooney: PCI/SRIOV question for you. with the upstream code, how do you ensure that an instance that requests a PCI NIC ends up on a compute node that has physical NICs on the desired physical network? Is that just host aggregates? As I recall, the network-aware scheduling stuff never landed.
16:22:49 sean-k-mooney the pci filter performs that check
16:23:13 sean-k-mooney in the whitelist we declare the physnet that the pf is connected too
16:23:39 mriedem gibi: for supporting numa live migration, i don't think a microversion was going to be added - today it just fails (might be a 400, i'd have to look),
16:24:36 mriedem i see both sides and i think the argument for not adding a microversion for move support is to avoid the ux mess of being able to create a server with one microversion but then you have to use another to do something with it
16:24:38 sean-k-mooney cfriesen: the network aware schdulling stuff was for offloads. idealy we would do this with placement rather then the pcipassthough filter
16:25:00 mriedem i guess that argument could be made for something like volume-backed rebuild as well
16:25:21 mriedem you can create a volume-backed server with 2.1 but can't rebuild and re-image the root volume without a new microversion
16:25:28 sean-k-mooney cfriesen: whenever we get around to modeling PFs/VFs in placemetn we could use either placement aggrates or traits to model physnets
16:25:51 mriedem gibi: anyway, if we don't have move support in stein anyway, then the microversion for move is a train discussion and we can defer until then can't we?
16:25:55 gibi mriedem: so in this case discoverability is less important here than ux microversion usage
16:26:32 mriedem unless the argument is being made that we shouldn't ship the create support in stein unless move support is also ready...which i don't think we should do (and that argument could be made about a lot of features we add, like vgpus and trusted certs)
16:27:00 mriedem i.e. resize with vgpus doesn't work completely, you have to rebuild the server after the resize to get the vgpus
16:27:42 mriedem btw, now that i say that, i wonder if that would work for bw resources as a workaround for cold migration ^
16:28:13 gibi mriedem: OK then I will propose the first microversion top of the create / delete support and deferr the move support microversion question for Train
16:28:27 mriedem gibi: or at least defer for a week until dan is back :)
16:28:39 gibi mriedem: yeah :)
16:28:51 gibi mriedem: does rebuild re-allocate today?
16:29:11 sean-k-mooney gibi: mriedem i was under the impression rebuild would not work either in stien
16:30:16 mriedem gibi: no, since resources shouldn't really change on rebuild since the flavor doesn't change
16:30:31 mriedem so i guess that won't work
16:30:34 sean-k-mooney its not strictly a move operation but i has understood that effectivly start,stop,pause/unpause,suspend and resume were the only actions that would work
16:30:34 gibi mriedem: so it would be an extra check during rebuild, to see if healing is needed
16:30:55 mriedem rebuild is specifically not a move
16:31:01 mriedem there is no resource claim on rebiuld
16:31:02 mriedem *rebuild
16:31:18 sean-k-mooney well unless the image is chaged
16:31:26 mriedem even though we have an outstanding bug about the pci resource usage changing b/c of changing the image
16:31:28 sean-k-mooney in which case we have to go back to the scheuler
16:31:39 mriedem sean-k-mooney: yes but that's for filtering the image, not for claiming resources
16:31:50 mriedem "does the new image work on this existing compute host"
16:32:07 sean-k-mooney well if the image changes the resouces that are need they would have to be claimed/updated
16:32:11 mriedem https://bugs.launchpad.net/nova/+bug/1780441
16:32:12 openstack Launchpad bug 1780441 in OpenStack Compute (nova) "Rebuild does not respect number of PCIe devices" [Undecided,New]
16:32:23 mriedem sean-k-mooney: normal resources don't change based on the image
16:32:26 mriedem except pci
16:32:28 mriedem hence that bug
16:32:32 gibi mriedem: in theory I can trigger a resource healing check during rebuild, but I guess I should not fail the rebuild if bandwidth resource is not available, should I?
16:32:49 sean-k-mooney well you can enable hugepags and cpu pinning and pinning policies and numa too
16:33:06 sean-k-mooney all of which may change the resoces required
16:33:11 sean-k-mooney but in general yes
16:33:37 mriedem for anything nfv related, the answer is don't ever try to do anythign with the server once you created it
16:33:42 sean-k-mooney gibi: mriedem for rebuild with BW aware schduling you would also need to validate if the port request changed
16:33:45 openstack Launchpad bug 1763766 in OpenStack Compute (nova) "nova needs to disallow resource consumption changes on image rebuild" [Medium,Triaged]
16:33:45 cfriesen mriedem: wouldn't that fall under https://bugs.launchpad.net/nova/+bug/1763766 ?
16:33:46 mriedem because nova doesn't support operations on those servers
16:34:04 mriedem cfriesen: oh i thought that was your bug
16:34:06 sean-k-mooney mriedem: well we have never enforced that
16:34:14 cfriesen yeah, it is. I haven't done anything about it yet.
16:34:26 cfriesen I'm just thinking that PCI would fall under it too
16:34:29 sean-k-mooney mriedem: its good advice but its not explcitly stated as far as i know
16:35:00 mriedem sean-k-mooney: yes i know
16:35:02 sean-k-mooney cfriesen: yes likely.
16:35:15 gibi sean-k-mooney: in general we said that changing the resource request of a port is not supported (yet). I don't see how this is special for rebiuld. The port can be changed any time
16:35:21 spotz Anyone able to ask a quick keypair metadata questioon?
16:35:29 spotz err answer... not enough coffee
16:35:54 sean-k-mooney gibi: for rebuild we are recreating the vm from scratch and should validate its resocues
16:36:17 gibi sean-k-mooney: but current nova code assumes that the resource allocation of such VM is unchanged hence no reallocation happen
16:36:24 mriedem correct
16:36:42 gibi sean-k-mooney: so it is not special for banwidth
16:36:45 mriedem because all of the nfv stuff added in juno didn't take rebuild into account
16:36:47 sean-k-mooney https://bugs.launchpad.net/nova/+bug/1763766
16:36:48 openstack Launchpad bug 1763766 in OpenStack Compute (nova) "nova needs to disallow resource consumption changes on image rebuild" [Medium,Triaged]
16:37:03 mriedem s/rebuild/any other operation besides delete/
16:37:07 sean-k-mooney true but the bug cfriesen pointed to would cover it^
16:37:23 cfriesen mriedem: and resize
16:37:34 mriedem "any other operation besides delete"
16:37:35 gibi sean-k-mooney: OK, so you suggest to fail rebuild if the port's resource request changed
16:37:43 sean-k-mooney gibi: yes
16:37:51 gibi sean-k-mooney: that would need nova to store such request
16:38:00 gibi sean-k-mooney: to have something to compare with
16:38:10 mriedem ummm
16:38:17 sean-k-mooney gibi: it could compare it to the existing placement allocation
16:38:22 gibi sean-k-mooney: I'm more like the idea that neutron rejects the change of a qos rule if the port is bound
16:38:29 mriedem that seems pretty shitty for nova have to do that enforcement,
16:38:33 gibi sean-k-mooney: with multiple port, that comparision is really ahrd
16:38:35 gibi hard
16:38:38 sean-k-mooney gibi: that was brought up before
16:38:51 mriedem neutron should be responsible for not allowing bw policy changes on attached ports
16:39:02 sean-k-mooney gibi: it would be a change in the neutron behaivor but not one that they said the were against
16:39:17 mriedem gibi: yes i agree with what you said,
16:39:23 sean-k-mooney mriedem: well this is special for min mandwith
16:39:25 mriedem "I'm more like the idea that neutron rejects the change of a qos rule if the port is bound"
16:39:37 gibi sean-k-mooney: I reacall that this was stated in the spec
16:39:37 sean-k-mooney there is no reason max bandwith of dscp cant change
16:39:43 openstackgerrit Merged openstack/nova master: Reduce calls to placement from _ensure https://review.openstack.org/615677
16:40:15 sean-k-mooney gibi: i raised this before yes but i dont think we made a decision to actully modify neutron to do it
16:40:39 gibi sean-k-mooney: I will ping rubasov tomorrow about it, he is leading the neutron work

Earlier   Later