Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2017-10-03
16:14:20 bauzas but between a versioned field and just an object var, I'd tend to prefer an object variable
16:14:33 bauzas if that's just for helping to not lookup
16:14:39 bauzas anyway, an implementation detail
16:15:09 mriedem jaypipes: edleafe: confused about something in https://review.openstack.org/#/c/505209/
16:15:52 dansmith jaypipes: edleafe bauzas: yeah, edleafe's explanation makes sense to me.. if we make it an actual CellMapping object them we're sending credentials over the RPC wire, and we don't really need to do that, so just the uuid seems fine to me
16:15:57 mriedem do we or do we not change GET /allocation_candidates, and if we do, is it just the response body that changes to show the root provider in the response?
16:16:27 bauzas dansmith: if we can avoid a lookup, then okay
16:16:33 jaypipes mriedem: you are correct.
16:17:02 bauzas dansmith: the real problem I have with that is that (host, node, cell) is a single tuple
16:17:20 bauzas I mean, those are interdependent
16:17:33 jaypipes mriedem: well, not even the root provider ID. rather, the parent_provider_uuid will be included in the provider_summaries section and providers that aren't contained in allocation_requests will appear in the provider_summaries (if they are parents of allocated providers)
16:17:37 mriedem jaypipes: ok then i'm going to update the nested rp spec quick to point out that distinction and then i'm +W
16:17:40 bauzas here, we're creating 3 distinct fields but where 2 are related to the third
16:17:43 jaypipes mriedem: ++
16:17:53 bauzas mriedem: well, good point
16:18:05 edleafe mriedem: we don't change the API call as we do for GET /resource_providers. Both will have changed response bodies to include root/parent
16:18:58 edleafe mriedem: that's noted in the first paragraph of that section
16:19:17 bauzas edleafe: mriedem's point is that it's unclear
16:19:36 mriedem edleafe: ok i guess "of appropriate placement REST APIs." is your way of saying GET /resource_providers and GET /allocation_candidates
16:20:31 mriedem bauzas: right, it says, "There is no change proposed to `GET /allocation_candidates`" but clearly there is
16:20:41 mriedem so i'll just update to say that the filter parameter won't be added to GET /allocation_candidates
16:20:51 bauzas mriedem: ping me when you're done and I +2
16:20:54 edleafe mriedem: ok, I can clarify the wording
16:21:03 edleafe oh wait, are you going to update?
16:21:06 bauzas in the mean time, I'm disappearing for dinner
16:21:10 openstackgerrit Matt Riedemann proposed openstack/nova-specs master: Re-propose nested resource providers spec https://review.openstack.org/505209
16:21:11 mriedem edleafe: ^
16:21:20 edleafe heh, question answered
16:21:23 mriedem if that looks ok i'll +W
16:22:23 edleafe mriedem: looks like you forgot to clean up L235
16:22:33 openstackgerrit Stephen Finucane proposed openstack/nova-specs master: Add 'move-nova-cmds-to-cliff' spec https://review.openstack.org/433603
16:23:05 stephenfin mriedem: I just dropped the nova-status bit. We can look at that separately down the line
16:23:13 openstackgerrit Ed Leafe proposed openstack/nova-specs master: Re-propose nested resource providers spec https://review.openstack.org/505209
16:23:29 edleafe mriedem: fixed it. Guess you need to re-+2 it
16:23:30 mriedem edleafe: done
16:23:31 openstackgerrit Matt Riedemann proposed openstack/nova-specs master: Re-propose nested resource providers spec https://review.openstack.org/505209
16:23:33 mriedem doh
16:24:21 edleafe mriedem: well, looks good now
16:25:06 ralonsoh cdent, jaypipes: I was mixing concepts and terms in https://review.openstack.org/#/c/502306. Thanks for your reviews
16:25:21 jaypipes ralonsoh: np
16:25:29 cdent ralonsoh: it’s (too) easy to do
16:25:35 ralonsoh jaypipes: I always have this in mind: https://youtu.be/LVkknWuGq_I?t=841
16:27:39 mriedem edleafe: we don't really need both https://blueprints.launchpad.net/nova/+spec/return-selection-objects and https://blueprints.launchpad.net/nova/+spec/return-alternate-hosts do we?
16:27:56 mriedem alternate hosts depends on the selection object stuff, and that's just an object model thing
16:29:16 edleafe mriedem: the selection object spec only came about because of disagreement over a) whether it is needed at all, and b) what it should look like. It was simply a way to reach consensus.
16:29:36 mriedem ok, but all code is going to be written under the return-alternate-hosts bp right?
16:29:37 edleafe alternate hosts could work with the unstructured glob
16:30:31 mriedem maybe i just don't know how you're going to split this up
16:30:36 stephenfin jaypipes: Per comments on that doc you reviewed, you should probably look at https://review.openstack.org/#/c/461456/5
16:31:14 edleafe it's just the result of switching direction in the middle. Moving forward, let's put all the code under the return-alternate-hosts bp
16:31:24 mriedem ok
16:31:30 jaypipes stephenfin: you mean my "clear as mud..." comment?
16:31:34 stephenfin claudiub: Think this is something you could tackle, given that you are the Hyper-V guy https://bugs.launchpad.net/nova/+bug/1660001
16:31:35 openstack Launchpad bug 1660001 in OpenStack Compute (nova) " Hyper-V PCI Passthrough" [Low,Confirmed]
16:31:39 stephenfin jaypipes: Correct
16:32:05 jaypipes stephenfin: heh, ok, will do. :)
16:32:42 stephenfin fwiw, I get where sahid is coming from but I think it's a helpful enough usability improvement to warrant inclusion
16:32:47 stephenfin jaypipes: Spot on
16:35:10 mriedem oh btw who is going to be brave and just push this through? https://review.openstack.org/#/c/457532/
16:41:28 claudiub stephenfin: docimpact, huh. hm, adding details about how to configure assignable PCI devices on Hyper-V in doc/source/admin/pci-passthrough.rst should be enough, IMO. any other thing is the same as other drivers.
16:41:44 claudiub stephenfin: will send a patch today / tomorrow
16:44:04 jaypipes mriedem: done.
16:45:16 mriedem danke
16:46:40 cfriesen mriedem: I've reviewed https://review.openstack.org/#/c/381912 (Strict isolation of group of hosts for image and flavor) as promised.
16:49:26 mriedem ok
16:50:47 openstackgerrit Merged openstack/osc-placement master: CLI for resource providers https://review.openstack.org/457532
16:52:34 jaypipes holy shit, the osc thing merged.
16:52:48 cdent limited tess
16:52:49 openstackgerrit Chris Dent proposed openstack/nova-specs master: Spec for limiting GET /allocation_candidates https://review.openstack.org/504540
16:52:49 cdent ts
16:53:10 cfriesen mriedem: I had an alternate proposal...rather than "strict" flags on the flavor/image (which would affect all the other image properties/flavor extra-specs) I think it'd make more sense to have a "strict" prefix on the metadata key in the host aggregate.
16:53:33 cfriesen that way you could be strict on some keys but not on others
16:54:24 efried cdent Nits/questions https://review.openstack.org/#/c/508164/
16:54:54 cdent roger con aye
16:56:15 openstackgerrit Matt Riedemann proposed openstack/nova-specs master: List/show all server migration types https://review.openstack.org/489029
17:00:26 cfriesen I just noticed something really weird...can someone confirm? It looks like AggregateInstanceExtraSpecsFilter will *not* match if a flavor specifies something and a host is not in an aggregate or the aggregate metadata doesn't have what the flavor is looking for.
17:00:52 cfriesen But it looks like AggregateImagePropertiesIsolation *will* match if the image specifies something that isn't in the aggregate metadata
17:01:32 cfriesen AggregateInstanceExtraSpecsFilter loops over the flavor extra-specs looking for a match, but AggregateImagePropertiesIsolation loops over the aggregate metadata looking for a match.
17:02:40 exarr Anyone around I can ask about rabbit connection problems?
17:02:42 openstackgerrit Merged openstack/nova-specs master: Return Alternate Hosts https://review.openstack.org/504275
17:02:45 exarr Invalid credentials it says. So I readd the user, change password, check the transtport_url details, all seems correct.
17:02:48 exarr rabbit logs say "AMQPLAIN login refused: user 'openstack' - invalid credentials"
17:03:00 exarr Seems clear cut, huh?
17:13:24 dansmith mriedem: stephenfin: so what is the deal on this nova-manage spec? we're going to just dump syntax compatibility across one release?
17:14:04 mriedem i wondered about that too, since it said it was unavoidable when moving to cliff
17:14:13 mriedem which is kind of a non-starter for me
17:14:15 dansmith seems kinda bad to me
17:14:19 mriedem you can't break everyone's tooling
17:14:26 mriedem just because we don't like our under the hood impl
17:14:33 dansmith right, that's my concern
17:14:39 mriedem well, unless it's cells v1 :)
17:14:42 mriedem then break away!
17:20:38 sdague the flagging structure should be the same more or less
17:20:58 sdague I guess the devil in the details there, but I wasn't imaging a big shift
17:21:06 openstackgerrit Lee Yarwood proposed openstack/nova-specs master: Libvirt: Native LUKS decryption by QEMU https://review.openstack.org/490824
17:21:27 melwitt I'd think we'd need a deprecation cycle for changing nova-manage syntax. is that clock already in motion?
17:22:41 mriedem sdague: cdent: this needs some more thought https://review.openstack.org/#/c/507762/
17:22:45 mriedem plus, it came up in newton
17:22:51 mriedem and there are some issues to overcome
17:22:52 clarkb as a drive by comment, the use of stevedore (via cliff aiui) in osc is what makes it so painfully slow to use for commands

Earlier   Later