Hi Paul,

We don’t disagree at all, and I think Koushik doesn’t either, we’re just 
talking about different things. Today there are limited options but there are 
ways to work with these options without having to rewrite the plugin model. Yes 
we agree that the plugin model needs to be rewritten, as was discussed in 
London, with emphasis on plugin model and loose coupling.

Cheers,

Funs


> On 12 Jun 2015, at 08:06, Paul Angus <paul.an...@shapeblue.com> wrote:
> 
> Hi Koushik (and Funs),
> 
> It isn't sustainable to keep adding plugins to the core code for 3rd party 
> devices which the community then has to support and maintain and (more 
> importantly) can't test as the vast majority of 'testers' won't have access 
> to the hardware.
> 
> A well implemented driver model allows 3rd parties to create drivers for 
> their device (which can be certified). I'm also talking about being able to 
> drop in VPN appliances, load balancers as well as virtual routing appliances.
> 
> This is a long term goal and needs a load of other pieces of the puzzle as 
> well.  We're working on making the automated testing portable which is a step 
> towards being able to ship a certification DDK.
> 
> Regards,
> 
> Paul Angus
> Cloud Architect
> D: +44 20 3468 5163 |S: +44 20 3603 0540 | M: +44 7711 418 784 | T: 
> @CloudyAngus
> paul.an...@shapeblue.com
> 
> -----Original Message-----
> From: Koushik Das [mailto:koushik....@citrix.com]
> Sent: 12 June 2015 05:57
> To: dev@cloudstack.apache.org
> Subject: RE: Third party VR / L2 support
> 
> Agree to what Funs mentioned. The current network service model is flexible, 
> there is option to select a provider for a given service by means of network 
> offering.
> About using 3rd party VR, there are 2 possibilities:
> - Fully replace the existing VR with 3rd party VR
> - Both co-exist and complement each other
> 
> CS manages the lifecycle of VR. For 3rd party (especially virtual 
> appliances), it needs to be decided what is the best way to manage lifecycle. 
> If CS is able to manage the lifecycle then it can be similar to existing VR 
> (spinning up instances when required). If managed externally, then a 
> pre-created pool of appliances needs to be registered from CS and used.
> 
> -Koushik
> 
> -----Original Message-----
> From: Funs Kessen [mailto:fozzielumpk...@gmail.com] On Behalf Of Funs Kessen
> Sent: Tuesday, June 09, 2015 3:26 PM
> To: dev@cloudstack.apache.org
> Subject: Re: Third party VR / L2 support
> 
> Hi Christian and Paul,
> 
> I agree that the VR/VPC construct could do with some improvements, the 
> biggest being that it should actually be api driven and allow for more 
> flexible networking/services combined with scale out itself (we’re looking 
> into this actually). All of these things bring along their own problems and 
> should be tackled piece by piece, if we’d want to be efficient we should 
> first blot out the API and then start pushing services in, which is difficult 
> at the speed it is moving at.
> 
> The driver model in Cloudstack already supports the decoupling of services 
> via "network service providers" (plugins) and ties in with the way the 
> “network service offerings" work with "service capabilities" and "supported 
> services". At SBP we use NSX-mh for the service “Connectivity”, we could add 
> “SourceNat”, “StaticNat” and “Port Forwarding” to this for NSX if we want to, 
> but decided to leave that in the VR back then as these services were rather 
> new in NSX. My point being that you can already mix and match things and are 
> not stuck with the VR/VPC, and you can actually use devices on that level if 
> need be, if you create the service offerings for them.
> At the moment anyone can already create a plugin that exposes a single 
> functionality or multiple, and expose that as a service that is offered, 
> examples of these are the Palo-Alto, SRX, F5, Netscaler, Cisco VNMC, NSX and 
> Nuage. I’m not saying it’s simple or easy, but if you know the API of what 
> you want to integrate with you can.
> The construction of the plugin module has its own unique challenges, and I 
> agree with John Burwell (Shape Blue) and Paul that we need to change the way 
> this all hangs together if we want more flexibility and ease of integration 
> in the future.
> 
> BGP is brought in for use with IPv6,  the first code for that has just gone 
> in from Suresh via Wilder. As that runs on top of Quagga you could do OSPF 
> with that too. This again leads me to believe we really need to change the 
> way the RV/VPC receives configuration, I’ve spoken to a big Cloudstack user, 
> whom also contributes, that wants to be able to do more with HaProxy, read 
> full configuration freedom, and after hearing this and bumping my head 
> against it in the past it made perfect sense to me.
> 
> On the topic of L2 networking we’re bridging in and out a lot of networks at 
> the moment for “Enterprise” production customers. Ranging from legacy 
> environments to cloud environments or environments where we have full cloud 
> workloads but also need physical iron due to “regulatory requirements” or 
> because there is no viable alternative yet (or we haven’t made a plugin that 
> exposes that functionality from another device/VM/container that can be 
> placed in a service offering etc). I think in our case L2 is not always a 
> requirement for all areas as such and I’d prefer L3 in most cases where 
> viable. We solved things that way, the L2 way, because that was our frame of 
> mind, although it may be a requirement in your case.
> 
> Cheers,
> 
> Funs
> 
>> On 09 Jun 2015, at 10:27, Paul Angus <paul.an...@shapeblue.com> wrote:
>> 
>> Hi Christian,
>> 
>> This is a feature put forward by myself.  As a non-developer I can
>> come up with these things and throw them over the wall to the
>> developers and pretend I don't know how complicated it is :)
>> 
>> In summary, it requires a few other pieces of the roadmap to be in place. 
>> The high level plan is to move ever closer to a driver/plugin model for 
>> CloudStack.  For this feature we need to fully separate the VR plugin code 
>> from the 'core' code and create strong contracts for VR commands/responses.  
>> Then 'anyone' can create and maintain drivers for any type of 
>> router/firewall/vpn endpoint/loadbalancer. The CloudStack community would 
>> then continue to maintain the 'standard' VR/VPC.
>> 
>> We're also developing OSPF capable and a routing-mode VPC offerings
>> which we hope will be in 4.6
>> 
>> I'd be interested to hear how you're using  the L2 devices to see where if 
>> we can fit it in to our 'Enterprise use' enhancements.
>> 
>> Regards,
>> 
>> Paul Angus
>> Cloud Architect
>> D: +44 20 3468 5163 |S: +44 20 3603 0540 | M: +44 7711 418 784 | T:
>> @CloudyAngus paul.an...@shapeblue.com
>> 
>> -----Original Message-----
>> From: Christian [mailto:christ...@bt.net]
>> Sent: 01 June 2015 13:26
>> To: dev@cloudstack.apache.org
>> Subject: Third party VR / L2 support
>> 
>> Hi Sebastien,
>> 
>> Thank you for publishing the roadmap.
>> 
>> 
>>> Replace VR with h/w (srx, asa etc)
>> 
>> 
>> A question for all - What are the implications of expanding this feature to 
>> support s/w appliances, such as the ASA/CSR 1000V ?
>> 
>> 
>> This is something that I have been implementing manually to date because:
>> 
>>> Improve VR, VR agent, API for VR   :)
>> 
>> 
>> 
>> It involves a little bit of 'creative networking' in order to suppress the 
>> CS virtual router. Any improvements in this area would be very useful.
>> Even a QuickCloudNoServices-like offering for isolated networks would be 
>> great. I¹m aware that this can be created manually, but I¹m not convinced 
>> that this is a supported configuration.
>> 
>> 
>> Pushing this concept further, I¹d like to see support for Layer 2 isolated 
>> networks. I use these for running virtual L2 devices under CS simply by 
>> creating dummy IP address ranges and ignoring them. Again, I have to 
>> suppress the VR, because it¹s not needed at L2.
>> 
>> 
>> I¹ve been doing a fair bit to push the limits of networking in CloudStack 
>> over the last year using just VLANs and the standard API calls . I¹m happy 
>> to answer any questions anyone may have.
>> 
>> 
>> Best regards,
>> 
>> -Christian
>> 
>> --
>> Christian Lafferty
>> <christ...@bt.net>
>> 
>> 
>> 
>> On 31/05/2015 05:08, "Sebastien Goasguen" <run...@gmail.com> wrote:
>> 
>>> Hi folks,
>>> 
>>> Several folks on this list representing their company¹s interest
>>> shared with me their fixes/features plans and hopes.
>>> 
>>> I believe we can use this to build a solid roadmap for our project,
>>> something that we have never had.
>>> 
>>> I captured a lot of bullet items and tried to categorize them to
>>> start building a roadmap.
>>> 
>>> You can see the document on our wiki at:
>>> 
>>> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Roadmap
>>> 
>>> I would like to call everyone to make this page a great living
>>> document that will be up to date and help us drive cloudstack forward.
>>> 
>>> First order of business would be to add description to each item and
>>> if you are working on it or would like to help out, write your name down !
>>> 
>>> 
>>> Cheers,
>>> 
>>> 
>>> -Sebastien
>> 
>> 
>> Find out more about ShapeBlue and our range of CloudStack related
>> services
>> 
>> IaaS Cloud Design &
>> Build<http://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

Reply via email to