Open Stack

On Tue, Oct 29, 2013 at 1:06 PM, Edgar Magana <emagana at plumgrid.com> wrote:

> Aaron,
>
> Moving the management of topology?
>

As in you are going to have to call the neutron api from within your api to
create the topology from the template (what heat already does).


> I am not proposing nothing like that, actually could you explain me the
> current workflow to save a network topology created by Neutron APIs, in
> order to use it by a different tenant or the owner itself in a different
> time?
>

Correct there is nothing that does this today (unless you write a script to
do it). That said, I think Zane said it best as the part that should be
implemented should be something that dumps out the existing network
configuration that you could use as a heat template.  Is there any reason
why this approach won't work in your opinion?


Possibly, that is the part that I am missing and it will help me to improve
> current proposal.
>
> Thanks,
>
> Edgar
>
> From: Aaron Rosen <arosen at nicira.com>
> Reply-To: OpenStack List <openstack-dev at lists.openstack.org>
> Date: Tuesday, October 29, 2013 12:48 PM
> To: OpenStack List <openstack-dev at lists.openstack.org>
> Subject: Re: [openstack-dev] [Heat] Network topologies
>
> 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
>
> _______________________________________________
> 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/20131029/36ede858/attachment.html>