cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daan Hoogland <>
Subject Re: Miami CCC '17 Roundtable/Hackathon Summary
Date Thu, 25 May 2017 08:14:09 GMT
Nice write-up Matthew,

In short, I think everybody in the round table (it was actually a big whole between the chairs,
but it was round indeed) agreed with
- the VR functionality should be packaged with cloudstack
- it must be easy to install
- the plugin system needs work
Thank you for your reminder, though. We cannot stress those ground principles enough. A movement
away from our own implementation(s) and leveraging other products as much as we can is the
only thing you could see as a change in philosophy, though that has been going on for quite
a while as well. The idea is that we package those products (as jars) as much as possible,
so the ‘monolithic’ nature of the beast is not compromised more than absolutely possible.
53 Chandos Place, Covent Garden, London  WC2N 4HSUK

On 24/05/2017, 21:48, "Matthew Smart" <> wrote:

    Hey guys,
    I originally chose Cloudstack because I really liked the idea of a 
    monolithic stack and always pick an Apache project over an industry 
    controlled one. I moved on to OpenStack because I could not figure out 
    how to implement some advanced networking capabilities using Cloudstack 
    (and for some stupid reason I did not engage the community to figure it 
    out). The networking architecture I was needing to implement was 
    supposed to be supported by OpenStack so I started working with it. I 
    spent months banging my head against that mess. I would get one module 
    up and running just to find out that another one was failing. I never 
    actually managed to get a stable OpenStack deployment running that I 
    felt I could trust with my production systems.
    So I came back to Cloudstack, talked to the mailing list, and found a 
    workaround for my networking environment and got deployed. Even so, 
    networking, and specifically the VR are the biggest liabilities in my 
    opinion. There are several very important features I am living without 
    right now because they either do not work or are not stable enough for 
    That being said, I am kind of in the middle on the NFV issue. The last 
    thing we should be doing is taking away those elements of Cloudstack 
    that differentiate us, both philosophically and structurally, from the 
    other platforms out there. Cloudstack should always have, as a core 
    feature, the fact that it is monolithic. One installer and a dead simple 
    means of deploying a full stack is absolutely essential for adoption.
    On the other hand, having just put together a networking plugin, I can 
    say that the plugin system needs to be MUCH less ambiguous. I would have 
    had my PR issued months ago (and would not have pestered Will and Syed 
    from Cloudops so relentlessly... poor bastards!) if I had advance 
    information about what data the system was going to send to my plugin 
    for the different networking functions. I kept running into situations 
    where my plugin was receiving the same data structure but with some 
    subset of the data elements coming through as NULL depending on the 
    situation. So I would be relying on having some data that I would 
    receive in some cases but not in others. I essentially had to get ACS to 
    send me commands for each permutation of operation and manually inspect 
    the command's data structures to see what I was being given and then 
    workaround the missing information. Of course, I would get most of the 
    way done and find a corner case that I missed where I did not have the 
    information I needed and that would require that I go back and refactor 
    things to workaround the limitation.
    If the plugin system was better documented though, then integrating with 
    it would be pretty simple. I really think we need to be careful here 
    about throwing out the baby with the bathwater. If we are looking to 
    replace the current plugin system entirely and make it more modular we 
    should first come up with a list of functionalities that are not 
    supported by the current system. If that list is sufficiently large then 
    it makes sense to start over. If not, then I think the entire issue can 
    be addressed by refactoring and documenting the existing plugin system. 
    At the end of the day, we would be doing ourselves, and our entire 
    community, a disservice if we start moving away from ease of 
    implementation. Openstack in my opinion is too modular. Thereby making 
    its architecture and implementation so complex that only a company who 
    specializes in it can efficiently deploy it. It is no surprise that its 
    sponsoring companies sell prepackaged Openstack distros and/or 
    deployment and maintenance services. Obfuscate and profit.
    Having something/s analogous to the current VR in terms of features is a 
    must have for Cloudstack no matter what decision is made.
    Matthew Smart
    Smart Software Solutions Inc.
    108 S Pierre St.
    Pierre, SD 57501
    Phone: (605) 280-0383
    Skype: msmart13
    On 05/24/2017 07:46 AM, David Mabry wrote:
    > Marty, thanks for keeping usability and adoption at the forefront of this conversation.
 I believe it is something that can be easily lost as we get deep in the technical weeds and
it is good to be reminded about what is important beyond how much code it will take to create
feature X.  I also believe that together we can come up with a solution that meets both technical
and ease of implementation requirements.  I think we can make a significant design change
to allow for a new VR, hopefully not one maintained by us, and include new feature like NFV
without forcing undue complexity on users who don’t want or need it.  In the end, for me,
it really comes down to orchestration.  How much can we do for a user “out of the box”?
 I think it is important that we have a “default” option for the VR/Networking that is
easy to implement and fits most SMB use cases.  With that said, I don’t think we can risk
alienating the larger companies that use ACS in a more complex environment.  I think for ACS
to stay relevant and compete against the likes of OpenStack we will need features like NFV
and a VR that is consistent and stable.  Oh and we also need IPv6 (That was for you Wido ;)
    > I agree with Paul that we might want to create a dedicated channel or have weekly
meetings to begin really pushing this major feature forward with the community, sooner rather
than later.  It is easy for us to lose momentum on monumental tasks such as this.
    > In short, one of the great features of ACS is that it provides *choice*.  What is
important, to Marty’s point, is that we don’t lose sight of usability and ease of implementation
when providing that choice for the wide variety of users that we have.
    > Thanks,
    > Dave Mabry
    > Education Networks of America
    > On 5/23/17, 10:29 PM, "Marty Godsey" <> wrote:
    >      Thank you Simon for the re-cap of the hackathon. I was able to catch the last
couple of hours of it but saw the notes on the boards..
    >      I am going to give my thoughts on this coming from a slightly different angle.
As many of you know, I am not a coder. I am an Systems/Network Engineer. I know many times
design decisions are made based upon the amount of time it will require to write a particular
piece of code, update, fix bugs, etc. But the one thing we can't forget is that many ACS users
may not have the ability to add their own plugins, write code to interact with a router, etc.
I know I can't myself, going back to the I'm not a coder, but thankfully I know people that
can and can get it done if need be but the point is many people cannot. As we decide how we
are going to re-write the networking portions of ACS we have to step back and take a look
at what was one of the most talked about topics at this year's CCC. I am not talking about
the networking, IPV6 support or any other cool idea we had. The constant conversation in the
hallways and at the many "Zest" outings was ADOPTION and MARKET AWARENESS.
    >      Adoption.. How do we get the word out and get it adopted by more people? It’s
a tough question but something that also has to influence how we build ACS. Let take a moment
and compare ACS to its closest competitor Openstack. We all know that Openstack has the market
share, it has the money behind it. But what is the constant complaint we hear from people
who use? ""Yea, it works but man,, it was a bi%#h to get going""  Openstack has gotten its
adoption cause it had big names and a lot of money behind it. Openstacks complexity has also
caused it to not be adopted in many cases. Your typical IT shop in a small to medium sized
business does not have the expertise to implement something like this. And when I say SMB
I am saying organizations from 10-500 people.
    >      So back to my adoption question. As mentioned before one of the reasons many
people come to ACS is the fact that it has it all. Networking, hyper-visor management, user
management, storage management, its multi-tenant. What will drive ACS adoption will be improving
what ACS already does, not making it more like OpenStack. Now do I think that having a module
service or plugin service to provide a framework to allow for external resources to be used
by ACS is a good thing? Yes I do. But I also do not want to, and hope we don’t, move away
from what made ACS what it is today. A software that allows companies to easily spin up new
public or private clouds. Adoption-Centric Usability.
    >      If I rambled a little here I apologize, its 11:30pm and sometimes I get ahead
of myself (especially when I write something like this at this hour) when writing about something
I am passionate about and I am passionate about getting more exposure and adoption of ACS.
    >      Thank you for listening guys.. Sorry for the ramble.
    >      Regards,
    >      Marty Godsey
    >      Principal Engineer
    >      nSource Solutions, LLC
    >      -----Original Message-----
    >      From: Rafael Weingärtner []
    >      Sent: Tuesday, May 23, 2017 11:18 AM
    >      To:
    >      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
    >      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
    >      On Tue, May 23, 2017 at 10:18 AM, Daan Hoogland <
    >      > 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" <> 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
    >      >
    >      >
    >      >
    >      >
    >      >
    >      >
    >      > 53 Chandos Place, Covent Garden, London  WC2N 4HSUK @shapeblue
    >      >
    >      >
    >      >
    >      >
    >      --
    >      Rafael Weingärtner

View raw message