| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-12-04 | |||
| 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 | |
| 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 | |
| 17:46:19 | efried | wha, wha? | |
| 17:46:28 | efried | how far back am I reading? | |
| 17:46:34 | mriedem | just post to the ML and let efried catch up there | |
| 17:46:43 | sean-k-mooney | efried: https://review.openstack.org/#/c/612256/7/specs/stein/approved/show-server-numa-topology.rst | |
| 17:46:58 | sean-k-mooney | but ya we can disscuss on the ML too | |
| 17:47:48 | sean-k-mooney | efried: i was just wondering if we could make feature like this work well across powervm, libvirt, hyperv ectra | |
| 17:48:12 | efried | sean-k-mooney: PowerVM doesn't expose or allow you to muck with its numa topology. | |
| 17:49:22 | sean-k-mooney | but would i have info taht might make debuing for an admin simpler when dong device passhtou/cpu pinning/numa that could be useful to expose | |
| 17:50:01 | sean-k-mooney | i was just wondering how driver specific it would be or not | |
| 17:50:36 | sean-k-mooney | anyway im going to go grab food. ill be back later | |
| 17:54:51 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Fix guestfs.set_backend_settings call https://review.openstack.org/524748 | |
| 18:31:47 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Add ratio online data migration when load compute node https://review.openstack.org/613499 | |
| 18:31:48 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Add compute_node ratio online data migration script https://review.openstack.org/609995 | |
| 18:33:37 | openstackgerrit | Eric Fried proposed openstack/nova-specs master: Spec: Provider config YAML file https://review.openstack.org/612497 | |
| 19:34:08 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Add compute_node ratio online data migration script https://review.openstack.org/609995 | |
| 19:34:29 | mriedem | jaypipes: i was just updating ^ and leaving comments probably while you were | |
| 19:34:35 | mriedem | see if your comments are addressed | |
| 19:34:50 | mriedem | oh wait | |
| 19:34:56 | mriedem | nvm, was thinking of https://review.openstack.org/609995 | |
| 19:37:20 | mriedem | jaypipes: dansmith: bauzas: efried: i'm +1 on this series https://review.openstack.org/#/q/topic:bp/initial-allocation-ratios+(status:open+OR+status:merged) because i wanted to wait to +2 so that all of the changes can be approved together, since 2 and 3 in the series are kind of inter-dependent a bit, | |
| 19:37:45 | mriedem | so i'm looking for another +2 on the last 2 changes - the ones that deal with the online data migration | |
| 19:38:23 | efried | I'll look if you get desperate. But the discussion in placement has me convinced I am a tard when it comes to anything involving "data migration". | |
| 19:38:43 | mriedem | :/ | |
| 19:43:00 | jaypipes | mriedem: ack. will look in a bit. | |
| 19:43:40 | cfriesen | maybe a weird question, but how does nova-manage handle authentication? is it based off the config file and whoever is allowed to run the executable? | |
| 19:44:30 | cfriesen | I'm trying to sort out dependencies | |
| 19:49:47 | melwitt | cfriesen: yes. I think it doesn't yet [or may never] do anything like call out to REST APIs (doesn't need keystone auth). the auth info for the database access is part of the [database]connection and [api_database]connection settings in the nova config file. and generally admin RequestsContext are used so nova-manage is able to access any database record | |
| 19:51:33 | cfriesen | melwitt: thanks, that confirms what I thought. | |
| 20:07:30 | prometheanfire | mriedem: ping :D | |
| 20:07:39 | prometheanfire | you remember what we've done in the past for libvirt fails on rhel based stuff and uppdating stable branches? https://review.openstack.org/622548 the intention is that they would backport to ocata afaik | |
| 20:12:02 | mriedem | prometheanfire: well, upper-constraints is less of an issue, it's lower-constraints that really matters for stable | |
| 20:12:29 | mriedem | i have no idea what the support matrix is for stable/ocata wrt centors | |
| 20:12:31 | mriedem | *centos | |
| 20:12:40 | prometheanfire | mriedem: true, problem is libvirt starting to fail due to a minor release... | |
| 20:13:14 | prometheanfire | on gentoo I've always left it uncapped so the latest stable is always used | |
| 20:13:24 | prometheanfire | haven't had complaints, yet | |
| 20:14:11 | mriedem | so centos 7.6 (released yesterday) has libvirt 4.5 and therefore libvirt-python 4.4 from u-c fails to build with it, because it needs to be >= 4.5 right? | |
| 20:14:31 | prometheanfire | something like that, ya | |
| 20:15:31 | prometheanfire | the author would know more I imagine | |
| 20:15:44 | mriedem | i left a comment, only wondering why 4.10 is used over 4.5 | |
| 20:15:46 | mriedem | to match libvirt | |
| 20:16:27 | prometheanfire | mainly because it's the latest release and using a newer one is fine (and hopefully future proofs stuff a little) | |
| 20:20:01 | mriedem | ok, shrug; it's weird having something in u-c that is so dependent on native package versions | |
| 20:20:25 | mriedem | it would also be weird to me to update libvirt-python in stable/ocata u-c at this point, especially given what limited CI coverage we run on ocata now | |
| 20:21:22 | mriedem | i know nova doesn't run centos jobs on ocata (or anywhere ever) | |
| 20:21:25 | prometheanfire | ya, iirc libvirt-python is the only thing like that | |