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