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. > > > > > >
