Open Stack

On 03/05/2014 02:16 AM, Thomas Spatzier wrote:
> Georgy Okrokvertskhov <gokrokvertskhov at mirantis.com> wrote on 05/03/2014
> 00:32:08:
>
>> From: Georgy Okrokvertskhov <gokrokvertskhov at mirantis.com>
>> To: "OpenStack Development Mailing List (not for usage questions)"
>> <openstack-dev at lists.openstack.org>
>> Date: 05/03/2014 00:34
>> Subject: Re: [openstack-dev] Incubation Request: Murano
>>
>> Hi Thomas, Zane,
>>
>> Thank you for bringing TOSCA to the discussion. I think this is
>> important topic as it will help to find better alignment or even
>> future merge of Murano DSL and Heat templates. Murano DSL uses YAML
>> representation too, so we can easily merge use constructions from
>> Heat and probably any other YAML based TOSCA formats.
>>
>> I will be glad to join TOSCA TC. Is there any formal process for that?
> The first part is that your company must be a member of OASIS. If that is
> the case, I think you can simply go to the TC page [1] and click a button
> to join the TC. If your company is not yet a member, you could get in touch
> with the TC chairs Paul Lipton and Simon Moser and ask for the best next
> steps. We recently had people from GigaSpaces join the TC, and since they
> are also doing very TOSCA aligned implementation in Cloudify, their input
> will probably help a lot to advance TOSCA.
>
>> I also would like to use this opportunity and start conversation
>> with Heat team about Heat roadmap and feature set. As Thomas
>> mentioned in his previous e-mail TOSCA topology story is quite
>> covered by HOT. At the same time there are entities like Plans which
>> are covered by Murano. We had discussion about bringing workflows to
>> Heat engine before HK summit and it looks like that Heat team has no
>> plans to bring workflows into Heat. That is actually why we
>> mentioned Orchestration program as a potential place for Murano DSL
>> as Heat+Murano together will cover everything which is defined by TOSCA.
> I remember the discussions about whether to bring workflows into Heat or
> not. My personal opinion is that workflows are probably out of the scope of
> Heat (i.e. everything but the derived orchestration flows the Heat engine
> implements). So there could well be a layer on-top of Heat that lets Heat
> deal with all topology-related declarative business and adds workflow-based
> orchestration around it. TOSCA could be a way to describe the respective
> overarching models and then hand the different processing tasks to the
> right engine to deal with it.
My general take is workflow would fit in the Orchestration program, but 
not be integrated into the heat repo specifically.  It would be a 
different repo, managed by the same orchestration program just as we 
have heat-cfntools and other repositories.  Figuring out how to handle 
the who is the core team of people responsible for program's individual 
repositories is the most difficult aspect of making such a merge.  For 
example, I'd not desire a bunch of folks from Murano +2/+A heat specific 
repos until they understood the code base in detail, or atleast the 
broad architecture.   I think the same think applies in reverse from the 
Murano perspective.  Ideally folks that are core on a specific program 
would need to figure out how to learn how to broadly review each repo 
(meaning the heat devs would have to come up to speed on murano and 
murano devs would have to come up to speed on heat.  Learning a new code 
base is a big commitment for an already overtaxed core team.

I believe expanding our scope in this way would require TC approval.

The main reason I don't want workflow in the heat repo specifically is 
because it adds complication to Heat itself.  We want Heat to be one 
nice tidy small set of code that does one thing really well. This makes 
it easy to improve, easy to deploy, and easy to learn!

These reasons are why, for example, we are continuing to push the 
autoscaling implementation out of Heat and into a separate repository 
over the next 1 to 2 cycles   This on the other hand won't be an 
expansion of scope of the Orchestration program, because we already do 
autoscaling, we just want to make it more consumable.

Regards,
-steve


>> I think TOSCA initiative can be a great place to collaborate. I
>> think it will be possible then to use Simplified TOSCA format for
>> Application descriptions as TOSCA is intended to provide such
> descriptions.
>> Is there a team who are driving TOSCA implementation in OpenStack
>> community? I feel that such team is necessary.
> We started to implement a TOSCA YAML to HOT converter and our team member
> Sahdev (IRC spzala) has recently submitted code for a new stackforge
> project [2]. This is very initial, but could be a point to collaborate.
>
> [1] https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=tosca
> [2] https://github.com/stackforge/heat-translator
>
> Regards,
> Thomas
>
>> Thanks
>> Georgy
>>
>> On Tue, Mar 4, 2014 at 2:36 PM, Thomas Spatzier
> <thomas.spatzier at de.ibm.com
>>> wrote:
>> Excerpt from Zane Bitter's message on 04/03/2014 23:16:21:
>>> From: Zane Bitter <zbitter at redhat.com>
>>> To: openstack-dev at lists.openstack.org
>>> Date: 04/03/2014 23:20
>>> Subject: Re: [openstack-dev] Incubation Request: Murano
>>>
>>> On 04/03/14 00:04, Georgy Okrokvertskhov wrote:
>>> It so happens that the OASIS's TOSCA technical committee are working as
>>> we speak on a "TOSCA Simple Profile" that will hopefully make things
>>> easier to use and includes a YAML representation (the latter is great
>>> IMHO, but the key to being able to do it is the former). Work is still
>>> at a relatively early stage and in my experience they are very much
> open
>>> to input from implementers.
>> Nice, I was probably also writing a mail with this information at about
> the
>> same time :-)
>> And yes, we are very much interested in feedback from implementers and
> open
>> to suggestions. If we can find gaps and fill them with good proposals,
> now
>> is the right time.
>>
>>> I would strongly encourage you to get involved in this effort (by
>>> joining the TOSCA TC), and also to architect Murano in such a way that
>>> it can accept input in multiple formats (this is something we are
> making
>>> good progress toward in Heat). Ideally the DSL format for Murano+Heat
>>> should be a trivial translation away from the relevant parts of the
> YAML
>>> representation of TOSCA Simple Profile.
>> Right, having a straight-forward translation would be really desirable.
> The
>> way to get there can actually be two-fold: (1) any feedback we get from
> the
>> Murano folks on the TOSCA simple profile and YAML can help us to make
> TOSCA
>> capable of addressing the right use cases, and (2) on the other hand make
>> sure the implementation goes in a direction that is in line with what
> TOSCA
>> YAML will look like.
>>
>>> cheers,
>>> Zane.
>>>
>>> _______________________________________________
>>> OpenStack-dev mailing list
>>> OpenStack-dev at lists.openstack.org
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>> --
>> Georgy Okrokvertskhov
>> Architect,
>> OpenStack Platform Products,
>> Mirantis
>> http://www.mirantis.com
>> Tel. +1 650 963 9828
>> Mob. +1 650 996 3284_______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev