You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cloudstack.apache.org by Christian <ch...@bt.net> on 2015/06/01 14:25:56 UTC
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
<ch...@bt.net>
On 31/05/2015 05:08, "Sebastien Goasguen" <ru...@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
RE: Third party VR / L2 support
Posted by Rajesh Battala <ra...@citrix.com>.
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.das@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:fozzielumpkins@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 <pa...@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.angus@shapeblue.com
>
> -----Original Message-----
> From: Christian [mailto:christian@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
> <ch...@bt.net>
>
>
>
> On 31/05/2015 05:08, "Sebastien Goasguen" <ru...@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://secure-web.cisco.com/1NTgUa4fzQa42q_3T_XpTUoFuwW4RoRm6V0Z
> iM7oPgP0-ItVsL6mkVQsA_-uXKQPH54czwGyS28mxt7gRuUOC-Go3u57toWkaQXYkPDZX8
> sv4c9rofl0C-R-G3f8bqHmyUaDM0npe1VNmKwXSTOGJlf26xnX8YXHj01JSJCxJy5hd71u
> i8Qnp9Ova_0MqJ31R/http%3A%2F%2Fshapeblue.com%2Fiaas-cloud-design-and-b
> uild%2F%2F> CSForge – rapid IaaS deployment
> framework<http://secure-web.cisco.com/1gxJw8pPv2ssbAm6NYkubkxR19T40kq6
> poYkbqC-d58dZdWgI6Fopw_8NntmiZmE3ScJMe4tUgF2ir9dR8kG0FW98CRuUXi3DtcB1c
> Ip1rBEjh_gtHVBCd_VGqv5PjX1f-3IOGJIOsDmAsMcbkgs1SefKTfVTNzHec9mI9CiDA_j
> a8h5Abi3VOgeoVbcSusz8/http%3A%2F%2Fshapeblue.com%2Fcsforge%2F>
> CloudStack
> Consulting<http://secure-web.cisco.com/1jWNM0Kh2pEf9DyT_T1U4eJl6rP7K2y
> vP_-4ZGRG_Prhsm_hypQSpgtVdnqan7JAwFGx-V4sKkWTRXFAN5FzVnfyDCyjXDysVzaSz
> KliSMkAYogajqlEieHV6xOkBSIlljD9Vq8K2MobsvX0H2Ko7MGltINDbv5lEIUOI5ZLesA
> txT-HB6hsIXolvmy-mPI_K/http%3A%2F%2Fshapeblue.com%2Fcloudstack-consult
> ancy%2F> CloudStack Software
> Engineering<http://secure-web.cisco.com/10FEn133mIAUNUe5Ml3aUpRE4V2031
> A_1FCMSI-YXGEfuih_Uq7vwmhHlAiquJEZINwlZolL1ieIj0NfhxLA4FytOEf2h_63Qg1A
> 3mTnpoqP6SEtS-P0Cw_k4Kps-MnW68o0qjnHmXqg5veuzqtB_ipVSVp5Y6e2r2PkXu8S5B
> UK7wspjCjuniGljxy1DF5NA/http%3A%2F%2Fshapeblue.com%2Fcloudstack-softwa
> re-engineering%2F> CloudStack Infrastructure
> Support<http://secure-web.cisco.com/1T9pIEjnSN8nCPGJKvEm8VapRX7LIcBYen
> calPRagsx10bbPrMovd3ooAShHWdiTfXYVZbXuTPNTmrb-ovIBaxzS2b8IFw1YYaxflIvh
> bFKjLpzMfzlI_cBZpKsGkU-hIvdNSDfLcQfe_yKyNAJie8y4GWd-__KGAk208fB39Ie8bJ
> SK23CWHWZkbAAE_1FPs/http%3A%2F%2Fshapeblue.com%2Fcloudstack-infrastruc
> ture-support%2F> CloudStack Bootcamp Training
> Courses<http://secure-web.cisco.com/1O8ikOAFTj3hPGypI7JLQc85nMtt4Nj6hy
> hYb7F-VfarsrkTIOkMSjxuLxdx3paM3U4Xu644oFXvtdKP2-NBg571Z80S3DkXA_KIG5gv
> G_rQX6eE6WSC0xy2sbtJq7f631ePaXioqihpHIs8TveQEvFEDBgONpyUsheRFRUPTDQDv-
> n8K3Ob_jkYjUWl4WRa3/http%3A%2F%2Fshapeblue.com%2Fcloudstack-training%2
> F>
>
> 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.
—
=Funs
RE: Third party VR / L2 support
Posted by Paul Angus <pa...@shapeblue.com>.
Hey Fozzielumpkins (love it),
Yes, Iets agree to agree!
Regards,
Paul Angus
Cloud Architect
S: +44 20 3603 0540 | M: +447711418784 | T: CloudyAngus
paul.angus@shapeblue.com
-----Original Message-----
From: Funs Kessen [mailto:fozzielumpkins@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 <pa...@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.angus@shapeblue.com
>
> -----Original Message-----
> From: Koushik Das [mailto:koushik.das@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:fozzielumpkins@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 <pa...@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.angus@shapeblue.com
>>
>> -----Original Message-----
>> From: Christian [mailto:christian@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
>> <ch...@bt.net>
>>
>>
>>
>> On 31/05/2015 05:08, "Sebastien Goasguen" <ru...@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://secure-web.cisco.com/1NTgUa4fzQa42q_3T_XpTUoFuwW4RoRm6V0
>> Z
>> iM7oPgP0-ItVsL6mkVQsA_-uXKQPH54czwGyS28mxt7gRuUOC-Go3u57toWkaQXYkPDZX
>> 8
>> sv4c9rofl0C-R-G3f8bqHmyUaDM0npe1VNmKwXSTOGJlf26xnX8YXHj01JSJCxJy5hd71
>> u
>> i8Qnp9Ova_0MqJ31R/http%3A%2F%2Fshapeblue.com%2Fiaas-cloud-design-and-
>> b uild%2F%2F> CSForge – rapid IaaS deployment
>> framework<http://secure-web.cisco.com/1gxJw8pPv2ssbAm6NYkubkxR19T40kq
>> 6
>> poYkbqC-d58dZdWgI6Fopw_8NntmiZmE3ScJMe4tUgF2ir9dR8kG0FW98CRuUXi3DtcB1
>> c
>> Ip1rBEjh_gtHVBCd_VGqv5PjX1f-3IOGJIOsDmAsMcbkgs1SefKTfVTNzHec9mI9CiDA_
>> j a8h5Abi3VOgeoVbcSusz8/http%3A%2F%2Fshapeblue.com%2Fcsforge%2F>
>> CloudStack
>> Consulting<http://secure-web.cisco.com/1jWNM0Kh2pEf9DyT_T1U4eJl6rP7K2
>> y
>> vP_-4ZGRG_Prhsm_hypQSpgtVdnqan7JAwFGx-V4sKkWTRXFAN5FzVnfyDCyjXDysVzaS
>> z
>> KliSMkAYogajqlEieHV6xOkBSIlljD9Vq8K2MobsvX0H2Ko7MGltINDbv5lEIUOI5ZLes
>> A
>> txT-HB6hsIXolvmy-mPI_K/http%3A%2F%2Fshapeblue.com%2Fcloudstack-consul
>> t
>> ancy%2F> CloudStack Software
>> Engineering<http://secure-web.cisco.com/10FEn133mIAUNUe5Ml3aUpRE4V203
>> 1
>> A_1FCMSI-YXGEfuih_Uq7vwmhHlAiquJEZINwlZolL1ieIj0NfhxLA4FytOEf2h_63Qg1
>> A
>> 3mTnpoqP6SEtS-P0Cw_k4Kps-MnW68o0qjnHmXqg5veuzqtB_ipVSVp5Y6e2r2PkXu8S5
>> B
>> UK7wspjCjuniGljxy1DF5NA/http%3A%2F%2Fshapeblue.com%2Fcloudstack-softw
>> a re-engineering%2F> CloudStack Infrastructure
>> Support<http://secure-web.cisco.com/1T9pIEjnSN8nCPGJKvEm8VapRX7LIcBYe
>> n
>> calPRagsx10bbPrMovd3ooAShHWdiTfXYVZbXuTPNTmrb-ovIBaxzS2b8IFw1YYaxflIv
>> h
>> bFKjLpzMfzlI_cBZpKsGkU-hIvdNSDfLcQfe_yKyNAJie8y4GWd-__KGAk208fB39Ie8b
>> J
>> SK23CWHWZkbAAE_1FPs/http%3A%2F%2Fshapeblue.com%2Fcloudstack-infrastru
>> c ture-support%2F> CloudStack Bootcamp Training
>> Courses<http://secure-web.cisco.com/1O8ikOAFTj3hPGypI7JLQc85nMtt4Nj6h
>> y
>> hYb7F-VfarsrkTIOkMSjxuLxdx3paM3U4Xu644oFXvtdKP2-NBg571Z80S3DkXA_KIG5g
>> v
>> G_rQX6eE6WSC0xy2sbtJq7f631ePaXioqihpHIs8TveQEvFEDBgONpyUsheRFRUPTDQDv
>> -
>> n8K3Ob_jkYjUWl4WRa3/http%3A%2F%2Fshapeblue.com%2Fcloudstack-training%
>> 2
>> F>
>>
>> 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.
>
> —
> =Funs
>
>
> 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
> framework<http://shapeblue.com/csforge/>
> CloudStack Consulting<http://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 license from Shape Blue Ltd. ShapeBlue is a registered trademark.
—
=Funs
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 framework<http://shapeblue.com/csforge/>
CloudStack Consulting<http://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 license from Shape Blue Ltd. ShapeBlue is a registered trademark.
Re: Third party VR / L2 support
Posted by Funs Kessen <fu...@barred.org>.
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 <pa...@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.angus@shapeblue.com
>
> -----Original Message-----
> From: Koushik Das [mailto:koushik.das@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:fozzielumpkins@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 <pa...@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.angus@shapeblue.com
>>
>> -----Original Message-----
>> From: Christian [mailto:christian@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
>> <ch...@bt.net>
>>
>>
>>
>> On 31/05/2015 05:08, "Sebastien Goasguen" <ru...@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://secure-web.cisco.com/1NTgUa4fzQa42q_3T_XpTUoFuwW4RoRm6V0Z
>> iM7oPgP0-ItVsL6mkVQsA_-uXKQPH54czwGyS28mxt7gRuUOC-Go3u57toWkaQXYkPDZX8
>> sv4c9rofl0C-R-G3f8bqHmyUaDM0npe1VNmKwXSTOGJlf26xnX8YXHj01JSJCxJy5hd71u
>> i8Qnp9Ova_0MqJ31R/http%3A%2F%2Fshapeblue.com%2Fiaas-cloud-design-and-b
>> uild%2F%2F> CSForge – rapid IaaS deployment
>> framework<http://secure-web.cisco.com/1gxJw8pPv2ssbAm6NYkubkxR19T40kq6
>> poYkbqC-d58dZdWgI6Fopw_8NntmiZmE3ScJMe4tUgF2ir9dR8kG0FW98CRuUXi3DtcB1c
>> Ip1rBEjh_gtHVBCd_VGqv5PjX1f-3IOGJIOsDmAsMcbkgs1SefKTfVTNzHec9mI9CiDA_j
>> a8h5Abi3VOgeoVbcSusz8/http%3A%2F%2Fshapeblue.com%2Fcsforge%2F>
>> CloudStack
>> Consulting<http://secure-web.cisco.com/1jWNM0Kh2pEf9DyT_T1U4eJl6rP7K2y
>> vP_-4ZGRG_Prhsm_hypQSpgtVdnqan7JAwFGx-V4sKkWTRXFAN5FzVnfyDCyjXDysVzaSz
>> KliSMkAYogajqlEieHV6xOkBSIlljD9Vq8K2MobsvX0H2Ko7MGltINDbv5lEIUOI5ZLesA
>> txT-HB6hsIXolvmy-mPI_K/http%3A%2F%2Fshapeblue.com%2Fcloudstack-consult
>> ancy%2F> CloudStack Software
>> Engineering<http://secure-web.cisco.com/10FEn133mIAUNUe5Ml3aUpRE4V2031
>> A_1FCMSI-YXGEfuih_Uq7vwmhHlAiquJEZINwlZolL1ieIj0NfhxLA4FytOEf2h_63Qg1A
>> 3mTnpoqP6SEtS-P0Cw_k4Kps-MnW68o0qjnHmXqg5veuzqtB_ipVSVp5Y6e2r2PkXu8S5B
>> UK7wspjCjuniGljxy1DF5NA/http%3A%2F%2Fshapeblue.com%2Fcloudstack-softwa
>> re-engineering%2F> CloudStack Infrastructure
>> Support<http://secure-web.cisco.com/1T9pIEjnSN8nCPGJKvEm8VapRX7LIcBYen
>> calPRagsx10bbPrMovd3ooAShHWdiTfXYVZbXuTPNTmrb-ovIBaxzS2b8IFw1YYaxflIvh
>> bFKjLpzMfzlI_cBZpKsGkU-hIvdNSDfLcQfe_yKyNAJie8y4GWd-__KGAk208fB39Ie8bJ
>> SK23CWHWZkbAAE_1FPs/http%3A%2F%2Fshapeblue.com%2Fcloudstack-infrastruc
>> ture-support%2F> CloudStack Bootcamp Training
>> Courses<http://secure-web.cisco.com/1O8ikOAFTj3hPGypI7JLQc85nMtt4Nj6hy
>> hYb7F-VfarsrkTIOkMSjxuLxdx3paM3U4Xu644oFXvtdKP2-NBg571Z80S3DkXA_KIG5gv
>> G_rQX6eE6WSC0xy2sbtJq7f631ePaXioqihpHIs8TveQEvFEDBgONpyUsheRFRUPTDQDv-
>> n8K3Ob_jkYjUWl4WRa3/http%3A%2F%2Fshapeblue.com%2Fcloudstack-training%2
>> F>
>>
>> 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.
>
> —
> =Funs
>
>
> 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 framework<http://shapeblue.com/csforge/>
> CloudStack Consulting<http://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 license from Shape Blue Ltd. ShapeBlue is a registered trademark.
—
=Funs
RE: Third party VR / L2 support
Posted by Paul Angus <pa...@shapeblue.com>.
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.angus@shapeblue.com
-----Original Message-----
From: Koushik Das [mailto:koushik.das@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:fozzielumpkins@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 <pa...@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.angus@shapeblue.com
>
> -----Original Message-----
> From: Christian [mailto:christian@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
> <ch...@bt.net>
>
>
>
> On 31/05/2015 05:08, "Sebastien Goasguen" <ru...@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://secure-web.cisco.com/1NTgUa4fzQa42q_3T_XpTUoFuwW4RoRm6V0Z
> iM7oPgP0-ItVsL6mkVQsA_-uXKQPH54czwGyS28mxt7gRuUOC-Go3u57toWkaQXYkPDZX8
> sv4c9rofl0C-R-G3f8bqHmyUaDM0npe1VNmKwXSTOGJlf26xnX8YXHj01JSJCxJy5hd71u
> i8Qnp9Ova_0MqJ31R/http%3A%2F%2Fshapeblue.com%2Fiaas-cloud-design-and-b
> uild%2F%2F> CSForge – rapid IaaS deployment
> framework<http://secure-web.cisco.com/1gxJw8pPv2ssbAm6NYkubkxR19T40kq6
> poYkbqC-d58dZdWgI6Fopw_8NntmiZmE3ScJMe4tUgF2ir9dR8kG0FW98CRuUXi3DtcB1c
> Ip1rBEjh_gtHVBCd_VGqv5PjX1f-3IOGJIOsDmAsMcbkgs1SefKTfVTNzHec9mI9CiDA_j
> a8h5Abi3VOgeoVbcSusz8/http%3A%2F%2Fshapeblue.com%2Fcsforge%2F>
> CloudStack
> Consulting<http://secure-web.cisco.com/1jWNM0Kh2pEf9DyT_T1U4eJl6rP7K2y
> vP_-4ZGRG_Prhsm_hypQSpgtVdnqan7JAwFGx-V4sKkWTRXFAN5FzVnfyDCyjXDysVzaSz
> KliSMkAYogajqlEieHV6xOkBSIlljD9Vq8K2MobsvX0H2Ko7MGltINDbv5lEIUOI5ZLesA
> txT-HB6hsIXolvmy-mPI_K/http%3A%2F%2Fshapeblue.com%2Fcloudstack-consult
> ancy%2F> CloudStack Software
> Engineering<http://secure-web.cisco.com/10FEn133mIAUNUe5Ml3aUpRE4V2031
> A_1FCMSI-YXGEfuih_Uq7vwmhHlAiquJEZINwlZolL1ieIj0NfhxLA4FytOEf2h_63Qg1A
> 3mTnpoqP6SEtS-P0Cw_k4Kps-MnW68o0qjnHmXqg5veuzqtB_ipVSVp5Y6e2r2PkXu8S5B
> UK7wspjCjuniGljxy1DF5NA/http%3A%2F%2Fshapeblue.com%2Fcloudstack-softwa
> re-engineering%2F> CloudStack Infrastructure
> Support<http://secure-web.cisco.com/1T9pIEjnSN8nCPGJKvEm8VapRX7LIcBYen
> calPRagsx10bbPrMovd3ooAShHWdiTfXYVZbXuTPNTmrb-ovIBaxzS2b8IFw1YYaxflIvh
> bFKjLpzMfzlI_cBZpKsGkU-hIvdNSDfLcQfe_yKyNAJie8y4GWd-__KGAk208fB39Ie8bJ
> SK23CWHWZkbAAE_1FPs/http%3A%2F%2Fshapeblue.com%2Fcloudstack-infrastruc
> ture-support%2F> CloudStack Bootcamp Training
> Courses<http://secure-web.cisco.com/1O8ikOAFTj3hPGypI7JLQc85nMtt4Nj6hy
> hYb7F-VfarsrkTIOkMSjxuLxdx3paM3U4Xu644oFXvtdKP2-NBg571Z80S3DkXA_KIG5gv
> G_rQX6eE6WSC0xy2sbtJq7f631ePaXioqihpHIs8TveQEvFEDBgONpyUsheRFRUPTDQDv-
> n8K3Ob_jkYjUWl4WRa3/http%3A%2F%2Fshapeblue.com%2Fcloudstack-training%2
> F>
>
> 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.
—
=Funs
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 framework<http://shapeblue.com/csforge/>
CloudStack Consulting<http://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 license from Shape Blue Ltd. ShapeBlue is a registered trademark.
Re: Third party VR / L2 support
Posted by sebgoa <ru...@gmail.com>.
On Jun 12, 2015, at 11:13 AM, Christian <ch...@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" <ko...@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:fozzielumpkins@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 <pa...@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.angus@shapeblue.com
>>>
>>> -----Original Message-----
>>> From: Christian [mailto:christian@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
>>> <ch...@bt.net>
>>>
>>>
>>>
>>> On 31/05/2015 05:08, "Sebastien Goasguen" <ru...@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://secure-web.cisco.com/1NTgUa4fzQa42q_3T_XpTUoFuwW4RoRm6V0Z
>>> iM7oPgP0-ItVsL6mkVQsA_-uXKQPH54czwGyS28mxt7gRuUOC-Go3u57toWkaQXYkPDZX8
>>> sv4c9rofl0C-R-G3f8bqHmyUaDM0npe1VNmKwXSTOGJlf26xnX8YXHj01JSJCxJy5hd71u
>>> i8Qnp9Ova_0MqJ31R/http%3A%2F%2Fshapeblue.com%2Fiaas-cloud-design-and-b
>>> uild%2F%2F> CSForge rapid IaaS deployment
>>> framework<http://secure-web.cisco.com/1gxJw8pPv2ssbAm6NYkubkxR19T40kq6
>>> poYkbqC-d58dZdWgI6Fopw_8NntmiZmE3ScJMe4tUgF2ir9dR8kG0FW98CRuUXi3DtcB1c
>>> Ip1rBEjh_gtHVBCd_VGqv5PjX1f-3IOGJIOsDmAsMcbkgs1SefKTfVTNzHec9mI9CiDA_j
>>> a8h5Abi3VOgeoVbcSusz8/http%3A%2F%2Fshapeblue.com%2Fcsforge%2F>
>>> CloudStack
>>> Consulting<http://secure-web.cisco.com/1jWNM0Kh2pEf9DyT_T1U4eJl6rP7K2y
>>> vP_-4ZGRG_Prhsm_hypQSpgtVdnqan7JAwFGx-V4sKkWTRXFAN5FzVnfyDCyjXDysVzaSz
>>> KliSMkAYogajqlEieHV6xOkBSIlljD9Vq8K2MobsvX0H2Ko7MGltINDbv5lEIUOI5ZLesA
>>> txT-HB6hsIXolvmy-mPI_K/http%3A%2F%2Fshapeblue.com%2Fcloudstack-consult
>>> ancy%2F> CloudStack Software
>>> Engineering<http://secure-web.cisco.com/10FEn133mIAUNUe5Ml3aUpRE4V2031
>>> A_1FCMSI-YXGEfuih_Uq7vwmhHlAiquJEZINwlZolL1ieIj0NfhxLA4FytOEf2h_63Qg1A
>>> 3mTnpoqP6SEtS-P0Cw_k4Kps-MnW68o0qjnHmXqg5veuzqtB_ipVSVp5Y6e2r2PkXu8S5B
>>> UK7wspjCjuniGljxy1DF5NA/http%3A%2F%2Fshapeblue.com%2Fcloudstack-softwa
>>> re-engineering%2F> CloudStack Infrastructure
>>> Support<http://secure-web.cisco.com/1T9pIEjnSN8nCPGJKvEm8VapRX7LIcBYen
>>> calPRagsx10bbPrMovd3ooAShHWdiTfXYVZbXuTPNTmrb-ovIBaxzS2b8IFw1YYaxflIvh
>>> bFKjLpzMfzlI_cBZpKsGkU-hIvdNSDfLcQfe_yKyNAJie8y4GWd-__KGAk208fB39Ie8bJ
>>> SK23CWHWZkbAAE_1FPs/http%3A%2F%2Fshapeblue.com%2Fcloudstack-infrastruc
>>> ture-support%2F> CloudStack Bootcamp Training
>>> Courses<http://secure-web.cisco.com/1O8ikOAFTj3hPGypI7JLQc85nMtt4Nj6hy
>>> hYb7F-VfarsrkTIOkMSjxuLxdx3paM3U4Xu644oFXvtdKP2-NBg571Z80S3DkXA_KIG5gv
>>> G_rQX6eE6WSC0xy2sbtJq7f631ePaXioqihpHIs8TveQEvFEDBgONpyUsheRFRUPTDQDv-
>>> n8K3Ob_jkYjUWl4WRa3/http%3A%2F%2Fshapeblue.com%2Fcloudstack-training%2
>>> F>
>>>
>>> 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.
>>
>> ―
>> =Funs
>>
>>
>
>
Re: Third party VR / L2 support
Posted by Christian <ch...@bt.net>.
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" <ko...@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:fozzielumpkins@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 <pa...@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.angus@shapeblue.com
>>
>> -----Original Message-----
>> From: Christian [mailto:christian@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
>> <ch...@bt.net>
>>
>>
>>
>> On 31/05/2015 05:08, "Sebastien Goasguen" <ru...@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://secure-web.cisco.com/1NTgUa4fzQa42q_3T_XpTUoFuwW4RoRm6V0Z
>> iM7oPgP0-ItVsL6mkVQsA_-uXKQPH54czwGyS28mxt7gRuUOC-Go3u57toWkaQXYkPDZX8
>> sv4c9rofl0C-R-G3f8bqHmyUaDM0npe1VNmKwXSTOGJlf26xnX8YXHj01JSJCxJy5hd71u
>> i8Qnp9Ova_0MqJ31R/http%3A%2F%2Fshapeblue.com%2Fiaas-cloud-design-and-b
>> uild%2F%2F> CSForge rapid IaaS deployment
>> framework<http://secure-web.cisco.com/1gxJw8pPv2ssbAm6NYkubkxR19T40kq6
>> poYkbqC-d58dZdWgI6Fopw_8NntmiZmE3ScJMe4tUgF2ir9dR8kG0FW98CRuUXi3DtcB1c
>> Ip1rBEjh_gtHVBCd_VGqv5PjX1f-3IOGJIOsDmAsMcbkgs1SefKTfVTNzHec9mI9CiDA_j
>> a8h5Abi3VOgeoVbcSusz8/http%3A%2F%2Fshapeblue.com%2Fcsforge%2F>
>> CloudStack
>> Consulting<http://secure-web.cisco.com/1jWNM0Kh2pEf9DyT_T1U4eJl6rP7K2y
>> vP_-4ZGRG_Prhsm_hypQSpgtVdnqan7JAwFGx-V4sKkWTRXFAN5FzVnfyDCyjXDysVzaSz
>> KliSMkAYogajqlEieHV6xOkBSIlljD9Vq8K2MobsvX0H2Ko7MGltINDbv5lEIUOI5ZLesA
>> txT-HB6hsIXolvmy-mPI_K/http%3A%2F%2Fshapeblue.com%2Fcloudstack-consult
>> ancy%2F> CloudStack Software
>> Engineering<http://secure-web.cisco.com/10FEn133mIAUNUe5Ml3aUpRE4V2031
>> A_1FCMSI-YXGEfuih_Uq7vwmhHlAiquJEZINwlZolL1ieIj0NfhxLA4FytOEf2h_63Qg1A
>> 3mTnpoqP6SEtS-P0Cw_k4Kps-MnW68o0qjnHmXqg5veuzqtB_ipVSVp5Y6e2r2PkXu8S5B
>> UK7wspjCjuniGljxy1DF5NA/http%3A%2F%2Fshapeblue.com%2Fcloudstack-softwa
>> re-engineering%2F> CloudStack Infrastructure
>> Support<http://secure-web.cisco.com/1T9pIEjnSN8nCPGJKvEm8VapRX7LIcBYen
>> calPRagsx10bbPrMovd3ooAShHWdiTfXYVZbXuTPNTmrb-ovIBaxzS2b8IFw1YYaxflIvh
>> bFKjLpzMfzlI_cBZpKsGkU-hIvdNSDfLcQfe_yKyNAJie8y4GWd-__KGAk208fB39Ie8bJ
>> SK23CWHWZkbAAE_1FPs/http%3A%2F%2Fshapeblue.com%2Fcloudstack-infrastruc
>> ture-support%2F> CloudStack Bootcamp Training
>> Courses<http://secure-web.cisco.com/1O8ikOAFTj3hPGypI7JLQc85nMtt4Nj6hy
>> hYb7F-VfarsrkTIOkMSjxuLxdx3paM3U4Xu644oFXvtdKP2-NBg571Z80S3DkXA_KIG5gv
>> G_rQX6eE6WSC0xy2sbtJq7f631ePaXioqihpHIs8TveQEvFEDBgONpyUsheRFRUPTDQDv-
>> n8K3Ob_jkYjUWl4WRa3/http%3A%2F%2Fshapeblue.com%2Fcloudstack-training%2
>> F>
>>
>> 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.
>
>―
> =Funs
>
>
RE: Third party VR / L2 support
Posted by Koushik Das <ko...@citrix.com>.
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:fozzielumpkins@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 <pa...@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.angus@shapeblue.com
>
> -----Original Message-----
> From: Christian [mailto:christian@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
> <ch...@bt.net>
>
>
>
> On 31/05/2015 05:08, "Sebastien Goasguen" <ru...@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://secure-web.cisco.com/1NTgUa4fzQa42q_3T_XpTUoFuwW4RoRm6V0Z
> iM7oPgP0-ItVsL6mkVQsA_-uXKQPH54czwGyS28mxt7gRuUOC-Go3u57toWkaQXYkPDZX8
> sv4c9rofl0C-R-G3f8bqHmyUaDM0npe1VNmKwXSTOGJlf26xnX8YXHj01JSJCxJy5hd71u
> i8Qnp9Ova_0MqJ31R/http%3A%2F%2Fshapeblue.com%2Fiaas-cloud-design-and-b
> uild%2F%2F> CSForge – rapid IaaS deployment
> framework<http://secure-web.cisco.com/1gxJw8pPv2ssbAm6NYkubkxR19T40kq6
> poYkbqC-d58dZdWgI6Fopw_8NntmiZmE3ScJMe4tUgF2ir9dR8kG0FW98CRuUXi3DtcB1c
> Ip1rBEjh_gtHVBCd_VGqv5PjX1f-3IOGJIOsDmAsMcbkgs1SefKTfVTNzHec9mI9CiDA_j
> a8h5Abi3VOgeoVbcSusz8/http%3A%2F%2Fshapeblue.com%2Fcsforge%2F>
> CloudStack
> Consulting<http://secure-web.cisco.com/1jWNM0Kh2pEf9DyT_T1U4eJl6rP7K2y
> vP_-4ZGRG_Prhsm_hypQSpgtVdnqan7JAwFGx-V4sKkWTRXFAN5FzVnfyDCyjXDysVzaSz
> KliSMkAYogajqlEieHV6xOkBSIlljD9Vq8K2MobsvX0H2Ko7MGltINDbv5lEIUOI5ZLesA
> txT-HB6hsIXolvmy-mPI_K/http%3A%2F%2Fshapeblue.com%2Fcloudstack-consult
> ancy%2F> CloudStack Software
> Engineering<http://secure-web.cisco.com/10FEn133mIAUNUe5Ml3aUpRE4V2031
> A_1FCMSI-YXGEfuih_Uq7vwmhHlAiquJEZINwlZolL1ieIj0NfhxLA4FytOEf2h_63Qg1A
> 3mTnpoqP6SEtS-P0Cw_k4Kps-MnW68o0qjnHmXqg5veuzqtB_ipVSVp5Y6e2r2PkXu8S5B
> UK7wspjCjuniGljxy1DF5NA/http%3A%2F%2Fshapeblue.com%2Fcloudstack-softwa
> re-engineering%2F> CloudStack Infrastructure
> Support<http://secure-web.cisco.com/1T9pIEjnSN8nCPGJKvEm8VapRX7LIcBYen
> calPRagsx10bbPrMovd3ooAShHWdiTfXYVZbXuTPNTmrb-ovIBaxzS2b8IFw1YYaxflIvh
> bFKjLpzMfzlI_cBZpKsGkU-hIvdNSDfLcQfe_yKyNAJie8y4GWd-__KGAk208fB39Ie8bJ
> SK23CWHWZkbAAE_1FPs/http%3A%2F%2Fshapeblue.com%2Fcloudstack-infrastruc
> ture-support%2F> CloudStack Bootcamp Training
> Courses<http://secure-web.cisco.com/1O8ikOAFTj3hPGypI7JLQc85nMtt4Nj6hy
> hYb7F-VfarsrkTIOkMSjxuLxdx3paM3U4Xu644oFXvtdKP2-NBg571Z80S3DkXA_KIG5gv
> G_rQX6eE6WSC0xy2sbtJq7f631ePaXioqihpHIs8TveQEvFEDBgONpyUsheRFRUPTDQDv-
> n8K3Ob_jkYjUWl4WRa3/http%3A%2F%2Fshapeblue.com%2Fcloudstack-training%2
> F>
>
> 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.
—
=Funs
Re: Third party VR / L2 support
Posted by Funs Kessen <fu...@barred.org>.
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 <pa...@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.angus@shapeblue.com
>
> -----Original Message-----
> From: Christian [mailto:christian@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
> <ch...@bt.net>
>
>
>
> On 31/05/2015 05:08, "Sebastien Goasguen" <ru...@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 framework<http://shapeblue.com/csforge/>
> CloudStack Consulting<http://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 license from Shape Blue Ltd. ShapeBlue is a registered trademark.
—
=Funs
Re: Third party VR / L2 support
Posted by Erik Weber <te...@gmail.com>.
Cloudrouter seems to be GPL2-ish.
--
Erik
On Thu, Jun 11, 2015 at 9:03 AM, Keerthiraja SJ <sj...@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 <pa...@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.angus@shapeblue.com
> >
> > -----Original Message-----
> > From: Christian [mailto:christian@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
> > <ch...@bt.net>
> >
> >
> >
> > On 31/05/2015 05:08, "Sebastien Goasguen" <ru...@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 framework<http://shapeblue.com/csforge/>
> > CloudStack Consulting<http://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
> > license from Shape Blue Ltd. ShapeBlue is a registered trademark.
> >
>
Re: Third party VR / L2 support
Posted by Keerthiraja SJ <sj...@gmail.com>.
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 <pa...@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.angus@shapeblue.com
>
> -----Original Message-----
> From: Christian [mailto:christian@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
> <ch...@bt.net>
>
>
>
> On 31/05/2015 05:08, "Sebastien Goasguen" <ru...@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 framework<http://shapeblue.com/csforge/>
> CloudStack Consulting<http://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
> license from Shape Blue Ltd. ShapeBlue is a registered trademark.
>
RE: Third party VR / L2 support
Posted by Paul Angus <pa...@shapeblue.com>.
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.angus@shapeblue.com
-----Original Message-----
From: Christian [mailto:christian@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
<ch...@bt.net>
On 31/05/2015 05:08, "Sebastien Goasguen" <ru...@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 framework<http://shapeblue.com/csforge/>
CloudStack Consulting<http://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 license from Shape Blue Ltd. ShapeBlue is a registered trademark.