+1
To find out if it is too complex to be worth doing, try writing the docs
for it and see if system managers can actually read it and tell you how
it works and what it is good for.
If they can not, you can save a lot of coding and make adoption more
likely by not doing it.
On 23/05/2017 11: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 [mailto:rafaelweingart...@gmail.com]
Sent: Tuesday, May 23, 2017 11:18 AM
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.hoogl...@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" <swel...@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.hoogl...@shapeblue.com
www.shapeblue.com
53 Chandos Place, Covent Garden, London WC2N 4HSUK @shapeblue
--
Ron Wheeler
President
Artifact Software Inc
email: rwhee...@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102
