Mailing-List: contact dev-help@cloudstack.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cloudstack.apache.org
MIME-Version: 1.0
Sender: williamstevens@gmail.com
In-Reply-To: <CAC2panqozuyXHuU_6RCdLtPKAJJ+cCN8EDLu9+OdokvZV3mM0Q@mail.gmail.com>
References: <CAC2panpbVGqZNC_N97d0ojsF7mbU2HeNZ_3n5YpsB9AsZysP5w@mail.gmail.com>
 <1992498351.33324.1473758566107.JavaMail.zimbra@li.nux.ro>
 <CCDA417A-176F-45B0-AB03-7A88002A5FA8@persistent.co.in> <B2B9B59D-661C-4BEF-A98C-0143C1AA5530@shapeblue.com>
 <BN6PR14MB1266FCF2120F0CC53BDD5395BDF10@BN6PR14MB1266.namprd14.prod.outlook.com>
 <CAEe685EaGRO_6jOjr=6bYfDvU4nkWa+oirXmG7ETdqT=21k-_A@mail.gmail.com>
 <BN6PR14MB126650C5993DEA058C5E3D74BDF00@BN6PR14MB1266.namprd14.prod.outlook.com>
 <CADMzvUqMaBxUrexkZW8WN5DpneJ04Tz4XO_hCu+HvBMpnsGWxA@mail.gmail.com> <CAC2panqozuyXHuU_6RCdLtPKAJJ+cCN8EDLu9+OdokvZV3mM0Q@mail.gmail.com>
From: Will Stevens <wstevens@cloudops.com>
Date: Wed, 14 Sep 2016 23:06:06 -0400
Message-ID: <CAC2panpFXsQhRZ+KSVV-Jo6X7M9jFk+ZEm04y9E7fAfCOPmeYA@mail.gmail.com>
Subject: Re: [DISCUSS] Replacing the VR
To: "dev@cloudstack.apache.org" <dev@cloudstack.apache.org>
Content-Type: multipart/alternative; boundary=001a1146645a7f7966053c83201b
archived-at: Thu, 15 Sep 2016 03:06:20 -0000

--001a1146645a7f7966053c83201b
Content-Type: text/plain; charset=UTF-8

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

--001a1146645a7f7966053c83201b--