[openstack-dev] [Glance] [all] Liberty summit: Updates in Glance
Flavio Percoco
flavio at redhat.com
Wed May 27 07:57:34 UTC 2015
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>
More information about the OpenStack-dev
mailing list