<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:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Tim,<br>
<br>
You statement "building an api that manages a network topology more than<br>
<div class="im">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 class="HOEnZb"><div class="h5"><br>
On 10/29/13 8:23 AM, "Tim Schnell" <<a href="mailto:tim.schnell@RACKSPACE.COM">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">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">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">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">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>