14:01:25 <johnthetubaguy> #startmeeting nova
14:01:27 <openstack> Meeting started Thu Aug 21 14:01:25 2014 UTC and is due to finish in 60 minutes.  The chair is johnthetubaguy. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:01:28 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:01:30 <openstack> The meeting name has been set to 'nova'
14:01:31 <johnthetubaguy> hello all
14:01:33 <mriedem> hi!
14:01:34 <dansmith> o/
14:01:37 <pkoniszewski> o/
14:01:39 <leifz> o/ after two weeks out.
14:02:05 <bauzas> \o
14:02:06 <johnthetubaguy> #topic Juno Status
14:02:09 <danpb> \o/
14:02:22 <johnthetubaguy> so the big thing, end of today is Feature Proposal Freeze
14:02:36 <johnthetubaguy> i.e. all patches for code features must be up for review
14:02:44 <johnthetubaguy> else you will need an exception
14:02:47 <adrian_otto> o/
14:03:14 <johnthetubaguy> dansmith: I think we said three core reviews to get an exception this time?
14:03:31 <dansmith> johnthetubaguy: that was the suggestion, based on previous cycles, yeah :)
14:03:48 <johnthetubaguy> dansmith: yeah, I like that
14:03:52 <johnthetubaguy> anyone against that idea?
14:04:03 <bauzas> s/reviews/reviewers ?
14:04:22 <dansmith> bauzas: yeah
14:04:27 <dansmith> bauzas: sponsors, if you will
14:04:36 <bauzas> dansmith: gotcha, tks
14:04:53 <johnthetubaguy> #info expect you will need three core developer to sponsor a blueprint if you want a feature proposal freeze exception, same for feature freeze exceptions
14:05:06 <johnthetubaguy> OK...
14:05:09 <johnthetubaguy> #link https://launchpad.net/nova/+milestone/juno-3
14:05:21 <johnthetubaguy> so anyone got any updates on high and medium blueprints they want to discuss
14:05:33 <johnthetubaguy> I have tidied up the list so they are all Needs Code Review
14:06:00 <johnthetubaguy> I am likely to kick out the low blueprints with no code tomorrow morning UK time, unless mikal beats me to it
14:06:17 <johnthetubaguy> dansmith: you send a good ML update a few days back, any major changes there?
14:06:45 <johnthetubaguy> #info please focus on reviewing the high priority and then medium priority blueprints: https://launchpad.net/nova/+milestone/juno-3
14:07:07 <dansmith> johnthetubaguy: on the review priorities? I think most of what I had was about the ironic stuff,
14:07:20 <dansmith> johnthetubaguy: which is making progress, but I haven't seen anything in the last couple days.. should check this morning
14:07:21 <mriedem> johnthetubaguy: the code for this is merged from what i can tell https://blueprints.launchpad.net/nova/+spec/add-differencing-vhdx-resize-support
14:07:42 <alaski> o/
14:07:44 <johnthetubaguy> mriedem: thanks I need to double check stuff like that after the big kick out
14:08:22 <danpb> johnthetubaguy: as mentioned on the mailing list, i think we need to make it a high priority to also review patches which already have one +2
14:08:29 <johnthetubaguy> mriedem: if you could link the patch series you know about that would be handy
14:08:40 <mriedem> johnthetubaguy: yeah it's in there, it's only 1 patch
14:08:46 <danpb> johnthetubaguy: we've got > 100 patches outstanding which have one +2 and no negative feedback some of which are a month old
14:08:46 <johnthetubaguy> danpb: thats a fair point
14:08:55 <johnthetubaguy> mriedem: oh, I assumed that was the spec
14:09:03 <danpb> which is just totally ridiculous and creating work for ourselves with inevitable rebases
14:09:05 <russellb> mriedem: updated
14:09:08 <mriedem> johnthetubaguy: no i think that missed icehouse so it was ready to go
14:09:09 <mriedem> russellb: thanks
14:09:23 <mriedem> danpb: some of those are in the tail end of a series, like vmware refactors
14:09:36 <mriedem> danpb: it's a good point, it's just not all onesy twosy fixes
14:09:38 <johnthetubaguy> russellb: thanks
14:09:40 <danpb> mriedem: that's a tiny minority of the ones i've looked at so far
14:10:21 <mriedem> moving on...
14:10:23 <johnthetubaguy> danpb: agreed, looking at stuff that already has a +2 makes sense at this point
14:10:24 <johnthetubaguy> yeah
14:10:30 <johnthetubaguy> we know what we need to do
14:10:43 <johnthetubaguy> #info Feature Proposal Freeze August 21st, September 4th Juno-3, FF and SF
14:10:59 <johnthetubaguy> so all patches need to be in by Sept 4th as a reminder
14:11:04 <johnthetubaguy> ideally well before that
14:11:10 <johnthetubaguy> #topic Bugs
14:11:20 <johnthetubaguy> OK, so there is a new feature on this web page:
14:11:30 <johnthetubaguy> #link http://54.201.139.117/nova-bugs.html
14:11:45 <johnthetubaguy> #info see what is in progress and needs reviewing
14:12:25 <johnthetubaguy> OK, nothing more there I guess
14:12:39 <johnthetubaguy> #topic Gate status
14:12:55 <mriedem> gate is fine, had a jsonschema issue yesterday but quickly resolved by dansmith
14:13:01 <johnthetubaguy> cools
14:13:01 <dansmith> \o/
14:13:05 <mriedem> sounds like other projects have the same issue, i.e. sahara
14:13:15 <johnthetubaguy> top work
14:13:18 <mriedem> they have a reqs patch to cap jsonschema, but they should probably just update their unit tests
14:13:26 <johnthetubaguy> #topic Mid-cycle summary
14:13:43 <johnthetubaguy> mikal is working on a summary of what happened now
14:13:53 <johnthetubaguy> etherpad is still there for the other bits
14:13:54 <mriedem> he has a lot of nice blog posts already
14:14:04 <mriedem> http://www.stillhq.com/openstack/juno/000014.html
14:14:06 <johnthetubaguy> #link https://etherpad.openstack.org/p/juno-nova-mid-cycle-meetup
14:14:32 <mriedem> actually http://www.stillhq.com/openstack/juno/
14:14:33 <johnthetubaguy> yeah, there are a few on the minuets
14:14:50 <johnthetubaguy> mriedem: cool, thats the link
14:14:53 <johnthetubaguy> #link http://www.stillhq.com/openstack/juno/
14:15:06 <johnthetubaguy> feedback via the ML I guess
14:15:21 <johnthetubaguy> #topic Open Discussion
14:15:33 <adrian_otto> o/ Containers Team Update
14:15:33 <johnthetubaguy> OK, so the first think is OS profiler
14:15:42 <johnthetubaguy> thats on the agenda
14:15:46 <johnthetubaguy> boris-42: are you around?
14:16:01 <boris-42> johnthetubaguy hi there
14:16:02 <johnthetubaguy> #link https://review.openstack.org/#/c/105096/
14:16:12 <boris-42> johnthetubaguy what is this meeting about?
14:16:13 <johnthetubaguy> #link https://review.openstack.org/#/c/105089/
14:16:20 <johnthetubaguy> boris-42: this is the nova meeting
14:16:25 <boris-42> johnthetubaguy ahh =)
14:16:30 <boris-42> johnthetubaguy okay ya
14:16:32 <johnthetubaguy> boris-42: I think mikal wanted you to talk about the os profiler stuff
14:16:40 <boris-42> johnthetubaguy yep I asked him
14:16:52 <boris-42> johnthetubaguy I thought it's a bit later
14:17:08 <johnthetubaguy> OK, jogo is −2 on this, and he will not be awake till later on
14:17:09 <boris-42> johnthetubaguy so osprofiler stuff is very useful for developers & operators and dev & production enviorments
14:17:19 <boris-42> johnthetubaguy -2 is cause of politics
14:17:24 <boris-42> johnthetubaguy not because of code
14:17:30 <boris-42> johnthetubaguy so you can ignore that -2
14:17:58 <boris-42> johnthetubaguy this is comment of Joe
14:17:59 <boris-42> blocked until oslo spec is merged: https://review.openstack.org/#/c/103825/
14:18:10 <boris-42> johnthetubaguy let's talk about osprofiler stuff
14:18:20 <danpb> is there any nova blueprint for this feature ?
14:18:36 <mriedem> nope, the blueprint is in oslo
14:18:39 <johnthetubaguy> danpb: thats my object honestly, there isn't one
14:18:45 <boris-42> danpb nope, I really don't want to add
14:18:48 <mriedem> it's one of these cross project things that some projects have adopted already but not nova
14:18:50 <boris-42> danpb blueprints for every project
14:18:57 <boris-42> mriedem +1
14:19:06 <danpb> ok, where is the olso blueprint ?
14:19:09 <boris-42> one sec
14:19:11 <boris-42> danpb
14:19:19 <boris-42> danpb https://review.openstack.org/#/c/103825/
14:19:21 <boris-42> danpb this is
14:19:25 <boris-42> danpb spec
14:19:28 <boris-42> danpb for dicussion
14:20:10 <boris-42> danpb johnthetubaguy actually more interesting is the way how to use it
14:20:12 <boris-42> and results
14:20:24 <boris-42> danpb johnthetubaguy http://boris-42.github.io/ngk.html
14:20:37 <boris-42> so this shows trace of booting VM via CLI
14:20:42 <johnthetubaguy> boris-42: OK, I think I will have to stop you, this is taking too long for this meeting with such a wide audience
14:20:49 <johnthetubaguy> boris-42: what did you want decided today?
14:21:03 <boris-42> johnthetubaguy just to get more reviews on patch
14:21:04 <johnthetubaguy> boris-42: yes or no for the current approach?
14:21:11 <johnthetubaguy> OK
14:21:19 <boris-42> johnthetubaguy actually I hope that nobody will be against
14:21:28 <johnthetubaguy> so are people happy with a feature coming into nova via an oslo blueprint
14:21:39 <boris-42> johnthetubaguy mikal as I know is=)
14:21:47 <johnthetubaguy> in a cross project consistency way
14:21:47 <boris-42> johnthetubaguy I can't say about all people in openstack
14:21:48 <ndipanov> johnthetubaguy, would that be the first?
14:21:51 <dansmith> johnthetubaguy: I'd need to review the impact first
14:21:52 <ndipanov> not really I think
14:22:00 <boris-42> danpb what kind of impact?
14:22:03 <dansmith> ndipanov: the first of this magnitude I think
14:22:03 <boris-42> dansmith*
14:22:06 <danpb> unless i'm missing something,the olso spec isn't even approved yet
14:22:17 <ndipanov> it's not
14:22:27 <danpb> so isn't it premature to talkl about merging code
14:22:28 <boris-42> danpb it's not approved, cause I am waiting more poeple
14:22:29 <bauzas> I'll also put some comments on how it's proposed
14:22:30 <ndipanov> but a lot of the comments are some political bikesheding about where it belongs
14:22:43 <boris-42> danpb I would like to discuss with as much as possible people
14:22:44 <danpb> to be clear, i think the feature is very useful and desirable
14:22:45 <dansmith> boris-42: meaning what the impact to nova code is, to decide if I think it needs a spec or not
14:22:53 <ndipanov> it's been on my list for some time now but never got to it
14:22:59 <boris-42> dansmith there is no big impact
14:23:03 <boris-42> dansmith on code
14:23:04 <danpb> but it seems pretty late in the day for us to talk about this for nova now isn't it ?
14:23:10 <bauzas> the implementation requires an external dependency which is not part of the reqs.txt IIUC
14:23:13 <johnthetubaguy> danpb: thats me feeling here
14:23:21 <boris-42> bauzas ?
14:23:27 <boris-42> bauzas it's in global requriemtns
14:23:38 <dansmith> johnthetubaguy: certainly too late for juno, right?
14:23:41 <johnthetubaguy> I think we just need to discuss this one on the ML after people have reviewed the patch
14:23:44 <danpb> separately we should definitely clarify how we want to handle things like this from the specs process POV
14:23:44 <johnthetubaguy> dansmith: thats my thinking
14:23:54 <danpb> because we don't want to make people create one spec for every project
14:24:01 <leifz> this spec also includes API changes correct?
14:24:03 <boris-42> danpb ya that sux
14:24:06 <johnthetubaguy> I see it as having missed the blueprint freeze
14:24:07 <danpb> but we need  a way to draw nova teams atttention to the oslo spec
14:24:20 <johnthetubaguy> danpb: agreed, we should have a way to do that
14:24:21 <boris-42> johnthetubaguy this feature was discussed since Atlanta summit
14:24:28 <boris-42> johnthetubaguy and there were cross session
14:24:33 <mriedem> fwiw for db2 we've created specs for each project
14:24:33 <boris-42> johnthetubaguy and I addressed all issues
14:24:36 <boris-42> johnthetubaguy and even more
14:24:37 <boris-42> =)
14:24:39 <mriedem> which is cross project
14:24:42 <boris-42> johnthetubaguy so it's not from yestarday
14:24:49 <dansmith> specs for each project make sense if the impact is not the same to each project, IMHO
14:24:52 <ndipanov> mriedem, were you happy with that
14:24:53 <ndipanov> ?
14:24:54 <boris-42> mriedem imho I don't want to taht=)
14:24:59 <johnthetubaguy> boris-42: yes, but there were two sessions at once, and I didn't know it impacted nova, etc
14:25:03 <mriedem> ndipanov: each project has different db migration issues with db2 so yeah it made sense
14:25:05 <leifz> dansmith: +1
14:25:12 <ndipanov> ok then
14:25:13 <danpb> mriedem: potentially we could simply create a dummy placeholder nova spec that says no more than "read the oslo spec" as a way to draw attention to it
14:25:16 <mriedem> boris-42: i'm not saying we wanted to, but it is what it is
14:25:25 <mriedem> danpb: sure
14:25:36 <johnthetubaguy> danpb: that would be reasonable I feel, just to get nova drivers to sign off on it, I like that
14:25:37 <boris-42> mriedem ya but in this case approach is absolutely the same
14:25:51 <boris-42> mriedem you need patch in client, you need patch in main project, and they are almost similiar
14:26:04 <boris-42> mriedem probably some tests are affected but overall it's the same change
14:26:10 <dansmith> if it touches our API, then it seems like it has to have a spec, right?
14:26:24 <dansmith> even if it's just the API bits, and then "look at the oslo spec for the rest of the details"
14:26:36 <boris-42> dansmith okay guys if you need spec
14:26:37 <johnthetubaguy> dansmith: +1 it changes the paste file
14:26:38 <leifz> boris-42: the concern I have is getting ops folks to take a look who only look at nova specs and not oslo specs.
14:26:41 <boris-42> dansmith ant these are rules
14:26:43 <boris-42> dansmith I can make it
14:26:50 <boris-42> dansmith but I hope I won't need to wait Kilo?
14:26:54 <boris-42> dansmith to get it?
14:27:02 <johnthetubaguy> boris-42: if it needs a spec, its not in juno, I think thats the thing
14:27:03 <dansmith> boris-42: you do in my opinion
14:27:13 <johnthetubaguy> dansmith: +1
14:27:13 <boris-42> dansmith okay I will do spec
14:27:14 <dansmith> johnthetubaguy: anyway, I think we need to move on, right?
14:27:20 <johnthetubaguy> dansmith: yes
14:27:25 <boris-42> dansmith or I should wait Kilo?
14:27:30 <boris-42> dansmith didn't get
14:27:31 <dansmith> boris-42: kilo
14:27:32 <danpb> i think that given this is the first time most of core seems to have heard about this feature  Kilo looks like best option
14:27:36 <boris-42> dansmith nope that is bad thing
14:27:42 <johnthetubaguy> #info seems like we need to wait for kilo of os profiles, move discussion to ML
14:27:50 <ndipanov> being pragmatic about this - easy perf profiling is a massive win for all, and I would not like to see it blocked on process
14:27:52 <boris-42> (*facepalm*)
14:27:54 <dansmith> danpb: this has had a huge amount of press, I dunno that it's new to everyone,
14:28:02 <boris-42> sorry guys
14:28:02 <dansmith> danpb: it's just unreviewed right now because of the timing I think
14:28:18 <boris-42> dansmith danpb guys this things can help you in development
14:28:22 <boris-42> to safe billions of hours
14:28:30 <ndipanov> if not even millions :)
14:28:32 <bauzas> I just discovered osprofiler in global reqs
14:28:32 <boris-42> on fixing different races, and bugs
14:28:34 <johnthetubaguy> two or three weeks back, with an approve oslo spec, then we would probably wave it through
14:28:41 <boris-42> performance issues and so on
14:28:45 <boris-42> bauzas yep it is
14:28:49 <bauzas> can't really see why it needs to be there
14:28:49 <boris-42> bauzas and it is already in galnce
14:28:51 <danpb> boris-42: no one is debating that this is a useful feature
14:28:53 <boris-42> bauzas and today will be in cinder
14:28:58 <johnthetubaguy> right now, we have so much to get juno out the door, we can't really afford the discussion, which sucks
14:29:05 <boris-42> danpb yep but I really don't see any reason to block it until Kilo
14:29:08 <dansmith> johnthetubaguy: right, that
14:29:11 <boris-42> danpb can we get FFF for it?
14:29:22 <boris-42> danpb dansmith I can disable it by default
14:29:27 <boris-42> danpb dansmith if it makes sense
14:29:30 <dansmith> boris-42: don't make me come up with a meaning for FFF :P
14:29:32 <johnthetubaguy> boris-42: please request on the ML, ideally with a nova-spec pointing to the merged solo spec
14:29:40 <bauzas> having a dependency disabled by default sounds weird to me...
14:29:50 <johnthetubaguy> anyways, really must move on...
14:29:52 <danpb> requesting FFF is reasonable way to continue the discussion
14:29:53 <bauzas> we already have numpy as a painful dep...
14:30:06 <johnthetubaguy> Opening specs for Kilo...?
14:30:14 <boris-42> bauzas please don't compare osprofiler with numpy
14:30:19 <johnthetubaguy> but no approvals till we get the process sorted?
14:30:22 <boris-42> bauzas osprofiler is 200 lines stuff
14:30:24 <ndipanov> I do think that it being late for J is realistic - just hate for it to be on a process snag
14:30:27 <boris-42> bauzas without any deependency
14:30:45 <danpb> yes please, on the grounds that I think we should require any nova design summit session proposal to have some prior discussions or proposal (whether a spec or a wiki page)
14:30:56 <johnthetubaguy> danpb: +1
14:31:02 <boris-42> danpb dansmith bauzas guys okay I'll make some email
14:31:12 <johnthetubaguy> I think we just let people submit for kilo
14:31:21 <johnthetubaguy> any objections at this point?
14:31:28 <mriedem> johnthetubaguy: does it get sorted out later then with the slots thing?
14:31:31 <johnthetubaguy> just to be clear, they might not get reviewed till later
14:31:33 <danpb> yep, no approvals until we're better on top of Juno work
14:31:47 <mriedem> was reading through jogo's k blueprint process patches a bit yesterday,
14:31:55 <johnthetubaguy> mriedem: yeah, no approvals still we decide whats happening for approvals (re slots, etc)
14:32:01 <mriedem> sounds like there is debate about when a spec is required,
14:32:11 <danpb> and review of specs would be low priority for core team given juno code backlog
14:32:13 <mriedem> but i guess if people want to write them, that's no skin off reviewers backs if they aren't reviewing them
14:32:16 <mriedem> right
14:32:17 <johnthetubaguy> mriedem: yeah, we were going to slacken it off a bit
14:32:55 <johnthetubaguy> right, I have no plans to review specs till after feature freeze at this point, but we could let people submit
14:33:06 <johnthetubaguy> also with the warning the template may get updated a little
14:33:24 <johnthetubaguy> sounds like we are agreed there… do speak up if not
14:33:38 <belliott> i'm still for getting rid of specs, i know i'm a minority
14:33:45 <johnthetubaguy> … next is… Power KVM CI?
14:34:17 <mriedem> johnthetubaguy: i think that's old
14:34:22 <mriedem> from last week
14:34:32 <johnthetubaguy> yeah, I think mikal wanted an update or something
14:34:38 <mriedem> krtaylor isn't here
14:34:38 <johnthetubaguy> but I could be wrong
14:34:40 <mriedem> i'll bug him in -nova
14:34:49 <johnthetubaguy> never mind, its probably the wrong time of day
14:34:55 <dansmith> I haven't been seeing it report,
14:34:59 <dansmith> so I assume no new news
14:35:01 <mriedem> it's disabled since last monday
14:35:01 <danpb> PowerKVM CI seems to be either awol or failing or both
14:35:09 <dansmith> it's disabled now
14:35:11 <dansmith> because it's broken
14:35:16 <johnthetubaguy> minesweeper is apparently waking back up now?
14:35:19 <dansmith> no reason or details, AFAIK
14:35:33 <johnthetubaguy> (needed more hardware I was told)
14:35:41 <dansmith> johnthetubaguy: MS seems to be very up and down lately, and tjones has been MIA for most of it
14:35:58 <mriedem> well MS was busted due to removing the esxi driver i guess
14:36:01 <johnthetubaguy> dansmith: its certainly been very patchy
14:36:05 <mriedem> that is sorted out now after several mini-reverts
14:36:19 <johnthetubaguy> XenServer CI had some blips, but I think BobBall got those sorted now
14:36:25 <dansmith> mriedem: it's still not running normally
14:36:29 <danpb> FYI this has some nice reports on CI status  http://ci-stats.cloudbase.it/
14:36:33 <dansmith> mriedem: I've had a -2 on a spawn refactor patch for a while
14:36:38 <mriedem> dansmith: yeah saw that
14:36:56 <danpb> it is a bit better than what mikal's site reports as it shows the trends of CI over time
14:37:07 <johnthetubaguy> nice
14:37:27 * mriedem bookmarks
14:37:36 <johnthetubaguy> anyways
14:37:42 <johnthetubaguy> any other stuff?
14:37:48 <johnthetubaguy> adrian_otto: did you have container stuff?
14:38:14 <johnthetubaguy> adrian_otto: we don't really do sub-team updates, just keeping it to critical release status stuff or breaking updates now
14:38:21 <adrian_otto> yes, I have two questions for the Noca team
14:38:26 <adrian_otto> *Nova
14:38:32 <johnthetubaguy> cool
14:38:33 <adrian_otto> #link https://review.openstack.org/114044 Containers Service Spec
14:38:39 <adrian_otto> 1) Is a full API spec desired for a high level spec for a new service?
14:38:47 <mriedem> johnthetubaguy: i guess i'll have something if you can come back to me
14:38:53 <adrian_otto> It might be better to agree on the concept and propose the API in a series of commits to the stackforge/containers repo in docstrings so we can more easily iterate on specific implementation of the API.
14:39:31 <adrian_otto> because in this week's team meeting we declared an intent to have an OpenStack specific API, and not just adopt Docker's API.
14:39:33 <johnthetubaguy> adrian_otto: ah, gotcha, maybe a follow up change on the spec?
14:39:54 <adrian_otto> planning that, but I am looking for conceptual guidance
14:40:12 <dansmith> the whole api spec is probably too large for being in the containers service spec,right?
14:40:22 <adrian_otto> exactly
14:40:26 <danpb> adrian_otto: i think we view the specs as only needing  high level design - focus on concepts, architecture & psuedo code at most
14:40:29 <johnthetubaguy> yeah, thats fair
14:40:35 <adrian_otto> that would make the spec impossible to review
14:40:38 <danpb> certainly don't want detailed code technical design in the spec
14:40:40 <dansmith> since this is large and new, perhps just iterate on the spec without the api details, and then have your own spec document in your tree as well
14:41:03 <dansmith> danpb: I think he's asking because we require api snippets in api-affecting specs for nova
14:41:07 <johnthetubaguy> danpb: honestly we need to set that expectation better, for APIs we make very detailed requirements at the moment, but yeah
14:41:21 <adrian_otto> ok, thanks. Any opposing viewpoints for us to consider on this point?
14:41:33 <adrian_otto> if not, I'll advance to the second question
14:41:42 <adrian_otto> #link https://review.openstack.org/115328 Stackforge Repo Spec
14:41:47 <johnthetubaguy> seems good, do what works best I guess
14:41:50 <adrian_otto> #link https://review.openstack.org/#/c/115328/2/modules/openstack_project/files/gerrit/acls/stackforge/containers.config Comments on PTL for Containers Service
14:41:57 <adrian_otto> 2) Should there be a separate PTL for a new compute program project, or should it be the Nova PTL?
14:42:13 <adrian_otto> we don't yet have a group called compute-ptl
14:42:13 <dansmith> I think while it's in stackforge, you're totally separate, right?
14:42:18 <dansmith> I think that's what we agreed on
14:42:25 <johnthetubaguy> I think we said inside the "compute" program eventually
14:42:26 <dansmith> so that you can iterate quickly
14:42:29 <johnthetubaguy> yeah
14:42:30 <adrian_otto> well, our intent is for this to be a compute program project
14:42:46 <adrian_otto> and I want to properly signal that
14:42:47 <dansmith> right, so I don't think it matters for the stackforge bootstrapping
14:43:06 <adrian_otto> so one thing I could do is make a containers-ptl group, and put a note in the commit message explaining that choice
14:43:07 <johnthetubaguy> yeah, maybe just say its the nova one, but have your own core list, for now?
14:43:28 <danpb> the intent is for this to become part of Nova eventually right
14:43:35 <adrian_otto> johnthetubaguy: ok, that would work
14:43:35 <dansmith> danpb: part of compute
14:43:57 <adrian_otto> danpb: not part of nova, but part of the compute program that Nova belongs to
14:44:03 <danpb> dansmith: what's the distinction there ?  forever having a  separate core team & ptl ?
14:44:09 <johnthetubaguy> dansmith: +1 in compute program, not in nova tree
14:44:17 <adrian_otto> so it will belong to the PTL, who currently only controls Nova
14:44:18 <dansmith> danpb: no, not necessarily core
14:44:29 <adrian_otto> but will have it's own core group
14:44:41 <johnthetubaguy> adrian_otto: sounds fine for stackforge
14:44:50 <dansmith> danpb: the distinction is two separate projects that share the same PTL and general mission statement (or whatever it's called), but could have different core teams
14:44:52 <adrian_otto> the PTL question really only matters for tagging releases
14:45:04 <danpb> ok
14:45:08 <adrian_otto> so I honestly don't care who carries that responsibility
14:45:23 <dansmith> adrian_otto: I don't think we do either, until you're formally part of the program :)
14:45:26 <adrian_otto> it will not impeede iterative progress
14:45:27 <dansmith> (IMHO)
14:45:32 <johnthetubaguy> dansmith: +1
14:45:42 <bauzas> well, you'll have to follow the Nova release cycle, even as a Stackforge project tho
14:45:42 <adrian_otto> dansmith: good, thanks
14:45:48 <johnthetubaguy> adrian_otto: you can always change it I guess
14:45:48 <dansmith> adrian_otto: if one option is less paperwork than the other, then I'd choose that :)
14:45:54 <adrian_otto> bauzas: yes!
14:46:04 <adrian_otto> :-)
14:46:08 <bauzas> adrian_otto: which is, from my understanding, the first time I'm seeing that
14:46:31 <johnthetubaguy> adrian_otto: cool, sounds like we answered everything now?
14:46:31 <adrian_otto> ok, thanks, those are the two open questions we had. We are iterating on design, and starting on API design work now.
14:46:36 <bauzas> adrian_otto: because stackforge projects are not possibly following openstack release cycle
14:46:37 <johnthetubaguy> cool
14:46:43 <johnthetubaguy> mriedem: did you have something?
14:46:54 <mriedem> johnthetubaguy: yeah on the enforce unique instance uuids patch,
14:46:58 <johnthetubaguy> ah
14:46:59 <mriedem> https://review.openstack.org/#/c/97946/
14:47:08 <mriedem> t-h actually has some data sets with null instance uuids
14:47:18 <bauzas> adrian_otto: ping me when you're free about containers vs. gantt, interested by this
14:47:20 <mriedem> so if you're on a gerrit dashboard and see that review, it has a -1
14:47:22 <mriedem> b/c of t-h
14:47:24 <dansmith> mriedem: yeah, mikal pointed that out right?
14:47:29 <adrian_otto> bauzas: yes sir.
14:47:30 <mriedem> dansmith: yeah
14:47:38 <dansmith> mriedem: I think he said he was going to figure out where those came from if possible
14:47:44 <mriedem> jhesketh also commented in the change
14:47:59 <mriedem> jhesketh basically said he's going to leave it there until the change is merged
14:48:07 <mriedem> anyway,
14:48:23 <mriedem> my question is if that's fine - it's going to detract from reviews, but it's low priority anyway,
14:48:30 <mriedem> i figured i'd just update the commit message pointing it out
14:48:35 <mriedem> so i don't have to answer the question 10 times
14:48:38 <dansmith> yeah, seems fine
14:48:45 <johnthetubaguy> cool
14:48:52 <mriedem> plus, if that does ever merge, t-h is going to be f'ed until they purge those rows :)
14:49:13 <mriedem> alright, that's it
14:49:19 <johnthetubaguy> cool
14:49:30 <johnthetubaguy> sounds like that everything, and we are done, any more?
14:49:37 * danpb has an item
14:49:46 <johnthetubaguy> danpb: fire away
14:50:01 <danpb> what is our guideline for reviewing nova client code changes wrt v3 api
14:50:16 <dansmith> -2 I think
14:50:16 <danpb> are we still caring about maintaining the v3 client classes
14:50:19 <marios> 
14:50:22 <johnthetubaguy> hmm, interesting, −2 I guess
14:50:34 <danpb> because it is really tedious reviewing identical code changes to both the v1_1 and v3/ directories
14:50:55 <dansmith> so no new code for those things, I think,
14:50:55 <danpb> so should we discourage people from changing v3/ directory at this point or not ?
14:51:00 <johnthetubaguy> yeah, I thought we decided v3 was never going to get exposed as v3, so that should never get merged
14:51:12 <dansmith> but removing them is kinda breaking the library-ness of the client
14:51:26 <johnthetubaguy> dansmith: oh, what did we add?
14:51:29 <dansmith> but they won't work past a point, so we should probably make the v3 module in the client raise some exception if you try to use them
14:51:44 <dansmith> johnthetubaguy: what do you mean?
14:51:49 <johnthetubaguy> dansmith: yeah, and bump the major version I guess
14:52:07 <johnthetubaguy> dansmith: sorry, its me being slow, didn't think we had any v3 in the client right now
14:52:28 <dansmith> johnthetubaguy: we do, don't we? wasn't that a requirement for getting as close as we were to having v3?
14:52:52 <dansmith> johnthetubaguy: https://github.com/openstack/python-novaclient/tree/master/novaclient/v3
14:52:52 <vishy> minor request: the last three paches for the multiple networks spec are waiting on a single core review on this patch: https://review.openstack.org/#/c/95262/
14:52:54 <danpb> johnthetubaguy: well python-novaclient has  novaclient/v3/*.py
14:53:01 <johnthetubaguy> dansmith: yeah, its coming back to me, was just looking there
14:53:08 <dansmith> yeah, it's really unfortunate,
14:53:18 <dansmith> but I think we need to basically replace all those with stubs that fail long-term
14:53:23 <dansmith> technically nobody should be using them, but...
14:53:25 <danpb> and the v3 code is pretty badly out of sync with the v1 dir
14:53:29 <dansmith> danpb: yeah
14:53:30 <johnthetubaguy> dansmith: +1
14:53:52 <johnthetubaguy> seems like we should do that ASAP before more people start using that stuff
14:54:15 <dansmith> danpb: the v3 patches going into nova that are moving it back to v2.1 are okay to approve of course, but any actual v3 patches should be -2d in nova and novaclient, IMHO
14:54:43 <danpb> so taking something like this https://review.openstack.org/#/c/115246/    we should -2 that change ?
14:54:48 <dansmith> johnthetubaguy: maybe, I'm not sure what our messaging has been on that, and technically the client code can be used against, say icehouse
14:54:55 <johnthetubaguy> dansmith: we have a load of jsonscheme stuff up for review, which is basically the crux of v2.1 I supose
14:55:16 <dansmith> johnthetubaguy: well, it's not just jsonschema stuff of course
14:55:17 <danpb> or this one which i approved earlier  https://review.openstack.org/#/c/112130/   we should have made them kill the file changes to v3 ?
14:55:21 <dansmith> danpb: yes, -2 I think
14:55:30 <dansmith> danpb: yes
14:55:47 <johnthetubaguy> dansmith: agreed
14:56:08 <danpb> we should probably have something in the wiki we note this, or a post to the mailing list to alert contributors that changes to v3 are not wanted anymore
14:56:37 <dansmith> danpb: maybe we wait for the v3 summary from the midcycle,
14:56:39 <danpb> something we can just post a link to in reviews so we don't have to explain it over & over again
14:56:45 <johnthetubaguy> danpb: yeah, we haven't been very clear on that, we need a nova-drivers meeting soon, to thrash out these kinds of things
14:56:48 <dansmith> and then send out something on that with the policy impacts?
14:57:00 <danpb> dansmith: sounds good
14:57:04 <johnthetubaguy> dansmith: oh, thats a good idea, like follow up with policy impacts code reviews
14:57:13 <dansmith> I think that would be the  most efficient
14:57:17 <johnthetubaguy> awesome, so we are basically out of time
14:57:20 <johnthetubaguy> dansmith: +1
14:57:36 <johnthetubaguy> but I found most of that useful, feeback always welcome as we try make these meeting more useful
14:57:49 <johnthetubaguy> any more that people want to discuss?
14:57:55 <PhilD> Sometimes you have to change the existign V3 files and tests though.   For exampelethe change I have to add two new quotas, they get picked up in the V3 API anyway (and we don't have extensiosn to hide them) - so I assume in that case the V� changes are stil OK?
14:58:30 <dansmith> PhilD: I guess only if it's required to pass tests
14:58:41 <dansmith> but we're not running tempest on v3 anymore, for example
14:58:45 <dansmith> so it would just be unit tests I think
14:58:55 <PhilD> Yeah - its unit test stuff
14:59:21 <johnthetubaguy> hmm, I guess its going drift more out of sync now, but thats life
14:59:25 <johnthetubaguy> anyways, time is up
14:59:26 <johnthetubaguy> thanks all
14:59:30 <johnthetubaguy> #endmeeting