Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2017-06-16
15:51:15 mriedem to fold the servers and search routes into the GET /os-hypervisors route using query parameters
15:51:35 mriedem https://developer.openstack.org/api-ref/compute/#hypervisors-os-hypervisors for context
15:51:49 mriedem i got to thinking last night,
15:52:16 mriedem search and servers were really just index with (1) hostname lookup pattern and (2) optional details on listing servers per host
15:52:31 mriedem folding those into index() as query parameters is natural
15:52:41 mriedem but then i got thinking last night,
15:52:57 mriedem if we add those as query parameters to index(), should we also add them as query parameters to GET /os-hypervisors/detail ?
15:53:09 mriedem because it would seem odd to be able to get per-host instance details from index, but not from detail
15:53:26 mriedem not that i'm looking for more work, but if i'm completely rewriting this API, we should probably do it properly
15:54:33 sdague yeh, well I've kind of thought the detail url pattern is a little bit broken. Because as far as I know no one users the main list
15:55:01 sdague but yes, any query parameters on index should also work on detail
15:55:02 mriedem what really got me thinking about this,
15:55:14 mriedem was in my change i'm using query parameter validation now, including on limit and marker for paging,
15:55:20 mriedem but didn't have that on detail() for the same microversion, which is odd
15:55:50 mriedem so you could do GET /os-hypervisors/detail?marker=uuid1&marker=uuid2 but not for GET /os-hypervisors
15:55:57 mriedem so yeah i guess i'm going to have to straighten that all out,
15:56:23 mriedem and i'll probably push an early change to consolidate all of the common code, since really index() and detail() are identical except for a boolean flag passed to show details
15:56:41 mriedem basically make it like how _get_servers works in the servers API
15:57:30 superdan mriedem: you good on this now? https://review.openstack.org/#/c/436094/
15:58:27 mriedem dropped my -1
15:59:19 superdan thanks
16:09:28 cfriesen mriedem: for the 2.47 novaclient changes, the point of --minimal (according to the help blurb) is that it doesn't do additional lookups. since we already have the data I figured we could just show it. I can artificially restrict the output though if we want, maybe only show the original name.
16:14:16 melwitt I could really use some cross-project-request-ids right now
16:14:54 sdague melwitt: they are mostly there
16:15:10 sdague thought, maybe the keystoneauth release regressed them
16:16:06 mriedem that's not going to help melwitt debug a havana problem
16:16:18 melwitt hey now, it's ocata
16:16:22 mriedem oh wow
16:16:39 sdague heh
16:27:44 openstackgerrit Artom Lifshitz proposed openstack/nova master: Plumbing for tagged nic attachment https://review.openstack.org/415622
16:27:47 openstackgerrit Artom Lifshitz proposed openstack/nova master: Delete nic metadata when detaching interface https://review.openstack.org/435387
16:28:11 openstackgerrit Artom Lifshitz proposed openstack/nova master: Delete disk metadata when detaching volume https://review.openstack.org/435082
16:28:24 openstackgerrit Artom Lifshitz proposed openstack/nova master: API support for tagged device attachment https://review.openstack.org/376021
16:28:24 openstackgerrit Artom Lifshitz proposed openstack/nova master: Plumbing for tagged volume attachment https://review.openstack.org/391941
16:29:59 mriedem superdan: i reckon we probably need to audit nova-status for multi-cell support at some point too
16:30:10 mriedem i know parts of it are counting things like compute nodes across cells
16:46:33 openstackgerrit Matt Riedemann proposed openstack/nova master: Add a status check for enabled filters https://review.openstack.org/427200
16:46:35 mriedem superdan: bauzas: ^ finally cleaned this up - not sure if we want to consider backporting that or not - if we did, we'd have to adjust it a bit
16:48:02 mriedem we should also see those warnings show up in the grenade logs because of the CoreFilter
16:49:24 openstackgerrit Chris Friesen proposed openstack/python-novaclient master: 2.47: Show flavor info in server details https://review.openstack.org/435141
16:53:25 sdague mriedem: https://github.com/sdague/nova-bug-tools/blob/master/stable-series-cleanup.py
16:55:44 sdague though if launchpad had reasonable search interfaces I wouldn't have to abuse their system so hard to find these series only bugs
16:58:13 mriedem sdague: ok
16:58:23 mriedem at some point that should probably live in the release-tools repo
17:00:43 sdague mriedem: maybe, right now I'm trying to build out some automation specific to experiments in nova. That one is probably more generic release oriented, but the rest of it seems like we're going to get more specific pretty quickly
17:00:57 sdague I have a bunch of uncommitted local work of experiments
17:01:56 mriedem ok. i'm going to be going down the placement rabbit hole this afternoon
17:02:13 figleaf mriedem: bring a lantern
17:05:48 mriedem i bring a ray of sunshine everywhere i go
17:13:34 eandersson mriedem: We should add an regression test for that commit imo
17:14:11 mriedem eandersson: oh your functional test?
17:14:26 eandersson Also, while this may fix master (actually not yet convinced), I don't think we can back port these changes to Mitaka/Newton
17:15:16 mriedem eandersson: we can backport dan's change to ocata and newton
17:15:19 eandersson I didn't write one for mine, but mostly because I had no clue how to write a test, but pretty sure we could write something simple
17:15:20 mriedem mitaka is basically eol upstream
17:15:53 eandersson It's funny because that is actually the fix I originally suggested :p
17:16:02 mriedem dan's change is 13 minutes from merge
17:16:43 mriedem we could still write a regression test and backport that before backporting the fix
17:16:53 mriedem if a regression test can be written
17:19:29 openstack Launchpad bug 1635367 in OpenStack Compute (nova) "Ram filter is broken since Mitaka" [High,In progress] - Assigned to Erik Olof Gunnar Andersson (eandersson)
17:19:29 melwitt this is the bug eandersson opened last year https://bugs.launchpad.net/nova/+bug/1635367 on overcommit being broken
17:24:21 openstackgerrit Merged openstack/nova master: Fix regression preventing reporting negative resources for overcommit https://review.openstack.org/474994
17:27:59 melwitt oh, already marked as duplicate. mriedem, that will hide that it's fixed to people searching though right? should the dupe be the other way around?
17:28:51 mriedem i didn't dupe it
17:29:23 mriedem it should probably be the other way around now though yes
17:29:24 melwitt oh. okay I'll fix it then
17:29:46 eandersson A little funny that it would be a dupe of a 3 hour old bug report :D
17:30:25 mriedem we can go either way i think
17:30:27 melwitt eandersson: it is, but I think that's the only way to make it look reasonable and not hide bug that shows the fix etc
17:30:45 melwitt I think someone told me the ones that get marked as dupes don't show up in searches etc
17:30:57 mriedem we can also dupe dan's against the original and change the status to fix released
17:31:00 mriedem on the originla
17:31:02 mriedem *original
17:31:27 melwitt okay, I can do that
17:31:53 eandersson Just don't mark it as fixed for Mitaka
17:32:21 melwitt yeah, will have to put that as won't fix I think
17:34:03 melwitt mriedem: are we gonna backport to mitaka? we still have a stable/mitaka branch
17:34:35 eandersson This is the kind of horrible issue that you will run in production, but won't notice until you reach capacity. So we should make it obvious that it's an issue for anyone running overcommit in Mitaka.
17:34:53 mriedem melwitt: mitaka is closed i think - the branch is there but i don't know if any ci works on it
17:35:19 melwitt okay
17:35:24 mriedem clarkb: is mitaka CI all dead now?
17:35:30 clarkb uh
17:35:35 clarkb no idea
17:35:39 mriedem ok
17:36:02 superdan didn't tony already announce mitaka as eol?
17:36:13 mriedem announcing and making it happen are different things
17:36:23 eandersson no mitaka eol tag yet at least
17:36:35 superdan I figured I'd have to backport it downstream only for mitaka, fwiw
17:37:18 superdan eandersson: do you want to propose backports of that to ocata and newton at least?
17:37:31 mriedem i was working on the ocata one
17:37:36 superdan eandersson: I'm happy to, but if you do, I can vote on them :P
17:42:35 sdague unless mitaka gets another release though it doesn't help much to stick it in git
17:43:44 superdan well, it helps people that pull from the git trees, but yeah
17:43:46 mriedem fwiw we did a novaclient mitaka release a week or two ago
17:46:20 sdague I'm not opposed to doing another mitaka release honestly, that fix seems like it would be worth it
17:47:21 sdague mriedem: ok, well I just closed out the kilo/liberty bug cruff, and moved all the Fix Committed => Fix Released in mitaka
17:50:21 mriedem ocata backport is posted for your viewing pleasure
17:50:30 mriedem https://review.openstack.org/475044
18:08:31 Redcavalier Hi, I believe I've found a bug in nova and I haven't seen any similar bug report. However, before I report it, I'd just like to validate it with someone if possible.
18:10:13 Redcavalier Essentially, when using the virtio-scsi driver for block devices, I get an error when I try to add additional block devices through cinder. The error is as follow : libvirtError: internal error: unable to execute QEMU command '__com.redhat_drive_add': Duplicate ID 'drive-scsi0-0-0-0' for drive

Earlier   Later