| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-12-04 | |||
| 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/ | |
| 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 | 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:32:53 | cfriesen | that would be for admin-only by default policy | |
| 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 | |
| 17:39:12 | mriedem | melwitt: https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:master+topic:bug/1806064 fixes a quota check cleanup regression since pike | |
| 17:39:14 | cfriesen | what about adding the numa topology info to the diagnostics endpoint? | |
| 17:39:44 | sean-k-mooney | cfriesen: the priamary usecase is admin dubuging yes | |
| 17:39:46 | mriedem | cfriesen: that's probably a better place for that kind of informatoin | |
| 17:39:49 | melwitt | mriedem: thx. had just opened a tab for that one | |
| 17:40:05 | mriedem | cfriesen: given it's already got hardware-specific details in it | |
| 17:40:35 | mriedem | i think it also has some flexibility for virt-specific backend stuff | |
| 17:41:00 | sean-k-mooney | looking at https://developer.openstack.org/api-ref/compute/?expanded=list-server-groups-detail,show-server-group-details-detail,show-server-diagnostics-detail#servers-diagnostics-servers-diagnostics ya | |
| 17:41:05 | sean-k-mooney | it has a driver field | |
| 17:41:36 | mriedem | it is a bit more biased to current usage though, it gets info from the hypervisor | |
| 17:42:06 | sean-k-mooney | we could proably extend the cpu_details and memory_details dicts to include the info | |
| 17:42:33 | mriedem | this is the libvirt code fwiw https://github.com/openstack/nova/blob/5f648dda49a6d5fe5ecfd7dddcb5f7dc3d6b51a6/nova/virt/libvirt/driver.py#L8609 | |
| 17:43:13 | cfriesen | maybe add a new "topology" section? | |
| 17:43:14 | mriedem | so there are 3 options: (1) include it directly in the server response details, (2) add a new subresource endpoint to servers (for show on a single server only), (3) make it part of diagnostics (which is also per server) | |
| 17:43:26 | mriedem | at this point you might want to take those 3 options to the ML | |
| 17:43:37 | cfriesen | okay, can do. | |
| 17:43:52 | sean-k-mooney | well we are already passing in the instance to that function and its in the dirver so that seam very doable | |
| 17:43:59 | mriedem | b/c alex_xu and gmann will probably also have input | |
| 17:44:17 | mriedem | sean-k-mooney: b/c the information they get comes from the driver, | |
| 17:44:25 | mriedem | for what this wants, we don't really need the driver, | |
| 17:44:32 | mriedem | we're just dumping info out of the db | |
| 17:45:19 | sean-k-mooney | mriedem: that is true altough i wonder if any of the driver treat the extra specs different | |
| 17:45:43 | mriedem | idk, i don't deal in numa | |
| 17:45:53 | mriedem | nova/virt/hardware.py is where i stop | |
| 17:46:07 | sean-k-mooney | cfriesen: efried: would praobly be another person to take a look | |