Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2018-03-26
15:04:03 mriedem efried: i lied
15:04:07 tssurya dansmith: regarding adding the "queued_for_delete" column
15:04:11 tssurya to handle a down cell,
15:04:14 tssurya does it need a spec ?
15:04:17 efried mriedem: you lying liar
15:04:26 rybridges mriedem: The example of an AttributeError being raised in the Python terminal that you showed on Friday is not meaningful at all. Of course it will throw an exception at the Python CLI. What you did does not represent how Neutron executes the code. Neutron wraps that call with the eventlet spawn_n() method which blanket catches all exceptions and prints them to stderr rather than using the standard
15:04:28 rybridges Python logging framework.
15:04:30 rybridges This means that exceptions thrown within eventlet loops will not be logged to files that are setup in a deployer's standard logging conf. Long story short, exceptions ARE actually being masked / swallowed which is why we had this problem. See my patch which improves the error handling: https://review.openstack.org/#/c/556120/
15:04:52 efried mriedem: Ah, nice finds
15:05:05 tssurya the use cases are nova list, nova service-list and blocking VM creations if a user has VMs in the down cell
15:05:14 tssurya however each of this has a bug opened
15:05:35 dansmith tssurya: yeah I think it probably should be a spec because there will be lots of behavioral changes to describe ...
15:05:38 tssurya so was wondering if it needs a spec, since the only common part would be adding the new column to the instance_mapping table
15:05:46 tssurya dansmith: ah okay,
15:06:00 tssurya also are we going to consider melwitt's proposal of adding user_id as well ?
15:06:31 tssurya since she said that is the only info missing for calculating per project per user quptas
15:06:34 tssurya quotas*
15:07:05 belmorei_ are user quotas something that nova will continue to support?
15:07:21 dansmith tssurya: is that related to the down-cell behavior thing? I thought that solved one of the quota issues, but not enough to calculate enough of the quota to enable booting when a cell is down
15:07:44 dansmith tssurya: regardless, if you think it's related and/or should be done at the same time, that's a thing to document the justification for in the spec I think
15:08:02 dansmith belmorei_: I think we have some we have to support because of history right?
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.

Earlier   Later