Earlier  
Posted Nick Remark
#openstack-nova - 2018-10-04
16:26:11 efried l8r
16:26:24 efried or "bis später" :)
16:26:54 bauzas heh, I won't finally have opportunity to speak German this year, but okay
16:41:45 openstackgerrit Gaudenz Steinlin proposed openstack/nova master: Ignore misleading resource updates from virt driver https://review.openstack.org/523006
16:48:16 openstackgerrit melanie witt proposed openstack/nova master: Use nova-consoleauth only if workaround enabled https://review.openstack.org/607068
16:52:00 openstackgerrit melanie witt proposed openstack/nova master: Use nova-consoleauth only if workaround enabled https://review.openstack.org/607068
17:04:15 sean-k-mooney dansmith: did ye have that hangout on hpet extraspec vs trait vs both ?
17:04:23 dansmith sean-k-mooney: in two hours
17:05:00 sean-k-mooney oh ok cool in that case i have time to read the specs properly
17:10:38 efried dansmith: three hours?
17:10:53 dansmith efried: 2000 UTC is 1200 PDT no?
17:11:15 dansmith oh sorry, I was looking at dublin time
17:11:17 dansmith yeah three hours
17:12:01 sean-k-mooney ya dublin is currently on irish summer time
17:12:14 sean-k-mooney hopefully daylight saving will no longer be a thing soon
17:14:26 openstackgerrit Merged openstack/nova stable/ocata: nova-manage - fix online_data_migrations counts https://review.openstack.org/605842
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 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:35 dansmith we looked at the flavor initially, now I think we just inspect the allocation, but.. same sort of thing
19:31:45 efried oh, yeah, if it's a resource vs traits that's totally different
19:31:54 sean-k-mooney dansmith: a hpet is not a consumable resouce
19:31:54 efried well, according to *some people*
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 :)

Earlier   Later