Thank you all for your views and comments. I agree with everything said when it is positioned under today’s business-as-usual cloud compute. Perhaps I should put some context around my thoughts.
NFV is coming and the world is looking to deliver solid cloud networking solutions over the next couple of years. 90% of what I am hearing in this area revolves around OpenStack. I’m trying to put the case forward for using CloudStack. Yes, I can use sheer force of will to bend CloudStack into shape. I can ignore its insistence on using IP addresses for everything and tap straight into VLANs. I can also use kludges to suppress the virtual router and remove unwelcome DHCP services. However, I have to declare that I am doing these things when I present the case for CloudStack and this weakens my argument. There are some quick wins here that would help greatly in positioning CloudStack as a contender for running virtualised network appliances. Having a checkbox that flags a virtual network as Layer 2 (no IP addresses) would be one of them. Officially supporting a ‘No virtual router’ option within a Network Offering would be another. I appreciate that offering third-party virtual routers as an alternative is not so straightforward, although this seems to be gaining more support than the ‘quick wins’. Maybe I am underestimating the development effort involved with the L2 asks? Cheers -Christian On 12/06/2015 05:57, "Koushik Das" <koushik....@citrix.com> wrote: >Agree to what Funs mentioned. The current network service model is >flexible, there is option to select a provider for a given service by >means of network offering. >About using 3rd party VR, there are 2 possibilities: >- Fully replace the existing VR with 3rd party VR >- Both co-exist and complement each other > >CS manages the lifecycle of VR. For 3rd party (especially virtual >appliances), it needs to be decided what is the best way to manage >lifecycle. If CS is able to manage the lifecycle then it can be similar >to existing VR (spinning up instances when required). If managed >externally, then a pre-created pool of appliances needs to be registered >from CS and used. > >-Koushik > >-----Original Message----- >From: Funs Kessen [mailto:fozzielumpk...@gmail.com] On Behalf Of Funs >Kessen >Sent: Tuesday, June 09, 2015 3:26 PM >To: dev@cloudstack.apache.org >Subject: Re: Third party VR / L2 support > >Hi Christian and Paul, > >I agree that the VR/VPC construct could do with some improvements, the >biggest being that it should actually be api driven and allow for more >flexible networking/services combined with scale out itself (we’re >looking into this actually). All of these things bring along their own >problems and should be tackled piece by piece, if we’d want to be >efficient we should first blot out the API and then start pushing >services in, which is difficult at the speed it is moving at. > >The driver model in Cloudstack already supports the decoupling of >services via "network service providers" (plugins) and ties in with the >way the “network service offerings" work with "service capabilities" and >"supported services". At SBP we use NSX-mh for the service >“Connectivity”, we could add “SourceNat”, “StaticNat” and “Port >Forwarding” to this for NSX if we want to, but decided to leave that in >the VR back then as these services were rather new in NSX. My point being >that you can already mix and match things and are not stuck with the >VR/VPC, and you can actually use devices on that level if need be, if you >create the service offerings for them. >At the moment anyone can already create a plugin that exposes a single >functionality or multiple, and expose that as a service that is offered, >examples of these are the Palo-Alto, SRX, F5, Netscaler, Cisco VNMC, NSX >and Nuage. I’m not saying it’s simple or easy, but if you know the API of >what you want to integrate with you can. >The construction of the plugin module has its own unique challenges, and >I agree with John Burwell (Shape Blue) and Paul that we need to change >the way this all hangs together if we want more flexibility and ease of >integration in the future. > >BGP is brought in for use with IPv6, the first code for that has just >gone in from Suresh via Wilder. As that runs on top of Quagga you could >do OSPF with that too. This again leads me to believe we really need to >change the way the RV/VPC receives configuration, I’ve spoken to a big >Cloudstack user, whom also contributes, that wants to be able to do more >with HaProxy, read full configuration freedom, and after hearing this and >bumping my head against it in the past it made perfect sense to me. > >On the topic of L2 networking we’re bridging in and out a lot of networks >at the moment for “Enterprise” production customers. Ranging from legacy >environments to cloud environments or environments where we have full >cloud workloads but also need physical iron due to “regulatory >requirements” or because there is no viable alternative yet (or we >haven’t made a plugin that exposes 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 > >
