Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2017-11-20
15:04:32 mriedem do the pci requests only come through flavor extra specs?
15:04:38 mriedem or can they also come through image metadata?
15:05:01 bauzas efried: yup
15:05:22 bauzas acknowledged sounds the most appropriate
15:05:36 bauzas but it sounds less harsh in English than it sounds in French
15:05:42 bauzas anyway
15:05:49 bauzas we should open a new chan
15:06:04 efried #openstack-linguistic-nerdiness
15:07:03 bauzas efried: I was more thinking of a general #openstack-schmooze
15:07:27 efried bauzas Ironically, if you say "dont acte", it sounds like you're saying "don't act" in English, which is almost the opposite.
15:09:30 efried (By the way, you should not google "don't act")
15:10:26 bauzas efried: "eventually" is the most interesting false friend I know of
15:11:34 bauzas efried: 'éventuellement' means "maybe" in our language
15:12:30 efried bauzas How is that different from "peut-être"?
15:12:44 bauzas that's a synonym
15:13:45 efried bauzas Google translate doesn't agree, which I'm sure leads to lots of humorous exchanges: https://translate.google.com/#fr/en/%C3%A9ventuellement
15:14:54 efried bauzas In Spanish/Porguguese, "indroducir" means "insert", not "introduce". So people wind up saying, "Allow me to insert myself".
15:15:14 stephenfin mriedem: iirc, it's only for extra specs
15:15:49 efried stephenfin At least according to the docs, there's no affordance for PCI requests via image metadata. I'm like 80% sure.
15:16:56 stephenfin mriedem, efried: https://github.com/openstack/nova/blob/6535abdaaa73d92ebe9101626cc3f5b11117a194/nova/compute/api.py#L825-L834
15:17:19 sean-k-mooney you can request pci device using the alias in the flavor our via the vnic type on a neutorn port in the case of sriov nics
15:17:43 efried stephenfin sean-k-mooney Yup, that all gels with what I believed to be true.
15:17:49 efried (phew)
15:18:34 openstackgerrit Merged openstack/nova master: Fix docstring for GET /os-migrations and related DB API https://review.openstack.org/520200
15:18:40 openstackgerrit Merged openstack/nova master: api-ref: make a note about os:scheduler_hints being a top-level key https://review.openstack.org/519717
15:19:00 sean-k-mooney efried: i do belive that some peole wante to be able to restrict the type of sriov device that could be passthough via the image metadata at some point but i dont think that ever went anywhere
15:19:11 efried Good to know.
15:20:10 sean-k-mooney efried: e.g. i only have intel nic driver so when i state that in image metatdata via vendor ids and product ids and then request an sriov nic in neutron and nova would make sure it iwas an intel one
15:20:36 efried sean-k-mooney But that's now done via the whitelist, nah?
15:20:56 sean-k-mooney efried: no they are two different things
15:22:15 sean-k-mooney the whitelist is the operators way to say this is what i will allow to be passed through . in the neutron sriov case it will be resticted to that list, but this was a way to allow tenants to say i only budeled x drives in my image so limit to those vedors
15:22:42 efried sean-k-mooney That makes sense. But you say that never got implemented?
15:23:10 openstackgerrit Andreas Jaeger proposed openstack/nova master: DNM - test updated releasenotes job https://review.openstack.org/520677
15:23:57 sean-k-mooney correct there was also a counter proposal for it to be supported as an atribute on the neutron port when you set vnic type direct via the port binding profile but neither were impleneted in the end
15:24:11 cfriesen mriedem: what's your plan for https://review.openstack.org/#/c/521200/ vs https://review.openstack.org/#/c/520660 ? Are you looking to break it up into a number of smaller commits?
15:26:32 mriedem cfriesen: do you mean because of this? https://review.openstack.org/#/c/520660/5/nova/compute/api.py@2954
15:27:51 mriedem cfriesen: as i see it, https://review.openstack.org/#/c/520660/ is really fixing 2 things, (1) rebuilding a volume-backed server changes the instance.image_ref from '' to $image_id, and (2) rebuilding a volume-backed server with a different image from what's in the root volume doesn't fail in the api
15:28:23 mriedem thinking about backports, i think backporting the fix for (1) is an easier case than (2)
15:28:29 cfriesen mriedem: whoops, I meant https://review.openstack.org/#/c/521391....which seems to be the same as 520660
15:28:56 mriedem it's not the same
15:29:19 mriedem https://review.openstack.org/#/c/521391/ fixes the bug where any volume-backed server, regardless of the image being different or not, sends the instance through the scheduler
15:29:25 mriedem for rebuidl
15:29:26 mriedem *rebuild
15:29:51 mriedem w/o introducing the change that changing the image makes the api fail
15:30:03 mriedem it's a subtle difference
15:30:29 cfriesen mriedem: right...so are you basically proposing breaking up 520660 into a number of commits?
15:31:00 mriedem i already broke 520660 into 2 changes, but 520660 could also be broken into 2 more changes if we wanted
15:31:11 mriedem where the final change in the series is the new behavior to fail fast if the image is changing on a volume-backed instance
15:31:47 efried There goes mriedem, breaking stuff again.
15:32:03 alex_xu efried: which bug you want me help to debug? I see there is a mention in the scheduler meeting
15:32:26 efried alex_xu The crossing-aggregates thing
15:34:03 alex_xu efried: ah, i see, there are some testcase you/gibi added
15:34:18 efried alex_xu Yes, all part of the pile :)
15:34:40 cfriesen mriedem: the thing that's confusing me is that 521391 is still included in 520660
15:34:49 alex_xu efried: I will try, but I'm in the travel from tomorrow.
15:35:03 cfriesen oh, wait, I see....you're just adding the else clause
15:35:15 efried alex_xu No worries. It's probably something jaypipes should be looking at too/instead.
15:36:25 jaypipes wait, I thought the scheduler meeting was in 25 minutes? :( daylight savings and all that...
15:37:13 efried jaypipes Wrong direction. It was 1.5h ago.
15:37:16 efried DST is stupid.
15:37:28 jaypipes oh ffs... sorry :(
15:37:45 efried jaypipes http://eavesdrop.openstack.org/meetings/nova_scheduler/2017/nova_scheduler.2017-11-20-14.00.log.html
15:37:56 jaypipes danke
15:38:23 openstackgerrit Elod Illes proposed openstack/nova master: Deduplicate keypair notification samples https://review.openstack.org/521562
15:38:25 efried jaypipes Some interesting discussion at the end...
15:40:06 openstackgerrit Eric Fried proposed openstack/nova master: placement: Document microversion header in api-ref https://review.openstack.org/521563
15:40:12 efried mriedem Like-a-that? ^
15:40:52 alex_xu efried: yea
15:41:54 mriedem efried: no
15:41:55 mriedem in https://developer.openstack.org/api-ref/placement/#placement-api
15:42:44 efried mriedem As in, the section above the section titled "Versions" ?
15:43:26 mriedem yes
15:43:30 mriedem commented inline
15:44:18 efried mriedem Ack
15:47:06 maciejjozefczyk jaypipes: Could you please take a look on https://review.openstack.org/#/c/520024/
15:47:18 maciejjozefczyk jaypipes: :) ?
15:48:02 jaypipes maciejjozefczyk: you see the func test failure in that? is it related to your changes?
15:48:24 openstackgerrit ayoung proposed openstack/nova master: Admin API Policy contingent on is_admin_project https://review.openstack.org/384148
15:49:03 maciejjozefczyk jaypipes: yes it fails and my questions are about how to fix it
15:49:25 jaypipes maciejjozefczyk: k, gimme a sec to finish reading the scheduler meeting notes and I'll look into it.
15:49:32 maciejjozefczyk jaypipes: thx
15:50:14 jaypipes efried: "<efried> I see clients finding it useful to be able to do one call and get a single blob with all that information collated." <-- that's kinda like the purpose of GET /allocation_candidates in a way.
15:50:16 mriedem jaypipes: stephenfin: i'm +2 on the placement osc plugin patch for rp inventories https://review.openstack.org/#/c/457533/ - it has some warts which i'll clean up in a follow up patch, but would be good to keep this ball rolling
15:51:55 efried jaypipes I can see that. The difference being the input parameters: GET /allocation_candidates wants me to tell it what resources/traits I need. Versus saying "here's a RP - give me all the information about that guy".
15:52:08 jaypipes efried: yes, understood.
15:52:42 efried jaypipes Which is basically what that new SRC method get_provider_tree is doing. But on the client side, via 2N+1 calls (ish)
15:53:00 jaypipes efried: though one might make the argument that the code in https://review.openstack.org/#/c/521098/4/nova/scheduler/client/report.py only needs to be run once and the client is the appropriate place to put that logic and caching.
15:53:31 efried jaypipes Only once... per what?
15:53:47 jaypipes efried: per instantiation of the report client.
15:54:21 efried jaypipes And then the report client has to keep the local copy of ProviderTree up to date whenever Something Changes?
15:54:38 jaypipes efried: err, that's already exactly what it does...
15:54:51 jaypipes self._provider_tree.
15:55:13 efried jaypipes Hum, which I was *not* planning to pass into the virt driver.
15:55:36 jaypipes efried: I was hoping you'd pass a clone()/deepcopy of self._provider_tree.
15:56:06 efried jaypipes Maybe - need to look into that further. But if I do, self._provider_tree is gonna need to be populated with more stuff than it is today, I think.
15:56:20 jaypipes efried: and do the diff against self._provider_tree when update_inventory() runs and the resulting ProviderTree is sent to reportclient for set_inventory_for_tree() (or whatever that method is named)
15:56:24 efried Also, self._provider_tree very well may be a superset of what the virt driver cares about. But I suppose that's okay.
15:57:11 efried jaypipes I think keeping-local-copy-current may be doable when the compute node owns all the resources. But sharing providers could (and will) be updated from outside. So we'll have to resync those periodically.
15:58:45 jaypipes efried: sure, but that's a relatively rare operation and the compute worker won't be updating inventory records against shared providers (it will delete allocations against shared providers, of course, when terminations happen)
15:59:11 efried jaypipes Actually, I do see virt updating shared provider records.

Earlier   Later