Open Stack

Excerpts from Steven Hardy's message of 2013-10-28 07:47:06 -0700:
> 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.
> 

Could not have said it better myself, thanks Steve.

One thing this brings to mind is the proposal for adopt/abandon. This
may be a new use case for that feature in Heat.

Neutron would be able to adopt all of the standing network topology to
do the serialization into a HOT template, and give it to the Neutron user.

Then to reverse the process Neutron can accept this Heat template
back from the user, and just use it to spin up the topology, but then
immediately abandon the stack. We get the workflow and dependency feature
without having to leave a dangling stack around for Neutron to clean up.

That would make it easier for users to interact with this feature without
actually needing to interact with Heat, and would also reduce Neutron's
footprint in Heat.