Thanks for your feedback Erno. I've answered your question inline. On 3/17/16 2:21 AM, Erno Kuvaja wrote: > On Wed, Mar 16, 2016 at 6:25 AM, Nikhil Komawar <nik.koma...@gmail.com > <mailto:nik.koma...@gmail.com>> wrote: > > Hello everyone, > > > > tl;dr; > > I'm writing to request some feedback on whether the cross project > Quotas > > work should move ahead as a service or a library or going to a far > > extent I'd ask should this even be in a common repository, would > > projects prefer to implement everything from scratch in-tree? > Should we > > limit it to a guideline spec? > > > > But before I ask anymore, I want to specifically thank Doug Hellmann, > > Joshua Harlow, Davanum Srinivas, Sean Dague, Sean McGinnis and Andrew > > Laski for the early feedback that has helped provide some good > shape to > > the already discussions. > > > > Some more context on what the happenings: > > We've this in progress spec [1] up for providing context and platform > > for such discussions. I will rephrase it to say that we plan to > > introduce a new 'entity' in the Openstack realm that may be a > library or > > a service. Both concepts have trade-offs and the WG wanted to get more > > ideas around such trade-offs from the larger community. > > > Would you mind to expand this "we" here? >
Quota WG ( http://eavesdrop.openstack.org/#Cross-project_Quotas_and_Nested_Quotas_Working_Group_Virtual_Standup ) > > Service: > > This would entail creating a new project and will introduce managing > > tables for quotas for all the projects that will use this service. For > > example if Nova, Glance, and Cinder decide to use it, this > 'entity' will > > be responsible for handling the enforcement, management and DB > upgrades > > of the quotas logic for all resources for all three projects. This > means > > less pain for projects during the implementation and maintenance > phase, > > holistic view of the cloud and almost a guarantee of best practices > > followed (no clutter or guessing around what different projects are > > doing). However, it results into a big dependency; all projects > rely on > > this one service for right enforcement, avoiding races (if do not > > incline on implementing some of that in-tree) and DB > > migrations/upgrades. It will be at the core of the cloud and prone to > > attack vectors, bugs and margin of error. > > > I'd prefer not. As lots of concern raised already ref. latency, extra > api etc. > Based on the unifying the user interface, common api might be desired > option, but it's own service, not so much. > > > > Library: > > A library could be thought of in two different ways: > > 1) Something that does not deal with backed DB models, provides a > > generic enforcement and management engine. To think ahead a little bit > > it may be a ABC or even a few standard implementation vectors that can > > be imported into a project space. The project will have it's own > API for > > quotas and the drivers will enforce different types of logic; per se > > flat quota driver or hierarchical quota driver with custom/project > > specific logic in project tree. Project maintains it's own DB and > > upgrades thereof. > > > Partially decent idea, just the fact annoys me that this is climbing > the tree > arse ahead. The individual API's is perhaps the worst option with common > code for the quotas as each project has their own requirements where the > API might be generalized. > > > 2) A library that has models for DB tables that the project can import > > from. Thus the individual projects will have a handy outline of > what the > > tables should look like, implicitly considering the right table > values, > > arguments, etc. Project has it's own API and implements drivers > in-tree > > by importing this semi-defined structure. Project maintains it's own > > upgrades but will be somewhat influenced by the common repo. > > > This is really not benefitting anyone. Again each project has their own > requirements for quotas, while the user experience is the one thing we > should try to unify. I have really difficulties to see Zaqar, Nova and > Glance > fitting into the single quota model, while the API interacting with > those could > be similar. > > > Library would keep things simple for the common repository and > sourcing > > of code can be done asynchronously as per project plans and priorities > > without having a strong dependency. On the other hand, there is a > > likelihood of re-implementing similar patterns in different projects > > with individual projects taking responsibility to keep things up to > > date. Attack vectors, bugs and margin of error are project > responsibilities > > > This is the problem I see with oslo approach currently. Originally > intended for > place to collect the common code from projects turning to "enforcing" > entity > of code some people thinks should be common and does not fit most. > > > > Third option is to avoid all of this and simply give guidelines, best > > practices, right packages to each projects to implement quotas > in-house. > > Somewhat undesirable at this point, I'd say. But we're all ears! > > > This is probably the best solution without "best practices", again one > model > does not suite all, but common concepts, specially on the interacting API > side is desired. _If_ proven that most of the projects would fit to > the same > suite, common lib could be built out of the outcome. > > > > > Thank you for reading and I anticipate more feedback. > > > > [1] https://review.openstack.org/#/c/284454/ > > > > -- > > > > Thanks, > > Nikhil > > > > I'd really like to see a project implementing quotas well, interacted > via API > agreed on the API Working Group (not too specific so it can be adopted for > majority of use cases) and proved taking the corner cases into > account. Like > starting with fixing the Cinder quotas in the first place (not > pointing fingers but > looking for proof of success) and showing that the initiative has basis of > accountability. > > Best, > Erno > > > > > __________________________________________________________________________ > > OpenStack Development Mailing List (not for usage questions) > > Unsubscribe: > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > <http://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) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
