Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2019-01-21
15:19:41 gibi mriedem: and I agree configuring weighers are hard, and this patch now makes it even more complex
15:20:37 mriedem heh
15:20:48 mriedem time for edleafe's scheduler dry run API
15:21:17 gibi is it a test environment for scheduler config? :)
15:23:36 edleafe gibi: the idea was to pass in a request and some target hosts, and have the scheduler return the hosts that would have passed, but not actually build anything on those hosts
15:24:32 edleafe It would have been useful for the Watcher project to know if they try to move an instance to a host whether the new host was a valid target
15:25:44 gibi edleafe: I see. It is interesting
15:26:28 edleafe gibi: now what they do is try to move it and catch the failure. It's slow and expensive
15:28:03 cdent I am slow and expensive
15:30:25 openstackgerrit Kashyap Chamarthy proposed openstack/nova master: libvirt: A few miscellaneous items related to "native TLS" https://review.openstack.org/630980
15:30:25 openstackgerrit Kashyap Chamarthy proposed openstack/nova master: docs: Update references to "QEMU-native TLS" document https://review.openstack.org/631283
15:35:33 gibi edleafe: in return, such a dryrun might return True for a host but then the actual scheduling will fail a due to races
15:35:43 gibi edleafe: but I see that this is a tradeoff
15:37:45 edleafe gibi: sure, that's always been understood, and things like total available resources are already able to be known. What it *would* do is help with things like affinity/anti-affinity, aggs, etc., that are pure nova-isms
15:38:07 gibi edleafe: yeah, make sense
16:12:22 gibi mriedem: btw, as dansmith is on vacation, I
16:12:39 gibi mriedem: btw, as dansmith is on vacation, I'd like to ask your oppinion on my answer in the bandwidth ML thread
16:12:59 gibi mriedem: of course if your oppinion is to wait for dansmith then I will wiat
16:13:02 gibi wait
16:14:56 sean-k-mooney gibi: by the way i was not arguing that all features reqire move support just that numa is not a good example :)
16:15:20 gibi sean-k-mooney: yeah. I could use other example like virt driver support for certain operations
16:15:47 sean-k-mooney yep ironic does not really have much of a choice
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 gibi mriedem: so it would be an extra check during rebuild, to see if healing is needed
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: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 cfriesen mriedem: wouldn't that fall under https://bugs.launchpad.net/nova/+bug/1763766 ?
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: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

Earlier   Later