| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-03-07 | |||
| 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 | |
| 14:31:13 | sean-k-mooney | edleafe: more or less | |
| 14:31:41 | edleafe | sean-k-mooney: ugh, that's what it sounds like | |
| 14:31:43 | efried | mriedem: https://review.openstack.org/641678 <== python-novaclient release | |
| 14:31:48 | sean-k-mooney | edleafe: the suggestion was to tag the fpga RP with a CUSTOM_ trait for the bitstream it is programed with | |
| 14:32:23 | efried | we doing this again? | |
| 14:32:23 | edleafe | sean-k-mooney: yeah, that was discussed and rejected a while ago. Looks like it's back from the dead. | |
| 14:32:35 | efried | it was not rejected | |
| 14:32:41 | efried | It was not anyone's favorite | |
| 14:32:42 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Refactor bandwidth related functional tests https://review.openstack.org/641679 | |
| 14:32:58 | sean-k-mooney | efried: ya i know im not really objecting to it | |
| 14:33:15 | sean-k-mooney | efried: i just thing that there is a better way of modeling it | |
| 14:33:22 | efried | edleafe: but it was agreed upon (by which I mean "consensus" - i.e. not everybody cast an aye vote) as the lesser evil | |
| 14:34:05 | mriedem | efried: ack, will take a look after i'm back from the bus stop | |
| 14:34:15 | sean-k-mooney | efried: for what its worth we never discussed the model im now proposeing and i think jaypipes and other may like it and it will enable more usecase for cyborg to | |
| 14:34:51 | smcginnis | mriedem_afk, efried: Correct, no need to tag milestone beta's unless you know there are downstream consumers that could use it. | |
| 14:35:55 | sean-k-mooney | efried: would you like me to write up a more detailed proposal? | |
| 14:35:58 | efried | If a "dynamic child provider" model is really seen as far superior to this design, we can look at switching to it in U or later. | |
| 14:35:58 | efried | sean-k-mooney: We have been in analysis paralysis on this thing for too long. We need to make forward progress. The design as currently represented in the PoC is what we agreed on in Denver after discussing it at every PTG for the past two years. It is simple. It works. It would be counterproductive to try to redesign it yet again at this stage. | |
| 14:36:14 | cdent | sean-k-mooney, efried, edleafe: didn't we make a decision many months ago that we should just stick with, even if it isn't perfect? | |
| 14:36:33 | efried | this ^ | |
| 14:36:37 | efried | because there is no perfect | |
| 14:37:08 | sean-k-mooney | for the record we also commited to having the poc working by m1 at the latest | |
| 14:37:53 | edleafe | cdent: I guess I don't remember a decision, just lots of back-and-forth discussion. Maybe it was in Berlin, and that's why I don't recall it? | |
| 14:38:33 | cdent | edleafe: not certain. I _think_ I'm remembering Denver. | |
| 14:38:58 | efried | sean-k-mooney: m1 of what? At this point we're proposing it for train, since stein has sailed. The PoC is ready now. | |
| 14:39:08 | sean-k-mooney | cdent: this discusstion predates teh creation of placement. at least my involvement in it does | |
| 14:39:38 | cdent | sean-k-mooney: then I think you've proving my point | |
| 14:39:40 | sean-k-mooney | efried: the poc was expected to be completed by m1 of stein | |
| 14:39:55 | efried | sean-k-mooney: if we were going to get it into stein, sure. | |
| 14:40:23 | jaypipes | mriedem: is it a 0% chance of getting the quota-in-placement series reviewed and merged today then? even if I take over the bottom patch? there's actually a lot of good in that series and it opens up much-needed refactoring and cleanup in Train if we can get it done (not to mention a simpler way of reasoning about quotas) | |
| 14:40:36 | efried | cdent, edleafe: Denver is where consensus was reached. | |
| 14:40:52 | dansmith | jaypipes: yes, zero chance of landing the whole thing | |
| 14:40:53 | jaypipes | mriedem_afk: and yes, I realize I'm coming at this way late. | |
| 14:41:30 | dansmith | jaypipes: at best we could land the bottom few to get the data model in place, but the top several functional ones haven't seen review and rushing it today is not okay with me | |
| 14:46:47 | mriedem | jaypipes: dansmith: right if we take over the changes we'd get up through the online data migration, | |
| 14:46:59 | mriedem | which is arguably useful to get done earlier than later so there is less data to migrate in train, | |
| 14:47:06 | jaypipes | ++ | |
| 14:47:08 | mriedem | but if we're unsure of the design at this point then we should defer | |
| 14:48:40 | jaypipes | efried, edleafe, sean-k-mooney: I will remind yet again that there is zero generation protection for multiple threads changing a provider's traits. that protection only exists on the quantitative side of the house -- i.e. inventory and resource classes. | |
| 14:49:12 | mriedem | i'll dig through git history to see if i can find any words around why server group member quota is enforced at the user rather than project leve | |
| 14:49:15 | mriedem | *level | |
| 14:49:19 | sean-k-mooney | jaypipes: yep i know which is part of why i was hoping to avoid that. | |
| 14:49:21 | mriedem | i'm sure this is probably something melwitt would have memorized by now | |
| 14:49:34 | sean-k-mooney | jaypipes: anyway i dont want to get into it now | |
| 14:49:43 | efried | whoah, that I didn't realize. | |
| 14:49:52 | dansmith | mriedem: yeah I think we've been over that before.. definitely doesn't seem like something we can change on a whim regardless of the reason | |