| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-03-07 | |||
| 13:39:17 | efried | okay, just propose a novaclient release? | |
| 13:39:31 | mriedem | yeah, will need this first https://review.openstack.org/#/c/637234/ | |
| 13:39:35 | efried | ...after checking if there's anything... yeah | |
| 13:41:36 | openstackgerrit | Merged openstack/python-novaclient master: Add support for microversion v2.72 https://review.openstack.org/637234 | |
| 13:42:14 | gibi | and it is merged ^^ | |
| 13:43:07 | openstackgerrit | Kashyap Chamarthy proposed openstack/nova-specs master: cpu-model-selection: s/cpu_models/cpu_model_list/ https://review.openstack.org/640866 | |
| 13:43:14 | kashyap | yaawang: ^ Hope that fixes it | |
| 13:43:34 | jaypipes | mriedem: answered. | |
| 13:43:49 | jaypipes | mriedem: fine to put a single index on user_id. was a good catch from dansmith | |
| 13:44:08 | jaypipes | mriedem: in a future patch, we can add a dual index if that is something we see is needed. | |
| 13:44:45 | jaypipes | mriedem: as melwitt stated, the server group members query is on user only, not project, so a dual index on (project_id, user_id) would not help that query. | |
| 13:45:21 | mriedem | jaypipes: but this one does use both https://review.openstack.org/#/c/638072/17/nova/objects/instance_mapping.py@407 | |
| 13:45:47 | jaypipes | ffs... | |
| 13:46:05 | mriedem | so i guess we'd want a user_id and user_id+project_id index? | |
| 13:46:19 | jaypipes | mriedem: no, it doesn't actually. | |
| 13:46:25 | jaypipes | mriedem: it's two queries :( | |
| 13:46:40 | jaypipes | mriedem: that ffs wasn't directed at you. | |
| 13:46:55 | jaypipes | mriedem: each .scalar() is a sep query. | |
| 13:47:00 | mriedem | yeah i realize | |
| 13:47:11 | mriedem | this is a pattern in the quota qounting query code... | |
| 13:47:13 | mriedem | in a few places | |
| 13:47:19 | jaypipes | oh, I see.. | |
| 13:47:25 | jaypipes | hrmph | |
| 13:48:36 | jaypipes | mriedem: ok, well if the pattern is that user_id is always queries along with project_id, then yes, the index should be on (project_id, user_id) | |
| 13:49:06 | mriedem | well project_id isn't always in there https://review.openstack.org/#/c/638324/19/nova/objects/instance_mapping.py@466 | |
| 13:49:57 | mriedem | the first one above is a replacement for the "instances" quota counting which is over project and user, | |
| 13:50:09 | mriedem | the latter is the server group members query which is just on user_id | |
| 13:50:20 | mriedem | "server_group_members" quota count query i should say | |
| 13:50:22 | jaypipes | does it need to be, though? | |
| 13:50:37 | jaypipes | in other words, can we add a project filter to the query? | |
| 13:50:40 | openstackgerrit | ya.wang proposed openstack/nova master: Select cpu model from a list of cpu models https://review.openstack.org/637834 | |
| 13:50:58 | gibi | nova meeting starts in 9 minutes on #openstack-meeting | |
| 13:50:59 | mriedem | server group member quota is enforced at the user, not project, level | |
| 13:51:22 | mriedem | jaypipes: https://github.com/openstack/nova/blob/master/nova/quota.py#L1075 | |
| 13:52:42 | bauzas | any urgent code review before FF ? | |
| 13:52:53 | bauzas | I looked at the etherpad, but it's a bit messy :( | |
| 13:53:10 | mriedem | it is yes | |
| 13:53:14 | bauzas | disclaimer: long series can't be honestly reviewed | |
| 13:53:17 | mriedem | i'm just trying to sort out the index question on https://review.openstack.org/#/c/633349/ | |
| 13:53:28 | jaypipes | good lord that is an expensive quota check :( | |
| 13:53:45 | mriedem | i don't know if we'll try to merge part of this instance mapping user_id series or not | |
| 13:54:00 | mriedem | it's getting to be too late to be having these types of questions | |
| 13:54:18 | bauzas | mriedem: do you want some other eye's lookup ? | |
| 13:54:59 | bauzas | I saw this series in the etherpad, but I was thinking it was a bit difficult to review it by only 6 hours | |
| 13:55:08 | openstackgerrit | Rodolfo Alonso Hernandez proposed openstack/nova-specs master: Boot a VM with an unaddressed port https://review.openstack.org/641670 | |
| 13:55:16 | mriedem | the bottom 4-5 changes have had a lot of review from me and dansmith actually | |
| 13:55:30 | bauzas | there is a -W from melwitt, can we still review ? | |
| 13:55:40 | jaypipes | mriedem: is there a technical reason why we couldn't still filter by project as well as user on that server group members quota query? | |
| 13:55:52 | mriedem | bauzas: that was procedural while waiting for approval of the changes above | |
| 13:55:54 | jaypipes | (seems like it's just a mistake in the original code) | |
| 13:56:04 | bauzas | mriedem: okay, then I'll look | |
| 13:56:41 | mriedem | jaypipes: i don't think it's an oversight | |
| 13:56:55 | jaypipes | mriedem: why not? | |
| 13:57:03 | mriedem | anyway, i wouldn't want to have to go down that rathole on FF | |
| 13:57:10 | jaypipes | ack | |
| 13:57:48 | mriedem | i'd have to dig into when server group member quota was added | |
| 13:57:57 | mriedem | we do have some per-user quota checks on purpose, | |
| 13:57:59 | mriedem | like keypairs i think | |
| 13:59:19 | mriedem | efried: https://review.openstack.org/#/c/637234/ is merged now if you want to start a novaclient release, or after the meeting | |
| 13:59:33 | efried | argh, meeting, thanks for the reminder. | |
| 13:59:38 | efried | mriedem: was just starting the release. | |
| 14:01:00 | jaypipes | mriedem: I understand the keypairs being user_id-specific. not so much the server groups one. | |
| 14:09:10 | efried | mriedem: So microversion parity changes don't count as major bump-worthy? | |
| 14:09:32 | mriedem | efried: no, since they are opt-in features | |
| 14:09:39 | mriedem | major is for backward incompatible changes | |
| 14:09:43 | efried | okay. | |
| 14:09:45 | mriedem | semver baby | |
| 14:10:12 | openstackgerrit | Rodolfo Alonso Hernandez proposed openstack/nova-specs master: Boot a VM with an unaddressed port https://review.openstack.org/641670 | |
| 14:18:53 | mriedem | yikun: efried: i saw yikun posted a topic proposal for nova/cyborg integration https://etherpad.openstack.org/p/DEN-train-nova-brainstorming - question is if that should be a forum or ptg session? it might be fine to have both. | |
| 14:19:12 | mriedem | forum session to lay out the goals/requirements and ptg session to talk about design/implementation details | |
| 14:19:38 | mriedem | i know our product team wants to focus on fpga integration with nova but it sounds like upstream cyborg team is talking more about gpu support? which we already have in nova. | |
| 14:22:01 | mriedem | yikun so i'd be in favor of a forum session | |
| 14:22:15 | efried | The more the better as far as I'm concerned. | |
| 14:22:16 | sean-k-mooney | mriedem: for what tis worth fpga integration with openstack is 1 already possible via pci passthrough and 2 on our products teams wishlist too to do without relying on pci passthouhg | |
| 14:22:53 | efried | though I'm kinda hoping to have the nova/cyborg integration design mostly agreed upon before Denver | |
| 14:23:04 | efried | since we already had it agreed upon after *last* Denver. | |
| 14:23:11 | mriedem | ok i guess i didn't know about #1, i only really ever hear about people using gpus | |
| 14:23:45 | sean-k-mooney | efried: by the way i think i have a path forward that jaypipes and you might like on one topic | |
| 14:23:50 | efried | mriedem: "Can do it with PCI passthrough" isn't a thing that should stop us doing stuff with cyborg. We've been trying to make PCI passthrough DIAF for years now. This is the opportunity to do that. | |
| 14:24:20 | mriedem | efried: sure, that's not my point | |
| 14:24:32 | efried | okay, sorry, I didn't get your point then | |
| 14:25:10 | sean-k-mooney | efried: when cyborg reprogams an fpga for mutiple tenatn. why dont we jsut create a child resouce provider form the otrgin device resouce provider with the new capablities listed as traits on the new RP and new invetores of the resouce it provides | |
| 14:25:25 | efried | sean-k-mooney: How does that help anything? | |
| 14:25:53 | sean-k-mooney | efried: we dont need to ever update the traits or resouce clases on the original RP | |
| 14:26:04 | mriedem | considering we'll be lucky to get *anything* of substance done wrt nova/cyborg integration, what is the biggest benefit of a new feature functionality we could add with that integration? gpus w/o passthrough or fpgas? we already have a lot of people using gpus with passthrough in nova, and we have vgpus, so it seems like fpga would be the bigger first "win" from an integration. | |
| 14:26:09 | sean-k-mooney | the orginal RP device inventory can be consumed by cyborg | |
| 14:26:41 | sean-k-mooney | and cyborge can create a dynamic child with the image capablities when its programed | |
| 14:26:57 | efried | how would the claim sequence work? | |
| 14:27:46 | sean-k-mooney | if you want ipsec ofload you make a resouce request for the ipsec class if you want a device you use a fpga device resource class | |
| 14:27:51 | sean-k-mooney | i can write something up | |
| 14:28:15 | efried | It sounds like a really complicated way to do the same thing as the existing design. | |
| 14:28:19 | sean-k-mooney | but basically you should be able to support both multi and singel tenant use of a device | |
| 14:28:28 | efried | for what benefit, preserving architectural purity? | |
| 14:28:34 | sean-k-mooney | efried: well we agreed to not update the rp in the existing desing | |
| 14:28:40 | efried | huh? | |
| 14:28:45 | sean-k-mooney | at least not in phase 1 | |
| 14:29:13 | efried | Not to update its inventory, yes. But we agreed to use dynamic traits to signify bitstreams. | |
| 14:30:13 | sean-k-mooney | efried: yes which means if a bitstream can support 8 concurent consumer fo aes compression we agreed that you cannot create a new inventory to model that | |
| 14:30:42 | edleafe | efried: is "dynamic traits" a euphemism for "tracking state"? | |
| 14:30:55 | sean-k-mooney | without creating new inventories you cannot alleratiors that have mulit tenatn bitstreams | |