Open Stack

Hello Folks,

Thank you Zane, Steven and Clint for you input.

Our main goal in this BP is to provide networking users such as Heat (we
consider it as a neutron user) a better and consolidated network building
block in terms of an API that you could use for orchestration of
application-driven requirements. This building block does not add any
"intelligence" to the network topology because it does not have it and
this is why I think this BP is different from the work that you are doing
in Heat.

The network topologies BP is not related to the Neutron Network Service
Insertion BP:
https://blueprints.launchpad.net/neutron/+spec/neutron-services-insertion-c
haining-steering


I do agree with Steven that the insertion work add "intelligence"
(explicit management of dependencies, state and workflow) to the network
orchestration simply because user will need to know the insertion
mechanism and dependencies between Network Advances Services, that work is
more into Heat space that the BP that I am proposing but that is just my
opinion.

However, is there a session where I can discuss this BP with you guys?,
the session that I proposed in Neutron has been rejected because it was
considered by the PTL as an overlapping work with the Heat goals,
therefore I wanted to know if you can to discuss it or I just simple go
ahead and start the implementation. I do still believe it can be easily
implemented in Neutron and then exposed to Heat but I am really looking
forward to having a broader discussion.

Thanks,

Edgar


On 10/28/13 9:47 AM, "Clint Byrum" <clint at fewbar.com> wrote:

>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_nkmuHYxCuUZ8HuryH752gQnkmrZd
>>XeE2LM/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.
>
>_______________________________________________
>OpenStack-dev mailing list
>OpenStack-dev at lists.openstack.org
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev