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