21:00:21 <alaski> #startmeeting nova
21:00:23 <openstack> Meeting started Thu Dec  3 21:00:21 2015 UTC and is due to finish in 60 minutes.  The chair is alaski. Information about MeetBot at http://wiki.debian.org/MeetBot.
21:00:24 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
21:00:26 <openstack> The meeting name has been set to 'nova'
21:00:30 <sc68cal> o/
21:00:31 * Vek waves
21:00:33 <alaski> #chair sdague
21:00:34 <openstack> Current chairs: alaski sdague
21:00:35 <melwitt> o/
21:00:38 <alaski> for when he shows up
21:00:41 <edleafe> \o
21:00:54 <bauzas> \o
21:00:58 <auggy> o/
21:01:00 <alaski> https://wiki.openstack.org/wiki/Meetings/Nova
21:01:08 <alaski> #topic Release Status
21:01:24 <alaski> This is mostly just a list of things on the wiki, but I'll share here
21:01:30 <alaski> Virtual doc sprint December 8th and 9th
21:01:41 <alaski> unfortunately there are no further details included on that
21:01:58 <alaski> like who to coordinate with, but hopefully there will be a ML post on it
21:02:08 <jichen> some info here:https://etherpad.openstack.org/p/nova-v2.1-api-doc
21:02:13 <alaski> ahh, great
21:02:20 <alaski> #link https://etherpad.openstack.org/p/nova-v2.1-api-doc
21:02:47 <alaski> * Mitaka-1 is now tagged
21:02:52 <ctrath> o/
21:03:11 <rlrossit> o/
21:03:17 <lpabon> o/
21:03:20 <bauzas> \o/
21:03:24 <alaski> let's work towards M-2 now
21:03:33 <dansmith> time flies
21:03:41 <alaski> also according to John that's the 100th tag for Nova
21:04:03 <dansmith> orly
21:04:16 * tonyb checks that .....
21:04:31 <alaski> that's what the twitters tell me
21:04:41 <Vek> dangerous to say things like that in a channel full of geeks :)
21:04:54 <tonyb> balder:nova tony8129$ git tag -l | wc -l 100
21:05:00 <tonyb> 100
21:05:02 <alaski> \o/
21:05:05 <tonyb> so there you go
21:05:12 <melwitt> nice
21:05:42 <alaski> nice work everyone
21:05:46 <alaski> * python-novaclient 3.0 hopefully next week
21:06:06 <bauzas> I'd like to see the reno changes merged before
21:06:30 <alaski> http://lists.openstack.org/pipermail/openstack-dev/2015-December/081290.html
21:06:57 <dansmith> bauzas: reno for client you mean?
21:06:58 <alaski> some big changes in there to be aware of
21:07:13 <bauzas> dansmith: yeah but the CI one https://review.openstack.org/#/c/248898/
21:07:23 <bauzas> btw. change* (without 's')
21:07:47 <alaski> bauzas: you may want to ping mriedem on that to be sure
21:07:58 <bauzas> alaski: yeah we'll sync
21:08:08 <bauzas> reno is in-tre
21:08:10 <alaski> great
21:08:11 <bauzas> tree even
21:08:21 <bauzas> but we don't have the voting job yet
21:08:39 <alaski> okay
21:08:49 <alaski> it would be great to get that, but I'm not sure it should hold up the release
21:09:03 <bauzas> fair enough, let's sync with mriedem
21:09:05 <alaski> but that's with mriedem
21:09:24 <alaski> so today is spec and bp freeze
21:09:43 <alaski> according to the meeting wiki there will be news on the exception process on the ML tomorrow
21:09:54 <alaski> so look forward to that
21:10:27 <alaski> though as always we want exceptions to be just that, exceptions.  so hopefully not much will apply
21:10:41 <tonyb> does freeze mean no new submissions or no new approvals?
21:10:48 <alaski> no new approvals
21:10:54 <dansmith> right
21:10:59 <tonyb> that
21:11:05 <dansmith> I lowered my typo tolerance for the day and approved several
21:11:07 <tonyb> s what I thought but I'm easily confused
21:11:25 <Vek> heh
21:11:57 <alaski> dansmith: they can always be fixed with followups :)
21:12:05 <dansmith> but this twitch in my eye can't
21:12:31 <alaski> there are specless bps to review, but that can be done on the following etherpad https://etherpad.openstack.org/p/mitaka-nova-spec-review-tracking
21:13:26 <alaski> There's a call for backwards incompatible changes for novaclient 3.0 http://lists.openstack.org/pipermail/openstack-dev/2015-November/079915.html
21:13:39 <alaski> and python2.6 support is being dropped
21:14:05 <alaski> so speak up if there's something you want included there
21:14:15 <alaski> #topic Regular reminders
21:14:21 <alaski> New review focus list: https://etherpad.openstack.org/p/mitaka-nova-priorities-tracking
21:14:48 <alaski> priority reviews should be listed there
21:15:05 <alaski> #topic Bugs
21:15:35 <alaski> There's nothing on the agenda here so I'm going to assume we're pretty good here
21:15:41 <alaski> unless someone knows of something
21:16:06 <alaski> http://status.openstack.org/elastic-recheck/index.html
21:16:15 <bauzas> I heard about a CI issue for multinode, right?
21:16:17 <Vek> I think there's supposed to be a statement of the status of bugs, but beyond that...*shrug*
21:16:28 <alaski> there do seem to be some Nova bugs in the top there
21:17:03 <bauzas> yeah that one I was referring to is http://status.openstack.org/elastic-recheck/index.html#1521823
21:17:31 <alaski> okay, eyes on those bugs would be appreciated
21:18:13 <alaski> for stable branches there's a note that https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:stable/liberty+topic:fix_status_reporting,n,z should trigger a point release
21:18:27 <alaski> after some reno adds for it
21:18:46 <alaski> #topic Stuck reviews
21:19:08 <alaski> mriedem listed one but isn't around to speak to it
21:19:10 <alaski> https://review.openstack.org/#/c/235983/
21:19:26 <alaski> there are some concerns about testing on the spec
21:19:35 <alaski> for booting from uefi
21:19:37 * Vek remembers a novaclient review currently needing discussion about the direction to go...
21:19:38 <melwitt> there's a thread on the ML about it too
21:19:50 <alaski> http://lists.openstack.org/pipermail/openstack-dev/2015-December/081263.html
21:19:59 <alaski> melwitt: that one I think
21:20:13 <melwitt> yes
21:20:48 <melwitt> Vek: the requests lib exception exposure thing?
21:21:06 <Vek> https://review.openstack.org/#/c/240023/
21:21:12 <Vek> melwitt: exactly the one I was thinking of.
21:21:26 <Vek> I've been meaning to direct him to the email list, but have been forgetting to.
21:21:36 <alaski> without mriedem around to discuss it I'll ask that reviewers take a look at https://review.openstack.org/#/c/235983/ and chime in
21:22:27 <tonyb> alaski: the ML message is a good read
21:22:48 <Vek> anyone have any opinions on the lib exception exposure review?
21:23:50 <alaski> Vek: I'm against it, but that review seems more stuck between submitter and reviewer than between reviewers
21:23:51 <Vek> (if we're going to do that, 3.0.0 would be the perfect time to do it...)
21:24:22 <alaski> tonyb: okay.  I need to read that fully as I don't feel qualified to offer an opinion yet
21:24:24 <Vek> alaski: yeah, but I want to get more commentors to convince the submitter that we're all on the same page against him, I guess :)
21:24:39 <melwitt> Vek: while I get the point of it, I don't see it adding a lot of value
21:25:30 * Vek nods
21:25:55 <alaski> Vek: perhaps direct him to the ML as you stated, and point out the v3.0 thread
21:26:21 <alaski> and anyone else with opinions please contribute to those two threads/reviews
21:26:44 <alaski> #topic Open discussion
21:26:54 <melwitt> I feel like we're in a corner about it, because the requests exceptions have been exposed so long, some people are relying on that, and it's hard to change it now
21:27:23 <macsz> wanted to ask jaypiepes for status : http://specs.openstack.org/openstack/nova-specs/specs/mitaka/approved/resource-objects.html
21:27:27 <macsz> but since he is not around
21:27:58 <alaski> melwitt: yeah.  and there still hasn't been a great case made for a change
21:28:04 <macsz> anyone knows? this one is pretty old, wanted to contribute to this, but cant get idea what was really done in this matter
21:28:14 <Vek> melwitt: agreed, which is why I commented that a 3.0.0 release would be the time to do it.
21:28:36 <tonyb> macsz: IIUC it's now waiting on the PCI cleanups
21:28:44 <Vek> macsz: I saw a bunch of reviews posted by him today that are related to that spec.
21:28:47 <alaski> macsz: I believe he's working on splitting it up a bit
21:28:54 <Vek> (all WIP, mind...)
21:29:05 <macsz> oh, thanks for intel
21:29:14 <tonyb> macsz: http://specs.openstack.org/openstack/nova-specs/specs/mitaka/approved/pci-stats-generate.html
21:29:22 <tonyb> macsz: I could be wrong.
21:30:05 <alaski> macsz: oh, I was thinking of the other spec
21:30:37 <alaski> tonyb: I believe you're correct on that
21:30:53 <alaski> he was also toying around with how it'll work with cells
21:31:12 <bauzas> yeah the PCI stuff is a bit blocking us
21:31:15 <alaski> macsz: you may be able to catch him on irc at some point to get an update
21:31:23 <bauzas> because we have many problems with that
21:31:46 <alaski> and that spec was approved if I recall
21:31:47 <macsz> alaski: i am counting on taht, but no luck so far :)
21:31:47 <tonyb> bauzas: well the spec merged overnight so that's a good thing
21:31:54 <bauzas> but that's really difficult to jump in for that unless you have some experience IMHO
21:32:12 <alaski> macsz: he's travelling right now I think
21:32:17 <bauzas> because the PCI tracking thing is probably one of the best stories in Nova
21:33:07 * Vek hrms...may have thought of the wrong spec
21:33:09 <bauzas> tonyb: honestly, I missed that one and I'm glad to see it approved
21:33:38 <alaski> So there's a ML thread about adding cross project liasons: http://lists.openstack.org/pipermail/openstack-dev/2015-December/080869.html if anyone has interest in that please sign up and let johnthetubaguy know
21:34:42 <alaski> anything else for open discussion?
21:35:11 <alaski> I don't think I beat mriedems time but we can end early
21:35:21 * Vek celebrates
21:35:32 <dansmith> 35 minutes is not impressive, no
21:35:48 * Vek once had a class that was -5 minutes long... :)
21:36:02 <bauzas> so I had a point
21:36:06 <alaski> next time I'll just copy/paste from the wiki so no typing needed
21:36:10 <bauzas> but we can hold that one
21:36:55 <alaski> bauzas: well now's the time if you want to bring it up
21:37:16 <bauzas> so, the concern is have was raised in https://review.openstack.org/#/c/245891/12/nova/tests/unit/conf_fixture.py,cm
21:37:45 <bauzas> basically, we agreed to use a per-service module for the opts
21:37:58 <bauzas> so it means that the import_opt() are no longer needed
21:38:27 <bauzas> but it means that for a code readibility, we loose when the option is used
21:38:30 * Vek is not necessarily convinced that that is true...
21:38:56 <sdague> bauzas: you know later in the code when it's used
21:38:56 <tonyb> bauzas: Oh I though you'd still need to import the opts you were using to be specific
21:39:32 <bauzas> sdague: that's fair to say that
21:40:16 <sdague> this is all trade offs, and we chose this trade off to try to get a handle on the 800+ config options by making seeing them all in one place possible
21:40:28 <edleafe> tonyb: no, now you'll just import nova.conf
21:40:29 <sdague> versus them being hidden in so many places we don't know where the bodies are
21:40:45 <bauzas> sdague: yeah that I know and I agree
21:41:28 <bauzas> sdague: my concern was just whether we should leave some explicit calls for importing the options we want (not registering them)
21:41:44 <sdague> meh, I think it's pretty arbitrary
21:42:01 <edleafe> bauzas: in what sense is this "importing"? Sounds more like declaring
21:42:02 <tonyb> edleafe: okay I thought there was more magic to it :)
21:42:09 <melwitt> don't you just get all the opts all the time now?
21:42:14 <bauzas> okay, I don't want to overthink on it
21:42:20 <alaski> bauzas: maybe make a case for the explicitness on the code review
21:42:22 <sdague> because if someone wants to add another option to that fixture are we going to make them add these noop lines?
21:42:33 <bauzas> melwitt: yeah by getting the global CONF object, you'll access all the opts now
21:42:47 <sdague> if you want explicitness put a class level comment block of "this uses the following conf options"
21:43:00 <bauzas> okay, fair enough
21:43:07 <edleafe> the previous imports were necessary because the global CONF may not have imported them
21:43:10 <sdague> noop import statements are just black magic that people will copy and paste and not know why
21:43:23 <melwitt> another way is to set self.flags(...) in tests where it's important. I do that even when they're already in scope if I think being explicit matters
21:43:26 <edleafe> now they are all imported up front
21:43:49 <sdague> melwitt: yeh, our conf usage in tests is layers of gorp :)
21:43:55 <alaski> sounds like everyone's on the same page now
21:44:00 <bauzas> yup
21:44:25 <alaski> then if nothing else we can all congregate in #openstack-nova
21:44:29 <alaski> thanks all
21:44:36 <alaski> #endmeeting