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