ty Godsey
Sent: Friday, September 16, 2016 12:24 PM
To: dev@cloudstack.apache.org
Subject: RE: [DISCUSS] Replacing the VR
So based upon this discussion would it be prudent to wait on VyOS 2.0?
The current VR is giving us issues but would the time invested in
another
"solution" be wast
;>> On 16/09/16, 11:59 PM, "Simon Weller" wrote:
>>>>>
>>>>> I think our other option is to take a real look at what it would take
>>>>>>
>>>>> to fix the VR. In my opinion, a lot of the problems are related to the
>>>
PM
To: dev@cloudstack.apache.org
Subject: Re: [DISCUSS] Replacing the VR
Will,
I think that would be very helpful to me at least and for posterity for sure. I
am in the process of rolling out my first production deployment of Cloudstack
so I have been busier than expected (plus I have been jumping back and fort
would be much easier to maintain.
- Si
From: Marty Godsey
Sent: Friday, September 16, 2016 12:24 PM
To: dev@cloudstack.apache.org
Subject: RE: [DISCUSS] Replacing the VR
So based upon this discussion would it be prudent to wait on VyOS 2.0?
The current VR is giving us issues but woul
of time separating out code into distinct
> modules, everything would behave a lot better.
> >>>
> >>>
> >>> The pain and suffering is due to years and years of patches and
> constant shelling out to complete tasks in my opinion. If we spend time to
> reth
;> The pain and suffering is due to years and years of patches and constant
>>> shelling out to complete tasks in my opinion. If we spend time to rethink
>>> how we interact with the VR in general and we abstract the systems and
>>> networking stuff and use well known a
Original Message-
> From: Matthew Smart [mailto:msm...@smartsoftwareinc.com]
> Sent: Thursday, September 22, 2016 2:35 PM
> To: dev@cloudstack.apache.org
> Subject: Re: [DISCUSS] Replacing the VR
>
> Thanks Will. That is the answer I expected tbh. But it never hurts to ask!
>
com]
Sent: Thursday, September 22, 2016 2:35 PM
To: dev@cloudstack.apache.org
Subject: Re: [DISCUSS] Replacing the VR
Thanks Will. That is the answer I expected tbh. But it never hurts to ask!
Matthew Smart
President
Smart Software Solutions Inc.
108 S Pierre St.
Pierre, SD 57501
Phone: (605) 280-
uch easier to maintain.
- Si
From: Marty Godsey
Sent: Friday, September 16, 2016 12:24 PM
To: dev@cloudstack.apache.org
Subject: RE: [DISCUSS] Replacing the VR
So based upon this discussion would it be prudent to wait on VyOS 2.0?
The current VR is giving us issues but would the time invested i
t;>>
>>>
>>> The pain and suffering is due to years and years of patches and constant
>>> shelling out to complete tasks in my opinion. If we spend time to rethink
>>> how we interact with the VR in general and we abstract the systems and
>>> networ
ems and networking
stuff and use well known and stable libraries to do the work, the VR would be
much easier to maintain.
- Si
From: Marty Godsey
Sent: Friday, September 16, 2016 12:24 PM
To: dev@cloudstack.apache.org
Subject: RE: [DISCUSS] Replacing t
blished libraries to complete tasks and instead shell out and run
>> commands that are both hard to track and hard to parse on return.
>> >
>> >
>> >If we daemonized this, used a real api for Agent to VR communication,
>> used common already existing libraries
uld be much easier to maintain.
> >
> >
> >- Si
> >
> >
> >
> >
> >
> >From: Marty Godsey
> >Sent: Friday, September 16, 2016 12:24 PM
> >To: dev@cloudstack.apache.org
> >Subject: RE: [DISCUSS] Repl
return.
>> >
>> >
>> >If we daemonized this, used a real api for Agent to VR communication,
>> used common already existing libraries for the system service and network
>> interactions and spent a bit of time separating out code into distinct
>&g
l and we abstract the systems and
> networking stuff and use well known and stable libraries to do the work,
> the VR would be much easier to maintain.
> >
> >
> >- Si
> >
> >
> >
> >
> >
> >From: Marty Godse
networking
>stuff and use well known and stable libraries to do the work, the VR would be
>much easier to maintain.
>
>
>- Si
>
>
>
>
>
>From: Marty Godsey
>Sent: Friday, September 16, 2016 12:24 PM
>To: dev@cloudstack.apache.
regards,
Paul Angus
paul.an...@shapeblue.com
www.shapeblue.com
53 Chandos Place, Covent Garden, London WC2N 4HSUK
@shapeblue
-Original Message-
From: Syed Ahmed [mailto:sah...@cloudops.com]
Sent: 19 September 2016 17:07
To: dev@cloudstack.apache.org
Subject: Re: [DISCUSS] R
don WC2N 4HSUK
@shapeblue
-Original Message-
From: Syed Ahmed [mailto:sah...@cloudops.com]
Sent: 19 September 2016 17:07
To: dev@cloudstack.apache.org
Subject: Re: [DISCUSS] Replacing the VR
Hey Guys,
Will and I had a discussion in the morning on around VyOS and I have an
idea that coul
tephan
>
>
> Am Sonntag, den 18.09.2016, 15:19 + schrieb Marty Godsey:
> > On this note I also mentioned pfsense earlier.
> >
> > www.pfsense.org
> >
> >
> > Regards,
> > Marty Godsey
> >
> > -Original Message-----
> > From
too often recently, which is
> > > > > why we
> > > > > have started looking into alternative implementations.
> > > > >
> > > > > One of the things that is nice about potentially using the
> > > > > VyOS is
on return.
>>>>>
>>>>>
>>>>> If we daemonized this, used a real api for Agent to VR communication,
>>>>>
>>>> used
>>>
>>>> common already existing libraries for the system service and network
>>>
mailto:williamstev...@gmail.com] On
Behalf Of Will Stevens
Sent: Friday, September 16, 2016 10:31 AM
To: dev@cloudstack.apache.org
Cc: dan...@baturin.org
Subject: Re: [DISCUSS] Replacing the VR
I just had a quick chat with a couple of the guys over on the VyOS chat.
I have CC'ed one of them in
gt; rethink
> >> how we interact with the VR in general and we abstract the systems and
> >> networking stuff and use well known and stable libraries to do the work,
> >> the VR would be much easier to maintain.
> >>
> >>
> >> - Si
> >>
&g
On this note I also mentioned pfsense earlier.
www.pfsense.org
Regards,
Marty Godsey
-Original Message-
From: ilya [mailto:ilya.mailing.li...@gmail.com]
Sent: Sunday, September 18, 2016 1:09 AM
To: dev@cloudstack.apache.org
Subject: Re: [DISCUSS] Replacing the VR
Our options become
emented and right as that time happened
>> to be when VyOS 2.0 is released. Of course you said they are just in the
>> scoping range so this could still be a year or more out.
>>
>> Thoughts?
>>
>> Regards,
>> Marty Godsey
>> nSource Solutions
>>
>> -O
; Thoughts?
>
> Regards,
> Marty Godsey
> nSource Solutions
>
> -Original Message-
> From: williamstev...@gmail.com [mailto:williamstev...@gmail.com] On
> Behalf Of Will Stevens
> Sent: Friday, September 16, 2016 10:31 AM
> To: dev@cloudstack.apache.org
> Cc:
tember 16, 2016 10:31 AM
> To: dev@cloudstack.apache.org
> Cc: dan...@baturin.org
> Subject: Re: [DISCUSS] Replacing the VR
>
> I just had a quick chat with a couple of the guys over on the VyOS chat.
> I have CC'ed one of them in case we have more licensing questi
t the systems and networking
stuff and use well known and stable libraries to do the work, the VR would be
much easier to maintain.
- Si
From: Marty Godsey
Sent: Friday, September 16, 2016 12:24 PM
To: dev@cloudstack.apache.org
Subject: RE: [DISCUSS] Replacing t
ll Stevens
Sent: Friday, September 16, 2016 10:31 AM
To: dev@cloudstack.apache.org
Cc: dan...@baturin.org
Subject: Re: [DISCUSS] Replacing the VR
I just had a quick chat with a couple of the guys over on the VyOS chat.
I have CC'ed one of them in case we have more licensing questions.
So her
or DNS/USERDATA/etc, unless we can make VyOS serve
> those
> > > too. Imho this adds complexity we should void.
> > >
> > > --
> > > Sent from the Delta quadrant using Borg technology!
> > >
> > > Nux!
> > > www.nux.ro
&g
ke VyOS serve those
> > too. Imho this adds complexity we should void.
> >
> > --
> > Sent from the Delta quadrant using Borg technology!
> >
> > Nux!
> > www.nux.ro
> >
> > ----- Original Message -
> > > From: "Will Stevens&
logy!
>
> Nux!
> www.nux.ro
>
> - Original Message -
> > From: "Will Stevens"
> > To: dev@cloudstack.apache.org
> > Sent: Thursday, 15 September, 2016 17:21:28
> > Subject: Re: [DISCUSS] Replacing the VR
>
> > Ya, we would need to add a
#creating-new-component
> >>
> >> <https://opensnaproute.github.io/docs/developer.html#
> >> creating-new-component>
> >>
> >>
> >> They've definitely build it with a microservices architecture in mind,
> so
> >> each indivi
pache.org
> Sent: Thursday, 15 September, 2016 17:21:28
> Subject: Re: [DISCUSS] Replacing the VR
> Ya, we would need to add a daemon for VPN as well. Load balancing is
> another aspect which we will need to consider if we went this route.
> Something like https://traefik.io/ could p
PLS based L3VPN, EVPN, VPLS in the future. This will be huge
>>> for our carrier community that rely on these technologies to do private
>>> gateway and inter-VPC interconnections today. We handle this stuff on our
>>> ASRs right now with a vlan interconnect into the VR. B
components if we really had to.
>
>
> - Si
>
>
>
> From: williamstev...@gmail.com on behalf of
> Will Stevens
> Sent: Thursday, September 15, 2016 9:17 AM
> To: dev@cloudstack.apache.org
> Subject: Re: [DISCUSS] Replacing the VR
>
rd server and the userdata components if we
really had to.
- Si
From: williamstev...@gmail.com on behalf of Will
Stevens
Sent: Thursday, September 15, 2016 9:17 AM
To: dev@cloudstack.apache.org
Subject: Re: [DISCUSS] Replacing the VR
A big part of why I know
o the VR would be awesome.
>
>
> It also seems to be written in GO (a language here at ENA we know very
> well).
>
>
> - Si
>
>
>
>
> From: Will Stevens
> Sent: Thursday, September 15, 2016 7:06 AM
> To: dev@cloudstack.apache.or
er 15, 2016 7:06 AM
To: dev@cloudstack.apache.org
Subject: RE: [DISCUSS] Replacing the VR
Ya. I don't think it covers our whole use case, but what it does cover is
all api driven...
On Sep 15, 2016 1:48 AM, "Marty Godsey" wrote:
> Though I don’t see VPN in Snaproute.. Makes
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 se
Behalf Of
Will Stevens
Sent: Wednesday, September 14, 2016 11:06 PM
To: dev@cloudstack.apache.org
Subject: Re: [DISCUSS] Replacing the VR
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
Wednesday, September 14, 2016 11:06 PM
To: dev@cloudstack.apache.org
Subject: Re: [DISCUSS] Replacing the VR
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
plifies it.
>> >
>> > Regards,
>> > Marty Godsey
>> > nSource Solutions
>> >
>> > -Original Message-
>> > From: Chiradeep Vittal [mailto:chirade...@gmail.com]
>> > Sent: Wednesday, September 14, 2016 5:37 PM
>> &
set of issues but it also
> > simplifies it.
> >
> > Regards,
> > Marty Godsey
> > nSource Solutions
> >
> > -Original Message-
> > From: Chiradeep Vittal [mailto:chirade...@gmail.com]
> > Sent: Wednesday, September 14, 2016 5:37 PM
> >
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
>
> Marty Godsey
> nSource Solutions
>
> -Original Message-
> From: Abhinandan Prateek [mailto:abhinandan.prat...@shapeblue.com]
> Sent: Wednesday, September 14, 2016 2:26 AM
> To: dev@cloudstack.apache.org
> Subject: Re: [DISCUSS] Replacing the VR
>
> Cloudrouter lo
ource Solutions
>
> -Original Message-
> From: Abhinandan Prateek [mailto:abhinandan.prat...@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
...@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
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" wrote:
>Hi,
>
>Instead of replacing the VR in first place we should
ptember 13, 2016 3:48 PM
> To: dev@cloudstack.apache.org
> Subject: Re: [DISCUSS] Replacing the VR
>
> I can't seem to find any API documentation for CloudRouter. Maybe my
> Google foo is weak. Has anyone else found any usable docs on that?
>
> *Will STEVENS*
> Lead Devel
I can't seem to find any API documentation for CloudRouter. Maybe my
Google foo is weak. Has anyone else found any usable docs on that?
*Will STEVENS*
Lead Developer
*CloudOps* *| *Cloud Solutions Experts
420 rue Guy *|* Montreal *|* Quebec *|* H3J 1S6
w cloudops.com *|* tw @CloudOps_
On Tue,
m] On Behalf Of
Will Stevens
Sent: Tuesday, September 13, 2016 3:48 PM
To: dev@cloudstack.apache.org
Subject: Re: [DISCUSS] Replacing the VR
I can't seem to find any API documentation for CloudRouter. Maybe my Google
foo is weak. Has anyone else found any usable docs on that?
*Will STE
From: Marty Godsey
>> Sent: Tuesday, September 13, 2016 12:05 PM
>> To: dev@cloudstack.apache.org
>> Subject: RE: [DISCUSS] Replacing the VR
>>
>> So it looks like we are eliminating CloudRouter. To many missing or non
>> API managed features.
>>
>> But in reading Vy
(did I mention really) ugly.
>
>
> From: Marty Godsey
> Sent: Tuesday, September 13, 2016 12:05 PM
> To: dev@cloudstack.apache.org
> Subject: RE: [DISCUSS] Replacing the VR
>
> So it looks like we are eliminating CloudRouter. To many miss
ens
> Sent: Tuesday, September 13, 2016 12:58 PM
> To: dev@cloudstack.apache.org
> Subject: Re: [DISCUSS] Replacing the VR
>
> Judging from this, it does not look like IPSec is managed via the API
> though:
> https://cloudrouter.atlassian.net/wiki/display/CPD/Bridging+
> Pub
Yeah, today, the agent uses a script to inject CLI via ssh into the VR. It's
really (did I mention really) ugly.
From: Marty Godsey
Sent: Tuesday, September 13, 2016 12:05 PM
To: dev@cloudstack.apache.org
Subject: RE: [DISCUSS] Replacing the VR
So it looks
ssage-
From: williamstev...@gmail.com [mailto:williamstev...@gmail.com] On Behalf Of
Will Stevens
Sent: Tuesday, September 13, 2016 12:58 PM
To: dev@cloudstack.apache.org
Subject: Re: [DISCUSS] Replacing the VR
Judging from this, it does not look like IPSec is managed via the AP
; Sent: Tuesday, September 13, 2016 12:49 PM
> To: dev@cloudstack.apache.org
> Subject: Re: [DISCUSS] Replacing the VR
>
> Does CloudRouter provide VPN (site-site and client)? Looking from their
> website I don't seem to find it. Also, missing is VVRP for redundancy. Has
> anyon
It does.. Its under Secure Connectivity.
-Original Message-
From: Syed Ahmed [mailto:sah...@cloudops.com]
Sent: Tuesday, September 13, 2016 12:49 PM
To: dev@cloudstack.apache.org
Subject: Re: [DISCUSS] Replacing the VR
Does CloudRouter provide VPN (site-site and client)? Looking from
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
16 12:43 PM
To: dev@cloudstack.apache.org
Subject: Re: [DISCUSS] Replacing the VR
+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 wrote:
> yes, technically we should be able to just make
l 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:williamstev...@gmail.com]
> > > Sent:
moment which has a
> > lot of manual configurations.
> >
> > Let me know if I can help in anyway.
> >
> > -Original Message-
> > From: Will Stevens [mailto:williamstev...@gmail.com]
> > Sent: Tuesday, September 13, 2016 7:21 AM
> > To: dev@cloud
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 defaul
manual
configurations.
Let me know if I can help in anyway.
-Original Message-
From: Will Stevens [mailto:williamstev...@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
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"
wrote:
> Hi,
>
> Instead of replacing the VR in first place we s
Ya. CloudRouter is interesting because it has a native api. For that reason
it was brought up as an alternative to VyOS in our internal discussions.
On Sep 13, 2016 5:23 AM, "Nux!" wrote:
> Hi,
>
> I like the idea.
>
> Cloudrouter looks really promising, I'm not too keen on VyOS (it doesn't
> ha
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 wi
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"
> To: dev@cloudstack.apache.org
> Sent: Monday
.@gmail.com] On
> Behalf Of Will Stevens
> Sent: Monday, September 12, 2016 6:16 PM
> To: dev@cloudstack.apache.org
> Subject: Re: [DISCUSS] Replacing the VR
>
> You have probably looked into this more than I have Rene.
>
> I am not sure there existed a time when the VR was ev
@cloudstack.apache.org
Subject: Re: [DISCUSS] Replacing the VR
You have probably looked into this more than I have Rene.
I am not sure there existed a time when the VR was ever "great". In my eyes,
the core ACS dev team should not be building and managing its own VR. I feel
like that is a liabili
You have probably looked into this more than I have Rene.
I am not sure there existed a time when the VR was ever "great". In my
eyes, the core ACS dev team should not be building and managing its own
VR. I feel like that is a liability because the subset of developers who
are proficient in netw
Hi
On 09/12/2016 10:20 PM, Will Stevens 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
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 servi
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 w
Will,
Typo. “application model” was meant to be “appliance 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:35 PM, John Burwell wrote:
>
> Will,
>
> I agree that we need to repl
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 n
77 matches
Mail list logo
