Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2017-10-03
15:11:49 mriedem and the answer i'm getting there is, "we don't use cloud-init to manage keys in the guest"
15:12:21 sdague um... so huh what?
15:12:41 sdague mriedem: joined there late, who said that?
15:12:44 mriedem bloomberg runs a script which is in the image that refreshes the users for the vm, or something
15:12:54 mriedem mihalis68
15:13:01 sdague yeh, cool, so they don't use the keypairs api then
15:13:15 sdague which, honestly, makes sense
15:13:16 jaypipes mriedem: probably they mean there's a single key they use for chef and then rely on chef to inject/write other user keys.
15:13:25 sdague do the whole thing out of band
15:14:26 mriedem cburgess: do you have input on this keypair update thing? do you configure cloud-init in the images to refresh keys on reboot or only new build of the guest?
15:15:13 sdague mriedem: I think the question probably should be A) do you regularly use the keypairs api
15:15:14 mriedem basically what i don't like about Kevin's spec is the 2-3 step dance, which varies from cloud to cloud based on how cloud-init is configured in the image
15:15:37 mriedem because it's (1) update server with new key_name, (2) reboot and check if that worked, else (3) rebuild
15:15:59 mriedem restricting it to just rebuild is definitely simpler
15:16:39 mriedem maybe infra users could help here, since they also have a use case for updating keypair in an instance
15:18:27 mriedem i've also considered this might be something that needs to be discussed at the summit with ops and users in the room
15:19:22 cfriesen cdent: for https://review.openstack.org/#/c/508164/1/specs/queens/approved/symmetric-allocations.rst I assume that with the new microversion the data would be *required* to be in the dict form? The spec makes it sound optional.
15:20:02 sdague mriedem: it's not really clear to me that there is any more feedback there then virtually
15:20:27 mriedem sdague: isn't the point of the forum to get the devs and ops and users in the same room?
15:21:21 jaypipes stephenfin: done
15:22:58 melwitt sdague: ack, will review that spec
15:23:44 cdent cfriesen: sorry was on the phone. the idea is that if you want to do it the old way you can always use the old microversion
15:24:00 stephenfin jaypipes: sahid had a similar complaint about "correctly configured host". I'm working on a larger doc a la '/admin/cpu-topologies': do I need to have that done before this merges?
15:24:18 cdent cfriesen: is there a specific place where I could make that more clear?
15:24:34 stephenfin I didn't include it there and there's a million and one steps necessary and I didn't want to bloat that doc, which is a reference-style doc
15:24:41 stephenfin *as there's
15:24:54 openstackgerrit Andrey Volkov proposed openstack/nova master: AZ operations: check host has no instances https://review.openstack.org/509206
15:26:37 jaypipes stephenfin: I'd be cool with a comment on the commit message pointing to or referencing it
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

Earlier   Later