Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2018-03-26
14:44:55 efried kashyap: Propose it!
14:45:05 mriedem ok, i guess that doesn't surprise me
14:45:23 dansmith man the queues are deep
14:45:30 kashyap efried: Heh :-) Haven't checked the list responses yet, still ploughing through other stuff
14:45:47 efried I don't know if anyone responded thusly. That was off the cuff.
14:46:08 kashyap dansmith: Hey, since you're a stickler for words, I'd love if you see any grammatical mistakes in the release note (I spent 3 hours writing it)
14:46:37 kashyap dansmith: 'Grr'it is slow for me; but here's a quick-loading file: https://review.openstack.org/#/c/534384/15/nova/virt/libvirt/driver.py
14:46:46 kashyap Err, "wrong" URL :P -- https://kashyapc.fedorapeople.org/libvirt-cpu-model-extra-flags-a23085f58bd22d27.yaml.txt
14:46:50 tssurya mriedem: oops
14:47:32 tssurya mriedem: I guess they did get merged out of order
14:48:32 dansmith kashyap: in a bit
14:48:34 tssurya dansmith, mriedem: dansmith has a comment on the debug stuff in the main filter patch,
14:48:44 tssurya I will fix it and we can merge that soon
14:49:05 kashyap dansmith: No rush at all. In an hour-ish, I'll be disappearing to my Dutch class, so I'll respond to questions on the review (if you have them)
14:53:14 openstackgerrit Eric Fried proposed openstack/nova master: Unit test framework: common FakeResponse https://review.openstack.org/556551
14:53:20 efried mriedem: You are interested in this ^
14:54:23 mriedem i am interested in that yes
14:55:06 efried mriedem: (While I was reviewing https://review.openstack.org/#/c/556334/1/nova/tests/unit/network/test_neutronv2.py)
14:55:28 mriedem yeah i figured
14:55:39 mriedem i was going to get there eventually
14:55:49 efried mriedem: But note that I implemented it differently than the one in test_identity.
14:56:43 openstackgerrit Tyler Blakeslee proposed openstack/nova master: Add __repr__ for NovaException https://review.openstack.org/555812
14:58:18 mriedem fix the typo and i'm +2
15:00:00 openstackgerrit Eric Fried proposed openstack/nova master: Unit test framework: common FakeResponse https://review.openstack.org/556551
15:00:11 efried mriedem: Done. Though I kinda like 'evalue'.
15:00:16 gibi jaypipes: do you have a minute for discussing the vnic_type issue or you prefer to have my reply in the review?
15:03:28 tssurya dansmith, mriedem: do you guys have some time now for a question ?
15:03:49 dansmith tssurya: shoot
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

Earlier   Later