09:00:30 #startmeeting ptl_sync 09:00:31 Meeting started Tue Mar 3 09:00:30 2015 UTC and is due to finish in 60 minutes. The chair is ttx. Information about MeetBot at http://wiki.debian.org/MeetBot. 09:00:33 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 09:00:35 The meeting name has been set to 'ptl_sync' 09:00:50 #topic Heat 09:01:10 #link https://launchpad.net/heat/+milestone/kilo-3 09:01:19 ttx: the only bp's in "not started" are convergence blueprints 09:01:39 there are a bunch of convergence blueprints, this was a very complex blueprint that we 09:01:39 yes -- what's your goal with that ? 09:01:39 broke up into many small blueprints for the purposes of splitting the work amounst the team. 09:01:46 i'd like to do the convergence blueprints a bit more flexibly for a number of reasons 09:01:46 1. they are quite small each 09:01:47 2. this feature is disabled by default and we want to do as much as possible so we can enable the feature early in Liberty 09:01:47 3. they are very inter-dependant so we can't start many until the initial ones are in 09:02:18 asalkeld: would it make sense to develop it in a feature branch ? 09:02:34 ttx: i prefer merging 09:02:51 i am not sure we have a good mechanim for that 09:02:52 any chance it will be "completed" for kilo (even if disabled) ? 09:03:14 yeah, but 50/50 09:03:27 one or two of those might miss 09:03:35 out of like a dozen 09:03:36 ok, I guess it could get exceptions, if it's totally disabled 09:03:57 yip, it's a big job and we are super focused on it 09:04:13 shame to just say no more work until branching 09:04:49 what about keystone-resources ? That's marked "started" 09:05:05 the author says he should have a patch up later today 09:05:11 (so i left it up) 09:05:20 I suppose convergence-push-data is part of "convergence" ? 09:05:25 ttx: yip 09:05:43 OK, so basically you have a FPF for everything but convergence (which gets an exception) 09:05:48 he is working on it today (small item) 09:06:00 keystone-resources needs to be up for review by Thursday 09:06:03 ttx: sounds good 09:06:15 ok, sounds reasonable 09:06:19 yes 09:06:51 #info FPF for everything but *convergence* BPs, keystone-resources still needs to put something up 09:07:23 agree 09:07:47 anything else ttx ? 09:07:48 asalkeld: in other news, I'll be at the ops summit next week, so we'll skip the formal 1:1 (and contact as-needed during that wekk by pining on this channel) 09:07:57 week* 09:07:59 pinging* 09:08:08 ok, see you then 09:08:19 asalkeld: have a good week! 09:08:23 you too 09:12:00 #topic Nova 09:12:21 johnthetubaguy is on holiday this week 09:12:26 just a few notes he sent me: 09:12:46 #info Some sub groups are busy deciding what goes to liberty, but most seem to be aware of the deadline 09:12:53 #info All exceptions are merged now. 09:13:13 #link https://launchpad.net/nova/+milestone/kilo-3 13:00:49 ttx: knock, knock ... ready when you are 13:00:54 eglynn_: here you are 13:01:00 #topic Ceilometer 13:01:17 #link https://launchpad.net/ceilometer/+milestone/kilo-3 13:01:18 #link https://launchpad.net/ceilometer/+milestone/kilo-3 13:01:21 ah! 13:01:34 FPF in two days, that leaves 2 outliers 13:01:47 configdb-api and conf-datastore-agents 13:01:57 so good progress on everything except configdb-api & conf-datastore-agents 13:02:02 exactly 13:02:03 Are both expected to post in the coming days, or are you granting exceptions ? 13:02:17 so FPF is Friday, I;ve made that point repeatedly 13:02:28 You seem to be in a good enough shape feature-wise to survive exceptions 13:02:57 but then Fabio has 3 specs in progress 13:02:59 well I'd prefer to have initial patches proposed by Mar 5th, but if needs be we could let it slide into the week after 13:03:09 it's not just Fabio working on them 13:03:12 ok 13:03:20 he has a HP colleague helping him out 13:03:49 ok, you seem to have things under control. happy with what you delivered in kilo overall ? 13:04:13 well, the ceilo LP doesn't capture the progress made on gnocchi in parallel 13:04:32 so taken as a whole, a fair bit has been acheived 13:04:38 eglynn_: if you had to single out a couple key features, what would that be ? 13:04:56 (top of your head, no need to over-think it) 13:05:05 probably the events/notification pipelines that gordc has been working on 13:05:23 (bringing us closer to what stacktach is capable of on that side) 13:05:34 also the gabbi API testing work that cdent has done 13:05:41 ok, I'll look into that! 13:05:48 (potential for application to a bunch of other projects) 13:06:03 and of course the gnocchi work that jd__ has been spearheading 13:06:13 (though that's at arm's length from ceilo for now) 13:06:51 eglynn_: in a big-tent model, would you keep gnocchi in the "ceilometer team" stuff ? Or would it make sense as a separate team ? 13:07:20 iow, how disjoint is gnocchi dev from ceilometer dev ? 13:07:35 I think I mentioned to you before that jd__ is interested in "big tenting" gnocchi 13:07:55 he probably hasn't made a direct approach yet to the TC as he was on PTO the last two weeks 13:08:03 ok 13:08:20 the dev teams are a bit disjoint in the sense that gnoochi-core is a subset of ceilo-core 13:08:24 I'll be at the Ops summit and skipping formal 1:1s next week 13:08:40 but I've been encouraging jd to extent that gnocchi-core team 13:08:51 ack 13:09:04 are the formal mechanics/process for making a big tent application all set now? 13:09:05 so ping me on IRC or by email if you need me for anything 13:09:10 coolness 13:09:30 eglynn_: yes. We just don't advertise the process that much since we'd like to start slow 13:09:35 https://wiki.openstack.org/wiki/Governance/NewProjectTeams 13:09:49 cool, I'll pass that on Julien 13:09:54 but right now it's so slow nobody applied 13:09:58 :) 13:10:17 cool, gnocchi might be your first customer so :) 13:10:41 he should anticipate the question of the relationship with ceilo, since I expect quite a few TC members are not up to speed on that 13:10:53 (I for one would benefit from a refreshed view) 13:11:03 yep, that makes sense 13:11:14 if you don't have anything else, talk to you later! 13:11:26 cool, thanks for your time :) 13:11:30 SergeyLukjanov: yt? 13:11:38 ttx, hi! 13:11:43 #topic Sahara 13:11:47 #link https://launchpad.net/sahara/+milestone/kilo-3 13:12:12 so, we have a bunch of new approved specs and lots of the merged features 13:12:40 Still 10 missing final code up, so FPF might be a bit short for you? 13:12:45 few of items are now candidates to move to the Liberty release (not started high :( ) 13:13:09 SergeyLukjanov: last week you were unsure of observing FPF in Sahara, what's your take today ? 13:13:27 granting a few exceptions maybe ? 13:13:45 (but not started stuff should definitely be deferred, unless it's really small 13:13:47 ) 13:14:31 * SergeyLukjanov counting nuber of potential FPFE 13:14:47 You fully control FPF fwiw 13:14:51 so you decide :) 13:15:02 (I only enforce FF and FFEs) 13:15:31 okay, so, I think that we'll try to make FPF this week with a few exceptions 13:15:47 sounds good 13:16:01 it looks like it's possible to do, mostly all of the important is stuff is on review (that was started) 13:16:19 I'm going to defer non-started specs to Liberty soon 13:16:23 Are you happy with what you got done in this cycle ? 13:16:45 if you had to single out a couple key kilo features, what would that be ? 13:16:55 (I'd like to look into them before we release) 13:17:12 ttx, yeah, it's going extremely great, we got a lot of new contributors and new feautres 13:17:45 ttx, it's about maturity, operability plus brand new CDH support (Cloudera disto of Hadoop) 13:18:09 plus a lot of improvements in Heat integration, security 13:18:25 ok 13:18:34 Will skip next week 1:1s as I'm at the Ops summit 13:18:41 ping me directly in case of need 13:18:53 in a few words - several new plugins and tons of tech, UX and securityimprovements 13:18:58 ttx, okay, thx 13:19:10 Have a great week! 13:19:12 I think there is no question from my side 13:19:16 ttx, thx, you too! 13:19:27 dhellmann: ready when you are 13:19:33 ttx: hi, there! 13:19:35 #topic Oslo 13:19:45 #link https://launchpad.net/oslo/+milestone/kilo-3 13:19:56 #link https://launchpad.net/oslo/+milestone/next-kilo 13:20:21 dhellmann: hwo are those graduations coming up ? 13:20:39 versionedobjects has some infra-related changes for dan to make 13:21:04 the reports one was kickstarted when I suggested we drop it last week, so it's just starting but there is a repository to be reviewed and imported 13:21:50 ok, we'll see how it goes 13:22:16 yeah, it's unlikely to be done by k-3, so I suppose we could remove it, but I want to let solly keep working on it one way or the other 13:22:47 Any particular kilo achievement you'd like to highlight ? My impression are that the key ones are procedural 13:23:06 like a streamlined release process 13:23:27 yes, although the policy and versionedobjects work has brought us new contributors as well 13:23:27 but I may have missed a critical lib graduation :) 13:24:42 hmm, is there a way to have lp show all of kilo, or just milestones? 13:25:45 apparently the magic behind finsing comon milestones across projects in a projectgroup doesn't extend to series 13:25:52 finding* 13:26:20 the oslo.log graduation wrapped up this cycle will be important for the work we need to do based on sdague's cross-project blueprint next cycle 13:26:34 https://blueprints.launchpad.net/oslo-incubator/kilo only has the incubator 13:26:34 also the common request context library 13:27:40 yeah, I'm looking at the separate milestone pages one at a time instead 13:28:04 I don't think there were any library features that were really big 13:28:08 Like I told the others, we'll skip 1:1s next week while I'm at the Ops summit 13:28:16 ok 13:28:27 I added "Add library stable release procedures/policy" for the cross-project meeting today 13:28:46 although I'm not sure that will result in a very useful discussion at the current stage 13:28:55 but we need to move on 13:29:06 the fact that not enough people care shouldn't block it 13:29:54 disappointing number of votes on that one 13:30:00 would be good to see if Brant can remove his -1 based on your reply 13:30:39 I'll ask him to look again 13:30:46 dhellmann: anything else you wanted to discuss ? 13:31:15 we have a few releases to make today, but none of the changes are very big so I don't expect trouble 13:31:37 ok, talk to you later then! 13:31:42 have a good day! 14:33:09 dhellmann: added a couple comments on the library stable spec 14:33:21 ttx: ack 14:33:25 (to make sure I got it right initially :) 15:00:15 ttx: Here and waiting sir. 15:00:23 * mestery knows he's early ... again ;) 15:00:24 ttx: I responded with a new draft 15:00:35 mestery: stop showing off ;-) 15:00:41 dhellmann: lol :) 15:01:06 dhellmann: My arrival time depends on whether or not we have a neutron meeting preceding this 1:1, and the status of my kids on some mornings :) 15:01:42 mestery: mine really only depends on whether I've been up in time to have breakfast first 15:01:53 dhellmann: rofl :) 15:02:38 #topic Neutron 15:02:49 And I thought I couold have a break, sigh 15:02:53 mestery: o/ 15:03:21 #link https://launchpad.net/neutron/+milestone/kilo-3 15:05:41 dhellmann: +2ed 15:05:53 ttx: I've been going through the list, there are many BPs which are close to merging and need a final push, I expect a lot to land later this week. 15:06:29 I count 11 that still need code proposed to match FPF 15:06:52 ttx: Yes, in yesterday's meeting I reiterated that to everyone. 15:06:53 Feeling ready to defer those ? Or granting exceptions ? 15:06:58 ttx: I expect some of those to not have code proposed by FPF 15:07:07 I'll grant some exceptions I expect. 15:07:10 rigth, but then there is plenty enough to review already 15:07:22 y 15:07:49 mestery: overall, how would you say that cycle went -- It felt a bit more under control to me, but then I'm not really in it 15:08:14 ttx: I agree! It's gone super from my perspective! We've had some slips with thigns as always ,but overall, I'm very happy with the way things are going. 15:08:33 If you had to single out a couple of key features, what would that be ? I guess the decomposition of -aaS and plugin stuff is one 15:09:00 Yes, decomposition and the split of the advanced services. Those, along with all the work refactoring and stabilizing all the agents have been huge. 15:09:18 I expect Neutron Kilo to be of high quality in the stability department 15:09:22 Famous last words I guess :) 15:09:50 I'll be at the ops sumit next week, so not around for our 1:1s 15:10:09 Ack, sounds good and safe travels, it's cold and snowy in the eastern US :) 15:10:22 * ttx looks up weather 15:10:26 lol 15:10:57 I hope that's Celsius and not Fahrenheit 15:11:13 rofl 15:11:44 mestery: ok, have a great week, and get ready for the hammer at the end of the week :) 15:12:33 * mestery straps on the kevlar :) 15:12:38 thanks ttx, safe travels, talk in 2 weeks! 15:12:38 nikhil_k: ready when you are 15:15:25 ttx: o/ 15:16:31 #topic Glance 15:16:38 #link https://launchpad.net/glance/+milestone/kilo-3 15:16:58 nikhil_k: looks like you're pretty close to target so far 15:17:10 Could you add a priority to https://blueprints.launchpad.net/glance/+spec/metadefs-upgrade-by-json-file ? 15:17:25 * nikhil_k thought he did 15:17:40 reloading still returns undefined 15:17:49 done 15:17:56 (sorry, that was new) 15:18:08 So, only https://blueprints.launchpad.net/glance/+spec/catalog-index-service is missing code up 15:18:18 which means you're technically very close to a FPF 15:18:39 ttx: that has code up, let me check if everything is in place though 15:18:52 and I will change the status accordingly 15:19:03 At this point I'd spend cycles reviewing and landing those features, an exception there wouldn't really hurt 15:19:52 nikhil_k: do you feel you accomplished what you wanted in this cycle ? 15:20:04 (it's not done yet, but since we'll soon freze...) 15:20:09 +e 15:20:42 ttx: :) almost.. code is being partially reviewed 15:20:50 nikhil_k: if you had to single out a couple of new kilo glance stuff, what would that be ? 15:20:53 so some features are half complete 15:21:26 ttx: catalog index service and artifacts 15:21:30 ttx: and this one https://blueprints.launchpad.net/glance/+spec/deactivate-image 15:21:56 that one has code in relatively better shape and needs a little bit of work 15:22:12 ack, thx, will try to have a look into that 15:22:31 I'll miss the 1:1s next week due to Ops Summit, but feel free to ping me as needed 15:22:44 That is all I had. 15:23:04 cool, will keep that in mind 15:23:32 ttx: just fyi, I proposed zhiyan for stable core (email subject [openstack-dev] [stable] [Glance] Nomination for glance-stable-maint ) 15:23:51 nikhil_k: yes, saw that -- you don't really need other cores to +1 that btw 15:24:09 I just need to make sure additions have read the stable branch policy before I add them 15:24:28 so let me know when I should reach out 15:24:45 at this point I'm waiting for your green flag 15:24:48 ttx: whenever convenient from now 15:24:54 oh ok. 15:24:56 WIll send 15:24:59 ttx: should I say that on the email or we'r good? 15:25:07 I'll post something there 15:25:15 thanks ttx ! 15:25:20 doing that now 15:25:36 cool 15:27:12 thingee: howdy 15:27:19 ttx: hi! 15:27:20 #topic Cinder 15:27:31 #link https://launchpad.net/cinder/+milestone/kilo-3 15:27:54 We are past your FPF (was on March 1st) and your k3 status matches that 15:28:05 I'd say you're looking pretty good 15:28:32 thanks! 15:28:44 * ttx should create liberty series and l1 milestone in LP 15:28:51 * ttx adds to todo list 15:29:34 How would you say this cycle went, now that we have started descent to release ? 15:30:19 This milestone makes up for all of it :) 15:30:37 thingee: if you had to single out a couple features, what would that be ? 15:31:34 well I was going to say that all the driver updates didn't really help in the last release. Haven't quite figured out what to do there. 15:32:02 Kind of hard when you implement new features in k-1 or k-2 and then there's a small window for drivers to do implement them. 15:32:36 thingee: looks like you need... a longer cycle ! (just kidding) 15:32:44 heh 15:33:11 I'm not really sure what the answer there is yet. People get scared when you say last milestone will just been bug fixes/core related things 15:33:22 so you have new features but drivers have not necessarily caught up to them ? 15:34:06 that's correct. I have plans on better coordinating with drivers in the future on new features. Mostly because only the active vendors keep up. I just think communication there has always not been that great. 15:34:33 But I also want some features to eventually be considered features that I can say will work across all backends. 15:34:44 thingee: I think the real solution is to accept that they won't be up to date and ocument that properly 15:34:48 +D 15:35:00 So they remain as optional features and not part of our minimum features list. The minimum feature list is what makes our driver api so great in my opinion. 15:35:12 something like an API microversion that they implement up to 15:35:25 and "driver updates" would increment that microversion support 15:36:23 so you'd have version x.y.z which adds feature a and b, and then some drivers submit a x.y.z support update and some others don't 15:36:44 or you can go the neutron road and decouple them 15:36:59 or you can do a longer cycle :) 15:37:42 That's an interesting idea. Well we have the ABC stuff done in an abstract class for the driver now. The minimum features are represented in this base minimum abstract class. All drivers must support that, or cinder won't even start up properly. unit tests would fail. As we graduate new features, we move them to that. 15:37:59 you can tell if all drivers implement it a feature you move to that. 15:38:28 right, I think that's sane -- I was more wondering how to solve the "new feature adopeted in few drivers" issue 15:38:39 communication 15:38:45 to start 15:38:46 :) 15:38:49 you could have features as levels and then ask drivers to submit level updates 15:39:23 and then document what each driver level is. But that may require a discipline people don't have 15:39:36 (i.e. what happens if they impelment all of level 45 except feature C 15:39:43 it has shown to be more successful in the third party ci then previous attempts anyways. As much as I want vendors to be around all the time to listen to updates. 15:40:01 ok, anyway, longer discussion ahead 15:40:13 I'll be at the ops sumit next week, so missing our 1:1 15:40:21 I'll be there 15:40:26 great! 15:40:28 good time to get feedback 15:40:29 see you there then 15:40:56 david-lyle: ready when you are 15:41:10 ttx: readu 15:41:17 close enough 15:41:22 #topic Horizon 15:41:32 ttx: I'll talk to you more about this later. thanks for the help 15:41:43 #link https://launchpad.net/horizon/+milestone/kilo-3 15:42:14 david-lyle: IIRC you said you would try to enforce FPF at the end of the week 15:42:22 you seem to be a bit far away from there 15:42:50 16 blueprints are not yet in "needs code review" 15:42:59 I think there will be a couple of exceptions, I'm repruning list 15:43:09 haven't made it to the bottom yet 15:43:15 ok 15:43:42 high priority item around launch instance rework will likely have a couple of exceptions 15:43:43 I thihnk to maiximize the quantity of stuff getting done, having a clean (and lean) list of stuff to review in the lmast two weeks helps 15:43:56 I can't type today 15:44:15 yes, we've been sprinting/review daying on the launch instance work 15:44:20 alright. So you will reprune the list and grant a couple exceptions 15:44:24 yes 15:44:39 That sounds good to me 15:45:24 So what are the likely key things that will land in kilo, now that we are sufficiently close to the end ? 15:45:36 I bet the launch instance rework is one 15:45:42 still looking to move to specs for next release and avoid the open assignment to milestones 15:46:40 launch instance, table rework (search) 15:46:48 are the biggest items 15:47:04 big UX improvements that set us up well for future progress 15:47:40 I will end up picking up the django item 15:47:44 david-lyle: as far as big-tent goes, I think Horizon will have to decide what they directly support and what they externally support 15:47:53 that may translate into two tags 15:48:09 something like horizon-built-in and horizon-plugin 15:48:17 yes, we're continuing to discuss that 15:48:27 projects you feel comfortable supporting would be horizon-built-in 15:48:40 projects providing a horizon-plugin of reasonable quality could be horizon-plugin 15:48:42 I think a lot of the overhead right now is from things that could be plugin 15:49:06 right, like I wrote elsewhere, I expect big-tent to clarify things and increase focus rather than decrease it 15:49:26 I think that's wise, trying to cover too much scope, we just drown 15:49:31 and be honest about what we (horizontal stuff) can support and not 15:50:04 I prefer we say "we support A B C and we help the others by giving them advice" rather than "we support anything they throw at us" 15:50:20 the UX team will become more integral once things move to plugins 15:50:22 and then not deliver consistent quality 15:50:45 indeed 15:50:57 ttx, I agree, I think horizon provides a solid, extensible base on some core services and their interrelation 15:51:15 the rest builds on that outside in plugins 15:51:28 I think that's not just true for horizon 15:51:41 so I think we're in violent agreement 15:51:58 right, that's the base -- doesn't mean you can't support directly /some/ stuff, but that should entirely be Horizon team decision, not the TC or someone else's 15:52:14 exactly same with release management 15:52:29 yes 15:52:43 as long as you provide base framework / tools / advice for those other teams to do it themselves, that's sane (and more scalable) 15:52:55 Anyway, I'll be at Ops Summit next week, so skipping this 1:1 15:53:00 what would be the process for extricating code already included? 15:53:09 has anyone thought about that? 15:53:36 david-lyle: that would be a repo split -- not worse that what neutron did this cycle 15:53:46 with horizon we support plugins, so rolling code out into plugins wouldn't be terrible, but maybe not an easy conversation 15:53:51 we can conserve history and all 15:54:14 technically not that difficult. Socially... 15:54:21 yes 15:54:32 so.. got to run; have a great week, and ping me if needed! 15:54:40 ok thanks 16:51:41 morganfainberg: ready when you are 16:51:57 O/ 16:52:04 #topic Keystone 16:52:17 #link https://launchpad.net/keystone/+milestone/kilo-3 16:52:43 That leaves 2 blueprints still needing to drop code before eow 16:52:45 So today going to push out a couple of those. 16:53:00 reseller & keystone-tokenless-authz-with-x509-ssl-client-cert 16:53:09 shorter title and longer title evar 16:53:09 Reseller is going to push out and x509 likely is as well 16:53:39 Feels like you have things under control 16:53:48 Code that will likely merge today will be the domain sql one and the last of the ae/kelt/fernet token ones. 16:54:13 As we begin our descent to final release, what are your first thoughts on how this cycle went for Keystone ? Did you end up doing what you wanted ? 16:54:16 Domain sql might request a ffe, but that is just to gate not because it's still being written. 16:54:58 I feel that we crammed too much into k3. I want to roll back fpf to m2 for next release of I'm ptl 16:55:09 If* 16:55:14 If you had to highlight a couple of kilo features/successes, what would those be ? 16:55:25 the fernet/ae token is a big win 16:55:46 I still need to dig in that. Was hoping one of those blogposts your team is so fond of about it 16:55:48 It is addressing the biggest scaling issue of keystone. The persistence requirement for tokens. 16:56:16 Yeah I haven't had the time to write one up:). Dolph wrote up a good one as did lance. 16:56:47 "Keystone to Keystone Service Providers" is the next step in k2k federation right 16:56:47 Also the move away from "extensions" is a big win I'm happy about. 16:57:05 Yes k2k is the next step in federation. 16:57:28 We also have added code to let deployers map users from an external Idp to a local user. 16:58:00 Instead of federated users always being ephemeral. 16:58:15 ack, will try to dig in all of those for my personal culture 16:58:28 I'll skip 1:1s next week due to Ops Summit 16:58:30 K2k needed that for some bigger use cases (cern iirc really could use that) 16:58:34 ++ 16:58:34 ping me in case of need 16:58:44 That is all I had 16:58:52 have a great week! 16:58:55 after ops summit I'll un -1 the sql downgrade spec 16:59:01 yap 16:59:02 Same to you, cheers. 17:00:02 notmyname: ready when you are 17:01:12 good morning. I'm ready 17:01:20 * notmyname just responded to the release tags patch 17:01:23 #topic Swift 17:01:38 * ttx looks 17:01:59 we can carry that on in gerrit :-) 17:02:20 ok. /me has 8 minutes until a phone call 17:02:20 heh, yes. If teher was a simple solution we'd all agree already 17:02:27 :-) 17:02:29 ok, what news ? 17:02:36 two things off the top of my head 17:02:44 I see work landing on the encryption branch alright 17:02:49 #info Swift's OPW intern has completed her project 17:02:50 yay 17:02:55 yay 17:03:00 this week is the last OPW scheduled week 17:03:06 so perfect timing 17:03:15 also, status update on EC... 17:03:29 we've made good progress in the last week. things are looking good 17:03:45 * notmyname is continually impressed by and happy to work with swift contributors 17:03:48 notmyname: any window for the big merge to master ? 17:04:15 this week (ie today->tomorrow) we'll be making the call, based on current momentum and outstanding work, if we will commit to an EC beta in Kilo 17:04:23 ok 17:04:41 That sounds good 17:04:45 if so (IF), then we will schedule the merge to master in about 4 weeks. allowing for 2 weeks for that to land before the RC 17:04:57 I'll be at Ops Summit next week, so skipping this 1:1 -- keep me posted on the decision though 17:05:03 scheduling the RC around the 10th. and the merge window starting mar 27 17:05:08 I too will be at the ops meetup 17:05:21 great! I'll see you there 17:05:30 those dates above are dependent on the EC decision 17:05:39 understood 17:05:47 in other news, yes the crypto work in progressing 17:06:05 and on the project management side, I made something 17:06:07 #info call to be made on including EC beta in kilo this week 17:06:20 #info if it is a go, will schedule the merge to master in about 4 weeks. allowing for 2 weeks for that to land before the RC 17:06:39 http://goo.gl/9EI0Sz and http://goo.gl/uRzLBX are 2 new/updated review dashboards for swift. on is for reviewers. one is an overview 17:07:09 Starred Patches, interesting 17:07:09 the reason I want to share those is because I'm doing something there I haven't seen done before: a dashboard listing stuff starred by other people 17:07:14 ya, I think so 17:07:35 so on the review one, it includes the PTL's starred patches. those are the same as the priority reviews 17:07:40 from https://wiki.openstack.org/wiki/Swift/PriorityReviews 17:08:05 you should definitely share those on some of the angry threads 17:08:06 on the project overview dash, there is a section for "Starred by any core". that gives me an idea of what people are interested in and looking at 17:08:43 I think it will be helpful to us. Even yesterday I found it useful for review queue hygiene 17:09:03 that's all I've got. anything from you? anything I can do? 17:09:17 nothing comes to mind right now 17:09:23 Jump on next meeting! 17:09:26 and see you next week 17:09:28 ok. see you next week 17:09:39 devananda: ready when you are 17:10:17 ttx: hi! 17:10:21 #topic Ironic 17:10:28 #link https://launchpad.net/ironic/+milestone/kilo-3 17:10:57 So I see 5 blueprints needing code land before FPF eow 17:11:01 I mean cope up 17:11:05 code up* 17:11:27 yea, we're going through that this week to make sure everything's in shape 17:11:51 You already have a lot to review -- planning to strictly observe FPF, or are exceptions considered ?* 17:12:01 pretty strict 17:12:08 there's far more than we'll actually be able to do already accepted 17:12:12 and we know that 17:12:21 good :) 17:12:34 we have not had to bump things in the past, because last cycle we didn't allow in things that we didn't have confidence in landing 17:12:40 so this will be new for our community 17:12:51 So, now that you ahve a pretty good idea of what will actually likely be in kilo, how would you say that cycle went for Ironic ? 17:12:58 we've put a lot of time into vetting designs, so there's confidence in that 17:13:16 but there is probably not enough time left to review all the code for each of those 17:13:44 i think many core reviewers do not like this structure 17:13:49 *release structure 17:14:06 and would rather have continual development & stabilization with much smaller iterations 17:14:22 but we'll see how the rest of the cycle goes, and i'm sure we'll talk about it in vancouver 17:14:31 we definitely will 17:14:38 I expect in a few weeks, there will be a minor revolt 17:14:47 when I kick half of these BPs to Liberty 17:15:01 It's weird, because the recent push was rather away from significant milestones and considering them just a tag 17:15:10 and development essentially stalls for a month 17:15:28 it's sort of like we just built up momentup for the cycle 17:15:29 and it feels like people want to tag more often 17:15:42 last two milestones were mostly spec work, with some foundational code merged 17:15:54 now that that's done, there's a BUNCH of work that folks are / have done, that we want to land 17:15:58 but the window to land it is too small 17:16:12 because of (seemingly) artificial milestones 17:16:24 right, so there was a mismatch with the time-based segment and your internal wave 17:16:28 yup 17:16:56 in THEORY, the various points in the cycle shoudl help in aligning the internal momentum with the cycle 17:17:13 but as we made milestones less significant, I think we lost that 17:17:26 indeed 17:17:42 also, now that ironic has microversion support in the API 17:17:49 folks are more inclined to allow faster iteration on things 17:18:02 right 17:18:17 I'm not sure that's wise -- just because we CAN do microversions does not mean we should start being less cautious about API changes 17:18:22 but it is a trend 17:20:05 OK, so as I said to the others, skipping 1:1s next week due to Ops Summit 17:20:33 *nod* 17:20:41 last question would be -- what are the key achievements for the Ironic team this cycle ? I want to lok into those before we go deeper in release mode 17:20:51 say hi to folks for me - i wish I was going, but need a break from travel 17:21:34 key achievements ... state machine is a massive one 17:21:36 #link https://blueprints.launchpad.net/ironic/+spec/new-ironic-state-machine 17:21:48 we might not finish implementing all of it this cyucle, though we're going to try 17:21:51 and we're close 17:22:45 configdrive support 17:22:47 #link https://blueprints.launchpad.net/ironic/+spec/driver-periodic-tasks 17:22:53 woops, wrong link 17:22:53 #undo 17:23:01 #link https://blueprints.launchpad.net/ironic/+spec/expose-configdrive 17:23:31 adding zapping and cleaning stages, which in turn allow RAID and firmware config to be implemented by drivers 17:23:42 also, node introspection through ironic-discoverd 17:23:53 which is still on stackforge, pending integration testing 17:24:07 once it has real CI, i'd like to move it to openstack/ namespace 17:24:22 devananda: is that likely to be happening in kilo ? 17:24:26 no 17:24:31 ok 17:24:47 devananda: need to switch to Trove. Have a great week! 17:24:52 ok! yo utoo 17:24:58 SlickNik: ready? 17:25:47 ttx: here 17:26:02 #link https://launchpad.net/trove/+milestone/kilo-3 17:26:17 #topic Trove 17:26:32 whoops, got a bit too eager there :) 17:26:35 Those are interesting colors 17:26:59 So still 3 in jeopardy, likely to be dropped at end of week 17:27:06 And a whole pile to review 17:27:13 Is that a fair summary ? 17:27:42 Yes — been driving to see which ones of the 3 can make it before FPF, and getting folks to review the ones that are already out there. 17:27:51 Good summary. 17:27:57 sounds all good to me 17:28:30 Asking the same question I asked others... what are the key features you think are in Kilo Trove ? 17:28:36 or will be, rather 17:28:46 features or key team achievements 17:29:03 I'd like to look into them before I'm stuck in release mode 17:29:47 Support for a two new datastores is top of the list — CouchDB and Vertica. 17:30:26 ack 17:30:29 Support for Vertica clusters. 17:30:52 * ttx doesn't even know what Vertica is, so I'll start by that one :) 17:31:08 SlickNik: I'll be away at the Ops SUmmit next week, so skipping 1:1 17:31:23 Vertica = column based datastore 17:31:24 don't hesitate to ping me on IRC or email in case of need though 17:31:34 Will do 17:32:01 SlickNik: have a great day and week 17:32:05 That concludes today's series of 1:1 syncs. Thanks for listening... 17:32:08 #endmeeting