16:00:19 #startmeeting Cinder 16:00:19 Meeting started Wed Nov 11 16:00:19 2015 UTC and is due to finish in 60 minutes. The chair is smcginnis. Information about MeetBot at http://wiki.debian.org/MeetBot. 16:00:21 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 16:00:23 The meeting name has been set to 'cinder' 16:00:28 o/ 16:00:31 hi 16:00:33 * DuncanT waves 16:00:35 hi 16:00:35 Hello :) 16:00:39 Hello! 16:00:40 hi 16:00:42 hi 16:00:42 Hi 16:00:50 hi 16:01:00 hi 16:01:17 hi 16:01:24 Hey everyone. 16:01:27 Hello! 16:01:31 hi 16:01:42 #link https://wiki.openstack.org/wiki/CinderMeetings#Next_meeting 16:01:43 No announcements. Let's get right to it. 16:01:43 0/ 16:01:49 #topic cinder-api-microversions 16:01:53 scottda: Hey 16:01:57 hi 16:02:15 Xing pointed out some things about API microversions spec 16:02:17 https://review.openstack.org/#/c/223803/9 16:02:25 That were encountered by Manila 16:02:36 1) API extensions cannot be versioned 16:02:51 Manila moved API extensions into core so they can be versioned 16:03:14 I'd like to but something in the spec for this, but do the work separately. 16:03:14 If I remember right, there was some discussion at the kilo midcycle about pulling API extensions in to core. 16:03:26 smcginnis: Yes 16:03:39 IMO, I'm OK with moving excentions to core, but we need to take care about backward compatibility 16:03:47 I don't know if anyone wants to drive that? or if it is controversial? 16:03:54 scottda: And that's fine to do it as a follow up IMO. We only need them moved once we want to microversion them, right? 16:03:55 e0ne: +1 16:04:07 smcginnis: Yes. 16:04:11 * bswartz creeps in late 16:04:13 we must follow deprecation policy for APIs 16:04:16 smcginnis: Ideally, the otehr way round 16:04:24 bswartz: We see you! :) 16:04:31 DuncanT: How so? 16:04:37 e0ne: Or just redirect the URLs so that they keep working 16:04:52 DuncanT: I think that's what manila did.? 16:05:05 DuncanT: agree, it's a simple and usable solution 16:05:10 smcginnis: Ideally you want extensions (which in our case include very core stuff) in your initial API version 16:05:24 yeah in manila we moved our extensions to make them core APIs -- we used redirects to avoid breaking anything existing 16:05:42 So should this be done before/at_the_same_time/after api-microversions? 16:05:43 smcginnis: Otherwise, your first API contract isn't enough to actually use the service 16:05:46 bswartz: Did that need to be done before microversions were introduced? 16:05:54 bswartz: I thought I saw Valeriy just do that. 16:05:56 no, definitely after 16:06:11 scottda: before IMO 16:06:11 get microversions merged and working first, then tackle the extensions 16:06:15 haha 16:06:22 * jgriffith is apparantly wrong 16:06:30 that way you can microversion the extension rename 16:06:43 Isn't 2.0 our first API contract? So as it is now should be fine, then we need to redirect once we want to have a 2.1. 16:06:44 * DuncanT is with jgriffith 16:06:50 bswartz: i think we are moving all extentions to core first, after they are merged, rename and change microversion 16:06:55 bswartz: smcginnis I guess my thought was more of the "same time" 16:07:05 we force people who use newer microversions to call the new URLs paths -- if they use the old paths with a new microversion they get 404 16:07:30 bswartz: That makes sense to me. 16:07:30 it's our way of encouraging application writers to stay current with the API 16:07:36 +1 16:07:56 And if they use old paths with no microversion, everything works 16:08:11 of course anyone sticking with an older microversion (or no microversion at all) will not break 16:08:18 scottda: I thought that is why it would need to be after introducing microversions. 16:08:19 So, I think the move of API extensions can occur after microversions lands. 16:08:28 What do we do with API changes to extensions in the mean time (e.g. backing up snapshots)? 16:08:36 o/ Sorry I am late. 16:08:43 DuncanT: you wait for microversions to land 16:08:47 * smcginnis marks jungleboyj tardy 16:08:50 and then move the extensions 16:08:58 and then land backing up snapshots 16:09:08 scottda: that seems kinda risky... but I guess it forces the issue 16:09:13 scottda: no pressure 16:09:17 hehe 16:09:39 I'm seeing lots of reviews on API changes that say "this should come after microversions" anyway 16:09:43 which makes sense 16:09:55 So, let's land the spec and move to the code reviews.... 16:10:05 and thus this conversation. 16:10:08 actually I am not sure if it makes a difference, the extension does not have version now anyway 16:10:23 So, I'll update the spec to do extension move later, but probably soon.... 16:10:29 scottda: I am saying it doesn't have to wait 16:10:41 xyang1: That was what I thought. 16:10:44 OK, I *think* we are on the same page 16:10:55 issue #2: 16:11:11 Use of the microversion "latest" can cause problems, and did in Manila 16:11:18 #info Need to land microversions, then move extensions 16:11:33 But, I think we (and Nova) need "latest" to properly run Tempest tests... 16:11:39 scottda: that's not accurate 16:11:41 This was discussed at the Tokyo Summit 16:12:03 bswartz: OK, but you (Manila) do not have Tempest tests in-tree 16:12:07 scottda: bswartz isn't "no version" == latest ? 16:12:15 in my mail thread I stated that using microversion "latest" results in inherently undefined behaviour, and a user should never do it 16:12:25 however for nova, they needed it because their tests were out of tree 16:12:27 jgriffith: no 16:12:35 cinder may need it for a similar reason 16:12:43 jgriffith: no version = 2.0 16:12:43 jgriffith: "no version" is lowest supported version, i.e. 2.0 16:12:43 jgriffith: no version == oldest (aka 2.0) 16:12:50 "latest" makes sense as a hack to make tests work 16:12:52 latest is highest version 16:12:55 :) 16:13:06 bswartz: So the issue is "latest" is kind of a moving target? 16:13:06 But how can you write tests against an unknown version? 16:13:20 bswartz: Yes, so we need latest, and cannot do what Manila did because of Tempest, just like NOva 16:13:46 scottda: I'm not sure why the tests need 'lastest' 16:13:58 scottda: It is fundamentally an undefined target 16:14:18 "latest" means what it sounds like -- you don't know what you're going to get -- but when testing it can get you out of jail 16:14:57 the issue with keeping your tests in a separate git repo is that it's hard to add a new microversion and add tests for it at the same time 16:15:02 I'm not positive on why the Tempest team wants or needs "latest", it is either a "must have" or a "very hard not to have" 16:15:46 scottda: +1. why does tempes require "latest"? 16:15:51 Not to add more work and confusion - but wasn't there some talk of moving our tempest tests in-tree? 16:16:08 +1 for moving some tests in tree 16:16:13 smcginnis: that would only be "some", but not all 16:16:19 e0ne: I'll have to get the details...I don't recall right now. 16:16:31 smcginnis: perhaps the ones that are affected by "new/latest" makes sense 16:16:31 tests that only test cinder should absolutely be in tree -- tests that test integration between cinder and other things should probably remain in tempest 16:16:35 mriedem: Do you know why Nova/cinder Tempest for microversions needs lates? 16:16:36 jgriffith: Ah, OK. So base level cinder functionality remains in tempest, then enhanced coverage in cinder? 16:16:38 You can as cinder what its latest supported version is, and surely tests need to target a known version? 16:16:41 jgriffith: +1 16:16:47 smcginnis: just an idea 16:16:55 jgriffith: One that makes sense. 16:16:59 lates? 16:17:13 microversion= "latest" 16:17:14 oh, latest 16:17:28 did tempest land the microversion testing yet? 16:17:35 i think tempest was going to test lower bound and latest 16:17:43 just so there is bounds testing 16:17:44 my thread on "latest" microversion: 16:17:46 #link http://lists.openstack.org/pipermail/openstack-dev/2015-August/073070.html 16:17:51 yeah i know about that 16:17:55 and we hit latest issues with novaclient 16:18:05 as in defaulting to latest for novaclient was a bad idea when the client didn't support latest 16:18:47 mriedem: Yes 16:18:54 to bounds checking 16:19:04 but it still seems like that's not going to work 16:19:14 in novaclient we cap the upper limit on what we know the client to support at that time 16:19:21 as the client adds new support, we raise that limit 16:19:27 i'd think tempest would have to do the same 16:19:28 And that works for Tempest testing? 16:19:41 b/c if nova renames an API in v2.20 and tempest isn't ready, it will explode 16:19:46 ok, I'll investigate further and update the spec when I'm certain of Tempest needs 16:19:48 i don't think tempest has nova microversion testing yet 16:19:56 k'inichi was working on it i tink 16:19:58 *think 16:20:01 mtreinish: ^ 16:20:02 mriedem: I don't think so either 16:20:04 scottda: not sure how else you would do it? I mean... why wouldn't your tests consume the API the same as your users? 16:20:08 But it is being worked on 16:20:24 jgriffith: useres aren't supposed to ask for 2.latest 16:20:28 I'll get some details and put them in the spec.... 16:20:32 they are support to opt-in to what they can handle 16:20:33 mriedem: no, that's my point 16:20:41 don't want to rathole on this further, agenda for today is long 16:20:42 ok, yeah 16:20:54 mriedem: IMO the tempest tests should just "work" as they do now, default to lowest version 16:20:56 nova specifically put in it's rest api docs that 2.latest is a thing but don't use it 16:21:08 mriedem: if tempest wants to test a new version (micro-version or whatever) that's explicit 16:21:19 yeah, i think that's the idea 16:21:21 mriedem: we don't do the "latest" strategy at all 16:21:35 test lower bound and 'interesting points' in between as sdague says 16:21:39 OK. Thanks, I'll verify the latest issue and update the spec 16:21:47 mriedem: yes.. that sounds right 16:21:48 Thanks. Ok to move on. 16:22:03 jgriffith: That makes sense to me. 16:22:10 scottda: OK, thanks! 16:22:11 jgriffith: +1. tempest should work in same way as other API clients 16:22:25 My parts should be quick, so the agenda isn't really as bad as it looks. 16:22:37 #topic Spec status 16:23:05 After being prodded several times by scottda, I've put up an etherpad to start tracking specs. :) 16:23:12 :) 16:23:15 This is something nova does regularly in their meetings. 16:23:34 So not much to it right now, but the idea is if we stick to it, it will help in the long run. 16:23:41 #link https://etherpad.openstack.org/p/mitaka-cinder-spec-review-tracking 16:23:57 #info Start tracking specs in etherpad. 16:24:17 There's also a link to all our open specs in the meeting agenda. 16:24:30 smcginnis: cool 16:24:37 It would be good to get those reviewed earlier in the cycle so we don't have a crunch at the end. 16:24:51 smcginnis: good idea, +2 16:24:53 So please do if you have the cycles. :) 16:25:06 #topic Bug Status 16:25:23 Another nova suggestion. And probably a good one to get visibility. 16:25:43 I'm working on some scripts to make this easier to get using some existing infra scripts. 16:25:58 But for now I've put a few numbers as of last night into the agenda. 16:26:14 Bottom line - we have a ton of bugs out there and they could probably use some attention. 16:26:26 smcginnis: what about to announce bug triage day on regular basis? 16:26:28 We have several that have been out there for quite some time. 16:26:44 e0ne: We can try. I do like the idea. 16:26:58 I think the last few times we've tried that it kind of fizzled. 16:27:02 But I would be up for it. 16:27:16 smcginnis: I can send e-mail like I did in the past 16:27:28 e0ne: +1 Awesome, that would be great. 16:27:30 sending e-mail costs almost nothing 16:27:49 I have a feeling a lot of them (especially from 2013) can probably just be closed at this point. 16:28:01 smcginnis, did you run the query to auto close bugs > then N years? 16:28:01 But it would be good to validate that. 16:28:09 kmartin: I did. 16:28:30 Anything that didn't have any activity older than 1-1-2015 I think I closed. 16:28:43 If there was activity (in-progress, etc) I left it alone. 16:29:07 I'm sure there was probably something in that set of bugs that is still legitimate, so a bit of a risk. 16:29:13 in-progress have to be cleaned too 16:29:42 But it seemed a little too unmanagable at 700+ open bugs, and if it was out there that long there's a good chance it either didn't matter or was fixed by other changes. 16:29:47 >2-3 month in-progress means it is not really in progress 16:29:49 e0ne: Yeah, probably. 16:29:58 hehe 16:29:59 I was being conservative to start. 16:30:22 (sorry, it's late, from the ping, but https://review.openstack.org/#/c/169126/ explains the testing strategy for microversions from tempest) 16:30:30 sdague: Thanks! 16:30:38 sdague: thanks 16:31:13 While we're on the topic, I'll also take this opportunity to state that changing comment text or refactoring code most likely is not a "bug". 16:31:32 So please don't file bugs just to close them with trivial patches. 16:31:38 smcginnis: +1 16:31:54 I think bugs are only valuable if they actually document an issue in the code that could affect someone. 16:32:06 ++ 16:32:14 and don't -1 to ask to file a such bug 16:32:17 smcginnis: refactoring a driver could be thousands of lines of code 16:32:21 +111 16:32:33 smcginnis: you sure you don't want to track that 16:32:45 xyang1: Then that sounds more like a bp to me. 16:32:51 smcginnis: yes 16:32:52 xyang1: A good refactor is a bunch of patches that move a bit each 16:32:59 xyang1: If the driver works before and the driver works after then there wasn't really a bug there. 16:33:08 But a bp would be good for tracking if it's significant. 16:33:15 xyang1: Multi-thousand line patches are not reviewable, so not acceptable IMO 16:33:23 DuncanT: No several thousand line code changes? :) 16:33:30 DuncanT: +1 16:33:32 :) 16:33:42 Only with donuts. :) 16:33:57 only removig several thousand LoC is good:) 16:34:05 e0ne: Yes! 16:34:09 :) 16:34:18 e0ne: rm -rf cinder; git commit -am "All bug removed" 16:34:30 DuncanT: only very few features left, too. 16:34:33 DuncanT: Some may upvote that. ;) 16:34:34 refactoring means thousands are removed and thousand are added 16:34:37 DuncanT: -1, please add Closes-Bug 16:34:38 * bswartz points out that simply renaming a file with 500 lines counts as a 1000 line patch 16:34:54 bswartz: depends on your git config. 16:34:55 Coffee and donuts. Right xyang1 ? 16:34:57 bs+1 16:35:07 Anyway... 16:35:08 jungleboyj: yes, if it works:) 16:35:12 #topic Go forward with use-cinder-without-nova blueprint 16:35:15 e0ne: Hi 16:35:21 hi 16:35:46 bswartz: sorry, I mean your comment 16:35:47 #link https://review.openstack.org/#/c/224124/ 16:35:56 I want to contibue our session at Summit and deside that we are on the same page 16:36:37 and, of course get more and more feedback on it 16:37:11 the main question is 16:37:31 what should we as community do to make it a part of cinder? 16:38:18 it==python-brickclient 16:38:44 Sorry, I have it in my list to get back to. 16:38:49 IMO yes, it needs to make it into gate eventually, or it /will/ break 16:38:58 It looked like it was on the right track last time I looked. 16:39:04 DuncanT: Agree 16:39:05 Even none-voting is better than nothing 16:39:27 DuncanT: that's why we need to move it from my github to openstack 16:39:45 e0ne: +1 16:40:14 DuncanT: because even if it will have tests, w/o it's nothing 16:40:32 Anyone against having this added as an offical project? 16:40:40 not me:) 16:40:45 e0ne: ;) 16:40:52 https://review.openstack.org/#/c/243080/ - Add python-brickclient to OpenStack 16:41:18 #link https://review.openstack.org/#/c/243080/ 16:41:26 Any concerns, vote there. ^^ 16:41:54 jgriffith has a consern about it 16:41:58 a sub-project under cinder? 16:42:05 xyang1: yes 16:42:13 Like python-cinderclient. 16:42:15 e0ne: ++ 16:42:23 e0ne: yeah, maybe I'm missing something 16:42:51 e0ne: not following exactly why we'd do that... instead of having say cinderclient consume brick as a lib (like libs usually work) 16:42:52 we can do it inside cinderclient, but I don's want to confuse anyone more with one more 'attach' api. 16:43:03 even if it will have other binary name 16:43:11 e0ne: ahh... yeah, that makes sense 16:43:14 e0ne: but 16:43:17 e0ne: +1 16:43:17 I think the discussion was to have a separate client to avoid confusion. 16:43:24 e0ne: why couldn't we just have a config option and do that? 16:43:39 e0ne: so use the same method we have today to talk with Cinder and get things like policy etc? 16:43:45 jgriffith: I'm not fun of config for clients 16:43:59 e0ne: that way that command never even shows up if it's not enabled via policy 16:44:25 e0ne: well it doesn't have to be config 16:44:34 jgriffith: Could you explain a little how that works? 16:44:55 jgriffith: how can we handle optional requirements for cinderclient? 16:44:58 e0ne: but honestly that seems WAYYY better to me than building all the framework for a brick client when brick was supposedly just a lib 16:45:18 e0ne: smcginnis if you have it disabled in policy file it won't be exposed IIRC 16:45:29 e0ne: smcginnis I can look into that 16:45:34 jgriffith: But it uses the same calls as nova.... 16:45:54 DuncanT: those are compute-extensions, we don't expose them currently 16:45:59 I do like the idea of not duplicating code to have a separate client. 16:46:06 DuncanT: if you do a "cinder help" you don't see them currently 16:46:09 DuncanT, jgriffith: keystone trusts could help us for this 16:47:28 smcginnis: You do like duplicating code? 16:47:51 jungleboyj: NOT duplicating code! :P 16:47:58 +1 16:48:01 "cinder attach" via CLI and python API will be different 16:48:17 it's a not user friendly at all 16:48:22 smcginnis: :-) Just making sure. 16:48:27 openstack-baseclient? :) 16:48:46 smcginnis: Oh, you did have a 'not' in there. My bad. 16:48:50 * jungleboyj can't read today 16:49:12 IMO, code duplication is the other issue wich should be fixed separatly 16:49:20 jungleboyj: http://www.zennioptical.com/ 16:49:32 jungleboyj: :) 16:49:52 info: we've got only 5 minutes more for this topic 16:49:55 or less 16:50:20 My 2 cents - I think we need this functionality. We just shouldn't impose confusion or difficulty for our "main" cinder consumers. 16:50:30 smcginnis: agreed 16:50:40 smcginnis: +1 16:50:45 smcginnis: and IMO having multiple clients would do just that :) 16:50:53 If that means a separate client, great. If we have a clean way of doing it without a separate client - awesome. 16:50:57 smcginnis: +1 16:51:02 smcginnis: +1 16:51:04 smcginnis: so I have to use cinderclient to create etc 16:51:14 smcginnis: then jump over to this 'brick' thing to attach 16:51:23 blah 16:51:36 jgriffith: I think the idea was both pieces of functionality would be in the new client. 16:51:40 So there would be some overlap. 16:51:45 But I could be wrong. 16:52:00 smcginnis: so that's cool... but like I said in the review; that's probably the right answer but it should be in the cinderclient 16:52:04 smcginnis: not the other way around 16:52:20 at least I think so 16:52:21 anyway 16:52:28 I'll look again 16:52:32 jgriffith: Very fair point. 16:52:33 no need to take up time here 16:52:41 e0ne: Good enough for now? 16:52:45 yes 16:52:51 e0ne: Thanks! 16:53:03 #topic Mid-cycle survey results 16:53:08 Drumroll... 16:53:09 smcginnis: I'll wait your and jgriffith's comments in the review 16:53:28 DuncanT: How did things turn out? 16:53:43 Ok 16:53:47 paging DuncanT 16:54:11 Survey results were "Ok"? Not a detailed survey? 16:54:22 :) 16:54:27 25th - 29th won by a fair bit. 16:54:27 25th - 29th won by a fair bit. 16:54:27 :D 16:54:28 c'mon Drama King, out with it! 16:54:35 lol 16:54:36 Sorry, connection issues 16:54:46 DuncanT: OK, overlap with nova, but that's not a huge deal. 16:55:02 No air raids during Cinder meetings please. 16:55:10 LOL 16:56:03 DuncanT: Did we lose you again? 16:56:16 the silence is killing me 16:56:18 https://www.irccloud.com/pastebin/xv2c1tKP/ 16:56:24 He;s just building suspense. 16:56:25 From DuncanT ^^^ 16:56:40 I CAN'T TAKE IT! 16:56:44 https://www.irccloud.com/pastebin/3LpS8zyW/ 16:56:50 Dublin and Raleigh near neck -and -neck, but 15 couldn't make Dublin .v. 1 who 16:56:53 can't make the US. 16:57:03 Internet pastebin chat - IPC 16:57:36 sorry I missed the meeting. I forgot it was at 8am, not 9am. :( 16:57:45 tbarron: Does hosting still work for you? 16:57:46 That's all I've got from DuncanT ^^ 16:57:59 Thanks, Scott 16:58:12 DuncanT: Yay, he's back! 16:58:15 I think that covers it 16:58:34 DuncanT: So week of the 25th, Raleigh or Dublin, but Dublin would be a few less attendees? 16:58:40 Yup 16:58:46 then lets take Dublin ;) 16:58:51 15 less according to the servey 16:59:22 smcginnis: sure, 16:59:23 oh survey results ? 16:59:31 Dublin would be better in the summer than the winter IMO 16:59:37 bswartz: +1 16:59:39 * eharney forgot about the time change, hi everyone 16:59:41 bswartz: Yeah 16:59:52 eharney, you aren't the only one. 16:59:55 smcginnis: sorry, am doing two meetings at once 16:59:56 hemna: At least you beat eharney. ;) 17:00:02 out of time 17:00:02 smcginnis, yeah!!!! 17:00:10 My big take-out from this is that a non-US midcycle is probably coming, but best do that for summer, not now 17:00:14 Follow up later. 17:00:18 Thanks everyone. 17:00:22 DuncanT: ++ 17:00:24 #endmeeting