Re: Miami CCC '17 Roundtable/Hackathon Summary
Hahaha, yes I know ;) And now you can see why I started that discussion to use a standard to describe applications clusters, instead of an ad-hoc solution. The idea is to kill two rabbits with a single shot (or at least one and a half). On Tue, May 30, 2017 at 2:28 AM, Daan Hoogland wrote: > At the moment I am looking at CAMP, used by Apache Brooklyn, to see if it > makes sense to embed a Brooklyn engine in ACS. There is an extension to > Brooklyn for TOSCA for comparison but I’d like to keep it as simple as > possible and hence use CAMP. (as you know Rafael ;) > > On 29/05/2017, 23:17, "Rafael Weingärtner" > wrote: > > On this idea of Rene to easily provide ways for vendors to integrate > solutions; if we had an endpoint that receives a blueprint for VM(s) > described in some language (let’s say TOSCA) we might be able to > achieve > that without needing to add tons of code to ACS. Appliances could be > described in this language and would be easily introduced into ACS > (pluggable appliances?); then there is the matter of creating > customization > endpoints for the deployed appliance, so administrators can configure > it. > We also would need to improve further the internals of ACS to provide > better extension points for anyone that wants to extend/enhance its > core > features. > > I also agree with everything discussed so far that even if we > modularize > the VR, we need to do so in a transparent way for the > operators/administrators that are already used to the ACS way of doing > cloud. > > On Mon, May 29, 2017 at 8:46 AM, Rene Moser > wrote: > > > Hi > > > > On 05/23/2017 02:16 PM, Simon Weller wrote: > > > > > 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. > > > > Speaking about endless possibilities... ;) > > > > I support the initiative (+1) to make the routing more API driven and > > modular, the issue I see with a "too hard backed" appliance is the > > integration into the existing environment. > > > > One big benefit of the VR is that we can relatively easy customize > it. > > > > I had some thoughts about how to integrate a standardized "custom > > configuration" mechanism to the VR. > > > > I like the idea to have a "user data" or "cloud init" for the VR on > the > > network offerings level. This would allow any virtual appliance > "vendor" > > to implement a simple interface (e.g. static yaml/json data) which > > allows the "cloudstack admin" to customize the virtual appliance in > the > > network offerings API. > > > > E.g. for our VR, the "cloud init" interface would allow > > > > * to install and configure custom monitoring solution > > * configure the automated update mechanism > > * add web hooks to trigger what so ever > > * install and run cfgmgmt like puppet/ansible-pull > > * etc. > > > > So for any virtual appliance the interfaces would be the same but the > > config option would differ based on features they provide. > > > > Regards > > René > > > > > > -- > Rafael Weingärtner > > > > daan.hoogl...@shapeblue.com > www.shapeblue.com > 53 Chandos Place, Covent Garden, London WC2N 4HSUK > @shapeblue > > > > -- Rafael Weingärtner
Re: Miami CCC '17 Roundtable/Hackathon Summary
At the moment I am looking at CAMP, used by Apache Brooklyn, to see if it makes sense to embed a Brooklyn engine in ACS. There is an extension to Brooklyn for TOSCA for comparison but I’d like to keep it as simple as possible and hence use CAMP. (as you know Rafael ;) On 29/05/2017, 23:17, "Rafael Weingärtner" wrote: On this idea of Rene to easily provide ways for vendors to integrate solutions; if we had an endpoint that receives a blueprint for VM(s) described in some language (let’s say TOSCA) we might be able to achieve that without needing to add tons of code to ACS. Appliances could be described in this language and would be easily introduced into ACS (pluggable appliances?); then there is the matter of creating customization endpoints for the deployed appliance, so administrators can configure it. We also would need to improve further the internals of ACS to provide better extension points for anyone that wants to extend/enhance its core features. I also agree with everything discussed so far that even if we modularize the VR, we need to do so in a transparent way for the operators/administrators that are already used to the ACS way of doing cloud. On Mon, May 29, 2017 at 8:46 AM, Rene Moser wrote: > Hi > > On 05/23/2017 02:16 PM, Simon Weller wrote: > > > 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. > > Speaking about endless possibilities... ;) > > I support the initiative (+1) to make the routing more API driven and > modular, the issue I see with a "too hard backed" appliance is the > integration into the existing environment. > > One big benefit of the VR is that we can relatively easy customize it. > > I had some thoughts about how to integrate a standardized "custom > configuration" mechanism to the VR. > > I like the idea to have a "user data" or "cloud init" for the VR on the > network offerings level. This would allow any virtual appliance "vendor" > to implement a simple interface (e.g. static yaml/json data) which > allows the "cloudstack admin" to customize the virtual appliance in the > network offerings API. > > E.g. for our VR, the "cloud init" interface would allow > > * to install and configure custom monitoring solution > * configure the automated update mechanism > * add web hooks to trigger what so ever > * install and run cfgmgmt like puppet/ansible-pull > * etc. > > So for any virtual appliance the interfaces would be the same but the > config option would differ based on features they provide. > > Regards > René > -- Rafael Weingärtner daan.hoogl...@shapeblue.com www.shapeblue.com 53 Chandos Place, Covent Garden, London WC2N 4HSUK @shapeblue
Re: Miami CCC '17 Roundtable/Hackathon Summary
On this idea of Rene to easily provide ways for vendors to integrate solutions; if we had an endpoint that receives a blueprint for VM(s) described in some language (let’s say TOSCA) we might be able to achieve that without needing to add tons of code to ACS. Appliances could be described in this language and would be easily introduced into ACS (pluggable appliances?); then there is the matter of creating customization endpoints for the deployed appliance, so administrators can configure it. We also would need to improve further the internals of ACS to provide better extension points for anyone that wants to extend/enhance its core features. I also agree with everything discussed so far that even if we modularize the VR, we need to do so in a transparent way for the operators/administrators that are already used to the ACS way of doing cloud. On Mon, May 29, 2017 at 8:46 AM, Rene Moser wrote: > Hi > > On 05/23/2017 02:16 PM, Simon Weller wrote: > > > 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. > > Speaking about endless possibilities... ;) > > I support the initiative (+1) to make the routing more API driven and > modular, the issue I see with a "too hard backed" appliance is the > integration into the existing environment. > > One big benefit of the VR is that we can relatively easy customize it. > > I had some thoughts about how to integrate a standardized "custom > configuration" mechanism to the VR. > > I like the idea to have a "user data" or "cloud init" for the VR on the > network offerings level. This would allow any virtual appliance "vendor" > to implement a simple interface (e.g. static yaml/json data) which > allows the "cloudstack admin" to customize the virtual appliance in the > network offerings API. > > E.g. for our VR, the "cloud init" interface would allow > > * to install and configure custom monitoring solution > * configure the automated update mechanism > * add web hooks to trigger what so ever > * install and run cfgmgmt like puppet/ansible-pull > * etc. > > So for any virtual appliance the interfaces would be the same but the > config option would differ based on features they provide. > > Regards > René > -- Rafael Weingärtner
Re: Miami CCC '17 Roundtable/Hackathon Summary
Hi On 05/23/2017 02:16 PM, Simon Weller wrote: > 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. Speaking about endless possibilities... ;) I support the initiative (+1) to make the routing more API driven and modular, the issue I see with a "too hard backed" appliance is the integration into the existing environment. One big benefit of the VR is that we can relatively easy customize it. I had some thoughts about how to integrate a standardized "custom configuration" mechanism to the VR. I like the idea to have a "user data" or "cloud init" for the VR on the network offerings level. This would allow any virtual appliance "vendor" to implement a simple interface (e.g. static yaml/json data) which allows the "cloudstack admin" to customize the virtual appliance in the network offerings API. E.g. for our VR, the "cloud init" interface would allow * to install and configure custom monitoring solution * configure the automated update mechanism * add web hooks to trigger what so ever * install and run cfgmgmt like puppet/ansible-pull * etc. So for any virtual appliance the interfaces would be the same but the config option would differ based on features they provide. Regards René
Re: Miami CCC '17 Roundtable/Hackathon Summary
> 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 > 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
Re: Miami CCC '17 Roundtable/Hackathon Summary
ating 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 [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 c
Re: Miami CCC '17 Roundtable/Hackathon Summary
l 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 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 > > > > > daan.hoogl...@shapeblue.com > www.shapeblue.com > 53 Chandos Place, Covent Garden, London WC2N 4HSUK @shapeblue > > > > -- Rafael Weingärtner
RE: Miami CCC '17 Roundtable/Hackathon Summary
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.an...@shapeblue.com www.shapeblue.com 53 Chandos Place, Covent Garden, London WC2N 4HSUK @shapeblue -Original Message- From: Rafael Weingärtner [mailto:rafaelweingart...@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 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
Re: Miami CCC '17 Roundtable/Hackathon Summary
+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 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, Dur
RE: Miami CCC '17 Roundtable/Hackathon Summary
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 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 a
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 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 > > > > > daan.hoogl...@shapeblue.com > www.shapeblue.com > 53 Chandos Place, Covent Garden, London WC2N 4HSUK > @shapeblue > > > > -- Rafael Weingärtner
Re: Miami CCC '17 Roundtable/Hackathon Summary
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 daan.hoogl...@shapeblue.com www.shapeblue.com 53 Chandos Place, Covent Garden, London WC2N 4HSUK @shapeblue