16:00:00 <thingee> #startmeeting cinder 16:00:02 <openstack> Meeting started Wed Feb 18 16:00:00 2015 UTC and is due to finish in 60 minutes. The chair is thingee. Information about MeetBot at http://wiki.debian.org/MeetBot. 16:00:03 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 16:00:05 <openstack> The meeting name has been set to 'cinder' 16:00:07 <thingee> hi everyone! 16:00:12 <rhe00> hi 16:00:33 <kmartin> hello 16:00:35 <scottda> hi 16:00:38 <xyang2> hi 16:00:38 <jungleboyj> hello 16:00:42 <smcginnis> o/ 16:00:46 <e0ne> hi 16:00:47 <Yogi> hello 16:01:00 <thingee> so first off announcements 16:01:01 <Swanson> Hello 16:01:02 <dulek> hi 16:01:12 <eharney> hi 16:01:13 <asselin_> hi 16:01:38 <thingee> we have our weekly reminder on the requirement of third party ci for all volume drivers in cinder 16:01:41 <jgriffith> 0/ 16:01:41 <thingee> #link http://lists.openstack.org/pipermail/openstack-dev/2015-January/054614.html 16:01:43 <thingee> march 19th 16:01:48 <thingee> that's the deadline date 16:02:14 <thingee> Google summer of code is coming up 16:02:29 <thingee> if you want to participate and help others on the openstack front, check out 16:02:30 <cebruns> o/ 16:02:31 <thingee> #link https://wiki.openstack.org/wiki/GSoC2015 16:02:36 <thingee> and reach out to dims__ 16:02:38 <jnrao> hi 16:02:43 <thingee> agenda for today 16:02:45 <thingee> #link https://wiki.openstack.org/wiki/CinderMeetings#Next_meeting 16:02:51 <thingee> lets get started! 16:03:02 <thingee> #topic 3rd Party CI - Important Action required 16:03:10 <thingee> asselin_: hi 16:03:12 <dims__> thanks thingee 16:03:16 <thingee> #link http://lists.openstack.org/pipermail/openstack-dev/2015-February/056508.html 16:03:22 <asselin_> Want to make sure everyone doing ci reads this ^^ 16:03:41 <avishay> hi 16:03:59 <thingee> #action If you have a firewall that blocks port 29418/tcp, be sure to start the process to get it updated, otherwise you may not be able to subscribe to the gerrit event stream. 16:04:01 <asselin_> If you have firewall egress rules, this can break your ci's ability to read the gerrit event stream 16:04:15 <flip214> asselin_: is there some protocol what should be done if eg. devstack setup fails? should then a +0 be sent? 16:04:20 <smcginnis> asselin_: Will there be overlap so we can test connection to the new host before DNS is switched? 16:04:41 <asselin_> flip214, it won't even get that far. 16:04:51 <asselin_> no jobs will get triggered w/o an event stream 16:05:17 <flip214> asselin_: if my CI re-creates a devstack setup to test a change, and this setup fails, what should it do? 16:05:19 <asselin_> smcginnis, I asked yesterday in the -infra meeting, but didn't get an answer....I was ask again 16:05:23 <flip214> just ignore it? 16:05:25 <rushiagr> o/ 16:05:34 <deepakcs> o/ 16:05:38 <smcginnis> asselin_: Thanks, that would be good to know. 16:05:40 <flip214> ignore this change is what I mean. 16:05:55 <asselin_> flip214, just fail 16:05:57 <thingee> #action asselin_ to figure out from infra if there will be a test connection to the new host 16:06:01 <jgriffith> flip214: it's a "failure" 16:06:33 <jgriffith> asselin_: so my understanding is this is just an IP change, same port etc etc 16:06:35 <DuncanT> Given that review.openstack.org is running in the cloud, it would be easy enough to assign the floating IP to the next instance I'd have thought, but still... 16:06:37 <flip214> jgriffith: yes, but not a failure caused by some change that just got committed. As we've had in Januiary... 16:06:41 <jgriffith> asselin_: correct? 16:06:48 <asselin_> jgriffith, correct ,just ip change 16:06:54 <jgriffith> asselin_: k, thanks 16:07:08 <clarkb> DuncanT rax doesnt have floating IPs unless something has changed 16:07:13 <asselin_> flip214, just fail. let reviewers issue a recheck 16:07:16 <jgriffith> flip214: off topic, but final word is "doesn't matter" the test failed to run 16:07:20 <DuncanT> clarkb: Ah, ok, thanks 16:07:28 <clarkb> if it has changed would require an IP change to get onto a floating ip regardless 16:07:28 <flip214> okay. 16:07:58 <thingee> asselin_: anything else to add? 16:08:06 <thingee> anyone else? 16:08:16 <asselin_> thingee, that's it. thanks 16:08:23 <thingee> asselin_: thanks for the notice 16:08:37 <thingee> #topic Volume Replication Plan Going Forward 16:08:40 <thingee> jungleboyj: you're up 16:08:49 <jungleboyj> thingee: Thanks. 16:09:02 <thingee> #link https://review.openstack.org/#/c/155644/ 16:09:17 <jungleboyj> We have been working on getting the issues with volume replication addressed that were raised during the mid-cycle meetup. 16:09:40 <thingee> #link https://etherpad.openstack.org/p/cinder-meetup-winter-2015 16:10:11 <jungleboyj> Now a proposal for volume replication v2 has been made by jgriffith and those are interested are actively working on iterating through that. 16:10:31 <jungleboyj> With that said, I want to propose how we handle wrapping up volume replication v1. 16:10:52 <jungleboyj> We have several patches in the pipeline that wish to use replication v1. 16:10:57 <thingee> jungleboyj: seems like a lot of good ideas are coming out from the spec from smcginnis. Thanks to jgriffith for starting things too 16:11:42 <jungleboyj> Based on what we are seeing in the v2 spec it seems that we are going to be keeping replication and v2 will be an udpate/improvement based on lessons learned as we hoped would be the case when we discussed this in Paris. 16:12:00 <smcginnis> jungleboyj: +1 16:12:21 <jungleboyj> Yes, thanks to jgriffith smcginnis ronenkat_ xyang1 . All who are commenting in there. 16:12:46 <thingee> so is it worth ibm having to have their customers switch to something else in L and worth us spending time doing the reviews. Also is it worth IBM to support two different ways of how replication is done. 16:12:49 <jungleboyj> So, at this point I want to broach the subject of getting the current patches for V1 in to Kilo as originally planned. 16:13:19 <jungleboyj> thingee: Well, this isn't just IBM patrickeast has his version out there as well. 16:13:21 <smcginnis> jungleboyj: Do you have patch links? 16:13:46 <patrickeast> jungleboyj: yep, but i think the decision for us is to wait for v2 16:13:50 <thingee> jungleboyj: my question still stands. Seems like a PITA for you guys, but if you really want to go that route 16:14:10 <jungleboyj> Regardless, I think we should get the updated spec in for V1 https://review.openstack.org/152735 16:14:11 <patrickeast> we don’t really want to have to try and support both approaches in our driver 16:14:18 <smcginnis> Captain replication can handle it. :P 16:14:22 <xyang2> https://review.openstack.org/#/c/145090/ 16:14:45 <smcginnis> patrickeast: What are your thoughts on v2? 16:14:49 <jungleboyj> GPFS: https://review.openstack.org/153918 16:14:53 <patrickeast> i like it a lot more 16:14:53 <jgriffith> jungleboyj: just to make sure I understand, you're proposing we have 2 implementations in place? 16:15:04 <thingee> jgriffith: yup 16:15:10 <patrickeast> it would simplify the implementation quite a bit 16:15:12 <thingee> in L, they'll switch to v2 16:15:20 <ronenkat_> thingee: we would probably get more feedback from added implmentations, and migration from v1 to v2 should be simple as the details are kept in the driver 16:15:23 <thingee> but they have to support Kilo's v1 implementation 16:15:29 <jgriffith> that seems troublesome 16:15:33 <jungleboyj> thingee: We would switch to v2 in L. 16:15:34 <thingee> jgriffith: +1 16:15:39 <thingee> jungleboyj: yup 16:16:10 <thingee> that's where I'm getting it at. IBM will be dealing with it though, so not really my problem. I would recommend against it though. 16:16:15 <thingee> for your sanity 16:16:29 <jgriffith> jungleboyj: that makes things rather difficult to clean things up I think. And it is going to introduce a lot of confusion 16:16:37 <jgriffith> thingee: Yeah, I think you're right 16:16:40 <smcginnis> Seems a pain, but we are converging toward a more consistent and usable design. I guess if jungleboyj and patrickeast think this is the right approach, we should work towards it. 16:16:56 <jgriffith> the other option I guess is don't do V2 until L 16:17:08 <thingee> jgriffith: v2 was always a plan to me in L 16:17:13 <jgriffith> and just no more implementations of the current replication 16:17:14 <smcginnis> jgriffith: Aren't we just delaying the inevitable? 16:17:16 <jgriffith> thingee: oh 16:17:20 <jgriffith> ok 16:17:24 <jungleboyj> jgriffith: I didn't think we were going to do v2 until L. 16:17:25 <thingee> but I would sponsor it in K if we really felt it was doable 16:17:28 <hemna> we were looking at adding replication but we decided to wait for K 16:17:30 <jungleboyj> That is why I am proposing this. 16:17:36 <jgriffith> jungleboyj: then I'm not sure why this is a topic :) 16:17:50 <thingee> I'm the guy targeting 48 things in k-3. what do I care? :P 16:17:57 <patrickeast> lol 16:17:58 <jgriffith> jungleboyj: thingee my bad, I had hoped to do this for K 16:18:05 <hemna> the whole periodic task thing in the volume manager seems very bad to me. 16:18:09 <jungleboyj> jgriffith: Ah, I see the confusion here. 16:18:14 <hemna> so I hope v2 fixes that 16:18:17 <jungleboyj> hemna: We have a patch up to fix that. 16:18:21 <jungleboyj> For V1. 16:18:22 <jgriffith> jungleboyj: thingee if you guys are going L then I don't even know why this would be a topic 16:18:26 <hemna> jungleboyj, well it's a partial fix 16:18:31 <jgriffith> jungleboyj: fix what's there if you can 16:18:37 <hemna> it's still pulling every volume from the db for a host though. 16:18:48 <jgriffith> I wouldn't want to see anybody else try to implement this version though 16:18:54 <hemna> jgriffith, +1 16:18:55 <jungleboyj> hemna https://review.openstack.org/154673 16:18:57 <ronenkat_> hemna: I don't think you can get it out - you will need it, you can change the frequency, but not the periodical itself 16:18:58 <thingee> jgriffith: doesn't hurt to talk about things now. I would rather people not focus on things for L right now though...we already have quite a bit to do in k-3 16:19:17 <ronenkat_> hemna: the performance issues will be taken care of 16:19:17 <thingee> and I have been reaching out to core directly for help on k-3 16:19:23 <DuncanT> hemna :We'll only be hitting the db while replication is enabled though now, right? 16:19:41 <jgriffith> DuncanT: on if the device reports that it supports it 16:19:43 <thingee> jgriffith: so I would sponsor it, but I just wasn't under the impression we would be ready in time 16:19:51 <jgriffith> DuncanT: hemna but actually that appears to be broken anyway 16:19:57 <hemna> DuncanT, the periodic is only enabled if the capability is reported 16:19:58 <jungleboyj> thingee: So, if we want to get our patch for GPFS in and the update to storwize is that acceptable. I will get the spec updated so that it is consistent for the v1 design and then for L we move the focus to v2? 16:20:02 <jgriffith> thingee: sure... that's fair 16:20:06 <hemna> but it still pulls every volume for a host from the db. 16:20:06 <thingee> jgriffith: there was no clear indication "thingee I plan to do this in L"...just a spec. 16:20:11 <jungleboyj> thingee: I am just looking for agreement there. 16:20:13 <thingee> no FFE 16:20:30 <hemna> I haven't looked at the review since last night though 16:20:31 <jgriffith> thingee: so I'm happy to do it whenever... like even in the next week or two 16:20:38 <hemna> so maybe they fixed that as well. /me crosses fingers 16:20:40 <DuncanT> hemna: Given only IBM have a driver for it, the best bet would be for nobody else to report support for it in K, then the periodic db hiit should be a none issue 16:20:41 <jgriffith> thingee: but also fine if nobody wants it in K as it's late 16:20:50 <thingee> I'm fine with it. I like the work jgriffith put in this. I just wouldn't approve something from drivers to do it in K at this point. not enough time imo 16:21:06 <jgriffith> thingee: ahh... good point 16:21:20 <jungleboyj> thingee: I agree with that on V2. We need to take time to hash it out carefully to avoid future issues. 16:21:38 <hemna> yup 16:21:48 <ronenkat_> jgriffith: since you did raise the point the replication got in with not enough considerations, I suggest we at least not do so now 16:22:03 <thingee> jgriffith: what issues with migrating to v2 do you see if drivers continue with v1 in K? 16:22:11 <jungleboyj> ronenkat_: +1 16:22:15 <jgriffith> thingee: behaviors are different 16:22:30 <jgriffith> thingee: and it eliminates quite a bit of code 16:22:44 <jgriffith> thingee: so the biggest thing is it's sort of a waste of effort 16:22:59 <thingee> I think if we plan this for L-1 and give time for drivers to do a hard switch... 16:23:04 <jgriffith> thingee: the other thing is I'm not sure the current impl can even work 16:23:14 <thingee> jungleboyj, ronenkat_, patrickeast: is that possible with what's proposed? 16:23:25 <ronenkat_> jgriffith: i don't see how you reach that conclusion, v2 can be an add-on with a change to the default 16:23:29 <jgriffith> thingee: yeah, I guess if people want to write it twice that's fine 16:23:40 <jungleboyj> thingee: I was going to have GPFS fix things to not add a new config option as you had suggested. 16:23:48 <jgriffith> thingee: but I am struggling to see your distinction between "drivers in K" for V1 vs V2 16:23:53 <jungleboyj> So we were going to make our current patches as porable as possible. 16:23:58 <patrickeast> thingee: it would be a rough transition from v1 -> v2 for our driver impl, we need to add a bunch of config options and stuff for v1 that (in its current form) go away with v2 16:23:59 <jgriffith> if it's too late isn't it too late? 16:24:02 <patrickeast> its easier to just not do v1 16:24:09 <hemna> patrickeast, +1 16:24:15 <thingee> jgriffith: the only problem is review resources going towards something at this point. Drivers ultimiately are going to have to deal with the pain points of migrating to v2 in L 16:24:20 <jungleboyj> thingee: The driver pieces under the covers shouldn't be that different. 16:24:38 <jgriffith> thingee: right, I'm with you on that... but maybe I'm misunderstood 16:24:39 <ronenkat_> thingee: I think this is an apparoch, v2 can be an evolution or a revolution, I think the 1st is the right one for Cinder 16:24:58 <jgriffith> thingee: are you proposing: "Drivers are free to implement replication using V1 in Kilo still"? 16:25:32 <thingee> jgriffith: we just have ibm and pure right? 16:25:44 <jungleboyj> thingee: I think that is it at this point. 16:25:47 <thingee> if there is an understanding now that we will do a hard switch in L, sure 16:25:57 <jgriffith> thingee: sorry, still confused 16:26:09 <jgriffith> thingee: so IBM and EMC have impl's 16:26:13 <jgriffith> thingee: pure has one proposed 16:26:35 <jgriffith> thingee: I'm asking... are you accepting replication adds to drivers for K if they use V1? 16:26:46 <thingee> yeah so I'm saying if people want to do v1, and support one impl in K, and a totally different impl + migration in L, sure. 16:26:54 <xyang2> jgriffith: EMC hasn't implemented replication yet 16:26:59 <thingee> ultimiately, I think you're going to suffer with issues in this migration, fair warning. 16:27:03 <xyang2> jgriffith: we just have cg 16:27:12 <jgriffith> xyang2: oh... sorry, thought you had 16:27:21 <jgriffith> so this seems odd to me.... 16:27:25 <hemna> soren, can the purestorage folks wait for L ? 16:27:30 <ronenkat_> jgriffith: thingee: I am confused here, I see v2 as upgrade, why are you insisting otherwise? 16:27:31 <hemna> *sigh* 16:27:31 <xyang2> jgriffith: we are planning for it still 16:27:32 <hemna> so 16:27:33 <jgriffith> there's one vendor that has replication and that's it? 16:27:44 <jgriffith> you say "too late to do a V2 in Kilo" 16:27:46 <jungleboyj> thingee: Ok, so I will get our patches set up so that they are least likely to have migration issues. 16:27:56 <patrickeast> yea we are ok waiting for L, this was something that would have gone in as a “tell the customers its experimental and not to use it” anyway 16:28:01 <jgriffith> but it's not too late to try and build on somethign that is questionable? 16:28:08 <hemna> patrickeast, cool 16:28:14 <hemna> patrickeast, we are waiting for L 16:28:16 <thingee> jgriffith: let me try again 16:28:22 <hemna> so that just leaves IBM 16:28:31 <jgriffith> thingee: don't worry about it, I'm apparantly the only one that doesn't understand 16:28:32 <jungleboyj> hemna: Appears that way. 16:28:46 <hemna> soren, lets do v2 in L' 16:28:52 <hemna> IBM has to deal with the upgrade 16:28:58 <hemna> everyone else waits for L 16:29:01 <hemna> next. 16:29:15 <thingee> jgriffith: you're not going to have v2 done in time for other drivers to take advantage of it. We have IBM and pure that are interested. If they understand the proposed spec, and the migration costs of v1 to v2 and trouble of support two implementations in K and L, then fine, let them. 16:29:17 <jungleboyj> hemna: Works for me. We already have to deal with it anyway. 16:29:40 <hemna> thingee, pure just said they can wait for L 16:29:55 <thingee> even better 16:29:58 <jungleboyj> thingee: Ok. 16:29:59 <DuncanT> So we're intentionally leaving any IBM users with replication set up with an upgrade headache that they should approach IBM to sort out? (I'm fine with this, as long as it is an explicit decision) 16:30:00 <hemna> lets get v2 to land by L1 ? 16:30:06 <thingee> hemna: +1 16:30:13 <hemna> give drivers time to get replication in by L2/3 16:30:15 <hemna> next 16:30:16 <jungleboyj> thingee: Thank you. 16:30:18 <thingee> DuncanT: exactly 16:30:20 <ronenkat_> thingee: just one more topic 16:30:23 <DuncanT> thingee: Thanks 16:30:25 <jungleboyj> hemna: +1000 16:30:46 <thingee> ronenkat_: yes? 16:31:02 <ronenkat_> thingee: the updated replication spec should allow an upgrade, mainly from the APi perspective 16:31:19 <ronenkat_> thingee: of course there will be changes 16:31:32 <ronenkat_> thingee: and internally we expect the code to be different 16:31:56 <DuncanT> ronenkat_: I don't think we can guarentee API back-compat here 16:32:37 <DuncanT> ronenkat_: While I think it is fair to set that as a general aim, I'd rather pulll replication from K completely than set that in stone 16:33:01 <ronenkat_> DuncanT: I have't seen anything that would break things, I think that the new spec API is fairly compatible with the current one 16:33:16 <thingee> ronenkat_: I honestly don't understand the changes to the current API, I would have to defer to jgriffith on those details. 16:33:19 <jgriffith> ronenkat_: I don't think that's accruate 16:33:24 <ronenkat_> DuncanT: the one in the spec are basically API renames 16:33:26 <jgriffith> ronenkat_: all of your DB stuff goes away 16:33:32 <jgriffith> ronenkat_: and youre replication volumes DNE 16:33:48 <jgriffith> ronenkat_: but anyway, sounds like we have plenty of time to worry about it 16:34:01 <ronenkat_> jgriffith: I have a diffrent view - I think some would not be needed, and that is good 16:34:03 <jgriffith> ronenkat_: and who knows... V2 may just die on the vine anyway 16:34:14 <xyang2> we should take care of db migrations 16:34:23 <jgriffith> ronenkat_: oh... def not needed, but the migration is a PITA :) 16:34:28 <ronenkat_> jgriffith: no, I think v2 is a great addition to replication 16:34:30 <DuncanT> ronenkat_: I've not compared the two specs, but the point of my explicit call out about was to say that we are going to feel free to break the k replication setup in L if necessary 16:34:33 <xyang2> there are replication related columns in volumes table today 16:34:56 <jungleboyj> xyang2: +1 16:34:59 <jgriffith> xyang2: correct 16:35:04 <DuncanT> ronenkat_: Sure we try not to, but we don't block merges that do, if they are needed 16:35:33 <ronenkat_> DuncanT: I agree - we would not hinder replication, and make changes as needed 16:35:46 <DuncanT> ronenkat_: Great, thanks 16:35:47 <smcginnis> DuncanT: ronenkat_ +1 16:35:57 <thingee> anyways, here's what I'm going to propose because I would like to get to the other topics... 16:36:50 <thingee> ronenkat_, jungleboyj, jgriffith: if migration is needed...work with jgriffith on it, but don't block the v2 work for this reason. we need the general drivers to be able to use this 16:37:25 <ronenkat_> thingee: +1 16:37:26 <hemna> thingee, +1 16:37:41 <smcginnis> thingee: +1 16:37:46 <e0ne> thingee: +1 16:37:50 <thingee> jungleboyj: anything else? 16:37:51 <jungleboyj> thingee: +1 16:37:57 <DuncanT> thingee: +1 16:38:07 <jungleboyj> thingee: Nope. I think my questions have been answered. 16:38:27 <thingee> thanks again to jgriffith for once again handling a hard issue in Cinder. I'm looking forward to this. 16:38:46 <thingee> #topic Standard Capabilities 16:38:55 <thingee> #link https://review.openstack.org/#/c/150511/ 16:39:20 <thingee> we talked about the idea of having standard capabilities in K. 16:39:48 <hemna> which was a separate topic IMHO from our original proposal to help the create volume type workflow. 16:40:01 <DuncanT> hemna: +1 16:40:19 <hemna> I think both are worth ironing out and have a lot of value. 16:40:32 <thingee> there are a couple of things were trying to solve: 1) let the operator know the capabilities of a driver and 2) give horizon information to allow setting extra specs based on this information 16:40:46 <thingee> #1 sounds great across to everyone 16:40:59 <thingee> #2 seems to be a mess to introduce in Cinder. 16:41:12 <hemna> I disagree 16:41:14 <thingee> from the feedback I got in this spec. 16:41:48 <DuncanT> thingee: I think 2 can be done via something other than the capabilities scheduler update, e.g. a direct call into the driver that horizon can make 16:41:49 <thingee> we're really running out of time unfortunately, and I don't even think horizon folks will be able to account for how late we are on our side. 16:41:49 <gary-smith> I think the negative feedback is that it is also trying to solve 3) modifications to scheduling vis a vis categories 16:42:03 <thingee> I would really like to get #1 at least done by K and revisit #2 in L. 16:42:07 <thingee> annnnnnnd discuss! 16:42:10 <hemna> DuncanT, that was my original design 16:42:40 <hemna> I don't think #1 is possible for K 16:42:53 <DuncanT> hemna: Yeah, I don't understand winston-d's objections... if horizon sees a key it doesn't have help for because it popped up dynamically, then it can ask again IMO 16:43:02 <hemna> because not only does it require updating all drivers, but you'll have to modify the capabilities filter to work with the new categories. 16:43:06 <bswartz> I'm all in favor of the proposal to standardize/categorize specs -- however I don't see them as a replacement for the vendor-specific extra_specs we have today 16:43:06 <hemna> but that's my $0.02 16:43:14 <thingee> hemna: that's true 16:43:19 <bswartz> I see them as a complement 16:43:37 <hemna> honestly I think even #2 at this point is a stretch for K 16:43:43 <hemna> I'd like to do both of them 'right' 16:43:55 <hemna> and by right I mean not use the scheduler for the extra specs schema reporting 16:44:02 <tbarron1> bswartz: +1 16:44:03 <jgriffith> hemna: gary-smith DuncanT did anybody give any thought to my suggestion for an extension specifically for extra-spec key settings? 16:44:15 <hemna> I have an idea that I worked on with gary-smith yesterday that I could propose, but it's an L thing really. 16:44:16 <thingee> bswartz: I agree, but the no feedback part and people off doing their own thing. I promise to help your guys review through, but I really need feedback on this. 16:44:25 <jgriffith> hemna: gary-smith DuncanT rather than lumping it in with capability/stats report? 16:44:34 <DuncanT> jgriffith: I think that might be what I'm talking about now? 16:44:48 <DuncanT> jgriffith: And I like the idea FWIW 16:44:48 <jgriffith> DuncanT: ahh... ok 16:44:53 <hemna> jgriffith, my original idea for the schema was something outside of the scheduler 16:44:57 <hemna> we should hash it out 16:44:57 <gary-smith> jgriffith: +1 16:45:03 <bswartz> okay 16:45:08 <jgriffith> thingee: was wondering what you thought on that... and bswartz 16:45:13 <hemna> but it's not really a K thing I think at this point, given how much we already have on our plate to review. 16:45:19 <DuncanT> jgriffith: We can solve the dynamic update problem in the client if necessary... 16:45:46 <jgriffith> DuncanT: I don't necessarily understand that problem space on that TBH, but that's probably ok for now :) 16:45:51 <thingee> jgriffith: when you say extension, you mean the driver maintainers go off and make their own? 16:46:07 <jgriffith> thingee: well... I mean in cinder/api/contrib 16:46:15 <hemna> jgriffith, +1 16:46:21 <hemna> that was my original idea 16:46:23 <jgriffith> thingee: we have a "get_vendor_keys" or something 16:46:36 <DuncanT> thingee: I definitely thing that is bad, we can and should standardise it 16:46:38 <thingee> jgriffith: before I really took a hard look at what HP was proposing with this, I had some great discussions with a variety of users. Then when I read the specs, this was right inline with what people wanted to do and it got me really excited. 16:46:41 <jgriffith> thingee: and it calls a specific method in the driver to get that info 16:46:47 <thingee> wrt to understanding the problem space 16:47:01 <jgriffith> thingee: fair 16:47:02 <thingee> jgriffith: sounds fine to me 16:47:16 <jgriffith> hemna: do you have a link to where you proposed that? 16:47:20 <DuncanT> thingee: I think that we can solve loads of the overhead problems just by moving it into it's own call 16:47:38 <jgriffith> hemna: for some reason the only proposal I remember was seeing this lumped in with capabilities update 16:47:52 <hemna> jgriffith, it might be in our original spec, but this is what I had proposed in Paris 16:47:56 <hemna> and winston-d shot me down 16:48:04 <thingee> DuncanT: yeah, doesn't help the scheduler part, but I think we can at least for now leave that as hints to the driver of what to do? Which is what I think jgriffith wanted originally 16:48:11 <hemna> saying it HAD to go through the capabilities and the scheduler. 16:48:12 <jgriffith> thingee: and I would LOVE to see your spec used to set a 'standard' format 16:48:17 <hemna> which I still don't agree with, but anyway 16:48:27 <DuncanT> thingee: The scheduler doesn't care about type info AFAIK 16:48:33 <jgriffith> hemna: wait.. you're contradicting yourself 16:48:54 <jgriffith> hemna: or... maybe not, maybe I'm missing a piece 16:49:00 <thingee> DuncanT: the whole point of standard capabilities I thought was for the scheduler to filter through them 16:49:06 <jgriffith> hemna: so you mean initially you wanted this and winston-d said no? 16:49:07 <hemna> I don't agree with being forced to use the scheduler 16:49:08 <thingee> and for a nicer interface to the user 16:49:12 <hemna> correct 16:49:12 <thingee> user=ops 16:49:17 <jgriffith> hemna: for the vendor unique keys? 16:49:25 <jgriffith> hemna: I wonder why, that seems odd to me 16:49:30 <DuncanT> thingee: Sorry, I'm taking about the typing/spec stuff, not the standardisation part 16:49:33 <hemna> yup 16:49:34 <winston-d> hemna: not HAD to, i said why not use what we already have, which is scheduler stats, to help your implementation 16:50:14 <thingee> DuncanT: me too. standard capabilities would be used in extra specs I thought. 16:50:19 <jgriffith> hemna: if we isolate it to vendor-unique keys I don't see any value in the scheduler having knowledge I don't think (although my notes to thingee 's spec did in fact merge everything into the scheduler) I realized that wasn't popular so I aborted :) 16:50:46 <jgriffith> thingee: DuncanT hemna so there are two categories: 16:50:48 <hemna> yah I think that's the jist of it 16:51:00 <hemna> jgriffith, https://review.openstack.org/#/c/127646/1/specs/kilo/get-vol-type-extra-specs.rst 16:51:01 <thingee> 10 minute warning 16:51:04 <jgriffith> 1. Standard capabilities (which the scheduler knows about) non-scoped keys 16:51:07 <hemna> the first patch set talks about what we wanted to do 16:51:20 <jgriffith> 2. Vendor unique which the scheduler ignores (scoped keys) 16:51:55 <winston-d> any thing needs to be put into type definition, will have to be exposed to scheduler, that's reason i suggested we use 'scheduler-stats' to help 'user-friendly-volume-type-creation-GUI' 16:52:00 <hemna> jgriffith, and to be clear, what horizon needs to support 1 and 2 is the schema description for both 1 and 2. 16:52:09 * thingee laughs when he told gary-smith he had one minor quick addition to all of this 16:52:21 <hemna> :P 16:52:25 <gary-smith> thingee: +1 16:52:31 <DuncanT> jgriffith: 2. is what I don't like - it is unnecessarily limitting 16:52:53 <jgriffith> hmm... ok 16:52:55 <bswartz> jgriffith: there are vendor-specific keys are aren't "scoped" or "qualified", they just have a vendor_ prefix 16:53:01 <hemna> this sounds like a good topic for Vancouver. 16:53:13 <jgriffith> well, then we come back to my proposed ammendment to the spec in how the data is presented 16:53:20 <e0ne> hemna: +1 16:53:25 <jgriffith> but honestly I think I've caused enough trouble 16:53:27 <gary-smith> jgriffith: are you referring to the gist? 16:53:29 <jgriffith> I'll butt out 16:53:33 <jgriffith> gary-smith: correct 16:54:04 <hemna> jgriffith, so I think what you had in the gist was good, but having the scheduler ignore the values, is what I still had issue with. 16:54:20 <jgriffith> hemna: oh... well it doesn't have to ignore them 16:54:27 <jgriffith> hemna: they were examples, you can do both 16:54:27 <DuncanT> hemna: +1 16:54:35 <hemna> perfect. 16:54:51 <winston-d> jgriffith: vendor specific caps/keys will have to expose to scheduler, if Ops want to put them into type defintion and use them to filter out backends, scheduler is involved. 16:54:56 <bswartz> hemna: I think I agree too 16:55:05 <hemna> winston-d, yup 16:55:10 <jgriffith> winston-d: understood, I don't disagree with that 16:55:31 <smcginnis> 5 minutes 16:55:46 <thingee> Ok so what am I updating with the spec now? :) 16:55:49 <winston-d> jgriffith: yes, there are cases, e.g. 3par driver, use extra specs to customize volume, not for filtering purpose, that can be ignored in scheduler. 16:55:51 <thingee> jgriffith's solution? 16:55:51 <jgriffith> What's funny is one of the first complaints I received was that "we don't want the scheduler involved" so I added the example of scoped keys that would be ignored 16:56:05 <jgriffith> now you're saying "we want the scehduler to handle all of this" 16:56:14 <bswartz> jgriffith: we need both 16:56:20 <hemna> bswartz, yes, we need both 16:56:21 <bswartz> scoped and unscoped keys both have uses 16:56:37 <gary-smith> bswartz: +1 16:56:37 <jgriffith> bswartz: which is what I initially proposed and was met with borderline hostility 16:56:48 <bswartz> the scheduler should ignore the scoped ones like it does today 16:56:58 <bswartz> errr 16:56:58 <thingee> jgriffith: I originally took from you that you didn't want the scheduler handling it. Unless that was after you got feedback from people for the scheduler to not handle things 16:56:59 <bswartz> not from me 16:57:20 <thingee> jgriffith: that was why I had my spec that way originally 16:57:23 <hemna> bswartz, yup, and if we want to get the scheduler involved with scoped keys, we can add a new scopedkeyfilter that folks can use if they have to. 16:57:31 <jgriffith> thingee: so it seems all of us are confused :) No, I wanted what we have today basicly 16:57:42 <jgriffith> but I wanted to "improve" the standard capability stuff 16:57:45 <bswartz> hemna, why not have vendor-specific unscoped keys? 16:57:55 <bswartz> like vendor_yada_yada=foo 16:58:06 <thingee> Ok, I'll have to take the rest of this offline 16:58:10 <jgriffith> hehe 16:58:11 <hemna> k 16:58:18 <thingee> #topic other announcements 16:58:24 <jgriffith> honestly white board in Vancouver may be the only solution 16:58:29 <hemna> jgriffith, +1 16:58:31 <thingee> march 1st, code for all blueprints has to be up 16:58:36 <thingee> -2 for anything proposed past that 16:58:39 <thingee> code up means: 16:58:43 <thingee> 1) jenkins passes 16:58:48 <winston-d> bswartz: scheduler (capabilities filer actually) will treat that as capabilities 16:58:48 <thingee> 2) not marked as wip 16:59:04 <bswartz> winston-d: I know 16:59:06 <thingee> march 10th, code must be merged. 16:59:09 <thingee> -2 anything past that 16:59:19 <DuncanT> thingee: Bug fixes? 16:59:25 <bswartz> thingee: what was the feb 15th deadline we already passed for? 16:59:26 <thingee> bug fixes are still good! 16:59:37 <thingee> bswartz: heh, specs new bps 16:59:42 <bswartz> k 16:59:45 <thingee> I will -2 anything that doesn't have an approved bp 16:59:47 <thingee> targeted 16:59:48 <e0ne> thingee: what if spec is merged but bp is not targeted for K? 16:59:49 <thingee> for k-3 16:59:58 <thingee> e0ne: contact me to correct it 16:59:59 <bswartz> so no new specs now 17:00:03 <thingee> thanks! 17:00:06 <thingee> #endmeeting