On Tue, Oct 29, 2013 at 1:06 PM, Edgar Magana <emag...@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 <aro...@nicira.com> > Reply-To: OpenStack List <openstack-dev@lists.openstack.org> > Date: Tuesday, October 29, 2013 12:48 PM > To: OpenStack List <openstack-dev@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 <emag...@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.schn...@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" <sha...@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@lists.openstack.org >> >>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> > >> > >> >_______________________________________________ >> >OpenStack-dev mailing list >> >OpenStack-dev@lists.openstack.org >> >http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> >> >> _______________________________________________ >> OpenStack-dev mailing list >> OpenStack-dev@lists.openstack.org >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> > > _______________________________________________ OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev