On Jun 12, 2015, at 11:13 AM, Christian <christ...@bt.net> wrote: > Thank you all for your views and comments. I agree with everything said > when it is positioned under today’s business-as-usual cloud compute. > Perhaps I should put some context around my thoughts. > > NFV is coming and the world is looking to deliver solid cloud networking > solutions over the next couple of years. 90% of what I am hearing in this > area revolves around OpenStack. I’m trying to put the case forward for > using CloudStack. > > Yes, I can use sheer force of will to bend CloudStack into shape. I can > ignore its insistence on using IP addresses for everything and tap > straight into VLANs. I can also use kludges to suppress the virtual router > and remove unwelcome DHCP services. However, I have to declare that I am > doing these things when I present the case for CloudStack and this weakens > my argument. > > There are some quick wins here that would help greatly in positioning > CloudStack as a contender for running virtualised network appliances. > Having a checkbox that flags a virtual network as Layer 2 (no IP > addresses) would be one of them. Officially supporting a ‘No virtual > router’ option within a Network Offering would be another. >
Christian, I totally agree with you. I was on the OPNFV mailing list couple months back and openstack was the only game in town. So how do we get those quick wins going ? Do you have code to make it happen and are looking for guidance to put them in the source ? If you have to code for it, I can show you how to contribute it. Or are you looking for other devs to do it ? A starting point might be to describe those quick wins in a bit more details on the wiki as a Feature request: https://cwiki.apache.org/confluence/display/CLOUDSTACK/Home If you create an account I can give you the writes to create a page. Let's keep this conversation going. thanks, -sebastien > I appreciate that offering third-party virtual routers as an alternative > is not so straightforward, although this seems to be gaining more support > than the ‘quick wins’. Maybe I am underestimating the development effort > involved with the L2 asks? > > Cheers > -Christian > > > On 12/06/2015 05:57, "Koushik Das" <koushik....@citrix.com> wrote: > >> Agree to what Funs mentioned. The current network service model is >> flexible, there is option to select a provider for a given service by >> means of network offering. >> About using 3rd party VR, there are 2 possibilities: >> - Fully replace the existing VR with 3rd party VR >> - Both co-exist and complement each other >> >> CS manages the lifecycle of VR. For 3rd party (especially virtual >> appliances), it needs to be decided what is the best way to manage >> lifecycle. If CS is able to manage the lifecycle then it can be similar >> to existing VR (spinning up instances when required). If managed >> externally, then a pre-created pool of appliances needs to be registered >> from CS and used. >> >> -Koushik >> >> -----Original Message----- >> From: Funs Kessen [mailto:fozzielumpk...@gmail.com] On Behalf Of Funs >> Kessen >> Sent: Tuesday, June 09, 2015 3:26 PM >> To: dev@cloudstack.apache.org >> Subject: Re: Third party VR / L2 support >> >> Hi Christian and Paul, >> >> I agree that the VR/VPC construct could do with some improvements, the >> biggest being that it should actually be api driven and allow for more >> flexible networking/services combined with scale out itself (we’re >> looking into this actually). All of these things bring along their own >> problems and should be tackled piece by piece, if we’d want to be >> efficient we should first blot out the API and then start pushing >> services in, which is difficult at the speed it is moving at. >> >> The driver model in Cloudstack already supports the decoupling of >> services via "network service providers" (plugins) and ties in with the >> way the “network service offerings" work with "service capabilities" and >> "supported services". At SBP we use NSX-mh for the service >> “Connectivity”, we could add “SourceNat”, “StaticNat” and “Port >> Forwarding” to this for NSX if we want to, but decided to leave that in >> the VR back then as these services were rather new in NSX. My point being >> that you can already mix and match things and are not stuck with the >> VR/VPC, and you can actually use devices on that level if need be, if you >> create the service offerings for them. >> At the moment anyone can already create a plugin that exposes a single >> functionality or multiple, and expose that as a service that is offered, >> examples of these are the Palo-Alto, SRX, F5, Netscaler, Cisco VNMC, NSX >> and Nuage. I’m not saying it’s simple or easy, but if you know the API of >> what you want to integrate with you can. >> The construction of the plugin module has its own unique challenges, and >> I agree with John Burwell (Shape Blue) and Paul that we need to change >> the way this all hangs together if we want more flexibility and ease of >> integration in the future. >> >> BGP is brought in for use with IPv6, the first code for that has 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 >> >> > >
