saction:
>>>>
>>>> provider := SELECT id, generation, ... FROM
>>>> resource_providers
>>>> JOIN (...)
>>>> WHERE ()
>>>>
>>>> for resource i
On 23 Apr 2016 14:26, "Jay Pipes" wrote:
> On 04/23/2016 03:18 PM, Mike Perez wrote:
>> How about extending a volume? A volume is a resource and can be extended
in
>> Cinder today.
>
>
> Yep, understood :) I recognize some resource amounts can be modified for
some resource classes. How about *sh
On Apr 23, 2016, at 3:10 PM, Jay Pipes wrote:
>
> Looking forward to arriving in Austin so that I can buy you a beer, Amrith,
> and have a high-bandwidth conversation about how you're wrong. :P
Beer is a great addition to any conversation!
-- Ed
___
On Apr 23, 2016, at 3:10 PM, Jay Pipes mailto:jaypi...@gmail.com>> wrote:
> BTW, note to Ed Leafe... unless your distributed data store supports
> transactional semantics, you can't use a distributed data store for these
> types of solutions. Instead, you will need to write a whole bunch of code
On 15:25 Apr 23, Jay Pipes wrote:
> On 04/23/2016 03:18 PM, Mike Perez wrote:
> >On 14:54 Apr 18, Jay Pipes wrote:
> >>On 04/16/2016 05:51 PM, Amrith Kumar wrote:
> >>> - update_resource(id or resource, newsize)
> >>
> >>Resizing resources is a bad idea, IMHO. Resources are easier to deal w
On 04/23/2016 03:25 PM, Jay Pipes wrote:
> On 04/23/2016 03:18 PM, Mike Perez wrote:
>> On 14:54 Apr 18, Jay Pipes wrote:
>>> On 04/16/2016 05:51 PM, Amrith Kumar wrote:
- update_resource(id or resource, newsize)
>>>
>>> Resizing resources is a bad idea, IMHO. Resources are easier t
On Sat, 2016-04-23 at 15:25 -0400, Jay Pipes wrote:
> On 04/23/2016 03:18 PM, Mike Perez wrote:
> > On 14:54 Apr 18, Jay Pipes wrote:
> >> On 04/16/2016 05:51 PM, Amrith Kumar wrote:
> >>> - update_resource(id or resource, newsize)
> >>
> >> Resizing resources is a bad idea, IMHO. Resource
On 04/23/2016 03:18 PM, Mike Perez wrote:
On 14:54 Apr 18, Jay Pipes wrote:
On 04/16/2016 05:51 PM, Amrith Kumar wrote:
- update_resource(id or resource, newsize)
Resizing resources is a bad idea, IMHO. Resources are easier to deal with
when they are considered of immutable size and
On 14:54 Apr 18, Jay Pipes wrote:
> On 04/16/2016 05:51 PM, Amrith Kumar wrote:
> > - update_resource(id or resource, newsize)
>
> Resizing resources is a bad idea, IMHO. Resources are easier to deal with
> when they are considered of immutable size and simple (i.e. not complex or
> nested
On 04/22/2016 09:57 PM, Tim Bell wrote:
I have reservations on f and g.
Probably not the *best* choice of words to describe your concerns, Tim :P
-jay
__
OpenStack Development Mailing List (not for usage questions)
Unsubs
11:19 AM
> To: openstack-dev@lists.openstack.org
> Subject: Re: [openstack-dev] More on the topic of DELIMITER, the Quota
> Management Library proposal
>
> On 04/22/2016 07:51 AM, Amrith Kumar wrote:
> > If it doesn't make it harder, I would like to see if we can make
On 04/22/2016 07:51 AM, Amrith Kumar wrote:
If it doesn’t make it harder, I would like to see if we can make the
quota API take care of the ordering of requests. i.e. if the quota API
is an extension of Jay’s example and accepts some data structure (dict?)
with all the claims that a project wants
> From: Jay Pipes [mailto:jaypi...@gmail.com]
>>> Sent: Thursday, April 21, 2016 8:08 PM
>>> To: openstack-dev@lists.openstack.org
>>> Subject: Re: [openstack-dev] More on the topic of DELIMITER, the Quota
>>> Management Library proposal
>>>
>&
#Data+Access
Amrith Kumar wrote:
Inline below ... thread is too long, will catch you in Austin.
-Original Message-
From: Jay Pipes [mailto:jaypi...@gmail.com]
Sent: Thursday, April 21, 2016 8:08 PM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] More on the topic of DELI
uld not but this email thread has got too long. Yes,
simpler interface, will catch you in Austin.
> Best,
> -jay
>
> On 04/19/2016 09:59 PM, Amrith Kumar wrote:
> >> -Original Message-
> >> From: Jay Pipes [mailto:jaypi...@gmail.com]
> >> Sent: Monday, A
m: Jay Pipes [mailto:jaypi...@gmail.com]
Sent: Monday, April 18, 2016 2:54 PM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] More on the topic of DELIMITER, the Quota
Management Library proposal
On 04/16/2016 05:51 PM, Amrith Kumar wrote:
If we therefore assume that this will
al Message-
From: Jay Pipes [mailto:jaypi...@gmail.com]
Sent: Monday, April 18, 2016 2:54 PM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] More on the topic of DELIMITER, the Quota
Management Library proposal
On 04/16/2016 05:51 PM, Amrith Kumar wrote:
If we therefore assume
Jay, thanks for the detailed comments. Detailed responses follow.
-amrith
> -Original Message-
> From: Jay Pipes [mailto:jaypi...@gmail.com]
> Sent: Monday, April 18, 2016 2:54 PM
> To: openstack-dev@lists.openstack.org
> Subject: Re: [openstack-dev] More on the topic of
On 04/16/2016 05:51 PM, Amrith Kumar wrote:
If we therefore assume that this will be a Quota Management Library, it
is safe to assume that quotas are going to be managed on a per-project
basis, where participating projects will use this library. I believe
that it stands to reason that any data p
First, let me thank Vilobh, Nikhil, Duncan and others who have been
working on this quota management library/service issue. Recently there
have been a number of threads [1], [2], [3] on the subject of quotas and
quota management. This email is partially in response to [3] but since
it is too long f
20 matches
Mail list logo
