Open Stack

On Sun, Oct 27, 2013 at 08:37:15AM -0700, Edgar Magana wrote:
> Heat Developers,
> 
> I am one of the core developers for Neutron who is lately working on the
> concept of "Network Topologies". I want to discuss with you if the
> following blueprint will make sense to have in heat or neutron code:
> https://blueprints.launchpad.net/neutron/+spec/network-topologies-api
> 
> Basically, I want to let tenants “save”, “duplicate” and “share” network
> topologies by means of an API and a standardized JSON format that describes
> network topologies. This google document provides detailed description:
> https://docs.google.com/document/d/1nPkLcUma_nkmuHYxCuUZ8HuryH752gQnkmrZdXeE2LM/edit#
> 
> There is a concern in Neutron of not duplicating efforts done by Heat team
> and also to find the right place for this API.
> 
> The intended work does NOT include any application driven orchestration
> system, does NOT include any already existing or vender-specific standard
> format for describing topologies, actually we want to standardized one
> based on Neutron but it is still on discussion.
> 
> If Heat developers could provide their point of view about this proposal,
> wether it should be moved to Heat or it is fine to keep it in Neutron.

This seems related to a discussion I had last week re the Neutron services
insertion and chaining functionality:

https://blueprints.launchpad.net/neutron/+spec/neutron-services-insertion-chaining-steering

It does seem that you (Neutron) are moving towards functionality which
requires more explicit management of dependencies, state and workflow, such
that it may make sense to implement, some of it at least, in Heat.

My opinion is that we should expose all of the underlying Neutron
capabilities (individual bits of functionality) via Heat resources, which I
think we're currently doing quite well (see [1] for the current list of
supported functionality)

Then any functionality requiring aggregation of resources where
dependencies and state are used to create a workflow, should probably
happen in Heat, IMHO.  It doesn't make sense to me to have two projects
building a dependency graph, managing state, and orchestrating workflow for
the same underlying Neutron features.

We should definitely continue these discussions so we can figure out where
the most appropriate integration points may be.

Steve

[1] http://docs.openstack.org/developer/heat/template_guide/index.html