Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2018-12-04
16:01:02 cdent nested took all brains
16:05:57 openstackgerrit Jack Ding proposed openstack/nova master: [WIP] Preserve UEFI NVRAM variable store https://review.openstack.org/621646
16:36:42 openstackgerrit Merged openstack/python-novaclient master: Change openstack-dev to openstack-discuss https://review.openstack.org/621869
16:49:14 openstackgerrit Balazs Gibizer proposed openstack/nova master: Remove port allocation during detach https://review.openstack.org/622421
16:56:07 mriedem cfriesen: i think i also suggested that in denver
16:56:26 mriedem ala https://developer.openstack.org/api-ref/compute/?expanded=#list-port-interfaces
16:56:33 mriedem https://developer.openstack.org/api-ref/compute/?expanded=#list-volume-attachments-for-an-instance
16:58:15 mriedem although i guess that wasn't noted in the etherpad, so maybe i thought it elsewhere
16:58:18 cfriesen mriedem: you mean querying server groups by instance?
16:58:34 mriedem yes, rather than return server group information in the servers resource api,
16:58:40 mriedem you filter server groups by member
16:59:03 sean-k-mooney jaypipes: just spent the last few minute talking to the kuryr folks they are now aware of the ML post and will follow up there.
16:59:37 bauzas cfriesen: I agree with mriedem
16:59:53 bauzas cfriesen: ie. not directly providing a new field for the servers API
16:59:53 sean-k-mooney jaypipes: turns out they are storing the os-vif object in the k8s api as annotation on the pod/deployment and k8s stores them in ectd
16:59:58 cfriesen yeah, we've already got the backend DB API to do it. If you and Sylvain are both in favour, I can recommend we switch the spec around to propose that.
17:00:11 bauzas cfriesen: but I'm fine with any other API endpoint
17:00:21 bauzas like mriedem said
17:00:43 mriedem let me read the spec first
17:00:57 mriedem i might have notes on this in my diff analysis thing too, checking
17:01:07 cfriesen bauzas' suggestion is listed in the "alternatives" secution
17:01:32 mriedem at the ptg we said we couldn't show server groups when listing servers with details b/c it would be too inefficient, so we'd restrict to just GET /servers/{server_id} (show)
17:01:52 mriedem but filtering server groups by member would also be useful i think and solve the same problem
17:02:18 openstackgerrit melissaml proposed openstack/os-traits master: Change openstack-dev to openstack-discuss https://review.openstack.org/622429
17:02:41 mriedem cfriesen: yeah column 35 https://docs.google.com/spreadsheets/d/1ugp1FVWMsu4x3KgrmPf7HGX8Mh1n80v-KVzweSDZunU/edit?usp=sharing
17:02:47 mriedem maybe i just had this conversation in my head
17:02:53 cfriesen :)
17:02:59 mriedem er row 35
17:03:03 mriedem "Propose a spec if we want this. We could store the server group information with the instance in the instance_extra table, or add a "member" query filter to the GET /os-server-groups API to filter groups returned by server members."
17:04:09 openstackgerrit Filippo Inzaghi proposed openstack/osc-placement master: Change openstack-dev to openstack-discuss https://review.openstack.org/622432
17:06:11 cfriesen mriedem: okay...and I suppose it'd make more sense to make the filter query keyword "member" since that lines up with the "members" field in the server group response
17:09:22 mriedem i commented
17:09:45 mriedem i would make the filter parameter "members" to match the response parameter
17:10:12 mriedem the only question is if we'd use the same "in:" semantics that the placement API uses for things like member_of=in:42896e0d-205d-4fe3-bd1e-100924931787,5e08ea53-c4c6-448e-9334-ac4953de3cfa
17:10:31 mriedem cdent: remind me, why did we use "in" rather than just allow member_of to be a list?
17:10:37 mriedem expliciteness?
17:11:04 mriedem "members" for the server groups API filtering seems obvious that it would be a list
17:11:08 cdent mriedem: I think it was following pre-existing patterns and also to make it clear that it means "one of", not "all of"
17:11:20 mriedem ah
17:11:46 cfriesen I think GET /os-server-groups?members=server1,server2 would be clear enough
17:12:12 mriedem but then is that OR'ed or AND'ed
17:12:19 cdent reads as a
17:12:23 cdent AND
17:12:24 cdent to me
17:12:28 mriedem right, me too
17:12:31 cfriesen a given instance can only be a member of one group though
17:12:35 cfriesen so AND doesn't make sense
17:12:50 sean-k-mooney cfriesen: can it
17:12:59 mriedem yes
17:13:06 mriedem you can only specify the group when creating the server,
17:13:11 mriedem you can't add/remove members to/from groups
17:13:24 mriedem despite previous attempts to push that into the api
17:13:26 sean-k-mooney ok then GET /os-server-groups?member=uuid woudl be enough
17:13:50 sean-k-mooney unless you want GET /os-server-groups?members=server1,server2 to tell you if they are in the same group
17:13:51 cfriesen sean-k-mooney: mriedem wanted to be able to query the membership of multiple instances in one call
17:14:08 mriedem i'm not saying i want anything :)
17:14:21 mriedem i'm trying to figure out what the use cases are besides "show me the group my server is a member of"
17:14:24 mriedem since that is the obvious one
17:14:32 cfriesen okay..personally I think the idea would be that you list a bunch of instance via filter, then you want to query the group membership for that list of instances
17:14:37 mriedem but i'd also like to avoid having 4 microversions over time because of AND/OR wrinkles that people want later
17:15:00 mriedem the member_of filtering in GET /resource_providers seems sufficiently flexible for all cases,
17:15:04 mriedem which is why i was saying maybe we model that
17:16:06 mriedem cfriesen: in which case, ?members=server1,server2 is OR'ed
17:16:19 mriedem or maybe not :)
17:16:21 mriedem idk
17:16:35 mriedem hard to know what people want when users aren't the ones asking for the feature
17:16:49 cdent maybe just wait until they do?
17:17:17 jaypipes sean-k-mooney: awesome :(
17:17:19 sean-k-mooney members for me implies intersection with set of memeber so that becomes and unless the endpoint can retun multiple groups
17:17:47 mriedem cdent: well windriver must have had some use case for this since it's in starlingx
17:18:02 sean-k-mooney jaypipes: we shoudl still be able to change the data model but we will have to do so in a compaible way or over 2 releases
17:18:05 cfriesen cdent: a bunch of our users use server groups for anti-affinity
17:18:25 cfriesen cdent: and currently there's no way to easily determine what server group an instance is in
17:18:37 cfriesen cdent: you have to loop over all server groups and check their membership list
17:18:37 cdent sorry mriedem, cfriesen: I was mostly just extending the snark, and not being helpful
17:18:55 mriedem sean-k-mooney: GET /os-server-groups lists all server groups for the tenant
17:19:18 mriedem so yes it can return multiple
17:19:45 sean-k-mooney mriedem: in which case i would expect a list to be returned if it has one entry the are in the same group if it has multiple they are not
17:19:58 mriedem what if we have: (1) GET /os-server-groups?members=server1,server2 (intersection) and (2) GET /os-server-groups?members=in:server1,server2 (union)
17:20:19 sean-k-mooney oh like the compute filter stuff
17:20:57 sean-k-mooney im really not familar enough with this endpont im going to go read the api ref
17:21:10 cfriesen so it looks like the way /resource_providers has done intersection is via two separate "member_of" statements
17:22:07 mriedem yeah, GET /resource_providers?member_of=AGGA_UUID&member_of=in:AGGB_UUID,AGGC_UUID
17:22:19 mriedem in A and B or C
17:23:11 cfriesen okay, no point wasting people's time further, I'll recommend switching to something along those lines
17:23:18 sean-k-mooney mriedem: i mean it would work but to we need that?
17:23:24 mriedem sean-k-mooney: idk
17:23:38 mriedem i'm also ok with keeping v1 simple
17:23:48 mriedem and letting people bring more use cases later if they have them i guess
17:24:18 sean-k-mooney cfriesen: what was the starlingx/windriver extention by the way
17:24:31 mriedem they showed the server group name/uuid in the server response body
17:24:37 mriedem it wasn't part of the server groups API
17:24:41 cfriesen sean-k-mooney: we just added it to the server details unconditionally, but people are worried about bloating the details
17:24:44 sean-k-mooney oh ok
17:24:57 mriedem it's less about the bloat for me,
17:25:01 mriedem as the performance
17:25:07 mriedem b/c the server and the group are in different dbs
17:25:40 sean-k-mooney so you trying to create a dedicated endpoint to fulfil the same usecase without imapction openstack server show/list
17:25:46 openstackgerrit Nate Johnston proposed openstack/nova master: Replace neutron-grenade job with grenade-py3 https://review.openstack.org/622453
17:25:52 cfriesen on which topic...what about the stuff in https://review.openstack.org/#/c/612256 ? (displaying instance topology, pci devices, etc. as part of server details)

Earlier   Later