Open Stack

I'm not sure how you could avoid dependencies in any network configuration worth dumping and restoring.

One case that I'd like to use the functionality you list is the following:

I have an external network, and I create a private network per tenant and attach it via a router to the public network. This is the "tenant public network"

I need to create this network per tenant. Having a tool to save and repeat this activity would be very nice.

But even being this simple, the network needs to be created before the router can be created/attached to it.

How about extended neutron services? There will probably some day (if not already) be some that need things started in order. LBaaS? Network first then LB?

Heat already supports all of this.

Thanks,
Kevin
________________________________________
From: Edgar Magana [emagana at plumgrid.com]
Sent: Tuesday, October 29, 2013 11:33 AM
To: OpenStack List
Subject: Re: [openstack-dev] [Heat] Network topologies

Tim,

You statement "building an api that manages a network topology more than
one that needs to build out the dependencies between resources to help
create the network topology"
Is exactly what we are proposing, and this is why we believe this is not
under Heat domain.

This is why we are NOT proposing to manage any dependency between network
elements, that part is what I call "intelligence" of the orchestration and
we are not proposing any orchestration system, you are already have that
in place :-)

So, we simple want an API that tenats may use to "save", "retrieve" and
"share" topologies. For instance, tenant A creates a topology with two
networks (192.168.0.0/24 and 192.168.1.0/24) both with dhcp enabled and a
router connecting them. So, we first create it using CLI commands or
Horizon and then we call the API to save the topology for that tenant,
that topology can be also share  between tenants if the owner wanted to do
that, the same concept that we have in Neutron for "share networks", So
Tenant B or any other Tenants, don't need to re-create the whole topology,
just "open" the shared topology from tenant A. Obviously, overlapping IPs
will be a "must" requirement.

I am including in this thread to Mark McClain who is the Neutron PTL and
the main guy expressing concerns in not  having overlapping
functionalities between Neutron and Heat or any other project.

I am absolutely, happy to discuss further with you but if you are ok with
this approach we could start the development in Neutron umbrella, final
thoughts?

Thanks,

Edgar

On 10/29/13 8:23 AM, "Tim Schnell" <tim.schnell at RACKSPACE.COM> wrote:

>Hi Edgar,
>
>It seems like this blueprint is related more to building an api that
>manages a network topology more than one that needs to build out the
>dependencies between resources to help create the network topology. If we
>are talking about just an api to "save", "duplicate", and "share" these
>network topologies then I would agree that this is not something that Heat
>currently does or should do necessarily.
>
>I have been focusing primarily on front-end work for Heat so I apologize
>if these questions have already been answered. How is this API related to
>the existing network topology in Horizon? The existing network topology
>can already define the relationships and dependencies using Neutron I'm
>assuming so there is no apparent need to use Heat to gather this
>information. I'm a little confused as to the scope of the discussion, is
>that something that you are potentially interested in changing?
>
>Steve, Clint and Zane can better answer whether or not Heat wants to be in
>the business of managing existing network topologies but from my
>perspective I tend to agree with your statement that if you needed Heat to
>help describe the relationships between network resources then that might
>be duplicated effort but if don't need Heat to do that then this blueprint
>belongs in Neutron.
>
>Thanks,
>Tim
>
>
>
>
>
>On 10/29/13 1:32 AM, "Steven Hardy" <shardy at redhat.com> wrote:
>
>>On Mon, Oct 28, 2013 at 01:19:13PM -0700, Edgar Magana wrote:
>>> 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.
>>
>>So how do you propose to handle dependencies between elements in the
>>topology, e.g where things need to be created/deleted in a particular
>>order, or where one resource must be in a particular state before another
>>can be created?
>>
>>> The network topologies BP is not related to the Neutron Network Service
>>> Insertion BP:
>>>
>>>https://blueprints.launchpad.net/neutron/+spec/neutron-services-insertio
>>>n
>>>-c
>>> haining-steering
>>
>>So I wasn't saying they were related, only that they both, arguably, may
>>have some scope overlap with what Heat is doing.
>>
>>> 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.
>>
>>This seems a good reason to leverage the work we're doing rather than
>>reinventing it.  I'm not arguing that Heat should necessarily be the
>>primary interface to such functionality, only that Heat could (and
>>possibly
>>should) be used to do the orchestration aspects.
>>
>>> 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.
>>
>>I don't think we have any sessions directly related to Neutron, but we
>>are
>>definitely interested in discussing this (and other Neutron BPs which may
>>have integration points requiring orchestration).
>>
>>I suggest we have an informal breakout session with those interested on
>>Tuesday or Wednesday, or it could be a topic which Steve Baker may
>>consider
>>for this placeholder session:
>>
>>http://summit.openstack.org/cfp/details/360
>>
>>Steve
>>
>>_______________________________________________
>>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