cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Zaeem Arshad <zaeem.ars...@gmail.com>
Subject Re: [DISCUSS] Replacing the VR
Date Tue, 13 Sep 2016 16:43:17 GMT
+1 on cloudrouter. We have been looking at this as a potential
replacement/addon to our existing VRs.

On Tue, Sep 13, 2016 at 9:07 PM, Will Stevens <wstevens@cloudops.com> wrote:

> yes, technically we should be able to just make a new VR implementation
> available and then when people create their network offerings, they just
> pick which VR implementation they want to use for the different
> capabilities.
>
> *Will STEVENS*
> Lead Developer
>
> *CloudOps* *| *Cloud Solutions Experts
> 420 rue Guy *|* Montreal *|* Quebec *|* H3J 1S6
> w cloudops.com *|* tw @CloudOps_
>
> On Tue, Sep 13, 2016 at 11:41 AM, Dustin Wright <
> dwright@untangledtechnology.com> wrote:
>
> > I would like to see a "virtual router offering" in the UI which lets you
> > pick the legacy VR or your own. Probably a component of the network
> > offering. I've had many cases were I needed Mikrotik RouterOS or pfSense
> to
> > match a clients on-premise gear. ACS should find a way to stay agnostic
> > IMO.
> >
> > On Tue, Sep 13, 2016 at 11:36 AM, Marty Godsey <marty@gonsource.com>
> > wrote:
> >
> > > I like this idea as well. I would be willing to test both VyOS and
> > > Cloudrouter if you need an active service to test with. Specifically I
> am
> > > looking to test IPv6 since I provide IPv6 /64 spaces to my customers
> and
> > I
> > > am having to provide it via an external router at the moment which has
> a
> > > lot of manual configurations.
> > >
> > > Let me know if I can help in anyway.
> > >
> > > -----Original Message-----
> > > From: Will Stevens [mailto:williamstevens@gmail.com]
> > > Sent: Tuesday, September 13, 2016 7:21 AM
> > > To: dev@cloudstack.apache.org
> > > Subject: Re: [DISCUSS] Replacing the VR
> > >
> > > Ya. If we go this way, I like the approach of building the integration
> > and
> > > putting it through its paces as a stand alone VR before we consider
> > > replacing the old VR and making it the default.
> > >
> > > On Sep 13, 2016 6:52 AM, "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
> > > > >
> > > > > ----- 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