Re: [openstack-dev] [cross-project][quotas][delimiter] Austin Summit - Design Session Summary

2016-05-15 Thread Mike Perez 
On 16:06 May 14, Nikhil Komawar wrote:
> On 5/14/16 2:35 PM, Mike Perez wrote:
> > Reading this thread, Nikhil who is speaking for the quota team is worried 
> > about
> > the amount of overhead caused by governance, instead of first focusing on
> > making something actually exist. I see quite a few people in this thread
> > speaking up that it should be part of the big tent either standalone or oslo
> > lib.
> >
> > I can't speak for the Oslo folks, but as a member of the TC here are the
> > requirements for the standalone route [1]. You would propose an agenda item 
> > to
> > the TC, and we would review that the project meets those requirements.
> > Considering the project does Open Design and has an Open Community - my 
> > guesses
> > on "probably would be followed" is Open Development and Open Source since we
> > don't have anything but a specification that exists to go off of.
> >
> > It sounds like the biggest hang up in going the oslo route is the oslo 
> > spec. So
> > question to the oslo folks, would you be interested in reviewing the
> > cross-project specification and allowing to be an oslo lib? That way the 
> > team
> > can focus on working on the library, and the community is happy it's part of
> > OpenStack already.
> >
> >
> >
> 
> Thanks Mike for helping us move forward.
> 
> After having been suggested yesterday, I have added this agenda item for
> the Oslo team meeting to get the answers
> https://wiki.openstack.org/wiki/Meetings/Oslo#Agenda_for_Next_Meeting .
> 
> Also, can you please re-reference as the link did not come through?

[1] - http://governance.openstack.org/reference/new-projects-requirements.html

-- 
Mike Perez

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [cross-project][quotas][delimiter] Austin Summit - Design Session Summary

2016-05-14 Thread Nikhil Komawar 



On 5/14/16 2:35 PM, Mike Perez wrote:
> On 18:46 May 12, Nikhil Komawar wrote:
>> I realized that I missed one of your questions earlier. Response for
>> that inline.
>>
>>
>> On 5/12/16 4:58 PM, Nikhil Komawar wrote:
>>>
>>> On 5/12/16 4:33 PM, Doug Hellmann wrote:
 Excerpts from Nikhil Komawar's message of 2016-05-12 15:40:05 -0400:
> Please find my response inline:
>
> On 5/12/16 1:10 PM, Doug Hellmann wrote:
>> Excerpts from Thierry Carrez's message of 2016-05-12 13:37:32 +0200:
>>> Tim Bell wrote:
 [...]
 I think it will be really difficult to persuade the mainstream 
 projects to adopt
 a library if it is not part of Oslo. Developing a common library for 
 quota
 management outside the scope of the common library framework for 
 OpenStack
 does not seem to be encouraging the widespread use of delimiter.
 [...]
>>> I agree it's hard enough to get Oslo libraries used across the board, I 
>>> don't think the task would be any easier with an external library.
>>>
>>> One case that would justify being external is if the library was 
>>> generally useful rather than OpenStack-specific: then the Oslo branding 
>>> might hinder its out-of-OpenStack adoption. But it doesn't feel like 
>>> that is the case here ?
>>>
>> In the past we've tried to encourage folks creating very specially
>> focused libraries for which areas where the existing Oslo team has no
>> real experience, such as os-win, to set up their own team. The Oslo team
>> doesn't have to own all libraries.
> Thanks for that pointer!
>
>> On the other hand, in this case I think quota management fits in Oslo as
>> well as messaging or policy do. We have a mechanism in place for managing
>> sub-teams so signing up to work on quotas doesn't have to mean signing
>> up to be oslo-core.
> Yes, I agree that this fits well into the cross-project consistency
> domain. And yes, thanks for proposing the sub-team strategy to move 
> forward.
>
> However, this library currently doesn't exist. We are still identifying
> what we want to achieve as a part of this scope, there's a ton of
> discussions in progress and we are on the advent of finding concrete
> tasks for people to pick up (so no second commit yet). Even after having
> done something we do not know if that's is something which will work for
> all the projects -- basically I am trying to say quotas is a big domain
> and now we are starting (very) small. We need a concrete implementation
> and it's adoption in a couple of projects to even say that it is a
> successful cross project implementation.
>
> The last thing we want to worry about is more process, governance and an
> approach to too-standardize things when we do not even have anything in
> tree. I think it makes sense as a part of somewhere _all_ projects can
> adopt but not until it's ready to be adopted.
 I'm not sure what processes you're talking about that might be a burden.
 Can you elaborate?
>> Currently, I do not have facts but only hints (anticipations, expected
>> hick-ups). If you think that's not the case, do you think we can be done
>> with all the processes, governance, etc. and yet be able to come up with
>> a POC release (dunno something like 0.0.3) within next 5 weeks that can
>> be experimented upon in one/two of the projects POC patches? We are
>> looking at that timeline and not sure how long the governance and specs
>> will take (do we need oslo spec?, how big is the process to setup
>> sub-cores? , how do we involve more folks without them thinking of oslo
>> standards?, etc.).
>>
>> My biggest concern is that this will be seen as something that is an
>> attempt to standardize things where we do not even have a standard but
>> want to create one. We wish to be agile in our workflow and do not care
>> where that exists.
> Reading this thread, Nikhil who is speaking for the quota team is worried 
> about
> the amount of overhead caused by governance, instead of first focusing on
> making something actually exist. I see quite a few people in this thread
> speaking up that it should be part of the big tent either standalone or oslo
> lib.
>
> I can't speak for the Oslo folks, but as a member of the TC here are the
> requirements for the standalone route [1]. You would propose an agenda item to
> the TC, and we would review that the project meets those requirements.
> Considering the project does Open Design and has an Open Community - my 
> guesses
> on "probably would be followed" is Open Development and Open Source since we
> don't have anything but a specification that exists to go off of.
>
> It sounds like the biggest hang up in going the oslo route is the oslo spec. 
> So
> question to the oslo folks, would you be interested in reviewing the
> cross-project specification and

Re: [openstack-dev] [cross-project][quotas][delimiter] Austin Summit - Design Session Summary

2016-05-14 Thread Mike Perez 
On 18:46 May 12, Nikhil Komawar wrote:
> I realized that I missed one of your questions earlier. Response for
> that inline.
> 
> 
> On 5/12/16 4:58 PM, Nikhil Komawar wrote:
> >
> >
> > On 5/12/16 4:33 PM, Doug Hellmann wrote:
> >> Excerpts from Nikhil Komawar's message of 2016-05-12 15:40:05 -0400:
> >>> Please find my response inline:
> >>>
> >>> On 5/12/16 1:10 PM, Doug Hellmann wrote:
>  Excerpts from Thierry Carrez's message of 2016-05-12 13:37:32 +0200:
> > Tim Bell wrote:
> >> [...]
> >> I think it will be really difficult to persuade the mainstream 
> >> projects to adopt
> >> a library if it is not part of Oslo. Developing a common library for 
> >> quota
> >> management outside the scope of the common library framework for 
> >> OpenStack
> >> does not seem to be encouraging the widespread use of delimiter.
> >> [...]
> > I agree it's hard enough to get Oslo libraries used across the board, I 
> > don't think the task would be any easier with an external library.
> >
> > One case that would justify being external is if the library was 
> > generally useful rather than OpenStack-specific: then the Oslo branding 
> > might hinder its out-of-OpenStack adoption. But it doesn't feel like 
> > that is the case here ?
> >
>  In the past we've tried to encourage folks creating very specially
>  focused libraries for which areas where the existing Oslo team has no
>  real experience, such as os-win, to set up their own team. The Oslo team
>  doesn't have to own all libraries.
> >>> Thanks for that pointer!
> >>>
>  On the other hand, in this case I think quota management fits in Oslo as
>  well as messaging or policy do. We have a mechanism in place for managing
>  sub-teams so signing up to work on quotas doesn't have to mean signing
>  up to be oslo-core.
> >>> Yes, I agree that this fits well into the cross-project consistency
> >>> domain. And yes, thanks for proposing the sub-team strategy to move 
> >>> forward.
> >>>
> >>> However, this library currently doesn't exist. We are still identifying
> >>> what we want to achieve as a part of this scope, there's a ton of
> >>> discussions in progress and we are on the advent of finding concrete
> >>> tasks for people to pick up (so no second commit yet). Even after having
> >>> done something we do not know if that's is something which will work for
> >>> all the projects -- basically I am trying to say quotas is a big domain
> >>> and now we are starting (very) small. We need a concrete implementation
> >>> and it's adoption in a couple of projects to even say that it is a
> >>> successful cross project implementation.
> >>>
> >>> The last thing we want to worry about is more process, governance and an
> >>> approach to too-standardize things when we do not even have anything in
> >>> tree. I think it makes sense as a part of somewhere _all_ projects can
> >>> adopt but not until it's ready to be adopted.
> >> I'm not sure what processes you're talking about that might be a burden.
> >> Can you elaborate?
> 
> Currently, I do not have facts but only hints (anticipations, expected
> hick-ups). If you think that's not the case, do you think we can be done
> with all the processes, governance, etc. and yet be able to come up with
> a POC release (dunno something like 0.0.3) within next 5 weeks that can
> be experimented upon in one/two of the projects POC patches? We are
> looking at that timeline and not sure how long the governance and specs
> will take (do we need oslo spec?, how big is the process to setup
> sub-cores? , how do we involve more folks without them thinking of oslo
> standards?, etc.).
> 
> My biggest concern is that this will be seen as something that is an
> attempt to standardize things where we do not even have a standard but
> want to create one. We wish to be agile in our workflow and do not care
> where that exists.

Reading this thread, Nikhil who is speaking for the quota team is worried about
the amount of overhead caused by governance, instead of first focusing on
making something actually exist. I see quite a few people in this thread
speaking up that it should be part of the big tent either standalone or oslo
lib.

I can't speak for the Oslo folks, but as a member of the TC here are the
requirements for the standalone route [1]. You would propose an agenda item to
the TC, and we would review that the project meets those requirements.
Considering the project does Open Design and has an Open Community - my guesses
on "probably would be followed" is Open Development and Open Source since we
don't have anything but a specification that exists to go off of.

It sounds like the biggest hang up in going the oslo route is the oslo spec. So
question to the oslo folks, would you be interested in reviewing the
cross-project specification and allowing to be an oslo lib? That way the team
can focus on working on the library, and

Re: [openstack-dev] [cross-project][quotas][delimiter] Austin Summit - Design Session Summary

2016-05-13 Thread Nikhil Komawar 

Hi Andreas,

Thanks for your suggestions. Please find my response inline.

On 5/13/16 2:45 AM, Andreas Jaeger wrote:
> On 05/12/2016 10:58 PM, Nikhil Komawar wrote:
>> [...]
>> But we are not working in a corner, we've a representative from cinder,
>> someone from trove who is interested in long term quota goals, someone
>> who has worked on nova (and then we are borrowing the gen_id concept of
>> Jay from Nova), someone from Zaqar, a PWG representative who is also
>> collaborating on UX study, someone who is interested from vmware's
>> perspective. And then we are developing this on the #openstack-irc
>> channel, ML, weekly meetings etc.
>>
>> Once some code is published, we will reflect back on the cross project
>> meetings to where things are heading.
> My understanding of the big tent is that you can do this kind of
> experimentation you plan also in the Big Tent - as part of an existing
> team. That was one of the big changes of the discussion AFAIU. You do
> not need to have a repository with content and can instead start right
> away - if being part of an existing project works for you,

Do we have a full fledged documentation of the BigTent somewhere? (my
search [1] doesn't only gives me older resolutions, blog posts (that may
not be time-stamped), etc)

We please do _not_ want to do this (even experiment) in a single
project. The scope is cross-project but it's a steep curve to get there.
The plan is to experiment soon in one project and with the help of other
project liaisons we need to start experimenting there too (possibly all
experimentation overlaps). Once the moving pendulum of library design
comes to a stop, we will like to consider it to be a truly cross project
entity (standard). Also, there are other issues doing this kind of stuff
in one (or more) projects separately, we need cross project liaisons
(who think cross project) to give us input, putting it in a project
polarizes the design.

[1]
https://governance.openstack.org/search.html?q=big+tent_keywords=yes=default
> Andreas
>
>


-- 

Thanks,
Nikhil



__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [cross-project][quotas][delimiter] Austin Summit - Design Session Summary

2016-05-13 Thread Andreas Jaeger 
On 05/12/2016 10:58 PM, Nikhil Komawar wrote:
> [...]
> But we are not working in a corner, we've a representative from cinder,
> someone from trove who is interested in long term quota goals, someone
> who has worked on nova (and then we are borrowing the gen_id concept of
> Jay from Nova), someone from Zaqar, a PWG representative who is also
> collaborating on UX study, someone who is interested from vmware's
> perspective. And then we are developing this on the #openstack-irc
> channel, ML, weekly meetings etc.
> 
> Once some code is published, we will reflect back on the cross project
> meetings to where things are heading.

My understanding of the big tent is that you can do this kind of
experimentation you plan also in the Big Tent - as part of an existing
team. That was one of the big changes of the discussion AFAIU. You do
not need to have a repository with content and can instead start right
away - if being part of an existing project works for you,

Andreas
-- 
 Andreas Jaeger aj@{suse.com,opensuse.org} Twitter/Identica: jaegerandi
  SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
   GF: Felix Imendörffer, Jane Smithard, Graham Norton,
   HRB 21284 (AG Nürnberg)
GPG fingerprint = 93A3 365E CE47 B889 DF7F  FED1 389A 563C C272 A126


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [cross-project][quotas][delimiter] Austin Summit - Design Session Summary

2016-05-12 Thread Nikhil Komawar 
I realized that I missed one of your questions earlier. Response for
that inline.


On 5/12/16 4:58 PM, Nikhil Komawar wrote:
>
>
> On 5/12/16 4:33 PM, Doug Hellmann wrote:
>> Excerpts from Nikhil Komawar's message of 2016-05-12 15:40:05 -0400:
>>> Please find my response inline:
>>>
>>> On 5/12/16 1:10 PM, Doug Hellmann wrote:
 Excerpts from Thierry Carrez's message of 2016-05-12 13:37:32 +0200:
> Tim Bell wrote:
>> [...]
>> I think it will be really difficult to persuade the mainstream projects 
>> to adopt
>> a library if it is not part of Oslo. Developing a common library for 
>> quota
>> management outside the scope of the common library framework for 
>> OpenStack
>> does not seem to be encouraging the widespread use of delimiter.
>> [...]
> I agree it's hard enough to get Oslo libraries used across the board, I 
> don't think the task would be any easier with an external library.
>
> One case that would justify being external is if the library was 
> generally useful rather than OpenStack-specific: then the Oslo branding 
> might hinder its out-of-OpenStack adoption. But it doesn't feel like 
> that is the case here ?
>
 In the past we've tried to encourage folks creating very specially
 focused libraries for which areas where the existing Oslo team has no
 real experience, such as os-win, to set up their own team. The Oslo team
 doesn't have to own all libraries.
>>> Thanks for that pointer!
>>>
 On the other hand, in this case I think quota management fits in Oslo as
 well as messaging or policy do. We have a mechanism in place for managing
 sub-teams so signing up to work on quotas doesn't have to mean signing
 up to be oslo-core.
>>> Yes, I agree that this fits well into the cross-project consistency
>>> domain. And yes, thanks for proposing the sub-team strategy to move forward.
>>>
>>> However, this library currently doesn't exist. We are still identifying
>>> what we want to achieve as a part of this scope, there's a ton of
>>> discussions in progress and we are on the advent of finding concrete
>>> tasks for people to pick up (so no second commit yet). Even after having
>>> done something we do not know if that's is something which will work for
>>> all the projects -- basically I am trying to say quotas is a big domain
>>> and now we are starting (very) small. We need a concrete implementation
>>> and it's adoption in a couple of projects to even say that it is a
>>> successful cross project implementation.
>>>
>>> The last thing we want to worry about is more process, governance and an
>>> approach to too-standardize things when we do not even have anything in
>>> tree. I think it makes sense as a part of somewhere _all_ projects can
>>> adopt but not until it's ready to be adopted.
>> I'm not sure what processes you're talking about that might be a burden.
>> Can you elaborate?

Currently, I do not have facts but only hints (anticipations, expected
hick-ups). If you think that's not the case, do you think we can be done
with all the processes, governance, etc. and yet be able to come up with
a POC release (dunno something like 0.0.3) within next 5 weeks that can
be experimented upon in one/two of the projects POC patches? We are
looking at that timeline and not sure how long the governance and specs
will take (do we need oslo spec?, how big is the process to setup
sub-cores? , how do we involve more folks without them thinking of oslo
standards?, etc.).

My biggest concern is that this will be seen as something that is an
attempt to standardize things where we do not even have a standard but
want to create one. We wish to be agile in our workflow and do not care
where that exists.

>>
 The notion that we're going to try to have all projects depend on
 something we create but that we *don't* create as part of an official
 project is extremely confusing. Whether we make it part of Oslo or part
 of its own thing, I think we want this to be official.
>>> Yes, that exists as a notion but it's agreed upon in the ML thread [1]
>>> that it's not practical yet. The hardest thing to achieve is to get the
>>> quotas code right and for now we would please like to focus on that. We
>>> do want to worry about governance and adoption across domain
>>> (standardization) once we do have a standard.
>> If you go off in a corner and build something that doesn't fit any of
>> our community standards for code or API, how do you expect the adoption
>> process to work out?
>>
> But we are not working in a corner, we've a representative from cinder,
> someone from trove who is interested in long term quota goals, someone
> who has worked on nova (and then we are borrowing the gen_id concept of
> Jay from Nova), someone from Zaqar, a PWG representative who is also
> collaborating on UX study, someone who is interested from vmware's
> perspective. And then we are developing this on the

Re: [openstack-dev] [cross-project][quotas][delimiter] Austin Summit - Design Session Summary

2016-05-12 Thread Nikhil Komawar 



On 5/12/16 4:33 PM, Doug Hellmann wrote:
> Excerpts from Nikhil Komawar's message of 2016-05-12 15:40:05 -0400:
>> Please find my response inline:
>>
>> On 5/12/16 1:10 PM, Doug Hellmann wrote:
>>> Excerpts from Thierry Carrez's message of 2016-05-12 13:37:32 +0200:
 Tim Bell wrote:
> [...]
> I think it will be really difficult to persuade the mainstream projects 
> to adopt
> a library if it is not part of Oslo. Developing a common library for quota
> management outside the scope of the common library framework for OpenStack
> does not seem to be encouraging the widespread use of delimiter.
> [...]
 I agree it's hard enough to get Oslo libraries used across the board, I 
 don't think the task would be any easier with an external library.

 One case that would justify being external is if the library was 
 generally useful rather than OpenStack-specific: then the Oslo branding 
 might hinder its out-of-OpenStack adoption. But it doesn't feel like 
 that is the case here ?

>>> In the past we've tried to encourage folks creating very specially
>>> focused libraries for which areas where the existing Oslo team has no
>>> real experience, such as os-win, to set up their own team. The Oslo team
>>> doesn't have to own all libraries.
>> Thanks for that pointer!
>>
>>> On the other hand, in this case I think quota management fits in Oslo as
>>> well as messaging or policy do. We have a mechanism in place for managing
>>> sub-teams so signing up to work on quotas doesn't have to mean signing
>>> up to be oslo-core.
>>
>> Yes, I agree that this fits well into the cross-project consistency
>> domain. And yes, thanks for proposing the sub-team strategy to move forward.
>>
>> However, this library currently doesn't exist. We are still identifying
>> what we want to achieve as a part of this scope, there's a ton of
>> discussions in progress and we are on the advent of finding concrete
>> tasks for people to pick up (so no second commit yet). Even after having
>> done something we do not know if that's is something which will work for
>> all the projects -- basically I am trying to say quotas is a big domain
>> and now we are starting (very) small. We need a concrete implementation
>> and it's adoption in a couple of projects to even say that it is a
>> successful cross project implementation.
>>
>> The last thing we want to worry about is more process, governance and an
>> approach to too-standardize things when we do not even have anything in
>> tree. I think it makes sense as a part of somewhere _all_ projects can
>> adopt but not until it's ready to be adopted.
> I'm not sure what processes you're talking about that might be a burden.
> Can you elaborate?
>
>>> The notion that we're going to try to have all projects depend on
>>> something we create but that we *don't* create as part of an official
>>> project is extremely confusing. Whether we make it part of Oslo or part
>>> of its own thing, I think we want this to be official.
>> Yes, that exists as a notion but it's agreed upon in the ML thread [1]
>> that it's not practical yet. The hardest thing to achieve is to get the
>> quotas code right and for now we would please like to focus on that. We
>> do want to worry about governance and adoption across domain
>> (standardization) once we do have a standard.
> If you go off in a corner and build something that doesn't fit any of
> our community standards for code or API, how do you expect the adoption
> process to work out?
>

But we are not working in a corner, we've a representative from cinder,
someone from trove who is interested in long term quota goals, someone
who has worked on nova (and then we are borrowing the gen_id concept of
Jay from Nova), someone from Zaqar, a PWG representative who is also
collaborating on UX study, someone who is interested from vmware's
perspective. And then we are developing this on the #openstack-irc
channel, ML, weekly meetings etc.

Once some code is published, we will reflect back on the cross project
meetings to where things are heading.

>> With that mind, please suggest the path of least resistance for moving
>> forward quickly on this. We have seen good interest in the library and
>> we want people to start working on things without having to wait on
>> decisions they are not interested in. We do, however, want to be
>> compliant with the governance rules so that it does not diverge too far.
>> Simply put, can we revisit the governance decision late in Newton?
>>
>>> Before pushing too hard to bring the new lib under the Oslo umbrella,
>>> I'd like to understand why folks might not want to do that. What "costs"
>>> are perceived?
>> Much appreciated!
>>
>>> Doug
>>>
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>>

Re: [openstack-dev] [cross-project][quotas][delimiter] Austin Summit - Design Session Summary

2016-05-12 Thread Doug Hellmann 
Excerpts from Nikhil Komawar's message of 2016-05-12 15:40:05 -0400:
> Please find my response inline:
> 
> On 5/12/16 1:10 PM, Doug Hellmann wrote:
> > Excerpts from Thierry Carrez's message of 2016-05-12 13:37:32 +0200:
> >> Tim Bell wrote:
> >>> [...]
> >>> I think it will be really difficult to persuade the mainstream projects 
> >>> to adopt
> >>> a library if it is not part of Oslo. Developing a common library for quota
> >>> management outside the scope of the common library framework for OpenStack
> >>> does not seem to be encouraging the widespread use of delimiter.
> >>> [...]
> >> I agree it's hard enough to get Oslo libraries used across the board, I 
> >> don't think the task would be any easier with an external library.
> >>
> >> One case that would justify being external is if the library was 
> >> generally useful rather than OpenStack-specific: then the Oslo branding 
> >> might hinder its out-of-OpenStack adoption. But it doesn't feel like 
> >> that is the case here ?
> >>
> > In the past we've tried to encourage folks creating very specially
> > focused libraries for which areas where the existing Oslo team has no
> > real experience, such as os-win, to set up their own team. The Oslo team
> > doesn't have to own all libraries.
> 
> Thanks for that pointer!
> 
> > On the other hand, in this case I think quota management fits in Oslo as
> > well as messaging or policy do. We have a mechanism in place for managing
> > sub-teams so signing up to work on quotas doesn't have to mean signing
> > up to be oslo-core.
> 
> 
> Yes, I agree that this fits well into the cross-project consistency
> domain. And yes, thanks for proposing the sub-team strategy to move forward.
> 
> However, this library currently doesn't exist. We are still identifying
> what we want to achieve as a part of this scope, there's a ton of
> discussions in progress and we are on the advent of finding concrete
> tasks for people to pick up (so no second commit yet). Even after having
> done something we do not know if that's is something which will work for
> all the projects -- basically I am trying to say quotas is a big domain
> and now we are starting (very) small. We need a concrete implementation
> and it's adoption in a couple of projects to even say that it is a
> successful cross project implementation.
> 
> The last thing we want to worry about is more process, governance and an
> approach to too-standardize things when we do not even have anything in
> tree. I think it makes sense as a part of somewhere _all_ projects can
> adopt but not until it's ready to be adopted.

I'm not sure what processes you're talking about that might be a burden.
Can you elaborate?

> 
> > The notion that we're going to try to have all projects depend on
> > something we create but that we *don't* create as part of an official
> > project is extremely confusing. Whether we make it part of Oslo or part
> > of its own thing, I think we want this to be official.
> 
> Yes, that exists as a notion but it's agreed upon in the ML thread [1]
> that it's not practical yet. The hardest thing to achieve is to get the
> quotas code right and for now we would please like to focus on that. We
> do want to worry about governance and adoption across domain
> (standardization) once we do have a standard.

If you go off in a corner and build something that doesn't fit any of
our community standards for code or API, how do you expect the adoption
process to work out?

> 
> With that mind, please suggest the path of least resistance for moving
> forward quickly on this. We have seen good interest in the library and
> we want people to start working on things without having to wait on
> decisions they are not interested in. We do, however, want to be
> compliant with the governance rules so that it does not diverge too far.
> Simply put, can we revisit the governance decision late in Newton?
> 
> > Before pushing too hard to bring the new lib under the Oslo umbrella,
> > I'd like to understand why folks might not want to do that. What "costs"
> > are perceived?
> 
> Much appreciated!
> 
> >
> > Doug
> >
> > __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> [1]
> http://lists.openstack.org/pipermail/openstack-dev/2016-March/thread.html#89453
> 

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [cross-project][quotas][delimiter] Austin Summit - Design Session Summary

2016-05-12 Thread Nikhil Komawar 
Please find my response inline:


On 5/12/16 1:10 PM, Doug Hellmann wrote:
> Excerpts from Thierry Carrez's message of 2016-05-12 13:37:32 +0200:
>> Tim Bell wrote:
>>> [...]
>>> I think it will be really difficult to persuade the mainstream projects to 
>>> adopt
>>> a library if it is not part of Oslo. Developing a common library for quota
>>> management outside the scope of the common library framework for OpenStack
>>> does not seem to be encouraging the widespread use of delimiter.
>>> [...]
>> I agree it's hard enough to get Oslo libraries used across the board, I 
>> don't think the task would be any easier with an external library.
>>
>> One case that would justify being external is if the library was 
>> generally useful rather than OpenStack-specific: then the Oslo branding 
>> might hinder its out-of-OpenStack adoption. But it doesn't feel like 
>> that is the case here ?
>>
> In the past we've tried to encourage folks creating very specially
> focused libraries for which areas where the existing Oslo team has no
> real experience, such as os-win, to set up their own team. The Oslo team
> doesn't have to own all libraries.

Thanks for that pointer!

> On the other hand, in this case I think quota management fits in Oslo as
> well as messaging or policy do. We have a mechanism in place for managing
> sub-teams so signing up to work on quotas doesn't have to mean signing
> up to be oslo-core.


Yes, I agree that this fits well into the cross-project consistency
domain. And yes, thanks for proposing the sub-team strategy to move forward.

However, this library currently doesn't exist. We are still identifying
what we want to achieve as a part of this scope, there's a ton of
discussions in progress and we are on the advent of finding concrete
tasks for people to pick up (so no second commit yet). Even after having
done something we do not know if that's is something which will work for
all the projects -- basically I am trying to say quotas is a big domain
and now we are starting (very) small. We need a concrete implementation
and it's adoption in a couple of projects to even say that it is a
successful cross project implementation.

The last thing we want to worry about is more process, governance and an
approach to too-standardize things when we do not even have anything in
tree. I think it makes sense as a part of somewhere _all_ projects can
adopt but not until it's ready to be adopted.

> The notion that we're going to try to have all projects depend on
> something we create but that we *don't* create as part of an official
> project is extremely confusing. Whether we make it part of Oslo or part
> of its own thing, I think we want this to be official.

Yes, that exists as a notion but it's agreed upon in the ML thread [1]
that it's not practical yet. The hardest thing to achieve is to get the
quotas code right and for now we would please like to focus on that. We
do want to worry about governance and adoption across domain
(standardization) once we do have a standard.

With that mind, please suggest the path of least resistance for moving
forward quickly on this. We have seen good interest in the library and
we want people to start working on things without having to wait on
decisions they are not interested in. We do, however, want to be
compliant with the governance rules so that it does not diverge too far.
Simply put, can we revisit the governance decision late in Newton?


> Before pushing too hard to bring the new lib under the Oslo umbrella,
> I'd like to understand why folks might not want to do that. What "costs"
> are perceived?

Much appreciated!

>
> Doug
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[1]
http://lists.openstack.org/pipermail/openstack-dev/2016-March/thread.html#89453

-- 

Thanks,
Nikhil


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [cross-project][quotas][delimiter] Austin Summit - Design Session Summary

2016-05-12 Thread Doug Hellmann 
Excerpts from Thierry Carrez's message of 2016-05-12 13:37:32 +0200:
> Tim Bell wrote:
> > [...]
> > I think it will be really difficult to persuade the mainstream projects to 
> > adopt
> > a library if it is not part of Oslo. Developing a common library for quota
> > management outside the scope of the common library framework for OpenStack
> > does not seem to be encouraging the widespread use of delimiter.
> > [...]
> 
> I agree it's hard enough to get Oslo libraries used across the board, I 
> don't think the task would be any easier with an external library.
> 
> One case that would justify being external is if the library was 
> generally useful rather than OpenStack-specific: then the Oslo branding 
> might hinder its out-of-OpenStack adoption. But it doesn't feel like 
> that is the case here ?
> 

In the past we've tried to encourage folks creating very specially
focused libraries for which areas where the existing Oslo team has no
real experience, such as os-win, to set up their own team. The Oslo team
doesn't have to own all libraries.

On the other hand, in this case I think quota management fits in Oslo as
well as messaging or policy do. We have a mechanism in place for managing
sub-teams so signing up to work on quotas doesn't have to mean signing
up to be oslo-core.

The notion that we're going to try to have all projects depend on
something we create but that we *don't* create as part of an official
project is extremely confusing. Whether we make it part of Oslo or part
of its own thing, I think we want this to be official.

Before pushing too hard to bring the new lib under the Oslo umbrella,
I'd like to understand why folks might not want to do that. What "costs"
are perceived?

Doug

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [cross-project][quotas][delimiter] Austin Summit - Design Session Summary

2016-05-12 Thread Thierry Carrez 

Tim Bell wrote:

[...]
I think it will be really difficult to persuade the mainstream projects to adopt
a library if it is not part of Oslo. Developing a common library for quota
management outside the scope of the common library framework for OpenStack
does not seem to be encouraging the widespread use of delimiter.
[...]


I agree it's hard enough to get Oslo libraries used across the board, I 
don't think the task would be any easier with an external library.


One case that would justify being external is if the library was 
generally useful rather than OpenStack-specific: then the Oslo branding 
might hinder its out-of-OpenStack adoption. But it doesn't feel like 
that is the case here ?


--
Thierry Carrez (ttx)

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [cross-project][quotas][delimiter] Austin Summit - Design Session Summary

2016-05-12 Thread Andreas Jaeger 
On 2016-05-12 02:59, Nikhil Komawar wrote:
> Thanks Josh about your reply. It's helpful.
> 
> The attempt of this cross project work is to come up with a standard way
> of implementing quota logic that can be used by different services.
> Currently, different projects have their individual implementations and
> there are many learning lessons. The library is supposed to be born out
> of that shared wisdom.
> 
> Hence, it needs to be an independent library that can make progress in a
> way, to be successfully adopted and vetted upon by cross project cases;
> but not necessarily enforce cross project standardization for projects
> to adopt it in a particular way.
> 
> 
> So, not oslo for now at least [1]. BigTent? -- I do not know the
> consequences of it not being in BigTent. We do not need design summit
> slot dedicated for this project, neither do we need to have elections,
> nor it is a big enough project to be coordinated with a specific release
> milestone (Newton, Ocata, etc.). The team, though, does follow the four
> opens [2]. So, we can in future go for either option as needed. As long
> as it lives under openstack/delimiter umbrella, runs the standard gate
> tests, follows the release process of openstack for libraries (but not
> necessarily require intervention of the release team), we are happy.

The release team only takes care of Big Tent projects, documentation and
translation teams are not covering independent projects - including
using the docs.openstack.org web site for publishing. Even in the Big
Tent you are not forced to release at a specific release milestone.

We don't have stackforge anymore by name, just by spirit: you can create
a repo for this as independent project as openstack/delimter,

Note that you can also start now under an existing project - like
keystone, glance or oslo - and later spin off as separate independent team.

Starting off independent is fine in general - it just really strikes me
as odd that a cross-project effort considers itself outside of the Big Tent,

Andreas
> 
> 
> [1] Personally, I do not care of where it lives after it has been
> adopted by a few different projects. But let's keep the future
> discussions in the Pandora's box for now.
> 
> [2] The four opens http://governance.openstack.org/reference/opens.html
> 
> On 5/11/16 7:16 PM, Joshua Harlow wrote:
>> So it was under my belief that at its current stage that this library
>> would start off on its own, and not initially start of (just yet) in
>> oslo (as I think the oslo group wants to not be the
>> blocker/requirement for a library being a successful thing + the cost
>> of it being in oslo may not be warranted yet).
>>
>> If in the future we as a community think it is better under oslo (and
>> said membership into oslo will help); then I'm ok with it being
>> there... I just know that others (in the oslo group) have other
>> thoughts here (and hopefully they can chime in).
>>
>> Part of this is also being refined in
>> https://review.openstack.org/#/c/312233/ and that hopefully can be a
>> guideline for new libraries that come along.
>>
>> -Josh
>>
>> Andreas Jaeger wrote:
>>> Since the review [1] to create the repo is up now, I have one question:
>>> This is a cross-project effort, so what is it's governance?
>>>
>>> The review stated it will be an independent project outside of the big
>>> tent - but seeing that this should become a common part for core
>>> projects and specific to OpenStack, I wonder whether that is the right
>>> approach. It fits nicely into Oslo as cross-project library - or it
>>> could be an independent team on its own in the Big Tent.
>>>
>>> But cross-project and outside of Big Tent looks very strange to me,
>>>
>>> Andreas
>>>
>>> [1] https://review.openstack.org/284454
>>
>> __
>>
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 


-- 
 Andreas Jaeger aj@{suse.com,opensuse.org} Twitter: jaegerandi
  SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
   GF: Felix Imendörffer, Jane Smithard, Graham Norton,
   HRB 21284 (AG Nürnberg)
GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [cross-project][quotas][delimiter] Austin Summit - Design Session Summary

2016-05-12 Thread Andreas Jaeger 
Looking at yourcross-project spec
https://review.openstack.org/#/c/284454/, I really wonder what's the
reason is for this developed outside of the Big Tent,

Andreas
-- 
 Andreas Jaeger aj@{suse.com,opensuse.org} Twitter: jaegerandi
  SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
   GF: Felix Imendörffer, Jane Smithard, Graham Norton,
   HRB 21284 (AG Nürnberg)
GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [cross-project][quotas][delimiter] Austin Summit - Design Session Summary

2016-05-12 Thread Tim Bell 


On 12/05/16 02:59, "Nikhil Komawar"  wrote:

>Thanks Josh about your reply. It's helpful.
>
>The attempt of this cross project work is to come up with a standard way
>of implementing quota logic that can be used by different services.
>Currently, different projects have their individual implementations and
>there are many learning lessons. The library is supposed to be born out
>of that shared wisdom.
>
>Hence, it needs to be an independent library that can make progress in a
>way, to be successfully adopted and vetted upon by cross project cases;
>but not necessarily enforce cross project standardization for projects
>to adopt it in a particular way.
>
>
>So, not oslo for now at least [1]. BigTent? -- I do not know the
>consequences of it not being in BigTent. We do not need design summit
>slot dedicated for this project, neither do we need to have elections,
>nor it is a big enough project to be coordinated with a specific release
>milestone (Newton, Ocata, etc.). The team, though, does follow the four
>opens [2]. So, we can in future go for either option as needed. As long
>as it lives under openstack/delimiter umbrella, runs the standard gate
>tests, follows the release process of openstack for libraries (but not
>necessarily require intervention of the release team), we are happy.
>

I think it will be really difficult to persuade the mainstream projects to adopt
a library if it is not part of Oslo. Developing a common library for quota
management outside the scope of the common library framework for OpenStack
does not seem to be encouraging the widespread use of delimiter.

What are the issues with being part of oslo ?

Is it that oslo may not want the library or are there constraints that it would 
impose 
on the development ? 

Tim

>
>[1] Personally, I do not care of where it lives after it has been
>adopted by a few different projects. But let's keep the future
>discussions in the Pandora's box for now.
>
>[2] The four opens http://governance.openstack.org/reference/opens.html
>
>On 5/11/16 7:16 PM, Joshua Harlow wrote:
>> So it was under my belief that at its current stage that this library
>> would start off on its own, and not initially start of (just yet) in
>> oslo (as I think the oslo group wants to not be the
>> blocker/requirement for a library being a successful thing + the cost
>> of it being in oslo may not be warranted yet).
>>
>> If in the future we as a community think it is better under oslo (and
>> said membership into oslo will help); then I'm ok with it being
>> there... I just know that others (in the oslo group) have other
>> thoughts here (and hopefully they can chime in).
>>
>> Part of this is also being refined in
>> https://review.openstack.org/#/c/312233/ and that hopefully can be a
>> guideline for new libraries that come along.
>>
>> -Josh
>>
>> Andreas Jaeger wrote:
>>> Since the review [1] to create the repo is up now, I have one question:
>>> This is a cross-project effort, so what is it's governance?
>>>
>>> The review stated it will be an independent project outside of the big
>>> tent - but seeing that this should become a common part for core
>>> projects and specific to OpenStack, I wonder whether that is the right
>>> approach. It fits nicely into Oslo as cross-project library - or it
>>> could be an independent team on its own in the Big Tent.
>>>
>>> But cross-project and outside of Big Tent looks very strange to me,
>>>
>>> Andreas
>>>
>>> [1] https://review.openstack.org/284454
>>
>> __
>>
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>-- 
>
>Thanks,
>Nikhil
>
>
>__
>OpenStack Development Mailing List (not for usage questions)
>Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [cross-project][quotas][delimiter] Austin Summit - Design Session Summary

2016-05-11 Thread Nikhil Komawar 
Thanks Josh about your reply. It's helpful.

The attempt of this cross project work is to come up with a standard way
of implementing quota logic that can be used by different services.
Currently, different projects have their individual implementations and
there are many learning lessons. The library is supposed to be born out
of that shared wisdom.

Hence, it needs to be an independent library that can make progress in a
way, to be successfully adopted and vetted upon by cross project cases;
but not necessarily enforce cross project standardization for projects
to adopt it in a particular way.


So, not oslo for now at least [1]. BigTent? -- I do not know the
consequences of it not being in BigTent. We do not need design summit
slot dedicated for this project, neither do we need to have elections,
nor it is a big enough project to be coordinated with a specific release
milestone (Newton, Ocata, etc.). The team, though, does follow the four
opens [2]. So, we can in future go for either option as needed. As long
as it lives under openstack/delimiter umbrella, runs the standard gate
tests, follows the release process of openstack for libraries (but not
necessarily require intervention of the release team), we are happy.


[1] Personally, I do not care of where it lives after it has been
adopted by a few different projects. But let's keep the future
discussions in the Pandora's box for now.

[2] The four opens http://governance.openstack.org/reference/opens.html

On 5/11/16 7:16 PM, Joshua Harlow wrote:
> So it was under my belief that at its current stage that this library
> would start off on its own, and not initially start of (just yet) in
> oslo (as I think the oslo group wants to not be the
> blocker/requirement for a library being a successful thing + the cost
> of it being in oslo may not be warranted yet).
>
> If in the future we as a community think it is better under oslo (and
> said membership into oslo will help); then I'm ok with it being
> there... I just know that others (in the oslo group) have other
> thoughts here (and hopefully they can chime in).
>
> Part of this is also being refined in
> https://review.openstack.org/#/c/312233/ and that hopefully can be a
> guideline for new libraries that come along.
>
> -Josh
>
> Andreas Jaeger wrote:
>> Since the review [1] to create the repo is up now, I have one question:
>> This is a cross-project effort, so what is it's governance?
>>
>> The review stated it will be an independent project outside of the big
>> tent - but seeing that this should become a common part for core
>> projects and specific to OpenStack, I wonder whether that is the right
>> approach. It fits nicely into Oslo as cross-project library - or it
>> could be an independent team on its own in the Big Tent.
>>
>> But cross-project and outside of Big Tent looks very strange to me,
>>
>> Andreas
>>
>> [1] https://review.openstack.org/284454
>
> __
>
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-- 

Thanks,
Nikhil


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [cross-project][quotas][delimiter] Austin Summit - Design Session Summary

2016-05-11 Thread Joshua Harlow 
So it was under my belief that at its current stage that this library 
would start off on its own, and not initially start of (just yet) in 
oslo (as I think the oslo group wants to not be the blocker/requirement 
for a library being a successful thing + the cost of it being in oslo 
may not be warranted yet).


If in the future we as a community think it is better under oslo (and 
said membership into oslo will help); then I'm ok with it being there... 
I just know that others (in the oslo group) have other thoughts here 
(and hopefully they can chime in).


Part of this is also being refined in 
https://review.openstack.org/#/c/312233/ and that hopefully can be a 
guideline for new libraries that come along.


-Josh

Andreas Jaeger wrote:

Since the review [1] to create the repo is up now, I have one question:
This is a cross-project effort, so what is it's governance?

The review stated it will be an independent project outside of the big
tent - but seeing that this should become a common part for core
projects and specific to OpenStack, I wonder whether that is the right
approach. It fits nicely into Oslo as cross-project library - or it
could be an independent team on its own in the Big Tent.

But cross-project and outside of Big Tent looks very strange to me,

Andreas

[1] https://review.openstack.org/284454


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [cross-project][quotas][delimiter] Austin Summit - Design Session Summary

2016-05-11 Thread Andreas Jaeger 
Since the review [1] to create the repo is up now, I have one question:
This is a cross-project effort, so what is it's governance?

The review stated it will be an independent project outside of the big
tent - but seeing that this should become a common part for core
projects and specific to OpenStack, I wonder whether that is the right
approach. It fits nicely into Oslo as cross-project library - or it
could be an independent team on its own in the Big Tent.

But cross-project and outside of Big Tent looks very strange to me,

Andreas

[1] https://review.openstack.org/284454
-- 
 Andreas Jaeger aj@{suse.com,opensuse.org} Twitter/Identica: jaegerandi
  SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
   GF: Felix Imendörffer, Jane Smithard, Graham Norton,
   HRB 21284 (AG Nürnberg)
GPG fingerprint = 93A3 365E CE47 B889 DF7F  FED1 389A 563C C272 A126


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [cross-project][quotas][delimiter] Austin Summit - Design Session Summary

2016-05-04 Thread Nikhil Komawar 
Comments inline.


On 5/4/16 2:58 PM, Tim Bell wrote:
>
> On 04/05/16 20:35, "Nikhil Komawar"  wrote:
>
>>
>> On 5/4/16 2:09 PM, Tim Bell wrote:
>>> On 04/05/16 19:41, "Nikhil Komawar"  wrote:
>>>
 Thanks for the summary and taking care of the setup, Vilobh!

 Pretty meticulously written on what was agreed at the session. Kudos!

 I wanted to add some points that were asked during the Glance
 contributors' meetup:

 * The quota limits will be set on the tables in the service that
 maintains the resources for each individual resource (not in keystone).
 The default value is what is picked from the config. I think over time
 we will come up with implementation detail on how the hierarchical
 default value should be set.

 * The quota allocation calculation will be based on the project
 hierarchy in consideration (given that driver is being used in such
 deployment scenario) and the usage for that resource recorded in the
 resource's quota table in that service. So, this will involve
 interaction with keystone and within the quota table in the project.

 * We will be working on a migration story separately (outside of the
 library). Delimiter does not own the quota limits and usage data so it
 will not deal with migrations.
>>> Given that Glance does not currently have a quota, it may be possible to 
>>> use this as the initial implementation. This would also avoid a later 
>>> migration effort.
>>>
>>> Tim
>>>
>>>
>> Thanks for the response Tim. I am of the same opinion but haven't really
>> internalized this migration path as I've not been on the deploy-er side
>> of managing quota yet. Intuitively migration for quotas seems like a
>> terrible experience, possibly going over days?
>>
>> I presume that nested quota support, if built in from get go, when the
>> tables are set is probably the best idea of hierarchical quota support.
>> Hoping that's not overly pessimistic assumption.
>
> With Glance not having quotas (and a reasonable set of defaults), I think we 
> can make the use of the delimiter functionalities
> optional for Glance at the beginning and thus is a much easier use case than 
> those who have to convert the existing combinations 
> of user/project/nested project quotas for production clouds. A release cycle 
> with Glance quotas in production would also encourage
> further adoption going forward.

I was of the differing opinion wrt to using delimiter's functionalities,
mostly because the lib can and should be configured by the service in a
way the service is setup to be used in keystone -- for nested lib's
nested driver would be used and for flat quotas it's flat driver. Given
the implementation will use some sort of if logic that will read
hierarchy, it would make sense to use the config in the service to use
hierarchical or non-hierarchical driver.

This would allow both existing deployments that do not have complex
hierarchy to use the library and to the new ones that have hierarchy
setup & prefer to use quota out of the box in hierarchical manner. From
the input I gather talking to a bunch of people, the difference between
adding simple quota or hierarchical quota is not significantly larger
than adding the entire functionality in a service (like Glance that
doesn't have quotas). As delimiter is an attempt to solve the
consistency, things should work pretty smoothly for services like Glance.

>
> I would like that nested quotas is not a special case as we deploy delimeter, 
> just business as usual. There are so many varied use cases and flexibility 
> for 
> those who do not need it to make it the standard deployment for delimeter. 
> Clearly, existing installs would need to find a migration
> path but generally, these would not be nested deployments.

I am not sure how far we can draw the line for seamless workflow for
delimiter. The spec [5] mentions on line 198 that default case would be
flat but the existing Glance deployments would be assuming 'Independent
quotas' (comment on line 86). Also, I am looking forward to next meeting
where we can get better picture of the layout of this library.

Basically, I'm saying we need to handle that logic in delimiter anyway
-- either today or later when the usage of the library happens. The risk
of having to migrate 100s of (tenants) projects and may be order of 100K
or more images is what is really scary. Operators do say they have a
massive amount of data in Glance tables -- that makes things worse as we
get requests for support of not just image-data storage quotas but of
#images, #properties, #members, etc. Looks to me like a impossible
migration :/

> A single oslo library gives a good chance to get a consistent implementation 
> across multiple OpenStack components. This would massively 
> simplify the operator and resource manager use cases.

+1

>
> Tim
>
>
 On 5/4/16 1:23 PM, Vilobh Meshram wrote:

Re: [openstack-dev] [cross-project][quotas][delimiter] Austin Summit - Design Session Summary

2016-05-04 Thread Tim Bell 


On 04/05/16 20:35, "Nikhil Komawar"  wrote:

>
>
>On 5/4/16 2:09 PM, Tim Bell wrote:
>>
>> On 04/05/16 19:41, "Nikhil Komawar"  wrote:
>>
>>> Thanks for the summary and taking care of the setup, Vilobh!
>>>
>>> Pretty meticulously written on what was agreed at the session. Kudos!
>>>
>>> I wanted to add some points that were asked during the Glance
>>> contributors' meetup:
>>>
>>> * The quota limits will be set on the tables in the service that
>>> maintains the resources for each individual resource (not in keystone).
>>> The default value is what is picked from the config. I think over time
>>> we will come up with implementation detail on how the hierarchical
>>> default value should be set.
>>>
>>> * The quota allocation calculation will be based on the project
>>> hierarchy in consideration (given that driver is being used in such
>>> deployment scenario) and the usage for that resource recorded in the
>>> resource's quota table in that service. So, this will involve
>>> interaction with keystone and within the quota table in the project.
>>>
>>> * We will be working on a migration story separately (outside of the
>>> library). Delimiter does not own the quota limits and usage data so it
>>> will not deal with migrations.
>> Given that Glance does not currently have a quota, it may be possible to use 
>> this as the initial implementation. This would also avoid a later migration 
>> effort.
>>
>> Tim
>>
>>
>
>Thanks for the response Tim. I am of the same opinion but haven't really
>internalized this migration path as I've not been on the deploy-er side
>of managing quota yet. Intuitively migration for quotas seems like a
>terrible experience, possibly going over days?
>
>I presume that nested quota support, if built in from get go, when the
>tables are set is probably the best idea of hierarchical quota support.
>Hoping that's not overly pessimistic assumption.


With Glance not having quotas (and a reasonable set of defaults), I think we 
can make the use of the delimiter functionalities
optional for Glance at the beginning and thus is a much easier use case than 
those who have to convert the existing combinations 
of user/project/nested project quotas for production clouds. A release cycle 
with Glance quotas in production would also encourage
further adoption going forward.

I would like that nested quotas is not a special case as we deploy delimeter, 
just business as usual. There are so many varied use cases and flexibility for 
those who do not need it to make it the standard deployment for delimeter. 
Clearly, existing installs would need to find a migration
path but generally, these would not be nested deployments.

A single oslo library gives a good chance to get a consistent implementation 
across multiple OpenStack components. This would massively 
simplify the operator and resource manager use cases.

Tim


>
>>>
>>> On 5/4/16 1:23 PM, Vilobh Meshram wrote:
 Hi All,

 For people who missed the design summit session on Delimiter - Cross
 project Quota enforcement library here is a gist of what we discussed.
 Etherpad [1] captures the details. 

 1. Delimiter will not be responsible for rate-limiting.
 2. Delimiter will not maintain data for the projects.
 3. Delimiter will not have the concept of reservations.
 4. Delimiter will fetch information for project quotas from respective
 projects.
 5. Delimiter will consolidate utility code for quota related issues at
 common place. For example X, Y, Z companies might have different
 scripts to fix quota issues. Delimiter can be a single place for it
 and the scripts can be more generalized to suit everyones needs.
 6. The details of project hierarchy is maintained in Keystone but
 Delimiter while making calculations for available/free resource will
 take into consideration whether the project has flat or nested hierarchy.
 7. Delimiter will rely on the concept of generation-id to guarantee
 sequencing. Generation-id gives a point in time view of resource usage
 in a project. Project consuming delimiter will need to provide this
 information while checking or consuming quota. At present Nova [3] has
 the concept of generation-id.
 8. Spec [5] will be modified based on the design summit discussion.

 If you want to contribute to Delimiter, please join *#openstack-quota. *

 We have *meetings every Tuesday at 17:00 UTC. *Please join us !
 *
 *
 I am in the process of setting up a new repo for Delimiter. The
 launchpad page[4] is up.


 Thanks!

 -Vilobh

 [1] Etherpad : https://etherpad.openstack.org/p/newton-quota-library
 [2] Slides
 : 
 http://www.slideshare.net/vilobh/delimiter-openstack-cross-project-quota-library-proposal
  
 [3] https://review.openstack.org/#/c/283253/
 [4] https://launchpad.net/delimiter
 [5]

Re: [openstack-dev] [cross-project][quotas][delimiter] Austin Summit - Design Session Summary

2016-05-04 Thread Nikhil Komawar 


On 5/4/16 2:09 PM, Tim Bell wrote:
>
> On 04/05/16 19:41, "Nikhil Komawar"  wrote:
>
>> Thanks for the summary and taking care of the setup, Vilobh!
>>
>> Pretty meticulously written on what was agreed at the session. Kudos!
>>
>> I wanted to add some points that were asked during the Glance
>> contributors' meetup:
>>
>> * The quota limits will be set on the tables in the service that
>> maintains the resources for each individual resource (not in keystone).
>> The default value is what is picked from the config. I think over time
>> we will come up with implementation detail on how the hierarchical
>> default value should be set.
>>
>> * The quota allocation calculation will be based on the project
>> hierarchy in consideration (given that driver is being used in such
>> deployment scenario) and the usage for that resource recorded in the
>> resource's quota table in that service. So, this will involve
>> interaction with keystone and within the quota table in the project.
>>
>> * We will be working on a migration story separately (outside of the
>> library). Delimiter does not own the quota limits and usage data so it
>> will not deal with migrations.
> Given that Glance does not currently have a quota, it may be possible to use 
> this as the initial implementation. This would also avoid a later migration 
> effort.
>
> Tim
>
>

Thanks for the response Tim. I am of the same opinion but haven't really
internalized this migration path as I've not been on the deploy-er side
of managing quota yet. Intuitively migration for quotas seems like a
terrible experience, possibly going over days?

I presume that nested quota support, if built in from get go, when the
tables are set is probably the best idea of hierarchical quota support.
Hoping that's not overly pessimistic assumption.

>>
>> On 5/4/16 1:23 PM, Vilobh Meshram wrote:
>>> Hi All,
>>>
>>> For people who missed the design summit session on Delimiter - Cross
>>> project Quota enforcement library here is a gist of what we discussed.
>>> Etherpad [1] captures the details. 
>>>
>>> 1. Delimiter will not be responsible for rate-limiting.
>>> 2. Delimiter will not maintain data for the projects.
>>> 3. Delimiter will not have the concept of reservations.
>>> 4. Delimiter will fetch information for project quotas from respective
>>> projects.
>>> 5. Delimiter will consolidate utility code for quota related issues at
>>> common place. For example X, Y, Z companies might have different
>>> scripts to fix quota issues. Delimiter can be a single place for it
>>> and the scripts can be more generalized to suit everyones needs.
>>> 6. The details of project hierarchy is maintained in Keystone but
>>> Delimiter while making calculations for available/free resource will
>>> take into consideration whether the project has flat or nested hierarchy.
>>> 7. Delimiter will rely on the concept of generation-id to guarantee
>>> sequencing. Generation-id gives a point in time view of resource usage
>>> in a project. Project consuming delimiter will need to provide this
>>> information while checking or consuming quota. At present Nova [3] has
>>> the concept of generation-id.
>>> 8. Spec [5] will be modified based on the design summit discussion.
>>>
>>> If you want to contribute to Delimiter, please join *#openstack-quota. *
>>>
>>> We have *meetings every Tuesday at 17:00 UTC. *Please join us !
>>> *
>>> *
>>> I am in the process of setting up a new repo for Delimiter. The
>>> launchpad page[4] is up.
>>>
>>>
>>> Thanks!
>>>
>>> -Vilobh
>>>
>>> [1] Etherpad : https://etherpad.openstack.org/p/newton-quota-library
>>> [2] Slides
>>> : 
>>> http://www.slideshare.net/vilobh/delimiter-openstack-cross-project-quota-library-proposal
>>>  
>>> [3] https://review.openstack.org/#/c/283253/
>>> [4] https://launchpad.net/delimiter
>>> [5] Spec : https://review.openstack.org/#/c/284454
>>>
>>>
>>>  
>>>
>>>
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> -- 
>>
>> Thanks,
>> Nikhil
>>
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-- 

Thanks,
Nikhil


__
OpenStack Development Mailing List (not for usage questions)

Re: [openstack-dev] [cross-project][quotas][delimiter] Austin Summit - Design Session Summary

2016-05-04 Thread Tim Bell 


On 04/05/16 19:41, "Nikhil Komawar"  wrote:

>Thanks for the summary and taking care of the setup, Vilobh!
>
>Pretty meticulously written on what was agreed at the session. Kudos!
>
>I wanted to add some points that were asked during the Glance
>contributors' meetup:
>
>* The quota limits will be set on the tables in the service that
>maintains the resources for each individual resource (not in keystone).
>The default value is what is picked from the config. I think over time
>we will come up with implementation detail on how the hierarchical
>default value should be set.
>
>* The quota allocation calculation will be based on the project
>hierarchy in consideration (given that driver is being used in such
>deployment scenario) and the usage for that resource recorded in the
>resource's quota table in that service. So, this will involve
>interaction with keystone and within the quota table in the project.
>
>* We will be working on a migration story separately (outside of the
>library). Delimiter does not own the quota limits and usage data so it
>will not deal with migrations.

Given that Glance does not currently have a quota, it may be possible to use 
this as the initial implementation. This would also avoid a later migration 
effort.

Tim



>
>
>On 5/4/16 1:23 PM, Vilobh Meshram wrote:
>> Hi All,
>>
>> For people who missed the design summit session on Delimiter - Cross
>> project Quota enforcement library here is a gist of what we discussed.
>> Etherpad [1] captures the details. 
>>
>> 1. Delimiter will not be responsible for rate-limiting.
>> 2. Delimiter will not maintain data for the projects.
>> 3. Delimiter will not have the concept of reservations.
>> 4. Delimiter will fetch information for project quotas from respective
>> projects.
>> 5. Delimiter will consolidate utility code for quota related issues at
>> common place. For example X, Y, Z companies might have different
>> scripts to fix quota issues. Delimiter can be a single place for it
>> and the scripts can be more generalized to suit everyones needs.
>> 6. The details of project hierarchy is maintained in Keystone but
>> Delimiter while making calculations for available/free resource will
>> take into consideration whether the project has flat or nested hierarchy.
>> 7. Delimiter will rely on the concept of generation-id to guarantee
>> sequencing. Generation-id gives a point in time view of resource usage
>> in a project. Project consuming delimiter will need to provide this
>> information while checking or consuming quota. At present Nova [3] has
>> the concept of generation-id.
>> 8. Spec [5] will be modified based on the design summit discussion.
>>
>> If you want to contribute to Delimiter, please join *#openstack-quota. *
>>
>> We have *meetings every Tuesday at 17:00 UTC. *Please join us !
>> *
>> *
>> I am in the process of setting up a new repo for Delimiter. The
>> launchpad page[4] is up.
>>
>>
>> Thanks!
>>
>> -Vilobh
>>
>> [1] Etherpad : https://etherpad.openstack.org/p/newton-quota-library
>> [2] Slides
>> : 
>> http://www.slideshare.net/vilobh/delimiter-openstack-cross-project-quota-library-proposal
>>  
>> [3] https://review.openstack.org/#/c/283253/
>> [4] https://launchpad.net/delimiter
>> [5] Spec : https://review.openstack.org/#/c/284454
>>
>>
>>  
>>
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>-- 
>
>Thanks,
>Nikhil
>
>
>__
>OpenStack Development Mailing List (not for usage questions)
>Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [cross-project][quotas][delimiter] Austin Summit - Design Session Summary

2016-05-04 Thread Nikhil Komawar 
Thanks for the summary and taking care of the setup, Vilobh!

Pretty meticulously written on what was agreed at the session. Kudos!

I wanted to add some points that were asked during the Glance
contributors' meetup:

* The quota limits will be set on the tables in the service that
maintains the resources for each individual resource (not in keystone).
The default value is what is picked from the config. I think over time
we will come up with implementation detail on how the hierarchical
default value should be set.

* The quota allocation calculation will be based on the project
hierarchy in consideration (given that driver is being used in such
deployment scenario) and the usage for that resource recorded in the
resource's quota table in that service. So, this will involve
interaction with keystone and within the quota table in the project.

* We will be working on a migration story separately (outside of the
library). Delimiter does not own the quota limits and usage data so it
will not deal with migrations.


On 5/4/16 1:23 PM, Vilobh Meshram wrote:
> Hi All,
>
> For people who missed the design summit session on Delimiter - Cross
> project Quota enforcement library here is a gist of what we discussed.
> Etherpad [1] captures the details. 
>
> 1. Delimiter will not be responsible for rate-limiting.
> 2. Delimiter will not maintain data for the projects.
> 3. Delimiter will not have the concept of reservations.
> 4. Delimiter will fetch information for project quotas from respective
> projects.
> 5. Delimiter will consolidate utility code for quota related issues at
> common place. For example X, Y, Z companies might have different
> scripts to fix quota issues. Delimiter can be a single place for it
> and the scripts can be more generalized to suit everyones needs.
> 6. The details of project hierarchy is maintained in Keystone but
> Delimiter while making calculations for available/free resource will
> take into consideration whether the project has flat or nested hierarchy.
> 7. Delimiter will rely on the concept of generation-id to guarantee
> sequencing. Generation-id gives a point in time view of resource usage
> in a project. Project consuming delimiter will need to provide this
> information while checking or consuming quota. At present Nova [3] has
> the concept of generation-id.
> 8. Spec [5] will be modified based on the design summit discussion.
>
> If you want to contribute to Delimiter, please join *#openstack-quota. *
>
> We have *meetings every Tuesday at 17:00 UTC. *Please join us !
> *
> *
> I am in the process of setting up a new repo for Delimiter. The
> launchpad page[4] is up.
>
>
> Thanks!
>
> -Vilobh
>
> [1] Etherpad : https://etherpad.openstack.org/p/newton-quota-library
> [2] Slides
> : 
> http://www.slideshare.net/vilobh/delimiter-openstack-cross-project-quota-library-proposal
>  
> [3] https://review.openstack.org/#/c/283253/
> [4] https://launchpad.net/delimiter
> [5] Spec : https://review.openstack.org/#/c/284454
>
>
>  
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-- 

Thanks,
Nikhil


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [cross-project][quotas][delimiter] Austin Summit - Design Session Summary

2016-05-04 Thread Vilobh Meshram 
Hi All,

For people who missed the design summit session on Delimiter - Cross
project Quota enforcement library here is a gist of what we discussed.
Etherpad [1] captures the details.

1. Delimiter will not be responsible for rate-limiting.
2. Delimiter will not maintain data for the projects.
3. Delimiter will not have the concept of reservations.
4. Delimiter will fetch information for project quotas from respective
projects.
5. Delimiter will consolidate utility code for quota related issues at
common place. For example X, Y, Z companies might have different scripts to
fix quota issues. Delimiter can be a single place for it and the scripts
can be more generalized to suit everyones needs.
6. The details of project hierarchy is maintained in Keystone but Delimiter
while making calculations for available/free resource will take into
consideration whether the project has flat or nested hierarchy.
7. Delimiter will rely on the concept of generation-id to guarantee
sequencing. Generation-id gives a point in time view of resource usage in a
project. Project consuming delimiter will need to provide this information
while checking or consuming quota. At present Nova [3] has the concept of
generation-id.
8. Spec [5] will be modified based on the design summit discussion.

If you want to contribute to Delimiter, please join *#openstack-quota. *

We have *meetings every Tuesday at 17:00 UTC. *Please join us !

I am in the process of setting up a new repo for Delimiter. The launchpad
page[4] is up.


Thanks!

-Vilobh

[1] Etherpad : https://etherpad.openstack.org/p/newton-quota-library
[2] Slides :
http://www.slideshare.net/vilobh/delimiter-openstack-cross-project-quota-library-proposal


[3] https://review.openstack.org/#/c/283253/
[4] https://launchpad.net/delimiter
[5] Spec : https://review.openstack.org/#/c/284454
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev