14:00:08 #startmeeting glance 14:00:09 Meeting started Thu Aug 27 14:00:08 2015 UTC and is due to finish in 60 minutes. The chair is nikhil_k. Information about MeetBot at http://wiki.debian.org/MeetBot. 14:00:11 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 14:00:13 The meeting name has been set to 'glance' 14:00:14 #topic agenda 14:00:20 #link https://etherpad.openstack.org/p/glance-team-meeting-agenda 14:00:24 o/ 14:00:24 0/ 14:00:29 o/ 14:00:30 o/ 14:00:31 o/ 14:00:31 Thanks jokke_ for setting the agenda for today! 14:00:32 o/ 14:01:09 o/ 14:01:16 o/ 14:01:19 o/ 14:01:48 ativelkov: around? 14:01:51 o/ 14:01:57 o/ 14:02:17 nikhil_k, he's on another meeting 14:02:22 mfedosin: I will let you give us some quick updates on artifacts if that's ok 14:02:28 #topic updates 14:02:30 okay 14:02:35 #info artifacts updates 14:02:45 we finished the client 14:03:05 awesome 14:03:10 \\o \o/ o// o/7 ... amazing guys! 14:03:12 currently we got several comments and I'll fix them soon 14:03:14 mfedosin: wooohoooo 14:03:37 also I finished fixing filtration issues 14:03:59 Alex tested murano client today and it works fine 14:04:11 mfedosin: are there any outstanding critical/high bugs to take care of at this point that may or may not be filed? 14:04:39 I didn't notice them 14:04:44 perfect! 14:04:58 one issue with disabling api v3 by default 14:04:58 mfedosin: and I saw you got your feature branch sorted out 14:05:16 with grenade gate 14:05:35 https://review.openstack.org/#/c/215709/ 14:06:13 I wrote a message to Mr. Dague, but still have no response from him 14:06:47 if you can please take a look how it can be fixed, please 14:07:06 looks like, the erros isn't evident 14:07:11 error* 14:07:48 yep, it's somewhere inside shell scripts 14:08:22 exactly here https://github.com/openstack-dev/grenade/blob/master/inc/upgrade#L68 14:08:32 we still have time, release process start tuesday sept 1 14:09:10 ff will be on sept 1 too? 14:09:28 I'm willing to say that we move grenade to non-voting if that's the way to merge it 14:09:54 ff should be Thu is that 3rd or so ... when L-3 is supposed to be tagged, no? 14:09:58 I don't think people are gunna like it 14:10:02 definitely it's the way :) 14:10:35 we don't have breaking features coming, so FF wasn't enforced. plus we have been careful with some of the proposals 14:10:43 I mean if we can't get our experimental API being disabled by default other means :P 14:10:44 I hope to find Mr.Dague and listen to his comments 14:11:06 mfedosin: email to ML to help rel-mgrs keep track 14:11:16 okay, will do 14:11:25 thnx mfedosin 14:11:36 sounds good 14:11:41 mfedosin: is the API spec done? 14:11:43 we need to move on for now to give some time for other topics proposed earlier 14:11:57 Kairat is working on it 14:12:17 please have them talk to the API-WG to speed this process up 14:12:22 sigmavirus24, so it will be done this week 14:13:10 sigmavirus24, I got you 14:14:02 #topic drivers updates 14:14:27 As we discussed the two most likely specs: 14:14:29 1. https://review.openstack.org/194868 14:14:43 2. https://review.openstack.org/177948 14:14:56 1 needs some work and 2 looks in good shape 14:15:14 The spec for 2 landed 14:15:18 the code seems to be updated 14:15:25 brilliant 14:15:26 we need reviews on 14:15:27 https://review.openstack.org/#/q/owner:%22Brianna+Poulos%22+status:open+project:openstack/glance,n,z 14:15:45 Given the fact that we're 2 weeks away from FF, should we still be considering mergint new specs? 14:15:53 * flaper87 should probably keep that for next drivers' meeting 14:16:06 tl;dr: I think specs should be frozen by now 14:16:06 nikhil_k: thanks 14:16:09 * flaper87 stfu 14:16:09 I think both of these are very well discussed and the second one is quite updated. So, they are unikely to cause more trouble. 14:16:14 bpoulos: great work, btw 14:16:26 flaper87: thanks :) 14:16:30 folks, about swift driver. https://review.openstack.org/#/c/207075/ 14:16:32 kudos bpoulos ... that looks good 14:16:33 nikhil_k: I agree about Image signing, lets move that forward 14:16:49 I'm worried about the spec that hasn't been merged, regardless of how much it's been discussed. 14:16:50 I think I'll publish the code next week 14:16:51 jokke_: thank you to you too 14:16:54 but lets keep that for next week's meeting 14:16:57 mfedosin: looking at the swift driver spec is on my todo list 14:17:05 mfedosin: jokke_ and I had a chat on the store and client proposals 14:17:11 mclaren, thanks! 14:17:29 mfedosin: I chatted with a swift core about it yesterday 14:17:49 it seems unlikely for us to consider releases for store so the specs related to that haven't been top priority 14:17:58 these are the results of testing https://etherpad.openstack.org/p/multithreaded-swift-tests 14:18:28 we have numbers? awesome! 14:18:29 there is no hurry to merge it liberty, and i'm ok to postpone it to M 14:18:35 nikhil_k: we will need the feature release of glance_store we carve stable/liberty out 14:18:38 we need to take care of these features after stable is cut 14:18:55 nikhil_k: and that should be done well before we have release out 14:18:58 mfedosin: we may be able to do this before M starts 14:19:05 jokke_: right 14:19:06 jokke_: ++ 14:19:09 mclaren, yes, in average we have 2,5-3 times upload boost 14:19:21 jokke_: probably even before FF 14:19:34 and about 20-30% download 14:20:22 ok, if nothing critical on these topics, we need to move on 14:20:37 I think we should test the driver properly on scale before merge 14:20:38 flaper87: store is not that big of an problem as glance is only consumer. But we need to have requirements for that stable release version set by rc1 14:20:57 #topic Oslo freezing 14:21:04 jokke_: it's not, I agree. But having an established workflow would be nice 14:21:07 jokke_: that's you? ^ 14:21:09 jokke_: it'd be even nicer to follow it 14:21:10 :P 14:21:20 mfedosin: where the images segmented in swift? 14:21:41 nikhil_k: yeah 14:21:45 it's actually this week 14:21:50 and that was more informational 14:22:03 let me talk about established workflow, appripriate patchesm, review etc once Liberty is out. can't wait. Particularly security risks introduced 14:22:11 just heads up this is happening so we need to keep eye on reuqirement changes 14:23:08 so unless questions, next! ;) 14:23:32 I've been ninja-approving requirements the whole cycle 14:23:34 FYI 14:23:45 after I saw them piling up 14:23:45 jokke_: I think we need to delegate all requirement change to rel-mgrs 14:23:46 :D 14:24:03 nikhil_k: fine by me 14:24:05 all those need to be handled by them only 14:24:11 flaper87: that seems to be only way to get them in 14:24:14 as they shouldn't break other projects 14:24:29 any +2s gets thrown away by new proposal before +a 14:25:22 any breaking change would be the blame of single person if not collab with rel-mgrs. it was a big headache last cycle 14:25:58 #topic Feature freeze 14:26:53 The only two safe features are pointed above 14:27:10 if there is something to bring up, this is the right time to consider everyone's feedback 14:27:22 nikhil_k: so those two and bugfixes are our top 1 from today onwards? 14:27:33 what about the buffered reader change...let me grab linky 14:27:36 artifacts obviously will live their own life for now 14:28:06 and also I want to discuss my suggestion with token expiration 14:28:24 https://review.openstack.org/#/c/199049/ 14:28:27 https://review.openstack.org/#/c/120866/ 14:28:30 jcook: that may go depending on whether we afford to create store rel after it merges 14:29:02 note that feature freeze is a dead line for new features 14:29:04 not bug fixes 14:29:06 the spec itself looks good and is tried and tested change. it's a contained effort as well and likely not to break the world 14:29:07 bug fixes can still land 14:29:15 should I right a spec on this proposal? 14:29:39 mfedosin: +1 to having that as a thing 14:30:12 mfedosin: let's discuss that later. I doubt it but good to consider the impact 14:30:13 *write 14:30:25 mfedosin: the fix (not necessarily a spec) 14:30:28 nikhil_k, sure 14:31:21 #topic glanceclient feature/artifacts branch 14:31:28 that was me again :P 14:31:53 jokke_: please no 14:32:10 So in short I'd like to propose that we let artifact guys merge to the branch by their own convenience to keep it moving 14:32:14 I think the point of FastTrack was to maintain project wide awareness 14:32:39 and yet enabled faster workflow on artifacts particularly 14:32:44 enable( 14:32:52 nikhil_k: fair enough ... and I think that's really important on the glance where the code merges to the master 14:33:03 +! 14:33:12 but it was just a thought ... I have no problem pushing the button on client :D 14:33:20 :) 14:33:26 If we do that, we should first release the client so we can create the liberty branch from that tag w/o artifacts 14:33:38 currently this branch lives on its own :) 14:33:44 yep 14:33:47 flaper87: artifacts are not part of liberty release 14:33:53 jokke_: I know 14:33:59 that's what I said 14:34:01 :D 14:34:02 and afaik all this code will be moved to muranoclient 14:34:07 that was the whole point of the feature/artifacts branch :D 14:34:09 or at least tried to 14:35:07 I vote for allowing us to merge our code, of course 14:35:23 mfedosin: I do undertand that you guys have priorities there as well, but I'm seriously expecting you to keep that feature branch up to date ... I'm happily -2'ing any syncs from muranoclient to glanceclient when we're bringing artifacts finally in ;) 14:35:27 can we discuss this when mitaka dev starts? 14:36:20 flaper87, sure 14:36:21 but I'm really happy to keep the workflow as it is for that branch as well as there is conserns 14:36:24 mfedosin: let's not. it wont be worthy 14:36:28 jokke_: we don't plan to sync anything from murano to glance 14:36:38 ativelkov: thanks ;) 14:37:03 #topic python-glanceclient release 14:37:14 ok to the sore point of the day 14:37:23 mclaren: ^ 14:37:46 ok, I guess it's good to talk through this 14:38:02 A couple of points 14:38:26 First, I think a 1.0.0 release is not just-another-release 14:38:50 we should try and squash any bugs which we don't think belong in a 1.0.0 14:39:08 would it be possible to do something like tag client bugs we'd like to see fixed in 1.0.0? 14:39:39 burn through them, and then release? 14:39:57 I sorta agree there but we are in a catch22 here 14:40:17 mclaren: is there something critical still pending? I don't know if you have looked into the release notes review, but there is quite a bunch of bugfixes currently going in 14:40:35 I think 1.0.0 should be pretty solid 14:40:44 I believe the thing concerning mclaren is the v1 -> v2 change 14:40:47 am I correct? 14:40:47 there's about 5 or 6 things I' personally suggest 14:40:50 Is there something else? 14:41:21 It feels like we're rushing it a bit. For example 14:41:49 I think we should be going through the commands and figuring out where the backwards non-compatabilities are 14:41:51 mclaren: I'm also really disappointed about the fact that I personally gave you heads up 2 days ago when Nikhil sent that e-mail out, and you expressed your concerns publicly an hour before scheduled release 14:42:26 so that when we notify the community it's easier for them to understand when they need to make changes 14:42:37 and, if possible, what the change should look like 14:43:12 I also think we need to give the other projects some time to update their scripts 14:43:27 i agree with jokke_ that the timing of the objection isn't ideal, but i also agree with mclaren that a change that breaks triple-O is problematic 14:43:39 so, figuring out back-compat should not be a problem to be sorted out in glance 14:43:45 releasing this and breaking several things (we haven't done the audit to figure out what breaks, or notified others so they can do it) 14:44:01 mclaren: so do you think the projects that has had almost 6 months time to adjust their scripts would do it in next six if we wait again? 14:44:05 would cause some consternation 14:44:06 FWIW, we've already broken puppet because they run on trunk, I believe 14:44:12 "broken" 14:44:13 as long as we rel as per semantics that suggest so 14:44:30 One more thing, stable branches are capped, someone running Kilo shouldn't be consuming 1.0 14:44:40 stable branches' requirements* 14:44:41 flaper87: no, they're broken because one part of them runs trunk another releases 14:44:54 jokke_: what did I say? 14:45:24 anyway 14:45:52 I think breaking backwards compatibility with this release cannot be avoided but communicating the change properly is important 14:46:05 Agreed 14:46:21 ++ 14:46:24 I think there may be some things we'd want to consider before 1.0.0, for example 14:46:39 However, I'd like this release to be part of Liberty and not wait until Mitaka 14:46:42 Who can take the action item for figuring out all the projects that break because of this and fix it before a set date? 14:46:48 there are ~30 metadef commands that show up when you just type 'glance' 14:47:25 nikhil_k: mclaren can :P 14:47:26 I think it would be neater to move those to sub-commands under a single 'metadef' command. That becomes harder to do if we're not on a major version bump 14:47:27 * flaper87 ducks 14:47:46 nikhil_k: that's not our job. Our job is to communicate this. 14:48:15 mclaren: +1 about metadefs ... iirc, the metadefs sub-team did not object to that 14:48:31 I think we need to allow people to tag bugs for 1.0.0 and then negotiate what folks think are reasonable 14:48:42 ok, who can figure out what all modes of communication we need to adopt besides rel notes that other projects rely on? 14:48:43 Can we start by sending an email to the OPs mailing list and os-dev ? 14:48:57 I believe those 2 are enough 14:49:01 while we're doing that we can send a mail to the ml - with a deadline 14:49:19 and mention it'll be released as part of "Liberty" 14:49:24 so actions: 14:49:31 so, if we postpone for such changes then this won't happen in liberty afaict 14:50:00 1. identify incompatabilies 2. communicate them 3. tag bugs 4. fix bugs 5. release 14:50:17 just to be realistic here there is lots of things that would be nice to have, but either we do this release in fairly near future or we make the call to postpone the 1.0.0 release. The later case means that we ask rel management to cut our stable/liberty branch from 0.19.0 and backport the bugfixes needed 14:51:04 That looks neat approach mclaren ! And I can settle with it if we hanve't made a prior commitment for rel with v2 as default 14:52:35 I think 1, 2 and 3 gotta happen this week 14:53:00 well, it's Thu. 14:53:01 here's a start on the email: https://etherpad.openstack.org/p/glanceclient-1.0.0-warning 14:53:01 or the order of action can be 1. rel notes (high level changes) 2. do in parallel (critical bugs, tagging, identifying incompat and raising on ML as they are found) 14:53:05 the problem with the client is that we're not the only consumers (or we do not consume it at all) so we need to give time to the projects depending on us to identify the bugs that the release will bring up 14:53:14 flaper87: and 5. early next 14:53:36 client rel needs to happen this week 14:53:56 otherwise rel-mgrs will most likely not agree as it breaks the world 14:54:11 it just feels we're rushing this too much 14:54:12 nikhil_k: that's my expectation as well 14:54:58 Like I mentioned this before, we have a conflicting push equally strong requirement for release and no-release. So, let's start with ML. 14:55:03 nikhil_k: thus either we release, collect the feedback and get the bugs fixed so we have something shiny to start M cycle or we keep 0.19.0 as our last feature release of the client 14:55:13 jokke_: right 14:55:26 I need to given some time for store rel 14:55:31 for liberty I mean, not for infinite :P 14:55:37 we can continue client convo on -glance 14:55:50 #topic glance_store release 14:56:00 I'm not sure it's a great idea but we could switch master back to v1 (temporarily) and release that 14:56:19 mclaren: no, please. 14:56:29 mclaren: i think that sends the wrong message 14:56:36 okok 14:56:39 :P 14:57:13 jokke_: anything imp on store? 14:57:20 jcook: wanna raise anything here? 14:57:40 nikhil_k: hi 14:57:46 nikhil_k: this was here just to remind folks that we need to do the feature release for _store as well to get the requirement update done 14:57:56 I have a few tickets that we'd like to get in for liberty 14:57:58 and basis where we cut our stable branch 14:58:19 https://review.openstack.org/#/c/170104/ 14:58:26 https://review.openstack.org/#/c/196240/ 14:58:33 https://review.openstack.org/#/c/217370/ 14:58:42 https://review.openstack.org/#/c/207075/ 14:58:48 https://review.openstack.org/#/c/199049/ 14:58:58 some mfedosin raised already 14:59:19 jcook: jokke_ is our stability liaison and is being stringent on what we can get in to avoid breakage. Now, we don't want to break the world but store is just being consumed by glance, not sure if horizon yet. 14:59:22 oh...this is glance store discussion not oopen discussion 14:59:22 sorry 14:59:44 nikhil_k: Can we have an etherpad with the reviews we should focus on ? 14:59:51 as said bugfixes are not in rush yet 15:00:00 but we need to be feature complete soon 15:00:03 FF is just for features, not bug fixes 15:00:08 https://etherpad.openstack.org/p/glance-liberty-3-reviews 15:00:09 Feature Freeze (FF) 15:00:13 nikhil_k: danke 15:00:18 we are out of time! 15:00:21 thanks all! 15:00:23 thanks 15:00:25 thanks! 15:00:25 #endmetting 15:00:28 #endmeeting