Open Stack

I kinda agree with all 3 of you, possibly because there are Grey areas 
on how best we can actually do this. We are talking about one cycle 
ahead to the very least. While that is a great thing to do, I think we 
should focus on making the current Artifacts implementation stable & 
bring it to a state that it works great with the different data asset 
requirements within OpenStack realm (to support the main motivation 
behind this concept and Glance's mission statement).

Cheers
Nikhil

On 5/27/15 8:30 AM, Kuvaja, Erno wrote:
>> -----Original Message-----
>> From: Flavio Percoco [mailto:flavio at redhat.com]
>> Sent: 27 May 2015 00:58
>> To: OpenStack Development Mailing List (not for usage questions)
>> Subject: Re: [openstack-dev] [Glance] [all] Liberty summit: Updates in Glance
>>
>> Jesse, you beat me on this one :)
>>
>> On 26/05/15 13:54 -0400, Nikhil Komawar wrote:
>>> Thank you Jesse for your valuable input (here and at the summit) as
>>> well as intent to clarify the discussion.
>>>
>>> Just trying to ensure people are aware about the EXPERIMENTAL nature of
>>> the v3 API and reasons behind it. Please find my responses in-line.
>>> However, I do want to ensure you all, that we will strive hard to move
>>> away from the EXPERIMENTAL nature and go with a rock solid
>>> implementation as and when interest grows in the code-base (that helps
>> stabilize it).
>>> On 5/26/15 12:57 PM, Jesse Cook wrote:
>>>
>>>
>>>     On 5/22/15, 4:28 PM, "Nikhil Komawar" <nik.komawar at gmail.com>
>> wrote:
>>>
>>>         Hi all,
>>>
>>>         tl;dr; Artifacts IS staying in Glance.
>>>
>>>          1. We had a nice discussion at the contributors' meet-up at the
>>>             Vancouver summit this morning. After weighing in many possibilities
>>>             and evolution of the Glance program, we have decided to go ahead
>>>             with the Artifacts implementation within Glance program under the
>>>             EXPERIMENTAL v3 API.
>>>
>>>     Want to clarify a bit here. My understanding is: s/Artifacts/v3 API/g. That
>>>     is to say, Artifacts is the technical implementation of the v3 API. This
>>>     also means the v3 API is an objects API vs just an images API.
>>>
>>>
>>> Generic "data assets'" API would be a nice term along the lines of the
>>> mission statement. Artifacts seemed fitting as that was the focus of
>>> discussion at various sessions.
>> Regardless of how we call it, I do appreciate the clarity on the fact that
>> Artifacts - data assests - is just the technical implementation of what will be
>> Glance's API v3. It's an important distinction to avoid sending the wrong
>> message on what it's going to be done there.
>>
>>>     We also had some hallway talk about putting the v1 and v2 APIs on top of
>>>     the v3 API. This forces faster adoption, verifies supportability via v1 and
>>>     v2 tests, increases supportability of v1 and v2 APIs, and pushes out the
>>>     need to kill v1 API.
>>>
>>> Let's discuss more as time and development progresses on that
>>> possibility. v3 API should stay EXPERIMENTAL for now as that would help
>>> us understand use-cases across programs as it gets adopted by various
>>> code-bases. Putting v1/v2 on top of v3 would be tricky for now as we
>>> may have breaking changes with code being relatively-less stable due to
>> narrow review domain.
>>
>> I actually think we'd benefit more from having V2 on top of V3 than not doing
>> it. I'd probably advocate to make this M material rather than L but I think it'd
>> be good.
> We perhaps would, but that would realistically push v2 adoption across the projects to somewhere around O release. Just looking how long it took the v2 code base to mature enough that we're seriously talking moving to use that in production.
>> I think regardless of what we do, I'd like to kill v1 as it has a sharing model
>> that is not secure.
> The above would postpone this one somewhere around Q-R (which is btw. not so far from U anymore).
>
> More I think about this the more convinced I am about focusing to the move to v2 on our consumers, deprecating the v1 out and after that we can start talking about moving v2 on top of the v3 codebase if possible, not other way around hoping that it would speed up the v3 adoption.
>
> - Erno
>> Flavio
>>
>>>          1.
>>>          2. The effort would primarily be conducted as a sub-team-like
>>>             structure within the program and the co-coordinators and drivers of
>>>             the necessary Artifacts features would be given core-reviewer
>>>             status temporarily with an informal agreement to merge code that is
>>>             only related to Artifacts.
>>>          3. The entire Glance team would give reviews as time and priorities
>>>             permit. The approval (+A/+WorkFlow) of any code within the
>> program
>>>             would need to come from core-reviewers who are not temporarily
>>>             authorized. The list of such individuals and updated time-line
>>>             would be documented in phases during the course of Liberty cycle.
>>>          4. We will continue to evaluate & update the governance, maturity of
>>>             the code and future plans for the v1, v2 and v3 Glance APIs as time
>>>             progresses. However, for now we are aiming to integrate all of
>>>             Glance (specifically Images) as Artifacts in the v3 API.
>>>
>>>
>>>     As I understand it, that is to say that v3 requests in the first
>>>     “micro-version” that specify the object type as image would get a not
>>>     implemented or similar error. The next next “micro-version” would likely
>>>     contain the support for images along with possibly implementing the v1
>> and
>>>     v2 APIs on top of v3.
>>>
>>> As we will have EXPERIMENTAL v3 API, we should try to avoid micro-
>> versions.
>>> However, we should soon consider this as a possibility once things seem
>>> to stabilize.
>>>
>>>          1.
>>>         Special thanks to Flavio for providing DefCore and TC perspective as
>>>         well as initializing this discussion. Also, thanks to Stuart McLaren
>>>         and Brian Rosmaita for giving us thoughtful veteran feedback. The
>>>         entire team did a great job at putting all their questions and concerns
>>>         amicably on the table and came to a good understanding of the plan
>> and
>>>         level of commitment.
>>>
>>>         All the best to the Project SearchLight team who have decided to start
>>>         ElasticSearch based development for search functionality in OpenStack
>>>         as a separate program and would be porting respective code out of
>>>         Glance. Glance team would help co-ordinate this porting effort in order
>>>         to avoid destabilizing Images and MetaDefs code-bases.
>>>
>>>         This also means we will re-evaluate some of the existing spec proposals
>>>         and most likely not ask people for radical changes in their approach.
>>>         This first phase of the Liberty cycle would focus on seeing the
>>>         Experimental Artifacts API through. We will also focus on stability
>>>         aspects of the Images (v1 & v2) related features. The second phase
>>>         priorities would be decided at the mid-cycle meet-up (details to come
>>>         out soon).
>>>
>>>         Feel free to ask me questions on IRC or via email.
>>>
>>>         Cheers,
>>>         Nikhil
>>>
>>>
>>>
>>>
>> __________________________________________________________
>> ________________
>>>     OpenStack Development Mailing List (not for usage questions)
>>>     Unsubscribe: OpenStack-dev-
>> request at lists.openstack.org?subject:unsubscribe
>>>     http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>> Cheers,
>>> Nikhil
>>> _________________________________________________________
>> ______________
>>> ___ OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe:
>>> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>> --
>> @flaper87
>> Flavio Percoco
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev