<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Oct 29, 2013 at 1:06 PM, Edgar Magana <span dir="ltr"><<a href="mailto:emagana@plumgrid.com" target="_blank">emagana@plumgrid.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="font-size:14px;font-family:Calibri,sans-serif;word-wrap:break-word">
<div>Aaron,</div><div><br></div><div>Moving the management of topology?<span style="font-family:arial;font-size:small"> </span></div></div></blockquote><div><br></div><div>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). </div>
<div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="font-size:14px;font-family:Calibri,sans-serif;word-wrap:break-word">
<div>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?</div>
</div></blockquote><div><br></div><div>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? </div>
<div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="font-size:14px;font-family:Calibri,sans-serif;word-wrap:break-word">
<div>Possibly, that is the part that I am missing and it will help me to improve current proposal.</div><div><br></div><div>Thanks,</div><div><br></div><div>Edgar</div><div><br></div><span><div style="border-width:1pt medium medium;border-style:solid none none;padding:3pt 0in 0in;text-align:left;font-size:11pt;font-family:Calibri;border-top-color:rgb(181,196,223)">
<span style="font-weight:bold">From: </span> Aaron Rosen <<a href="mailto:arosen@nicira.com" target="_blank">arosen@nicira.com</a>><br><span style="font-weight:bold">Reply-To: </span> OpenStack List <<a href="mailto:openstack-dev@lists.openstack.org" target="_blank">openstack-dev@lists.openstack.org</a>><br>
<span style="font-weight:bold">Date: </span> Tuesday, October 29, 2013 12:48 PM<br><span style="font-weight:bold">To: </span> OpenStack List <<a href="mailto:openstack-dev@lists.openstack.org" target="_blank">openstack-dev@lists.openstack.org</a>><br>
<span style="font-weight:bold">Subject: </span> Re: [openstack-dev] [Heat] Network topologies<br></div><div><div class="h5"><div><br></div><div dir="ltr">Hi Edgar, <div><br></div><div>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. </div>
<div><br></div><div>Best, </div><div><br></div><div>Aaron</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Oct 29, 2013 at 11:33 AM, Edgar Magana <span dir="ltr"><<a href="mailto:emagana@plumgrid.com" target="_blank">emagana@plumgrid.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Tim,<br><br>
You statement "building an api that manages a network topology more than<br><div>one that needs to build out the dependencies between resources to help<br>
create the network topology"<br></div>Is exactly what we are proposing, and this is why we believe this is not<br>
under Heat domain.<br><br>
This is why we are NOT proposing to manage any dependency between network<br>
elements, that part is what I call "intelligence" of the orchestration and<br>
we are not proposing any orchestration system, you are already have that<br>
in place :-)<br><br>
So, we simple want an API that tenats may use to "save", "retrieve" and<br>
"share" topologies. For instance, tenant A creates a topology with two<br>
networks (<a href="http://192.168.0.0/24" target="_blank">192.168.0.0/24</a> and <a href="http://192.168.1.0/24" target="_blank">192.168.1.0/24</a>) both with dhcp enabled and a<br>
router connecting them. So, we first create it using CLI commands or<br>
Horizon and then we call the API to save the topology for that tenant,<br>
that topology can be also share  between tenants if the owner wanted to do<br>
that, the same concept that we have in Neutron for "share networks", So<br>
Tenant B or any other Tenants, don't need to re-create the whole topology,<br>
just "open" the shared topology from tenant A. Obviously, overlapping IPs<br>
will be a "must" requirement.<br><br>
I am including in this thread to Mark McClain who is the Neutron PTL and<br>
the main guy expressing concerns in not  having overlapping<br>
functionalities between Neutron and Heat or any other project.<br><br>
I am absolutely, happy to discuss further with you but if you are ok with<br>
this approach we could start the development in Neutron umbrella, final<br>
thoughts?<br><br>
Thanks,<br><br>
Edgar<br><div><div><br>
On 10/29/13 8:23 AM, "Tim Schnell" <<a href="mailto:tim.schnell@RACKSPACE.COM" target="_blank">tim.schnell@RACKSPACE.COM</a>> wrote:<br><br>
>Hi Edgar,<br>
><br>
>It seems like this blueprint is related more to building an api that<br>
>manages a network topology more than one that needs to build out the<br>
>dependencies between resources to help create the network topology. If we<br>
>are talking about just an api to "save", "duplicate", and "share" these<br>
>network topologies then I would agree that this is not something that Heat<br>
>currently does or should do necessarily.<br>
><br>
>I have been focusing primarily on front-end work for Heat so I apologize<br>
>if these questions have already been answered. How is this API related to<br>
>the existing network topology in Horizon? The existing network topology<br>
>can already define the relationships and dependencies using Neutron I'm<br>
>assuming so there is no apparent need to use Heat to gather this<br>
>information. I'm a little confused as to the scope of the discussion, is<br>
>that something that you are potentially interested in changing?<br>
><br>
>Steve, Clint and Zane can better answer whether or not Heat wants to be in<br>
>the business of managing existing network topologies but from my<br>
>perspective I tend to agree with your statement that if you needed Heat to<br>
>help describe the relationships between network resources then that might<br>
>be duplicated effort but if don't need Heat to do that then this blueprint<br>
>belongs in Neutron.<br>
><br>
>Thanks,<br>
>Tim<br>
><br>
><br>
><br>
><br>
><br>
>On 10/29/13 1:32 AM, "Steven Hardy" <<a href="mailto:shardy@redhat.com" target="_blank">shardy@redhat.com</a>> wrote:<br>
><br>
>>On Mon, Oct 28, 2013 at 01:19:13PM -0700, Edgar Magana wrote:<br>
>>> Hello Folks,<br>
>>><br>
>>> Thank you Zane, Steven and Clint for you input.<br>
>>><br>
>>> Our main goal in this BP is to provide networking users such as Heat<br>
>>>(we<br>
>>> consider it as a neutron user) a better and consolidated network<br>
>>>building<br>
>>> block in terms of an API that you could use for orchestration of<br>
>>> application-driven requirements. This building block does not add any<br>
>>> "intelligence" to the network topology because it does not have it and<br>
>>> this is why I think this BP is different from the work that you are<br>
>>>doing<br>
>>> in Heat.<br>
>><br>
>>So how do you propose to handle dependencies between elements in the<br>
>>topology, e.g where things need to be created/deleted in a particular<br>
>>order, or where one resource must be in a particular state before another<br>
>>can be created?<br>
>><br>
>>> The network topologies BP is not related to the Neutron Network Service<br>
>>> Insertion BP:<br>
>>><br>
>>><a href="https://blueprints.launchpad.net/neutron/+spec/neutron-services-insertio" target="_blank">https://blueprints.launchpad.net/neutron/+spec/neutron-services-insertio</a><br>
>>>n<br>
>>>-c<br>
>>> haining-steering<br>
>><br>
>>So I wasn't saying they were related, only that they both, arguably, may<br>
>>have some scope overlap with what Heat is doing.<br>
>><br>
>>> I do agree with Steven that the insertion work add "intelligence"<br>
>>> (explicit management of dependencies, state and workflow) to the<br>
>>>network<br>
>>> orchestration simply because user will need to know the insertion<br>
>>> mechanism and dependencies between Network Advances Services, that work<br>
>>>is<br>
>>> more into Heat space that the BP that I am proposing but that is just<br>
>>>my<br>
>>> opinion.<br>
>><br>
>>This seems a good reason to leverage the work we're doing rather than<br>
>>reinventing it.  I'm not arguing that Heat should necessarily be the<br>
>>primary interface to such functionality, only that Heat could (and<br>
>>possibly<br>
>>should) be used to do the orchestration aspects.<br>
>><br>
>>> However, is there a session where I can discuss this BP with you guys?,<br>
>>> the session that I proposed in Neutron has been rejected because it was<br>
>>> considered by the PTL as an overlapping work with the Heat goals,<br>
>>> therefore I wanted to know if you can to discuss it or I just simple go<br>
>>> ahead and start the implementation. I do still believe it can be easily<br>
>>> implemented in Neutron and then exposed to Heat but I am really looking<br>
>>> forward to having a broader discussion.<br>
>><br>
>>I don't think we have any sessions directly related to Neutron, but we<br>
>>are<br>
>>definitely interested in discussing this (and other Neutron BPs which may<br>
>>have integration points requiring orchestration).<br>
>><br>
>>I suggest we have an informal breakout session with those interested on<br>
>>Tuesday or Wednesday, or it could be a topic which Steve Baker may<br>
>>consider<br>
>>for this placeholder session:<br>
>><br>
>><a href="http://summit.openstack.org/cfp/details/360" target="_blank">http://summit.openstack.org/cfp/details/360</a><br>
>><br>
>>Steve<br>
>><br>
>>_______________________________________________<br>
>>OpenStack-dev mailing list<br>
>><a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br>
>><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
><br>
><br>
>_______________________________________________<br>
>OpenStack-dev mailing list<br>
><a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br>
><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br><br><br><br>
_______________________________________________<br>
OpenStack-dev mailing list<br><a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br></div>
_______________________________________________
OpenStack-dev mailing list
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a>
</div></div></span></div>
<br>_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br></div></div>