Earlier  
Posted Nick Remark
#openstack-nova - 2017-05-26
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
19:19:29 mriedem mtreinish: plus anything in the devref is going to get out of date
19:19:43 artom melwitt, I just discovered a couple of days ago ;)
19:19:55 melwitt launchpad, you are full of mysteries
19:20:17 mtreinish mriedem: well if we don't actually write it down anywhere how are people supposed to know what's needed?
19:20:18 mriedem just like http://cosmosmysteryarea.com/index.html
19:20:20 artom For all we know LP is where The Matrix will come from
19:20:42 mriedem mtreinish: requirements.txt + bindep?
19:21:28 mriedem we used to have a fairly full package list in https://docs.openstack.org/developer/nova/development.environment.html#explicit-install-clone
19:21:34 mriedem but then we got bindep and that was cleaned up
19:21:50 melwitt lol, we have the same thing in santa cruz https://www.mysteryspot.com/
19:22:23 mtreinish mriedem: and bindep are just the deps for running the tests (like what you need to build libxml, etc)
19:23:19 mtreinish like where does it say I need qemu-img installed?
19:23:37 mriedem mtreinish: where does it say you need hyper-v or vcenter installed?
19:23:49 mriedem or a power 8 rack for powervm? :)
19:24:11 mriedem https://docs.openstack.org/ocata/config-reference/compute/hypervisors.html
19:24:21 mriedem is anything hypervisor specific
19:26:02 mtreinish mriedem: well powervm isn't in tree :)
19:26:41 sdague mtreinish: surprise! it mostly is
19:27:03 openstackgerrit Chris Dent proposed openstack/nova master: Changing deleting stale allocations warning to debug https://review.openstack.org/468519
19:27:10 mtreinish oh, it started merging
19:27:56 mriedem yeha
19:27:57 mriedem *yeah
19:28:06 mtreinish mriedem: so I agree there are some bits that are config dependent, but clearly outlining the requirements for using nova seems like something we should do
19:28:08 mriedem i actually got on efried the other night about docs
19:28:21 mriedem mtreinish: i have triaged it as opinion
19:28:30 mriedem which means it is now in purgatory
19:28:38 mtreinish mriedem: especially since there are things which you need like qemu-img which are always needed (at least from what I could tell)
19:28:45 mtreinish mriedem: what does opinion even mean?
19:28:53 mriedem it means, meh
19:28:55 cdent mriedem: I've pushed fixes for both of those bugs, but only ran the nearby tests before I did. It is time for my weekend to start so feel free to fix everything I've forgotten.

Earlier   Later