John, When you say to decompose the services to multiple containers? Where do you envision the containers be running? Surely, they must be running in some VM running on top of the hypervisor otherwise you would not be able to support all hypervisors. Now the question is, does each individual service require its own VM? Could you elaborate this further?
Thanks, -Syed On Mon, Sep 12, 2016 at 4:52 PM, Will Stevens <wstev...@cloudops.com> wrote: > Those are fair points John. I was going down the thought process of "if we > have a VR, let's use an existing proven technology and not build our own". > > I think ACS needs an easy-to-use, out-of-the box default which anyone can > use without having to think too much about it. It would be great if it was > also implemented using a composition of distinct parts, but my initial goal > was to solve for a drop in replacement. > > Let's broaden the discussion to include the potential of introducing > composable pieces. If we are rewriting all of this, it would make sense to > consider that at the same time. The one thing that I think could be > challenging if we do that is the backwards compatibility of the plugin > implementations for the current hardware appliances because the plugin > hooks may have to change. > > Let's keep the conversation going... :P > > *Will STEVENS* > Lead Developer > > *CloudOps* *| *Cloud Solutions Experts > 420 rue Guy *|* Montreal *|* Quebec *|* H3J 1S6 > w cloudops.com *|* tw @CloudOps_ > > On Mon, Sep 12, 2016 at 4:35 PM, John Burwell <john.burw...@shapeblue.com> > wrote: > > > Will, > > > > I agree that we need to replace the VR, but I am not convinced that > > continuing with the notion of a monolithic application model is a best > > direction. The problem with the current model is that it lacks > > flexibility. Some users only need to deploy DHCP and DNS across a zone > > where others need a much wider range of services at the pod or cluster > > level. With the monolithic appliance, we are forced to build to the > lowest > > common denominator. > > > > I would like to see the VR’s functions disambiguated likely into > > containers (Zones/LXC-style rather than requiring the Docker/rkt > runtime). > > With this subdivision, we could then adopt the service chain model and > > allow users to compose networks services to better fit their use cases. > > > > My thinking is that if we are going to through the (continuing) pain of > > another VR replacement, we should take the opportunity to re-evaluate the > > entire model. > > > > Thanks, > > -John > > > > > > > john.burw...@shapeblue.com > > www.shapeblue.com > > 53 Chandos Place, Covent Garden, London VA WC2N 4HSUK > > @shapeblue > > > > > > > > On Sep 12, 2016, at 4:20 PM, Will Stevens <williamstev...@gmail.com> > > wrote: > > > > > > *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/ > > > > >
