Re: [openstack-dev] [Heat] Network topologies
On Nov 2, 2013, at 3:12 PM, Salvatore Orlando sorla...@nicira.com wrote: Hi. I looked at the detailed API specification submitted by Edgar. I think that the document Edgar shared does a fine job in discussion how an API for managing logical topologies should work. On the other hand, there are two aspects which still need some clarification, and which perhaps are at the source of the confusion regarding whether it belongs to neutron, heat, or anywhere else. First, the use cases section merely re-states the objective session. I think that section should somehow address the questions why do we need this API? How having an API for storing network topologies would be useful for us. The other aspect is that - and I might be terribly wrong here - I think that one of the goals Neutron API was already supposed to abstract the complexity of network topologies - if we need another API (or perhaps more aptly an extension of the Neutron API) to satisfy this goal, does this mean the Neutron API is failing in one of its main goals? Not to hijack this thread, but this is exactly the reason Cisco, IBM, Juniper, Nuage Networks, Plexxi, Red Hat and others are proposing the following BP at the Summit this week [1]. I think as you will read in the BP the abstractions of the Neutron API can be extended such that it removes some of the complexity for API users. We have a session Friday afternoon in the Neutron track to discuss these in fact. Looking forwarding to a lively discussion! Thanks, Kyle [1] https://docs.google.com/document/d/1ZbOFxAoibZbJmDWx1oOrOsDcov6Cuom5aaBIrupCD9E/edit?pli=1 Finally it would be interesting to have a few more details concerning how topologies created with this new API would be reflected on the existing data model. While this appears easy for bridges and routers, it is not immediate for other 'nfds' such as dhcp services. Salvatore On 29 October 2013 19:48, Aaron Rosen aro...@nicira.com wrote: 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
Re: [openstack-dev] [Heat] Network topologies
Excerpts from Kyle Mestery (kmestery)'s message of 2013-11-05 06:35:04 +0800: On Nov 2, 2013, at 3:12 PM, Salvatore Orlando sorla...@nicira.com wrote: Hi. I looked at the detailed API specification submitted by Edgar. I think that the document Edgar shared does a fine job in discussion how an API for managing logical topologies should work. On the other hand, there are two aspects which still need some clarification, and which perhaps are at the source of the confusion regarding whether it belongs to neutron, heat, or anywhere else. First, the use cases section merely re-states the objective session. I think that section should somehow address the questions why do we need this API? How having an API for storing network topologies would be useful for us. The other aspect is that - and I might be terribly wrong here - I think that one of the goals Neutron API was already supposed to abstract the complexity of network topologies - if we need another API (or perhaps more aptly an extension of the Neutron API) to satisfy this goal, does this mean the Neutron API is failing in one of its main goals? Not to hijack this thread, but this is exactly the reason Cisco, IBM, Juniper, Nuage Networks, Plexxi, Red Hat and others are proposing the following BP at the Summit this week [1]. I think as you will read in the BP the abstractions of the Neutron API can be extended such that it removes some of the complexity for API users. We have a session Friday afternoon in the Neutron track to discuss these in fact. Looking forwarding to a lively discussion! Thanks, Kyle [1] https://docs.google.com/document/d/1ZbOFxAoibZbJmDWx1oOrOsDcov6Cuom5aaBIrupCD9E/edit?pli=1 Hi Kyle, can you copy this to etherpad.openstack.org and link it from https://wiki.openstack.org/wiki/Summit/Icehouse/Etherpads Thanks! ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Heat] Network topologies
On Nov 4, 2013, at 7:31 PM, Clint Byrum cl...@fewbar.com wrote: Excerpts from Kyle Mestery (kmestery)'s message of 2013-11-05 06:35:04 +0800: On Nov 2, 2013, at 3:12 PM, Salvatore Orlando sorla...@nicira.com wrote: Hi. I looked at the detailed API specification submitted by Edgar. I think that the document Edgar shared does a fine job in discussion how an API for managing logical topologies should work. On the other hand, there are two aspects which still need some clarification, and which perhaps are at the source of the confusion regarding whether it belongs to neutron, heat, or anywhere else. First, the use cases section merely re-states the objective session. I think that section should somehow address the questions why do we need this API? How having an API for storing network topologies would be useful for us. The other aspect is that - and I might be terribly wrong here - I think that one of the goals Neutron API was already supposed to abstract the complexity of network topologies - if we need another API (or perhaps more aptly an extension of the Neutron API) to satisfy this goal, does this mean the Neutron API is failing in one of its main goals? Not to hijack this thread, but this is exactly the reason Cisco, IBM, Juniper, Nuage Networks, Plexxi, Red Hat and others are proposing the following BP at the Summit this week [1]. I think as you will read in the BP the abstractions of the Neutron API can be extended such that it removes some of the complexity for API users. We have a session Friday afternoon in the Neutron track to discuss these in fact. Looking forwarding to a lively discussion! Thanks, Kyle [1] https://docs.google.com/document/d/1ZbOFxAoibZbJmDWx1oOrOsDcov6Cuom5aaBIrupCD9E/edit?pli=1 Hi Kyle, can you copy this to etherpad.openstack.org and link it from https://wiki.openstack.org/wiki/Summit/Icehouse/Etherpads Hi Clint: I've already posted an etherpad there, it's in fact at this link [1]. I've copied some notes there, it's hard to translate the diagrams but what I've put in there is enough to get the discussion going on Friday. Thanks, Kyle [1] https://etherpad.openstack.org/p/Group_Based_Policy_Abstraction_for_Neutron Thanks! ___ 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
Re: [openstack-dev] [Heat] Network topologies
On 3 November 2013 17:36, Edgar Magana emag...@plumgrid.com wrote: Zen, Kevin, Aaron, Salvatore et al, Thank you so much for taking some time and reviewing this proposal. I couldn't get any time slot neither in Neutron nor Heat track to have a deep discussion about this proposal. My conclusions are the following: I'm sorry if I managed to miss something, but what problem are you trying to solve? I don't mean the technical problem - that seems clear [provide store/restore of network definition], but the user story: what are people doing /trying to do that will become easier/better/possible with this thing implemented? -Rob -- Robert Collins rbtcoll...@hp.com Distinguished Technologist HP Converged Cloud ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Heat] Network topologies
Il giorno 03/nov/2013 17:15, Robert Collins robe...@robertcollins.net ha scritto: On 3 November 2013 17:36, Edgar Magana emag...@plumgrid.com wrote: Zen, Kevin, Aaron, Salvatore et al, Thank you so much for taking some time and reviewing this proposal. I couldn't get any time slot neither in Neutron nor Heat track to have a deep discussion about this proposal. My conclusions are the following: I'm sorry if I managed to miss something, but what problem are you trying to solve? I don't mean the technical problem - that seems clear [provide store/restore of network definition], but the user story: what are people doing /trying to do that will become easier/better/possible with this thing implemented? That was actually one of my questions as well, and an answer to it will probably be very helpful to understand where this API should be placed. -Rob -- Robert Collins rbtcoll...@hp.com Distinguished Technologist HP Converged Cloud ___ 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
Re: [openstack-dev] [Heat] Network topologies
Zen, Kevin, Aaron, Salvatore et al, Thank you so much for taking some time and reviewing this proposal. I couldn't get any time slot neither in Neutron nor Heat track to have a deep discussion about this proposal. My conclusions are the following: - This API should be allocated in Heat project, at least will start there and see how the implementation goes. I am new in Heat, so I will need some help :-) - There are a lot of people who find it interested and useful, therefore It should be implemented. - It should be extended to all new advanced services (VPNaaS, FWaaS, LBaaS) - Dependencies should be included, my point here is to let tenants to do/control that, even if they make mistakes, is there network design after all. - Horizon support will bring a lot of visibility, I will prepare some mock-ups. Open Questions: Is there enough interest in order to schedule an unconference session? (don't want to be the only one in the room) What would happen with the concept of Services Insertion in Neutron? Should it be also move to Heat? Thanks again everybody and I will see you in just one more day. Edgar On Sat, Nov 2, 2013 at 1:12 PM, Salvatore Orlando sorla...@nicira.comwrote: Hi. I looked at the detailed API specification submitted by Edgar. I think that the document Edgar shared does a fine job in discussion how an API for managing logical topologies should work. On the other hand, there are two aspects which still need some clarification, and which perhaps are at the source of the confusion regarding whether it belongs to neutron, heat, or anywhere else. First, the use cases section merely re-states the objective session. I think that section should somehow address the questions why do we need this API? How having an API for storing network topologies would be useful for us. The other aspect is that - and I might be terribly wrong here - I think that one of the goals Neutron API was already supposed to abstract the complexity of network topologies - if we need another API (or perhaps more aptly an extension of the Neutron API) to satisfy this goal, does this mean the Neutron API is failing in one of its main goals? Finally it would be interesting to have a few more details concerning how topologies created with this new API would be reflected on the existing data model. While this appears easy for bridges and routers, it is not immediate for other 'nfds' such as dhcp services. Salvatore On 29 October 2013 19:48, Aaron Rosen aro...@nicira.com wrote: 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.comwrote: 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
Re: [openstack-dev] [Heat] Network topologies
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-insertion-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
Re: [openstack-dev] [Heat] Network topologies
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-insertion -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
Re: [openstack-dev] [Heat] Network topologies
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
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
Re: [openstack-dev] [Heat] Network topologies
Aaron, Moving the management of topology? 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? 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 http://192.168.0.0/24 and 192.168.1.0/24 http://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
Re: [openstack-dev] [Heat] Network topologies
I'm not sure how you could avoid dependencies in any network configuration worth dumping and restoring. One case that I'd like to use the functionality you list is the following: I have an external network, and I create a private network per tenant and attach it via a router to the public network. This is the tenant public network I need to create this network per tenant. Having a tool to save and repeat this activity would be very nice. But even being this simple, the network needs to be created before the router can be created/attached to it. How about extended neutron services? There will probably some day (if not already) be some that need things started in order. LBaaS? Network first then LB? Heat already supports all of this. Thanks, Kevin From: Edgar Magana [emag...@plumgrid.com] Sent: Tuesday, October 29, 2013 11:33 AM To: OpenStack List Subject: Re: [openstack-dev] [Heat] Network topologies 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
Re: [openstack-dev] [Heat] Network topologies [and more]
Zane Bitter zbit...@redhat.com wrote on 10/28/2013 06:47:50 AM: On 27/10/13 16:37, Edgar Magana wrote: Heat Developers, I am one of the core developers for Neutron who is lately working on the concept of Network Topologies. I want to discuss with you if the following blueprint will make sense to have in heat or neutron code: https://blueprints.launchpad.net/neutron/+spec/network-topologies-api ... It sounds to me like the only thing there that Heat is not already doing is to dump the existing network configuration. What if you were to implement just that part and do it in the format of a Heat template? (An independent tool to convert the JSON output to a Heat template would also work, I guess.) ... It does sound very much like you're trying to solve the same problem as Heat. In my templates I have more than a network topology. How would I combine the extracted/shared network topology with the other stuff I want in my heat template? Thanks, Mike___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Heat] Network topologies [and more]
On 28/10/13 15:07, Mike Spreitzer wrote: Zane Bitter zbit...@redhat.com wrote on 10/28/2013 06:47:50 AM: On 27/10/13 16:37, Edgar Magana wrote: Heat Developers, I am one of the core developers for Neutron who is lately working on the concept of Network Topologies. I want to discuss with you if the following blueprint will make sense to have in heat or neutron code: https://blueprints.launchpad.net/neutron/+spec/network-topologies-api ... It sounds to me like the only thing there that Heat is not already doing is to dump the existing network configuration. What if you were to implement just that part and do it in the format of a Heat template? (An independent tool to convert the JSON output to a Heat template would also work, I guess.) ... It does sound very much like you're trying to solve the same problem as Heat. In my templates I have more than a network topology. How would I combine the extracted/shared network topology with the other stuff I want in my heat template? Copy and paste? ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Heat] Network topologies [and more]
On Oct 28, 2013, at 9:07 AM, Mike Spreitzer mspre...@us.ibm.commailto:mspre...@us.ibm.com wrote: Zane Bitter zbit...@redhat.commailto:zbit...@redhat.com wrote on 10/28/2013 06:47:50 AM: On 27/10/13 16:37, Edgar Magana wrote: Heat Developers, I am one of the core developers for Neutron who is lately working on the concept of Network Topologies. I want to discuss with you if the following blueprint will make sense to have in heat or neutron code: https://blueprints.launchpad.net/neutron/+spec/network-topologies-api ... It sounds to me like the only thing there that Heat is not already doing is to dump the existing network configuration. What if you were to implement just that part and do it in the format of a Heat template? (An independent tool to convert the JSON output to a Heat template would also work, I guess.) ... It does sound very much like you're trying to solve the same problem as Heat. In my templates I have more than a network topology. How would I combine the extracted/shared network topology with the other stuff I want in my heat template? Well, if Neutron generated a Heat template describing a particular topology, you could always include that in another template as a provider resource assuming said template is generated with meaningful outputs. IMO, there is some appeal to having Neutron generate a Heat template for this feature. Its something directly consumable by another Openstack service allowing you to not only describe, but save and re-create for later any networking configuration using the same artifact. Thanks, Mike___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.orgmailto: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
Re: [openstack-dev] [Heat] Network topologies
On Sun, Oct 27, 2013 at 08:37:15AM -0700, Edgar Magana wrote: Heat Developers, I am one of the core developers for Neutron who is lately working on the concept of Network Topologies. I want to discuss with you if the following blueprint will make sense to have in heat or neutron code: https://blueprints.launchpad.net/neutron/+spec/network-topologies-api Basically, I want to let tenants “save”, “duplicate” and “share” network topologies by means of an API and a standardized JSON format that describes network topologies. This google document provides detailed description: https://docs.google.com/document/d/1nPkLcUma_nkmuHYxCuUZ8HuryH752gQnkmrZdXeE2LM/edit# There is a concern in Neutron of not duplicating efforts done by Heat team and also to find the right place for this API. The intended work does NOT include any application driven orchestration system, does NOT include any already existing or vender-specific standard format for describing topologies, actually we want to standardized one based on Neutron but it is still on discussion. If Heat developers could provide their point of view about this proposal, wether it should be moved to Heat or it is fine to keep it in Neutron. This seems related to a discussion I had last week re the Neutron services insertion and chaining functionality: https://blueprints.launchpad.net/neutron/+spec/neutron-services-insertion-chaining-steering It does seem that you (Neutron) are moving towards functionality which requires more explicit management of dependencies, state and workflow, such that it may make sense to implement, some of it at least, in Heat. My opinion is that we should expose all of the underlying Neutron capabilities (individual bits of functionality) via Heat resources, which I think we're currently doing quite well (see [1] for the current list of supported functionality) Then any functionality requiring aggregation of resources where dependencies and state are used to create a workflow, should probably happen in Heat, IMHO. It doesn't make sense to me to have two projects building a dependency graph, managing state, and orchestrating workflow for the same underlying Neutron features. We should definitely continue these discussions so we can figure out where the most appropriate integration points may be. Steve [1] http://docs.openstack.org/developer/heat/template_guide/index.html ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Heat] Network topologies [and more]
On Mon, Oct 28, 2013 at 10:07:08AM -0400, Mike Spreitzer wrote: Zane Bitter zbit...@redhat.com wrote on 10/28/2013 06:47:50 AM: On 27/10/13 16:37, Edgar Magana wrote: Heat Developers, I am one of the core developers for Neutron who is lately working on the concept of Network Topologies. I want to discuss with you if the following blueprint will make sense to have in heat or neutron code: https://blueprints.launchpad.net/neutron/+spec/network-topologies-api ... It sounds to me like the only thing there that Heat is not already doing is to dump the existing network configuration. What if you were to implement just that part and do it in the format of a Heat template? (An independent tool to convert the JSON output to a Heat template would also work, I guess.) ... It does sound very much like you're trying to solve the same problem as Heat. In my templates I have more than a network topology. How would I combine the extracted/shared network topology with the other stuff I want in my heat template? The most flexible answer IMO is to define the network topology in a heat template, then consume it via a provider resource, mapped via your environment (either globally or per-user): http://hardysteven.blogspot.co.uk/2013/10/heat-providersenvironments-101-ive.html This would allow you to completely separate the network definition from other stuff, and reuse it as needed, including easily selecting different versions (e.g staging workflow between dev/test etc where the network definition differs but not the application) Steve ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Heat] Network topologies
Excerpts from Steven Hardy's message of 2013-10-28 07:47:06 -0700: On Sun, Oct 27, 2013 at 08:37:15AM -0700, Edgar Magana wrote: Heat Developers, I am one of the core developers for Neutron who is lately working on the concept of Network Topologies. I want to discuss with you if the following blueprint will make sense to have in heat or neutron code: https://blueprints.launchpad.net/neutron/+spec/network-topologies-api Basically, I want to let tenants “save”, “duplicate” and “share” network topologies by means of an API and a standardized JSON format that describes network topologies. This google document provides detailed description: https://docs.google.com/document/d/1nPkLcUma_nkmuHYxCuUZ8HuryH752gQnkmrZdXeE2LM/edit# There is a concern in Neutron of not duplicating efforts done by Heat team and also to find the right place for this API. The intended work does NOT include any application driven orchestration system, does NOT include any already existing or vender-specific standard format for describing topologies, actually we want to standardized one based on Neutron but it is still on discussion. If Heat developers could provide their point of view about this proposal, wether it should be moved to Heat or it is fine to keep it in Neutron. This seems related to a discussion I had last week re the Neutron services insertion and chaining functionality: https://blueprints.launchpad.net/neutron/+spec/neutron-services-insertion-chaining-steering It does seem that you (Neutron) are moving towards functionality which requires more explicit management of dependencies, state and workflow, such that it may make sense to implement, some of it at least, in Heat. My opinion is that we should expose all of the underlying Neutron capabilities (individual bits of functionality) via Heat resources, which I think we're currently doing quite well (see [1] for the current list of supported functionality) Then any functionality requiring aggregation of resources where dependencies and state are used to create a workflow, should probably happen in Heat, IMHO. It doesn't make sense to me to have two projects building a dependency graph, managing state, and orchestrating workflow for the same underlying Neutron features. Could not have said it better myself, thanks Steve. One thing this brings to mind is the proposal for adopt/abandon. This may be a new use case for that feature in Heat. Neutron would be able to adopt all of the standing network topology to do the serialization into a HOT template, and give it to the Neutron user. Then to reverse the process Neutron can accept this Heat template back from the user, and just use it to spin up the topology, but then immediately abandon the stack. We get the workflow and dependency feature without having to leave a dangling stack around for Neutron to clean up. That would make it easier for users to interact with this feature without actually needing to interact with Heat, and would also reduce Neutron's footprint in Heat. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Heat] Network topologies
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. The network topologies BP is not related to the Neutron Network Service Insertion BP: https://blueprints.launchpad.net/neutron/+spec/neutron-services-insertion-c haining-steering 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. 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. Thanks, Edgar On 10/28/13 9:47 AM, Clint Byrum cl...@fewbar.com wrote: Excerpts from Steven Hardy's message of 2013-10-28 07:47:06 -0700: On Sun, Oct 27, 2013 at 08:37:15AM -0700, Edgar Magana wrote: Heat Developers, I am one of the core developers for Neutron who is lately working on the concept of Network Topologies. I want to discuss with you if the following blueprint will make sense to have in heat or neutron code: https://blueprints.launchpad.net/neutron/+spec/network-topologies-api Basically, I want to let tenants ³save², ³duplicate² and ³share² network topologies by means of an API and a standardized JSON format that describes network topologies. This google document provides detailed description: https://docs.google.com/document/d/1nPkLcUma_nkmuHYxCuUZ8HuryH752gQnkmrZd XeE2LM/edit# There is a concern in Neutron of not duplicating efforts done by Heat team and also to find the right place for this API. The intended work does NOT include any application driven orchestration system, does NOT include any already existing or vender-specific standard format for describing topologies, actually we want to standardized one based on Neutron but it is still on discussion. If Heat developers could provide their point of view about this proposal, wether it should be moved to Heat or it is fine to keep it in Neutron. This seems related to a discussion I had last week re the Neutron services insertion and chaining functionality: https://blueprints.launchpad.net/neutron/+spec/neutron-services-insertion -chaining-steering It does seem that you (Neutron) are moving towards functionality which requires more explicit management of dependencies, state and workflow, such that it may make sense to implement, some of it at least, in Heat. My opinion is that we should expose all of the underlying Neutron capabilities (individual bits of functionality) via Heat resources, which I think we're currently doing quite well (see [1] for the current list of supported functionality) Then any functionality requiring aggregation of resources where dependencies and state are used to create a workflow, should probably happen in Heat, IMHO. It doesn't make sense to me to have two projects building a dependency graph, managing state, and orchestrating workflow for the same underlying Neutron features. Could not have said it better myself, thanks Steve. One thing this brings to mind is the proposal for adopt/abandon. This may be a new use case for that feature in Heat. Neutron would be able to adopt all of the standing network topology to do the serialization into a HOT template, and give it to the Neutron user. Then to reverse the process Neutron can accept this Heat template back from the user, and just use it to spin up the topology, but then immediately abandon the stack. We get the workflow and dependency feature without having to leave a dangling stack around for Neutron to clean up. That would make it easier for users to interact with this feature without actually needing to interact with Heat, and would also reduce Neutron's footprint in Heat. ___ 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
