16:00:04 <thingee> #startmeeting Cinder
16:00:05 <openstack> Meeting started Wed Oct  8 16:00:04 2014 UTC and is due to finish in 60 minutes.  The chair is thingee. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:00:06 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:00:08 <openstack> The meeting name has been set to 'cinder'
16:00:18 * DuncanT- waves
16:00:21 <smcginnis> o/
16:00:23 <cknight> Hi
16:00:27 <patrickeast> hey
16:00:27 <thangp> o/
16:00:28 <scottda> hi
16:00:30 <xyang1> hi
16:00:32 <glenng> Hello!
16:00:35 <irina_pov> hi to all
16:00:39 <jungleboyj> \o/
16:00:47 <thingee> Agenda items for today https://wiki.openstack.org/wiki/CinderMeetings
16:01:04 <bswartz> .o/
16:01:07 <thingee> #topic thirdparty voting permissions
16:01:07 <eharney> hi
16:01:12 <thingee> patrickeast: you're up
16:01:37 <patrickeast> ok, so I wanted to discuss how we decide when to give voting permissions for CI’s and the process to do so
16:01:55 <patrickeast> the instructions for this on the wiki are pretty vague
16:02:08 <patrickeast> and i suspect i’m not the only one who will be wanted to do this
16:02:14 <patrickeast> wanting*
16:02:27 <jgriffith> patrickeast: actually I have no intention of doing it myself :)
16:02:30 <thingee> patrickeast: can you provide the link to the wiki page in question that's confusing?
16:02:33 <jgriffith> patrickeast: I see it as just noise
16:02:53 <bswartz> this sounds like question for infra...
16:03:03 <jungleboyj> jgriffith: I was also under the impression we wouldn't be doing that.
16:03:06 <jgriffith> bswartz: +1
16:03:09 <patrickeast> jgriffith: yea i was wondering about that
16:03:10 <smcginnis> jgriffith: Does voting add value?
16:03:11 <DuncanT-> bswartz: Infra asked us to come up witha n approvals process
16:03:13 <thingee> bswartz: +1
16:03:34 <patrickeast> bswartz: yep, but infra bounces me to cinder saying they wont do anything unless cinder core wants it
16:03:39 <clarkb> right
16:03:40 <jgriffith> patrickeast: DuncanT- :)
16:03:41 <patrickeast> thingee: one sec, pulling up the page
16:03:43 <DuncanT-> voting makes automated results extraction easier
16:03:44 <jgriffith> that makes sense
16:03:49 <xyang1> jungleboyj: I thought so too
16:03:50 <bswartz> IMO, step 1: get your system running consistently, step 2: have it comment on every patchset, step 3: ask for voting power
16:03:50 <clarkb> infra isn't around to police individual projects
16:03:58 <clarkb> we just want to know when to make those changes
16:04:02 <jgriffith> patrickeast: DuncanT- thingee how about an "incubation" period
16:04:09 <jgriffith> if we in fact want to do it that is
16:04:21 <jgriffith> so the idea would be something like stats over 1 month
16:04:21 <thingee> clarkb: +1 we should not expect infra to
16:04:32 <smcginnis> jgriffith: +1
16:04:32 <jgriffith> meet a certain criteria and then you can go voting if you like
16:04:44 <DuncanT-> Basically infra want us to have some sort of process for approving them, they won''t approve obviously wrong accounts (no logs, always fails, etc) but said we need to be the decider
16:04:45 <jgriffith> criteria being: % of succesful runs
16:04:49 <bswartz> well there are 2 questions here -- what are the technical requirements to get the CI system able to vote -- and what are the administrative requirements for the cinder team to allow a CI system to vote
16:05:03 <jgriffith> bswartz: I think for now there's just one question
16:05:10 <jgriffith> that being: what's the criteria
16:05:15 <bswartz> ok
16:05:22 <thingee> #idea infra should not expect to police every project
16:05:29 <smcginnis> Criteria 0: is voting necessary, desired?
16:05:32 <DuncanT-> jgriffith: Extracting the % success is hard if they aren't voting
16:05:48 <jgriffith> DuncanT-: maybe I'm confused on what people refer to as voting
16:06:05 <DuncanT-> jgriffith: Putting a score as well as a comment == voting
16:06:13 <bswartz> DuncanT-: they can "comment" +1 or -1 but it can be a non-voting +1 or -1
16:06:16 <patrickeast> thingee: sry for the delay, the instructions that i mentioned are here http://ci.openstack.org/third_party.html it basically just says email the openstack-dev list and fix any feedback
16:06:40 <xyang1> I think voting means a -1 will block a patch
16:06:53 * DuncanT- is now confused
16:06:58 <thingee> #link http://ci.openstack.org/third_party.html
16:07:23 <thingee> I agree with xyang1. non-voting means not voting.
16:07:25 <bswartz> the term "voting" doesn't seem to have a clear definiton
16:07:26 <jgriffith> DuncanT-: so my point was you gather stats based on comments
16:07:45 <eharney> xyang1: V-1 doesn't block the patch
16:07:46 <jgriffith> DuncanT-: measure percentage of commits you voted on
16:07:47 <bswartz> I think scoring is a better term
16:07:47 <DuncanT-> jgriffith: That is hard to do
16:07:53 <jgriffith> DuncanT-: how many passed and how many failed
16:08:11 <DuncanT-> jgriffith: I spent... several minutes on it, and couldn't do it with gerrit queries
16:08:17 <xyang1> eharney: are you sure?  a -1 from pylint will block the patch.  is this different?
16:08:26 <jgriffith> eharney: correct
16:08:28 <jgriffith> only -2
16:08:42 <jungleboyj> xyang1: There are the ones that also have (non-voting) listed though.
16:08:42 <DuncanT-> xyang1: Jenkins has extra magic flags
16:08:43 <eharney> xyang1: it only blocks because it turns into a V-2 later (or is never put in the gate queue)
16:08:54 <eharney> xyang1: V-1 from things other than Jenkins is just advisory
16:09:37 <xyang1> that's true, but usually a patch won't be approved with -1
16:10:00 <glenng> xyang1: +1
16:10:04 <patrickeast> so if that is the case, is it useful for driver CI’s to be voting?
16:10:09 <DuncanT-> xyang1: I ignore -1 from CIs quite often, particularly the CIs that -1 for no good reason
16:10:25 <hemna> don't most folks ignore -1's from CI ?
16:10:27 <hemna> :(
16:10:32 <smcginnis> patrickeast: +1
16:10:33 <xyang1> DuncanT-: that's good to know
16:10:34 <ameade> +1
16:10:39 * DuncanT- things it is useful for them to vote, since it is easy to do queries for how reliable the CI system is then
16:10:40 <jungleboyj> DuncanT-: +1
16:10:42 <thingee> the only people today that have really cared about the thirdparty ci's are infra and the people running the ci.
16:10:45 <thingee> if it
16:10:54 <thingee> s going to meaningful, I think it needs to be able to vote
16:11:30 <DuncanT-> Vote make searching /much/ easier, which is the first step in monitoring them, and therefore getting people to fix them
16:11:38 <bswartz> -1 should only be ignored if that CI has a history of inconsistent results
16:11:52 <smcginnis> If it makes it easier to query and extract info as DuncanT- says then I see value in the voting.
16:12:00 <bswartz> a good CI system returning a -1 shouldn't be ignored -- that's the whole point of having CI
16:12:15 <jgriffith> bswartz: are you currently reviewing patches and checking results of all the 3'rd party CI systems?
16:12:18 <DuncanT-> bswartz: Getting to the point where CI is mostly good is only just starting to happen
16:12:30 <thingee> does anyone have any disagreement with third party ci's having voting rights?
16:12:33 <DuncanT-> bswartz: In principle, you're absolutely correct
16:12:38 * jgriffith sees this as another case of run before you walk
16:12:47 <hemna> we need more stability from CI to make folks really take a look at -1s I think
16:12:48 <bswartz> not many patches, but I always look at the CI results
16:13:03 <thingee> hemna: I agree.
16:13:03 <jgriffith> bswartz: and what's your finding?
16:13:19 <jgriffith> bswartz: what's the number one failure reason for HP tests for example?
16:13:24 <jungleboyj> hemna: I totally agree.
16:13:26 <jgriffith> bswartz: since you look at them and all
16:13:28 <bswartz> my observation has been that they're flaky
16:13:32 <thingee> where I'm getting it at though to move forward, is anyone just completely against ci's having voting rights, even if we all agreed on a requirement to be met to prove stability?
16:13:34 <patrickeast> so with the goal of having reliable CI’s who’s -1 votes actually mean something, should we gate letting a CI vote until it has a certain level a credibility?
16:13:40 <jgriffith> bswartz: ha!  Well that's a good catch all
16:13:52 <bswartz> but when they're not flaky I take them more seriously
16:13:57 <smcginnis> patrickeast: +1
16:14:07 <jgriffith> thingee: I would probably be "ok" once we have criteria defined and it's proven
16:14:20 * DuncanT- intends to start chasing CI owners who disagree with jenkins frequently for no good reason
16:14:24 <jgriffith> thingee: although honestly I'm not sure I see the added value
16:14:28 <jungleboyj> thingee: I don't think I have a problem with that .  Agree with jgriffith
16:14:30 <DuncanT-> But I can only do that for CIs that vote
16:14:33 <jgriffith> comment works the same way IMO
16:14:57 <DuncanT-> jgriffith: Literally the only difference is it is easier to search with votes than comments
16:15:00 <jgriffith> I don't think we need to make all of this some sort of a witch hunt
16:15:08 <hemna> the CI system itself hasn't been stable, let alone the running of the tests against real backends.
16:15:11 <jgriffith> the idea was just to make the code better
16:15:16 <jgriffith> and make sure we test our driers
16:15:18 <jgriffith> drivers even
16:15:26 <hemna> so I think we just need more time and help get the CI system stable, and then the backends will become stable with time.
16:15:36 <DuncanT-> jgriffith: Not witch hunt, just a gentle poking and an invitation to make the issues into bugs where necessary
16:15:36 <hemna> cart/horse
16:15:45 <jungleboyj> hemna: +1
16:16:00 <smcginnis> So kilo just require CI's to comment, L enforce stability to have confidence in voting?
16:16:00 <jgriffith> DuncanT-: fair enough.. but my contention is that if I have a system I'm monitoring it
16:16:02 <thingee> jgriffith: +1
16:16:04 <thingee> hemna: +1
16:16:11 <jgriffith> and I should have enough self interest to file a defect if need be
16:16:19 <jgriffith> or fix it etc
16:16:39 <jgriffith> I don't need a police-man watching my system
16:16:50 <thingee> Ok, this is a good start. I would like to capture our thoughts here.
16:16:54 <DuncanT-> jgriffith: If you're monitoring it then hopefully you'll fix it before I notice, or respond to the poke with 'working on it', either of which is great
16:17:01 <jgriffith> Unless we want to use it as criteria to kick me out :)
16:17:12 <jgriffith> DuncanT-: understood.... agreed
16:17:12 <jungleboyj> :-)
16:17:20 <DuncanT-> jgriffith: Kick you out? Nah. Kick you? Maybe ;-)
16:17:30 <jgriffith> DuncanT-: :)
16:17:33 <hemna> we monitor ours pretty closely and have found issues that we've had to fix.
16:17:35 <jgriffith> Better have long legs :)
16:17:41 <glenng> LOL
16:17:42 <hemna> and also deal with the CI mechanism itself as well.
16:17:59 <thingee> patrickeast: I don't think we're going to have an answer yet. I would like to get further answers from some people on certain points. do you mind if I capture the thoughts here and revisit it next week?
16:18:00 <jgriffith> thingee: sorry... we're digressing; you wanted to capture thoughts
16:18:05 <hemna> I think we just need to relax a bit and churn on it and help stabilize CI itself.
16:18:08 <patrickeast> thingee: sounds good to me
16:18:13 <thingee> I will also give people time to comment on the points
16:18:17 <thingee> thanks everyone
16:18:21 <jungleboyj> DuncanT-: He he.  Wasn't going to go there.
16:18:59 <thingee> #action thingee will capture thoughts so things can be revisited next meeting
16:19:06 * DuncanT- suggests giving voting rights early and easily for now, makes monitoring easier
16:19:16 <thingee> #topic Introduce a nice way of accessing up-to-date information on Cinder drivers
16:19:22 <thingee> irina_pov: you're up
16:19:42 <irina_pov> Hi guys! so, I've got an idea for those who maintain drivers
16:20:18 <Swanson> Is it providing documentation?
16:20:23 <navneet> irina_pov: is it about versioning  scheme...
16:20:36 <irina_pov> No, I'm speaking about driverlog and openstack marketplace
16:20:59 <DuncanT-> irina_pov: What are you trying to achieve?
16:21:04 <irina_pov> information on drivers is kept in a json file, so it's easy to update it when necessary
16:21:22 <DuncanT-> irina_pov: What information?
16:21:32 <mkoderer> irina_pov: do you have some examples?
16:21:34 <irina_pov> on drivers and on maintainers
16:21:35 <navneet> irina_pov: not getting you
16:21:43 <hemna> ?
16:21:43 <thingee> irina_pov: this is a bit vague. do you have code, or wiki page to provide us more information?
16:21:43 <mkoderer> btw hello everybody ;)
16:21:51 <thingee> mkoderer: hey :)
16:21:56 <irina_pov> for instance, there's some information on driver, but it's out-of-date
16:22:08 <irina_pov> so, none can contact the maintainer
16:22:12 <irina_pov> that's the point
16:22:17 <jgriffith> https://wiki.openstack.org/wiki/File:Png;base64726103ed8c60adf5.png
16:22:19 <navneet> irina_pov: vendor driver ---mapped to---> maintainer
16:22:33 <DuncanT-> irina_pov: So there's a proposed maintainers file in the cinder git tree
16:22:41 <winston-d> IIRC, jaypipes mentioned similar idea once on ML
16:22:43 <jgriffith> sorry... meant this: https://wiki.openstack.org/wiki/DriverLog
16:22:58 <thingee> #link https://wiki.openstack.org/wiki/DriverLog
16:23:03 <jgriffith> irina_pov: that's what you're referring to correct?
16:23:13 <smcginnis> DuncanT-: Any progress on having something automatically extract driver maintainers?
16:23:19 <irina_pov> I want maintainers to update the information
16:23:20 <jgriffith> irina_pov: I have issues with this whole concept FWIW
16:23:31 <hemna> irina_pov, http://stackalytics.com/driverlog/?project_id=openstack%2Fcinder&vendor=HP&release_id=
16:23:34 <kmartin> same info as #link http://stackalytics.com/driverlog/
16:23:37 <jgriffith> IMO rather than voting in CI we should be automating publishing to this
16:23:42 <hemna> are you referring to the info that renders that page ?
16:23:45 <navneet> seems like support matrix
16:23:50 <DuncanT-> smcginnis: That turns out to be infeasible - I might be able to do something where you can't submit a driver withotu a maintainer though
16:24:00 <smcginnis> DuncanT-: +1
16:24:03 <thingee> #link https://review.openstack.org/#/c/116887/
16:24:18 <thingee> DuncanT-'s review for maintainers file ^
16:24:41 <DuncanT-> irina_pov: As far as feature matrix, that should be automatically extractable once we do the ABC change that we just approved a spec for
16:25:05 <clarkb> DuncanT-: thingee: I think anteaya would like to see that info on the wiki
16:25:12 <clarkb> so that it doesn't have to go through code review to be updated
16:25:49 <DuncanT-> wikis are terrible for such info, they either get forgotten or somebody claims maintainership off somebody else and caused a fight
16:26:05 <irina_pov> the idea is just to put changes into the json file...without wikis and emails
16:26:12 <e0ne> DuncanT-: agree
16:26:13 <clarkb> DuncanT-: your code base is no better...
16:26:16 <DuncanT-> We've dozens of out of date wiki pages already
16:26:22 <thingee> DuncanT-: that's fair, but I think it's also fair that our dev docs in the repo got forgotten
16:26:26 <clarkb> except the barrier to updating a file in a repo is much higher
16:26:28 <irina_pov> marketplace and driverlog are set up from the same json
16:26:33 <navneet> DuncanT-: why not have a cinder standard driver versioning scheme for support matrix?
16:27:02 <jgriffith> irina_pov: FWIW I have no problem with updating that as you suggest
16:27:05 <DuncanT-> navneet: Because it is a bitmask, not a progressive scheme, and ABCs are a much clearer way of expressing that in code
16:27:17 <jgriffith> irina_pov: my only question is are we infact making driver-log the one version of truth?
16:27:30 <jgriffith> irina_pov: I wasn't aware that had been decided, but if it has fair enough
16:27:41 <irina_pov> driverlog and marketplace are the same
16:27:55 <irina_pov> the same sources of information
16:28:03 <irina_pov> not the single ones
16:28:12 <navneet> DuncanT-: how do you expect customer to get the info by running an api and not referring a wiki or similar?
16:28:15 <jgriffith> irina_pov: well that's part of the problem IMO
16:28:23 <xyang1> irina_pov: I thought there was a spreedsheet for market place, not exactly the same as driverlog
16:28:31 <jgriffith> need to have a single source of truth
16:28:37 <DuncanT-> navneet: We can generate a page automatically from the code
16:28:42 <irina_pov> as I know, both are made up from the same file
16:28:43 <mkoderer> navneet: if you have it in the code you could extract it
16:28:47 <DuncanT-> navneet: Manually updated wiki pages suck
16:28:56 <navneet> DuncanT-: agree
16:29:00 <irina_pov> marketplace just has no info on maintainers
16:29:05 <DuncanT-> We could extract most of the info that driverlog wants from the code actually
16:29:12 <irina_pov> so, my idea is to update the json when necessary
16:29:15 <navneet> DuncanT-: mkoderer do we have the code in place to extract such an info?
16:29:31 <DuncanT-> navneet: Not yet
16:29:33 <mkoderer> navneet: not yet
16:29:40 <anteaya> clarkb is right, this information needs to be on this page: https://wiki.openstack.org/wiki/ThirdPartySystems
16:29:52 <mkoderer> but we can do that after ABC bp is done
16:29:53 <anteaya> if you also want to have it in your repo, that is up to you
16:29:59 <navneet> DuncanT-: alright...we need to get one then
16:30:34 <navneet> irina_pov: is this what you are doing...having the extraction mechanism in place
16:30:40 <irina_pov> for now, if I want to get up-to-date info, I have to write to a maintainer
16:30:55 <thingee> DuncanT-: I feel like this is something we need to coordinate with the rest of the projects. Since infra is already working with different projects, we should probably continuing working with them.
16:31:11 <jungleboyj> thingee: Good point.
16:31:30 <navneet> thingee: +1
16:31:32 <thingee> i just don't want 3 projects having their source of truth here, and another four doing this, etc
16:31:33 <anteaya> it is in accordance with the requirements: http://ci.openstack.org/third_party.html#requirements
16:31:45 <anteaya> under publish contact information for maintainers
16:31:55 <DuncanT-> thingee: having a bot push update reviews into driverlog seems reasonable.... looks like it is well structured enough to be able to do so
16:32:21 <irina_pov> well, driverlog is quite Ok for posting an update as you can see the result quickly
16:32:40 <thingee> DuncanT-: overall though, I think we should all recognize the work you have originally driven with the gathering the maintainers info
16:33:22 <DuncanT-> thingee: I think having truth outside the cider tree will bitrot fast. No problem publishing the info via wiki/driverlog/etc though
16:33:22 * jungleboyj needs to switch to lurker mode.
16:33:37 <thingee> ok so I'm hearing drivelog and the infra wants wiki
16:33:42 <thingee> driverlog*
16:34:25 <DuncanT-> thingee: Manually maintained wiki pages are always going to suck, and in some cases we might be better suggesting better approaches to infra
16:34:43 <thingee> Then I think irina_pov should be working with infra on this.
16:34:49 <thingee> to improve that system
16:34:54 <DuncanT-> thingee: +1
16:34:56 <mkoderer> +1
16:35:01 <irina_pov> thingee, I'll take it up
16:35:29 <DuncanT-> irina_pov's json looks well structured, so doing programatic things with it looks eminently doable
16:35:38 <thingee> anteaya: is that fair? not needing a yes right now from infra, but a proposal?
16:36:02 <anteaya> we always welcome proposals
16:36:14 <anteaya> and welcome help from anyone in the third party space
16:36:14 <irina_pov> I've updated wiki on driverlog on how to update information, so it became even simplier to understand
16:36:18 <thingee> irina_pov: infra is already slammed as we all know, so this will be a bit of work for driverlog
16:36:21 <thingee> team
16:36:40 <anteaya> but be aware that any system not in compliance with the thrid party requirements can be turned off until they comply
16:36:51 <anteaya> and any member of infra can and may do so
16:37:04 <anteaya> so heads up if you choose not to recommend compliance
16:37:17 <anteaya> while the proposal is being presented and considered
16:37:29 <thingee> #agreed irina_pov will propose driver log to infra team
16:37:29 <anteaya> and irina_pov you are welcome to attend third party meetings
16:37:51 <anteaya> as well as infra meetings
16:37:54 <irina_pov> thank you, guys! I'll talk to infra
16:37:56 <thingee> #topic Oslo Project Liaison for Kilo Release
16:37:59 <thingee> irina_pov: thank you
16:38:19 <thingee> dhellmann sent a post to the ML about this http://www.mail-archive.com/openstack-dev@lists.openstack.org/msg37015.html
16:38:43 <thingee> first I would like to recognize DuncanT- for helping with juno release
16:39:12 <DuncanT-> Actually I was pretty poor at it, but never mind
16:39:32 <thingee> the signup for Kilo is available at https://wiki.openstack.org/wiki/CrossProjectLiaisons
16:39:41 <winston-d> thingee, DuncanT- what is the responsibility of Olso Liaison?
16:40:15 <DuncanT-> winston-d: Basically working with the oslo team to get graduated oslo projects into cinder
16:40:18 <thingee> winston-d: the wiki sign up page I just gave should have it
16:40:19 <thingee> https://wiki.openstack.org/wiki/CrossProjectLiaisons
16:40:28 <DuncanT-> winston-d: And generally keeping track of cinder <-> oslo interactions
16:40:32 <thingee> #link https://wiki.openstack.org/wiki/CrossProjectLiaisons
16:40:47 <mkoderer> winston-d: and it's a good idea to attend to their meetings, too
16:41:29 <thingee> ideally someone core should step up to this, but I would not be opposed to someone that is not part of core
16:41:35 <navneet> any pre requisite to sign up as liason?
16:41:37 <thingee> (there is a ML discussion on this particular topic)
16:42:24 <thingee> so just putting that out there.
16:42:43 <winston-d> when is Olso's weekly meeting?
16:43:06 <winston-d> nvmind, find it
16:43:07 <e0ne> DuncanT-: what kind of tracking? some projects (e.g. oslo.db) could be partically integrated
16:43:08 <mkoderer> https://wiki.openstack.org/wiki/Meetings/Oslo
16:43:09 <thingee> winston-d: 1600utc
16:43:31 <thingee> it would be great if someone can step up to this by friday.
16:43:52 <thingee> ok
16:44:09 <DuncanT-> e0ne: It is about knowing exactly that kind of detail ;-) There's no formal tracking at the moment, but when a new graduation comes up, knowing if it is in use or if we should use it
16:44:30 <thingee> #topic cinder stabilization
16:44:32 <e0ne> thingee: i could do it for a part of oslo.db. i started wortking on migrating migrratins tests today
16:44:45 <thingee> who put this up?
16:44:56 <thingee> #link https://etherpad.openstack.org/p/cinder-kilo-stabilisation-work
16:45:29 <hemna> that was me
16:45:31 <hemna> my bad
16:45:34 <thingee> hemna: you're up :)
16:45:48 <hemna> we hadn't gone through that list yet
16:46:14 <hemna> so I was wondering if that list is still worth keeping and looking at?   Are folks picking up any of those
16:46:21 <smcginnis> Review link doesn't work for me.
16:46:23 <hemna> are folks creating cinder-specs associated with them?
16:47:09 * DuncanT- is still bashing away at state machines. They definitely don't align well with the current taskflow tasks is my only feedback so far
16:47:22 <e0ne> hemna: i'm working on some items from list:)
16:47:29 <hemna> we had talked at the mid summit meetup at the possibility of making Kilo a stabilization release.
16:47:31 <thingee> hemna: I'm still getting a bit organized with things. I think I will have a better picture of things next week
16:47:38 <hemna> ok
16:48:04 <hemna> I guess if folks are actively working on any one of those items, to put your name next to it and/or put a link to the cinder-specs url ?
16:48:07 <thingee> but I do encourage people to look at that list and step up to something of interest that you can see through the end of the release.
16:48:22 <xyang1> hemna: there are  a couple of patches already up for the state management
16:48:29 <hemna> I know we have a cinder-spec for the ABC stuff
16:48:29 <mkoderer> hemna: should we put links to the blueprints in that etherpad?
16:48:35 <thingee> xyang1: that's true.
16:48:49 <e0ne> mkoderer: yes
16:48:56 <mkoderer> I'll do that for ABC
16:49:01 <e0ne> mkoderer: or links to the review requests
16:49:09 <hemna> mkoderer, coolio thanks
16:49:10 <thingee> So I don't want to get into state machine stuff here. But I will say that I have one proposal coming to me that's complete. That does not mean it's going to be it, but it's something more complete than anything else I've gotten
16:49:22 <hemna> thingee, awesome.
16:49:36 <hemna> I would love to see that get in for K
16:49:56 <thingee> if anyone opposes the patches up for state machine starter stuff with taskflow, please provide feed back
16:50:37 <thingee> #action thingee will have a better idea next week of who is working on what and what we still need help with
16:50:54 <thingee> #topic Kilo release specs
16:51:00 <thingee> #link https://review.openstack.org/#/q/project:+openstack/cinder-specs+status:+open+label:Verified%253E%253D1%252Cjenkins+NOT+label:Code-Review%252Cself,n,z
16:51:19 <thingee> this gerrit link should only show the specs that pass jenkins and haven't been reviewed by you
16:51:28 <thingee> use it please and provide the rest of the community with your feedback
16:51:35 <hemna> Code Review - Error
16:51:44 <thingee> hemna: are you logged in?
16:51:47 <hemna> nope
16:51:49 <hemna> heh
16:51:50 <hemna> sorry
16:51:54 <smcginnis> hemna: I get that in chrome but not ff
16:51:55 <DuncanT-> thingee: That shows me things I've already +2d
16:51:59 <thingee> oh yeah, so that link will error if you're not logged in
16:52:03 <thingee> otherwise it doesn't know who self is
16:52:23 <thingee> DuncanT-: oh heh, I'll improve it and send it to the room
16:52:34 <thingee> room being #openstack-cinder
16:53:00 <DuncanT-> thingee: Cheers. I still suck at bending gerrit search to my will
16:53:14 <thingee> but just encouraging people to discuss the specs that are up now. We also need to clean up ones that are stale.
16:53:36 <hemna> ok sounds good.  I'll take a pass at em.
16:53:38 <thingee> I'll be doing a great deal myself this week, so also please get your blueprints up now.
16:53:50 <DuncanT-> Do we want to auto-expire old specs that don't respond to feedback?
16:54:13 <thingee> I don't think we need to discuss every spec that comes in, but certainly people mention in the comments if you think this too complicated that it should be brought up in the next meeting.
16:54:25 <thingee> it would be up to the spec author to propose the agenda item and be there
16:55:00 <hemna> +1
16:55:40 <thingee> #topic anything else?
16:55:48 <glenng> NFS Security
16:55:49 <e0ne> it will be good to anounce it in openstack-dev
16:56:09 <thingee> glenng: heh ok 4 mins
16:56:33 <glenng> I am working on Rushi's comments now and wish to know if we can get some focus on https://review.openstack.org/#/c/107693/.
16:56:47 <eharney> does it gracefully handle upgrades now?
16:56:48 <glenng> It has been going on sine July 17th.
16:56:56 <glenng> YES, new option added
16:57:13 <eharney> i'll look at it when i get a chance
16:57:24 <glenng> Am hoping for any other feedback for last set of changes ;-)
16:57:44 <thingee> #link https://review.openstack.org/#/c/107693/
16:57:48 <glenng> Would like to close off on this very important change. Does anyone else have concerns?
16:58:25 <thingee> #action community should provide feedback on nfs security enhancement patch
16:58:35 <glenng> Thanks everyone!
16:58:40 <thingee> thanks glenng
16:58:46 <thingee> 2 more mins anything else?
16:58:51 <glenng> *feels better now*
16:58:57 <cknight> thingee: quick question: fibrechannel drivers are coming for NetApp arrays.  Is there a hard requirement to have CI in place to submit new derivative drivers?
16:59:35 <thingee> I'm going to be working with DuncanT- on this since he has a strong opinion with this and anyone else that wants to be part of it.
16:59:57 <thingee> my initial thoughts though, we can force people, but things aren't going to be successful unless we have the tools for people to be able to do it
17:00:03 <cknight> thingee: OK, thanks.  I'm glad to participate in that conversation.
17:00:06 <thingee> that's all!
17:00:08 <thingee> #endmeeting