| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-03-07 | |||
| 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 | |
| 14:50:24 | jaypipes | efried: I said it on the hangout the other day with Sundar and I've said it at each of the past PTGs where the whole custom RCs vs traits was discussed. | |
| 14:50:32 | efried | We should fix that regardless. | |
| 14:50:41 | efried | we've got multiple threads potentially dorking with traits already. | |
| 14:50:58 | mriedem | jaypipes: the good news is phil day was good about writing useful commit messages https://review.openstack.org/#/c/104957/ | |
| 14:52:05 | dansmith | mriedem: am I missing where in there is justifies being user-only? | |
| 14:52:30 | mriedem | "They can be defined per project or per user within a project" | |
| 14:52:32 | jaypipes | mriedem: "They can be defined per project or per user within a project" <-- shows me that user-specific quota *always* will be "within a project" and therefore should have had the project_id in the query. | |
| 14:52:33 | mriedem | i'm also looking | |
| 14:52:40 | jaypipes | lol. jiunx. | |
| 14:52:43 | edleafe | efried: capabilities don't change dynamically. State does. | |
| 14:53:09 | jaypipes | edleafe: zactly. | |
| 14:53:21 | dansmith | mriedem: yeah that just doesn't tell me why | |
| 14:53:59 | jaypipes | dansmith: fwiw, I wasn't wondering why it's a user-specific quota, just why the query for it wasn't also appending a project_id | |
| 14:54:09 | cdent | efried: we've got generations on adding traits to providers. | |
| 14:54:13 | dansmith | jaypipes: okay | |
| 14:54:35 | jaypipes | cdent: that's not what I'm referring to actually. :) | |
| 14:54:36 | mriedem | yeah idk either on the server group member user-only quota check, | |
| 14:54:40 | mriedem | if it was a mistake, | |
| 14:54:51 | mriedem | it sure farted it's way through several very large changes and different cores | |
| 14:55:05 | cdent | jaypipes: well I kind of assumed not, but got a bit lost trying to track all of this round about | |
| 14:55:05 | mriedem | too bad we don't have people around that maintain this code... | |
| 14:55:53 | mriedem | maybe sdague would remember.... | |
| 14:56:18 | cdent | so jaypipes what does "there is zero generation protection for multiple threads changing a provider's traits." | |
| 14:56:21 | mriedem | cyeoh and ken'ichi moved it through | |
| 14:56:21 | jaypipes | cdent: specifically, this is the protection that doesn't exist when traits are used as faux inventory: https://github.com/openstack/placement/blob/master/placement/objects/allocation.py#L427-L447 | |
| 14:56:33 | cdent | jinxish | |
| 14:56:35 | efried | cdent, jaypipes: Updating what traits are set on a resource provider <== has generation controls. Phew. | |
| 14:56:56 | jaypipes | efried: not for claiming resources. | |
| 14:57:02 | efried | oh, sure, traits aren't part of an allocation | |
| 14:57:04 | jaypipes | efried: which is what I've been saying. | |
| 14:57:05 | efried | that's just fine. | |
| 14:57:27 | efried | had me scared there for a minute | |
| 14:58:09 | cdent | jaypipes: so your concerned about the case where we've chosen a target on which we want to allocate and since we selected it, the traits of that thing have changed? | |
| 14:58:41 | efried | We also don't do ^ for aggregate memberships we originally used to gather the candidate. | |