Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2017-10-03
15:26:57 jaypipes stephenfin: be sure to mention the moon cycle and solar flares.
15:27:41 sdague mriedem: you get a really small micro slice of the devs and operators that also had a big travel budget and time
15:28:35 jaypipes sdague: micro slice, huh? is that a new container technology? :)
15:29:00 sdague :)
15:29:11 sdague really more of a uni-kernel ....
15:29:15 jaypipes heh
15:29:56 mriedem ok, so what's the point in going to the summit at all?
15:30:12 mriedem but we've been here before, i don't mean to digress
15:31:15 gibi mriedem: I'm thinking about skipping the notification subteam meeting not to disturb your spec review focus. Is that OK for you?
15:31:24 mriedem gibi: yeah
15:31:32 melwitt mriedem: fwiw I know that at yahoo they inject keypairs via cloud-init and have wanted to be able to pass new userdata on a rebuild to update those
15:31:37 sdague mriedem: because you get higher bandwidth ability to work through hard things
15:31:49 gibi mriedem: OK
15:33:16 cfriesen cdent: review updated
15:48:13 jaypipes efried: you had a nice little ascii diagram in one of your review comments of a provider tree... which review/spec was that?
15:48:46 efried jaypipes This is the one I just did a few minutes ago: https://review.openstack.org/#/c/502306/
15:49:17 mriedem melwitt: i'm confused, we don't allow passing in new user_data during rebuild
15:49:28 mriedem oh, "have wanted"
15:49:40 jaypipes efried: donkey shame.
15:49:47 efried jaypipes bitter
15:50:22 mriedem melwitt: maybe you want to comment on this then, https://review.openstack.org/#/c/509013/ because i said we wouldn't allow psasing user_data during rebuild even if we remove the ability to pass personality files during rebuild
15:50:26 melwitt mriedem: yeah, just another data point on how ppl do ssh keys
15:51:18 melwitt mriedem: o rly? I thought at the PTG what came out of that discussion was that we'd be allowing user_data during rebuild
15:53:40 melwitt L441 on https://etherpad.openstack.org/p/nova-ptg-queens
15:53:49 openstackgerrit Chris Dent proposed openstack/nova-specs master: Add spec for symmetric GET and PUT of allocations https://review.openstack.org/508164
15:55:35 mriedem melwitt: i know, see the ML thread i just started
15:56:05 melwitt okay
16:02:55 openstackgerrit Ed Leafe proposed openstack/nova-specs master: Return Selection Objects https://review.openstack.org/498830
16:07:11 sahid mriedem: can you have this in your list for the spec review? https://review.openstack.org/#/c/485522/
16:07:42 sahid jaypipes: ^ perhaps you can have a look, the code is ready but you might want this to wait for one of your work in-progress
16:07:59 jaypipes mriedem, dansmith, bauzas, cdent: OK, I'm good with https://review.openstack.org/#/c/498830/. I say ship it.
16:08:23 mriedem i'm still in keypair update land
16:08:29 jaypipes heh, ok :)
16:11:14 bauzas jaypipes: edleafe: I'm still not sold on the cell_uuid usefulness but meh
16:11:35 jaypipes bauzas: I can see what edleafe was saying about being beneficial to the superconductor.
16:12:42 openstackgerrit John Garbutt proposed openstack/nova-specs master: Support traits in the Ironic driver https://review.openstack.org/507052
16:12:54 bauzas jaypipes: sure, but adding a new field because of that doesn't seem very nice
16:13:28 jaypipes bauzas: I don't think it hurts.
16:13:44 bauzas if we don't persist it, for sure
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

Earlier   Later