| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-03-26 | |||
| 14:42:11 | mriedem | i'll look at the scheduler patch after the scheduling meeting | |
| 14:42:21 | dansmith | mriedem: I -1d the docs patch so it should be okay until after, | |
| 14:42:40 | dansmith | mriedem: it's actually not a linear set anymore | |
| 14:42:56 | mriedem | yeah i see that now, which is why the create_cell change merged probably | |
| 14:43:00 | mriedem | anywho | |
| 14:43:09 | dansmith | yeah, not a huge deal to me, but whatever you want | |
| 14:43:20 | mriedem | johnthetubaguy: can i get you to come back on this nova-status ironic flavor migratoin patch? https://review.openstack.org/#/c/527541/ | |
| 14:43:24 | kashyap | Dan / Matt, when you get a moment, does this look better? https://review.openstack.org/#/c/534384/15/nova/virt/libvirt/driver.py | |
| 14:43:31 | mriedem | i don't think we can drop the ironic flavor migration stuff in the driver until nova-status has a check for it | |
| 14:43:31 | kashyap | (Tests pass, and also release note builds.) | |
| 14:43:55 | mriedem | kashyap: what happened to putting a 'choices' or hard-coding the only option to pcie for the backport? | |
| 14:44:16 | mriedem | not a different option, but restricting the single choice for the backport and then opening it up on master | |
| 14:44:18 | kashyap | mriedem: Yep, that's what I did. But, the check is in driver.py | |
| 14:44:22 | mriedem | oh | |
| 14:44:27 | kashyap | mriedem: That's exactly what I did :-) | |
| 14:44:36 | mriedem | why not 'choices' kwarg on the config option itself? | |
| 14:44:41 | kashyap | Because, there's no 'choices' for ListOpt() for Oslo class | |
| 14:44:47 | kashyap | Only for StrOpt(0 | |
| 14:44:47 | efried | see dev ML :) | |
| 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) | |