| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-10-04 | |||
| 19:09:04 | dansmith | are you guys cheating? | |
| 19:09:21 | efried | ah dammit, I thought you said dansmith wasn't here | |
| 19:09:31 | dansmith | I'm always here. | |
| 19:19:32 | jaypipes | efried: sorry, standup meetings... | |
| 19:19:46 | efried | Well, you're a standup kind of guy. | |
| 19:23:48 | jaypipes | lol | |
| 19:25:33 | efried | btw, the irony is not lost on me that standup meetings, which are supposed to be standup so they're short, are consuming your whole day. | |
| 19:25:39 | mriedem | fwiw, translating flavor extra specs that the driver needs to placement traits in a pre-request filter doesn't seem too hair brained, we've talked about the same kind of thing for translating volume multiattach boot requests to query allocation candidates via compute node capabilities | |
| 19:26:26 | dansmith | mriedem: yeah I said that in the meeting | |
| 19:26:32 | dansmith | it's basically what request filters are for | |
| 19:27:02 | mriedem | if we do it generically it should be ok - just don't add one filter per extra spec | |
| 19:27:05 | mriedem | that would be hair brained | |
| 19:27:07 | efried | mriedem: FYI we're doing a hangout in ~34min, and there's a spec https://review.openstack.org/#/c/607989/ where the options are laid out and we're collecting thoughts | |
| 19:27:13 | dansmith | mriedem: you are not PTOing well | |
| 19:27:23 | mriedem | i'm T-33 minutes until nephew gets home | |
| 19:27:27 | mriedem | at which point i'll drop off | |
| 19:27:45 | dansmith | not a good excuse | |
| 19:27:52 | mriedem | after listening to AM radio for 4 hours in the car i needed something to do | |
| 19:28:08 | efried | mriedem: Then you may register your vote in the spec, and we'll make up everything else you might have said. | |
| 19:28:45 | dansmith | mriedem: do you have an opinion of not just adding another hw_ spec and making this a trait requirement in the flavor? | |
| 19:28:46 | dansmith | so we get the scheduling for free | |
| 19:30:11 | mriedem | but the driver still needs to know about the thing right? | |
| 19:30:23 | dansmith | sure, it just looks for the presence of that on the flavor | |
| 19:30:26 | mriedem | which we then figure out from the trait on the flavor rather than an extra spec? | |
| 19:30:29 | dansmith | like we do for gpus today | |
| 19:30:33 | dansmith | right | |
| 19:30:36 | mriedem | is tha twhat we do for gpus today? | |
| 19:30:37 | mriedem | i didn't know | |
| 19:30:41 | dansmith | yeah | |
| 19:30:42 | mriedem | then sure | |
| 19:30:54 | efried | does jaypipes know about that ^ ? (the GPU thing) | |
| 19:30:58 | mriedem | throw it in a method that knows what to look for and it doesn't matter if its extra spec or trait | |
| 19:31:06 | sean-k-mooney | dansmith: today we enable a gpu by addign a trait? | |
| 19:31:09 | jaypipes | efried: still standing... | |
| 19:31:11 | dansmith | sean-k-mooney: no | |
| 19:31:21 | dansmith | sean-k-mooney: it's a resource, but same difference | |
| 19:31:33 | sean-k-mooney | dansmith: not quite | |
| 19:31:35 | dansmith | we looked at the flavor initially, now I think we just inspect the allocation, but.. same sort of thing | |
| 19:31:35 | efried | I thought for GPUs we use conf to populate traits to get scheduling, and then the driver looks at the same conf ... | |
| 19:31:45 | efried | oh, yeah, if it's a resource vs traits that's totally different | |
| 19:31:54 | efried | well, according to *some people* | |
| 19:31:54 | sean-k-mooney | dansmith: a hpet is not a consumable resouce | |
| 19:31:56 | dansmith | it seems entirely un-different to me | |
| 19:32:03 | dansmith | sean-k-mooney: I'm aware, thanks :) | |
| 19:32:17 | dansmith | the mechanism by which the driver knows to configure a thing is the same | |
| 19:32:49 | efried | ftr I have no problem with that, been thinking along those lines since Denver-part-one, but Jay, Ed, and Chris all vetoed the idea pretty hard, then and since. | |
| 19:33:17 | dansmith | I think the difference between your concern and theirs is whether or not the traits are opaque | |
| 19:33:24 | dansmith | could be wrong, but that seems to be the stumbling block | |
| 19:33:35 | efried | I'm not talking about key/value encoding at all. | |
| 19:34:02 | dansmith | maybe we should wait for the hangout? | |
| 19:34:21 | efried | I think the argument is that the trait is *not* opaque if the driver is doing a string compare to effect some config change on the guest.... sure :) | |
| 19:34:26 | sean-k-mooney | dansmith: i was goint got comment but your right :) | |
| 19:34:44 | dansmith | efried: I would respond to your comment with an argument, but I will wait | |
| 19:35:46 | efried | Above was me being devil's advocate (for several specific values of "devil"). I don't feel that way. | |
| 19:35:53 | efried | i.e. I think you and I are in agreement, dansmith | |
| 19:36:14 | efried | ikr | |
| 19:36:58 | efried | Swhy the whole ownership traits thing caused a rift in the continuum. | |
| 19:37:40 | sean-k-mooney | efried: ya so did anything come of that? | |
| 19:38:00 | efried | sean-k-mooney: I think it's dead. Ed and Jay are -1. | |
| 19:38:02 | sean-k-mooney | i assumed it died on the vine at the ptg but i have not been following | |
| 19:38:10 | efried | no, it was agreed upon at the ptg | |
| 19:38:15 | efried | so I put up a patch for it, sec... | |
| 19:38:25 | efried | sean-k-mooney: https://review.openstack.org/#/c/602160/ | |
| 19:39:40 | sean-k-mooney | hehe i like the doc string | |
| 19:40:11 | sean-k-mooney | traited is a ajative that is not used often enough | |
| 19:40:39 | efried | Given Jay's (albeit reluctant) capitulation on the ML, we *might* still get away with using custom traits for ownership for a little while until we have that represented in some native key/value form (Jay's preference being an actual column in the resource provider table). | |
| 19:40:54 | efried | but I don't see the standard traits flying. | |
| 19:41:30 | jaypipes | ok, I'm back now.. sorry about that | |
| 19:41:39 | sean-k-mooney | was that not the original propsoal. add an owner colume to the resouce providers | |
| 19:41:50 | dansmith | sean-k-mooney: it was, and it was NAKd | |
| 19:41:59 | dansmith | it was for a different reason though | |
| 19:43:00 | dansmith | the consumer type/owner has to not be just "cinder", "nova" if we want to support the multi-service possibility, | |
| 19:43:16 | dansmith | which means you really only know "is this mine or not" if you're looking at that field | |
| 19:43:25 | dansmith | which is probably okay | |
| 19:43:50 | sean-k-mooney | oh but that would be an ower of an allocation not an ower of the resouce provider | |
| 19:44:09 | dansmith | ah you're right I'm confusing these two things | |
| 19:45:09 | efried | We do have to assume well-behaved API client code. And I don't think we want to, like, make the providers only appear to their owners, that would be crazy. | |
| 19:45:28 | efried | so yeah, load up a provider record, look at the owner field, if it ain't me, don't dork with it. | |
| 19:45:41 | sean-k-mooney | for owner of the resouce provder we disucssed 3 options. a trait. a nameing schem or a new db/object filed. the first two did not need placement change and the trait could be standardised so we suggeted that one | |
| 19:45:49 | sean-k-mooney | at least i think that was the rough logic | |
| 19:46:11 | efried | ++ | |
| 19:46:24 | dansmith | yep | |
| 19:46:24 | cdent | could (not saying it is a good idea, just being a completist) also use an aggregate | |
| 19:46:27 | efried | But Jay was out of the room or something. | |
| 19:46:48 | sean-k-mooney | cdent: yes that could also work | |
| 19:46:56 | dansmith | efried: he was there, but doing the "sit in the back of the room looking like he wants to kill everyone" thing he does | |
| 19:47:05 | sean-k-mooney | that came up in related to neutron and rack scale design before | |
| 19:47:57 | efried | oh, see, if he had been out of the room actually killing someone, that might have been a good excuse | |
| 19:48:08 | dansmith | depends on who | |
| 19:48:22 | efried | comes back in dripping blood, "Okay, now what decisions did y'all make without me?" | |
| 19:48:50 | jaypipes | dansmith: s/kill someone/kill himself/ .... but yeah. that. | |
| 19:49:04 | sean-k-mooney | jaypipes: arent you glad you rejoined chat | |
| 19:49:34 | jaypipes | are we ready to hangout? | |
| 19:50:11 | dansmith | https://hangouts.google.com/call/7dw4HGf7o0A9UahxcR3ZAAEE | |
| 19:50:18 | dansmith | we can watch jaypipes make that look until it's time | |
| 19:50:30 | melwitt | I'm gonna lurk | |
| 19:53:07 | efried | cfriesen, sean-k-mooney, jackding: | |
| 19:53:43 | cdent | dansmith, efried, jaypipes: i'm unable to join, but as I said before: the combined might of the brains involved ought to be able to get it right, but I do hope you will be summarizing to email or whatever please and thank you. | |
| 19:54:26 | sean-k-mooney | efried: sorry was making tea. joining | |
| 19:55:54 | melwitt | bauzas: it's hangout time ^ | |