Open Stack

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.

I think regardless of what we do, I'd like to kill v1 as it has a
sharing model that is not secure.

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150527/03bd9d80/attachment.pgp>