| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-10-04 | |||
| 17:29:39 | openstackgerrit | Surya Seetharaman proposed openstack/nova master: API microversion bump for handling-down-cell https://review.openstack.org/591657 | |
| 17:41:53 | openstackgerrit | Merged openstack/nova master: Add attach kwarg to base/nova-net allocate_for_instance methods https://review.openstack.org/605464 | |
| 17:43:30 | openstackgerrit | melanie witt proposed openstack/nova master: De-dupe subnet IDs when calling neutron /subnets API https://review.openstack.org/608040 | |
| 18:06:55 | openstackgerrit | melanie witt proposed openstack/nova master: De-dupe subnet IDs when calling neutron /subnets API https://review.openstack.org/608040 | |
| 18:11:10 | openstackgerrit | Merged openstack/nova master: consumer gen: support claim_resources https://review.openstack.org/583667 | |
| 18:25:25 | openstackgerrit | Vlad Gusev proposed openstack/nova master: Not set instance to ERROR if set_admin_password failed https://review.openstack.org/555160 | |
| 18:38:06 | jaypipes | melwitt, dansmith, other stable cores... https://review.openstack.org/#/c/607626/ would be great to review. thanks in advance. | |
| 18:40:10 | s10 | Please approve back ports for https://review.openstack.org/#/q/I27160140cbccf3e6914aed2dcff54d547e446c1f and https://review.openstack.org/#/q/topic:bug/1785827+(status:open+OR+status:merged) | |
| 18:46:07 | melwitt | jaypipes: +W | |
| 18:52:02 | melwitt | mriedem: this backport just needs an upgrade of your +1 to a +2/+W https://review.openstack.org/592337 | |
| 18:59:18 | jaypipes | melwitt: danke | |
| 18:59:29 | jaypipes | efried: left a question/thought for you on https://review.openstack.org/#/c/605902/ | |
| 19:01:32 | efried | jaypipes: For the sake of keeping things together, perhaps we should have that discussion on the spec. | |
| 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 | |