15:59:48 <jgriffith> #startmeeting cinder 15:59:49 <openstack> Meeting started Wed Aug 26 15:59:48 2015 UTC and is due to finish in 60 minutes. The chair is jgriffith. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:59:50 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 15:59:50 <eharney> hi 15:59:51 <patrickeast> Hi 15:59:51 <rajinir> hi 15:59:52 <openstack> The meeting name has been set to 'cinder' 15:59:52 <rhe00> hi 15:59:54 <geguileo> Hi 15:59:54 <jgriffith> Hey everyone 15:59:54 <Swanson> Hello. 15:59:55 <smcginnis> o/ 15:59:55 <vincent_hou> Hi 15:59:56 <tbarron> hi 15:59:56 <thangp> o/ 16:00:01 <mtanino_> o/ 16:00:02 <dulek> o/ 16:00:03 <wilson2> hi 16:00:07 <winston-d> o/ 16:00:09 <jgriffith> We have an agenda this week posted here: https://wiki.openstack.org/wiki/CinderMeetings 16:00:10 <xyang> hi 16:00:14 <hemna> boink 16:00:15 <scottda> hi 16:00:16 <e0ne> hi 16:00:23 <tim_o> hi 16:00:24 <jgriffith> A lot to go through so let's take a run at it... 16:00:28 <dannywilson> hi 16:00:30 <jgriffith> mtanino_: ready? 16:00:34 <mtanino_> yup 16:00:41 <mtanino_> Get Volume Driver Capabilities patch (mtanino) 16:00:41 <jgriffith> #topic Get driver capabilities 16:00:48 <breitz> hi 16:00:49 <mtanino_> Hi, about Get Volume Driver Capabilities patch, 16:00:58 <mtanino_> I'd like to have opinions for naming policy of propoerties. 16:01:10 <smcginnis> mtanino_: I'd rather not use vendor_name. 16:01:15 <mtanino_> In this feature, we have two types of properties, "cinder well defined keys" and "vendor unique properties". 16:01:22 <smcginnis> Especially given there are names and punctuation. 16:01:30 <smcginnis> /names/spaces/ 16:01:47 <cebruns> Hi 16:01:48 <hemna> I didn't think we were removing scoped keys as part of this effort ? 16:01:50 <mtanino_> so Gorka's proposal is Use `vendor_name` in volume_stats OR use anything the driver wants as a prefix. 16:02:09 <smcginnis> mtanino_: My vote would be it is up to the driver what they want to use. 16:02:20 <hemna> if you remove the scoping, then the capabilities filter is going to use those values to match 16:02:31 <geguileo> smcginnis: But they could be sending vendor_name 16:02:59 <jgriffith> let's back up a second... I might be lost :) 16:03:00 <smcginnis> geguileo: Sure, if they want. But I wouldn't want to make it a requirement that it has to match vendor_name. 16:03:22 <geguileo> smcginnis: Ok, do we have any specific requirements for those values or anything goes? 16:03:29 <jgriffith> geguileo: mtanino_ first let's talk about replacing colon's 16:03:41 <mtanino_> jgriffith: I see. 16:03:46 <geguileo> smcginnis: Because we must be able to remove the scoping like hemna said 16:04:06 <jgriffith> geguileo: mtanino_ depending on what you're proposing that's a scoped key and we need that to bypass scheduler 16:04:14 <mtanino_> so currently, separate is "_", but I think colon is reasonable separator for the prefix 16:04:30 <geguileo> Original proposal in Kilo used : 16:04:33 <mtanino_> like Hitachi:minIOPS, Hewlett-Packard:minIOPS or hp3par:minIOPS, SolidFire Inc:minIOPS or SolidFire:minIOPS 16:04:38 <jgriffith> mtanino_: Ok, I see what you're sayign I think 16:04:46 <mtanino_> It's good? 16:04:54 <mtanino_> I see. 16:04:55 <hemna> I wasn't suggesting we do remove the scoping 16:05:18 <hemna> I was simply pointing out that if you do remove it, the capabilities filter will then now filter on those keys, which has issues of it's own. 16:05:19 <jgriffith> hemna: not saying you were, I was just backing up to make sure I understand what mtanino_ and geguileo are proposing :) 16:06:00 <jgriffith> mtanino_: geguileo so the proposal is to change the reporting of vendor keys in capabiities from xxxx_yyyy, to xxx:yyy ? 16:06:14 <mtanino_> jgriffith: correct. 16:06:16 <jgriffith> mtanino_: geguileo makes sense... there may be some complications on upgrades though 16:06:25 <geguileo> jgriffith: But the important part was the xxxx part 16:06:41 <geguileo> jgriffith: If we force it to vendor_name (we already said no) 16:06:42 <jgriffith> geguileo: mtanino_ any thoughts on using a different delimeter so as to avoid any issues with scoped keys? 16:06:48 <jgriffith> mtanino_: mtanino_ like using '-' 16:07:07 <jgriffith> since that's improper formatting for a python var in our code anyway :) 16:07:25 <winston-d> smcginnis 16:07:25 <mtanino_> jgriffith: If the colon is included, I will replace it to "_" 16:07:47 <jgriffith> mtanino_: oh... 16:08:01 <jgriffith> mtanino_: so I don't necessarily like that FWIW 16:08:13 <jgriffith> mtanino_: underscores may be included in the var name 16:08:20 <jgriffith> mtanino_: which could make things kinda confusing IMO 16:08:34 <jgriffith> mtanino_: I prefer using something else if we can agree on it 16:08:44 <geguileo> jgriffith: Not confussing, because you would be able to separate it by the : 16:09:04 <geguileo> Ok, let's recap 16:09:08 <jgriffith> geguileo: ok, maybe I'm still not following :) 16:09:16 <jgriffith> geguileo: yes.. let's :) 16:09:20 <geguileo> Drivers can use any vendor prefix they want 16:09:31 <geguileo> So whatever separator we decide to use 16:09:32 <mtanino_> geguileo: yes. 16:09:40 <geguileo> It "could" be used in that prefix 16:09:44 <geguileo> Which is a problem 16:09:50 <geguileo> So we would log a warning 16:09:54 <geguileo> And replace it with something else 16:10:02 <jgriffith> geguileo: wait... why is that a problem? 16:10:19 * hemna is confused 16:10:39 <geguileo> So we don't need to separate the vendor part from the rest of the key?> 16:10:49 <winston-d_> how about just let driver developers know that some character(s) are not to be used 16:10:49 <jgriffith> geguileo: I certainly didn't say that 16:11:08 <geguileo> jgriffith: No, it was a genuine question, as in I'm not sure if we have to XD 16:11:19 <jgriffith> geguileo: I did say however that things like vendorname_compression_type is not good IMHO 16:11:34 <winston-d_> as long as we can clearly distinguish the 'well-defined' keys from the rest, it'd be fine. 16:11:35 <jgriffith> there's no clear delimeter between the prefix and the key itself 16:11:38 <geguileo> winston-d_: Exactly, but code should still work even if they don't do it right 16:11:49 <geguileo> winston-d_: That's why we would give a warning and replace it with something else 16:11:56 <jgriffith> winston-d_: geguileo I understand it "would be fine" but I'm asking why it's better? 16:12:05 <geguileo> jgriffith: It would be something like vendorname:compression_type 16:12:07 <winston-d_> and I thought we agreed in Vancouver that well defined keys will start with sth like 'cinder_' 16:12:18 <jgriffith> winston-d_: geguileo why is that better than vendor:key or vendor-key 16:12:31 <geguileo> winston-d_: That was changed later on 16:12:37 <geguileo> winston-d_: Well defined will not have prefix 16:12:45 <geguileo> winston-d_: Only vendor ones will have it 16:12:47 <jgriffith> geguileo: ok, so I'm reallynot following because what you just wrote it EXACTLY what I just proposed 16:13:23 <geguileo> jgriffith: What I proposed is what I was proposing from the start %D 16:13:24 <jgriffith> winston-d_: we did but after looking at the patch it seemed like just omitting the prefix from well defined keys was cleaner 16:13:42 <jgriffith> geguileo: then what's the discussion around the use of underscore? 16:13:57 <geguileo> jgriffith: At this point I think it is :-D 16:14:06 <winston-d_> jgriffith: so either prefix 'well-defined' ones or the rest. 16:14:36 <jgriffith> winston-d_: right, and I'm proposing the "others" are prefixed 16:14:42 <geguileo> jgriffith: I agree 16:14:47 <winston-d_> __not_well_defined_whatever_you_like 16:14:53 <mtanino_> winston-d_: like Hitachi:minIOPS 16:15:00 <jgriffith> geguileo: I can't tell for the life of me what you're proposing I'm afraid 16:15:11 <geguileo> XD XD 16:15:28 <geguileo> Let driver use whatever prefix they want 16:15:35 <geguileo> But they should know : is not allowed 16:15:42 <tbarron> can't we handle the weird vendor:name:compression_type capability by making a utility to split the vendor name and key that uses rsplit on the colon? 16:15:43 <geguileo> And will be replaced and a warning issued 16:16:00 <mtanino_> geguileo: It's my current plan 16:16:05 <winston-d_> ':' was used for scoped keys 16:16:07 <geguileo> tbarron: Yes 16:16:22 <jgriffith> winston-d_: and still is ;) 16:16:29 <tbarron> geguileo: so why do we have to replace the lefthand colon? 16:16:29 <geguileo> tbarron: But what if they want to have a : in the name? 16:16:30 <xyang> I don't understand why ":" will be replaced automatically? 16:16:39 <xyang> it is been used everywhere 16:16:42 <winston-d_> and 'capablities:' has specailly meanings, any keys prefixed with that will be consumed by CapablitiesFilter. 16:16:48 <jgriffith> we can't take that way, but geguileo you're talking in circles 16:16:48 <jgriffith> 16:12 geguileo| jgriffith: It would be something like vendorname:compression_type 16:16:50 <geguileo> tbarron: It's easier to control the vendor name, since we are already going to check it 16:16:55 <jgriffith> and then you say: 16:17:12 <jgriffith> : is not allowed and will log a warning? 16:17:22 <geguileo> If vendor prefix has : 16:17:27 <jgriffith> geguileo: or are you just saying they can't have ':' in the prefix itself? 16:17:30 <tbarron> geguileo: ok, I get what you are saying 16:17:37 <jgriffith> geguileo: Ohhh.. well yeah... duhhh :) 16:17:38 <geguileo> jgriffith: Yes 16:17:48 <jgriffith> geguileo: that's just natural IMO 16:17:51 <geguileo> jgriffith: So "if" they do we replace it 16:17:57 <geguileo> jgriffith: I think so too 16:18:12 <xyang> that will break drivers. Am I missing anything? 16:18:18 <jgriffith> geguileo: Well certainly... although IMO it woudl be fine if it fails 16:18:20 <jgriffith> xyang: nahhh 16:18:31 <hemna> if you disallow : in the key, then you will all of a sudden then get a lot of "No host found" in creating volumes. 16:18:36 <geguileo> jgriffith: If it fails to start the service? 16:18:48 <winston-d_> so 3par:max_iops will be changed to 3par_max_iops, for example? 16:18:54 <jgriffith> xyang: it only breaks drivers that use a ':' as a character in their capability value name (key name) 16:19:04 <mtanino_> Hita::chi:minIOPS should change Hitachi:minIOPS right? 16:19:14 <geguileo> hemna: Not in the key, in the vendor prefix part 16:19:16 <jgriffith> winston-d_: so my understanding is that is valid/ok 16:19:17 <xyang> jgriffith: that is widely used though 16:19:22 <jgriffith> winston-d_: geguileo ^^ 16:19:34 <geguileo> winston-d_: No 16:19:40 <jgriffith> winston-d_: geguileo my interpretation is that if you have "hp:3par:some_key" 16:19:43 <jgriffith> that's the problem 16:19:50 <tbarron> jgriffith: +1 16:19:51 <jgriffith> and it changes to hp_3par:some_key 16:19:52 <mtanino_> jgriffith: correct 16:20:00 <geguileo> winston-d_: 3:par:max_iops will be changed to 3_par:max_iops 16:20:18 <geguileo> jgriffith: Exactly 16:20:25 <winston-d_> 3par:some_key:some_subkey suddently won't work? 16:20:25 <jgriffith> that just makes sense to me 16:20:42 <geguileo> winston-d_: It will work 16:20:48 <geguileo> winston-d_: Because prefix is 3par 16:20:57 <geguileo> winston-d_: And it doesn't have : 16:21:18 <winston-d_> how is that different from hp:3par:key? 16:21:33 <geguileo> winston-d_: Because driver passes back the prefix 16:21:37 <jgriffith> geguileo: but winston-d_ has a point, it's a bit trickier to parse it, but if you're just using vendor_name from the capabilities it works easy enough 16:21:41 <geguileo> winston-d_: In one case it would pass hp:3par 16:21:47 <geguileo> winston-d_: And the other h3par 16:22:04 <navneet> I think the behavior in the scheduler is to ignore keys with ":" 16:22:18 <geguileo> jgriffith: Current implementation requires drivers to pass back the prefix so we can check it 16:22:19 <navneet> and its passed to the backend driver to handle it 16:22:24 <jgriffith> geguileo: so the crux of it is "don't use ':' in your vendor name" right? and I dont' know that anybody is doing that anyway 16:22:57 <winston-d_> i missed 'cinder_' prefix, it seems to me that will make life(&code) much easier 16:23:03 <smcginnis> I'd prefer vendor chosen prefix, but not necessarily vendor_name. 16:23:04 <winston-d_> s/missed/miss/ 16:23:06 <geguileo> jgriffith: jgriffith They are not 16:23:15 <smcginnis> Do we really want something like "Violin Memory, Inc.:compression" 16:23:17 <navneet> in that case does it still require prefix with vendor like vendor:key 16:23:27 <geguileo> smcginnis: We agreed on that, we all prefer it 16:23:30 <hemna> smcginnis, yuk 16:23:43 <smcginnis> geguileo: Which is preferred? 16:23:52 <smcginnis> I don't think we've all agreed on anything. 16:23:52 <geguileo> smcginnis: The one you suggest 16:24:00 <geguileo> smcginnis: Drivers can choose prefix 16:24:05 <jgriffith> smcginnis: it translates to Violin_Memory_Inc:compression 16:24:09 <geguileo> smcginnis: Current patch implementation is like that 16:24:10 <smcginnis> geguileo: OK, I'm good then. Thanks. :) 16:24:35 <jgriffith> winston-d_: you feel the prefix cinder_ is better/easier? 16:24:35 <geguileo> jgriffith: No, we won't be doing translation for that part 16:24:37 <winston-d_> __some_ugly_prefix_so_admin_will_never_miss_used__FREEFORALL 16:24:41 <geguileo> jgriffith: Only replace : 16:24:48 <jgriffith> geguileo: ok, fair enough 16:24:59 <jgriffith> geguileo: but I'd change my prefix if I had that :) 16:25:01 <smcginnis> winston-d_: Hey, if that's what the vendor wants. :) 16:25:19 <jgriffith> geguileo: my only suggestion is to add a capability key "prefix" 16:25:32 <jgriffith> geguileo: mtanino_ and use capability.get(prefix, vendor_name) 16:25:41 <jgriffith> geguileo: they don't have to be the same that way 16:25:57 <vincent_hou> mtanino_: geguileo: please get it documented with examples somewhere. Need to make every developer know. 16:26:22 <winston-d_> jgriffith: if we went wight 'cinder_', we only need to handle what, less than ten defined keys, but prefixing the rest, that seems much more messier. 16:26:30 <rajinir> Where is this kind of stuff documented? 16:26:31 <jgriffith> winston-d_: LOL 16:26:32 <winston-d_> s/wight/with/ 16:26:39 <hemna> *sigh* 16:26:46 <jgriffith> winston-d_: fair point 16:26:54 <jgriffith> winston-d_: I was laughing at your example above :) 16:27:04 <mtanino_> vincent_hou: will documented in the comment. 16:27:13 <vincent_hou> rajinir: devref, maybe. 16:27:27 <geguileo> mtanino_: And update the spec file like you are doing, right? 16:27:38 <mtanino_> geguileo: yes. correct 16:27:55 <mtanino_> geguileo: jgriffith I will put detail of this in the SPEC 16:27:58 <jgriffith> winston-d_: I'm on the fence honestly, the only thing I like better about what you're saying is that "explicit is better than implicit" 16:28:35 <jgriffith> geguileo: mtanino_ now that I understand what you're saying (and it's just how I assumed it worked :)) I'm fine either way 16:28:40 <rajinir> vincent_hou: thx 16:28:41 <winston-d_> jgriffith: yup 16:28:49 <jgriffith> mtanino_: geguileo I would like winston-d_ and others to consider the alternative... 16:29:03 <jgriffith> mtanino_: geguileo and see if perhaps we should be doing one way over the other in this case 16:29:34 <geguileo> jgriffith: In theory this was changed from what winston-d_ says to the new way 16:29:46 <geguileo> mtanino_: You mentioned this was changed, right? 16:30:11 <mtanino_> geguileo: jgriffith that proposal comes from jgriffith. 16:30:20 <jgriffith> winston-d_: the only advantage the other way was that in my case I'd change all my custom extra-specs to use the same scoped key 16:30:32 <jgriffith> winston-d_: of course I could have done that anyway, and still could 16:30:56 <jgriffith> winston-d_: I just didn't really consider it at the time when I wrote the driver 16:31:15 <vincent_hou> mtanino_: check if there is a good place in devref for something to document. Under doc folder I think. 16:31:26 <jgriffith> geguileo: mtanino_ YES, the change is completely my fault :( 16:31:29 <winston-d_> jgriffith: what do you prefix your custom extra-specs keys for now? 16:31:32 * jgriffith hides in the corner 16:31:51 <mtanino_> jgriffith: We can still back to use cinder_ 16:31:57 <jgriffith> winston-d_: QOS or REPLICATION 16:31:59 <mtanino_> for well defined keys 16:32:31 <jgriffith> I still like the bare key, but I've caused enough trouble already so I'll let others speak if they have an opinion 16:32:44 <jgriffith> but we need to wrap this topic up and get the code merged 16:32:57 <mtanino_> yes... 16:33:02 <jgriffith> as I have issues with things like this which I'll bring up in my next topic :) 16:33:04 <bswartz> +1 for bare key 16:33:25 <winston-d_> jgriffith: ok, and because those are well defined, so you don't want to have to change your driver, right? 16:33:26 <navneet> using cinder_ internal to cinder seems odd 16:33:38 <navneet> thenits as better as bare 16:33:42 <jgriffith> hemna: smcginnis DuncanT e0ne geguileo winston-d_ other cores... votes? 16:33:50 <jgriffith> winston-d_: correct 16:33:56 <jgriffith> winston-d_: wait... no 16:34:01 <winston-d_> navneet: we can use 'nova', if that's fancier, or 'docker', maybe 16:34:09 <geguileo> I vote for vendor_name prefix instead of cinder_ prefix 16:34:10 <hemna> chewbacca_ 16:34:10 <jgriffith> winston-d_: those are not well defined keys, they're vendor unique 16:34:12 <winston-d_> any buzz words 16:34:13 <xyang> +1 for cinder_ so we don't have to change other keys 16:34:34 <jgriffith> xyang: we don't have to change other keys though 16:34:47 <xyang> jgriffith: the replacement part 16:34:53 <winston-d_> jgriffith: so you will have to change your driver if you want to provide list of capabilities? 16:34:55 <e0ne> +1 for vendor prefix 16:34:56 <smcginnis> I was leaning toward vendor, but it is true there is a smaller discrete set of cinder ones that could be covered with the cinder_ prefix. 16:34:57 <navneet> winston-d_:if we want to make it explicit then vendor_ or bare is better than cinder_ 16:35:15 <smcginnis> No strong opinion really. 16:35:25 <geguileo> winston-d_: Yes, you need to report them with a method 16:35:33 <jgriffith> hehe... we're getting nowhere on this one I fear 16:35:35 <hemna> I don't care as long as we are consistent. 16:35:39 <jgriffith> Ok, vote be reviewing the patch :) 16:35:50 <jgriffith> BUT, make sure you load it up to see how it impacts your current functionality 16:36:04 <jgriffith> of course none of us have the patches in our drivers so it's kinda moot 16:36:25 <smcginnis> yep 16:36:36 <xyang> jgriffith: we'll just make sure all CI passes:) 16:36:40 <winston-d_> mtanino_: your patch, will you just do the lvm driver and let other make simliar changes or you will do that for everybody? 16:37:37 <mtanino_> winston-d_: as for well defined keys, every driver has these keys. 16:37:54 <jgriffith> Ok, hate to cut this short, but we're running pretty long 16:38:00 <smcginnis> +1 16:38:05 <jgriffith> we can discuss further in #openstack-cinder maybe? 16:38:10 <winston-d_> let's move on 16:38:11 <mtanino_> geguileo: jgriffith Thank you for your help. 16:38:15 <jgriffith> or state your opinion viareivew 16:38:17 <geguileo> mtanino_: np 16:38:18 <jgriffith> mtanino_: thank you!! 16:38:28 <jgriffith> Ok... 16:38:36 <jgriffith> #topic feature freeze for liberty 16:39:00 <jgriffith> I have some things i wanted to bring up as a team here 16:39:04 <navneet> jgriffith: I just started :) 16:39:20 <winston-d_> sure 16:39:23 <jgriffith> navneet: ? 16:39:52 <jgriffith> we implemented the cut off date of last Sunday saying anything that wasn't passing jenkins and had an approved BP was to be rejected until M 16:40:02 <jgriffith> I think that's *ok*, BUT 16:40:06 <navneet> jgriffith:feature freeze came so early 16:40:12 <jgriffith> I have some concerns about a few things... 16:40:24 <jgriffith> navneet: yes, I felt it was a bit early but none the less 16:40:50 <jgriffith> I have issues with things like replication for example... and the capabilities patch we just discussed 16:40:57 <hemna> navneet, FWIW nova's feature freeze is the 2nd Milestone. 16:41:16 <jgriffith> by the "rules" in place that means that none of the new features that landed in core can be implemented by anybody 16:41:34 <jgriffith> inparticular replication is a good example becuase I didn't finisht he core work until Sunday 16:41:57 <navneet> hemna: oh yes...tokyo is near by 16:42:12 <Swanson> We can just admire it from a distance. 16:42:14 <jgriffith> I think we need to determine whether features like this should NOT be implemented by anybody, or if everybody should have the time to implement them? 16:42:25 <jgriffith> Swanson: that's fine honestly if you ask me 16:42:42 <jgriffith> saying that the core pieces are in place, but not implemented anywhere until next release 16:42:48 <smcginnis> It does prevent folks from trying to cram untested implementations in at the last minute. 16:42:50 <hemna> jgriffith, I'm not sure what the right answer is honestly. These big features are typically not done until later in the release 16:43:06 <jgriffith> the rush at the ned and only one or two implementations at release is kinda what's bit us in the past 16:43:09 <hemna> and in the past most folks didn't have enough time to implement, but patches usually show up early in the next release. 16:43:14 <xyang> I'd prefer we allow reference implementations for new features 16:43:14 <jgriffith> hemna: indeed 16:43:25 <smcginnis> For stability I would prefer everyone just prepping to have it ready for M. 16:43:28 <navneet> xyang: +1 16:43:34 <kmartin> I thought for the folks that were working along side the feature(i.e Pure) and entered approved BPs then they should get in. 16:43:43 <e0ne> xyang: +1 16:43:47 <jgriffith> kmartin: yes, that was the ruling 16:43:57 <Swanson> I thought pure or someone had a reference implementation. 16:43:58 <jgriffith> kmartin: I'm saying I'm not sure that's really such a good approach 16:44:08 <jgriffith> because we still go out with only one implementation of a major feature 16:44:25 <jgriffith> I don't think there's anything wrong with a feature spanning multiple releases 16:44:26 <hemna> jgriffith, the only other option really is to not allow the features to land in the 3rd milestone and hold them for the 1st milestone of the next release ? 16:44:32 <winston-d_> only core piece can bite 'cinder', right? vendor implementation only bites themselves, not others. 16:44:38 <xyang> non-disruptive backup has no reference implemenation 16:44:44 <smcginnis> winston-d_: Good point. 16:44:45 <jgriffith> winston-d_: correct 16:44:46 <navneet> jgriffith: but that serves as a template and must do for others in next rel 16:44:48 <xyang> code is done but not allowed to merge 16:44:59 <jgriffith> winston-d_: which is the second part of what i wanted to throw out :) 16:45:04 <xyang> winston-d_: +1 16:45:09 <eharney> winston-d: vendor implementation bites us all if we end up finding out that core changes are needed as more vendors implement it in the next cycle 16:45:28 <jgriffith> should we allow an extended period for drivers to implement features that have landed in core cinder? 16:45:33 <smcginnis> eharney: Like replication v1. 16:45:39 <jgriffith> a staggered freeze so to speak? 16:45:43 <cebruns> eharney: +1 16:45:43 <winston-d_> as long as we are confident about core pieces, i don't care some vendor squeeze in their slappy implementation and end up pissing off their customer 16:45:54 <xyang> jgriffith: +1 16:45:57 <jgriffith> I kinda wish I thought of that a few months ago but I didn't :( 16:46:10 <geguileo> winston-d_: I don't agree 16:46:17 <navneet> jgriffith: allowing drivers to implement only adds more instability 16:46:23 <geguileo> winston-d_: Customers some times have multiple drivers and they don't know who to blame 16:46:30 <bswartz> fwiw, this is why I proposed "experimental" APIs at the midcycle -- to cover the period between when a new feature merges and when it's widely implemented and well tested 16:46:31 <geguileo> winston-d_: So they end up blaming Cinder 16:46:32 <navneet> but atleast one reference implementation should be allowed 16:46:38 <patrickeast> i like the idea of a staggered freeze, is the suggestion that we do something like that now for L? 16:46:41 <patrickeast> or going forward? 16:46:43 <xyang> without driver implementation, what is point of introducing a feature? 16:46:47 <eharney> winston-d_: but that sloppy impl then forces compatibility concerns on us, even if it's sloppy 16:46:51 <jgriffith> bswartz: sorry, I don't think I was around for that topic... sounds interesting though 16:47:10 <jgriffith> patrickeast: so the way I see it we have two choices for L 16:47:29 <tbarron> eharney: +1 on compatibility concerns 16:47:32 <patrickeast> i also might be biased but i do think having at least some driver impl does help to find any issues with the core feature... at a minimum it should ease the amount of problems others have next time 16:47:35 <winston-d_> geguileo: one works, the other doesn't, you know who to blame. :) 16:47:37 <hemna> xyang, so it gets more complex when the feature itself has dependencies in Nova. re: multi-attach. If the Cinder side doesn't land, then Nova never can land, due to the schedule and deadlines, etc. 16:47:38 <jgriffith> patrickeast: features that merged in core at the last minute are granted some exception for drivers 16:47:40 <jgriffith> patrickeast: OR 16:47:41 <xyang> bswartz: that is a good idea, but we don't have it yet 16:47:45 <patrickeast> bswartz: +1 for experimental features 16:47:46 <jgriffith> nobody goes out the door with it 16:47:48 <geguileo> winston-d_: It's not that simple :-D 16:47:51 <hemna> so I don't think we can be so hard/fast with the rules on this 16:47:59 <navneet> xyang: its like an appetizer...but atleast one reference impl 16:48:09 <jgriffith> hemna: that's why I brought it up here :) 16:48:21 <Swanson> xyang: Chicken and egg. Plus someone could implement out of band. 16:48:30 <hemna> jgriffith, so you can probably guess my opinion on this one :) 16:48:31 <jgriffith> hemna: I thought it was important enough that we should discuss and make a decision as a team 16:48:38 <hemna> jgriffith, +1 16:48:43 <jgriffith> hemna: actually no I can't 16:48:54 <guitarzan> the concept of experimental features seems like a pretty good middle ground imo 16:49:10 <jgriffith> guitarzan: yeah, but it's kinda off the table for L IMO 16:49:17 <guitarzan> sure, no question 16:49:18 <hemna> heh ok. I think it's fine to have core features land in the 3rd milestone, even if there is no ref implementation. 16:49:31 <guitarzan> jgriffith: are you really just asking about replication and being sneaky about it? :) 16:49:38 <hemna> :) 16:49:47 <bswartz> jgriffith: if you're interested you can look at how it was done in manila -- first we did microversions https://review.openstack.org/#/c/207228/ then we added experimental as an enhancement on top of microversions https://review.openstack.org/#/c/215340/ 16:49:48 <xyang> hemna: but if the ref imp is ready, why block it? 16:49:51 <jgriffith> hemna: well... ok, but given the two options I proposed... which do you think is the right way to go (or neither) 16:49:57 <navneet> lets just fix whats around here for now 16:50:03 <patrickeast> jgriffith: why is calling replication experimental off the table? couldn't we lock down the api's and document it as experimental with a big warning label on it? 16:50:31 <hemna> xyang, if the ref impl is ready, then land it, if CI is passing. 16:50:41 <jgriffith> patrickeast: well, to do experimental right, you need more than a "label" on it IMO 16:50:49 <xyang> hemna: we are not allowed currently:( 16:51:04 <jgriffith> patrickeast: as bswartz pointed out, micro-versioning and other things are probably a good idea 16:51:19 <patrickeast> jgriffith: yea, i agree, to do it 'right' is more effort 16:51:35 <patrickeast> jgriffith: but imo a huge portion of it is communication to customers about it 16:51:36 <e0ne> agree that we need to have saparate deadlines for ref impl and for drivers 16:51:41 <patrickeast> s/customers/operators/ 16:51:45 <jgriffith> patrickeast: I'm also not convinced it's necessary if we think ahead about timing etc 16:51:52 <bswartz> yeah microversions solves a lot of problems which would otherwise be caused by introducing experimental APIs and later changing/removing them 16:53:08 <patrickeast> jgriffith: not sure what you mean about timing 16:53:15 <hemna> 9 minutes 16:53:17 <patrickeast> jgriffith: you mean about when we land the features? 16:53:31 <jgriffith> patrickeast: requiring core-features to merge earlier 16:53:38 <patrickeast> jgriffith: ahh gotcha 16:53:46 <winston-d_> just to argue about having core only and wait for drivers to catch up in next release cycle, I'd say that actually keep us from finding out if necessary core changes might be needed. 16:54:01 <jgriffith> winston-d_: agreed 16:54:09 <e0ne> jgriffith: +1 on "requiring core-features to merge earlier" 16:54:09 <winston-d_> more drivers impls, more confidence we have 16:54:12 <xyang> winston-d_: +1 16:54:13 <jgriffith> winston-d_: there are definitely pros/cons either way 16:54:23 <jgriffith> so how about this... we'll take two votes 16:54:39 <jgriffith> 1. allow an extra week of driver implementation of merged core features 16:54:42 <jgriffith> and 16:54:46 <e0ne> core featured for milestone-2 and drivers for miletone-3? 16:54:55 <jgriffith> 2. No driver implementations for those core features that landed last minute 16:55:15 <dannywilson> is this voting for M or L? 16:55:20 <jgriffith> we'll take the winner and move forward for L... with a design summit topic for M to fix this 16:55:26 <jgriffith> dannywilson: this is L 16:55:38 <navneet__> option 2 16:55:38 <hemna> 1 16:55:40 <e0ne> jgriffith: option #1 is good for me if it is tested by 3rd party ci 16:55:44 <jgriffith> dannywilson: we'll discuss how to deal with this sort of thing going forward at summit 16:55:46 <xyang> 1 16:55:46 <patrickeast> i hate to be that guy, but shouldn't there be an option 3 which is stick to thingee's plan? (i'm voting for option 1 though) 16:55:47 <dannywilson> changing the rules at the last minute like this seems a bit sucky 16:55:50 <winston-d_> we use the '#vote' or just speak out? 16:55:53 <navneet__> more stablility with trunk 16:56:10 <jgriffith> #startvote Extend driver implementation deadline for new features by 1 week? Yes, No 16:56:10 <openstack> Begin voting on: Extend driver implementation deadline for new features by 1 week? Valid vote options are Yes, No. 16:56:12 <openstack> Vote using '#vote OPTION'. Only your last vote counts. 16:56:18 <xyang> #vote 1 16:56:18 <hemna> #vote 1 16:56:18 <openstack> xyang: 1 is not a valid option. Valid options are Yes, No. 16:56:19 <smcginnis> 2 16:56:20 <openstack> hemna: 1 is not a valid option. Valid options are Yes, No. 16:56:22 <bswartz> #vote no 16:56:22 <navneet__> 2 16:56:23 <Swanson> #vote 2 16:56:25 <openstack> Swanson: 2 is not a valid option. Valid options are Yes, No. 16:56:27 <e0ne> #vote Yes 16:56:28 <hemna> #vote yes 16:56:30 <jgriffith> #vote yes 16:56:30 <Swanson> #vote No 16:56:31 <winston-d_> #vote Yes 16:56:31 <rhe00> #vote yes 16:56:33 <patrickeast> #vote Yes 16:56:41 <dannywilson> #vote no 16:56:42 <vincent_hou> Any time left for me? :-) 1 16:56:43 <navneet__> #vote No 16:56:44 <smcginnis> Yes is 1 and no is 2? 16:56:45 <cebruns> #vote yes 16:56:45 <jgriffith> xyang: you need to vote "yes or no" 16:56:49 <xyang> yes 16:56:53 <xyang> #vote yes 16:56:53 <guitarzan> #vote yes 16:56:59 <smcginnis> #vote no 16:57:01 <jgriffith> xyang: haha you need to prefix it 16:57:09 <xyang> ? 16:57:11 <dulek> #vote no 16:57:19 <eharney> i'm not familiar enough with the exact list of features at hand etc to really cast a well-reasoned vote here 16:57:20 <jgriffith> xyang: nm you got it 16:57:35 <jseiler_> #vote no 16:57:35 <xyang> will this be counted automatically? 16:57:35 <geguileo> eharney: +1 16:57:39 <jgriffith> eharney: replication, capability reporting, cg-snaps, online backupes 16:57:44 <jgriffith> backups even 16:57:53 <jgriffith> xyang: yes 16:57:59 <xyang> cool 16:57:59 <jgriffith> 10 seconds.... 16:58:01 <tbarron> #vote no 16:58:14 <winston-d_> geguileo: vote pls 16:58:26 <jgriffith> geguileo: eharney last chance to vote 16:58:33 <hemna> hurry up and snipe the vote! 16:58:35 <navneet__> seems like vendors prefer #yes but operators #no 16:58:41 <smcginnis> vincent_hou: Guess you'll need to report in -cinder. 16:58:41 <wilson2> #vote yes 16:58:44 <jgriffith> #endvote 16:58:45 <openstack> Voted on "Extend driver implementation deadline for new features by 1 week?" Results are 16:58:46 <openstack> Yes (10): hemna, cebruns, winston-d_, xyang, jgriffith, rhe00, e0ne, wilson2, patrickeast, guitarzan 16:58:47 <openstack> No (8): bswartz, navneet__, smcginnis, tbarron, Swanson, jseiler_, dannywilson, dulek 16:58:57 <Swanson> bah 16:58:58 <jgriffith> navneet__: you seem to be wrong about that 16:59:07 <jgriffith> navneet__: all the operators seem to have voted yes 16:59:25 <jgriffith> ok.. one more vote 16:59:31 <smcginnis> time 16:59:54 <jgriffith> #startvote should we remove late landing core features from any driver and wait til next release? Yes, No 16:59:56 <openstack> Begin voting on: should we remove late landing core features from any driver and wait til next release? Valid vote options are Yes, No. 16:59:57 <openstack> Vote using '#vote OPTION'. Only your last vote counts. 17:00:00 <Swanson> Can vincent do a progress report in a single line? 17:00:12 <hemna> #vote no 17:00:13 <dannywilson> #vote no 17:00:14 <dulek> #vote no 17:00:17 <xyang> #vote no 17:00:18 <e0ne> #vote no 17:00:19 <jgriffith> I'll give this one 30 seoncs 17:00:21 <winston-d> #vote no 17:00:22 <patrickeast> #vote no 17:00:22 <jgriffith> #vote yes 17:00:23 <bswartz> #vote no 17:00:23 <navneet__> #vote no 17:00:24 <cebruns> #vote no 17:00:28 <ericksonsantos> #vote no 17:00:29 <smcginnis> #yes 17:00:29 <vincent_hou> let us go to cinder shall we? 17:00:29 <guitarzan> #vote no 17:00:31 <tbarron> #no 17:00:32 <smcginnis> #vote yes 17:00:35 <rhe00> #vote yes 17:00:37 <Swanson> #vote yes 17:00:41 <jseiler_> #vote yes 17:00:44 <jgriffith> 5 seconds 17:00:47 <geguileo> #vote yes 17:00:55 <jgriffith> #endvote 17:00:56 <openstack> Voted on "should we remove late landing core features from any driver and wait til next release?" Results are 17:00:58 <openstack> Yes (6): smcginnis, jseiler_, jgriffith, rhe00, Swanson, geguileo 17:00:59 <openstack> No (12): bswartz, navneet__, hemna, ericksonsantos, cebruns, xyang, winston-d, e0ne, dannywilson, patrickeast, guitarzan, dulek 17:01:06 <hemna> if we did this, then nova could never get things like multi-attach support. 17:01:13 <jgriffith> ok... that one is pretty overwhelming 17:01:17 <jgriffith> hemna: not true at all 17:01:30 <hemna> jgriffith, I went through 3 releases of that and it was true. 17:01:33 <hemna> anyway 17:01:41 <smcginnis> To -cinder? 17:01:51 <hemna> we are out of time here 17:01:52 <vincent_hou> hemna: you will be there. 17:01:53 <jgriffith> hemna: I don't follow... but we can chat 17:01:56 <dannywilson> jgriffith: voting yes on both like you did seems funny 17:02:00 <jgriffith> vincent_hou: can you meet us in cinder? 17:02:07 <vincent_hou> sure 17:02:08 <jgriffith> dannywilson: hehe... I'm funny that way 17:02:19 <jgriffith> I'm mixed on what's best for Cinder to be honest 17:02:19 <vincent_hou> see you in cinder 17:02:21 <jgriffith> ok... 17:02:26 <jgriffith> let's go over to cinder and give up the room 17:02:30 <jgriffith> #endmeeting