Earlier  
Posted Nick Remark
#openstack-nova - 2017-06-16
15:15:47 mriedem plus, i think this only shows up if a node is down right?
15:15:53 mriedem ironic i mean
15:18:27 sdague mriedem: ok, so what do you want the behavior to be on these stable bugs?
15:19:36 sdague like should I start converting them over to Fix Released? Or make a tool so you can do that when running the release?
15:19:37 mriedem sdague: if they are released then i guess the status should be fix released
15:19:58 sdague mriedem: right, well for dead branches, that's easy to determine
15:20:02 sdague for live ones, less so
15:20:03 mriedem we don't know if they are released though w/o pulling the change down and checking tags
15:20:21 openstackgerrit Baodong (Robert) Li proposed openstack/nova master: [WIP] Expose vlan trunking in metadata/configdrive https://review.openstack.org/471874
15:20:25 sdague mriedem: right
15:20:35 sdague when are the next stable releases scheduled?
15:20:39 mriedem or we just punt and do like on master and say if it's committed it's released
15:20:45 mriedem sdague: they aren't scheduled
15:20:50 sdague mriedem: ok
15:20:50 mriedem they are more or less on demand
15:21:30 sdague ok, well that's kind of option B. I can put this into a tool that can be run on a branch when a release is done, and it would sweep everything to fix released then
15:26:01 openstackgerrit Ed Leafe proposed openstack/nova master: Extract custom resource classes from flavors https://review.openstack.org/473627
15:26:31 mriedem sdague: we could just provide the release tag / version to the tool so it can leave a comment when switching the lp bug status to fix released too
15:26:35 mriedem to simplify
15:26:47 mriedem melwitt: i think there are a couple of issues in this one https://review.openstack.org/#/c/457861/
15:26:54 mriedem for after your friday morning super meeting
15:26:57 sdague mriedem: sure
15:27:49 mriedem anyone fancy going through the bottom 4 quotas changes here? https://review.openstack.org/#/c/446241/ - i'm +2 on all, they are pretty mechanical
15:28:24 melwitt mriedem: super meeting was 7-8, but I'm digging into a bugzilla right now. will look when I can
15:33:29 mriedem cfriesen: looking at your novaclient change, the tests are much more readable now w/o the evals and stuff :)
15:43:56 mriedem cfriesen: i think you're missing handling --minimal for nova show
15:43:57 mriedem so -1 for that
15:50:50 mriedem alex_xu: if you're around
15:50:59 mriedem alex_xu: sdague: so this os-hypervisors API change i'm working on,
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: Plumbing for tagged volume attachment https://review.openstack.org/391941
16:28:24 openstackgerrit Artom Lifshitz proposed openstack/nova master: API support for tagged device attachment https://review.openstack.org/376021
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 melwitt this is the bug eandersson opened last year https://bugs.launchpad.net/nova/+bug/1635367 on overcommit being broken
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: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

Earlier   Later