cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chiradeep Vittal <chirade...@gmail.com>
Subject Re: [DISCUSS] Replacing the VR
Date Wed, 14 Sep 2016 21:37:26 GMT
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