| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-12-04 | |||
| 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) | |
| 17:25:53 | mriedem | the endpoint already exists, | |
| 17:25:58 | mriedem | this would be adding a filter parameter to it | |
| 17:26:21 | sean-k-mooney | mriedem: your right i prhased that incorrectly | |
| 17:26:26 | mriedem | cfriesen: i think that would have to be part of the server response since we don't have separate endpoints for numa/pci | |
| 17:26:44 | mriedem | we had os-pci years ago until i killed it | |
| 17:27:22 | sean-k-mooney | mriedem: i assuem os-pci listed the avalibe devices or somethin similar | |
| 17:28:12 | mriedem | https://github.com/openstack/nova/blob/juno-eol/nova/api/openstack/compute/plugins/v3/pci.py | |
| 17:28:57 | sean-k-mooney | oh it was part of nova v3 api no onder i dont remember it | |
| 17:29:36 | cfriesen | sean-k-mooney: would appreciate your take on https://review.openstack.org/#/c/612256 (displaying detailed topology stuff for servers) | |
| 17:30:11 | sean-k-mooney | cfriesen: well i was just wonder if a /servers/{server_id}/toplogy endpoint made sense | |
| 17:30:34 | sean-k-mooney | cfriesen: i assume we would not need this endpoint in a list view? | |
| 17:31:06 | melwitt | o/ | |