Honestly, this looks interesting. I have never used it myself but it "reads" very much like what we are wanting to do.
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 >> > > 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. >> > > >>> - Support for OSPF & BGP. >> > > >>> - VPN support through OpenVPN & StrongSwan. >> > > >>> - Easily supports HA (redundant routers) through VRRP. >> > > >>> - VXLAN support. >> > > >>> - Transaction based changes to the VR with rollback on error. >> > > >>> >> > > >>> Items that could be difficult to solve: >> > > >>> - Userdata password reset workflow and implementation. >> > > >>> - Upgrade process. >> > > >>> >> > > >>> The VyOS is not the only option if we were to consider this >> approach. >> > > >>> Another option, which I don't know as well, would be >> > > >>> CloudRouter (AGPL >> > > >>> license) [2] which is purely API driven. >> > > >>> >> > > >>> Anyway, would love to hear your thoughts... >> > > >>> >> > > >>> Will >> > > >>> >> > > >>> [1] https://vyos.io/ >> > > >>> [2] https://cloudrouter.org/ >> > > > >> > > > >> > > > >> > > > >> > > >DISCLAIMER >> > > >========== >> > > >This e-mail may contain privileged and confidential information >> > > >which is >> > > the property of Accelerite, a Persistent Systems business. It is >> > > intended only for the use of the individual or entity to which it >> > > is addressed. If you are not the intended recipient, you are not >> > > authorized to read, retain, copy, print, distribute or use this >> > > message. If you have received this communication in error, please >> > > notify the sender and delete all copies of this message. >> > > Accelerite, a Persistent Systems business does not accept any >> > > liability for virus >> > infected mails. >> > > >> > >> > >
