16:01:52 <jgriffith> #startmeeting cinder
16:01:53 <openstack> Meeting started Wed Sep  3 16:01:52 2014 UTC and is due to finish in 60 minutes.  The chair is jgriffith. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:01:54 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:01:56 <openstack> The meeting name has been set to 'cinder'
16:01:59 <jgriffith> hola everybody
16:01:59 <hemna> mep
16:02:01 <avishay> hello all
16:02:03 <xyang1> hi
16:02:04 <eharney> hi
16:02:08 <Guest95203> hi
16:02:09 <vbala> hi
16:02:09 <kmartin> o/
16:02:11 <Arkady_Kanevsky> hello
16:02:19 <asselin__> hi
16:02:22 <jgriffith> so just a few things to start....
16:02:27 <jgriffith> #topic J3
16:02:35 <smcginnis> o/
16:02:46 <jgriffith> We went ahead and set the whels in motion to tag J3 this morning
16:03:11 <jgriffith> There were two SMB patches granted exceptions that we'll focus on when RC1 opens
16:03:33 <jgriffith> We shouldn't approve anything new after this point
16:03:49 <jkremer> hi
16:03:50 <jgriffith> keep the J3 target map clean
16:04:02 <hemna> so the incremental backups patch is out then?
16:04:05 <jgriffith> #topic folks requesting exceptions for drivers
16:04:10 <jgriffith> hemna: yes
16:04:12 <hemna> ok
16:04:16 <hemna> I'll -2 it now then.
16:04:28 <Murali__> Can you add comments
16:04:36 <e0ne> jgriffith which bugs priority will be acceptable after j3?
16:04:37 <Murali__> on the patch so I can address them
16:04:38 <jungleboyj_> Sorry, my client died.
16:04:38 <jgriffith> Murali__: I'll explain in a sec
16:04:47 <Murali__> ok.
16:04:53 <jungleboyj_> So, even the items in flight are getting -2'd now?
16:04:54 <jgriffith> e0ne: bugs are always allowed to be fixed for the most part
16:05:06 <xyang1> jgriffith: question for you.  Is the driver implemenation of CG considered a bug fix or feature?  Is it too late to merge that?
16:05:14 <jgriffith> everybody please wait a second
16:05:25 <jgriffith> you can't all ask me questions at once about different topics :)
16:05:45 <jgriffith> There are two drivers that were in process
16:05:57 <jgriffith> rhe00_: had an X-IO driver
16:06:09 <jgriffith> and joa with his scality driver
16:06:39 <rhe00_> yes
16:07:02 <hemna> jgriffith, I just -2'd his driver because he doesn't have any cert logs, FYI.
16:07:05 <jgriffith> I'd like to get input from other core memebers
16:07:11 <jgriffith> hemna: which ?
16:07:22 <hemna> jgriffith, joa's scality rest block driver
16:07:32 <jgriffith> hemna: k
16:07:53 <jgriffith> anybody have any input on these two, other than what hemna just pointed out on Scality driver?
16:08:13 <jungleboyj_> jgriffith: I need to look at the Scality driver.
16:08:19 <hemna> I think eharney had issues with the SMB driver breaking the nfs driver
16:08:22 <jungleboyj_> I had reviewed the X-IO one before I believe.
16:08:24 <hemna> did that get ironed out?
16:08:28 <jgriffith> so I think maybe I'm not being clear......
16:08:29 <eharney> hemna: that was fixed
16:08:37 <jgriffith> do we want to do exceptions for these?
16:08:40 <jgriffith> bahhh
16:08:42 <avishay> weeeeeee
16:08:49 <jungleboyj_> Sheesh.
16:08:51 <DuncanT> SMB driver had enough +2s to merge but we held off to get final signoff from Eric
16:08:55 <hemna> eharney, ok cool.
16:08:59 <DuncanT> I'd support that one getting an exception
16:09:00 <jgriffith> wow... that was awesome
16:09:50 <jungleboyj_> DuncanT: I am ok with that if eharney is ok with it.
16:09:54 <hemna> I'd be ok with the SMB driver.  it's waiting on jenkins currently
16:09:54 <jgriffith> FYI the SMB patches already have an exception
16:09:57 <eharney> yes, i am
16:09:58 <hemna> ok
16:10:04 <jgriffith> I'm specifically asking aobut the two drivers
16:10:08 <jgriffith> XIO and Scality
16:10:10 <hemna> so exceptions for X-IO and scality?
16:10:23 <jgriffith> hemna: yes, that's the question on the table
16:10:38 <eharney> X-IO appears to have had virtually no review so hard to say
16:10:40 <hemna> XIO at least has driver cert results
16:10:51 <jgriffith> hemna: +1
16:11:14 <DuncanT> Scality I'm told has been running cert runs, haven't seen the results posted though
16:11:24 <thingee_> hey all
16:11:25 <jgriffith> I'm surprised joa isn't ehre
16:11:47 <bswartz> freenode is having problems
16:11:53 <bswartz> my client keeps dropping
16:12:16 <hemna> I don't see any core reviews on X-IO yet
16:12:17 <rhe00_> rhe00 is here for X-IO, and I'm hoping for an exception. :)
16:12:36 <jungleboyj_> hemna: Where is that review?
16:12:47 <hemna> https://review.openstack.org/#/c/116186/
16:12:58 <hemna> the driver was submitted Aug 21.  feature freeze date
16:13:01 <hemna> :(
16:13:25 <jungleboyj_> hemna: Thanks.  Doh, I guess I hadn't looked at that one.
16:14:09 <jgriffith> so general thoughts on exceptions for drivers?
16:14:13 <DuncanT> X-IO was very late and has had almost no reviews, I think we punt it
16:14:20 <hemna> I think X-IO was too late
16:14:23 <hemna> and no real reviews
16:14:24 <jgriffith> DuncanT: thank you for voicing an opinion
16:14:33 <jgriffith> hemna: ditto
16:14:49 <jungleboyj_> I think that seems logical DuncanT
16:15:13 <rushiagr> I missed seeing that review too..
16:15:24 <jgriffith> Ok, so shall we punt on both of them?
16:15:44 <jungleboyj_> jgriffith: Wasn't scality further along in the process?
16:16:03 <jgriffith> jungleboyj_: well, depends on how you define "further along" :)
16:16:11 <hemna> ok doing a quick review on the X-IO driver, I see problems with it.
16:16:16 <hemna> soren, I vote no on it for Juno
16:16:25 <jungleboyj_> jgriffith: :-)
16:16:25 <DuncanT> While feeling sorry for Joa, I vote to punt that one too
16:16:26 <hemna> *Sigh*  s/soren/so
16:16:31 <eharney> did the scality one get much feedback other than name debates?
16:16:44 <jgriffith> OK... anybody from core want to champion one of them?
16:16:50 <jgriffith> if not we'll punt I think
16:16:58 <hemna> joa has at least been active recently trying to get feedback
16:17:04 <DuncanT> eharney: There's been a fair bit of discussion on their snapshot approach, but no actual problems found
16:17:30 <jungleboyj_> hemna: That is my concern.
16:17:30 <jgriffith> Honestly I don't have a problem if people want to review and work on it
16:17:34 <jgriffith> make a decision next week
16:17:38 <eharney> DuncanT: yeah I've looked at it a bit but can't gauge how close it is
16:17:52 <hemna> I'd be ok with giving the scality driver a bit more time.
16:17:53 <jgriffith> ok, let's review the code
16:17:56 <hemna> get those cert logs up today
16:18:02 <hemna> and review the code
16:18:02 <jgriffith> depending on what happens in the next 24 hours I'll make a call
16:18:04 <jungleboyj_> jgriffith: Lets get reviews on scality and SMB.
16:18:10 <jungleboyj_> jgriffith: Punt XIO.
16:18:16 <DuncanT> jungleboyj_: +2
16:18:17 <hemna> X-IO should be out IMHO.
16:18:23 <eharney> sounds good
16:18:26 <jgriffith> ok
16:18:31 <thingee> jgriffith: I'm back from burning man, so I can pitch in ;)
16:18:40 <rhe00_> then can I please get it marked for the next release?
16:18:48 <jgriffith> rhe00_: absolutely
16:18:49 <rhe00_> so I don't miss that train as well
16:19:05 <jgriffith> Ok, scality is in
16:19:08 <jgriffith> let's move on
16:19:10 <rhe00_> already missed icehouse with a narrow margin and then fumbled for Juno
16:19:25 <jgriffith> #topic moving brick out of cinder
16:19:35 <jgriffith> eOne isn't here :(
16:19:41 <e0ne> e0ne ;(
16:19:48 <jgriffith> ahh... there you are
16:20:16 <e0ne> i hope Emma and Ben are here too
16:20:26 <jgriffith> so... short and sweet
16:20:28 <jgriffith> +1
16:20:31 <jgriffith> stackforge
16:20:40 <jgriffith> but currently there's little value
16:20:58 <jgriffith> I'd say we have to work out solving the "real" problem
16:21:11 <jgriffith> the LVM code inparticular as is is not ready or good
16:21:15 <e0ne> stackforge is much easier. it could be moved to oslo later
16:21:16 <DuncanT> There are multiple 'real' problems
16:21:37 <jgriffith> so I'd like to regroup on this later TBH
16:21:46 <hemna> jgriffith, you want to do this for Juno ?
16:21:55 <jgriffith> it's not well thought out, and there's still no movement on what we actually want here
16:21:59 <jgriffith> hemna: huh?  Helll noooo
16:22:02 <hemna> ok :)
16:22:19 <jgriffith> let's discuss this after we get Juno under our belt
16:22:20 <bswartz> Isn't one of the real problems that cinder and nova have different implementations of the same code (i.e. how to attach to stuff that cinder creates)?
16:22:21 <eharney> i think that sounds like a good plan... i'm glad this is being discussed but it's not clear what the basic ideas are
16:22:30 <jgriffith> I think there's still a lot of misconception and lack of focus here
16:22:37 <hemna> I think there is value on having something outside of cinder that handles LUN discovery (a la brick connectors)
16:22:37 <jgriffith> eharney: :)
16:23:00 <jgriffith> e0ne: let's sync up later
16:23:02 <e0ne> jgriffith: you decided that Ban will be responsible  for moving it from Cinder
16:23:10 <jgriffith> e0ne: I'll give you the ugly history
16:23:17 <jgriffith> Ban?
16:23:20 <e0ne> e0ne: ok
16:23:26 <jgriffith> e0ne: huh?
16:23:35 <e0ne> link https://etherpad.openstack.org/p/cinder-meetup-summer-2014
16:23:44 <hemna> I guess the decision is do we want an agent that cinder/nova can talk to that does this, or just a library (brick) ?
16:23:56 <jgriffith> agent
16:24:06 <hemna> I think the agent makes more sense long term IMO
16:24:16 <DuncanT> agent, but it is a hard thing to design
16:24:31 <hemna> and the agent needs a concrete API that cinder/nova can talk to
16:24:36 <hemna> and then get buy off from Nova
16:24:40 <hemna> *sigh*
16:24:48 <bswartz> so brick is dead, long live cinder-agent?
16:24:50 <xyang1> hemna: there was a nova-spec on this, I think
16:24:59 <jgriffith> bswartz: that's what brick was supposed to be
16:25:04 <hemna> bswartz, well it's not dead yet...
16:25:04 <jgriffith> anyway...
16:25:09 <jgriffith> let's move on
16:25:12 <DuncanT> bswartz: Brick is a library that has many useful bits for building the agent
16:25:19 <hemna> DuncanT, +1
16:25:19 <jgriffith> we have higher priorities right now
16:25:34 <jgriffith> #topic Cinder CI tests and FC
16:25:36 <bswartz> yeah sorry for the hyperbole -- I think I get the gist and I have no disagreement
16:25:37 <jgriffith> asselin__:
16:25:42 <jgriffith> bswartz: :)
16:25:44 <hemna> maybe we can start small and just have the simple agent that does the LUN discover and report back.
16:26:08 <jgriffith> Ok...
16:26:15 <jgriffith> asselin__: has pass-through FC working
16:26:16 <DuncanT> hemna: Probably best to write a spec and we can discuss it then?
16:26:18 <jgriffith> yayyy
16:26:21 <hemna> DuncanT, agreed
16:26:23 <jgriffith> good job asselin__
16:26:27 <xyang1> asselin__: great!
16:26:36 <jgriffith> #topic cut off dates for Kilo
16:26:38 <asselin__> thanks
16:26:44 <e0ne> asselin__ congrats!
16:26:45 <jgriffith> asselin__: oh.. you're here
16:26:54 <jgriffith> asselin__: anything inparticular you want to share here?
16:27:08 <hemna> he was just missing the FC drivers on the blade yesterday and then everything fell into place
16:27:19 <asselin__> well I got it working yesterday. Lots of credit to hemna and Rahul Verma (our summer intern)
16:27:46 <xyang1> asselin__: we should try this soon.  thanks!
16:27:51 <asselin__> it's been running overnight, but there are some stability problems. Not sure if it's related to FC or not.
16:28:18 <asselin__> the scripts are in my github repo. Link is in the meeting minutes.
16:28:53 <xyang1> asselin__: how many commits can your CI handle in a day?
16:29:17 <asselin__> so it'd be good for others to try out.
16:30:02 <asselin__> xyang1, we're limited to 1 job at a time now. So about 24/day is a good guess.
16:30:21 <xyang1> asselin__: thanks.  good to know
16:30:30 <hemna> 1 job per node at any time
16:30:31 <asselin__> 1 job = 1 driver. We have 3 drviers, so 3 jobs simultaneously.
16:30:37 <hemna> due to FC passthrough
16:30:51 <xyang1> ok
16:31:13 <asselin__> right, we do 1 fc job at a time, 1 iscsi job at a time, and 1 other iscsi job that doesn't require a 2nd eth
16:32:33 <asselin__> so, please try it out. let me know what works or not. bug fixes are appreciated.
16:33:22 <asselin__> documentation is still poor, so do your best and ask me questions.
16:33:30 <asselin__> poor -> non-existent
16:34:35 <asselin__> that's it, unless anyone has questions, or freenode is having issues.
16:34:40 <jgriffith> Ok.. thanks asselin__
16:34:51 <jgriffith> back to cut-off dates
16:34:53 <jgriffith> jungleboyj_:
16:35:06 <jungleboyj_> jgriffith: Thanks.
16:35:24 <jungleboyj_> jgriffith: Just wanted to nail down what is expected for Kilo.
16:35:33 <jungleboyj_> No drivers after Kilo1?
16:35:48 <jgriffith> jungleboyj_: I'm good with that
16:35:49 <rushiagr> +1
16:35:59 <jgriffith> I think avishay would like to say "NO new drivers."
16:36:10 <avishay> jgriffith: :)
16:36:13 <jungleboyj_> jgriffith: Well, we already have some deferred.  ;-)
16:36:20 <jgriffith> but I think K1 is a good compromise
16:36:23 <rhe00_> so when is Kilo1?
16:36:23 <hemna> jungleboyj_, +1
16:36:23 <jgriffith> jungleboyj_: yup
16:36:32 <jgriffith> rhe00_: don't know yet
16:36:35 <hemna> I think we wanted to target Kilo for stabilization no?
16:36:37 <avishay> jgriffith: i think drivers are less harmful...i'd like to see less new features
16:36:37 <xyang1> jgriffith: ok, good to know.  we'll target k-1:)
16:36:39 <jungleboyj_> jgriffith: How about adding support for features into drivers?
16:36:39 <jgriffith> rhe00_: will likely be around Dec
16:36:43 <bswartz> Kilo will be early december most likely
16:36:49 <rushiagr> I like the idea of K1. We're not saying 'no' to drivers, and also we're ensuring we've good amount of time for stabilizing/improving cinder
16:37:00 <bswartz> December 5 is my bet
16:37:11 <eharney> jungleboyj_: i'm not sure it's reasonable to restrict adding support for features into drivers
16:37:14 <jgriffith> Ok, anybody object to running with that for the K release?
16:37:24 <jgriffith> eharney: we'll get to that next :)
16:37:33 <jungleboyj_> jgriffith: Works for me.
16:37:42 <jgriffith> ok.. going once?
16:37:46 <avishay> jgriffith: +8
16:37:48 <eharney> i'll say i'm +0 on the k-1 driver limit
16:37:51 <jgriffith> speak now or don't wine to me in 2 months
16:37:59 <jgriffith> eharney: fair enough
16:38:06 <xyang1> jgriffith: I found the dates always keep moving:)
16:38:15 <jgriffith> xyang1: indeed they do
16:38:21 <jungleboyj_> xyang1: If we set them earlier they won't move out so far.
16:38:30 <hemna> jgriffith, +1 on drivers at K1.
16:38:37 <DuncanT> +1 from me too
16:38:40 <jgriffith> xyang1: the idea is we'd like to have a release where we spend more of our efforts on the core project and stability
16:38:41 <rhe00_> why would you want to prevent new drivers?
16:38:51 <xyang1> jgriffith: understand
16:38:54 <jgriffith> rhe00_: we don't want to prevent them
16:39:06 <rhe00_> ok, that's what it sounded like
16:39:08 <DuncanT> Can we put a big, loud, clear statement on the mailing list today, so that people can't say they didn't know? (I'll send it, and a reminder at summit time)
16:39:08 <jgriffith> rhe00_: but adding a dozen drivers in the last milestone of every release sucks
16:39:10 <hemna> rhe00_, they just need to be in by K1.
16:39:18 <hemna> DuncanT, +2
16:39:26 <jgriffith> rhe00_: we'd at least like to have them submitted early
16:39:29 <jungleboyj_> rhe00_: We want to focus on other reviews and fixes.
16:39:32 <jgriffith> rather than at the last minutes
16:39:36 <DuncanT> rhe00_: New drivers suck up review time like crazy
16:39:41 <rhe00_> ok, understood.
16:39:45 <jgriffith> because we all know there's no better time than the last minute
16:39:59 <jgriffith> #topic no new driver features
16:40:09 <jgriffith> I'm certainly not a proponent of that
16:40:10 <DuncanT> #action Duncan to go advertise this decision on the mailing list
16:40:24 <eharney> i don't think this one makes sense unless there's something i'm missing
16:40:29 <jgriffith> jungleboyj_: are you saying you'd propose that?
16:40:30 <DuncanT> I think we want /more/ drivers to fix up missing features, not fewer
16:40:37 <hemna> eharney, +1
16:40:42 <jgriffith> eharney: doesn't make sense to me either, but jungleboyj_ posted it
16:40:49 <rhe00_> DuncanT: +1
16:41:02 <AlkaD> +1
16:41:03 <hemna> for Kilo, we'll have several things we need to get in for our drivers now that some new stuff landed in J.
16:41:05 <jungleboyj_> jgriffith: No, just wanted to make sure the expected dates are documented.
16:41:09 <jgriffith> DuncanT: agreed... still waiting for jungleboyj_ to say something
16:41:11 <jgriffith> ahhh
16:41:18 <hemna> existing drivers should always be allowed to update to support cinder features IMO.
16:41:28 <jungleboyj_> So, K3 for new driver features being proposed still?
16:41:28 <AlkaD> +1
16:41:31 <jgriffith> jungleboyj_: well that's not an expectation, and I fear now it will just cause confusion :(
16:41:35 <xyang1> hemna: +1
16:41:38 <mtanino> DuncanT: +1
16:41:47 <DuncanT> hemna: Not necessarily after feature freeze - testing and stabilisation takes time
16:41:55 <eharney> jungleboyj_: i think so, because some driver features are fairly small and there isn't really a reason to block them as a whole
16:41:59 <hemna> DuncanT, sure that goes w/o saying I thinks.
16:42:02 <thingee> DuncanT, jgriffith: can we get an etherpad list of the drivers to still review through for this release?
16:42:07 <jgriffith> jungleboyj_: I don't think we need more beuarocracy
16:42:15 <jgriffith> ie dates for *everything*
16:42:18 <avishay> i agree, drivers should be able to enable features
16:42:22 <hemna> thingee, I think it's only the scality driver now
16:42:24 <jgriffith> thingee: there's only 3
16:42:28 <hemna> thingee, X-IO is out
16:42:34 <jgriffith> thingee: SMB and Scality Block Driver
16:42:39 <jgriffith> SMB has two patches
16:42:40 <rhe00_> but you can still review it. :)
16:42:48 <jungleboyj_> jgriffith: Ok ... So, nothing that needs to be documented there.  Forget that I worried about it.
16:42:50 <jgriffith> rhe00_: yes... sorry :)
16:42:54 <jgriffith> jungleboyj_: :)
16:42:59 <eharney> jungleboyj_: i think it's assumed to be part of the feature freeze
16:43:06 <jgriffith> the bigger question.....
16:43:07 <eharney> er never mind, read that wrong
16:43:08 <thingee> jgriffith: I reup'd the datera driver. no changes except rebase and regenerate config https://review.openstack.org/#/c/109481/11
16:43:08 <DuncanT> I think it might be worth making clear here that we mean no problem with drivers implementing their bit of existing cinder features
16:43:13 <jgriffith> #topic new features in Kilo
16:43:18 <jungleboyj_> eharney: jgriffith Thanks!
16:43:18 <DuncanT> Rather than crazy new features
16:43:26 <jgriffith> DuncanT: fair enough
16:43:43 <hemna> DuncanT, do you have the etherpad URL for the Kilo stabilization items?
16:43:49 <jgriffith> frankly if people want to optimize their drivers, add internal things etc that's fine by me
16:43:53 <jgriffith> make your driver better
16:44:08 <AlkaD> +1
16:44:10 <jgriffith> so there's different thoughts on Kilo
16:44:12 <hemna> we actually went through that list here and are trying to see how much we can contribute to them for Kilo.
16:44:17 <hemna> we might try and take on some of them.
16:44:18 <jgriffith> the question that have come up:
16:44:20 <DuncanT> https://etherpad.openstack.org/p/cinder-kilo-stabilisation-work
16:44:29 <hemna> DuncanT, thanks
16:44:33 <jgriffith> 1. Should we just cease introducing ANY new features in Kilo
16:44:49 <jgriffith> 2. Should we allow limited new features, and if so up until what milestone?
16:45:06 <DuncanT> -1 on no new features at all, things like differential backup I want ot see in
16:45:10 <jgriffith> 3. If we do a 'stability' release like this, willl people actually participate/contribute?
16:45:20 <DuncanT> No new features that don't have PoC code before the summit?
16:45:32 <hemna> 3. YES!  :)
16:45:41 <jgriffith> hemna: I know you will :)
16:45:45 <jgriffith> Ok...
16:45:52 <jgriffith> so I don't like option 1 myself
16:45:54 <DuncanT> 3. Yes from us (the other bit of HP)
16:46:00 <jgriffith> I prefer option 2
16:46:09 <hemna> jgriffith, +2 on 2.
16:46:15 <jgriffith> 3 will take care of itself so whatever
16:46:16 <kmartin> I like #2
16:46:35 <xyang1> #2 is good.  We just need to come up with a date
16:46:37 <jgriffith> I don't know how I feeel about the no new features that don't have POC code at summit
16:46:40 <jungleboyj_> jgriffith: +2 seems reasonable?  Do we set K1 again?
16:46:52 <kmartin> that came out wron=g :)  I prefer option 2
16:46:55 <jgriffith> I DO say no summit sessions for features without POC code
16:47:08 <jungleboyj_> kmartin: Thanks, I needed a laugh!
16:47:18 <jgriffith> As far as cutting off features....
16:47:19 <rushiagr> +1 for #2
16:47:30 <avishay> jgriffith: sounds good to me, and any new feature should comply with the stabalization code - no submitting code that needs immediate cleanup
16:47:33 <jgriffith> First, I'd like to be VERY picky and selective about features
16:47:42 <jgriffith> avishay: +1
16:47:45 <hemna> kmartin, #1 go take a #2
16:47:48 <DuncanT> avishay: +
16:48:09 <jungleboyj_> Who does #2 work for?
16:48:12 <jgriffith> I'd propose that we're very picky about any new features being proposed.  There needs to be a very clear benefit and win for Cinder
16:48:24 <kmartin> end of K2, and they must be merged by then not just submitted
16:48:29 <jgriffith> and not just "vendor xyz would like to support abc"
16:48:39 <hemna> yah
16:48:46 <jgriffith> kmartin: I think that seems reasonable
16:48:59 <DuncanT> The only feature I want to see is differential backup, and that should be merged before K1 hopefully
16:49:05 <jgriffith> That gives an entire milestone for testing and stability improvements
16:49:09 <hemna> I things like multi-attach are a bit tricky, because it involves nova more than anything.
16:49:20 <jgriffith> DuncanT: I know I know.. you want differential backups :)
16:49:24 <jungleboyj_> kmartin: +2
16:49:24 <hemna> but I like the by K2 target.
16:49:39 <Murali__> I am with Duncan :)
16:49:47 <jgriffith> does anybody disagree with limited features and cut off being K2?
16:49:55 <jgriffith> Murali__: I'm with both of you :)
16:50:05 <eharney> i'm wary it will get in the way of smaller things that could go into K-3 without much issue
16:50:42 <eharney> for large cinder-wide features, sure
16:50:48 <jgriffith> eharney: valid point
16:50:59 <thingee> eharney: +1
16:50:59 <DuncanT> eharney: We want it to get in the way - we want to push people towards working on testing, stabilisation, correctness, docs etc
16:51:03 <jgriffith> so here's the thing... for me at least; I'm not a fan of strict black and white rules
16:51:09 <jgriffith> I'm thinking more of guidelines here
16:51:15 <eharney> DuncanT: it's not really obvious to me that will be the outcome
16:51:25 <eharney> DuncanT: people may just work on their features shooting for M-1 instead
16:51:26 <bswartz> rules are made to be broken
16:51:31 <hemna> jgriffith, +1 there should be a case by case exception if possible.
16:51:34 <jgriffith> I think that introducing rigid rules causes more harm than good
16:51:35 <hemna> or we'll turn into nova.
16:51:38 <eharney> er, L-1
16:51:41 <hemna> the project of no.
16:51:48 <smcginnis> jgriffith: +1
16:51:52 <eharney> hemna: agreed
16:51:55 <DuncanT> eharney: That is always a risk, hopefully their feature will be better tested by then at the least
16:51:56 <jgriffith> Ok, so let's call these things "Guidelines"
16:52:02 <jgriffith> and "Goals"
16:52:15 <DuncanT> hema: +1
16:52:17 <jgriffith> Guidelines:
16:52:25 <jgriffith> 1. New drivers submitted by K1
16:52:39 <jgriffith> 2. New features are limited and ideally merged by K2
16:53:00 <jgriffith> 3. K3 is dedicated to stability and bug fixing
16:53:13 <avishay> 2. ...and POC at summit ?
16:53:20 <jgriffith> 4. or course item 3 applies to all milestones
16:53:41 <eharney> if a new feature lands in K-2 that involves driver enablement, we might want K-3 to get it supported in drivers...
16:53:42 <jgriffith> 5. POC required for any summit session related to new features
16:53:42 <DuncanT> PoC at summit for all summit sessions?
16:53:59 <jgriffith> eharney: yeah, that's always a "special" case IMO
16:54:00 <kmartin> why do we have two #2's ?
16:54:10 <jgriffith> kmartin: because avishay added another one :)
16:54:14 <eharney> jgriffith: yeah but we have to write these special cases down if we're going to list all these guidelines :)
16:54:15 <kmartin> :)
16:54:19 <avishay> :)
16:54:22 <eharney> otherwise nobody can figure out what's going on
16:54:24 <jgriffith> eharney: agreed
16:54:35 <hemna> kmartin, didn't you know that 2 was after 2 and before 3?
16:54:41 <hemna> :P
16:54:44 <kmartin> I like the guidelines they are clear and to the point, +1
16:54:57 <hemna> jgriffith, yah awesome job.   +2!
16:54:58 <avishay> sounds good to me
16:54:59 <jgriffith> Ok, everybody good with those 5 items as guidelines for Kilo?
16:55:06 <jgriffith> anything that should be added?
16:55:07 <DuncanT> +1
16:55:10 <xyang1> sounds good
16:55:11 <e0ne> +1
16:55:14 <jungleboyj_> jgriffith: +2
16:55:18 <thingee> +1
16:55:22 <jgriffith> #action jgriffith to add these guidelines to the wiki page
16:55:29 <avishay> jgriffith: and ML?
16:55:40 <xyang1> jgriffith: what is the requirement for CI on the drivers?
16:55:49 <avishay> gotta run, bye all
16:55:53 <jgriffith> avishay: DuncanT already stated he took an action item to post to ML
16:55:58 <jgriffith> I'll leave that one to him
16:56:10 <DuncanT> Not a problem
16:56:10 <jgriffith> xyang1: I'm glad you asked :)
16:56:23 <jgriffith> #topic third party CI
16:56:32 <eharney> yes please make sure that thoughts on CI in Kilo get written down somewhere solid as well
16:56:37 * DuncanT is highly disappointed no to see more systems posting by now
16:56:52 <jgriffith> so first let's talk about the rest of Juno
16:57:15 <jgriffith> I still expect to see people getting this up and running before we close out
16:57:49 <jgriffith> If you remember I had different views on this at the summit
16:58:02 <jgriffith> but the bottom line is what we have sucks
16:58:07 <jgriffith> all the way around
16:58:31 <jgriffith> and I'm sorry, not to offend anybody, but putting up somethign that doesn't work is worse than not putting something up at all
16:58:48 <jgriffith> this whole approach isn't working for me quite frankly
16:58:50 <kmartin> jgriffith: now the FC passthough is working we can focus on stability, no more excuses for us
16:59:03 <smcginnis> jgriffith: I think part of the problem is not having a good clear direction on HOW to set up the CI.
16:59:07 <jgriffith> kmartin: but my point is and has been... you shouldn't be voting if you're not stable
16:59:17 <jgriffith> and if your system doesn't publish results
16:59:38 <rhe00_> wouldn't it be possible to "clone" an environment that works instead of having every single vendor go through all the gotchas on their own?  a VM or something?
16:59:39 <jgriffith> I've had a CI system running for weeks, but I'm not voting because I was having intermittent failures
16:59:48 <jgriffith> rhe00_: there are LOTS of options
16:59:57 <jgriffith> rhe00_: DuncanT has his KISS_CI
16:59:58 <hemna> I don't think anyone has 3rd party CI voting yet?
17:00:05 <jgriffith> rhe00_: I have my version of it using ansible
17:00:13 <jgriffith> asselin__: has Jenkins
17:00:25 <jgriffith> xyang1: has Jenkins as well
17:00:56 <hemna> I think it might help if we posted a wiki/blog about setups for the different approaches.
17:01:01 <jgriffith> Bottom line is with the exception of a few most have just ignored third party CI requirements
17:01:09 <jgriffith> hemna: fair enough
17:01:29 <hemna> jgriffith, time
17:01:30 <tjones> hi guys - almost done?
17:01:32 <jgriffith> hemna: I'll write up mine this week and get it published to my blog and share it
17:01:42 <jgriffith> Ok... let's head over to cinder channel
17:01:46 <jgriffith> #endmeeting cinder