| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-10-03 | |||
| 14:53:16 | jaypipes | efried: so it's the scheduler's responsibility to understand those things. | |
| 14:53:24 | efried | Yup. | |
| 14:53:52 | jaypipes | efried: currently, the scheduler does that by keeping that map of service RPC to compute node UUID in memory. It will need to be adapted to understand nested/root providers | |
| 14:54:12 | efried | jaypipes Will provider summaries include the whole tree, or only the exact RPs being consumed from? | |
| 14:54:38 | jaypipes | efried: the exact RPs that could be consumed from and their parents. | |
| 14:54:50 | efried | parents/ancestors | |
| 14:54:50 | jaypipes | efried: which is needed for callers to piece the tree together. | |
| 14:54:53 | jaypipes | yes | |
| 14:54:54 | efried | up to the root | |
| 14:54:57 | efried | okay. | |
| 14:54:57 | jaypipes | yes | |
| 14:55:16 | efried | I dig that. Saves an extra call from the scheduler. | |
| 14:55:28 | jaypipes | efried: I wasn't planning on making provider_summaries into a tree structure, though. was relying on the caller to do that as needed. | |
| 14:56:04 | efried | I don't see the need for the whole tree - except that's easier to build, cause you'll already have that code for that API (forget which one) that returns a whole tree. | |
| 14:56:28 | efried | The chain of parents is simple enough, but a separate algorithm. | |
| 14:56:30 | bauzas | efried: jaypipes: sorry I had to disappear due to family business | |
| 14:56:46 | bauzas | but yeah let's punt that discussion | |
| 14:57:00 | jaypipes | bauzas: commented on the spec. | |
| 14:57:19 | ralonsoh | jaypipes: hello. About https://review.openstack.org/#/c/502306/2/specs/queens/approved/bandwidth-resource-provider.rst@111. I don't understand what you mean. Should ML2 plugin be able to make RP claims? Or create/delete allocation records? | |
| 14:57:35 | bauzas | the thoughts that I had was about saying "what if I'm asking for more than the inventory amount supported by one child" | |
| 14:57:46 | cdent | jaypipes: I just had a quick confused run through there. Looks like some fundamental misconceptions. | |
| 14:58:05 | jaypipes | ralonsoh: heh, I was just making a joke about the repeated misspellings of the word "bandwidth" :) | |
| 14:58:16 | ralonsoh | jaypipes: sorry! | |
| 14:58:18 | jaypipes | Including in the spec title ;) | |
| 14:58:29 | jaypipes | ralonsoh: it's cool, I'm just kidding with ya | |
| 14:59:13 | jaypipes | cdent: "Horse". | |
| 14:59:41 | cdent | such disappoint | |
| 14:59:51 | jaypipes | ralonsoh: I'll comment on the spec, k? | |
| 15:00:00 | ralonsoh | jaypipes: perfect! and thanks | |
| 15:00:06 | jaypipes | ralonsoh: no problemo | |
| 15:00:32 | mriedem | stephenfin: you've made the diff on this impossible https://review.openstack.org/#/c/496160/ | |
| 15:00:37 | mriedem | to compare to the pike spec | |
| 15:00:55 | stephenfin | mriedem: How so? | |
| 15:00:55 | mriedem | stephenfin: if you're re-proposing a spec from a previous release, please leave the stylistic changes for a separate patch | |
| 15:01:04 | mriedem | you change all the line wrapping | |
| 15:01:33 | mriedem | i think you are going to need to setup a dr visit about your serious ocd issue | |
| 15:02:15 | jaypipes | wait... mriedem is calling someone ocd? | |
| 15:02:22 | cdent | my thoughts exactly | |
| 15:02:24 | stephenfin | mriedem: Ah, I can undo those, but the only functional changes are the things that were already commented on | |
| 15:02:26 | jaypipes | :P | |
| 15:04:36 | mriedem | stephenfin: already approved | |
| 15:04:38 | mriedem | but for next time | |
| 15:04:52 | stephenfin | mriedem: (y) | |
| 15:05:26 | mriedem | jaypipes: i'm not the one that -1s your changes for putting closing ] and } and ) on separate lines :P | |
| 15:05:44 | jaypipes | mriedem: lol, tru dat | |
| 15:05:59 | jaypipes | mriedem: that would be edleafe and dansmith, or as I call them "The Parens Posse" | |
| 15:09:32 | cdent | dan’s down with tpp | |
| 15:09:54 | cfriesen | tpp ya you know me... | |
| 15:10:03 | sdague | mriedem: yeh, I don't know either | |
| 15:10:25 | sdague | also, I think there is lots of confusion about "rebuild" | |
| 15:10:41 | sdague | because even in the ML thread where someone said "yes, this would be great!" | |
| 15:10:56 | sdague | and I asked "on just rebuild or you want reboot", A: "we never use rebuild" | |
| 15:11:31 | mriedem | i'm trying to get some more answers in the ops channel | |
| 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. | |