cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Angus <paul.an...@shapeblue.com>
Subject RE: Miami CCC '17 Roundtable/Hackathon Summary
Date Wed, 24 May 2017 08:08:36 GMT
Rather than trying to re-write my presentation at CCC17 here, have a look at the slides here:
 https://www.slideshare.net/ShapeBlue/ccna17-cloudstack-and-nfv

Before we can separate out the VR into VNFs, we need to be able to connect VNFs together logically
in a useful manner.  A firewall VM will need to pass traffic to a discreet VPN VM and a discreet
loadbalancer.  CloudStack doesn't allow for that kind of plumbing currently. And to be honest,
CloudStack intelligently provisioning and them and configuring them on its own will be no
mean feat either.

I'm a big fan of VyOS - in that I used Vyatta Core quite a bit before it was shutdown by Brocade.
 So I'm going to have a look at that PR.

A 'drop in' replacement for the home-brew VR seems to be the easiest path. 

A guy in my presentation from the incubating Apache Project ARIA TOSCA http://ariatosca.org/about/
 - suggested that we should be looking to TOSCA to provide our 'definitions' and blueprints.
 Which is actually quite a sensible approach.

I think this thread could run for a while yet....

We should probably try to have a dedicated 'channel' or bi-weekly 'conf calls' to make real
progress....


Kind regards,

Paul Angus

paul.angus@shapeblue.com 
www.shapeblue.com
53 Chandos Place, Covent Garden, London  WC2N 4HSUK
@shapeblue
  
 


-----Original Message-----
From: Rafael Weingärtner [mailto:rafaelweingartner@gmail.com] 
Sent: 23 May 2017 16:18
To: dev@cloudstack.apache.org
Subject: Re: Miami CCC '17 Roundtable/Hackathon Summary

I missed the roundtable and hackathon, my bad guys :(

I liked the ideas that you (all) put forward. The VR is interesting and a nice feature to
have, but it causes some pain to maintain in our development cycles. The idea to split the
current VR into NFV is great; this can make things more pluggable and take ACS to NFV (officially).
We could develop a framework in ACS (an API method?) that creates a system VM called NFV where
people (vendors, enthusiast, users and others) can then extend and add their functions/systems
there. The problem is the work required to design and develop such thing.

I use Daan`s words here, this is a community effort and not a single company or individual.
What do you guys think? We could start creating a roadmap of when we want this feature (milestones
for delivering piece by piece of the complete feature), then the draft of a proposal, and
later define the implementation job, so people of the community can embrace it.

On Tue, May 23, 2017 at 10:18 AM, Daan Hoogland <daan.hoogland@shapeblue.com
> wrote:

> Great thanks Simon,
>
> Just want to play bingo a bit; dividing the VR into VNFs (virtual 
> network
> functions) was mentioned. This pertains to the mention of making the 
> VR more modular ;)
>
> Hopefully everybody is inspired by this because no one company or 
> person is going to make this happen.
>
> Dahn
>
> On 23/05/17 14:16, "Simon Weller" <sweller@ena.com.INVALID> wrote:
>
>     Hi everyone,
>
>
>     During the CCC last week in Miami, we held a roundtable/hackathon 
> to discuss some of the major areas the community would like to focus 
> more attention.
>
>
>     The discussions were passionate and were mainly focused around 
> networking and our current use of our home-spun Virtual Router.
>
>
>     For most of the us, the VR has become a challenging beast, mainly 
> due to how difficult it is to end-to-end test for new releases.
>
>     Quite often PRs are pushed that fix an issue on one feature set, 
> but break another unintentionally. This has a great deal to do with 
> how inter-mingled all the features are currently.
>
>
>     We floated some ideas related to short term VR fixes in order to 
> make it more modular, as well as API driven, rather than the currently 
> SSH JSON injections.
>
>     A number of possible alternatives were also brought up to see what 
> VR feature coverage could be handled by other virtual appliances 
> currently out on the market.
>
>
>     These included (but not limited to):
>
>
>     VyOS (current PR out there for integration via a plugin – thanks
> Matthew!)
>
>     Microtek (Commerical)
>
>     Openswitch/Flexswitch
>
>     Cloud Router
>
>
>     The second major topic of the day was related to how we want to 
> integrate networking moving forward.
>
>
>     A fair number of individuals felt that we shouldn't be focusing so 
> much on integrating network functions, but relying on other network 
> orchestrators to hand this.
>
>     It was also noted that what draws a lot of people to ACS is the 
> fact we have a VR and do provide these functions out of the box.
>
>
>     We discussed how we could standardize the network sub system to 
> use some sort of queuing bus to make it easier for others projects to 
> integrate their solutions.
>
>     The current plugin implementation is fairly complex and often 
> other projects (or commercial entities) put it into the too hard 
> basket, until someone either does it themselves or is willing to pay for the development.
>
>     Most also felt it was important to maintain a default network 
> function that works out of the box so that the complexity of a full 
> orchestrator could be avoided if not needed.
>
>
>     I'm sure I've missed some key points, so hopefully this starts a 
> discussion with the entire community of where we focused next.
>
>
>     Thanks to all those that participated on Tuesday afternoon.
>
>
>     - Si
>
>
>
>
> daan.hoogland@shapeblue.com
> www.shapeblue.com
> 53 Chandos Place, Covent Garden, London  WC2N 4HSUK @shapeblue
>
>
>
>


-- 
Rafael Weingärtner
Mime
View raw message