| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-10-04 | |||
| 19:02:23 | jaypipes | efried: or the hangout later... | |
| 19:02:24 | efried | jaypipes: I agree it makes sense to allow the trait to be in the image. Not sure that means we shouldn't also support it in the flavor, or that we should allow it to be present in the flavor and still hit a non-capable host. | |
| 19:02:38 | jaypipes | efried: ack, totes | |
| 19:03:03 | jaypipes | efried: and it's not like we have the ability to say "this trait can only go in an image metadata k/v and not a flavor extra spec k/v..." | |
| 19:03:12 | efried | jaypipes: I assume we would support something like hw:hpet=True in image meta. | |
| 19:03:38 | efried | so really any of the three options in the spec could be applied to both flavor and image | |
| 19:03:44 | jaypipes | efried: I was just pointing out that for *some* of these things, the trait makes more sense as a constraint that is derived from an image, versus a constraint coming from a flavor... | |
| 19:03:55 | efried | oh, yeah, totally agree with you there. | |
| 19:04:17 | efried | If the op wants the flavor to be flexible in terms of which arch it lands on, don't put arch-specific stuff in it. | |
| 19:04:24 | efried | that seems like a fair rule of thumb | |
| 19:04:57 | jaypipes | ya | |
| 19:05:28 | jaypipes | efried: I guess what I'm saying is I don't think a decision on the traits thing should hold up jding's patch. | |
| 19:06:05 | efried | jaypipes: no, but the decision about whether to fail if I see the request but can't fulfil it. | |
| 19:06:13 | efried | ^ should hold up the patch | |
| 19:06:34 | jaypipes | efried: but again, if the guest/image arch isn't x86, the flavor's HPET extra spec makes no difference... | |
| 19:06:53 | efried | so that's where I think we disagree. | |
| 19:07:00 | efried | If you've asked for a thing in the flavor, you should get the thing, or fail. | |
| 19:07:10 | efried | unless you want to call it hw:hpet_if_you_can_please | |
| 19:08:55 | efried | jaypipes: I added a note here: https://review.openstack.org/#/c/607989/1/specs/stein/approved/support-hpet-on-guest.rst@23 | |
| 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 | ++ | |