Seems like we need someone to step up and document the process of this. I would offer however I am not a coder so I would not get far.
How is "in charge" of documentation of ACS? Regards, Marty Godsey -----Original Message----- From: Matthew Smart [mailto:msm...@smartsoftwareinc.com] Sent: Thursday, September 22, 2016 2:35 PM To: dev@cloudstack.apache.org Subject: Re: [DISCUSS] Replacing the VR Thanks Will. That is the answer I expected tbh. But it never hurts to ask! Matthew Smart President Smart Software Solutions Inc. 108 S Pierre St. Pierre, SD 57501 Phone: (605) 280-0383 Skype: msmart13 Email: msm...@smartsoftwareinc.com On 09/22/2016 01:24 PM, Will Stevens wrote: > Unfortunately there is not much documentation around the network > plugin functionality. When I wrote the Palo Alto integration I > basically figured out how to do it by reviewing existing plugins and just > figuring it out. > > So if you were to begin to implement a new hardware firewall for > example, I would point you to the Palo Alto integration code [1] and > the functional spec [2] and then make myself available to try to > answer any questions you have (like how the NetworkGuru works, where > the different pieces are registered, etc)... > > Unfortunately it is not trivial, mainly because we don't have any > documentation to follow, but the plugin interface IS there. It just > requires people who have worked it in the past to offer guidance. > > [1] > https://github.com/apache/cloudstack/tree/master/plugins/network-eleme > nts/palo-alto > [2] > https://cwiki.apache.org/confluence/display/CLOUDSTACK/Palo+Alto+Firew > all+Integration > > *Will STEVENS* > Lead Developer > > *CloudOps* *| *Cloud Solutions Experts > 420 rue Guy *|* Montreal *|* Quebec *|* H3J 1S6 w cloudops.com *|* tw > @CloudOps_ > > On Thu, Sep 22, 2016 at 1:53 PM, Matthew Smart > <msm...@smartsoftwareinc.com> > wrote: > >> Hey Murali, >> >> I have been reading through the API and other documentation to try to >> get a basic understanding of the network service offering abstraction >> methodology in CS. I have not dove into the code yet but before I did >> I thought I would try a different approach. >> >> Imagine I were to come to this list and say that I have a network >> offering that I sell and that I wanted to write whatever I needed to >> in order to integrate it as an offering in CloudStack. Is there some >> specific documentation and guidelines you would direct me to read in >> order to gather the knowledge necessary to create a cloudstack >> compatible interface for my product? >> >> I don't know the history but I see several products that have >> navigated this process (Nuage, Nicira, ...etc) and am wondering how a >> new provider would work with you guys to navigate that process. If >> this is too vague, we can pretend my new offering is a hardware firewall >> device. >> >> My goal here is to gain an understanding of how CS interacts with >> third party offerings underneath the hood. I have some thoughts (I >> think inline with Will Steven's brain dump and diagram) but want to >> make sure I am not suffering some misapprehensions about the >> architecture and, short of tracing code, was not successful at >> finding the information I needed to satisfy myself that I know how it is >> designed. >> >> Thanks, >> >> Matthew Smart >> President >> Smart Software Solutions Inc. >> 108 S Pierre St. >> Pierre, SD 57501 >> >> Phone: (605) 280-0383 >> Skype: msmart13 >> Email: msm...@smartsoftwareinc.com >> >> On 09/20/2016 04:54 AM, Murali Reddy wrote: >> >>> Configuration management of network appliances particularly for >>> Cloud and NFV scenarios is still evolving area. Programmability is >>> the not the strength for even the most popular network operating >>> systems like IOS, JunoS etc. So its not surprising why CloudStack >>> integrates in a archaic way with stock linux for the VR. >>> >>> VR was never integral/hardcoded option in CloudStack. Its always >>> been a plugin. CloudStack network orchestration is well abstracted >>> and designed with vision to compose a network with different set of >>> providers for different services. Yes that vision is not fully >>> realised yet, and we don’t have true service function chains. That would be >>> different discussion topic. >>> >>> I tend to agree with Simon, as alternate/interim option we can take >>> hard look whats causing the problems with current VR integration. >>> Personally, I think it would be easier we take a cue from >>> configuration managers and network configuration solutions out there >>> (for e.g promise theory based Cisco ACI) move to more declarative >>> model of expressing desired state of network configuration. Infact >>> current VR from 4.6, actually holds the desired state per service basis, >>> seems to be in that direction. >>> >>> It does make sense to evaluate new appliances which can provide rich >>> semantics (like programmable API, declarative configuration, >>> versioning, commit/rollback etc), but will need significant >>> engineering effort and time to stabilise. We may make same mistakes >>> with integration of other appliance as well, if we fully don’t >>> understand the nature of the current problems with CloudStack core >>> and service provider interaction and current VR integration. >>> >>> >>> On 16/09/16, 11:59 PM, "Simon Weller" <swel...@ena.com> wrote: >>> >>> I think our other option is to take a real look at what it would >>> take to >>>> fix the VR. In my opinion, a lot of the problems are related to the >>>> monolithic python code base and the fact nothing is actually separated. >>>> >>>> Secondly, the python scripts (and bash scripts) don't use any >>>> established libraries to complete tasks and instead shell out and >>>> run commands that are both hard to track and hard to parse on return. >>>> >>>> >>>> If we daemonized this, used a real api for Agent to VR >>>> communication, used common already existing libraries for the >>>> system service and network interactions and spent a bit of time >>>> separating out code into distinct modules, everything would behave a lot >>>> better. >>>> >>>> >>>> The pain and suffering is due to years and years of patches and >>>> constant shelling out to complete tasks in my opinion. If we spend >>>> time to rethink how we interact with the VR in general and we >>>> abstract the systems and networking stuff and use well known and >>>> stable libraries to do the work, the VR would be much easier to maintain. >>>> >>>> >>>> - Si >>>> >>>> >>>> >>>> >>>> ________________________________ >>>> From: Marty Godsey <ma...@gonsource.com> >>>> Sent: Friday, September 16, 2016 12:24 PM >>>> To: dev@cloudstack.apache.org >>>> Subject: RE: [DISCUSS] Replacing the VR >>>> >>>> So based upon this discussion would it be prudent to wait on VyOS 2.0? >>>> The current VR is giving us issues but would the time invested in >>>> another "solution" be wasted especially if by the time another >>>> option is chose, then coded, then tested, then implemented and >>>> right as that time happened to be when VyOS 2.0 is released. Of >>>> course you said they are just in the scoping range so this could still be >>>> a year or more out. >>>> >>>> Thoughts? >>>> >>>> Regards, >>>> Marty Godsey >>>> nSource Solutions >>>> >>>> -----Original Message----- >>>> From: williamstev...@gmail.com [mailto:williamstev...@gmail.com] On >>>> Behalf Of Will Stevens >>>> Sent: Friday, September 16, 2016 10:31 AM >>>> To: dev@cloudstack.apache.org >>>> Cc: dan...@baturin.org >>>> Subject: Re: [DISCUSS] Replacing the VR >>>> >>>> I just had a quick chat with a couple of the guys over on the VyOS chat. >>>> I have CC'ed one of them in case we have more licensing questions. >>>> >>>> So here is the status with the license "the code inherited from >>>> Vyatta and our modifications from it is GPLv2 (strict, not v2+). >>>> The config reading library is GPLv2 too, so anything that links to is is >>>> GPLv2. >>>> Some auxiliary components we made after the fork are more >>>> permissive, >>>> LGPLv2+ or MIT." >>>> >>>> They are currently in the process of scoping a redesign (VyOS 2.0), >>>> "we are planning a clean rewrite that will solve issues of the >>>> current config system". >>>> This will include the ability to configure via the API. >>>> >>>> If we have more questions for VyOS, they are very friendly and >>>> responsive, so we should be able to get answers. >>>> >>>> *Will STEVENS* >>>> Lead Developer >>>> >>>> *CloudOps* *| *Cloud Solutions Experts >>>> 420 rue Guy *|* Montreal *|* Quebec *|* H3J 1S6 w cloudops.com *|* >>>> tw @CloudOps_ >>>> >>>> On Fri, Sep 16, 2016 at 9:37 AM, Syed Ahmed <sah...@cloudops.com> wrote: >>>> >>>> I agree with Will Ilya. There are so many problems with the VR right now. >>>>> Most of the outages we've had recently have somehow involved the VR. >>>>> We set custom iptables rules on the VR which can and have easily >>>>> gone wrong. >>>>> Openswan is broken, Strongswan replacement still needs to be tested. >>>>> VVRP with redundant router still needs work, and not to mention >>>>> the problems we will have when we introduce IPv6 into the whole picture. >>>>> >>>>> I think the spirit of the discussion is to rely on a 3rd party to >>>>> do the networking for us (eg VyOS) and have us handle just the >>>>> orchestration. All the problems that I've described have already >>>>> been solved in VyOS. We also get the advantage of a potential >>>>> wider community to fix and maintain the VR and given our current >>>>> development velocity, it think it totally makes sense to look for >>>>> a 3rd party option. >>>>> >>>>> -Syed >>>>> >>>>> >>>>> On Fri, Sep 16, 2016 at 9:18 AM, Will Stevens >>>>> <wstev...@cloudops.com> >>>>> wrote: >>>>> >>>>> The VR has been biting us far too often recently, which is why we >>>>>> have started looking into alternative implementations. >>>>>> >>>>>> One of the things that is nice about potentially using the VyOS >>>>>> is that >>>>>> >>>>> it >>>>> >>>>>> is based on Debian, so we should be able to run the other >>>>>> services that >>>>>> >>>>> we >>>>> >>>>>> currently have like the password server and userdata on the VyOS. >>>>>> This means we would not have to change our architecture initially >>>>>> and could focus on only replacing the networking paths. >>>>>> >>>>>> *Will STEVENS* >>>>>> Lead Developer >>>>>> >>>>>> *CloudOps* *| *Cloud Solutions Experts >>>>>> 420 rue Guy *|* Montreal *|* Quebec *|* H3J 1S6 w cloudops.com >>>>>> *|* tw @CloudOps_ >>>>>> >>>>>> On Fri, Sep 16, 2016 at 6:20 AM, Nux! <n...@li.nux.ro> wrote: >>>>>> >>>>>> The more this is discussed the more I think we should stick with >>>>>>> our >>>>>>> >>>>>> VR. >>>>>> All these other options either seem unfinished or with >>>>>>> incompatible license. >>>>>>> >>>>>>> VyOS looks the most promising so far, it's a serious, mature project. >>>>>>> Adopting it though means we'll have to microservice our way out >>>>>>> of it >>>>>>> >>>>>> with >>>>>> >>>>>>> extra machines for DNS/USERDATA/etc, unless we can make VyOS >>>>>>> serve >>>>>>> >>>>>> those >>>>>> too. Imho this adds complexity we should void. >>>>>>> -- >>>>>>> Sent from the Delta quadrant using Borg technology! >>>>>>> >>>>>>> Nux! >>>>>>> www.nux.ro >>>>>>> >>>>>>> ----- Original Message ----- >>>>>>> >>>>>>>> From: "Will Stevens" <wstev...@cloudops.com> >>>>>>>> To: dev@cloudstack.apache.org >>>>>>>> Sent: Thursday, 15 September, 2016 17:21:28 >>>>>>>> Subject: Re: [DISCUSS] Replacing the VR Ya, we would need to >>>>>>>> add a daemon for VPN as well. Load balancing is another aspect >>>>>>>> which we will need to consider if we went this route. >>>>>>>> Something like https://traefik.io/ could potentially be a good >>>>>>>> fit >>>>>>>> >>>>>>> due >>>>>> to >>>>>>>> its API driven configuration, but it may be more than what we need. >>>>>>>> >>>>>>>> We should probably try define which pieces make sense to be >>>>>>>> solved >>>>>>>> >>>>>>> together >>>>>>> >>>>>>>> and which pieces would be best suited to be broken out. >>>>>>>> >>>>>>>> I think the network connectivity, routing and firewalling >>>>>>>> should >>>>>>>> >>>>>>> probably >>>>>>> all stay together since the majority of the tools we would >>>>>>> potentially >>>>>> use >>>>>>>> would handle all of that together in a single implementation. >>>>>>>> >>>>>>>> The password server and userdata seems like a good option for >>>>>>>> being >>>>>>>> >>>>>>> broken >>>>>>> >>>>>>>> out and handled independently (and probably rewritten >>>>>>>> completely >>>>>>>> >>>>>>> since >>>>>> they >>>>>>>> currently have some issues). >>>>>>>> >>>>>>>> Load balancing is another that could warrant splitting out, but >>>>>>>> that depends on what direction we go and how we would be managing it. >>>>>>>> >>>>>>> DHCP >>>>>> and >>>>>>>> DNS are others which could go either way. >>>>>>>> >>>>>>>> If we do split out services, I think we should consolidate as >>>>>>>> much as >>>>>>>> >>>>>>> we >>>>>>> can into each service we break out. Ideally a network packet >>>>>>>> would >>>>>>>> >>>>>>> never >>>>>>> hit more than one, maybe two, services. I don't think we should >>>>>>>> be splitting services 'just because', I think we need a valid >>>>>>>> case for splitting any service out because it adds complexity. >>>>>>>> Our project is already complex enough, we need to avoid adding >>>>>>>> complexity unless it >>>>>>>> >>>>>>> is >>>>>> really needed. >>>>>>>> Some more of my thoughts on this anyway... >>>>>>>> >>>>>>>> *Will STEVENS* >>>>>>>> Lead Developer >>>>>>>> >>>>>>>> *CloudOps* *| *Cloud Solutions Experts >>>>>>>> 420 rue Guy *|* Montreal *|* Quebec *|* H3J 1S6 w cloudops.com >>>>>>>> *|* tw @CloudOps_ >>>>>>>> >>>>>>>> On Thu, Sep 15, 2016 at 10:28 AM, Simon Weller >>>>>>>> <swel...@ena.com> >>>>>>>> >>>>>>> wrote: >>>>>>> I do agree with you that this probably isn't the right place >>>>>>>>> the >>>>>>>>> >>>>>>>> password >>>>>>>> service and user data. >>>>>>>>> >>>>>>>>> Having said that, after taking a cursory look at the dev docs, >>>>>>>>> it >>>>>>>>> >>>>>>>> doesn't >>>>>>>> seem that difficult to add new daemons: >>>>>>>> https://opensnaproute.github. >>>>>> io/docs/developer.html#creating-new-component >>>>>>>>> <https://opensnaproute.github.io/docs/developer.html# >>>>>>>>> creating-new-component> >>>>>>>>> >>>>>>>>> >>>>>>>>> They've definitely build it with a microservices architecture >>>>>>>>> in >>>>>>>>> >>>>>>>> mind, >>>>>> so >>>>>>>> each individual feature is abstracted into it's own small >>>>>>>>> daemon >>>>>>>>> >>>>>>>> process. >>>>>>>> We could just create a daemon for the password server and the >>>>>>>> userdata >>>>>> components if we really had to. >>>>>>>>> >>>>>>>>> - Si >>>>>>>>> >>>>>>>>> >>>>>>>>> ________________________________ >>>>>>>>> From: williamstev...@gmail.com <williamstev...@gmail.com> on >>>>>>>>> behalf >>>>>>>>> >>>>>>>> of >>>>>>> Will Stevens <wstev...@cloudops.com> >>>>>>>>> Sent: Thursday, September 15, 2016 9:17 AM >>>>>>>>> To: dev@cloudstack.apache.org >>>>>>>>> Subject: Re: [DISCUSS] Replacing the VR >>>>>>>>> >>>>>>>>> A big part of why I know about it is because it is written in Go. >>>>>>>>> >>>>>>>> :P >>>>>> Yes, it is definitely interesting for the routing and traffic >>>>>>>> handling >>>>>> aspects of the VR. We will likely have to rethink some of the >>>>>>>> pieces >>>>>> a >>>>>> >>>>>>> little bit like the password server and userdata if we are to >>>>>>>>> adopt >>>>>>>>> >>>>>>>> a >>>>>> different VR approach. This is where I think some of JohnB and >>>>>>>> Chiradeep's >>>>>>>> ideas make sense. In many ways, it does not make sense for the >>>>>>>> device >>>>>> handling routing and network traffic to also be responsible for >>>>>>>> passwords >>>>>>>> and userdata. >>>>>>>>> *Will STEVENS* >>>>>>>>> Lead Developer >>>>>>>>> >>>>>>>>> *CloudOps* *| *Cloud Solutions Experts >>>>>>>>> 420 rue Guy *|* Montreal *|* Quebec *|* H3J 1S6 w cloudops.com >>>>>>>>> *|* tw @CloudOps_ >>>>>>>>> >>>>>>>>> On Thu, Sep 15, 2016 at 9:10 AM, Simon Weller >>>>>>>>> <swel...@ena.com> >>>>>>>>> >>>>>>>> wrote: >>>>>>> I hadn't heard of Flexswitch until you mentioned it. It looks >>>>>>>>> pretty >>>>>> cool! >>>>>>>>>> It even supports ONIE install. >>>>>>>>>> >>>>>>>>>> To be honest, the ipsec feature could be added, or we could >>>>>>>>>> >>>>>>>>> offload >>>>>> it to >>>>>>>> separate vm if we needed to. The fact it is so feature rich >>>>>>>>>> from a >>>>>>>>>> >>>>>>>>> routing >>>>>>>>> >>>>>>>>>> perspective (and all API driven) is really nice. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Based on the roadmap, it looks like they plan to also support >>>>>>>>>> >>>>>>>>> capabilities >>>>>>>>> >>>>>>>>>> such as BGP-MPLS based L3VPN, EVPN, VPLS in the future. This >>>>>>>>>> will >>>>>>>>>> >>>>>>>>> be >>>>>> huge >>>>>>>> for our carrier community that rely on these technologies to >>>>>>>>>> do >>>>>>>>>> >>>>>>>>> private >>>>>>>> gateway and inter-VPC interconnections today. We handle this >>>>>>>>>> stuff >>>>>>>>>> >>>>>>>>> on >>>>>>> our >>>>>>> >>>>>>>> ASRs right now with a vlan interconnect into the VR. Being >>>>>>>>>> able to >>>>>>>>>> >>>>>>>>> do >>>>>>> MPLS >>>>>>>>>> all the way to the VR would be awesome. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> It also seems to be written in GO (a language here at ENA we >>>>>>>>>> know >>>>>>>>>> >>>>>>>>> very >>>>>>> well). >>>>>>>>>> >>>>>>>>>> - Si >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> ________________________________ >>>>>>>>>> From: Will Stevens <williamstev...@gmail.com> >>>>>>>>>> Sent: Thursday, September 15, 2016 7:06 AM >>>>>>>>>> To: dev@cloudstack.apache.org >>>>>>>>>> Subject: RE: [DISCUSS] Replacing the VR >>>>>>>>>> >>>>>>>>>> Ya. I don't think it covers our whole use case, but what it >>>>>>>>>> does >>>>>>>>>> >>>>>>>>> cover is >>>>>>>> all api driven... >>>>>>>>>> On Sep 15, 2016 1:48 AM, "Marty Godsey" <ma...@gonsource.com> >>>>>>>>>> >>>>>>>>> wrote: >>>>>>> Though I don’t see VPN in Snaproute.. Makes sense since it >>>>>>>>>>> was >>>>>>>>>>> >>>>>>>>>> not >>>>>> intended to do IPSec. >>>>>>>>>>> It seems as though VyOS is starting to look like the best >>>>>>>>>>> >>>>>>>>>> option. >>>>>> Regards, >>>>>>>>>>> Marty Godsey >>>>>>>>>>> nSource Solutions >>>>>>>>>>> >>>>>>>>>>> -----Original Message----- >>>>>>>>>>> From: williamstev...@gmail.com >>>>>>>>>>> [mailto:williamstev...@gmail.com >>>>>>>>>>> >>>>>>>>>> ] >>>>>> On >>>>>> >>>>>>> Behalf Of Will Stevens >>>>>>>>>>> Sent: Wednesday, September 14, 2016 11:06 PM >>>>>>>>>>> To: dev@cloudstack.apache.org >>>>>>>>>>> Subject: Re: [DISCUSS] Replacing the VR >>>>>>>>>>> >>>>>>>>>>> Or we could go completely crazy and go with something like >>>>>>>>>>> >>>>>>>>>> FlexSwitch >>>>>>>> from >>>>>>>>>>> SnapRoute >>>>>>>>>>> - http://www.snaproute.com/ >>>>>>>>>>> - https://opensnaproute.github.io/docs/apis.html >>>>>>>>>>> >>>>>>>>>>> *Will STEVENS* >>>>>>>>>>> Lead Developer >>>>>>>>>>> >>>>>>>>>>> *CloudOps* *| *Cloud Solutions Experts >>>>>>>>>>> 420 rue Guy *|* Montreal *|* Quebec *|* H3J 1S6 w >>>>>>>>>>> cloudops.com >>>>>>>>>>> >>>>>>>>>> *|* >>>>>>> tw >>>>>>> >>>>>>>> @CloudOps_ >>>>>>>>>>> On Wed, Sep 14, 2016 at 10:55 PM, Will Stevens < >>>>>>>>>>> >>>>>>>>>> wstev...@cloudops.com> >>>>>>>> wrote: >>>>>>>>>>> I tend to agree with Syed and Marty. I am not sure what >>>>>>>>>>> problems >>>>>>> are >>>>>>> >>>>>>>> solved by splitting up the function of the VR into a >>>>>>>>>>>> bunch of >>>>>>>>>>>> >>>>>>>>>>> separate >>>>>>>>>> services. As Syed points out, the complexity added is >>>>>>>>>>> non-trivial. >>>>>>>> We now have to manage all the intercontainer networking >>>>>>>>>>>> as >>>>>>>>>>>> >>>>>>>>>>> well >>>>>> as >>>>>> >>>>>>> the >>>>>>>>>> orchestrated ACS networking. >>>>>>>>>>>> VyOS is interesting to me because it covers the majority of >>>>>>>>>>>> >>>>>>>>>>> our >>>>>> use >>>>>>>> case with a single unified control plane. It also has >>>>>>>>>>>> good >>>>>>>>>>>> >>>>>>>>>>> support >>>>>>>> for extending features we care about, like IPv6, VXLAN, >>>>>>>>>>>> VRRP, transactions, etc... >>>>>>>>>>>> >>>>>>>>>>>> *Will STEVENS* >>>>>>>>>>>> Lead Developer >>>>>>>>>>>> >>>>>>>>>>>> *CloudOps* *| *Cloud Solutions Experts >>>>>>>>>>>> 420 rue Guy *|* Montreal *|* Quebec *|* H3J 1S6 w >>>>>>>>>>>> >>>>>>>>>>> cloudops.com >>>>>> *|* >>>>>>>> tw >>>>>>>>>> @CloudOps_ >>>>>>>>>>>> On Wed, Sep 14, 2016 at 9:49 PM, Syed Ahmed < >>>>>>>>>>>> >>>>>>>>>>> sah...@cloudops.com> >>>>>>> wrote: >>>>>>>>>>> Agree with Marty, adding Docker containers to the >>>>>>>>>>>>> picture >>>>>>>>>>>>> >>>>>>>>>>>> although >>>>>>>> can make the VR more flexible but the added complexity >>>>>>>>>>>>> is >>>>>>>>>>>>> >>>>>>>>>>>> just >>>>>> not >>>>>>>> worth it. Not to mention we would need to take care of >>>>>>>>>>>> networking >>>>>>> each container manually and given that our iptable rules >>>>>>>>>>>>> are >>>>>>>>>>>>> >>>>>>>>>>>> very >>>>>>> unstable at the moment I don't see a big value add. >>>>>>>>>>>>> Vyos looks like a better solution to me. I know that it >>>>>>>>>>>>> does >>>>>>>>>>>>> >>>>>>>>>>>> not >>>>>>> provide an api but it does fit the bill quite well >>>>>>>>>>>> otherwise. I >>>>>> specially like the fact that it has a transaction based >>>>>>>>>>>>> model >>>>>>>>>>>>> >>>>>>>>>>>> and >>>>>>> you >>>>>>>>>> can rollback changes if something goes wrong. >>>>>>>>>>>>> On Wed, Sep 14, 2016 at 9:06 PM Marty Godsey < >>>>>>>>>>>>> >>>>>>>>>>>> ma...@gonsource.com> >>>>>>>> wrote: >>>>>>>>>>>> Licensing aside, I think splitting the various >>>>>>>>>>>>>> functions >>>>>>>>>>>>>> >>>>>>>>>>>>> into >>>>>> containers is not a good route either. This will force >>>>>>>>>>>>> users >>>>>> to >>>>>> >>>>>>> have to maintain >>>>>>>>>>>>> and >>>>>>>>>>>>> >>>>>>>>>>>>>> use containers and adds complexity to the networking >>>>>>>>>>>>>> >>>>>>>>>>>>> aspects >>>>>> of >>>>>> >>>>>>> ACS. >>>>>>>>>> Complexity decreases stability. Now I understand the >>>>>>>>>>>>> argument >>>>>> that >>>>>>>> a monolithic approach also brings its own set of >>>>>>>>>>>>>> issues but >>>>>>>>>>>>>> >>>>>>>>>>>>> it >>>>>>> also >>>>>>>>>> simplifies it. >>>>>>>>>>>>>> Regards, >>>>>>>>>>>>>> Marty Godsey >>>>>>>>>>>>>> nSource Solutions >>>>>>>>>>>>>> >>>>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>>>> From: Chiradeep Vittal [mailto:chirade...@gmail.com] >>>>>>>>>>>>>> Sent: Wednesday, September 14, 2016 5:37 PM >>>>>>>>>>>>>> To: dev@cloudstack.apache.org >>>>>>>>>>>>>> Subject: Re: [DISCUSS] Replacing the VR >>>>>>>>>>>>>> >>>>>>>>>>>>>> I rather doubt that the Cloudrouter will fit the needs of >>>>>>>>>>>>>> >>>>>>>>>>>>> the >>>>>> CloudStack project >>>>>>>>>>>>>> - it is AGPL licensed. Many enterprises will not touch >>>>>>>>>>>>>> >>>>>>>>>>>>> anything >>>>>>>> that >>>>>>>>>>>>> has >>>>>>>>>>>>> >>>>>>>>>>>>>> AGPL >>>>>>>>>>>>>> - the github repo shows rather infrequent updates. >>>>>>>>>>>>>> Quite >>>>>>>>>>>>>> >>>>>>>>>>>>> likely >>>>>>>> they aren't considering the use cases of the >>>>>>>>>>>>>> CloudStack >>>>>>>>>>>>>> >>>>>>>>>>>>> community >>>>>>>> I'd back John B's comments on disaggregating the VR. >>>>>>>>>>>>>> Split >>>>>>>>>>>>>> >>>>>>>>>>>>> it >>>>>> into >>>>>>>> many docker containers >>>>>>>>>>>>>> - password server >>>>>>>>>>>>>> - userdata server >>>>>>>>>>>>>> - DHCP / DNS >>>>>>>>>>>>>> - s2s VPN >>>>>>>>>>>>>> - RA VPN >>>>>>>>>>>>>> - intra-VPC routing and ACL >>>>>>>>>>>>>> - Port forwarding + NAT >>>>>>>>>>>>>> - FW >>>>>>>>>>>>>> - LB (public) >>>>>>>>>>>>>> - LB (internal), >>>>>>>>>>>>>> - secondary storage >>>>>>>>>>>>>> - agent >>>>>>>>>>>>>> Glue them together with docker compose files (one per >>>>>>>>>>>>>> use >>>>>>>>>>>>>> >>>>>>>>>>>>> case - >>>>>>>> basic zone, isolated, VPC, SSVM, etc). >>>>>>>>>>>>>> The VR image then becomes a JeOS + docker. You can test >>>>>>>>>>>>>> >>>>>>>>>>>>> each >>>>>> of >>>>>> >>>>>>> the >>>>>>>>>> components independently and fixing one bug in the >>>>>>>>>>>>>> field >>>>>>>>>>>>>> >>>>>>>>>>>>> (say >>>>>> DHCP) >>>>>>>>>> is hitless to the other components. You don't need to >>>>>>>>>>>>>> build per-hypervisor VRs. You could even run on baremetal. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Along the way you need to figure out how to >>>>>>>>>>>>>> - make the traffic traverse the containers that are >>>>>>>>>>>>>> needed >>>>>>>>>>>>>> >>>>>>>>>>>>> to >>>>>>> be >>>>>>> >>>>>>>> traversed (in most cases just 1) >>>>>>>>>>>>>> - bootstrap the router (how does it find its compose file? >>>>>>>>>>>>>> >>>>>>>>>>>>> where >>>>>>>> is the >>>>>>>>>>>>>> registry?) >>>>>>>>>>>>>> - rethink the command and control of the VR functions. >>>>>>>>>>>>>> SSH >>>>>>>>>>>>>> >>>>>>>>>>>>> works, >>>>>>>> but something more declarative, idempotent should be >>>>>>>>>>>>> explored. >>>>>>> As you do this, it becomes clearer which of the >>>>>>>>>>>>>> functions >>>>>>>>>>>>>> >>>>>>>>>>>>> can >>>>>> be >>>>>>>> substituted by for example CloudRouter. Command and >>>>>>>>>>>>>> Control >>>>>>>>>>>>>> >>>>>>>>>>>>> of >>>>>>> the >>>>>>> >>>>>>>> docker >>>>>>>>>>>>>> containers can be moved out to another container. Etc. >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> On Wed, Sep 14, 2016 at 12:59 AM, Marty Godsey >>>>>>>>>>>>>> <ma...@gonsource.com> >>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>> This one does look nice. My biggest concern is the >>>>>>>>>>>>>>> lack >>>>>>>>>>>>>>> >>>>>>>>>>>>>> of >>>>>> VXLANs. It seems that any of the ones we mentioned >>>>>>>>>>>>>>> do not >>>>>>>>>>>>>>> >>>>>>>>>>>>>> have >>>>>>>> an >>>>>>>>>> API so we may be stuck at the SSH method. >>>>>>>>>>>>>>> Regards, >>>>>>>>>>>>>>> Marty Godsey >>>>>>>>>>>>>>> nSource Solutions >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>>>>> From: Abhinandan Prateek >>>>>>>>>>>>>>> [mailto:abhinandan.prat...@shapeblue.com] >>>>>>>>>>>>>>> Sent: Wednesday, September 14, 2016 2:26 AM >>>>>>>>>>>>>>> To: dev@cloudstack.apache.org >>>>>>>>>>>>>>> Subject: Re: [DISCUSS] Replacing the VR >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Cloudrouter looks promising. These have potential to >>>>>>>>>>>>>>> save >>>>>>>>>>>>>>> >>>>>>>>>>>>>> future >>>>>>>> engineering effort for example on ipv6 routing, OSPF etc. >>>>>>>>>>>>>>> And the best part is they come with test automation >>>>>>>>>>>>>>> >>>>>>>>>>>>>> framework. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On 13/09/16, 4:22 PM, "Jayapal Uradi" >>>>>>>>>>>>>>> <jayapal.ur...@accelerite.com> >>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Hi, >>>>>>>>>>>>>>>> Instead of replacing the VR in first place we should >>>>>>>>>>>>>>>> add VyOS/cloudrouter >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> as provider. Once it is stable, network offerings (on >>>>>>>>>>>>>>> >>>>>>>>>>>>>> upgrade) >>>>>>>> can be updated to use it and we can drop the VR if >>>>>>>>>>>>>>> we >>>>>>>>>>>>>>> >>>>>>>>>>>>>> want >>>>>> at >>>>>> >>>>>>> that release >>>>>>>>>>>>>> onwards. >>>>>>>>>>>>>> >>>>>>>>>>>>>>> VR is stabilized over a period of time and some of >>>>>>>>>>>>>>>> them >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> are >>>>>>> running >>>>>>>>>>>>>>> without issues. When we replicate the ACS VR features >>>>>>>>>>>>>>> in >>>>>>>>>>>>>>> >>>>>>>>>>>>>> new >>>>>>> solution it takes some to find the missing pieces >>>>>>>>>>>>>>> (hidden >>>>>>>>>>>>>>> >>>>>>>>>>>>>> bugs). >>>>>>>> Thanks, >>>>>>>>>>>>>>>> Jayapal >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On Sep 13, 2016, at 2:52 PM, Nux! < >>>>>>>>>>>>>>>>> n...@li.nux.ro> wrote: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Hi, >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> I like the idea. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Cloudrouter looks really promising, I'm not too keen >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> on >>>>>> VyOS >>>>>>>> (it >>>>>>>>>>>>>>>> doesn't have a proper http api etc). >>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>>> Sent from the Delta quadrant using Borg technology! >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Nux! >>>>>>>>>>>>>>>>> www.nux.ro >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> abhinandan.prat...@shapeblue.com >>>>>>>>>>>>>>> www.shapeblue.com<http://www.shapeblue.com> >>>>>>>>>>>>>>> 53 Chandos Place, Covent Garden, London WC2N 4HSUK >>>>>>>>>>>>>>> >>>>>>>>>>>>>> @shapeblue >>>>>>>>>>>>>>> ----- Original Message ----- >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> From: "Will Stevens" <williamstev...@gmail.com> >>>>>>>>>>>>>>>>>> To: dev@cloudstack.apache.org >>>>>>>>>>>>>>>>>> Sent: Monday, 12 September, 2016 21:20:11 >>>>>>>>>>>>>>>>>> Subject: [DISCUSS] Replacing the VR >>>>>>>>>>>>>>>>>> *Disclaimer:* This is a thought experiment and should >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> be >>>>>>> treated as >>>>>>>>>>>>>>>>> such. >>>>>>>>>>>>>>>> Please weigh in with the good and bad of this idea... >>>>>>>>>>>>>>>>>> A couple of us have been discussing the idea of >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> potentially >>>>>>>> replacing the ACS VR with the VyOS [1] (Open >>>>>>>>>>>>>>>>>> Source >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Vyatta >>>>>>>> VM). >>>>>>>>>>> There may be a license issue because I think it >>>>>>>>>>>>>>>>>> is >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> licensed >>>>>>>> under GPL, but for the sake of discussion, let's >>>>>>>>>>>>>>>>> assume >>>>>> we >>>>>>>> can overcome any >>>>>>>>>>>>>>>>> license issues. >>>>>>>>>>>>>>>> I have spent some time recently with the VyOS >>>>>>>>>>>>>>>>>> and I >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> have >>>>>>> to >>>>>>> >>>>>>>> admit, I was pretty impressed. It is simple and >>>>>>>>>>>>>>>>> intuitive >>>>>>>> and it gives you a lot more options for auditing >>>>>>>>>>>>>>>>>> the >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> configuration etc... >>>>>>>>>>>> Items of potential interest: >>>>>>>>>>>>>>>>>> - Clean up our current VR script spaghetti to a >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> simpler >>>>>> more >>>>>>>> auditable configuration workflow. >>>>>>>>>>>>>>>>>> - Gives a cleaner path for IPv6 support. >>>>>>>>>>>>>>>>>> - Handles VPN configuration via the same >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> configuration >>>>>> interface. >>>>>>>>>>
