Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2019-01-21
13:52:14 edleafe I know we skipped one conference; can't remember which
13:52:32 edleafe wrong window
13:55:46 efried n-sch meeting in 5 minutes in #openstack-meeting-alt. Expect it to be a short one.
14:03:26 openstackgerrit Natal Ngétal proposed openstack/nova master: [Configuration] Clean up .gitignore references to personal tools https://review.openstack.org/632086
14:37:50 sean-k-mooney jaypipes: thanks for the +w i forgot stephenfin is on PTO today
14:38:41 jaypipes sean-k-mooney: no problemo.
14:46:32 gibi mriedem: hi, I see that jaypipes already +2 the ensure consumer status check but I have a question in https://review.openstack.org/#/c/631671/7/placement/cmd/status.py@51
14:49:20 mriedem gibi: so a consumer record for allocations but no generation?
14:49:24 mriedem i don't think that's possible...
14:49:34 mriedem the consumer generation would start at 0 if it's new
14:50:12 gibi mriedem: based on your docstring I felt that you wanted to detect this case as well with the query but I don't think that the current query detects that
14:50:31 mriedem the consumers table defaults generation to 0 so as long as there is a consumers table record, i think it has a generation
14:50:55 gibi mriedem: OK, then I just overreacted. thanks for the explanation
14:51:09 mriedem np
14:52:50 mriedem gibi: while you're here, and you've been on the per-aggregate weights patch, i had a usage/behavior question about one of the weighers which you might have an opinion https://review.openstack.org/#/c/628163/12/nova/tests/unit/scheduler/weights/test_weights_compute.py@95
14:54:30 mriedem i'd ask dan but he's out this week
14:57:02 mriedem stephenfin: easy cleanup patch on which you have context https://review.openstack.org/#/c/628205/
14:57:36 sean-k-mooney mriedem: stephenfin is on PTO today he will be back tomorrow
14:58:28 mriedem ah yes MLK day in ireland...
14:58:46 sean-k-mooney no he just took today off
14:58:56 sean-k-mooney i think he was at a gig over the weekend or something
15:00:38 gibi mriedem: looking...
15:01:29 sean-k-mooney actully he may been skying the cleanups make sense to me.
15:04:15 gibi mriedem: I tend to agree to simply document that min in case of build_failure weigher means the min of the configured weights not the calculated (and negated) weights
15:13:02 mriedem gibi: ok so you wouldn't change anything about the docs here? https://review.openstack.org/#/c/628163/13/doc/source/user/filter-scheduler.rst@508
15:13:28 mriedem i had started commenting on that about whether or not we should mention something about that, or give an example, but when i read what i'd add it just makes it more confusing
15:15:59 mriedem i left a comment that i can't come up with a good comment, +2
15:19:11 gibi mriedem: I think that doc is correct from external perspective
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: docs: Update references to "QEMU-native TLS" document https://review.openstack.org/631283
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: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 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?

Earlier   Later