RE: Third party VR / L2 support
Your views are correct in managing the 3rd party VRs I see people try to use external devices to provide network services if they see VR cannot handle the performance or stability or if the admin thinks third party providers can do well w.r.t their environment. In current cloudstack, CloudStack VR is the only option to be on Data Path and majority of network services can be delegated to third party. Am looking at how NetScaler can be leveraged to be a VR in CloudStack. Thanks Rajesh Battala -Original Message- From: Koushik Das [mailto:koushik@citrix.com] Sent: Friday, June 12, 2015 10:27 AM To: dev@cloudstack.apache.org Subject: RE: Third party VR / L2 support Agree to what Funs mentioned. The current network service model is flexible, there is option to select a provider for a given service by means of network offering. About using 3rd party VR, there are 2 possibilities: - Fully replace the existing VR with 3rd party VR - Both co-exist and complement each other CS manages the lifecycle of VR. For 3rd party (especially virtual appliances), it needs to be decided what is the best way to manage lifecycle. If CS is able to manage the lifecycle then it can be similar to existing VR (spinning up instances when required). If managed externally, then a pre-created pool of appliances needs to be registered from CS and used. -Koushik -Original Message- From: Funs Kessen [mailto:fozzielumpk...@gmail.com] On Behalf Of Funs Kessen Sent: Tuesday, June 09, 2015 3:26 PM To: dev@cloudstack.apache.org Subject: Re: Third party VR / L2 support Hi Christian and Paul, I agree that the VR/VPC construct could do with some improvements, the biggest being that it should actually be api driven and allow for more flexible networking/services combined with scale out itself (we’re looking into this actually). All of these things bring along their own problems and should be tackled piece by piece, if we’d want to be efficient we should first blot out the API and then start pushing services in, which is difficult at the speed it is moving at. The driver model in Cloudstack already supports the decoupling of services via network service providers (plugins) and ties in with the way the “network service offerings work with service capabilities and supported services. At SBP we use NSX-mh for the service “Connectivity”, we could add “SourceNat”, “StaticNat” and “Port Forwarding” to this for NSX if we want to, but decided to leave that in the VR back then as these services were rather new in NSX. My point being that you can already mix and match things and are not stuck with the VR/VPC, and you can actually use devices on that level if need be, if you create the service offerings for them. At the moment anyone can already create a plugin that exposes a single functionality or multiple, and expose that as a service that is offered, examples of these are the Palo-Alto, SRX, F5, Netscaler, Cisco VNMC, NSX and Nuage. I’m not saying it’s simple or easy, but if you know the API of what you want to integrate with you can. The construction of the plugin module has its own unique challenges, and I agree with John Burwell (Shape Blue) and Paul that we need to change the way this all hangs together if we want more flexibility and ease of integration in the future. BGP is brought in for use with IPv6, the first code for that has just gone in from Suresh via Wilder. As that runs on top of Quagga you could do OSPF with that too. This again leads me to believe we really need to change the way the RV/VPC receives configuration, I’ve spoken to a big Cloudstack user, whom also contributes, that wants to be able to do more with HaProxy, read full configuration freedom, and after hearing this and bumping my head against it in the past it made perfect sense to me. On the topic of L2 networking we’re bridging in and out a lot of networks at the moment for “Enterprise” production customers. Ranging from legacy environments to cloud environments or environments where we have full cloud workloads but also need physical iron due to “regulatory requirements” or because there is no viable alternative yet (or we haven’t made a plugin that exposes that functionality from another device/VM/container that can be placed in a service offering etc). I think in our case L2 is not always a requirement for all areas as such and I’d prefer L3 in most cases where viable. We solved things that way, the L2 way, because that was our frame of mind, although it may be a requirement in your case. Cheers, Funs On 09 Jun 2015, at 10:27, Paul Angus paul.an...@shapeblue.com wrote: Hi Christian, This is a feature put forward by myself. As a non-developer I can come up with these things and throw them over the wall to the developers and pretend I don't know how complicated it is :) In summary, it requires a few other pieces of the roadmap to be in place. The high level plan is to move ever
RE: Third party VR / L2 support
Hi Koushik (and Funs), It isn't sustainable to keep adding plugins to the core code for 3rd party devices which the community then has to support and maintain and (more importantly) can't test as the vast majority of 'testers' won't have access to the hardware. A well implemented driver model allows 3rd parties to create drivers for their device (which can be certified). I'm also talking about being able to drop in VPN appliances, load balancers as well as virtual routing appliances. This is a long term goal and needs a load of other pieces of the puzzle as well. We're working on making the automated testing portable which is a step towards being able to ship a certification DDK. Regards, Paul Angus Cloud Architect D: +44 20 3468 5163 |S: +44 20 3603 0540 | M: +44 7711 418 784 | T: @CloudyAngus paul.an...@shapeblue.com -Original Message- From: Koushik Das [mailto:koushik@citrix.com] Sent: 12 June 2015 05:57 To: dev@cloudstack.apache.org Subject: RE: Third party VR / L2 support Agree to what Funs mentioned. The current network service model is flexible, there is option to select a provider for a given service by means of network offering. About using 3rd party VR, there are 2 possibilities: - Fully replace the existing VR with 3rd party VR - Both co-exist and complement each other CS manages the lifecycle of VR. For 3rd party (especially virtual appliances), it needs to be decided what is the best way to manage lifecycle. If CS is able to manage the lifecycle then it can be similar to existing VR (spinning up instances when required). If managed externally, then a pre-created pool of appliances needs to be registered from CS and used. -Koushik -Original Message- From: Funs Kessen [mailto:fozzielumpk...@gmail.com] On Behalf Of Funs Kessen Sent: Tuesday, June 09, 2015 3:26 PM To: dev@cloudstack.apache.org Subject: Re: Third party VR / L2 support Hi Christian and Paul, I agree that the VR/VPC construct could do with some improvements, the biggest being that it should actually be api driven and allow for more flexible networking/services combined with scale out itself (we’re looking into this actually). All of these things bring along their own problems and should be tackled piece by piece, if we’d want to be efficient we should first blot out the API and then start pushing services in, which is difficult at the speed it is moving at. The driver model in Cloudstack already supports the decoupling of services via network service providers (plugins) and ties in with the way the “network service offerings work with service capabilities and supported services. At SBP we use NSX-mh for the service “Connectivity”, we could add “SourceNat”, “StaticNat” and “Port Forwarding” to this for NSX if we want to, but decided to leave that in the VR back then as these services were rather new in NSX. My point being that you can already mix and match things and are not stuck with the VR/VPC, and you can actually use devices on that level if need be, if you create the service offerings for them. At the moment anyone can already create a plugin that exposes a single functionality or multiple, and expose that as a service that is offered, examples of these are the Palo-Alto, SRX, F5, Netscaler, Cisco VNMC, NSX and Nuage. I’m not saying it’s simple or easy, but if you know the API of what you want to integrate with you can. The construction of the plugin module has its own unique challenges, and I agree with John Burwell (Shape Blue) and Paul that we need to change the way this all hangs together if we want more flexibility and ease of integration in the future. BGP is brought in for use with IPv6, the first code for that has just gone in from Suresh via Wilder. As that runs on top of Quagga you could do OSPF with that too. This again leads me to believe we really need to change the way the RV/VPC receives configuration, I’ve spoken to a big Cloudstack user, whom also contributes, that wants to be able to do more with HaProxy, read full configuration freedom, and after hearing this and bumping my head against it in the past it made perfect sense to me. On the topic of L2 networking we’re bridging in and out a lot of networks at the moment for “Enterprise” production customers. Ranging from legacy environments to cloud environments or environments where we have full cloud workloads but also need physical iron due to “regulatory requirements” or because there is no viable alternative yet (or we haven’t made a plugin that exposes that functionality from another device/VM/container that can be placed in a service offering etc). I think in our case L2 is not always a requirement for all areas as such and I’d prefer L3 in most cases where viable. We solved things that way, the L2 way, because that was our frame of mind, although it may be a requirement in your case. Cheers, Funs On 09 Jun 2015, at 10:27, Paul Angus paul.an...@shapeblue.com wrote
Re: Third party VR / L2 support
Thank you all for your views and comments. I agree with everything said when it is positioned under today’s business-as-usual cloud compute. Perhaps I should put some context around my thoughts. NFV is coming and the world is looking to deliver solid cloud networking solutions over the next couple of years. 90% of what I am hearing in this area revolves around OpenStack. I’m trying to put the case forward for using CloudStack. Yes, I can use sheer force of will to bend CloudStack into shape. I can ignore its insistence on using IP addresses for everything and tap straight into VLANs. I can also use kludges to suppress the virtual router and remove unwelcome DHCP services. However, I have to declare that I am doing these things when I present the case for CloudStack and this weakens my argument. There are some quick wins here that would help greatly in positioning CloudStack as a contender for running virtualised network appliances. Having a checkbox that flags a virtual network as Layer 2 (no IP addresses) would be one of them. Officially supporting a ‘No virtual router’ option within a Network Offering would be another. I appreciate that offering third-party virtual routers as an alternative is not so straightforward, although this seems to be gaining more support than the ‘quick wins’. Maybe I am underestimating the development effort involved with the L2 asks? Cheers -Christian On 12/06/2015 05:57, Koushik Das koushik@citrix.com wrote: Agree to what Funs mentioned. The current network service model is flexible, there is option to select a provider for a given service by means of network offering. About using 3rd party VR, there are 2 possibilities: - Fully replace the existing VR with 3rd party VR - Both co-exist and complement each other CS manages the lifecycle of VR. For 3rd party (especially virtual appliances), it needs to be decided what is the best way to manage lifecycle. If CS is able to manage the lifecycle then it can be similar to existing VR (spinning up instances when required). If managed externally, then a pre-created pool of appliances needs to be registered from CS and used. -Koushik -Original Message- From: Funs Kessen [mailto:fozzielumpk...@gmail.com] On Behalf Of Funs Kessen Sent: Tuesday, June 09, 2015 3:26 PM To: dev@cloudstack.apache.org Subject: Re: Third party VR / L2 support Hi Christian and Paul, I agree that the VR/VPC construct could do with some improvements, the biggest being that it should actually be api driven and allow for more flexible networking/services combined with scale out itself (we’re looking into this actually). All of these things bring along their own problems and should be tackled piece by piece, if we’d want to be efficient we should first blot out the API and then start pushing services in, which is difficult at the speed it is moving at. The driver model in Cloudstack already supports the decoupling of services via network service providers (plugins) and ties in with the way the “network service offerings work with service capabilities and supported services. At SBP we use NSX-mh for the service “Connectivity”, we could add “SourceNat”, “StaticNat” and “Port Forwarding” to this for NSX if we want to, but decided to leave that in the VR back then as these services were rather new in NSX. My point being that you can already mix and match things and are not stuck with the VR/VPC, and you can actually use devices on that level if need be, if you create the service offerings for them. At the moment anyone can already create a plugin that exposes a single functionality or multiple, and expose that as a service that is offered, examples of these are the Palo-Alto, SRX, F5, Netscaler, Cisco VNMC, NSX and Nuage. I’m not saying it’s simple or easy, but if you know the API of what you want to integrate with you can. The construction of the plugin module has its own unique challenges, and I agree with John Burwell (Shape Blue) and Paul that we need to change the way this all hangs together if we want more flexibility and ease of integration in the future. BGP is brought in for use with IPv6, the first code for that has just gone in from Suresh via Wilder. As that runs on top of Quagga you could do OSPF with that too. This again leads me to believe we really need to change the way the RV/VPC receives configuration, I’ve spoken to a big Cloudstack user, whom also contributes, that wants to be able to do more with HaProxy, read full configuration freedom, and after hearing this and bumping my head against it in the past it made perfect sense to me. On the topic of L2 networking we’re bridging in and out a lot of networks at the moment for “Enterprise” production customers. Ranging from legacy environments to cloud environments or environments where we have full cloud workloads but also need physical iron due to “regulatory requirements” or because there is no viable alternative yet (or we haven’t made a plugin that exposes
Re: Third party VR / L2 support
Hi Paul, We don’t disagree at all, and I think Koushik doesn’t either, we’re just talking about different things. Today there are limited options but there are ways to work with these options without having to rewrite the plugin model. Yes we agree that the plugin model needs to be rewritten, as was discussed in London, with emphasis on plugin model and loose coupling. Cheers, Funs On 12 Jun 2015, at 08:06, Paul Angus paul.an...@shapeblue.com wrote: Hi Koushik (and Funs), It isn't sustainable to keep adding plugins to the core code for 3rd party devices which the community then has to support and maintain and (more importantly) can't test as the vast majority of 'testers' won't have access to the hardware. A well implemented driver model allows 3rd parties to create drivers for their device (which can be certified). I'm also talking about being able to drop in VPN appliances, load balancers as well as virtual routing appliances. This is a long term goal and needs a load of other pieces of the puzzle as well. We're working on making the automated testing portable which is a step towards being able to ship a certification DDK. Regards, Paul Angus Cloud Architect D: +44 20 3468 5163 |S: +44 20 3603 0540 | M: +44 7711 418 784 | T: @CloudyAngus paul.an...@shapeblue.com -Original Message- From: Koushik Das [mailto:koushik@citrix.com] Sent: 12 June 2015 05:57 To: dev@cloudstack.apache.org Subject: RE: Third party VR / L2 support Agree to what Funs mentioned. The current network service model is flexible, there is option to select a provider for a given service by means of network offering. About using 3rd party VR, there are 2 possibilities: - Fully replace the existing VR with 3rd party VR - Both co-exist and complement each other CS manages the lifecycle of VR. For 3rd party (especially virtual appliances), it needs to be decided what is the best way to manage lifecycle. If CS is able to manage the lifecycle then it can be similar to existing VR (spinning up instances when required). If managed externally, then a pre-created pool of appliances needs to be registered from CS and used. -Koushik -Original Message- From: Funs Kessen [mailto:fozzielumpk...@gmail.com] On Behalf Of Funs Kessen Sent: Tuesday, June 09, 2015 3:26 PM To: dev@cloudstack.apache.org Subject: Re: Third party VR / L2 support Hi Christian and Paul, I agree that the VR/VPC construct could do with some improvements, the biggest being that it should actually be api driven and allow for more flexible networking/services combined with scale out itself (we’re looking into this actually). All of these things bring along their own problems and should be tackled piece by piece, if we’d want to be efficient we should first blot out the API and then start pushing services in, which is difficult at the speed it is moving at. The driver model in Cloudstack already supports the decoupling of services via network service providers (plugins) and ties in with the way the “network service offerings work with service capabilities and supported services. At SBP we use NSX-mh for the service “Connectivity”, we could add “SourceNat”, “StaticNat” and “Port Forwarding” to this for NSX if we want to, but decided to leave that in the VR back then as these services were rather new in NSX. My point being that you can already mix and match things and are not stuck with the VR/VPC, and you can actually use devices on that level if need be, if you create the service offerings for them. At the moment anyone can already create a plugin that exposes a single functionality or multiple, and expose that as a service that is offered, examples of these are the Palo-Alto, SRX, F5, Netscaler, Cisco VNMC, NSX and Nuage. I’m not saying it’s simple or easy, but if you know the API of what you want to integrate with you can. The construction of the plugin module has its own unique challenges, and I agree with John Burwell (Shape Blue) and Paul that we need to change the way this all hangs together if we want more flexibility and ease of integration in the future. BGP is brought in for use with IPv6, the first code for that has just gone in from Suresh via Wilder. As that runs on top of Quagga you could do OSPF with that too. This again leads me to believe we really need to change the way the RV/VPC receives configuration, I’ve spoken to a big Cloudstack user, whom also contributes, that wants to be able to do more with HaProxy, read full configuration freedom, and after hearing this and bumping my head against it in the past it made perfect sense to me. On the topic of L2 networking we’re bridging in and out a lot of networks at the moment for “Enterprise” production customers. Ranging from legacy environments to cloud environments or environments where we have full cloud workloads but also need physical
Re: Third party VR / L2 support
On Jun 12, 2015, at 11:13 AM, Christian christ...@bt.net wrote: Thank you all for your views and comments. I agree with everything said when it is positioned under today’s business-as-usual cloud compute. Perhaps I should put some context around my thoughts. NFV is coming and the world is looking to deliver solid cloud networking solutions over the next couple of years. 90% of what I am hearing in this area revolves around OpenStack. I’m trying to put the case forward for using CloudStack. Yes, I can use sheer force of will to bend CloudStack into shape. I can ignore its insistence on using IP addresses for everything and tap straight into VLANs. I can also use kludges to suppress the virtual router and remove unwelcome DHCP services. However, I have to declare that I am doing these things when I present the case for CloudStack and this weakens my argument. There are some quick wins here that would help greatly in positioning CloudStack as a contender for running virtualised network appliances. Having a checkbox that flags a virtual network as Layer 2 (no IP addresses) would be one of them. Officially supporting a ‘No virtual router’ option within a Network Offering would be another. Christian, I totally agree with you. I was on the OPNFV mailing list couple months back and openstack was the only game in town. So how do we get those quick wins going ? Do you have code to make it happen and are looking for guidance to put them in the source ? If you have to code for it, I can show you how to contribute it. Or are you looking for other devs to do it ? A starting point might be to describe those quick wins in a bit more details on the wiki as a Feature request: https://cwiki.apache.org/confluence/display/CLOUDSTACK/Home If you create an account I can give you the writes to create a page. Let's keep this conversation going. thanks, -sebastien I appreciate that offering third-party virtual routers as an alternative is not so straightforward, although this seems to be gaining more support than the ‘quick wins’. Maybe I am underestimating the development effort involved with the L2 asks? Cheers -Christian On 12/06/2015 05:57, Koushik Das koushik@citrix.com wrote: Agree to what Funs mentioned. The current network service model is flexible, there is option to select a provider for a given service by means of network offering. About using 3rd party VR, there are 2 possibilities: - Fully replace the existing VR with 3rd party VR - Both co-exist and complement each other CS manages the lifecycle of VR. For 3rd party (especially virtual appliances), it needs to be decided what is the best way to manage lifecycle. If CS is able to manage the lifecycle then it can be similar to existing VR (spinning up instances when required). If managed externally, then a pre-created pool of appliances needs to be registered from CS and used. -Koushik -Original Message- From: Funs Kessen [mailto:fozzielumpk...@gmail.com] On Behalf Of Funs Kessen Sent: Tuesday, June 09, 2015 3:26 PM To: dev@cloudstack.apache.org Subject: Re: Third party VR / L2 support Hi Christian and Paul, I agree that the VR/VPC construct could do with some improvements, the biggest being that it should actually be api driven and allow for more flexible networking/services combined with scale out itself (we’re looking into this actually). All of these things bring along their own problems and should be tackled piece by piece, if we’d want to be efficient we should first blot out the API and then start pushing services in, which is difficult at the speed it is moving at. The driver model in Cloudstack already supports the decoupling of services via network service providers (plugins) and ties in with the way the “network service offerings work with service capabilities and supported services. At SBP we use NSX-mh for the service “Connectivity”, we could add “SourceNat”, “StaticNat” and “Port Forwarding” to this for NSX if we want to, but decided to leave that in the VR back then as these services were rather new in NSX. My point being that you can already mix and match things and are not stuck with the VR/VPC, and you can actually use devices on that level if need be, if you create the service offerings for them. At the moment anyone can already create a plugin that exposes a single functionality or multiple, and expose that as a service that is offered, examples of these are the Palo-Alto, SRX, F5, Netscaler, Cisco VNMC, NSX and Nuage. I’m not saying it’s simple or easy, but if you know the API of what you want to integrate with you can. The construction of the plugin module has its own unique challenges, and I agree with John Burwell (Shape Blue) and Paul that we need to change the way this all hangs together if we want more flexibility and ease of integration in the future. BGP is brought in for use with IPv6, the first code for that has
RE: Third party VR / L2 support
Hey Fozzielumpkins (love it), Yes, Iets agree to agree! Regards, Paul Angus Cloud Architect S: +44 20 3603 0540 | M: +447711418784 | T: CloudyAngus paul.an...@shapeblue.com -Original Message- From: Funs Kessen [mailto:fozzielumpk...@gmail.com] On Behalf Of Funs Kessen Sent: Friday, June 12, 2015 1:06 PM To: dev@cloudstack.apache.org Subject: Re: Third party VR / L2 support Hi Paul, We don’t disagree at all, and I think Koushik doesn’t either, we’re just talking about different things. Today there are limited options but there are ways to work with these options without having to rewrite the plugin model. Yes we agree that the plugin model needs to be rewritten, as was discussed in London, with emphasis on plugin model and loose coupling. Cheers, Funs On 12 Jun 2015, at 08:06, Paul Angus paul.an...@shapeblue.com wrote: Hi Koushik (and Funs), It isn't sustainable to keep adding plugins to the core code for 3rd party devices which the community then has to support and maintain and (more importantly) can't test as the vast majority of 'testers' won't have access to the hardware. A well implemented driver model allows 3rd parties to create drivers for their device (which can be certified). I'm also talking about being able to drop in VPN appliances, load balancers as well as virtual routing appliances. This is a long term goal and needs a load of other pieces of the puzzle as well. We're working on making the automated testing portable which is a step towards being able to ship a certification DDK. Regards, Paul Angus Cloud Architect D: +44 20 3468 5163 |S: +44 20 3603 0540 | M: +44 7711 418 784 | T: @CloudyAngus paul.an...@shapeblue.com -Original Message- From: Koushik Das [mailto:koushik@citrix.com] Sent: 12 June 2015 05:57 To: dev@cloudstack.apache.org Subject: RE: Third party VR / L2 support Agree to what Funs mentioned. The current network service model is flexible, there is option to select a provider for a given service by means of network offering. About using 3rd party VR, there are 2 possibilities: - Fully replace the existing VR with 3rd party VR - Both co-exist and complement each other CS manages the lifecycle of VR. For 3rd party (especially virtual appliances), it needs to be decided what is the best way to manage lifecycle. If CS is able to manage the lifecycle then it can be similar to existing VR (spinning up instances when required). If managed externally, then a pre-created pool of appliances needs to be registered from CS and used. -Koushik -Original Message- From: Funs Kessen [mailto:fozzielumpk...@gmail.com] On Behalf Of Funs Kessen Sent: Tuesday, June 09, 2015 3:26 PM To: dev@cloudstack.apache.org Subject: Re: Third party VR / L2 support Hi Christian and Paul, I agree that the VR/VPC construct could do with some improvements, the biggest being that it should actually be api driven and allow for more flexible networking/services combined with scale out itself (we’re looking into this actually). All of these things bring along their own problems and should be tackled piece by piece, if we’d want to be efficient we should first blot out the API and then start pushing services in, which is difficult at the speed it is moving at. The driver model in Cloudstack already supports the decoupling of services via network service providers (plugins) and ties in with the way the “network service offerings work with service capabilities and supported services. At SBP we use NSX-mh for the service “Connectivity”, we could add “SourceNat”, “StaticNat” and “Port Forwarding” to this for NSX if we want to, but decided to leave that in the VR back then as these services were rather new in NSX. My point being that you can already mix and match things and are not stuck with the VR/VPC, and you can actually use devices on that level if need be, if you create the service offerings for them. At the moment anyone can already create a plugin that exposes a single functionality or multiple, and expose that as a service that is offered, examples of these are the Palo-Alto, SRX, F5, Netscaler, Cisco VNMC, NSX and Nuage. I’m not saying it’s simple or easy, but if you know the API of what you want to integrate with you can. The construction of the plugin module has its own unique challenges, and I agree with John Burwell (Shape Blue) and Paul that we need to change the way this all hangs together if we want more flexibility and ease of integration in the future. BGP is brought in for use with IPv6, the first code for that has just gone in from Suresh via Wilder. As that runs on top of Quagga you could do OSPF with that too. This again leads me to believe we really need to change the way the RV/VPC receives configuration, I’ve spoken to a big Cloudstack user, whom also contributes, that wants to be able to do more with HaProxy, read full configuration
RE: Third party VR / L2 support
Agree to what Funs mentioned. The current network service model is flexible, there is option to select a provider for a given service by means of network offering. About using 3rd party VR, there are 2 possibilities: - Fully replace the existing VR with 3rd party VR - Both co-exist and complement each other CS manages the lifecycle of VR. For 3rd party (especially virtual appliances), it needs to be decided what is the best way to manage lifecycle. If CS is able to manage the lifecycle then it can be similar to existing VR (spinning up instances when required). If managed externally, then a pre-created pool of appliances needs to be registered from CS and used. -Koushik -Original Message- From: Funs Kessen [mailto:fozzielumpk...@gmail.com] On Behalf Of Funs Kessen Sent: Tuesday, June 09, 2015 3:26 PM To: dev@cloudstack.apache.org Subject: Re: Third party VR / L2 support Hi Christian and Paul, I agree that the VR/VPC construct could do with some improvements, the biggest being that it should actually be api driven and allow for more flexible networking/services combined with scale out itself (we’re looking into this actually). All of these things bring along their own problems and should be tackled piece by piece, if we’d want to be efficient we should first blot out the API and then start pushing services in, which is difficult at the speed it is moving at. The driver model in Cloudstack already supports the decoupling of services via network service providers (plugins) and ties in with the way the “network service offerings work with service capabilities and supported services. At SBP we use NSX-mh for the service “Connectivity”, we could add “SourceNat”, “StaticNat” and “Port Forwarding” to this for NSX if we want to, but decided to leave that in the VR back then as these services were rather new in NSX. My point being that you can already mix and match things and are not stuck with the VR/VPC, and you can actually use devices on that level if need be, if you create the service offerings for them. At the moment anyone can already create a plugin that exposes a single functionality or multiple, and expose that as a service that is offered, examples of these are the Palo-Alto, SRX, F5, Netscaler, Cisco VNMC, NSX and Nuage. I’m not saying it’s simple or easy, but if you know the API of what you want to integrate with you can. The construction of the plugin module has its own unique challenges, and I agree with John Burwell (Shape Blue) and Paul that we need to change the way this all hangs together if we want more flexibility and ease of integration in the future. BGP is brought in for use with IPv6, the first code for that has just gone in from Suresh via Wilder. As that runs on top of Quagga you could do OSPF with that too. This again leads me to believe we really need to change the way the RV/VPC receives configuration, I’ve spoken to a big Cloudstack user, whom also contributes, that wants to be able to do more with HaProxy, read full configuration freedom, and after hearing this and bumping my head against it in the past it made perfect sense to me. On the topic of L2 networking we’re bridging in and out a lot of networks at the moment for “Enterprise” production customers. Ranging from legacy environments to cloud environments or environments where we have full cloud workloads but also need physical iron due to “regulatory requirements” or because there is no viable alternative yet (or we haven’t made a plugin that exposes that functionality from another device/VM/container that can be placed in a service offering etc). I think in our case L2 is not always a requirement for all areas as such and I’d prefer L3 in most cases where viable. We solved things that way, the L2 way, because that was our frame of mind, although it may be a requirement in your case. Cheers, Funs On 09 Jun 2015, at 10:27, Paul Angus paul.an...@shapeblue.com wrote: Hi Christian, This is a feature put forward by myself. As a non-developer I can come up with these things and throw them over the wall to the developers and pretend I don't know how complicated it is :) In summary, it requires a few other pieces of the roadmap to be in place. The high level plan is to move ever closer to a driver/plugin model for CloudStack. For this feature we need to fully separate the VR plugin code from the 'core' code and create strong contracts for VR commands/responses. Then 'anyone' can create and maintain drivers for any type of router/firewall/vpn endpoint/loadbalancer. The CloudStack community would then continue to maintain the 'standard' VR/VPC. We're also developing OSPF capable and a routing-mode VPC offerings which we hope will be in 4.6 I'd be interested to hear how you're using the L2 devices to see where if we can fit it in to our 'Enterprise use' enhancements. Regards, Paul Angus Cloud Architect D: +44 20 3468 5163 |S: +44
Re: Third party VR / L2 support
Cloudrouter seems to be GPL2-ish. -- Erik On Thu, Jun 11, 2015 at 9:03 AM, Keerthiraja SJ sjkeer...@gmail.com wrote: Below are the router we can choose for the cloudstack integration. https://cloudrouter.org/ http://sourceforge.net/projects/rcp100/?source=directory On Tue, Jun 9, 2015 at 1:57 PM, Paul Angus paul.an...@shapeblue.com wrote: Hi Christian, This is a feature put forward by myself. As a non-developer I can come up with these things and throw them over the wall to the developers and pretend I don't know how complicated it is :) In summary, it requires a few other pieces of the roadmap to be in place. The high level plan is to move ever closer to a driver/plugin model for CloudStack. For this feature we need to fully separate the VR plugin code from the 'core' code and create strong contracts for VR commands/responses. Then 'anyone' can create and maintain drivers for any type of router/firewall/vpn endpoint/loadbalancer. The CloudStack community would then continue to maintain the 'standard' VR/VPC. We're also developing OSPF capable and a routing-mode VPC offerings which we hope will be in 4.6 I'd be interested to hear how you're using the L2 devices to see where if we can fit it in to our 'Enterprise use' enhancements. Regards, Paul Angus Cloud Architect D: +44 20 3468 5163 |S: +44 20 3603 0540 | M: +44 7711 418 784 | T: @CloudyAngus paul.an...@shapeblue.com -Original Message- From: Christian [mailto:christ...@bt.net] Sent: 01 June 2015 13:26 To: dev@cloudstack.apache.org Subject: Third party VR / L2 support Hi Sebastien, Thank you for publishing the roadmap. Replace VR with h/w (srx, asa etc) A question for all - What are the implications of expanding this feature to support s/w appliances, such as the ASA/CSR 1000V ? This is something that I have been implementing manually to date because: Improve VR, VR agent, API for VR :) It involves a little bit of 'creative networking' in order to suppress the CS virtual router. Any improvements in this area would be very useful. Even a QuickCloudNoServices-like offering for isolated networks would be great. I¹m aware that this can be created manually, but I¹m not convinced that this is a supported configuration. Pushing this concept further, I¹d like to see support for Layer 2 isolated networks. I use these for running virtual L2 devices under CS simply by creating dummy IP address ranges and ignoring them. Again, I have to suppress the VR, because it¹s not needed at L2. I¹ve been doing a fair bit to push the limits of networking in CloudStack over the last year using just VLANs and the standard API calls . I¹m happy to answer any questions anyone may have. Best regards, -Christian -- Christian Lafferty christ...@bt.net On 31/05/2015 05:08, Sebastien Goasguen run...@gmail.com wrote: Hi folks, Several folks on this list representing their company¹s interest shared with me their fixes/features plans and hopes. I believe we can use this to build a solid roadmap for our project, something that we have never had. I captured a lot of bullet items and tried to categorize them to start building a roadmap. You can see the document on our wiki at: https://cwiki.apache.org/confluence/display/CLOUDSTACK/Roadmap I would like to call everyone to make this page a great living document that will be up to date and help us drive cloudstack forward. First order of business would be to add description to each item and if you are working on it or would like to help out, write your name down ! Cheers, -Sebastien Find out more about ShapeBlue and our range of CloudStack related services IaaS Cloud Design Build http://shapeblue.com/iaas-cloud-design-and-build// CSForge – rapid IaaS deployment frameworkhttp://shapeblue.com/csforge/ CloudStack Consultinghttp://shapeblue.com/cloudstack-consultancy/ CloudStack Software Engineering http://shapeblue.com/cloudstack-software-engineering/ CloudStack Infrastructure Support http://shapeblue.com/cloudstack-infrastructure-support/ CloudStack Bootcamp Training Courses http://shapeblue.com/cloudstack-training/ This email and any attachments to it may be confidential and are intended solely for the use of the individual to whom it is addressed. Any views or opinions expressed are solely those of the author and do not necessarily represent those of Shape Blue Ltd or related companies. If you are not the intended recipient of this email, you must neither take any action based upon its contents, nor copy or show it to anyone. Please contact the sender if you believe you have received this email in error. Shape Blue Ltd is a company incorporated in England Wales. ShapeBlue Services India LLP is a company incorporated in India and
Re: Third party VR / L2 support
Below are the router we can choose for the cloudstack integration. https://cloudrouter.org/ http://sourceforge.net/projects/rcp100/?source=directory On Tue, Jun 9, 2015 at 1:57 PM, Paul Angus paul.an...@shapeblue.com wrote: Hi Christian, This is a feature put forward by myself. As a non-developer I can come up with these things and throw them over the wall to the developers and pretend I don't know how complicated it is :) In summary, it requires a few other pieces of the roadmap to be in place. The high level plan is to move ever closer to a driver/plugin model for CloudStack. For this feature we need to fully separate the VR plugin code from the 'core' code and create strong contracts for VR commands/responses. Then 'anyone' can create and maintain drivers for any type of router/firewall/vpn endpoint/loadbalancer. The CloudStack community would then continue to maintain the 'standard' VR/VPC. We're also developing OSPF capable and a routing-mode VPC offerings which we hope will be in 4.6 I'd be interested to hear how you're using the L2 devices to see where if we can fit it in to our 'Enterprise use' enhancements. Regards, Paul Angus Cloud Architect D: +44 20 3468 5163 |S: +44 20 3603 0540 | M: +44 7711 418 784 | T: @CloudyAngus paul.an...@shapeblue.com -Original Message- From: Christian [mailto:christ...@bt.net] Sent: 01 June 2015 13:26 To: dev@cloudstack.apache.org Subject: Third party VR / L2 support Hi Sebastien, Thank you for publishing the roadmap. Replace VR with h/w (srx, asa etc) A question for all - What are the implications of expanding this feature to support s/w appliances, such as the ASA/CSR 1000V ? This is something that I have been implementing manually to date because: Improve VR, VR agent, API for VR :) It involves a little bit of 'creative networking' in order to suppress the CS virtual router. Any improvements in this area would be very useful. Even a QuickCloudNoServices-like offering for isolated networks would be great. I¹m aware that this can be created manually, but I¹m not convinced that this is a supported configuration. Pushing this concept further, I¹d like to see support for Layer 2 isolated networks. I use these for running virtual L2 devices under CS simply by creating dummy IP address ranges and ignoring them. Again, I have to suppress the VR, because it¹s not needed at L2. I¹ve been doing a fair bit to push the limits of networking in CloudStack over the last year using just VLANs and the standard API calls . I¹m happy to answer any questions anyone may have. Best regards, -Christian -- Christian Lafferty christ...@bt.net On 31/05/2015 05:08, Sebastien Goasguen run...@gmail.com wrote: Hi folks, Several folks on this list representing their company¹s interest shared with me their fixes/features plans and hopes. I believe we can use this to build a solid roadmap for our project, something that we have never had. I captured a lot of bullet items and tried to categorize them to start building a roadmap. You can see the document on our wiki at: https://cwiki.apache.org/confluence/display/CLOUDSTACK/Roadmap I would like to call everyone to make this page a great living document that will be up to date and help us drive cloudstack forward. First order of business would be to add description to each item and if you are working on it or would like to help out, write your name down ! Cheers, -Sebastien Find out more about ShapeBlue and our range of CloudStack related services IaaS Cloud Design Build http://shapeblue.com/iaas-cloud-design-and-build// CSForge – rapid IaaS deployment frameworkhttp://shapeblue.com/csforge/ CloudStack Consultinghttp://shapeblue.com/cloudstack-consultancy/ CloudStack Software Engineering http://shapeblue.com/cloudstack-software-engineering/ CloudStack Infrastructure Support http://shapeblue.com/cloudstack-infrastructure-support/ CloudStack Bootcamp Training Courses http://shapeblue.com/cloudstack-training/ This email and any attachments to it may be confidential and are intended solely for the use of the individual to whom it is addressed. Any views or opinions expressed are solely those of the author and do not necessarily represent those of Shape Blue Ltd or related companies. If you are not the intended recipient of this email, you must neither take any action based upon its contents, nor copy or show it to anyone. Please contact the sender if you believe you have received this email in error. Shape Blue Ltd is a company incorporated in England Wales. ShapeBlue Services India LLP is a company incorporated in India and is operated under license from Shape Blue Ltd. Shape Blue Brasil Consultoria Ltda is a company incorporated in Brasil and is operated under license from Shape Blue Ltd. ShapeBlue SA Pty Ltd is a company registered by The Republic of South Africa and is traded under
Re: Third party VR / L2 support
Hi Christian and Paul, I agree that the VR/VPC construct could do with some improvements, the biggest being that it should actually be api driven and allow for more flexible networking/services combined with scale out itself (we’re looking into this actually). All of these things bring along their own problems and should be tackled piece by piece, if we’d want to be efficient we should first blot out the API and then start pushing services in, which is difficult at the speed it is moving at. The driver model in Cloudstack already supports the decoupling of services via network service providers (plugins) and ties in with the way the “network service offerings work with service capabilities and supported services. At SBP we use NSX-mh for the service “Connectivity”, we could add “SourceNat”, “StaticNat” and “Port Forwarding” to this for NSX if we want to, but decided to leave that in the VR back then as these services were rather new in NSX. My point being that you can already mix and match things and are not stuck with the VR/VPC, and you can actually use devices on that level if need be, if you create the service offerings for them. At the moment anyone can already create a plugin that exposes a single functionality or multiple, and expose that as a service that is offered, examples of these are the Palo-Alto, SRX, F5, Netscaler, Cisco VNMC, NSX and Nuage. I’m not saying it’s simple or easy, but if you know the API of what you want to integrate with you can. The construction of the plugin module has its own unique challenges, and I agree with John Burwell (Shape Blue) and Paul that we need to change the way this all hangs together if we want more flexibility and ease of integration in the future. BGP is brought in for use with IPv6, the first code for that has just gone in from Suresh via Wilder. As that runs on top of Quagga you could do OSPF with that too. This again leads me to believe we really need to change the way the RV/VPC receives configuration, I’ve spoken to a big Cloudstack user, whom also contributes, that wants to be able to do more with HaProxy, read full configuration freedom, and after hearing this and bumping my head against it in the past it made perfect sense to me. On the topic of L2 networking we’re bridging in and out a lot of networks at the moment for “Enterprise” production customers. Ranging from legacy environments to cloud environments or environments where we have full cloud workloads but also need physical iron due to “regulatory requirements” or because there is no viable alternative yet (or we haven’t made a plugin that exposes that functionality from another device/VM/container that can be placed in a service offering etc). I think in our case L2 is not always a requirement for all areas as such and I’d prefer L3 in most cases where viable. We solved things that way, the L2 way, because that was our frame of mind, although it may be a requirement in your case. Cheers, Funs On 09 Jun 2015, at 10:27, Paul Angus paul.an...@shapeblue.com wrote: Hi Christian, This is a feature put forward by myself. As a non-developer I can come up with these things and throw them over the wall to the developers and pretend I don't know how complicated it is :) In summary, it requires a few other pieces of the roadmap to be in place. The high level plan is to move ever closer to a driver/plugin model for CloudStack. For this feature we need to fully separate the VR plugin code from the 'core' code and create strong contracts for VR commands/responses. Then 'anyone' can create and maintain drivers for any type of router/firewall/vpn endpoint/loadbalancer. The CloudStack community would then continue to maintain the 'standard' VR/VPC. We're also developing OSPF capable and a routing-mode VPC offerings which we hope will be in 4.6 I'd be interested to hear how you're using the L2 devices to see where if we can fit it in to our 'Enterprise use' enhancements. Regards, Paul Angus Cloud Architect D: +44 20 3468 5163 |S: +44 20 3603 0540 | M: +44 7711 418 784 | T: @CloudyAngus paul.an...@shapeblue.com -Original Message- From: Christian [mailto:christ...@bt.net] Sent: 01 June 2015 13:26 To: dev@cloudstack.apache.org Subject: Third party VR / L2 support Hi Sebastien, Thank you for publishing the roadmap. Replace VR with h/w (srx, asa etc) A question for all - What are the implications of expanding this feature to support s/w appliances, such as the ASA/CSR 1000V ? This is something that I have been implementing manually to date because: Improve VR, VR agent, API for VR :) It involves a little bit of 'creative networking' in order to suppress the CS virtual router. Any improvements in this area would be very useful. Even a QuickCloudNoServices-like offering for isolated networks would be great. I¹m aware that this can be created manually, but I¹m not
RE: Third party VR / L2 support
Hi Christian, This is a feature put forward by myself. As a non-developer I can come up with these things and throw them over the wall to the developers and pretend I don't know how complicated it is :) In summary, it requires a few other pieces of the roadmap to be in place. The high level plan is to move ever closer to a driver/plugin model for CloudStack. For this feature we need to fully separate the VR plugin code from the 'core' code and create strong contracts for VR commands/responses. Then 'anyone' can create and maintain drivers for any type of router/firewall/vpn endpoint/loadbalancer. The CloudStack community would then continue to maintain the 'standard' VR/VPC. We're also developing OSPF capable and a routing-mode VPC offerings which we hope will be in 4.6 I'd be interested to hear how you're using the L2 devices to see where if we can fit it in to our 'Enterprise use' enhancements. Regards, Paul Angus Cloud Architect D: +44 20 3468 5163 |S: +44 20 3603 0540 | M: +44 7711 418 784 | T: @CloudyAngus paul.an...@shapeblue.com -Original Message- From: Christian [mailto:christ...@bt.net] Sent: 01 June 2015 13:26 To: dev@cloudstack.apache.org Subject: Third party VR / L2 support Hi Sebastien, Thank you for publishing the roadmap. Replace VR with h/w (srx, asa etc) A question for all - What are the implications of expanding this feature to support s/w appliances, such as the ASA/CSR 1000V ? This is something that I have been implementing manually to date because: Improve VR, VR agent, API for VR :) It involves a little bit of 'creative networking' in order to suppress the CS virtual router. Any improvements in this area would be very useful. Even a QuickCloudNoServices-like offering for isolated networks would be great. I¹m aware that this can be created manually, but I¹m not convinced that this is a supported configuration. Pushing this concept further, I¹d like to see support for Layer 2 isolated networks. I use these for running virtual L2 devices under CS simply by creating dummy IP address ranges and ignoring them. Again, I have to suppress the VR, because it¹s not needed at L2. I¹ve been doing a fair bit to push the limits of networking in CloudStack over the last year using just VLANs and the standard API calls . I¹m happy to answer any questions anyone may have. Best regards, -Christian -- Christian Lafferty christ...@bt.net On 31/05/2015 05:08, Sebastien Goasguen run...@gmail.com wrote: Hi folks, Several folks on this list representing their company¹s interest shared with me their fixes/features plans and hopes. I believe we can use this to build a solid roadmap for our project, something that we have never had. I captured a lot of bullet items and tried to categorize them to start building a roadmap. You can see the document on our wiki at: https://cwiki.apache.org/confluence/display/CLOUDSTACK/Roadmap I would like to call everyone to make this page a great living document that will be up to date and help us drive cloudstack forward. First order of business would be to add description to each item and if you are working on it or would like to help out, write your name down ! Cheers, -Sebastien Find out more about ShapeBlue and our range of CloudStack related services IaaS Cloud Design Buildhttp://shapeblue.com/iaas-cloud-design-and-build// CSForge – rapid IaaS deployment frameworkhttp://shapeblue.com/csforge/ CloudStack Consultinghttp://shapeblue.com/cloudstack-consultancy/ CloudStack Software Engineeringhttp://shapeblue.com/cloudstack-software-engineering/ CloudStack Infrastructure Supporthttp://shapeblue.com/cloudstack-infrastructure-support/ CloudStack Bootcamp Training Courseshttp://shapeblue.com/cloudstack-training/ This email and any attachments to it may be confidential and are intended solely for the use of the individual to whom it is addressed. Any views or opinions expressed are solely those of the author and do not necessarily represent those of Shape Blue Ltd or related companies. If you are not the intended recipient of this email, you must neither take any action based upon its contents, nor copy or show it to anyone. Please contact the sender if you believe you have received this email in error. Shape Blue Ltd is a company incorporated in England Wales. ShapeBlue Services India LLP is a company incorporated in India and is operated under license from Shape Blue Ltd. Shape Blue Brasil Consultoria Ltda is a company incorporated in Brasil and is operated under license from Shape Blue Ltd. ShapeBlue SA Pty Ltd is a company registered by The Republic of South Africa and is traded under license from Shape Blue Ltd. ShapeBlue is a registered trademark.
