| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-05-26 | |||
| 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 | openstack | Launchpad bug 1692893 in OpenStack Compute (nova) "'nova usage' returns 500 when deleted row in instance_extra is archived" [Undecided,New] | |
| 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: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 | openstack | Launchpad bug 1692376 in OpenStack Compute (nova) "Binary dependencies aren't easily discoverable" [Undecided,New] | |
| 19:18:57 | mriedem | mtreinish: so i just read https://bugs.launchpad.net/nova/+bug/1692376 | |
| 19:19:03 | artom | So I went to duplicate it, and then thought otherwise | |
| 19:19:04 | mriedem | mtreinish: and....idk | |
| 19:19:21 | mriedem | mtreinish: the binary dependencies you need are going to depend on service and configuration | |
| 19:19:21 | melwitt | artom: interesting, never knew that | |
| 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. | |
| 19:29:01 | mriedem | cdent: thanks | |
| 19:31:13 | sdague | mtreinish: I think writing the arch install guide in nova tree is out of scope. That is kind of part of what the install guide and packaging is about | |
| 19:32:19 | mtreinish | I'm not saying the arch install guide. (I haven't even tried that) I'm saying we're shipping code with external requirements that aren't documented anywhere | |
| 19:32:29 | mtreinish | sure packaging solves this, but how do packagers know what's needed | |
| 19:33:02 | mtreinish | it doesn't seem unreasonable to say if installing from source make sure you have X, Y, Z installed since nova calls out to those | |
| 19:33:03 | sdague | by being part of our community | |
| 19:33:25 | efried | mtreinish Since you're clearly interested in furthering the cause of powervm in-tree, here ya go: https://review.openstack.org/#/c/443189/ | |
| 19:33:43 | sdague | I do get in a perfect world there would be a crisp "here is everything you need" interface, but in the list of priorities that's not really in the top 100 | |
| 19:33:59 | efried | (and mriedem, updating refs is on our to-do list, near the top) | |
| 19:34:22 | sdague | as the only people it's impacting is building from source without using any of the deployment projects | |
| 19:34:36 | mtreinish | sdague: I'm not saying it's a priority. I filed a bug to just recognize it's a gap | |
| 19:34:54 | mriedem | mtreinish: i didn't invalidate the bug, i just marked it low priority | |
| 19:34:58 | mriedem | if someone wants to take that on they can | |
| 19:35:12 | mriedem | with my reservations about it noted in there | |
| 19:35:18 | mriedem | i.e. complicated and getting out of date easily | |
| 19:35:48 | mtreinish | efried: I guess that I can take a look... | |
| 19:36:18 | efried | mtreinish It's a biggie. Perhaps you can figure out a way to parallel-process the review using that cloud in your closet... | |
| 19:36:50 | sdague | mtreinish: right, so my feeling is that bugs not in the top 100 priorities are just hay hiding needles in the stack. | |
| 19:37:48 | sdague | efried: https://review.openstack.org/#/c/443189/24/nova/virt/powervm/tasks/storage.py ... I'm confused about the LOG.exception that have "ignoring" in their message | |
| 19:38:01 | sdague | because, that's going to be a giant stack trace which will scare people | |
| 19:38:06 | sdague | but then being "meh" | |
| 19:38:10 | mtreinish | efried: I asked ibm to give me funding for that cloud and I was told no. They didn't even offer to give me any power boxes | |
| 19:38:12 | sdague | seems contradictory | |
| 19:38:12 | efried | sdague Taskflow esoterica | |
| 19:38:17 | mtreinish | not that my circuit breaker could handle them | |
| 19:39:00 | mriedem | leakypipes: did https://review.openstack.org/#/c/409706/ resolve that mitaka issue you were chasing the other night? | |
| 19:39:09 | sdague | efried: ok, intentional, then I'm fine with it | |
| 19:39:24 | efried | sdague This code only gets hit if the forward part of a Task Flow failed, and it's reverting. If one of the revert methods raises an exception, that's the exception that winds up getting raised overall, obscuring the original and bailing out of the remainder of the revert sequence. | |
| 19:39:44 | sdague | efried: sure | |
| 19:39:52 | sdague | I get catching the exception | |