| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-12-04 | |||
| 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 | cdent | sorry mriedem, cfriesen: I was mostly just extending the snark, and not being helpful | |
| 17:18:37 | cfriesen | cdent: you have to loop over all server groups and check their membership list | |
| 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/ | |
| 17:31:21 | sean-k-mooney | you could also have a /servers/detail/toplogy endpoint if you did but ill take a look | |
| 17:31:29 | sean-k-mooney | melwitt: welcome back o/ | |
| 17:31:38 | melwitt | thanks sean-k-mooney | |
| 17:32:12 | cfriesen | sean-k-mooney: I'm open to suggestions. :) we just included it in /servers/detail but we don't have ginormous numbers of instances | |
| 17:32:41 | sean-k-mooney | cfriesen: im not sure how i feel about the incltion of physical_mapping | |
| 17:32:53 | cfriesen | that would be for admin-only by default policy | |
| 17:32:53 | mriedem | belmoreira: tssurya: while you're around, did anyone ever create a nova bug to track that issue where you disable computes for maintenance of a cell but because of the allocation candidate result limit, we end up getting novalidhost b/c placement returns all disabled computes? | |
| 17:33:18 | cfriesen | sean-k-mooney: it's useful for admins to debug issues, making sure that things are where nova thinks they are | |
| 17:34:00 | sean-k-mooney | it is but im still not sure how i feel about it which is a good thing as it means i dont hate it | |
| 17:34:06 | cfriesen | lol | |
| 17:34:43 | sean-k-mooney | cfriesen: i think the respoce for this would be large enough to warrent its own enpoint honestly | |
| 17:35:39 | cfriesen | sean-k-mooney: could you mention that on the spec review? | |
| 17:35:50 | sean-k-mooney | yes | |
| 17:36:00 | sean-k-mooney | i also need to read the sepc | |
| 17:36:15 | sean-k-mooney | oh its nice an short | |
| 17:36:39 | sean-k-mooney | i just went strait to the json responce | |
| 17:36:42 | mriedem | it's nice and short b/c it does'nt say anything | |
| 17:36:47 | cfriesen | the other thing I'm not sure how to handle is jaypipes comment about not wanting a JSON blob | |
| 17:36:48 | mriedem | user wants this, so do it | |
| 17:37:11 | mriedem | i definitely don't think we should be dumping random unversioned json blobs out of the api | |
| 17:37:14 | sean-k-mooney | well in this case i think this is 75% admin only stuff | |
| 17:37:26 | mriedem | we had ^ with the diagnostics api already | |
| 17:37:36 | sean-k-mooney | mriedem: i agree with that | |
| 17:38:48 | sean-k-mooney | i know i had started working on convertin alot of the pic request/alias stuff to ovos a while back. we would want this endpont to be independet of the libvirt definitons | |