cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Will Stevens <wstev...@cloudops.com>
Subject Re: [DISCUSS] Replacing the VR
Date Thu, 15 Sep 2016 02:55:07 GMT
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 <sahmed@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 <marty@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:chiradeepv@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 <marty@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.prateek@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.uradi@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! <
> > > >
> > > >> nux@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.prateek@shapeblue.com
> > > www.shapeblue.com
> > > 53 Chandos Place, Covent Garden, London  WC2N 4HSUK @shapeblue
> > >
> > >
> > >
> > > ----- Original Message -----
> > > >>> From: "Will Stevens" <williamstevens@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.
> > >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message