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.koma...@gmail.com <mailto:nik.koma...@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.
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.

    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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Reply via email to