16:00:21 <jgriffith> #startmeeting
16:00:22 <openstack> Meeting started Wed Jul 11 16:00:21 2012 UTC.  The chair is jgriffith. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:00:23 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:00:38 <jgriffith> Ok, who's here?
16:01:15 <jgriffith> Huuuhhh.. noone!
16:01:22 <thingee> o/
16:01:49 <fergal> here
16:02:06 <rnirmal> I'm here, but will be silent for a few mins
16:02:18 <jgriffith> Ok, I'll get started then
16:02:29 <jgriffith> #topic core status update
16:02:45 <Mandell> Here
16:02:50 <winston-d> here
16:02:56 <jgriffith> Most of you may have heard/seen we're now a core project in Openstack as of yesterdays PPB meeting
16:03:06 <Mandell> Yay :)
16:03:10 <jgriffith> :)
16:03:20 <jgriffith> Yes, very cool!
16:03:53 <jgriffith> There are some significant details that need to be sorted out regarding the existing Nova Volume code
16:04:02 <Vincent_Hou> cool
16:04:11 <Mandell> I saw vishy's note.
16:04:27 <jgriffith> Check your emails and respond, preferrably +1 option 1
16:04:42 <winston-d> already done that
16:04:52 <jgriffith> Keep in mind we all have features in mind and we're spread thin already, maintaining two projects is not going to help
16:05:00 <jgriffith> winston-d: Yes, I saw your vote :)
16:05:13 <winston-d> :)
16:05:22 <jgriffith> So now that we're core that brings up the official business we're going to need to conduct
16:05:42 <jgriffith> We'll need to wipe out the existing core team and strat over officially
16:05:51 <jgriffith> s/strat/start/
16:06:00 <jgriffith> We'll also need to have a PTL election
16:06:25 <jgriffith> I'm a bit concerned about the core team part....
16:07:12 <jgriffith> I don't want to end up with NO core team members in Cinder :)
16:07:30 <winston-d> I don't think that would happen. :)
16:07:31 <jgriffith> And I don't want these extra things to hinder progress
16:07:32 <Mandell> That would be less than optimal.
16:08:02 <jgriffith> So I'm wondering what people think in terms of timing?  Should we start the process this week?
16:08:18 <jgriffith> (For both core team setup and PTL election)
16:08:44 <winston-d> that works for me.
16:09:00 <jgriffith> any objections/concerns from anybody?
16:09:07 <winston-d> and i agree we should start early to settle things down
16:09:10 <DuncanT> No objections
16:09:20 <jgriffith> winston-d: Yes, I think that's an excellent point
16:09:42 <jgriffith> Ok, I'll start moving forward with that whole process
16:10:12 <rnirmal> +1 for that, lets get it kicked off
16:10:35 <jgriffith> One thing I'll have to clear up is if we then have to have another PTL election at F3 anyway, in which case maybe that part we just wait and do it once
16:10:46 <rnirmal> but remember doing so is likely at the minimum a one week downtime in getting in new code
16:10:55 <jgriffith> I'll have to figure out the details on the "rules"
16:11:11 <jgriffith> rnirmal: I'm hoping we can avoid that
16:11:23 <jgriffith> rnirmal: We can't afford that TBH
16:11:36 <rnirmal> yeah that's what I'm getting at
16:11:41 <jgriffith> I think we leave existing setup in place until official results are in
16:11:51 <jgriffith> Then we switch it up and move on
16:12:01 <rnirmal> ok sounds better :)
16:12:38 <jgriffith> We'll still have to bend the rules a bit regarding code submissions to Cinder, but I'd propose code submissions/reviews to Nova be accepted the same
16:13:02 <jgriffith> Any questions, advice, concerns ?
16:13:48 <jgriffith> BTW some other good things that are happening are we're working on Tempest integration
16:14:07 <bswartz> is cinder going to stick with the same milestones/deadlines as nova?
16:14:08 <winston-d> great!
16:14:30 <jgriffith> bswartz: Yes!  Those milestones/deadlines are Openstack not Nova specific
16:14:49 <jgriffith> bswartz: We've already been adhering to those, that's what we had to demonstrate to become Core
16:15:24 <jgriffith> So just to be clear, all fo the same processes, rules, schedules, milestones etc
16:15:53 <jgriffith> Ok, any questions about being a core project?
16:16:13 <galthaus_> Does that mean it will be in the folsum release?
16:16:25 <winston-d> i think so
16:16:25 <jgriffith> galthaus_: Yes
16:16:28 <galthaus_> Or tied to it, I should say.
16:16:46 <galthaus_> Faster than expect, but good.
16:16:51 <jgriffith> galthaus_: I mentioned earlier in the meeting check your emails for the thread on what to do with Nova-V
16:17:12 <jgriffith> galthaus_: Vote for option 1 please, unless you have a real concern that hasn't been addressed
16:17:17 <jgriffith> :)
16:18:01 <jgriffith> galthaus_: I'll let you catch up on my pitch there via the logs :)
16:18:26 <jgriffith> #topic Status
16:18:52 <jgriffith> So now for status of the code and 'real' work....
16:19:29 <jgriffith> There's been a bit going on and some new folks getting involved ( winston-d thingee )
16:19:39 <jgriffith> welcome!  :)
16:19:51 <thingee> hello all!
16:20:16 <jgriffith> I've taken a first pass at cleaning up the DB
16:20:23 <DuncanT> How did the Tuesday hackday thing go? We didn't hear anything about it and I was out sick so didn't chase...
16:20:34 <jgriffith> DuncanT: It went pretty well
16:20:53 <jgriffith> DuncanT: Had a chance to share some really good ideas about direction of the project and design
16:21:08 <rnirmal> jgriffith: didn't see any new code from the hackday though
16:21:34 <jgriffith> rnirmal: Yeah, so there are things that were started but not "finished"
16:21:44 <jgriffith> rnirmal: My db code was done at that hack day
16:21:58 <rnirmal> ok cool
16:22:15 <jgriffith> jmckent started working on the openstack.common/logging port
16:22:28 <jgriffith> a number of folks did some devstack testing/work
16:22:37 <jgriffith> Renuka did some Xen verification
16:22:57 <jgriffith> _0x44 is working on bug: 1008866
16:23:33 <jgriffith> All in all there was some good effort taking place, just not a lot has landed (yet) :)
16:23:58 * rnirmal looking forward to all that
16:24:09 <jgriffith> I'd like to try and set something up again in the future
16:24:28 <jgriffith> If nothing else, it's good to get everybody in a room face to face and discuss ideas inbetween summits
16:25:05 <rnirmal> jgriffith: tomorrow is bug squash day, if people plan to meet
16:25:32 <jgriffith> rnirmal: yes, I am hoping that folks here will be available and join in!
16:26:10 <jgriffith> Unfortunately the're something broken in devstack right now and it could make squash day a bit difficult :(
16:26:28 <jgriffith> The devstack exercises.sh tests fail
16:26:42 <jgriffith> Except on the RS jenkins cloud
16:26:53 <jgriffith> Don't know why that is though....
16:27:30 <jgriffith> Actually if any of you here have a chance to spin up devstack on your systems and run exercises.sh today it would be very helpful in trying to isolate what's going on
16:27:59 <winston-d> i can do that
16:28:09 <jgriffith> winston-d: Fantastic!
16:28:27 <jgriffith> #action winston-d to try and run devstack exercises.sh
16:28:54 <jgriffith> So the issue isn't Cinder related by the way... so you can even run just the default nova-vol
16:29:03 <jgriffith> it appears to be a networking related issue, but not sure
16:29:48 <jgriffith> Ok... so the other thing that needs to happend SOON is we need to work with the devstack team to make Cinder the default :)
16:29:51 <winston-d> ok, noted. i'll take a look at that
16:30:08 <jgriffith> I'll get with dtroyer today and try to make that happen
16:30:22 <jgriffith> Or submit the change and see if they accept it :)
16:30:34 <Vincent_Hou> remove n-vol?
16:30:37 <galthaus_> yyeah - that was more my question.
16:31:04 <sdague> jgriffith: question, we've got a team that's got a volume driver almost ready to submit. I assume we should forgo nova and submit straight to cinder at this point?
16:31:16 <jgriffith> Vincent_Hou: galthaus_: It doens't remove it, but rather than modify localrc to use Cinder, Cinder would be default and you'd modify localrc to use Nova-vol
16:31:33 <rnirmal> swap the default
16:31:51 <jgriffith> sdague: So it sort of depends on how the email thread regarding how to proceed with nova-volumes goes
16:31:54 <winston-d> sdague, i believe so if n-vol is to be removed.
16:31:57 <galthaus_> okay - so shouldn't that be a "bug" and reviewed fix to the devstack "project"
16:32:04 <Vincent_Hou> yes, i was trying cinder recently
16:32:11 <jgriffith> sdague: To be honest depending on your driver you might want to do both as it could be just a duplicate
16:32:12 <sdague> jgriffith: well, where would you like to see it land first :)
16:32:23 <jgriffith> sdague: Well Cinder of course :)
16:32:51 <jgriffith> galthaus_: Sorry, what do you mean?
16:33:05 <sdague> I assume it's going to need some community review before it gets in, so instead of managing 2 branches, encouraging them to hit one tree first where it will get the most active review, then port accross later to other trees if it makes sense
16:33:32 <rnirmal> jgriffith: sdague: any new driver should probably just go in cinder
16:33:35 <galthaus_> jgriffith: working with dtroyer is the polite thing to do.  But you could also start with a proposal of change of default as well. right?
16:33:41 <sdague> ok, good, I'll tell them that
16:33:47 <galthaus_> rnimral: +1
16:33:47 <rnirmal> we had this discussion a while back on bug fixes only back into n-vol
16:33:48 <jgriffith> galthaus_: Ahhh... got ya
16:34:07 <galthaus_> rnirmal: sorry about name
16:34:19 <rnirmal> galthaus_: no harm done
16:34:53 <jgriffith> galthaus_: Yeah, should probably be a blueprint though
16:35:11 <Vincent_Hou> Does cinder have more features than n-vol now? I mean moving more advanced?
16:35:21 <thingee> jgriffith: +1
16:35:26 <rnirmal> Vincent_Hou: not yet
16:35:30 <jgriffith> Vincent_Hou: not yet
16:35:42 <jgriffith> Vincent_Hou: But I hope to by F3
16:35:52 <Vincent_Hou> cool
16:36:25 <jgriffith> Vincent_Hou: That's part of the problem, if we have to maintain both code bases it will make it very difficult and unlikely to get new features going
16:37:38 <jgriffith> Ok, any questions about 'status'
16:38:08 <jgriffith> Moving on to "blueprints" if there are no questions?
16:38:20 <jgriffith> #topic outstanding blueprints
16:38:22 <winston-d> so i'm working on openstack-common stuff
16:38:48 <winston-d> jgriffith, sorry, you can move forward with blueprints
16:38:54 <jgriffith> winston-d: Excellent!! Let's get a blueprint submitted and assigned to you on that today
16:39:28 <jgriffith> winston-d: Have you started that work or do we need to talk about it offline after the meeting?
16:39:54 <rnirmal> jgriffith: there's already a blueprint for it
16:40:01 <jgriffith> Just so everybody knows, the idea here is that we've been left in the dust in terms of things Nova has started using out of openstack.common
16:40:05 <rnirmal> #link https://blueprints.launchpad.net/cinder/+spec/use-openstack-common-in-cinder
16:40:12 <jgriffith> I'd like to get up to speed with them
16:40:27 <jgriffith> rnirmal: Yeah, thanks... I wrote it :)
16:40:28 <winston-d> i've started timeutils a little bit.  and yes, we can talk about it offliine
16:40:40 <jgriffith> rnirmal: But it's a bit "vague" needs details and an assignee
16:41:06 <jgriffith> winston-d: Ok, sounds good... we'll chat
16:41:24 <jgriffith> Mandell: Do you know where Josh is at with the logging changes?
16:41:49 <rnirmal> jgriffith: I can add some details to it, I'll update it
16:42:01 <jgriffith> rnirmal: Awesome... thanks!
16:42:13 <jgriffith> https://blueprints.launchpad.net/cinder/+spec/cinder-common-logging
16:42:37 <Mandell> jgriffith: He has a working branch and I should be able to rebase it for him and get it submitted for review.
16:43:00 <jgriffith> Mandell: Awesome!!  So winston-d the logging should be covered :)
16:43:10 <winston-d> good :)
16:43:21 <jgriffith> So this is going to be a pretty big patch, if we need to break it down into pieces that might be a good idea
16:43:41 <jgriffith> Even taking each openstack.common class per patch
16:43:58 <rnirmal> I think that would be ideal and easier for people to review too
16:43:58 <jgriffith> That way if folks have bandwidth there's an easy way to figure out how to help
16:44:16 <jgriffith> rnirmal: yeah, reviewers would greatly appreciate it
16:44:23 <Mandell> rnirmal: agreed!
16:44:25 <jgriffith> Let's plan on going that route
16:44:27 <winston-d> i plan to submit multiple patches, timeutils as one, policy, json.., etc.
16:44:36 <jgriffith> winston-d: Perfect
16:44:55 <winston-d> that's be easier for me too. :)
16:45:04 <jgriffith> :)
16:45:17 <jgriffith> So the other big things are Availability Zones and Quotas :(
16:45:30 <jgriffith> I'm going to bring up the Quotas thing again while we're all here
16:45:51 <jgriffith> I think there was some misunderstanding regarding my submission Monday
16:46:05 <jgriffith> That patch was specifically DB/API cleanup
16:46:20 <jgriffith> Not trying to solve the Quotas issue yet
16:46:54 <jgriffith> For that I'm proposing that quota information stays in Nova, based on how the objects are designed it's the only thing that makes sense right now
16:47:23 <jgriffith> We'd then have to add a method in cinder/ that checks that info from Nova on volume_create
16:47:34 <jgriffith> That would also require updating th counts etc
16:47:56 <jgriffith> I've talked with thingee about this a bit and I think we're worked out some good ideas/details
16:48:20 <jgriffith> We talked about a new home including possibly ceilometer etc
16:48:32 <renuka> jgriffith: did the keystone switch turn out to be too much at this point?
16:48:39 <jgriffith> But... until Nova does it we're still just duplcating cod
16:48:40 <jgriffith> code
16:48:51 <jgriffith> renuka: The keystone switch...
16:48:55 <thingee> jgriffith: thinking about it more yesterday and thanks to dhellmann too, it would be an additional request if we kept it on nova, versus keystone. We're already sending an auth request to keystone so we can include a request for quota info
16:49:00 <jgriffith> So for those that don't know
16:49:03 <thingee> that does make the call more complex imo though
16:49:06 <thingee> more things to go wrong
16:49:39 * jgriffith looking for link to keystone quota blueprint
16:49:41 <renuka> thingee: i dont understand.
16:50:05 <renuka> thingee: why does making the quota request to keystone (versus nova) make the call more complex?
16:50:06 <jgriffith> #link https://blueprints.launchpad.net/keystone/+spec/store-quota-data
16:50:17 <renuka> policy would need to be in keystone after all
16:50:36 <thingee> renuka: you're now make a single request that used to just do auth now do auth and quota check
16:50:55 <jgriffith> renuka: I think wht thingee  is getting at is we already talk to keystone, but we don't have any hooks to nova
16:51:04 <jgriffith> thingee: Sorry... I'll let you speak for yourself :)
16:51:12 <winston-d> but quota is stored in nova db?
16:51:33 <jgriffith> winston-d: Right now it is yes, but that blueprint proposes changing that
16:51:36 <renuka> At the moment, which is not the right thing to do anyway, so they are working on moving it to keystone
16:51:53 <jgriffith> So here's my problem with the keystone method:
16:52:04 <thingee> winston-d: correct. to be more clear, keystone wouldn't enforce the quota, cinder's api should
16:52:08 <jgriffith> I have not been able to get a hold of Everett to find out how that's going
16:52:20 <jgriffith> My fear is that it won't be ready in the near future
16:52:50 <thingee> winston-d: keystone is just providing the quota for tenant/user. Cinder then has to ask whatever backend what they're currently at
16:53:01 <renuka> thingee: i disagree.. keystone is where policy should go. Different providers may have different rules for quota
16:53:15 <jgriffith> If anybody knows Everett's IRC handle or a way to contact him it would be great if we could get a status and see if we can help or at least let him know that we think this blueprint would GREAT to have implemented
16:53:35 <thingee> renuka: I agree it should be in central place. I just don't think keystone is the right place.
16:53:44 <renuka> why?
16:53:49 <winston-d> the keystone-quota blueprint, will it land before folsom?
16:53:55 <jgriffith> renuka: You mean you think keystone should enforce it as well as hold the information?
16:54:06 <jgriffith> winston-d: That's the problem, I don't know
16:54:35 <thingee> jgriffith. renuka: I agree that whatever is storing the quotas should enforce it as well. less dup code on the different api code
16:54:59 <renuka> Well keystone's description clearly says it "provides Identity, Token, Catalog and Policy services"
16:55:24 <creiht> Isn't that more of a general openstack question as to where quotas belong?
16:55:38 <jgriffith> creiht: yes
16:55:50 <galthaus_> Should enforcement be in Keystone?  Wouldn't that mean a lot of calls to keystone?
16:55:54 <creiht> has "openstack" decided they belong in keystone?
16:56:02 <jgriffith> creiht: And I'd also argue that it's up to them to figure out how to get that accepted and how it's implemented
16:56:04 <renuka> I got the impression that since we have an approved blueprint, it was agreed that it belongs in keystone... but i could be wrong
16:56:13 <thingee> galthaus_: the point is it would be tied in with the auth request we would already be making
16:56:15 <jgriffith> As well as exactly what their responsibilities are
16:56:22 <jgriffith> After that we follow suite
16:56:40 <thingee> but it is making the request more complex. Having the quota stuff on some other project however, is an additional request
16:56:55 <galthaus_> thingee: doesn't that assume a 1-to-1 action to auth request setup.  Are we maintaining that?
16:56:59 <jgriffith> renuka: I would "think" that is true, but I don't know
16:57:04 <creiht> It seems until there is official support for quotas in keystone, you shouldn't try to rely on it being there
16:57:12 <Mandell> Since we're core, what we need to be sure of is that we work with the correct openstack way of doing quotas at the end of folsom.
16:57:16 <creiht> You should probably go ahead and implement quotas
16:57:21 <jgriffith> creiht: And there's my point :)
16:57:26 <thingee> renuka: I think you make an excellent point on the description of keystone though
16:57:27 <creiht> cool
16:57:35 <creiht> :)
16:57:54 <jgriffith> My proposal is that unless we hear something different regarding the status, we implement it with a check back to Nova for now
16:58:00 <winston-d> hey creiht :) didn't notice you were here.
16:58:07 <jgriffith> Then if this lands we do the same patch work that everybody else is goign to have to do
16:58:16 <renuka> jgriffith: how does that not make the request more "complex"
16:58:17 <rnirmal> I still disagree using nova for the quotas
16:58:32 <creiht> winston-d: just lurking
16:58:43 <jgriffith> renuka: Regardless of whether it's more complex or not, right now you can't even do it
16:58:43 <thingee> I have to drop for a second everyone
16:59:09 <rnirmal> the quota code could land in common with the projects maintaing it in their respective dbs still something common lands
16:59:22 <jgriffith> rnirmal: Why?  I have a hard time stomaching duplicating all of that code and trying to keep it in synch
16:59:27 <DuncanT> renuka: You can't generally cache the result of a quota check for starters, where as you can an auth check
16:59:38 <rnirmal> well the only duplication would be the db tables
16:59:44 <renuka> jgriffith: so lets just agree that complexity has nothing to do with this decision ;) We are making a quick fix, which will be changed in the future... because we can certainly not depend on nova to do policy checking for cinder
16:59:47 <rnirmal> if we can get the code in openstack-common
16:59:48 <jgriffith> rnirmal: But all of the "real" code is actually the DB code itself so what does that buy you?
16:59:55 <rnirmal> true
17:00:17 <rnirmal> but talking to nova doesn't fell right either for the quotas
17:00:19 <jgriffith> renuka: I htink that may be a reasonable summary
17:00:46 <thingee_zz> renuka: what was the summary, sorry, dropped.
17:01:09 <jgriffith> 10:59 < renuka> jgriffith: so lets just agree that complexity has nothing to do with this decision ;) We are making a  quick fix, which will be changed in the future... because we can certainly not depend on nova to do  policy checking for cinder
17:01:18 <renuka> thingie_zz: we will depend on nova for quotas as a quick and dirty way of doing things
17:01:42 <jgriffith> So there's one other option that people may liek btter
17:01:51 <jgriffith> like better (stupid keyboard)
17:01:52 <renuka> thingie_zz: which we will change to the appropriate policy manager, keystone or otherwise, asap
17:02:18 <jgriffith> Implement our own version temporarily, becuase copying the nova version is overkill
17:03:32 <thingee_zz> +1
17:04:02 <renuka> jgriffith: thats more correct, and more work
17:04:20 <DuncanT> +1 for our own version... less ocuplign with nova is better
17:04:21 <creiht> possibly more work, certainly less cruft :)
17:04:25 <DuncanT> *coupling
17:04:29 <jgriffith> renuka: Well, may not be more work
17:04:33 <renuka> so overall, +1
17:04:42 <winston-d> +1
17:04:45 <creiht> and I think that is probably the best route
17:04:57 <creiht> especially considering the timeline you guys are looking at
17:04:58 <jgriffith> The reason I say that is that the implementation in Nova has to deal with Cores, instances blah blah blah
17:05:15 <jgriffith> We have to deal with volume count and space utilization
17:06:06 <jgriffith> Ok... so it sounds like we're leaning towards our own temporary implemenation?
17:06:16 <jgriffith> thingee: are you puking?
17:06:23 <winston-d> :)
17:06:26 <Vincent_Hou> Does other projects have the same quota issue except cinder?
17:06:35 <thingee> (in two meetings)
17:06:42 <jgriffith> Vincent_Hou: Nope,not yet at least
17:07:03 <winston-d> quantum should have some problem i guess
17:07:06 <jgriffith> It's only in NOva right now, but I suspect quantum will need to figure it out too
17:07:12 <renuka> jgriffith: any idea what quantum does
17:07:16 <creiht> yeah I was just wondering about what quantum does for it
17:07:48 <jgriffith> renuka: Right now I don't see anything regarding quotas in their code, but I will ask dwent about it
17:08:22 * creiht has to run
17:08:35 <rnirmal> also swift most likely has it's one quotas
17:08:38 <winston-d> creiht, see u
17:09:17 <winston-d> swift is different, it is like totally separate/standalone service
17:09:40 <renuka> winston-d: the idea is for cinder to be completely standalone
17:09:42 <winston-d> and has nothing to do with nova
17:09:45 <jgriffith> Actually swift may not be a bad model to look at
17:09:53 <jgriffith> we're trying to do the same sort of thing
17:10:17 <winston-d> but cinder/volume only works when attached to instance.
17:10:29 <jgriffith> winston-d: nope
17:10:38 <jgriffith> winston-d: The idea is to be a standalone block service
17:10:46 <renuka> jgriffith: which also leaves me concerned about attach/detach, so could we talk about that at some point (continuing from the email)
17:10:49 <jgriffith> winston-d: BSaaS
17:11:13 <jgriffith> renuka: k, we'll do that next
17:11:24 <Vincent_Hou> work independently?
17:11:38 <jgriffith> Vincent_Hou: Well, to an extent
17:11:49 <Vincent_Hou> it sounds cool
17:11:50 <jgriffith> Vincent_Hou: The idea is that anybody could use Cinder to manage block storage
17:11:52 <winston-d> i see. lookin' forward to that
17:12:05 <jgriffith> Then do whatever they want with it, it doesn't have to be Nova only
17:12:18 <jgriffith> Could be any openstack project or even something outside of openstack
17:12:24 <jgriffith> Alright....
17:12:47 <jgriffith> #action jgriffith do some more research and come up with prototype of quota implementation
17:12:58 <jgriffith> renuka: attach/detach?
17:13:02 <rnirmal> oh we are already overtime
17:13:14 <jgriffith> Oh wow... way over time!
17:13:19 <renuka> perhaps we continue it on the email thread :)
17:13:37 <jgriffith> Works for me.. or in #cinder
17:13:42 <rnirmal> yes I had some comments, I'll reply to that email thread
17:13:49 <jgriffith> Sorry we went so long
17:13:50 <renuka> sounds good
17:13:57 <winston-d> could you guys keep in me the loop if you want to do that in email?
17:13:57 <jgriffith> Thanks everyone!
17:14:00 <jgriffith> #endmeeting