[openstack-dev] [Heat] Network topologies

Salvatore Orlando sorlando at nicira.com
Sat Nov 2 20:12:14 UTC 2013


Hi.

I looked at the detailed API specification submitted by Edgar.
I think that the document Edgar shared does a fine job in discussion how an
API for managing logical topologies should work.
On the other hand, there are two aspects which still need some
clarification, and which perhaps are at the source of the confusion
regarding whether it belongs to neutron, heat, or anywhere else.

First, the "use cases" section merely re-states the objective session. I
think that section should somehow address the questions "why do we need
this API?" "How having an API for storing network topologies would be
useful for us".

The other aspect is that - and I might be terribly wrong here - I think
that one of the goals Neutron API was already supposed to abstract the
complexity of network topologies - if we need another API (or perhaps more
aptly an extension of the Neutron API) to satisfy this goal, does this mean
the Neutron API is failing in one of its main goals?

Finally it would be interesting to have a few more details concerning how
topologies created with this new API would be reflected on the existing
data model. While this appears easy for bridges and routers, it is not
immediate for other 'nfds' such as dhcp services.

Salvatore


On 29 October 2013 19:48, Aaron Rosen <arosen at nicira.com> wrote:

> Hi Edgar,
>
> I definitely see the usecase for the idea that you propose. In my opinion,
> I don't see the reason for moving the management of topology into neutron,
>  Heat already provides this functionality (besides for the part of taking
> an existing deployment and generating a template file). Also, I wanted to
> point out that in a way you will have to do orchestration as you're
> topology manager will have to call the neutron api in order to create the
> topology and tear it down.
>
> Best,
>
> Aaron
>
>
> On Tue, Oct 29, 2013 at 11:33 AM, Edgar Magana <emagana at plumgrid.com>wrote:
>
>> 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
>>
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131102/b5731ac9/attachment.html>


More information about the OpenStack-dev mailing list