16:59:15 <vilobhmm11> #startmeeting quotas-wg
16:59:15 <openstack> Meeting started Tue Apr 19 16:59:15 2016 UTC and is due to finish in 60 minutes.  The chair is vilobhmm11. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:59:17 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:59:19 <openstack> The meeting name has been set to 'quotas_wg'
16:59:26 <vilobhmm11> hello everyone
17:00:07 <amrith> hello everyone
17:00:10 <nikhil> o/
17:00:41 <nikhil> vilobhmm11: can you please highlight us on the channel, I've the courtesy reminder list added to the agenda etherpad.. thanks in advance!
17:00:41 <vilobhmm11> hi so have updated the agenda for today
17:01:03 <nikhil> #link https://etherpad.openstack.org/p/quotas-wg-meeting-agenda
17:01:10 <vilobhmm11> sure
17:01:11 <vilobhmm11> nikhil, vilobhmm, DuncanT, mc_nair, ninag, amrith
17:01:45 <vilobhmm11> nikhil : thanks for the link
17:01:49 <nikhil> yw!
17:01:58 <raildo> hey :)
17:02:02 <vilobhmm11> will wait for few min
17:02:04 <vilobhmm11> hey raildo
17:02:30 <amrith> hello all
17:02:38 <nikhil> :)
17:03:23 <vilobhmm11> alrite lets start
17:03:35 <DuncanT> Hi
17:03:45 <vilobhmm11> #topic Meetup at Summit
17:04:14 <vilobhmm11> Nikhil bought up a good point last meeting or an e-mail conversation that we should meetup on Monday
17:04:34 <vilobhmm11> before we session on Tuesday 04/26
17:05:40 <nikhil> #link http://doodle.com/poll/e4nq9tc77bdv8zwr
17:05:41 <vilobhmm11> we can meet at room 4a reserved for brown bag
17:05:41 <DuncanT> Seems like a good plan
17:05:58 <nikhil> please vote!
17:06:06 <vilobhmm11> nikhil : thanks again ! :)
17:06:14 <nikhil> np
17:07:18 <amrith> sorry, am timeslicing with a phone call
17:08:05 <vilobhmm11> as per the timings on the doodle we won't be getting the room reserved for brown bag but we can all meet near that room and then find a common one
17:08:23 <vilobhmm11> otherwise it would be very hard to find each other
17:08:49 <nikhil> vilobhmm11: yeah, true
17:09:01 <nikhil> what's the best mode of communication here? email?
17:09:24 <DuncanT> Email for me
17:09:33 <amrith> email works for me, IRC won't most of the time
17:09:38 <vilobhmm11> nikhil : email works for me too
17:09:45 <nikhil> cool
17:10:07 <vilobhmm11> so please vote on the doodle
17:10:11 <nikhil> Thanks all. will email then.
17:10:38 <vilobhmm11> we can gather votes and find a good time that works for everyone
17:10:44 <vilobhmm11> #topic Product group getting started with requirements.
17:11:08 <nikhil> (it'd be great if harlowja can join us too given he is leading the CP session)
17:11:13 <DuncanT> I've some substantial worries about this and scope creep
17:11:25 <nikhil> :)
17:11:38 <vilobhmm11> nikhil : he will join; we discussed and i will be leading the CP session
17:11:47 <DuncanT> Things like reserving quota for heat and similar - at least for cinder, that's pointless
17:11:57 <nikhil> vilobhmm11: ah k, thanks for the update.
17:12:03 <vilobhmm11> harlowja : ping
17:12:44 <nikhil> DuncanT: reserving or enforcing ? :)
17:12:50 <nikhil> or both
17:12:52 <vilobhmm11> nikhil : did request sdauge to for an update on the chair for the quota session ; should see an update soon…
17:13:10 <nikhil> vilobhmm11: excellent, thanks. I was about to ping you offline.
17:13:19 <DuncanT> nikhil: what's the point of a reservation if it is anything other than enforcing?
17:13:30 <vilobhmm11> DuncanT , nikhil : will come to reservation in a bit; its a long topic …lets cover smaller ones quickly…thanks!
17:13:42 <nikhil> ok
17:13:46 <vilobhmm11> irc://irc.freenode.net:6667/#topic : Product group getting started with requirements.
17:13:51 <vilobhmm11> irc://irc.freenode.net:6667/#topic Product group getting started with requirements
17:13:57 <DuncanT> vilobhmm11: This isn't reservations in the currnet code sense :-)
17:14:04 <nikhil> but is this particular one tied to PW
17:14:07 <vilobhmm11> ok :)
17:14:33 <vilobhmm11> shamail and other have started gathering use-cases and requirement about how people use quota and do capacity management
17:14:44 <nikhil> is there a reference document for the scope? and for worries from DuncanT?
17:14:47 <DuncanT> We've lots of terms beign thrown around, and we've still got no glossary - each mailing list thread picks its own terminology
17:15:19 <nikhil> a BIG +1 on "defining terms"
17:15:23 <vilobhmm11> this will help to strengthen the use-cases problems with current quota mgmt
17:15:31 <DuncanT> (please excuse my typing, I've substantial damage to two fingers and so it's rather tricky to type well and fast)
17:16:02 <nikhil> actually, that can be the additional info section in the spec and people _should_ refer to it while emailing
17:16:09 <vilobhmm11> coming back to nikhil and DuncanT :)
17:16:17 <DuncanT> I'm a strong proponent of matching terms to existing usage, e.g. reservation should be the code construct we already have in three projects
17:16:32 <vilobhmm11> #topic No reservation
17:16:40 <vilobhmm11> DuncanT : +1
17:17:17 <DuncanT> So first question: what do we mean by 'reservation'?
17:17:17 <amrith> I'm curious to know how we can handle quotas without reservations; the risk is that quotas are not a constraint if you don't have reservations (I THINK, AND MAY BE WRONG)
17:17:38 <amrith> DuncanT, if that's a quesiton to me, I described it in my mail to the ML
17:17:41 <vilobhmm11> having said that what it funcationaly translates to in every project and in delimiter can mean different things (if at all they are used)
17:17:46 * amrith shamlessly plugs email to the ML :)
17:17:55 <nikhil> heh
17:18:00 <DuncanT> amrith: Got a link to your mail, please?
17:18:06 <vilobhmm11> amrith : first of all thanks for the ML
17:18:30 <amrith> http://openstack.markmail.org/thread/at3phitv3oupxupi
17:18:42 <amrith> I got one comment from Jay, didn't realize it till now
17:18:44 <amrith> have to read it
17:18:57 <amrith> his comments are always very insightful
17:19:06 <vilobhmm11> yup
17:19:08 <vilobhmm11> they are
17:19:15 <vilobhmm11> in short let me brief everyone
17:19:31 <vilobhmm11> on why i am saying that even going with no-reservation can be an option
17:19:33 <nikhil> I think the advantage (and consequential disadvantages for "the other set") is that reservation is super useful if your assets/resources "DO have" a task potentially in process that is not highly elastic or distributed.
17:19:42 <DuncanT> I strongly disagree with Jay about rate limiting not being a quota thing, for the record. I'll write a reply to him soon
17:20:34 <amrith> vilobhmm11, I'm going to wait to hear what you say about no-reservations and hold off on reading Jay's comments
17:20:52 <DuncanT> In the case of cinder, a reservation is just consumed quota attached to a request i nprogress.
17:21:00 <DuncanT> in progress
17:21:30 <nikhil> exactly DuncanT, it's the "in process" part that's significant
17:21:36 <nikhil> because the race is outside of the DB
17:21:37 <vilobhmm11> DuncanT : rate limiting or rate of request mgmt can be done even by external sources like repose http://www.openrepose.org/
17:21:42 <nikhil> to elaborate on my point: Glance will not need reservation for storing images or number of images or members etc. I think the DB transaction semantics is enough.
17:21:48 <DuncanT> nikhil: There shouldn't be a race
17:22:13 <vilobhmm11> amrith : sure…in a min going through duncanT and nikhils comments
17:22:31 <DuncanT> nikhil: Assuming the semantics are implemented without bugs, there are no race differences between getting a reservation and getting commited quota before returning from the create request
17:23:08 <nikhil> I see
17:23:24 <nikhil> so, we are talking about reservation vs. quota-commit+rollback
17:23:31 <nikhil> there's the third case
17:23:34 <DuncanT> The only difference between a reservation and a commited quota usage is that the reservation can be cancelled if the consuming process dies (plus they are handy for some debugging, though not as handy as they could be)
17:23:43 <nikhil> that involved simply quota-commit on success
17:24:26 <DuncanT> You need to(Semantically) quota commit before you create the resource, or the quota is useless against DoS and similar
17:24:27 * amrith is having a hard time demultiplexing conversations
17:24:54 <nikhil> DuncanT: not necessarily
17:25:07 <nikhil> for example: image-create call in glance
17:25:18 <nikhil> it's a simple record / row creation in the DB
17:25:25 <nikhil> the only thing that we need is:
17:25:33 <nikhil> 1. create a image , update quota table
17:25:45 <DuncanT> Plus storage used....
17:25:51 <nikhil> 2. once quota is full, keep returning non availability to the users
17:26:01 <nikhil> storage is different resource
17:26:17 <nikhil> so I am breaking things down for sanity sake
17:26:21 <nikhil> 1. # images
17:26:36 <nikhil> 2. amount of data stored for all images in a cloud account
17:26:50 <nikhil> 3. # members on an image / account (depending on usage)
17:27:08 <nikhil> for #1, all we need quota commit on success
17:27:26 <nikhil> #2 is image upload for which it's a "task" or potentially long running process
17:27:28 <DuncanT> nikhil: If I can create db resources (even db records, in principle) without quota check, then in theory I can bomb the system with parallel requests
17:28:07 <DuncanT> nikhil: Glance is a pretty weird API, but the principle stands. If I have a quota of 10, it should be impossible for me to create more than 10 'things'
17:28:29 <DuncanT> nikhil: I should never have got back a 200 or a 202 from the 11th request
17:28:37 <nikhil> Glance API is that way as Nova needs it so
17:29:06 <DuncanT> nikhil: I can strongly disagree with that, but this isn't the venue  -grab me over a beer
17:29:19 <nikhil> and to your point of 10 resources, if we implement test and set for quota check in glance we don't need reservation (As the transaction can be limited to DB only)
17:30:41 <nikhil> yeah, I don't know what you are referring to with the specifics of Glance API. If you ask me , cinder shouldn't be using glance (& use something like GLARE) in the first place but then again .. not the place for that :)
17:31:13 <vilobhmm11> alrite first of all DuncanT : I agree with you on the point of *timelines for reservation and quota commit*  nikhil : just to elaborate more you can think of reservation and few quota related tables as *cache* tables for actual resource consumption. They are nothing more than that!
17:31:32 <vilobhmm11> amrith : ^^
17:31:44 <nikhil> vilobhmm11: exactly
17:31:50 <vilobhmm11> reservation and few quota tables are cache tables
17:31:50 <nikhil> and that's a race for glance
17:32:08 <amrith> vilobhmm11, I've totally lost the train of the conversation
17:32:19 <vilobhmm11> actual resource consumption happens in actual resource tables like nova.instances in nova or glance.images in glance
17:32:20 <DuncanT> The one thing about cinder and nova reservations currently is that they can auto-uncommit if the system breaks down and the creation request is  lost. That is badly done at the moment but might be a desirable property
17:32:28 <amrith> I don't know who is replying to whom/what and I'm trying to untangle the threads
17:32:41 <DuncanT> nikhil: Why is there a race?
17:33:04 <vilobhmm11> amrith : just read my last comment you will get a gist of it
17:33:08 <amrith> also, I think we're talking about the specifics of a specific service or a set of services, rather than talking about what a generic set of requirements may be for a bunch of services.
17:33:18 <amrith> vilobhmm11, I read it; I don't understand why we're talking about tables.
17:33:22 <amrith> that's an implementation detail
17:33:33 <amrith> what I want to understand is what we're going to QUOTA'ify.
17:33:40 <amrith> is it (for example) some predetermined set of resources
17:33:49 <amrith> or can each consumer of thelibrary define their own set of resources
17:34:10 <vilobhmm11> amrith : for existing project there are well defined set of resources right
17:34:15 <DuncanT> amrith: Consumers need to define their own resource set. That's a hard requirement for cinder
17:34:35 <amrith> DuncanT, I'll let you respond to that point that Jay makes (a static set of resources)
17:34:44 <amrith> ok, then there's a question on the kinds of quotas we want
17:34:45 <DuncanT> amrith: e.g. volume types (which are arbitrary in name and number) have individual quotas currently
17:34:46 <amrith> upper bound
17:34:47 <vilobhmm11> DuncanT : for existing projects too …like nova has ram, cpu, mem as resources
17:34:48 <amrith> lower bound
17:34:49 <amrith> rate
17:35:03 <vilobhmm11> DuncanT : for existing projects too ?
17:35:21 <amrith> then there's the question of what to do about resizes; should they be supported in the library or not
17:35:50 <DuncanT> We need to support all of the quota operations used in projects today, or we won't get adopted
17:35:56 <vilobhmm11> amrith : let me go over jay's reply and get back
17:36:05 <amrith> then, are these quotas to be multi-tenant or system wide
17:36:13 <amrith> vilobhmm11, this isn't about jay's email
17:36:15 <vilobhmm11> amrith, DuncanT, nikhil :strongly agree on getting the scope right for the lib
17:36:16 <amrith> I haven't read it
17:36:19 <DuncanT> Resizes are supported in projects right now (e.g. cinder), ergo we need to wupport them
17:36:37 <nikhil> vilobhmm11: yes, and we need to meet personally for that! :))
17:36:48 <vilobhmm11> nikhil : ++
17:36:59 <amrith> then there's the question of how we intend dealing with the use-case where a user (say me) may have a quota of 5 instances and comes and makes two concurrent requests for 3 instances each
17:37:06 <amrith> the first one we look at says 3 < 5, great
17:37:18 <amrith> but since no instances have been actually created, the others says 3 < 5, great
17:37:25 <amrith> and now we get 6 instances
17:37:31 <amrith> and 6 > 5
17:37:46 <amrith> we can figure out what we want to call it; reservations, preallocations, intents, ...
17:37:53 <DuncanT> amrith: That is already handled - creating a reservation consumes quota. The first to grab the quota gets created, the second doesn't
17:38:19 <nikhil> vilobhmm11: I need 5 mins for open discussion
17:38:23 <DuncanT> amrith: We can't go backwards from that sematic (we can fix the races that each project has that break those semantics)
17:38:30 <vilobhmm11> nikhil : sure
17:39:37 <amrith> so DuncanT what you are saying is that this new library is constrained by what existing projects are doing?
17:39:42 <vilobhmm11> the timeline when the reservation is commited and when the quota commit happens are the same…also the validation applies at both places…amrith : the use case you mentioned above
17:39:49 <DuncanT> amrith: That semantic *can* be implemented without any kind of reservation though, as long as you're on a single DB. You put the thing in the DB table in some 'creating' state (cinder and nova already do that) and count those as existing for quota purposes
17:40:24 <amrith> DuncanT, depending on the isolation level of your database, that may or may not work
17:40:25 <vilobhmm11> DuncanT : yup +1
17:41:00 <amrith> sorry vilobhmm11, happy to sketch it out on a whiteboard and show you why not
17:41:06 <vilobhmm11> amrith : question for you…what benefits you think that reservation is bringing right now and we might end up loosing it if it is removed ?
17:41:25 <vilobhmm11> amrith : sure
17:41:40 <amrith> I believe that the business that a service does is multi-step
17:41:48 <amrith> and that is surely the case for something like trove
17:42:01 <amrith> and therefore, being able to support multiple steps is essential
17:42:20 <amrith> and having a database transaction be long lived and assuming that this will work is fraught with danger
17:42:37 <amrith> so I'm viewing reservations as short lived database operations that help you break up the long lived database transaction
17:42:39 <DuncanT> amrith: That is *not* what reservations (as the term is currently used in the code) is all about
17:43:06 <amrith> ok, what does a reservation mean in the current usage in code
17:43:11 <DuncanT> amrith: reservations are not an externally visible thing
17:43:24 <DuncanT> amrith: They're a handle on a block of consumed quota
17:43:29 <DuncanT> That's it
17:43:41 <amrith> I think I'm describing the same thig
17:43:42 <amrith> thing
17:43:52 <amrith> not externally visible: yes
17:44:02 <amrith> a handle on a block of consumed quota: yes
17:44:09 <amrith> something that is 'in flight'
17:44:18 <DuncanT> Ok, I'm just not understanding you then
17:44:24 <amrith> to make a database instance I need an instance and a cinder volume
17:44:30 <amrith> i make a reservation for cinder
17:44:34 <amrith> then a reservation for an instance
17:44:36 <DuncanT> No.
17:44:45 <amrith> if the latter fails, I release the former
17:44:47 <DuncanT> Definitely not.
17:44:58 <amrith> sorry, I don't know what you mean by no; that's the use-case in Trove :)
17:45:09 <DuncanT> There is no concept of trove 'making a reservation' for cinder
17:45:14 <DuncanT> Currently
17:45:34 <DuncanT> Reservations are just a construct inside cinder - no external consumer sees them
17:45:36 <amrith> actually there is, but ...
17:45:42 <amrith> here is what I mean
17:45:51 <amrith> You do what you wish in cinder, that's a black box to me
17:45:53 <DuncanT> Trove asks cinder to create a volume. That's the only operation it has
17:45:57 <amrith> here are the limits that trove has
17:46:05 <amrith> no user may have more than 10 db volumes
17:46:11 <amrith> no user may have more than 10 db instances
17:46:19 <amrith> remember that the user has a nova quota of 1000 instances
17:46:25 <amrith> and a cinder quota of 500 volumes
17:46:34 <amrith> trove has its own limits ON CINDER RESOURCES
17:46:42 <amrith> that Trove has to enforce
17:46:50 <DuncanT> MY point being, the word 'reservation' has a meaning in the code now. You're using it to mean  something slightly different, and that is causing communication difficulties
17:47:02 <amrith> sorry, I'm using it to mean the same thing
17:47:08 <amrith> in the trove context
17:47:17 <amrith> I need to make a reservaton for a cinder volume
17:47:21 <amrith> and a reservation for an instnace
17:47:25 <amrith> I don't tell cinder about it
17:47:27 <amrith> you don't know
17:47:31 <amrith> I make my own reservations
17:47:43 <amrith> once I make my reservations and they all succeed, then it means the user has the quotas
17:47:50 <amrith> then I go call cinder and ask for a volume
17:47:54 <amrith> you could still fail the request
17:47:57 <amrith> no guarantees
17:48:00 <amrith> then I go ask nova
17:48:00 <DuncanT> Gah, ok, so you're talking about trove's counting of cinder volumes? That was entirely not clear
17:48:06 <amrith> it could succeed or fail
17:48:11 <amrith> sorry
17:48:27 <amrith> that was Trove's reservation for a cinder resource; not something cinder gets to know about
17:48:52 <amrith> as I said in my email, "Such a hypothetical service may also consume resources from other services that it wishes to track, and impose limits on."
17:48:55 <DuncanT> You could just commit all those reservations in trove, and release them later in exactly the same way as a delete - there's no need for a reservation
17:49:06 <nikhil> vilobhmm11: my point on defining terms  and the ill consequences of over use of the same word .. :) (in practice) (no offense to anyone, just pointing out example of mis communications)
17:49:09 <DuncanT> Just consume the resource
17:49:23 <DuncanT> BAcking out a reservation is semantically the same as deleting it
17:49:53 <vilobhmm11> nikhil : sure…but few terms which come over time should def be documented in glossary..point noted will take care
17:50:05 <amrith> Sorry DuncanT how do you intend that I do that?
17:50:20 <amrith> "just commit all those ..."
17:51:03 <DuncanT> amrith: start transaction; count (volumes where tenant id = me); if count < quota insert into volumes table state = creating
17:51:14 <DuncanT> Then do the same for the nova table
17:51:18 <amrith> DuncanT, great
17:51:23 <amrith> now let me tell you why that won't work
17:51:25 <nikhil> vilobhmm11: yes, agreed on glossary (true!, we can't really predict the future) :)
17:51:38 <amrith> to begin, what's the database isolation level? I assume read-committed?
17:51:50 <amrith> or would you like more than that?
17:51:55 <amrith> would you like repeatable read
17:51:58 <amrith> or serializable?
17:52:03 <amrith> take your pick, let me know
17:52:08 <amrith> I'm assuming read committed
17:52:12 <amrith> do we agree?
17:52:23 * amrith waits
17:52:39 <DuncanT> amrith: Honestly, I can only pick what is currently used in cinder, I've not looked the the terms for teh semantics I want for some time
17:52:46 <vilobhmm11> amrith : read-commited means read whatever is written last right
17:52:51 <amrith> NO
17:52:56 <amrith> what ever was committed last
17:52:58 <amrith> let me explain
17:53:00 <amrith> starting state
17:53:03 <amrith> 0 instances
17:53:06 <amrith> 0 volumes
17:53:08 <amrith> quota 5 of each
17:53:10 <vilobhmm11> by written i mean commited
17:53:13 <amrith> request 1: 3 instances
17:53:18 <vilobhmm11> ok
17:53:21 <amrith> begin transaction request 1
17:53:30 <amrith> transaction 1: how many instances: answer 0
17:53:40 <amrith> 0 is less than 5, insert 3 in table
17:53:47 <amrith> request 2: 3 instances please
17:53:52 <amrith> begin transaction request 2
17:54:00 <amrith> transaction 2: how many instance?
17:54:02 <amrith> answer: 0
17:54:11 <amrith> please give me 3 ...
17:54:14 <amrith> insert 3 in table
17:54:20 <amrith> transaction 1: do something about volumes
17:54:22 <amrith> commit
17:54:28 <amrith> tranaction 2: do something about volumes
17:54:29 <amrith> commit
17:54:31 <amrith> net result
17:54:33 <amrith> 6 instances
17:54:43 <DuncanT> amrith: It is my understanding that one of those transations should fail
17:54:51 <amrith> not if you run read committed
17:54:56 <DuncanT> amrith: Or at least can be constructed that way
17:55:10 <amrith> for that you increase isolation level for the db
17:55:14 <amrith> to repeatable read
17:55:17 <nikhil> amrith: yes, that was the argument I was making earlier but in non-defined terms
17:55:17 <amrith> or serializable
17:55:21 <vilobhmm11> amrith : yes won't compare and swap or test and set happen at the db level
17:55:21 <amrith> then performance issues begin
17:55:39 <DuncanT> amrith: Ok, I now understand your point. Thank you.
17:55:41 <amrith> vilobhmm11, yes, if you have the right isolation level
17:55:57 <DuncanT> amrith: I also need to go examine some cinder db atomics code
17:56:33 <nikhil> I think the openstack general rule on sql-like DBs is read committed
17:56:34 <amrith> and please read: http://dev.mysql.com/doc/refman/5.7/en/innodb-transaction-model.html
17:56:37 <nikhil> barring nova in some cases
17:56:39 <amrith> the default is read-committed for mysql
17:56:55 <amrith> yes, if you run in something more, be ready for deadlocks galore
17:57:17 <amrith> anyway, I'll reply to jay on this aspect
17:57:28 <DuncanT> amrith: So I think our best way forward is to define a python interface and its semantics and then figure out how to implement it (and stress test it)?
17:57:32 <nikhil> amrith: in glance, we explicitly implemented test&set for some update operations
17:57:48 <vilobhmm11> amrith : but in openstack context for now we are mostly concered about sql db only no *nosql* in openstack right…so sql based i.e. mysql is read-commited by default..
17:57:51 <nikhil> not sure how much of that is upstream (gah)
17:58:35 <DuncanT> nikhil: We have something similar, but I think they only operate on one table and use update...where in our case
17:58:37 <vilobhmm11> alrite guys we are running out of time
17:58:37 <harlowja> howdy
17:58:55 <nikhil> :)
17:58:56 <vilobhmm11> hello harlowja…just wrapping up
17:59:03 <nikhil> I need a few mins pls
17:59:10 <vilobhmm11> #topic open discussion
17:59:11 <harlowja> i'm around :-P
17:59:11 <harlowja> but on phone, ha
17:59:13 <nikhil> thanks
17:59:14 <vilobhmm11> yes nikhil
17:59:14 <amrith> nikhil gets 1 min
17:59:17 <nikhil> :)
17:59:19 <harlowja> ya, i'll lead, but u guys need to drive ;)
17:59:21 <harlowja> pong
17:59:22 <vilobhmm11> harlowja : np
17:59:23 <nikhil> I was just thinking..
17:59:32 <nikhil> glance midcycle is in boston/cambridge
17:59:36 <nikhil> june 15-17
17:59:51 <nikhil> I know amrith is in that area (from twitter) ?
17:59:59 <nikhil> would it be possible for others to join
18:00:09 <nikhil> may be the 14th for quotas?
18:00:18 <amrith> I will be happy to attend but 15-17 is ... I hae a board meeting on 15, I can do 16 and 17
18:00:22 <nikhil> seems to me that summit will be too short for long discussions
18:00:27 <amrith> I can do 14th
18:00:36 <amrith> but I'd prefer 16th or 17th
18:00:48 <DuncanT> That's a long flight for me, I'm unlikely to get funding
18:00:56 <nikhil> umm, let me ask shamail too
18:01:05 <nikhil> I can arrange for remote attendance
18:01:16 <nikhil> all I need is your full attention for half a day
18:01:18 <DuncanT> remote is certainly doable
18:01:33 <vilobhmm11> nikhil : need to check about funding..otherwise can join via hangouts
18:01:38 <DuncanT> It will have to be morning though - I'm at GMT+2/3
18:01:39 <amrith> should we move to #openstack-quota?
18:01:45 <nikhil> something that you can block in your .cal and let mgmt know unavailability for that time
18:01:57 <nikhil> sure
18:02:00 <vilobhmm11> sure
18:02:02 <nikhil> we can discuss this at the summit
18:02:04 <nikhil> food for thought
18:02:09 <vilobhmm11> lets move to #openstack-quota
18:02:10 <nikhil> thanks all!
18:02:14 <vilobhmm11> thanks!
18:02:15 <vilobhmm11> #endmeeting