Open Stack

Hi Nikhil:
     The Tacker project may also be interested in using Glare during 
this cycle.  Is there any API or other documentation/examples that we 
could use to start?

Thanks

Bob

On 5/3/2016 2:40 PM, EXT Nikhil Komawar wrote:
> 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
>>
>>
>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: bob_haddleton.vcf
Type: text/x-vcard
Size: 255 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160504/0b689866/attachment.vcf>