cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Simon Weller <swel...@ena.com.INVALID>
Subject Miami CCC '17 Roundtable/Hackathon Summary
Date Tue, 23 May 2017 12:16:30 GMT
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


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message