Open Stack

Hi Bob,

Thanks for reaching out!

We're in the process of finalizing the API and the team is working hard
on getting the code ready; atm with near to complete functionality WIP
patches. Please be mindful of the fact that there is currently an
experimental API in glance and code that will change completely. As we
do not want to document these things, they are missing from the search
results of advanced search engines.

A good reference document is [1] . This spec has evolved over time and
has input from many a standards so I do not expect drastic changes
unless some security loophole is found during testing (Probability ~0.1).

Hope that helps.

[1] https://review.openstack.org/#/c/283136/

On 5/4/16 10:08 AM, HADDLETON, Robert W (Bob) wrote:
> 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
>>>
>>>
>>
>
>
>
> __________________________________________________________________________
> 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160504/2f3b04d0/attachment.html>