Earlier  
Posted Nick Remark
#openstack-nova - 2017-05-26
18:33:43 mriedem yup
18:36:24 artom mriedem, the InstanceNotFound test thing - better to squash the two patches into one in the backport, or leave separate?
18:36:56 mriedem artom: gonna be hard to separate them since it's writing a test for something already fixed on master
18:37:27 artom mriedem, it could be fix first then test in the top patch. But yeah, squash makes more sense
18:37:34 mriedem unless you mean the test backport comes after the fix backport on stable too
18:37:38 mriedem ok
18:37:41 mriedem either way
18:38:34 mriedem cdent: figleaf: anyone want to pick that up? seems like just needs to handle that InstanceNotFound in RT, but i didn't review that original patch
18:38:53 cdent mriedem: i can give it a try, that's what I was thinking too
18:39:07 artom I noticed lyarwood proposed the fix for ocata too - if you're still around lyarwood, mind if I jump in in your patch and add the test?
18:39:36 mriedem why is this a warning? https://review.openstack.org/#/c/460177/12/nova/compute/resource_tracker.py@1013
18:40:01 mriedem because the RT shouldn't be cleaning up allocations when the scheduler/conductor is?
18:41:31 openstackgerrit Artom Lifshitz proposed openstack/nova master: Test InstanceNotFound handling in 'nova usage' https://review.openstack.org/468514
18:41:50 cdent warning seems wrong to me.
18:42:29 mriedem "WARNING I AM DOING THAT THING YOU ASKED ME TO DO"
18:42:55 cdent i'll change that too?
18:43:02 mriedem separate
18:43:09 mriedem but wow http://logstash.openstack.org/#dashboard/file/logstash.json?query=message%3A%5C%22Deleting%20stale%20allocation%20for%20instance%5C%22%20AND%20tags%3A%5C%22screen-n-cpu.txt%5C%22&from=7d
18:44:05 mriedem cdent: it was latent https://review.openstack.org/#/c/460177/12/nova/scheduler/client/report.py@a929
18:44:10 figleaf cdent: sorry, was heads down and just saw the above. You got it?
18:44:10 mriedem and if that's in ocata we'll want to backport that
18:44:59 cdent figleaf: yeah, you carry on on your stuff, should be fine
18:45:01 mriedem crap it's all the way back to newton https://github.com/openstack/nova/commit/9374566d194be1e861e7d08dd0e3b2a615ff408c
18:45:08 mriedem cdent: i'll open a separate bug for the warning
18:45:14 cdent ✔
18:47:35 mriedem https://bugs.launchpad.net/nova/+bug/1693903
18:47:35 openstack Launchpad bug 1693903 in OpenStack Compute (nova) "Excessive "Deleting stale allocation for instance" warnings in nova-compute logs" [Undecided,New]
18:47:39 openstackgerrit Sean Dague proposed openstack/nova master: Be more tolerant of keystone catalog configuration https://review.openstack.org/438049
18:47:58 sdague lbragstad / mriedem ^^^
18:58:19 mriedem sdague: commented. some issues in the release note
18:58:38 mriedem i thought the validation in the quota sets api happened in ocata so i was wrong there, we probably do want the new note under the upgrade section
18:58:43 mriedem but let's do it in a separate new release note please
19:00:32 sdague mriedem: ok, I'm trying to understand what you wanted as release notes
19:00:34 sdague because in the last patch you said make it a dedicated one
19:01:04 sdague oh, that it shows up so much later that we just need a whole other file?
19:01:27 sdague walk me through your ideal world here, I'll make it :)
19:01:44 sdague also, irc client crash, so my back buffer is gone
19:02:04 mtreinish sdague: I want world peace
19:04:32 mriedem sdague: the release note you're updating is already in a tagged release,
19:04:36 mriedem so it should be a separate file
19:04:43 mriedem tox -e venv -- reno new <something>
19:05:11 openstackgerrit John Griffith proposed openstack/nova master: WIP/POC Implement new attach Cinder flow https://review.openstack.org/330285
19:05:15 mriedem sdague: i was also confused because i thought we had this validation in the quotas api in ocata,
19:05:18 mriedem but we don't,
19:05:41 sdague ok, separate file is fine
19:05:44 mriedem so i think you just need to add a new release note with an upgrade impact that notes the thing about not being able to find keystone v3 will result in a 400 for these apis now
19:06:04 sdague I don't think this is an upgrade impact
19:06:09 sdague I actually think it mitigates one
19:06:15 mriedem if ksa does the magic to find v3 and the only issue is if v3 isn't there, then maybe the upgrade impact is just, 'nova requires keystone v3 now'
19:06:37 sdague the previous patch actually required unversioned keystone endpoint
19:06:44 mriedem it's an upgrade impact if you don't have keystone v3 right?
19:06:51 sdague sure
19:07:00 lbragstad yeah - i was going to say something like that in the comment here - https://review.openstack.org/#/c/438049/7/nova/api/openstack/identity.py,unified
19:07:00 mriedem which i dont think we required before this
19:07:13 sdague mriedem: it's actually kind of unclear if we did or not
19:07:31 sdague it turns out if we'd had this patch, tripleo would have worked
19:07:33 mriedem alternative we don't release note it
19:07:35 sdague without any changes
19:07:37 lbragstad reading the error on lines 45 - 48 make it seem like nova requires v3
19:07:48 sdague lbragstad: it does for this call
19:08:25 mriedem i think i'm just trying to say, if we were unsure before, we're sure now
19:08:29 mriedem so seems we should note that
19:08:31 sdague mriedem: yes, that's fair
19:08:41 mriedem but...the existing reno has GET /v3/projects/project_id in it
19:08:47 mriedem which implies v3 is required
19:08:52 mriedem so maybe we just don't need a release note for this fix
19:09:02 sdague yeh
19:09:13 sdague I was just looking, that is what I'd sort of go with
19:09:23 mriedem i'm good either way
19:09:31 sdague the only other item is the fact that we fixed a bug we introduced in p1
19:09:38 mriedem right that tripped me up
19:09:55 sdague but, for people that don't consume this until pike final, saying that might be really confusing
19:09:58 mriedem i very much doubt many people are in product on p1 right now
19:10:04 mriedem right
19:10:23 mriedem so i'd either say nothing, no new reno, or new reno that just has an upgrade impact saying keystone v3 is for sure required now
19:10:33 sdague ok, lets go nothing
19:10:47 mriedem read my lips, no, new, reno
19:11:00 openstackgerrit Sean Dague proposed openstack/nova master: Be more tolerant of keystone catalog configuration https://review.openstack.org/438049
19:13:10 mriedem +2
19:14:31 openstackgerrit Matt Riedemann proposed openstack/nova master: Migrate to oslo request_id middleware - mv 2.46 https://review.openstack.org/467998
19:14:51 openstackgerrit Matt Riedemann proposed openstack/nova master: Updated from global requirements https://review.openstack.org/468089
19:15:01 mriedem sdague: also +2 on your 2.46
19:15:04 mriedem melwitt: ^
19:15:47 mriedem artom_: so about this bug https://bugs.launchpad.net/nova/+bug/1692893 - what you reported is really a duplicate of the other bug, so shouldn't we duplicate it?
19:15:47 openstack Launchpad bug 1692893 in OpenStack Compute (nova) "'nova usage' returns 500 when deleted row in instance_extra is archived" [Undecided,New]
19:16:11 melwitt mriedem: +W
19:16:56 openstackgerrit Chris Dent proposed openstack/nova master: Catch InstanceNotFound when deleting allocations https://review.openstack.org/468517
19:17:02 artom_ mriedem, I specifically didn't because duplicating it would hide it from search results, and I feel like my report is more relevant to actual users, as opposed to the other Tempest stacktrace
19:17:30 mriedem ok, well, i just duplicated it :)
19:17:39 artom mriedem, *shrug*
19:17:44 mriedem i didn't think about search results
19:18:03 artom I don't feel that strongly about it
19:18:43 melwitt hm, I didn't think dupes got hidden from search results
19:18:54 artom It warns you before you do it
19:18:57 mriedem mtreinish: so i just read https://bugs.launchpad.net/nova/+bug/1692376
19:18:57 openstack Launchpad bug 1692376 in OpenStack Compute (nova) "Binary dependencies aren't easily discoverable" [Undecided,New]
19:19:03 artom So I went to duplicate it, and then thought otherwise
19:19:04 mriedem mtreinish: and....idk
19:19:21 melwitt artom: interesting, never knew that
19:19:21 mriedem mtreinish: the binary dependencies you need are going to depend on service and configuration

Earlier   Later