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