| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-03-26 | |||
| 15:08:13 | dansmith | belmorei_: I don't have those details in my head, so maybe we should discuss when melwitt is awake | |
| 15:09:06 | tssurya | dansmith: yea sure, the reason I was asking about the user_id is if its going to be incorporated then it changes the solution I would be proposing in this spec for VM booting | |
| 15:09:31 | mriedem | keypairs | |
| 15:09:41 | mriedem | keypair quota is based on user_id, not project_id | |
| 15:10:06 | dansmith | tssurya: yeah, so maybe it needs to be two specs, I dunno, I don't have it all in my head right now, so just use your judgment about whether or not to include it or mention it as a related effort I guess | |
| 15:10:11 | mriedem | https://github.com/openstack/nova/blob/master/nova/quota.py#L1248 | |
| 15:10:34 | belmorei_ | mriedem right, missed that | |
| 15:10:41 | tssurya | dansmith: so without the user_id, it would be something like - user can spawn new VMs if he/she doesn't have any in the cell which is down, with the user_id it would be done from placement and VM booting can be allowed even if the user has VMs in the down cell | |
| 15:10:55 | tssurya | dansmith: yea will do that | |
| 15:11:00 | tssurya | and consult melwitt | |
| 15:11:06 | tssurya | when she is awake | |
| 15:11:09 | gibi | jaypipes: I'm falling back replying to you in the spec as I have to go offline soonish | |
| 15:11:13 | dansmith | tssurya: oh you mean user_id in placement for calculating quotas? | |
| 15:11:24 | mriedem | we can't use placement for quota calculations | |
| 15:11:30 | mriedem | not yet anyway | |
| 15:11:42 | dansmith | yeah, I thought you meant user_id on something else.. instance mapping or something | |
| 15:11:50 | tssurya | dansmith: trying to find the mailing list email in which melwitt was talking about this | |
| 15:12:01 | tssurya | yes its about adding user_id to instance_mapping table | |
| 15:12:11 | dansmith | hmm, okay, well, idk | |
| 15:12:13 | tssurya | but using placement db for quotas calculation | |
| 15:12:14 | dansmith | probably two specs though | |
| 15:12:24 | tssurya | so that we no longer depend on individual cell_db's | |
| 15:12:26 | dansmith | yeah, that placement quotas thing is a larger can of worms, | |
| 15:12:36 | dansmith | don't depend on that for your queued_for_delete thing | |
| 15:14:20 | tssurya | dansmith: http://lists.openstack.org/pipermail/openstack-dev/2018-March/128334.html | |
| 15:14:41 | tssurya | dansmith: yes okay then will do a spec without thinking about ^^ | |
| 15:16:02 | dansmith | tssurya: we can sneak that column in so we just have one db migration to add both, but the actual work is a separate spec I think | |
| 15:16:22 | tssurya | dansmith: yea I agree, | |
| 15:21:06 | gibi | jaypipes: replied in https://review.openstack.org/#/c/502306 but I have to go offline in 5. I will check your reply tomorrow morning | |
| 15:21:30 | mriedem | stephenfin: https://review.openstack.org/#/c/534724 drops a lot of info | |
| 15:22:05 | stephenfin | mriedem: Fair points. I'll address those | |
| 15:22:11 | stephenfin | Thanks for the review (y) | |
| 15:23:55 | gibi | Kevin_Zheng: I left some suggestion in https://review.openstack.org/#/c/553288 | |
| 15:25:36 | mriedem | tssurya: figured out why you can't run nova-api without having [database]/connection setup http://logs.openstack.org/46/555346/2/check/tempest-full/69cf0dc/controller/logs/screen-n-api.txt.gz#_Mar_24_00_53_19_452955 | |
| 15:25:51 | mriedem | tssurya: File "/opt/stack/nova/nova/api/openstack/wsgi_app.py", line 49, in _setup_service is not multi-cell aware | |
| 15:25:59 | mriedem | belmorei_: ^ | |
| 15:26:53 | mriedem | that code should likely just lookup the cell0 mapping and use it's context | |
| 15:27:09 | tssurya | mriedem: ah okay | |
| 15:27:51 | kashyap | dansmith: Responded; I'm not quite sure if a soft log warning would suffice... | |
| 15:28:15 | belmorei_ | mriedem thanks | |
| 15:28:55 | openstackgerrit | Eric Fried proposed openstack/nova master: Unit test framework: common FakeResponse https://review.openstack.org/556551 | |
| 15:29:01 | efried | mriedem: Done. More red! Yay! | |
| 15:29:09 | kashyap | dansmith: Also, about verbosity in the `reno`, I was aware of it; but I was not merely describing _what_ are those 3 modes. | |
| 15:29:20 | tssurya | mriedem: thanks for spotting it | |
| 15:29:35 | kashyap | dansmith: Rather, what would Operators want to do in context of the three modes Nova allows. | |
| 15:29:46 | kashyap | (As I've lost count on other Virt lists & IRC where people have asked about it.) | |
| 15:30:41 | kashyap | That said ... happy to snip it, and add it to a separate blog post or something. I'm all for brevity with clarity. | |
| 15:31:01 | dansmith | kashyap: ask someone else, but IMHO, it's about 500% too wordy | |
| 15:31:22 | kashyap | dansmith: Folks on #openstack-release said it reads very well, FWIW. smcginnis and dhellmann reviewed it | |
| 15:31:46 | dansmith | kashyap: cool, but I think it's too much | |
| 15:32:23 | kashyap | dansmith: I can cut it down. But I'd rather want to definitely retain the info about what an Operator would do with each of the 3 modes | |
| 15:32:34 | kashyap | It _certainly_ makes sense. As it's a completely valid question that will come up. | |
| 15:32:43 | kashyap | (As not everyone dwells on it.) | |
| 15:32:54 | dansmith | kashyap: that's fine, but I'll still be -1 on it | |
| 15:33:43 | kashyap | I'd rather first get someone else's view too in Nova. | |
| 15:34:36 | dansmith | kashyap: didn't I say ask someone else? :) | |
| 15:34:52 | kashyap | Sure :-) | |
| 15:35:46 | dansmith | efried: are you looking for me to add aggregates to ResourceRequest, or just to slap it into the result of resources_from_request_spec? because it seems like that function does some weirdness where it requests some resource group and then jams extra resources into the result | |
| 15:36:06 | dansmith | efried: this specifically: https://github.com/openstack/nova/blob/master/nova/scheduler/utils.py#L334 | |
| 15:36:58 | dansmith | I guess it's returning some internal object and then jamming the resource request in there | |
| 15:37:02 | efried | dansmith: That bit is for special handling of the "default resource classes". Wouldn't think aggregates would play in there. | |
| 15:37:19 | dansmith | efried: yeah, I'm trying to figure out where aggregates go and reading that is confusing to me | |
| 15:37:33 | efried | dansmith: Anyway, yeah, I was looking for ResourceRequest to get an agg field (similar to the traits field) which would be populated based on the request spec. | |
| 15:37:37 | dansmith | efried: you want an setter method on ResourceRequest that takes aggregates? | |
| 15:37:38 | efried | ...using the code you already done wrote. | |
| 15:37:50 | dansmith | or can I just set res_req.aggregates = [] | |
| 15:37:52 | dansmith | ? | |
| 15:38:30 | dansmith | like, resources_from_request_spec() seems like it should be a classmethod on ResourceRequest, but it's not so I'm trying to figure out how much of "friends" they are | |
| 15:38:52 | efried | dansmith: um, looks like I already have member_of on RequestGroup . | |
| 15:39:13 | dansmith | okay and I don't really get the RequestGroup thing | |
| 15:39:24 | dansmith | and that comes out of placement, | |
| 15:40:08 | dansmith | so in that case, I _would_ actually do aggregates like the extra resources are getting jammed in there? | |
| 15:40:18 | dansmith | res_req.get_request_group(None).member_of = aggregates ? | |
| 15:40:25 | efried | yeah | |
| 15:40:33 | dansmith | mkay | |
| 15:40:42 | dansmith | I don't really get what this is doing, but.. as you wish | |
| 15:40:52 | efried | dansmith: It's the framework for granular. | |
| 15:41:04 | dansmith | ah, and that's what ident is then.. okay | |
| 15:41:37 | efried | dansmith: Puts in one place the parsing of the extra specs into the RequestGroups which will feed into the placement call. | |
| 15:42:12 | dansmith | efried: so, RequestGroup doesn't have much schema, so do you want me to: | |
| 15:42:21 | dansmith | grp.member_of = ['foo,bar', 'baz'] | |
| 15:42:21 | dansmith | or | |
| 15:42:37 | dansmith | grp.member_of = [('foo','bar'), ('baz',)] | |
| 15:42:38 | dansmith | ? | |
| 15:42:57 | efried | dansmith: Guess it depends on how that spec shakes out :P | |
| 15:43:02 | jaypipes | gibi: hey, sorry, went to get something to eat. I'll respond on the spec. | |
| 15:43:16 | openstackgerrit | Matthew Booth proposed openstack/nova-specs master: Add serial numbers for local disks https://review.openstack.org/556565 | |
| 15:43:26 | dansmith | efried: I don't think it really does, this is just the internal way we communicate the request to report client right? | |
| 15:43:49 | dansmith | efried: I'm not really sure why this lives in placement.lib I mean | |
| 15:43:50 | dansmith | because later that will be out of tree and we won't use it to communicate with our own reportclient I think | |
| 15:43:50 | efried | dansmith: yeah. I think the sooner we get to the list-of-tuples representation, the better. So option 2 | |
| 15:43:58 | dansmith | mkay | |
| 15:44:12 | efried | dansmith: It's just because RequestGroup is used by both nova side and placement side. | |
| 15:44:26 | efried | on the placement side, we parse the incoming querystring into the exact same representation. | |
| 15:44:36 | dansmith | yeah, this seems like code sharing we should be removing so that we don't have any ties | |
| 15:44:41 | efried | It's like... having a serializable object without having a serializable object. | |
| 15:45:23 | efried | dansmith: Well, cdent is aware, and was involved in the review process (I think). I imagine there will come a time when there will be a placement_lib module that both of them will import. | |
| 15:45:58 | dansmith | I don't see why we'd use that to communicate between internal components of nova, unless it provides a lot of pre-calculation of things or something, which it does not do now, | |
| 15:46:22 | dansmith | but just be advised how hard it will be to land changes to that across both projects and update requirements and such before you can use a new thing if we go that route | |
| 15:46:34 | cdent | I think I expressed reservations at the time, but mostly shrugged in a "we'll figure it out" and "if it helps now, cool" kind of way. | |