Open Stack

Hi Steve,

Thank you for sharing your thoughts. I believe that is what we were trying
to receive as a feedback form TC. The current definition of program
actually suggest the scenario you described. A new project will appear
under Orchestration umbrella. Let say there will be two project one is Heat
and another is Workflow (no specific name here, probably some part of
Murano).  Program will have one PTL (current Heat PTL) and two separate
code team for each project. That was our understanding of what we want. I
am not sure that this was enough stressed out on TC meeting. There were no
any intentions to add anything to Heat. Not at all. We just discussed a
possibility to split current Murano App Catalog into two parts. Catalog
part would go to Catalog program to land App Catalog code near Glance
project and integrate them as Glance will store application packages for
Murano App Catalog service. The second part of Murano related to
environment processing (deployment, life cycle management, events) would go
to Orchestration program as a new project like Murano workflows or Murano
environment control or anything else.

As I mentioned in one of the previous e-mails, we already discussed with
the heat team workflows & Heat before HK summit. We understand this very
well that workflows will not fit Heat and we perfectly understand reasons
why.

I think that the good result of last TC was the official mandate to discuss
alignment and integration between projects Glance, Heat, Murano and
probably other projects. Right now we consider the following:
1) Continue discussion around Catalog program mission and how Murano App
Catalog will fit into this program.
2) Start conversation with the Heat team in two directions:
  a) TOSCA and its implementation. How Murano can extend TOSCA and how
TOSCA can help Murano to define an application package. Murano should reuse
as much as possible from TOSCA to implement this open standard
  b) Define the alignment between Heat and Murano. How workflows can
coexist with HOT. What will be the best way to develop both Heat and
Workflows within Orchestration program.
3) Explore Application space for OpenStack. As Thierry mentioned on TC
meeting, there are concerns that it is probably to early for OpenStack to
make a new step up to the stack.

Thanks,
Georgy


On Wed, Mar 5, 2014 at 7:47 PM, Steven Dake <sdake at redhat.com> wrote:

> 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
>>
>
>
> _______________________________________________
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140305/8550ee7b/attachment.html>