[openstack-dev] [glance] [glare] [heat] [tosca] [tacker] [murano] [magnum] [app-catalog] Austin summit summary: Generic cataloging and Glare v1 API

Nikhil Komawar nik.komawar at gmail.com
Tue May 3 19:40:51 UTC 2016


Comment inline.

On 5/3/16 3:21 PM, Flavio Percoco wrote:
> On 02/05/16 19:09 -0400, Nikhil Komawar wrote:
>
>> Added a few more tags to the subject line.
>>
>>
>>
>> On 5/2/16 7:05 PM, Nikhil Komawar wrote:
>>
>>> Hello everyone,
>>>
>>>
>>>
>>> Just wanted to send a brief summary of the discussions at the summit.
>>>
>>> This list is not holistic however, it covers the relevant aspects that
>>>
>>> various stakeholders need to be aware of.
>>>
>>>
>>>
>>>   * Glare is useful for different use cases in OpenStack including
>>>
>>>     currently being asked for in Heat, Murano and TOSCA
>>>
>>>   * Heat needs something for usage in Newton
>>>
>>>   * Murano needs the stable API to adapt the changes as they currently
>>>
>>>     use experimental version
>>>
>>>   * Glance team will continue to make progress on this effort and plan
>>>
>>>     to have POC after Newton R-16 [1]
>>>
>>>   * The initial plan is to focus on base artifact (no data asset
>>>
>>>     associated) and then support at least one artifact type
>>>
>>>   * The first artifact can be Murano application catalogs or Heat
>>>
>>>     templates depending on either team's priorities when Glare is ready
>>>
>>>     for consumption
>>>
>>>   * In Newton, we will focus on the adoption of this service in at least
>>>
>>>     the above mentioned two projects and getting the API in good shape
>>>
>>>   * Images compatibility is deferred for now
>>>
>>>   * Glare will be a side-priority for Newton meaning most of the cores
>>>
>>>     are currently not expected to prioritize reviews on it except for
>>>
>>>     those who want to focus on cross project initiatives and those
>>>
>>>     involved in its adoption
>>>
>
>
> Does this mean there will be some sort of "Fast Track" again? I'm
> asking because

No, we won't have the FastTrack model. But at the same time, we want to
iterate over the code once that is consumed by the first service so that
the behavioral changes found during that phase can be corrected before
m-3. The end goal is to have a good API that can be consumed by other
services (and something compliant with OpenStack standards).

>
> I believe this model polarizes the community a bit as far as picking
> reviews go.
>
> We voted to remove it in Mitaka and I was hoping we would workout a
> way to bring
>
> the community together in the Glare reviews.

My goal is to have champions for each module that is being worked on in
Newton (import, micro-versions, glare, documentation, etc) . This does
have a little bit of effect in creating tribal knowledge but we do have
that even today. The iterative plan though (yet to be formalized) is
that we need some sort of knowledge sharing model. I have been trying to
do that using the dedicated Glare meetings but we may need other models
of KT (knowledge transfer) here.

>
>
>
> Please, don't get me wrong. As far as priorities go, I agree with what
> you've

Thanks for bringing this up. Refines the thought process for sure.

>
> said in the last point but review wise, I'm worried this would
> implicitly bring
>
> back some kind of fast track model.
>
>

Let's not go with the FastTrack model :-)

>
> Cheers,
>
> Flavio
>
>
>
>
>
> __________________________________________________________________________
> 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
>
>


-- 

Thanks,
Nikhil





More information about the OpenStack-dev mailing list