Open Stack

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131029/934bab8e/attachment.html>