Adding Redundant Routers to VPCs

[Karl Harris]

Comments/Critiques/Additions to this list as well as implementation
suggestions are requested.


After looking at the differences between Public cloud routing and Virtual
Private Cloud Routing it appears the main differences are:


Public Cloud   VPC

One private network connection   Multiple (1…n) private
networks (tiers?)

Single router/1 NIC public/1 NIC private Single router/ 1 NIC public/
(1….n) NIC private (tiers?)



Additional/Needed functionality for redundant VPC routers:


Router pairs must be initialized (master/backup) with the same
functionality (NAT,DNS,etc).

Router pairs must be initialized with the same number of NIC both public
and private on each router.

Unique IP's must be available for each NIC on both master and backup
routers using CIDR(s) configured in VPC private network.

It appears most of the changes functional will be inside the Java class:
VpcVirtualNetworkApplianceManagerImpl


Have I missed any critical differences?





Karl Harris

Cloud Software Engineer

Sungard Availability Systems




Listed below, lifted from the CloudStack Documentation, are the
characteristics of a VPC as a reference:

*Major Components of a VPC:*

A VPC is comprised of the following network components:

   - *VPC*: A VPC acts as a container for multiple isolated networks that
   can communicate with each other via its virtual router.
   - *Network Tiers*: Each tier acts as an isolated network with its own
   VLANs and CIDR list, where you can place groups of resources, such as VMs.
   The tiers are segmented by means of VLANs. The NIC of each tier acts as its
   gateway.
   - *Virtual Router*: A virtual router is automatically created and
   started when you create a VPC. The virtual router connect the tiers and
   direct traffic among the public gateway, the VPN gateways, and the NAT
   instances. For each tier, a corresponding NIC and IP exist in the virtual
   router. The virtual router provides DNS and DHCP services through its IP.
   - *Public Gateway*: The traffic to and from the Internet routed to the
   VPC through the public gateway. In a VPC, the public gateway is not exposed
   to the end user; therefore, static routes are not support for the public
   gateway.
   - *Private Gateway*: All the traffic to and from a private network
   routed to the VPC through the private gateway. For more
information, see Section 11.19.5,
   “Adding a Private Gateway to a
VPC”<http://cloudstack.apache.org/docs/en-US/Apache_CloudStack/4.0.2/html/Installation_Guide/configure-vpc.html#add-gateway-vpc>
   .
   - *VPN Gateway*: The VPC side of a VPN connection.
   - *Site-to-Site VPN Connection*: A hardware-based VPN connection between
   your VPC and your datacenter, home network, or co-location facility. For
   more information, see Section 11.17.4, “Setting Up a Site-to-Site VPN
   
Connection”<http://cloudstack.apache.org/docs/en-US/Apache_CloudStack/4.0.2/html/Installation_Guide/vpn.html#site-to-site-vpn>
   .
   - *Customer Gateway*: The customer side of a VPN Connection. For more
   information, seeSection 11.17.4.1, “Creating and Updating a VPN Customer
   
Gateway”<http://cloudstack.apache.org/docs/en-US/Apache_CloudStack/4.0.2/html/Installation_Guide/vpn.html#create-vpn-customer-gateway>
   .
   - *NAT Instance*: An instance that provides Port Address Translation for
   instances to access the Internet via the public gateway. For more
   information, see Section 11.19.9, “Enabling or Disabling Static NAT on a
   
VPC”<http://cloudstack.apache.org/docs/en-US/Apache_CloudStack/4.0.2/html/Installation_Guide/configure-vpc.html#enable-disable-static-nat-vpc>
   .

*Network Architecture in a VPC*

In a VPC, the following four basic options of network architectures are
present:

   - VPC with a public gateway only
   - VPC with public and private gateways
   - VPC with public and private gateways and site-to-site VPN access
   - VPC with a private gateway only and site-to-site VPN access

*Connectivity Options for a VPC*

You can connect your VPC to:

   - The Internet through the public gateway.
   - The corporate datacenter by using a site-to-site VPN connection
   through the VPN gateway.
   - Both the Internet and your corporate datacenter by using both the
   public gateway and a VPN gateway.

*VPC Network Considerations*

Consider the following before you create a VPC:

   - A VPC, by default, is created in the enabled state.
   - A VPC can be created in Advance zone only, and can't belong to more
   than one zone at a time.
   - The default number of VPCs an account can create is 20. However, you
   can change it by using the max.account.vpcs global parameter, which
   controls the maximum number of VPCs an account is allowed to create.
   - The default number of tiers an account can create within a VPC is 3.
   You can configure this number by using the vpc.max.networks parameter.
   - Each tier

Re: Adding Redundant Routers to VPCs

[Karl Harris]

Hope I get this thread correct.

On Wed, Jan 22, 2014 at 2:55 PM, Sheng Yang  wrote:

> Again, Karl, please keep the relevant things in ONE mail thread.
>
> Please don't start one thread every time you posted in the community.
>
> You can simply reply the thread you posted before, address people's
> comment, and also would keep the people involved know what's going on.
>
> On Wed, Jan 22, 2014 at 10:02 AM, Karl Harris  >wrote:
>
> > Comments/Critiques/Additions to this list as well as implementation
> > suggestions are requested.
> >
> >
> > After looking at the differences between Public cloud routing and Virtual
> > Private Cloud Routing it appears the main differences are:
> >
> >
> > Public Cloud   VPC
> >
> > One private network connection   Multiple (1…n) private
> > networks (tiers?)
> >
> > Single router/1 NIC public/1 NIC private Single router/ 1 NIC public/
> > (1….n) NIC private (tiers?)
> >
> >
> >
> > Additional/Needed functionality for redundant VPC routers:
> >
> >
> > Router pairs must be initialized (master/backup) with the same
> > functionality (NAT,DNS,etc).
> >
>
> Yes. And the backup's service would be disabled temporarily.


> >
> > Router pairs must be initialized with the same number of NIC both public
> > and private on each router.
> >
>
> Yes.
>
>
> >
> > Unique IP's must be available for each NIC on both master and backup
> > routers using CIDR(s) configured in VPC private network.
> >
>
> You meant, same IP? Except the control(link local) ip.
>

Yes unique IP for the control ip on both master and backup.

Am I correct to assume an ARP flush, after the backup router is enabled,
remaps the public, private(may be multiple) and site-site VPN
IP's to the appropriate MAC addresses on the backup router (the IP's would
be the same as the master) to the appropriate virtual routers NICs? If this
is true then yes same IP's, using the appropriate CIDR, for each of the
non-control IP addresses.


>
> >
> > It appears most of the changes functional will be inside the Java class:
> > VpcVirtualNetworkApplianceManagerImpl
> >
>
> Lots of work would be in the VR script as well, since eth2 is no longer
> assumed public nic.
>
Thanks I need to look at the VR script.

>
> --Sheng
>
>
> >
> > Have I missed any critical differences?
> >
> >
> >
> >
> >
> > Karl Harris
> >
> > Cloud Software Engineer
> >
> > Sungard Availability Systems
> >
> >
> >
> >
> > Listed below, lifted from the CloudStack Documentation, are the
> > characteristics of a VPC as a reference:
> >
> > *Major Components of a VPC:*
> >
> > A VPC is comprised of the following network components:
> >
> >- *VPC*: A VPC acts as a container for multiple isolated networks that
> >can communicate with each other via its virtual router.
> >- *Network Tiers*: Each tier acts as an isolated network with its own
> >VLANs and CIDR list, where you can place groups of resources, such as
> > VMs.
> >The tiers are segmented by means of VLANs. The NIC of each tier acts
> as
> > its
> >gateway.
> >- *Virtual Router*: A virtual router is automatically created and
> >started when you create a VPC. The virtual router connect the tiers
> and
> >direct traffic among the public gateway, the VPN gateways, and the NAT
> >instances. For each tier, a corresponding NIC and IP exist in the
> > virtual
> >router. The virtual router provides DNS and DHCP services through its
> > IP.
> >- *Public Gateway*: The traffic to and from the Internet routed to the
> >VPC through the public gateway. In a VPC, the public gateway is not
> > exposed
> >to the end user; therefore, static routes are not support for the
> public
> >gateway.
> >- *Private Gateway*: All the traffic to and from a private network
> >routed to the VPC through the private gateway. For more
> > information, see Section 11.19.5,
> >“Adding a Private Gateway to a
> > VPC”<
> >
> http://cloudstack.apache.org/docs/en-US/Apache_CloudStack/4.0.2/html/Installation_Guide/configure-vpc.html#add-gateway-vpc
> > >
> >.
> >- *VPN Gateway*: The VPC side of a VPN connection.
> >- *Site-to-Site VPN Connection*: A hardware-based VPN connection
> between
> >your VPC and your datacen

Re: Working on CloudStack Jira-764:nTier Apps 2.0 : Redundant Virtual Router for VPC email 2 of 2

[Karl Harris]

All,

At first redundant DHCP seemed like a good idea. I did some cursory
research and the more I read the more I'm convinced it may be
more trouble than its worth for the first implementation. I'll talk
with some of our Systems Engineer's here and get a broader
perspective.

There seems to be only a single implementation of an open source DHCP
server that will handle the synchronization required for redundant
servers.

Karl


On Fri, Jan 24, 2014 at 5:47 PM, Daan Hoogland  wrote:
> Saurav,
>
> Not sure how this happens now, but it is definateluy something we
> want. For the static conf files it won't be much of a problem. The
> firewall/loadbalences won't be much of a problem, they are fire and
> forget configurations of the ms that can just be sent to both. The
> dhcp is a challange. I am not sure if it is solved for the plain rvr
> now but it should be solved for that as well.
>
> On Fri, Jan 24, 2014 at 3:53 PM, Saurav Lahiri
>  wrote:
>> Daan,
>> I was wondering if you had not shared your thoughts, but looks like I had
>> missed your mail.
>>
>> I agree that redundant dhcp or dns would be good to have. What I meant was,
>> it appears that by  just enabling RVR   there is no way to auto sync
>> configuration between the  master and slave nodes with regard to dhcp,
>> loadbalancer and firewall(specifically the dhcp lease file, haproxy,cfg and
>> iptables configuration).  So just enabling RVR does not ensure high
>> availability for  these services. Is there a way cloudstack autosyncs
>> configuration?
>>
>> For the routing portion this is not an issue as the participating routers
>> learn the route through known protocols.
>>
>> Thanks
>> Saurav
>>
>>
>> On Fri, Jan 17, 2014 at 2:37 AM, Daan Hoogland 
>> wrote:
>>
>>> Saurav, I don't see why you can't benefit from having other services
>>> redundant as well. Vpn might be a problem as the source ip of a
>>> redundant router pair on a vpn might give a problem (maybe there is an
>>> implementation) but why wouldn't you want redundant dhcp or dns
>>> services? As I understand it these are used at Schuberg Philis at the
>>> moment. will double check when I get a chance.
>>>
>>> regards,
>>> Daan
>>>
>>>
>>>
>>> On Thu, Jan 16, 2014 at 1:33 PM, Saurav Lahiri
>>>  wrote:
>>> > Daan,
>>> > So looking at what is available today for guest network, the Redundant VR
>>> > can be enabled only for the source nat service. I guess the mention of
>>> the
>>> > source nat router is in relation to that. I could be wrong though. It
>>> > appears  that the other services like vpn, dhcp, dns do not benefit much
>>> > from the RVR capability. Can you clarify if thats correct?
>>> >
>>> > Thanks
>>> > Saurav
>>> >
>>> >
>>> > On Thu, Jan 16, 2014 at 2:27 AM, Karl Harris >> >wrote:
>>> >
>>> >> -- Forwarded message --
>>> >> From: Daan Hoogland 
>>> >> Date: Wed, Jan 15, 2014 at 2:51 PM
>>> >> Subject: Re: rvr4vpc
>>> >> To: Karl Harris 
>>> >> Cc: Christopher Litsinger 
>>> >>
>>> >>
>>> >> H Karl,
>>> >>
>>> >> Thanks for sharing. I didn't want to initiate this but I encourage you
>>> >> to share this on the dev list (not in jira) as things are only
>>> >> considered 'discussed' if they passed by there.
>>> >>
>>> >> You speak of '1 Get configuration data on Source Nat Router', I don't
>>> >> understand why you call the router by this designation. 'Source Nat'
>>> >> is only one of it's many possible functions.
>>> >>
>>> >> Apart from the design principles I shared with you I have so far only
>>> >> a technical implementation detail so far. That is to reserve the
>>> >> (eth2) interface for the private gateway on the vpc (r)vr. This way
>>> >> the inteface to configure are somewhat predictable.
>>> >>
>>> >> As for the design principle to have a statefull router (reboot proof)
>>> >> the idea is to implement a configuration file that will be uploaded to
>>> >> the router after which a self-config command is send that will
>>> >> implement the details of configuring the interfaces, haproxy and
>>> >> keepali

Re: Working on CloudStack Jira-764:nTier Apps 2.0 : Redundant Virtual Router for VPC email 2 of 2

[Karl Harris]

After discussion with my colleagues  questions about initial
configuration of the open network redundant routers and the
applicability of the existing bash scripts (cloud-early-config) to the
setup of VPC redundant routers have generated.


Some setup first: In the bash script cloud-early-config there is a
function named setup_redundant_router which makes copies of several
template files. The template files are used to configure keepalived
and conntrackd. The template copies are edited, via sed editor, using
environment variables ($ROUTER_PR, $ETH0_IP,$NAME, etc.)  which are
obtained from the kernel of the current running linux image using the
virtual file system /proc/cmdline.

I'm sure keepalived and conntrackd  can be used for starting and
control of VPC redundant routers. However the setup of keepalived and
conntrackd for VPC needs setup parameters which are dynamic because a
VPC can have N number of redundant router pairs, not just the fixed
number parsed from proc/cmdline in the running kernel.

Am I correct in this analysis?

If so, given the dynamic nature of the VPC redundant router
configurations: Is using a setup_VPC_redundant_router bash function,
similar to the existing open network function mentioned above, the
most appropriate way to setup the keepalived or conntrackd
configuration files for VPC redundant routers in the
cloud-early-script? It seems to me reading the parameters from the
kernel will require a unwieldy set of kernels to match the N private
network redundant router pairs configured by the enduser.


Comments, questions, clarifications?

Karl


In the bash script ea
On Mon, Jan 27, 2014 at 11:25 AM, Daan Hoogland  wrote:
> good reason to skip it for a next version, let's look into it anyway,
> as we don't want to burn any of our ships.
>
> On Mon, Jan 27, 2014 at 4:53 PM, Karl Harris  wrote:
>> All,
>>
>> At first redundant DHCP seemed like a good idea. I did some cursory
>> research and the more I read the more I'm convinced it may be
>> more trouble than its worth for the first implementation. I'll talk
>> with some of our Systems Engineer's here and get a broader
>> perspective.
>>
>> There seems to be only a single implementation of an open source DHCP
>> server that will handle the synchronization required for redundant
>> servers.
>>
>> Karl
>>
>>
>> On Fri, Jan 24, 2014 at 5:47 PM, Daan Hoogland  
>> wrote:
>>> Saurav,
>>>
>>> Not sure how this happens now, but it is definateluy something we
>>> want. For the static conf files it won't be much of a problem. The
>>> firewall/loadbalences won't be much of a problem, they are fire and
>>> forget configurations of the ms that can just be sent to both. The
>>> dhcp is a challange. I am not sure if it is solved for the plain rvr
>>> now but it should be solved for that as well.
>>>
>>> On Fri, Jan 24, 2014 at 3:53 PM, Saurav Lahiri
>>>  wrote:
>>>> Daan,
>>>> I was wondering if you had not shared your thoughts, but looks like I had
>>>> missed your mail.
>>>>
>>>> I agree that redundant dhcp or dns would be good to have. What I meant was,
>>>> it appears that by  just enabling RVR   there is no way to auto sync
>>>> configuration between the  master and slave nodes with regard to dhcp,
>>>> loadbalancer and firewall(specifically the dhcp lease file, haproxy,cfg and
>>>> iptables configuration).  So just enabling RVR does not ensure high
>>>> availability for  these services. Is there a way cloudstack autosyncs
>>>> configuration?
>>>>
>>>> For the routing portion this is not an issue as the participating routers
>>>> learn the route through known protocols.
>>>>
>>>> Thanks
>>>> Saurav
>>>>
>>>>
>>>> On Fri, Jan 17, 2014 at 2:37 AM, Daan Hoogland 
>>>> wrote:
>>>>
>>>>> Saurav, I don't see why you can't benefit from having other services
>>>>> redundant as well. Vpn might be a problem as the source ip of a
>>>>> redundant router pair on a vpn might give a problem (maybe there is an
>>>>> implementation) but why wouldn't you want redundant dhcp or dns
>>>>> services? As I understand it these are used at Schuberg Philis at the
>>>>> moment. will double check when I get a chance.
>>>>>
>>>>> regards,
>>>>> Daan
>>>>>
>>>>>
>>>>>
>>>>> On Thu, Jan 16, 2014 at 1:33 PM, Saurav Lahiri
>>>>>  wro

Re: Working on CloudStack Jira-764:nTier Apps 2.0 : Redundant Virtual Router for VPC email 2 of 2

[Karl Harris]

On Mon, Feb 3, 2014 at 12:54 PM, Daan Hoogland wrote:

>
> On 03 Feb 2014, at 18:03, Karl Harris  wrote:
>
> > After discussion with my colleagues  questions about initial
> > configuration of the open network redundant routers and the
> > applicability of the existing bash scripts (cloud-early-config) to the
> > setup of VPC redundant routers have generated.
> >
> >
> > Some setup first: In the bash script cloud-early-config there is a
> > function named setup_redundant_router which makes copies of several
> > template files. The template files are used to configure keepalived
> > and conntrackd. The template copies are edited, via sed editor, using
> > environment variables ($ROUTER_PR, $ETH0_IP,$NAME, etc.)  which are
> > obtained from the kernel of the current running linux image using the
> > virtual file system /proc/cmdline.
> >
> > I'm sure keepalived and conntrackd  can be used for starting and
> > control of VPC redundant routers. However the setup of keepalived and
> > conntrackd for VPC needs setup parameters which are dynamic because a
> > VPC can have N number of redundant router pairs, not just the fixed
> > number parsed from proc/cmdline in the running kernel.
> >
> > Am I correct in this analysis?
> Karl, I think not. There is only one router in a vac, it routes for all
> networks in the virtual private cloud. Am I misreading your description.

Ok then a VPC should contain a single router containing N+1 (N+2 if using a
VPN connection) nic's? Where N is the number of private networks.

If so then my original question still holds in the sense that the nic's
need to be created in the VM kernel based on the number of private networks
desired? I found the method update_System_Vm_Templates in the jar file
Upgrade410to420 in cloud-engine-schema/src/com/cloud/upgrade/dao which
seems to point to a set of pre-configured VM images.

>
> > If so, given the dynamic nature of the VPC redundant router
> > configurations: Is using a setup_VPC_redundant_router bash function,
> > similar to the existing open network function mentioned above, the
> > most appropriate way to setup the keepalived or conntrackd
> > configuration files for VPC redundant routers in the
> > cloud-early-script? It seems to me reading the parameters from the
> > kernel will require a unwieldy set of kernels to match the N private
> > network redundant router pairs configured by the enduser.
> >
> >
> > Comments, questions, clarifications?
>
> >
> > Karl
> >
> >
> > In the bash script ea
> > On Mon, Jan 27, 2014 at 11:25 AM, Daan Hoogland 
> wrote:
> >> good reason to skip it for a next version, let's look into it anyway,
> >> as we don't want to burn any of our ships.
> >>
> >> On Mon, Jan 27, 2014 at 4:53 PM, Karl Harris 
> wrote:
> >>> All,
> >>>
> >>> At first redundant DHCP seemed like a good idea. I did some cursory
> >>> research and the more I read the more I'm convinced it may be
> >>> more trouble than its worth for the first implementation. I'll talk
> >>> with some of our Systems Engineer's here and get a broader
> >>> perspective.
> >>>
> >>> There seems to be only a single implementation of an open source DHCP
> >>> server that will handle the synchronization required for redundant
> >>> servers.
> >>>
> >>> Karl
> >>>
> >>>
> >>> On Fri, Jan 24, 2014 at 5:47 PM, Daan Hoogland <
> daan.hoogl...@gmail.com> wrote:
> >>>> Saurav,
> >>>>
> >>>> Not sure how this happens now, but it is definateluy something we
> >>>> want. For the static conf files it won't be much of a problem. The
> >>>> firewall/loadbalences won't be much of a problem, they are fire and
> >>>> forget configurations of the ms that can just be sent to both. The
> >>>> dhcp is a challange. I am not sure if it is solved for the plain rvr
> >>>> now but it should be solved for that as well.
> >>>>
> >>>> On Fri, Jan 24, 2014 at 3:53 PM, Saurav Lahiri
> >>>>  wrote:
> >>>>> Daan,
> >>>>> I was wondering if you had not shared your thoughts, but looks like
> I had
> >>>>> missed your mail.
> >>>>>
> >>>>> I agree that redundant dhcp or dns would be good to have. What I
> meant was,
> >>>>> it appears that by  just enabling RVR   there is no way to auto sy

Re: Working on CloudStack Jira-764:nTier Apps 2.0 : Redundant Virtual Router for VPC email 2 of 2

[Karl Harris]

On Mon, Feb 3, 2014 at 2:03 PM, Daan Hoogland wrote:

>
> On 03 Feb 2014, at 19:45, Karl Harris  wrote:
>
> > On Mon, Feb 3, 2014 at 12:54 PM, Daan Hoogland  >wrote:
> >
> >>
> >> On 03 Feb 2014, at 18:03, Karl Harris  wrote:
> >>
> >>> After discussion with my colleagues  questions about initial
> >>> configuration of the open network redundant routers and the
> >>> applicability of the existing bash scripts (cloud-early-config) to the
> >>> setup of VPC redundant routers have generated.
> >>>
> >>>
> >>> Some setup first: In the bash script cloud-early-config there is a
> >>> function named setup_redundant_router which makes copies of several
> >>> template files. The template files are used to configure keepalived
> >>> and conntrackd. The template copies are edited, via sed editor, using
> >>> environment variables ($ROUTER_PR, $ETH0_IP,$NAME, etc.)  which are
> >>> obtained from the kernel of the current running linux image using the
> >>> virtual file system /proc/cmdline.
> >>>
> >>> I'm sure keepalived and conntrackd  can be used for starting and
> >>> control of VPC redundant routers. However the setup of keepalived and
> >>> conntrackd for VPC needs setup parameters which are dynamic because a
> >>> VPC can have N number of redundant router pairs, not just the fixed
> >>> number parsed from proc/cmdline in the running kernel.
> >>>
> >>> Am I correct in this analysis?
> >> Karl, I think not. There is only one router in a vac, it routes for all
> >> networks in the virtual private cloud. Am I misreading your description.
> >
> > Ok then a VPC should contain a single router containing N+1 (N+2 if
> using a
> > VPN connection) nic's? Where N is the number of private networks.
> And I would like to see N+3 as it will allocate another when a private
> gateway is defined. That is why I proposed to pre-allocate this nic to be
> able to predict mic-ids, i.e. eth<#>.
>
> >
> > If so then my original question still holds in the sense that the nic's
> > need to be created in the VM kernel based on the number of private
> networks
> > desired?
>
> Yes
>
> > I found the method update_System_Vm_Templates in the jar file
> > Upgrade410to420 in cloud-engine-schema/src/com/cloud/upgrade/dao which
> > seems to point to a set of pre-configured VM images.
> I can not find the method you describe but these preconfigured images are
> the ones used for all the system vms. That would be secondary storage vms,
> console proxy vms and indeed the router vms.
>
> Based on the discussion above the the configuration part of the VPC
redundant router is:

 1. Collecting the correct data required to configure the nics. (Is this
part already in the VPC setup code? I will look for it, pointers will be
helpful.)
 2. Based on the hypervisor/vm types configure the nic(s) on the router VM
using the data collected above (Same question as in 1 above is this code
already in place?). My guess is to start with a preconfigured template and
configure the vm based on the number of nics and any other appropriate data.
 3. Configuring conntrackd and keepalived after the router vm (nics) have
been configured and the router(s) started or restarted? I still need to
work through this.




>
> >>
> >>> If so, given the dynamic nature of the VPC redundant router
> >>> configurations: Is using a setup_VPC_redundant_router bash function,
> >>> similar to the existing open network function mentioned above, the
> >>> most appropriate way to setup the keepalived or conntrackd
> >>> configuration files for VPC redundant routers in the
> >>> cloud-early-script? It seems to me reading the parameters from the
> >>> kernel will require a unwieldy set of kernels to match the N private
> >>> network redundant router pairs configured by the enduser.
> >>>
> >>>
> >>> Comments, questions, clarifications?
> >>
> >>>
> >>> Karl
> >>>
> >>>
> >>> In the bash script ea
> >>> On Mon, Jan 27, 2014 at 11:25 AM, Daan Hoogland <
> daan.hoogl...@gmail.com>
> >> wrote:
> >>>> good reason to skip it for a next version, let's look into it anyway,
> >>>> as we don't want to burn any of our ships.
> >>>>
> >>>> On Mon, Jan 27, 2014 at 4:53 PM, Karl Harris  >
> >> wrote:
> >>>>> All,
> >>>

Re: Working on CloudStack Jira-764:nTier Apps 2.0 : Redundant Virtual Router for VPC email 2 of 2

[Karl Harris]

Would implementing a VPC Redundant Router Network Guru using the an
extension of the NetworkGuru interface be an appropriate way to create a
VPC network with redundant routers. It seems that extending Network Guru
interface or extending one of it's children eg the abstract class
GuestNetworkGuru would be a appropriate design path.

Comments?

Karl



On Mon, Feb 3, 2014 at 2:58 PM, Daan Hoogland wrote:

> On Mon, Feb 3, 2014 at 8:50 PM, Sheng Yang  wrote:
> > On Mon, Feb 3, 2014 at 11:27 AM, Karl Harris  >wrote:
> >
> >> On Mon, Feb 3, 2014 at 2:03 PM, Daan Hoogland  >> >wrote:
> >>
> >> >
> >> > On 03 Feb 2014, at 19:45, Karl Harris 
> wrote:
> >> >
> >> > > On Mon, Feb 3, 2014 at 12:54 PM, Daan Hoogland <
> >> daan.hoogl...@gmail.com
> >> > >wrote:
> >> > >
> >> > >>
> >> > >> On 03 Feb 2014, at 18:03, Karl Harris 
> >> wrote:
> >> > >>
> >> > >>> After discussion with my colleagues  questions about initial
> >> > >>> configuration of the open network redundant routers and the
> >> > >>> applicability of the existing bash scripts (cloud-early-config) to
> >> the
> >> > >>> setup of VPC redundant routers have generated.
> >> > >>>
> >> > >>>
> >> > >>> Some setup first: In the bash script cloud-early-config there is a
> >> > >>> function named setup_redundant_router which makes copies of
> several
> >> > >>> template files. The template files are used to configure
> keepalived
> >> > >>> and conntrackd. The template copies are edited, via sed editor,
> using
> >> > >>> environment variables ($ROUTER_PR, $ETH0_IP,$NAME, etc.)  which
> are
> >> > >>> obtained from the kernel of the current running linux image using
> the
> >> > >>> virtual file system /proc/cmdline.
> >> > >>>
> >> > >>> I'm sure keepalived and conntrackd  can be used for starting and
> >> > >>> control of VPC redundant routers. However the setup of keepalived
> and
> >> > >>> conntrackd for VPC needs setup parameters which are dynamic
> because a
> >> > >>> VPC can have N number of redundant router pairs, not just the
> fixed
> >> > >>> number parsed from proc/cmdline in the running kernel.
> >> > >>>
> >> > >>> Am I correct in this analysis?
> >> > >> Karl, I think not. There is only one router in a vac, it routes for
> >> all
> >> > >> networks in the virtual private cloud. Am I misreading your
> >> description.
> >> > >
> >> > > Ok then a VPC should contain a single router containing N+1 (N+2 if
> >> > using a
> >> > > VPN connection) nic's? Where N is the number of private networks.
> >> > And I would like to see N+3 as it will allocate another when a private
> >> > gateway is defined. That is why I proposed to pre-allocate this nic
> to be
> >> > able to predict mic-ids, i.e. eth<#>.
> >> >
> >> > >
> >> > > If so then my original question still holds in the sense that the
> nic's
> >> > > need to be created in the VM kernel based on the number of private
> >> > networks
> >> > > desired?
> >> >
> >> > Yes
> >> >
> >> > > I found the method update_System_Vm_Templates in the jar file
> >> > > Upgrade410to420 in cloud-engine-schema/src/com/cloud/upgrade/dao
> which
> >> > > seems to point to a set of pre-configured VM images.
> >> > I can not find the method you describe but these preconfigured images
> are
> >> > the ones used for all the system vms. That would be secondary storage
> >> vms,
> >> > console proxy vms and indeed the router vms.
> >> >
> >> > Based on the discussion above the the configuration part of the VPC
> >> redundant router is:
> >>
> >>  1. Collecting the correct data required to configure the nics. (Is this
> >> part already in the VPC setup code? I will look for it, pointers will be
> >> helpful.)
> >>
> >
> > vpc_guestgw.sh
> and VpcVirtualNetworkApplianceManager and -Impl and their ancestors
>
>
> >
> >
> >>  2. Based on the hyperv

Re: Working on CloudStack Jira-764:nTier Apps 2.0 : Redundant Virtual Router for VPC email 2 of 2

[Karl Harris]

On Wed, Feb 12, 2014 at 9:38 AM, Karl Harris wrote:

> Would implementing a VPC Redundant Router Network Guru using the an
> extension of the NetworkGuru interface be an appropriate way to create a
> VPC network with redundant routers. It seems that extending Network Guru
> interface or extending one of it's children eg the abstract class
> GuestNetworkGuru would be a appropriate design path.
>
> Comments?
>
> Karl
>
I know the configuration of the VM which implement the redundant routers
are handled via BASH scripts and the environment variables int the VM
images are used to configure the conntrackd and keepalived applications via
SED in bash scripts. I am looking for a clean way to pass the variable
number of NIC's and then generate the LINK and IGNORE configuration
commands for conntrackd.

The Network Guru mentioned above seemed like an interesting place to look,
even though it's used to work with the DAO's for the NetworkElements.

Karl


>
> On Mon, Feb 3, 2014 at 2:58 PM, Daan Hoogland wrote:
>
>> On Mon, Feb 3, 2014 at 8:50 PM, Sheng Yang  wrote:
>> > On Mon, Feb 3, 2014 at 11:27 AM, Karl Harris > >wrote:
>> >
>> >> On Mon, Feb 3, 2014 at 2:03 PM, Daan Hoogland > >> >wrote:
>> >>
>> >> >
>> >> > On 03 Feb 2014, at 19:45, Karl Harris 
>> wrote:
>> >> >
>> >> > > On Mon, Feb 3, 2014 at 12:54 PM, Daan Hoogland <
>> >> daan.hoogl...@gmail.com
>> >> > >wrote:
>> >> > >
>> >> > >>
>> >> > >> On 03 Feb 2014, at 18:03, Karl Harris 
>> >> wrote:
>> >> > >>
>> >> > >>> After discussion with my colleagues  questions about initial
>> >> > >>> configuration of the open network redundant routers and the
>> >> > >>> applicability of the existing bash scripts (cloud-early-config)
>> to
>> >> the
>> >> > >>> setup of VPC redundant routers have generated.
>> >> > >>>
>> >> > >>>
>> >> > >>> Some setup first: In the bash script cloud-early-config there is
>> a
>> >> > >>> function named setup_redundant_router which makes copies of
>> several
>> >> > >>> template files. The template files are used to configure
>> keepalived
>> >> > >>> and conntrackd. The template copies are edited, via sed editor,
>> using
>> >> > >>> environment variables ($ROUTER_PR, $ETH0_IP,$NAME, etc.)  which
>> are
>> >> > >>> obtained from the kernel of the current running linux image
>> using the
>> >> > >>> virtual file system /proc/cmdline.
>> >> > >>>
>> >> > >>> I'm sure keepalived and conntrackd  can be used for starting and
>> >> > >>> control of VPC redundant routers. However the setup of
>> keepalived and
>> >> > >>> conntrackd for VPC needs setup parameters which are dynamic
>> because a
>> >> > >>> VPC can have N number of redundant router pairs, not just the
>> fixed
>> >> > >>> number parsed from proc/cmdline in the running kernel.
>> >> > >>>
>> >> > >>> Am I correct in this analysis?
>> >> > >> Karl, I think not. There is only one router in a vac, it routes
>> for
>> >> all
>> >> > >> networks in the virtual private cloud. Am I misreading your
>> >> description.
>> >> > >
>> >> > > Ok then a VPC should contain a single router containing N+1 (N+2 if
>> >> > using a
>> >> > > VPN connection) nic's? Where N is the number of private networks.
>> >> > And I would like to see N+3 as it will allocate another when a
>> private
>> >> > gateway is defined. That is why I proposed to pre-allocate this nic
>> to be
>> >> > able to predict mic-ids, i.e. eth<#>.
>> >> >
>> >> > >
>> >> > > If so then my original question still holds in the sense that the
>> nic's
>> >> > > need to be created in the VM kernel based on the number of private
>> >> > networks
>> >> > > desired?
>> >> >
>> >> > Yes
>> >> >
>> >> > > I found the method update_System_Vm_Templates in the jar file
>>

Re: Working on CloudStack Jira-764:nTier Apps 2.0 : Redundant Virtual Router for VPC email 2 of 2

[Karl Harris]

All,

Here's what I've got so far with partitioning the problem.

There are 3 main areas I've found so far along with a proposal for
implementation.



Keepalived:

As Is:

Current VRR network configuration setup is assumed by the existing code to
be static. A single Keepalived config template file is edited at router VM
boot time. The script cloud-early-config.sh and other BASH scripts are used
to edit the template. The output of the edits is a keepalived.conf file
used to configure the Keepalived application when the router VM boots.

Desired:

Ability (API, Java wrapper?) to  configure/reconfigure Keepalived as the
number of NIC's and other parameters change, a type of CRUD functionality
along with start/stop/restart, which will allow the configuration state of
network to be realized in the CloudStack database and NOT embedded
statically in a combination of keepalived.conf.tmpl, hypervisorbased VM
images and the actual edited keepalived.conf file.  The operational state
of the network is obviously kept by keepalived and conntrackd as well at
the virtual router application itself.


Conntrackd:

As Is:
Current Router state is managed by Conntrackd which is setup similarly to
Keepalived using cloud-early-config.sh BASH script.

Desired:

Similarly to keepalived above: Ability (API, Java wrapper?) to do
CRUD,start,stop,restart on Conntrackd network configuration.


CloudStack Java code:

As is:

CloudStack only allows Virtual redundant routers for a single, static
configuration for public networks mainly because of the lack of the ability
to the existing code to dynamically
change the configuration of the keepalived and conntrackd applications. As
mentioned in a previous thread, it appears most, if not all, of the JAVA
code used for public network redundant routers is available to use for
implementation of VPC virtual redundant routers if the ability to
dynamically reconfigure the network configuration of  keepalived and
conntrackd can be realized. Obviously additions to the JAVA code will need
to be made to utilize the new CRUD functionality for keepalived and
contrackd. As mentioned previously most if not all of the information is
already in the MySQL database accessible via DAO/VO's

Desired:

CloudStack to be able to manipulate the keepalived and conntrackd
applications to allow for dynamic configuration of VPC networks(s) which
require virtual redundant router capability.




Comments on this partitioning of the issues?

Did I miss any major part?




On Thu, Feb 13, 2014 at 3:12 PM, Sheng Yang  wrote:

> Hi Karl,
>
> From Network Guru part of view, there is no VPC or isolated network guru.
> Guru is per network type, e.g. public network, guest network, control
> network, mgmt network. So VPC contained one public and multiple guest
> network, which would be created by each guru accordingly. By this means,
> VPC or isolated network is not a guru.
>
> The configuration of VR is done in VirtualNetworkApplianceManager and
> VPCVirtualNetworkApplianceManager, which would be called by Virtual Router
> element and VPC virtual router element. And they've already passed all the
> information VR needed for VPC. I think every information you needed to
> configure keepalived and conntrackd should be already there, except
> redundant_router=1 parameter.
>
> For original redundant router implementation, there are two major parts of
> code I've heavily modified: how to start two routers in one network(through
> findOrDeployVirtualRouterInGuestNetwork()), and how to program them(through
> cmdline parameter in the VR). I think the VPC implementation would face the
> same issues as well. You can take a look at current implementation and
> follow the code flow, to see if it would help you.
>
> --Sheng
>
> On Wed, Feb 12, 2014 at 11:15 AM, Karl Harris  >wrote:
>
> > On Wed, Feb 12, 2014 at 9:38 AM, Karl Harris  > >wrote:
> >
> > > Would implementing a VPC Redundant Router Network Guru using the an
> > > extension of the NetworkGuru interface be an appropriate way to create
> a
> > > VPC network with redundant routers. It seems that extending Network
> Guru
> > > interface or extending one of it's children eg the abstract class
> > > GuestNetworkGuru would be a appropriate design path.
> > >
> > > Comments?
> > >
> > > Karl
> > >
> > I know the configuration of the VM which implement the redundant routers
> > are handled via BASH scripts and the environment variables int the VM
> > images are used to configure the conntrackd and keepalived applications
> via
> > SED in bash scripts. I am looking for a clean way to pass the variable
> > number of NIC's and then generate the LINK and IGNORE configuration
> > commands for conntrackd.
> >
>

Review Request 18795: Sanity code review for: JIRA CloudStack-764 nTier Apps 2.0 : Redundant Virtual Router for VPC

[Karl Harris]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/18795/
---

Review request for cloudstack.


Repository: cloudstack-git


Description
---

Changes/additions to BASH scripts and .java files as well as pseudo code 
comments. This posting is a sanity check review posting; before I get too far 
along with making the changes required for this JIRA CloudStack-764 nTier Apps 
2.0 : Redundant Virtual Router for VPC I thought I'd publish my intentions to 
the community to review and comment.


Diffs
-

  core/src/com/cloud/agent/api/SetupGuestNetworkCommand.java 
2cf5bf8ffaa2b0df122c69f047ee3f56982267e1 
  
plugins/hypervisors/vmware/src/com/cloud/hypervisor/vmware/resource/VmwareResource.java
 03af0da51b1eec93eb878fd1ebeca2ff2e0802ce 
  
plugins/hypervisors/xen/src/com/cloud/hypervisor/xen/resource/CitrixResourceBase.java
 69b7c9e07c753c0f0c93197a809acfb3399cf555 
  systemvm/patches/debian/config/opt/cloud/bin/vpc_guestnw.sh 
e5da2e096b30f6fdb15226e889517537d04f2e3e 

Diff: https://reviews.apache.org/r/18795/diff/


Testing
---

None, yet still coding


Thanks,

Karl Harris

Re: Review Request 18795: Sanity code review for: JIRA CloudStack-764 nTier Apps 2.0 : Redundant Virtual Router for VPC

[Karl Harris]

Redundancy will be on a vpc basis. I'm attempting to add  CRUD
functionality on a network basis. Does this make sense?

On Thursday, March 6, 2014, daan Hoogland  wrote:

>
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/18795/#review36352
> ---
>
>
> Are you contemplating redundant routing on a per network basis? It would
> seem to me that the router, hence the whole vpc with all it networks is
> redundant or not.
>
> - daan Hoogland
>
>
> On March 5, 2014, 8:20 p.m., Karl Harris wrote:
> >
> > ---
> > This is an automatically generated e-mail. To reply, visit:
> > https://reviews.apache.org/r/18795/
> > ---
> >
> > (Updated March 5, 2014, 8:20 p.m.)
> >
> >
> > Review request for cloudstack.
> >
> >
> > Repository: cloudstack-git
> >
> >
> > Description
> > ---
> >
> > Changes/additions to BASH scripts and .java files as well as pseudo code
> comments. This posting is a sanity check review posting; before I get too
> far along with making the changes required for this JIRA CloudStack-764
> nTier Apps 2.0 : Redundant Virtual Router for VPC I thought I'd publish my
> intentions to the community to review and comment.
> >
> >
> > Diffs
> > -
> >
> >   core/src/com/cloud/agent/api/SetupGuestNetworkCommand.java
> 2cf5bf8ffaa2b0df122c69f047ee3f56982267e1
> >
> plugins/hypervisors/vmware/src/com/cloud/hypervisor/vmware/resource/VmwareResource.java
> 03af0da51b1eec93eb878fd1ebeca2ff2e0802ce
> >
> plugins/hypervisors/xen/src/com/cloud/hypervisor/xen/resource/CitrixResourceBase.java
> 69b7c9e07c753c0f0c93197a809acfb3399cf555
> >   systemvm/patches/debian/config/opt/cloud/bin/vpc_guestnw.sh
> e5da2e096b30f6fdb15226e889517537d04f2e3e
> >
> > Diff: https://reviews.apache.org/r/18795/diff/
> >
> >
> > Testing
> > ---
> >
> > None, yet still coding
> >
> >
> > Thanks,
> >
> > Karl Harris
> >
> >
>
>

-- 
Karl O. Harris
Cloud Software Engineer
Sungard Availability Services

Re: Review Request 18795: Sanity code review for: JIRA CloudStack-764 nTier Apps 2.0 : Redundant Virtual Router for VPC

[Karl Harris]

The description below is what my initial code is working toward:

Turn on VPC redundancy and allow user to do CRUD to the networks just as it
is now.( Create guest networks:NICS, etc; Read guest networks:NICS,etc;
Update guest networks:NICS,etc; Delete guest networks:NICS,etc)   Because
redundancy is turned on, the master AND backup router VM's, as well as
services conntrackd and keepalived running on those router VM's are part of
the creating, reading, updating and deleting of the guest networks.

I am making these changes IN ADDITION to the existing functionality.  I do
not want to break what exists when the redundant routing to VPC's is added,
so yes, in that sense I am trying to keep VPC's and standalone networks
aligned.

Currently, in a VPC,  a SINGLE router  is available without redundant
routers. In a VPC, guest networks can be created, read, updated, deleted
(CRUD) but without any redundancy only one router VM needs to be updated.

With redundancy in VPC's both a master and backup router VM's need to be
changed as well as supporting services conntrackd and keepalived need to be
(re)configured when guest networks are created, read, updated and deleted.

In contrast to VPC's the CloudStack standalone (public) networks currently
offer a redundant network topology which is static so the redundant
topology is created once. If CRUD changes need to be made the routers are
 deleted and created again with the changed configuration; individual
networks are never created or deleted.

A bit more detail:

I understand redundancy is either in the VPC or not. In other words ALL
guest networks within a VPC either have a redundant path or they do not.

Currently there is CRUD for VPC guest networks, you can create, read,
update and delete a guest network in a VPC, however VPC's do NOT have the
ability to offer a redundant path to the guest networks.

My additions to the code are an initial attempt to adapt the existing
network CRUD functionality to a VPC which has a redundant path for all the
guest networks.

When the VPC has redundancy turned on and one creates, reads, updates or
deletes a guest network, both the master and backup router configuration
need to be altered based on what is being changed.   When the VPC has
redundancy turned on the conntrackd and keepalived services need to be
reconfigured and possibly stopped and started when a guest network create,
update or delete takes place.

Let me know if the above is a bit clearer.



Karl




On Thu, Mar 6, 2014 at 8:02 AM, Daan Hoogland wrote:

> Not very much, unless i am missing something. The redundancy can not
> be enabled on a per network basis as the router needs to be in the air
> twice anyway. I would not like to save data that has no use. What CRUD
> are you thinking of? Or are you maybe putting some effort into keeping
> VPC and standalone networks alligned?
>
> On Thu, Mar 6, 2014 at 1:13 PM, Karl Harris 
> wrote:
> > Redundancy will be on a vpc basis. I'm attempting to add  CRUD
> functionality
> > on a network basis. Does this make sense?
> >
> > On Thursday, March 6, 2014, daan Hoogland 
> wrote:
> >>
> >>
> >> ---
> >>
> >> This is an automatically generated e-mail. To reply, visit:
> >> https://reviews.apache.org/r/18795/#review36352
> >> ---
> >>
> >>
> >>
> >> Are you contemplating redundant routing on a per network basis? It would
> >> seem to me that the router, hence the whole vpc with all it networks is
> >> redundant or not.
> >>
> >> - daan Hoogland
> >>
> >>
> >> On March 5, 2014, 8:20 p.m., Karl Harris wrote:
> >> >
> >> > ---
> >>
> >> > This is an automatically generated e-mail. To reply, visit:
> >> > https://reviews.apache.org/r/18795/
> >> > ---
> >> >
> >> > (Updated March 5, 2014, 8:20 p.m.)
> >>
> >> >
> >> >
> >> > Review request for cloudstack.
> >> >
> >> >
> >> > Repository: cloudstack-git
> >> >
> >> >
> >> > Description
> >> > ---
> >> >
> >> > Changes/additions to BASH scripts and .java files as well as pseudo
> code
> >> > comments. This posting is a sanity check review posting; before I get
> too
> >> > far along with making the changes required for this JIRA
> CloudStack-764
> >> > nTier Apps 2.0 : Redundant Virtual Router for VPC I thought I

Re: Review Request 18795: Sanity code review for: JIRA CloudStack-764 nTier Apps 2.0 : Redundant Virtual Router for VPC

[Karl Harris]

> On March 6, 2014, 10:09 a.m., daan Hoogland wrote:
> > Are you contemplating redundant routing on a per network basis? It would 
> > seem to me that the router, hence the whole vpc with all it networks is 
> > redundant or not.

The description below is what my initial code is working toward:

Turn on VPC redundancy and allow user to do CRUD to the networks just as it is 
now.( Create guest networks:NICS, etc; Read guest networks:NICS,etc; Update 
guest networks:NICS,etc; Delete guest networks:NICS,etc)   Because redundancy 
is turned on, the master AND backup router VM's, as well as services conntrackd 
and keepalived running on those router VM's are part of the creating, reading, 
updating and deleting of the guest networks. 

I am making these changes IN ADDITION to the existing functionality.  I do not 
want to break what exists when the redundant routing to VPC's is added, so yes, 
in that sense I am trying to keep VPC's and standalone networks aligned.

Currently, in a VPC,  a SINGLE router  is available without redundant routers. 
In a VPC, guest networks can be created, read, updated, deleted (CRUD) but 
without any redundancy only one router VM needs to be updated.  

With redundancy in VPC's both a master and backup router VM's need to be 
changed as well as supporting services conntrackd and keepalived need to be 
(re)configured when guest networks are created, read, updated and deleted. 

In contrast to VPC's the CloudStack standalone (public) networks currently 
offer a redundant network topology which is static so the redundant topology is 
created once. If CRUD changes need to be made the routers are  deleted and 
created again with the changed configuration; individual networks are never 
created or deleted.  

A bit more detail:

I understand redundancy is either in the VPC or not. In other words ALL guest 
networks within a VPC either have a redundant path or they do not. 

Currently there is CRUD for VPC guest networks, you can create, read, update 
and delete a guest network in a VPC, however VPC's do NOT have the ability to 
offer a redundant path to the guest networks.

My additions to the code are an initial attempt to adapt the existing network 
CRUD functionality to a VPC which has a redundant path for all the guest 
networks. 

When the VPC has redundancy turned on and one creates, reads, updates or 
deletes a guest network, both the master and backup router configuration need 
to be altered based on what is being changed.   When the VPC has redundancy 
turned on the conntrackd and keepalived services need to be reconfigured and 
possibly stopped and started when a guest network create, update or delete 
takes place.


- Karl


---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/18795/#review36352
-------


On March 5, 2014, 8:20 p.m., Karl Harris wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/18795/
> ---
> 
> (Updated March 5, 2014, 8:20 p.m.)
> 
> 
> Review request for cloudstack.
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> Changes/additions to BASH scripts and .java files as well as pseudo code 
> comments. This posting is a sanity check review posting; before I get too far 
> along with making the changes required for this JIRA CloudStack-764 nTier 
> Apps 2.0 : Redundant Virtual Router for VPC I thought I'd publish my 
> intentions to the community to review and comment.
> 
> 
> Diffs
> -
> 
>   core/src/com/cloud/agent/api/SetupGuestNetworkCommand.java 
> 2cf5bf8ffaa2b0df122c69f047ee3f56982267e1 
>   
> plugins/hypervisors/vmware/src/com/cloud/hypervisor/vmware/resource/VmwareResource.java
>  03af0da51b1eec93eb878fd1ebeca2ff2e0802ce 
>   
> plugins/hypervisors/xen/src/com/cloud/hypervisor/xen/resource/CitrixResourceBase.java
>  69b7c9e07c753c0f0c93197a809acfb3399cf555 
>   systemvm/patches/debian/config/opt/cloud/bin/vpc_guestnw.sh 
> e5da2e096b30f6fdb15226e889517537d04f2e3e 
> 
> Diff: https://reviews.apache.org/r/18795/diff/
> 
> 
> Testing
> ---
> 
> None, yet still coding
> 
> 
> Thanks,
> 
> Karl Harris
> 
>

Re: Review Request 18795: Sanity code review for: JIRA CloudStack-764 nTier Apps 2.0 : Redundant Virtual Router for VPC

[Karl Harris]

The functional spec for Redundant Virtual Router for VPC's states:
Deployment for RvR

   - Mgmt server would try to deploy two VR in the physical devices as far
   apart as possible. It would try different pod, different cluster, different
   storage, different host first, until there is none of above condition can
   be met, it would deploy both of them in the same host.



Is a design method in a PrivateRedundantNetworkGuru NetworkGuru class(es)
the most appropriate place to put this code?

Separate Guru's for each of the pod,cluster,storage, host entities or a
single Guru that "designs" using the above criteria?

Karl


On Wed, Mar 5, 2014 at 3:20 PM, Karl Harris  wrote:

>
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/18795/
> ---
>
> Review request for cloudstack.
>
>
> Repository: cloudstack-git
>
>
> Description
> ---
>
> Changes/additions to BASH scripts and .java files as well as pseudo code
> comments. This posting is a sanity check review posting; before I get too
> far along with making the changes required for this JIRA CloudStack-764
> nTier Apps 2.0 : Redundant Virtual Router for VPC I thought I'd publish my
> intentions to the community to review and comment.
>
>
> Diffs
> -
>
>   core/src/com/cloud/agent/api/SetupGuestNetworkCommand.java
> 2cf5bf8ffaa2b0df122c69f047ee3f56982267e1
>
> plugins/hypervisors/vmware/src/com/cloud/hypervisor/vmware/resource/VmwareResource.java
> 03af0da51b1eec93eb878fd1ebeca2ff2e0802ce
>
> plugins/hypervisors/xen/src/com/cloud/hypervisor/xen/resource/CitrixResourceBase.java
> 69b7c9e07c753c0f0c93197a809acfb3399cf555
>   systemvm/patches/debian/config/opt/cloud/bin/vpc_guestnw.sh
> e5da2e096b30f6fdb15226e889517537d04f2e3e
>
> Diff: https://reviews.apache.org/r/18795/diff/
>
>
> Testing
> ---
>
> None, yet still coding
>
>
> Thanks,
>
> Karl Harris
>
>

Re: Review Request 18795: Sanity code review for: JIRA CloudStack-764 nTier Apps 2.0 : Redundant Virtual Router for VPC

[Karl Harris]

Using the Cloudstack definition of Network
Service<http://www.slideshare.net/kkitase/3-networking-cloudstack-developer-day>as
a foundation my question is: Should the VPC Virtual Redundant Router
be
considered a Network Service?

I'm conflicted. The user can turn on redundancy however the redundant
functionality is really a type of router, not a L2-L7 network function.

If not, should the implementation be implemented as an additional router
(virtual device, separate router vm template image, etc)  or additional
functionality (the ability to provide redundant services
without L2-L7 knowing about it) to the existing virtual router modifying
the existing router vm template?

A related question is should the vrr
protocol<http://en.wikipedia.org/wiki/Virtual_Router_Redundancy_Protocol>
used
by Keepalived <http://www.keepalived.org/> be passed on the Cloudstack
Management network or an isolated network between the master and
backup router?


On Tue, Apr 22, 2014 at 5:57 AM, Daan Hoogland wrote:

> Sounds like a single guru should do the job.
> Also I would think of some offerings that contain affinity so that the
> guru has a guideline as to where to deploy the pair of routers. For a
> certain type of network design a admin may already know where the
> routers should be deployed and in that case it makes no sense to let
> the guru do any calculations on that. The admin should be able to
> specify it with tags or the likes. Of course the criteria you mention
> must not conflict but I think it makes sense to have a admin created
> offering override the standard algorithm.
>
> regards,
> Daan
>
> On Mon, Apr 21, 2014 at 9:21 PM, Karl Harris 
> wrote:
> > The functional spec for Redundant Virtual Router for VPC's states:
> > Deployment for RvR
> >
> >- Mgmt server would try to deploy two VR in the physical devices as
> far
> >apart as possible. It would try different pod, different cluster,
> different
> >storage, different host first, until there is none of above condition
> can
> >be met, it would deploy both of them in the same host.
> >
> >
> >
> > Is a design method in a PrivateRedundantNetworkGuru NetworkGuru class(es)
> > the most appropriate place to put this code?
> >
> > Separate Guru's for each of the pod,cluster,storage, host entities or a
> > single Guru that "designs" using the above criteria?
> >
> > Karl
> >
> >
> > On Wed, Mar 5, 2014 at 3:20 PM, Karl Harris 
> wrote:
> >
> >>
> >> ---
> >> This is an automatically generated e-mail. To reply, visit:
> >> https://reviews.apache.org/r/18795/
> >> ---
> >>
> >> Review request for cloudstack.
> >>
> >>
> >> Repository: cloudstack-git
> >>
> >>
> >> Description
> >> ---
> >>
> >> Changes/additions to BASH scripts and .java files as well as pseudo code
> >> comments. This posting is a sanity check review posting; before I get
> too
> >> far along with making the changes required for this JIRA CloudStack-764
> >> nTier Apps 2.0 : Redundant Virtual Router for VPC I thought I'd publish
> my
> >> intentions to the community to review and comment.
> >>
> >>
> >> Diffs
> >> -
> >>
> >>   core/src/com/cloud/agent/api/SetupGuestNetworkCommand.java
> >> 2cf5bf8ffaa2b0df122c69f047ee3f56982267e1
> >>
> >>
> plugins/hypervisors/vmware/src/com/cloud/hypervisor/vmware/resource/VmwareResource.java
> >> 03af0da51b1eec93eb878fd1ebeca2ff2e0802ce
> >>
> >>
> plugins/hypervisors/xen/src/com/cloud/hypervisor/xen/resource/CitrixResourceBase.java
> >> 69b7c9e07c753c0f0c93197a809acfb3399cf555
> >>   systemvm/patches/debian/config/opt/cloud/bin/vpc_guestnw.sh
> >> e5da2e096b30f6fdb15226e889517537d04f2e3e
> >>
> >> Diff: https://reviews.apache.org/r/18795/diff/
> >>
> >>
> >> Testing
> >> ---
> >>
> >> None, yet still coding
> >>
> >>
> >> Thanks,
> >>
> >> Karl Harris
> >>
> >>
>
>
>
> --
> Daan
>
>

Re: Review Request 18795: Sanity code review for: JIRA CloudStack-764 nTier Apps 2.0 : Redundant Virtual Router for VPC

[Karl Harris]

Daan,

I appears your response was truncated.

Karl



On Thu, Apr 24, 2014 at 3:41 PM, Daan Hoogland wrote:

> One answer inline...
>
> mobile bilingual spell checker used
>
> Op 24 apr. 2014 16:54 schreef "Karl Harris" :
> 
> > A related question is should the vrr
> > protocol<http://en.wikipedia.org/wiki/Virtual_Router_Redundancy_Protocol
> >
> > used
> > by Keepalived <http://www.keepalived.org/> be passed on the Cloudstack
> > Management network or an isolated network between the master and
> > backup router?
> On all the networks that should be served redundantly, e.g. all.
>
> >
> >
> > On Tue, Apr 22, 2014 at 5:57 AM, Daan Hoogland  >wrote:
> >
> > > Sounds like a single guru should do the job.
> > > Also I would think of some offerings that contain affinity so that the
> > > guru has a guideline as to where to deploy the pair of routers. For a
> > > certain type of network design a admin may already know where the
> > > routers should be deployed and in that case it makes no sense to let
> > > the guru do any calculations on that. The admin should be able to
> > > specify it with tags or the likes. Of course the criteria you mention
> > > must not conflict but I think it makes sense to have a admin created
> > > offering override the standard algorithm.
> > >
> > > regards,
> > > Daan
> > >
> > > On Mon, Apr 21, 2014 at 9:21 PM, Karl Harris <
> karl.har...@sungardas.com>
> > > wrote:
> > > > The functional spec for Redundant Virtual Router for VPC's states:
> > > > Deployment for RvR
> > > >
> > > >- Mgmt server would try to deploy two VR in the physical devices
> as
> > > far
> > > >apart as possible. It would try different pod, different cluster,
> > > different
> > > >storage, different host first, until there is none of above
> condition
> > > can
> > > >be met, it would deploy both of them in the same host.
> > > >
> > > >
> > > >
> > > > Is a design method in a PrivateRedundantNetworkGuru NetworkGuru
> class(es)
> > > > the most appropriate place to put this code?
> > > >
> > > > Separate Guru's for each of the pod,cluster,storage, host entities or
> a
> > > > single Guru that "designs" using the above criteria?
> > > >
> > > > Karl
> > > >
> > > >
> > > > On Wed, Mar 5, 2014 at 3:20 PM, Karl Harris  >
> > > wrote:
> > > >
> > > >>
> > > >> ---
> > > >> This is an automatically generated e-mail. To reply, visit:
> > > >> https://reviews.apache.org/r/18795/
> > > >> ---
> > > >>
> > > >> Review request for cloudstack.
> > > >>
> > > >>
> > > >> Repository: cloudstack-git
> > > >>
> > > >>
> > > >> Description
> > > >> ---
> > > >>
> > > >> Changes/additions to BASH scripts and .java files as well as pseudo
> code
> > > >> comments. This posting is a sanity check review posting; before I
> get
> > > too
> > > >> far along with making the changes required for this JIRA
> CloudStack-764
> > > >> nTier Apps 2.0 : Redundant Virtual Router for VPC I thought I'd
> publish
> > > my
> > > >> intentions to the community to review and comment.
> > > >>
> > > >>
> > > >> Diffs
> > > >> -
> > > >>
> > > >>   core/src/com/cloud/agent/api/SetupGuestNetworkCommand.java
> > > >> 2cf5bf8ffaa2b0df122c69f047ee3f56982267e1
> > > >>
> > > >>
> > >
>
> plugins/hypervisors/vmware/src/com/cloud/hypervisor/vmware/resource/VmwareResource.java
> > > >> 03af0da51b1eec93eb878fd1ebeca2ff2e0802ce
> > > >>
> > > >>
> > >
>
> plugins/hypervisors/xen/src/com/cloud/hypervisor/xen/resource/CitrixResourceBase.java
> > > >> 69b7c9e07c753c0f0c93197a809acfb3399cf555
> > > >>   systemvm/patches/debian/config/opt/cloud/bin/vpc_guestnw.sh
> > > >> e5da2e096b30f6fdb15226e889517537d04f2e3e
> > > >>
> > > >> Diff: https://reviews.apache.org/r/18795/diff/
> > > >>
> > > >>
> > > >> Testing
> > > >> ---
> > > >>
> > > >> None, yet still coding
> > > >>
> > > >>
> > > >> Thanks,
> > > >>
> > > >> Karl Harris
> > > >>
> > > >>
> > >
> > >
> > >
> > > --
> > > Daan
> > >
> > >
>

Re: Review Request 18795: Sanity code review for: JIRA CloudStack-764 nTier Apps 2.0 : Redundant Virtual Router for VPC

[Karl Harris]

Daan,

Much clearer response, Thanks.

Be Well.

Karl



On Fri, Apr 25, 2014 at 8:05 AM, Daan Hoogland wrote:

> H Karl, it doesn't appear so to me. My point was that keepalive should
> run over any interface that needs to be guarded. This menas all the
> guestnetworks, the optional private gateway network and the management
> and possibly even the public interface.
>
> maybe I was a little short on words describing this.
>
> Daan
>
> On Thu, Apr 24, 2014 at 9:49 PM, Karl Harris 
> wrote:
> > Daan,
> >
> > I appears your response was truncated.
> >
> > Karl
> >
> >
> >
> > On Thu, Apr 24, 2014 at 3:41 PM, Daan Hoogland  >wrote:
> >
> >> One answer inline...
> >>
> >> mobile bilingual spell checker used
> >>
> >> Op 24 apr. 2014 16:54 schreef "Karl Harris"  >:
> >> 
> >> > A related question is should the vrr
> >> > protocol<
> http://en.wikipedia.org/wiki/Virtual_Router_Redundancy_Protocol
> >> >
> >> > used
> >> > by Keepalived <http://www.keepalived.org/> be passed on the
> Cloudstack
> >> > Management network or an isolated network between the master and
> >> > backup router?
> >> On all the networks that should be served redundantly, e.g. all.
> >>
> >> >
> >> >
> >> > On Tue, Apr 22, 2014 at 5:57 AM, Daan Hoogland <
> daan.hoogl...@gmail.com
> >> >wrote:
> >> >
> >> > > Sounds like a single guru should do the job.
> >> > > Also I would think of some offerings that contain affinity so that
> the
> >> > > guru has a guideline as to where to deploy the pair of routers. For
> a
> >> > > certain type of network design a admin may already know where the
> >> > > routers should be deployed and in that case it makes no sense to let
> >> > > the guru do any calculations on that. The admin should be able to
> >> > > specify it with tags or the likes. Of course the criteria you
> mention
> >> > > must not conflict but I think it makes sense to have a admin created
> >> > > offering override the standard algorithm.
> >> > >
> >> > > regards,
> >> > > Daan
> >> > >
> >> > > On Mon, Apr 21, 2014 at 9:21 PM, Karl Harris <
> >> karl.har...@sungardas.com>
> >> > > wrote:
> >> > > > The functional spec for Redundant Virtual Router for VPC's states:
> >> > > > Deployment for RvR
> >> > > >
> >> > > >- Mgmt server would try to deploy two VR in the physical
> devices
> >> as
> >> > > far
> >> > > >apart as possible. It would try different pod, different
> cluster,
> >> > > different
> >> > > >storage, different host first, until there is none of above
> >> condition
> >> > > can
> >> > > >be met, it would deploy both of them in the same host.
> >> > > >
> >> > > >
> >> > > >
> >> > > > Is a design method in a PrivateRedundantNetworkGuru NetworkGuru
> >> class(es)
> >> > > > the most appropriate place to put this code?
> >> > > >
> >> > > > Separate Guru's for each of the pod,cluster,storage, host
> entities or
> >> a
> >> > > > single Guru that "designs" using the above criteria?
> >> > > >
> >> > > > Karl
> >> > > >
> >> > > >
> >> > > > On Wed, Mar 5, 2014 at 3:20 PM, Karl Harris <
> karl.har...@sungard.com
> >> >
> >> > > wrote:
> >> > > >
> >> > > >>
> >> > > >> ---
> >> > > >> This is an automatically generated e-mail. To reply, visit:
> >> > > >> https://reviews.apache.org/r/18795/
> >> > > >> ---
> >> > > >>
> >> > > >> Review request for cloudstack.
> >> > > >>
> >> > > >>
> >> > > >> Repository: cloudstack-git
> >> > > >>
> >> > > >>
> >> > > >> Description
> >> > > >> --

Re: Working on CloudStack Jira-764:nTier Apps 2.0 : Redundant Virtual Router for VPC email 2 of 2

[Karl Harris]

All,

I have made changes to the shell scripts within the CloudStack system
virtual machines that implement virtual routers for virtual private cloud.

Question:

What is the best way to test these scripts at the command line level?

 I want to test my changes directly with a image of the vm which contains
my changes to the shell scripts bypassing the console proxy vm. See
previous emails, in this thread, for the changes: basically a ethernet port
CRUD for virtual redundant router.

My first thought is to rebuild the system vm image then spin up a VM in
VBOX and log into the command line console by setting the appropriate keys
similar to the console proxy.

I am asking the list if there are any other ways of testing this and
generating unit tests.

What was used in the past to test the system vm's?

Karl





On Wed, Jan 15, 2014 at 3:57 PM, Karl Harris wrote:

>
>
> -- Forwarded message --
> From: Daan Hoogland 
> Date: Wed, Jan 15, 2014 at 2:51 PM
> Subject: Re: rvr4vpc
> To: Karl Harris 
> Cc: Christopher Litsinger 
>
>
> H Karl,
>
> Thanks for sharing. I didn't want to initiate this but I encourage you
> to share this on the dev list (not in jira) as things are only
> considered 'discussed' if they passed by there.
>
> You speak of '1 Get configuration data on Source Nat Router', I don't
> understand why you call the router by this designation. 'Source Nat'
> is only one of it's many possible functions.
>
> Apart from the design principles I shared with you I have so far only
> a technical implementation detail so far. That is to reserve the
> (eth2) interface for the private gateway on the vpc (r)vr. This way
> the inteface to configure are somewhat predictable.
>
> As for the design principle to have a statefull router (reboot proof)
> the idea is to implement a configuration file that will be uploaded to
> the router after which a self-config command is send that will
> implement the details of configuring the interfaces, haproxy and
> keepalived and maybe more. I think your current assessment of the
> working of the RVRs is accurate but it will not be workable for an
> implementation for vpc's as they have an unpreditable number of
> interfaces.
>
> to bad you can't make it next thursday,
> Daan Hoogland
>
>
> On Wed, Jan 15, 2014 at 3:25 PM, Karl Harris 
> wrote:
> > Daan,
> >
> > Sorry for the delayed response but as Christopher mentioned to you in his
> > email I am getting my head around the CloudStack software.
> > Since I am new to CloudStack but "old" to enterprise level JAVA the task
> is
> > large but not impossible. I have no experience with running CloudStack
> but
> > considerable experience designing and maintaining large JAVA
> applications.
> >
> > I've created what I believe is a very high level abstract of how the
> current
> > guest VRR's are created for guest networks with the intent of making this
> > abstract
> > more detailed.
> >
> > 1 Get configuration data on Source Nat Router  selected as a redundant
> > router
> >1.1 Public and Guest network identified.
> > 2 Both routers are provisioned
> >2.1 Software  trys different, regions(?),zones,pods,clusters,hosts in
> > that order as the location of the router. Log maximum “distance” apart.
> > 3 Keepalived is configured
> > 4 Both routers are started
> > 5 Keepalived is started
> >
> > Obviously there is much more that is happening under each of the steps
> > above. My intent is to complete this detailed "as is" listing as much as
> we
> > can. Then  using the "as is" description/sequence
> > make a "to-be" addition for VPC's. When I get a consensus on WHAT needs
> to
> > be implemented for the VRR in VPC  then develop HOW best to implement the
> > "to-be" addition with the
> > existing JAVA code as well as what additional classes need to be
> > extended/implemented/created.
> >
> > Comments, critiques and changes to the above sequence are encouraged.
> >
> > I plan on posting this to the dev-list/Jira very soon.
> >
> > I have been using this functional spec as a guide, after discussing this
> > with our Systems Engineering people this spec meets our requirements.
> >
> > Do you have an implementation in mind?
> >
> > We have an internal Cloud Meeting with conflicts with the cloudstack
> "day"
> > next week so I will not be in attendence.
> >
> > Karl
> >
> >
> >
> >
> >
> >
> >
> > On Tue, Jan 14, 2014 at 4:35 PM, Daan

Re: redundant virtual routers for VPCs

[Karl Harris]

I will be happy to join!



On Saturday, June 7, 2014, Daan Hoogland  wrote:

> At Schuberg Philis, the urge to have virtual routers in a redundant
> way is getting to be pressing. It seems Citrix wants to move away from
> it entirely and Sungard is working on it but has to little resources
> for it. Withing our dev group we are now planning a sprint to
> experiment with this subject and then implement or fix the present
> routers to support this. However we would very much like input from
> the people who have already worked on this and are also very willing
> to let them in our sprint-team if they are willing.
>
> So: who want to join in a irc meeting (or conf call) on the subject
> coming week? Dutch people are not in the office on the day after
> ascension so tuesday is our intention.
>
> on behalf of some very impatient operators;)
> --
> Daan
>
>

Re: redundant virtual routers for VPCs

[Karl Harris]

Recovering from a laptop hard disk crash should be back online by 22:00 UTC!

Karl


On Tuesday, June 10, 2014, Daan Hoogland  wrote:

> I would like to have Hugo in the meeting So let's make it 20:00 UTC
>
> I would suggest #cloudstack-meeting
>
> On Tue, Jun 10, 2014 at 10:29 AM, Hugo Trippaers 
> wrote:
> >
> > I can’t make 15:00, but 22:00 could work.
> >
> > Cheers,
> >
> > Hugo
> >
> >
> > On 10 jun. 2014, at 10:14, Daan Hoogland 
> wrote:
> >
> >> Quite right:
> >>
> >>
> >> -  Feasibility experiment plans by Schuberg Philis
> >>
> >> -  Reusable work by Karl
> >>
> >> -  Problems Citrix encountered with the regular redundant
> router (and how to avoid them)
> >>
> >> -  Work division
> >>
> >> -  (next meeting needed?)
> >>
> >> Any additions?
> >>
> >> \DaanH
> >>
> >> From: Sheng Yang [mailto:sh...@yasker.org]
> >> Sent: dinsdag 10 juni 2014 1:39
> >> To: Sander Botman
> >> Cc: Daan Hoogland; Karl Harris; dev; Alena Prokharchyk;
> kis...@cloud.com; Christopher Litsinger; Hugo Trippaers; int-toolkit
> >> Subject: Re: redundant virtual routers for VPCs
> >>
> >> BTW, do we have an agenda or some topics we want to discuss for the
> meeting? I just want to make sure it's efficient.
> >>
> >> --Sheng
> >>
> >> On Mon, Jun 9, 2014 at 1:14 PM, Sander Botman <
> sbot...@schubergphilis.com<mailto:sbot...@schubergphilis.com>> wrote:
> >> Hi all
> >>
> >> I can make 15:00.
> >>
> >> Cannon join at 20:00.
> >>
> >> Cheers Sander
> >>
> >> Verstuurd vanaf mijn iPhone
> >>
> >>> Op 9 jun. 2014 om 21:31 heeft "Daan Hoogland"  <mailto:daan.hoogl...@gmail.com>> het volgende geschreven:
> >>>
> >>> nice,
> >>>
> >>> so given pacific time I can have a meeting at 15:00 utc or at 20:00
> >>> utc (8 am or 2 pm if I'm correct). Given office hours in Holland 17:00
> >>> (15:00 utc) would be best but if you're not in it could be later. As
> >>> the person calling the meeting I would like to participate but if the
> >>> highest attendance can be found only between 16 and 22 utc thats fine
> >>> as well.
> >>>
> >>>> On Mon, Jun 9, 2014 at 8:35 PM, Karl Harris <
> karl.har...@sungardas.com<mailto:karl.har...@sungardas.com>> wrote:
> >>>> I will be happy to join!
> >>>>
> >>>>
> >>>>
> >>>>> On Saturday, June 7, 2014, Daan Hoogland  <mailto:daan.hoogl...@gmail.com>> wrote:
> >>>>>
> >>>>> At Schuberg Philis, the urge to have virtual routers in a redundant
> >>>>> way is getting to be pressing. It seems Citrix wants to move away
> from
> >>>>> it entirely and Sungard is working on it but has to little resources
> >>>>> for it. Withing our dev group we are now planning a sprint to
> >>>>> experiment with this subject and then implement or fix the present
> >>>>> routers to support this. However we would very much like input from
> >>>>> the people who have already worked on this and are also very willing
> >>>>> to let them in our sprint-team if they are willing.
> >>>>>
> >>>>> So: who want to join in a irc meeting (or conf call) on the subject
> >>>>> coming week? Dutch people are not in the office on the day after
> >>>>> ascension so tuesday is our intention.
> >>>>>
> --
> Daan
>

Re: redundant virtual routers for VPCs

[Karl Harris]

20:00 utc ;-) missed the last change in time!


Karl


On Tuesday, June 10, 2014, Daan Hoogland 
wrote:

>  Karl, That’s midnight over here! :(
>
>
>
> *\*DaanH
>
>
>
> *From:* Karl Harris [mailto:karl.har...@sungardas.com
> ]
> *Sent:* dinsdag 10 juni 2014 2:43
> *To:* Daan Hoogland
> *Cc:* Hugo Trippaers; dev; Sheng Yang; Sander Botman; Alena Prokharchyk;
> kis...@cloud.com ;
> Christopher Litsinger; Hugo Trippaers; int-toolkit
> *Subject:* Re: redundant virtual routers for VPCs
>
>
>
> Recovering from a laptop hard disk crash should be back online by 22:00
> UTC!
>
>
>
> Karl
>
>
>
> On Tuesday, June 10, 2014, Daan Hoogland  wrote:
>
> I would like to have Hugo in the meeting So let's make it 20:00 UTC
>
> I would suggest #cloudstack-meeting
>
> On Tue, Jun 10, 2014 at 10:29 AM, Hugo Trippaers 
> wrote:
> >
> > I can’t make 15:00, but 22:00 could work.
> >
> > Cheers,
> >
> > Hugo
> >
> >
> > On 10 jun. 2014, at 10:14, Daan Hoogland 
> wrote:
> >
> >> Quite right:
> >>
> >>
> >> -  Feasibility experiment plans by Schuberg Philis
> >>
> >> -  Reusable work by Karl
> >>
> >> -  Problems Citrix encountered with the regular redundant
> router (and how to avoid them)
> >>
> >> -  Work division
> >>
> >> -  (next meeting needed?)
> >>
> >> Any additions?
> >>
> >> \DaanH
> >>
> >> From: Sheng Yang [mailto:sh...@yasker.org]
> >> Sent: dinsdag 10 juni 2014 1:39
> >> To: Sander Botman
> >> Cc: Daan Hoogland; Karl Harris; dev; Alena Prokharchyk;
> kis...@cloud.com; Christopher Litsinger; Hugo Trippaers; int-toolkit
> >> Subject: Re: redundant virtual routers for VPCs
> >>
> >> BTW, do we have an agenda or some topics we want to discuss for the
> meeting? I just want to make sure it's efficient.
> >>
> >> --Sheng
> >>
> >> On Mon, Jun 9, 2014 at 1:14 PM, Sander Botman <
> sbot...@schubergphilis.com<mailto:sbot...@schubergphilis.com>> wrote:
> >> Hi all
> >>
> >> I can make 15:00.
> >>
> >> Cannon join at 20:00.
> >>
> >> Cheers Sander
> >>
> >> Verstuurd vanaf mijn iPhone
> >>
> >>> Op 9 jun. 2014 om 21:31 heeft "Daan Hoogland" <
> daan.hoogl...@gmail.com<mailto:daan.hoogl...@gmail.com>> het volgende
> geschreven:
> >>>
> >>> nice,
> >>>
> >>> so given pacific time I can have a meeting at 15:00 utc or at 20:00
> >>> utc (8 am or 2 pm if I'm correct). Given office hours in Holland 17:00
> >>> (15:00 utc) would be best but if you're not in it could be later. As
> >>> the person calling the meeting I would like to participate but if the
> >>> highest attendance can be found only between 16 and 22 utc thats fine
> >>> as well.
> >>>
> >>>> On Mon, Jun 9, 2014 at 8:35 PM, Karl Harris <
> karl.har...@sungardas.com<mailto:karl.har...@sungardas.com>> wrote:
> >>>> I will be happy to join!
> >>>>
> >>>>
> >>>>
> >>>>> On Saturday, June 7, 2014, Daan Hoogland <
> daan.hoogl...@gmail.com<mailto:daan.hoogl...@gmail.com>> wrote:
> >>>>>
> >>>>> At Schuberg Philis, the urge to have virtual routers in a redundant
> >>>>> way is getting to be pressing. It seems Citrix wants to move away
> from
> >>>>> it entirely and Sungard is working on it but has to little resources
> >>>>> for it. Withing our dev group we are now planning a sprint to
> >>>>> experiment with this subject and then implement or fix the present
> >>>>> routers to support this. However we would very much like input from
> >>>>> the people who have already worked on this and are also
>

Re: irc meeting on rvr4vpc

[Karl Harris]

Outlined below is an overview of the analysis and in process work for
adding Virtual Redundant Routing to CloudStack Virtual Private Clouds.


Current state:

Public networks allow for redundant VR (Virtual Routers).
The network topology is static. The network topology consists of a single
guest
network and a public network. The VR redundancy is implemented using a
second VR
and KeepAlived and Conntrackd software packages configured to match the
static
network topology. The static network topology is configured using parameters
passed to the VR Linux image using /proc/cmdline. The /proc/cmdline line
information
is parsed by a shell script called cloud-early-config.sh. The appropriate
parameters
required for VR redundant setup are used to configured the KeepAlived and
Conntrackd
packages if a boolean named redundant_router is true(1). While changes can
be made
to the guest network using the script guestnw.sh; this shell script assumes
the topology
of the network will not change.

Desired state:

Redundant VR's should be available in not only Public Networks but also
Virtual Private Clouds (VPC)
under CloudStack.

Issues:

VPC allow for, among other things, networks with a dynamic topology, aka
tiers.

Current shells scripts that configure redundant VR's in public networks
cannot
Create, Read, Update, or Delete (CRUD) virtual networks and VR's because of
the
the script(s) and programs used to change the guest network assume a static
network topology.

Minimal unit testing for CRUD functions.


Current Work in Process:

Generate Unit tests to Create, Read, Update and Delete for both redundant
and non redundant
networks using a single System Vritual Machine image VM based on changes to
script files
below.

Generate Unit test to verify VPCVirtualNetworkApplianceManagerImpl.java
will work with CRUD
enabled scripts.

Add the interface and ability to do network CRUD to guestnw.sh and
cloud-early-config.sh.

Modify VPCVirtualNetworkApplianceManagerImpl to allow changes to guest
network using
new CRUD functionality of guesnw.sh mentioned above.

Modify UI and other Java code as required for implantation of VPC redundant
routers.

Karl


On Wed, Jun 11, 2014 at 3:16 PM, Sheng Yang  wrote:

> One note:
>
> In fact the split of MASTER is not a big issue, because that would only
> happen if network runs bad enough, which already cause packet loss.
>
> The problem is it should recover from that situation fast enough.
> Previously due to ARP ping from BACKUP router(which thought it would
> replace MASTER), upstream switch would redirect the traffic to original
> BACKUP router for a while, then as soon as network recovered, MASTER would
> preempt BACKUP once again. But it may take some time for upstream switch to
> aware that MAC/Port/IP mapping has been changed. We once tried different
> MAC for MASTER and BACKUP but found it would result in upstream switch fail
> to recognize the MASTER again. Now we're still using same MAC for MASTER
> and BACKUP, and upstream switch can handle the situation better.
>
> --Sheng
>
>
> On Wed, Jun 11, 2014 at 12:48 AM, Daan Hoogland <
> dhoogl...@schubergphilis.com> wrote:
>
> > H,
> >
> > We had a little meeting on the state of this feature and the way to go. I
> > have no karma for ASFBot meetings so here is my excerpt from the
> transcript:
> >
> > Attendance:
> > K3KH Karl Harris
> > Yasker Sheng Yang
> > Spark404 Hugo Trippaers
> > echaz Eric Chazas
> > LeoSimons Leo Simons
> > dahn Daan Hoogland
> >
> > others where present in the room but not active in the meeting
> >
> > Agenda:
> > -  Feasibility experiment plans by Schuberg Philis
> > -  Reusable work by Karl
> > -  Problems Citrix encountered with the regular redundant router
> > (and how to avoid them)
> > -  Work division
> > -  (next meeting needed?)
> >
> > We tried to follow the agenda but were not very strict on it. I'll
> > summarize outcome per agenda bullet:
> >
> > Schuberg Philis wants to implement a feasibility redundant router on a
> > simulated vpc environment using the operational expertise it has in
> house.
> > The outcome would then be back ported to the device, it's agent and the
> > management server.
> >
> > The implementation tactics is to create a json like configuration
> > description and to let the device do its own configuration. The idea is
> to
> > have a single device for normal and vpc routers and to let the redundancy
> > be a mere property of it. This should lead to the ultimate objective
> which
> > is to have a single relatively simple maintainable device.
> >
> > Karl will describe his endeavors in adapting the exi

Testing a Cloudstack Virtual Router (SystemVM).

[Karl Harris]

What is the current framework used to test a Cloudstack Virtual Router
(SystemVM) in isolation aka without Management Server if any?

I'd like to call a SystemVM script with a set of configuration parameters
(changes for VPCVrr, etc.) and observe the changes to the virtual routers
configuration.

Since I will eventually need the ethernet connections to be added and
deleted I would like to aviod using ethernet to make the connection to the
SystemVM image. Ideally I don't want to change the SystemVM image from what
is build by tools/appliance/build.sh.

How was this testing done in the past?

Thanks,

Karl

Re: Testing a Cloudstack Virtual Router (SystemVM).

[Karl Harris]

How is the unit testing accomplished for changes to the
configuration/startup scripts? I can obviously run the scripts in a
different Debian build!
Im trying to build something that can be tested easily without many changes
to the baseline System VM image.

The current System VM build runs under vbox freestanding but has no net
work unless parameter are passed to it via Grub/proc/cmdline which is used
by cloud-early-config.sh to set up the network.

How was the unit testing done in the past?

Or was iit ntegration testing only?


On Tuesday, July 8, 2014, Rohit Yadav  wrote:

> Hi Karl,
>
> Karl Harris wrote:
>
>> What is the current framework used to test a Cloudstack Virtual Router
>> (SystemVM) in isolation aka without Management Server if any?
>>
>
> AFAIK we don't have any such testing/automation framework within Apache
> CloudStack.
>
>  I'd like to call a SystemVM script with a set of configuration parameters
>> (changes for VPCVrr, etc.) and observe the changes to the virtual routers
>> configuration.
>>
>> Since I will eventually need the ethernet connections to be added and
>> deleted I would like to aviod using ethernet to make the connection to the
>> SystemVM image. Ideally I don't want to change the SystemVM image from
>> what
>> is build by tools/appliance/build.sh.
>>
>>
> The SystemVM image and the agent is tightly coupled with CloudStack, you
> may have to change things in the build script (if you intend to
> add/remove/modify packages, files and contents).
>
>  How was this testing done in the past?
>>
>
> In the past, I would create a systemvm template, have CloudStack
> management to use it to boot up SSVMs, VRs etc. and ssh into them from
> their respective hosts on their link local IP. Then, I would change the
> internal state of the VM and check with management server to test things
> and see if it would fix the state itself, execute platform apis etc.
>
> There is/was no automation framework to do the testing so it was mostly
> manually. Any work in this regard would be great.
>
> Regards.
>
>
>> Thanks,
>>
>> Karl
>>
>>  Find out more about ShapeBlue and our range of CloudStack related
> services
>
> IaaS Cloud Design & Build<http://shapeblue.com/
> iaas-cloud-design-and-build//>
> CSForge – rapid IaaS deployment framework<http://shapeblue.com/csforge/>
> CloudStack Consulting<http://shapeblue.com/cloudstack-consultancy/>
> CloudStack Infrastructure Support<http://shapeblue.com/
> cloudstack-infrastructure-support/>
> CloudStack Bootcamp Training Courses<http://shapeblue.com/
> cloudstack-training/>
>
> This email and any attachments to it may be confidential and are intended
> solely for the use of the individual to whom it is addressed. Any views or
> opinions expressed are solely those of the author and do not necessarily
> represent those of Shape Blue Ltd or related companies. If you are not the
> intended recipient of this email, you must neither take any action based
> upon its contents, nor copy or show it to anyone. Please contact the sender
> if you believe you have received this email in error. Shape Blue Ltd is a
> company incorporated in England & Wales. ShapeBlue Services India LLP is a
> company incorporated in India and is operated under license from Shape Blue
> Ltd. Shape Blue Brasil Consultoria Ltda is a company incorporated in Brasil
> and is operated under license from Shape Blue Ltd. ShapeBlue is a
> registered trademark.
>
>

Re: Testing a Cloudstack Virtual Router (SystemVM).

[Karl Harris]

Sorry for the duplicate questions!

Most were answered in you previous response!

Thanks Rohit!

On Tuesday, July 8, 2014, Karl Harris  wrote:

> How is the unit testing accomplished for changes to the
> configuration/startup scripts? I can obviously run the scripts in a
> different Debian build!
> Im trying to build something that can be tested easily without many
> changes to the baseline System VM image.
>
> The current System VM build runs under vbox freestanding but has no net
> work unless parameter are passed to it via Grub/proc/cmdline which is used
> by cloud-early-config.sh to set up the network.
>
> How was the unit testing done in the past?
>
> Or was iit ntegration testing only?
>
>
> On Tuesday, July 8, 2014, Rohit Yadav  > wrote:
>
>> Hi Karl,
>>
>> Karl Harris wrote:
>>
>>> What is the current framework used to test a Cloudstack Virtual Router
>>> (SystemVM) in isolation aka without Management Server if any?
>>>
>>
>> AFAIK we don't have any such testing/automation framework within Apache
>> CloudStack.
>>
>>  I'd like to call a SystemVM script with a set of configuration parameters
>>> (changes for VPCVrr, etc.) and observe the changes to the virtual routers
>>> configuration.
>>>
>>> Since I will eventually need the ethernet connections to be added and
>>> deleted I would like to aviod using ethernet to make the connection to
>>> the
>>> SystemVM image. Ideally I don't want to change the SystemVM image from
>>> what
>>> is build by tools/appliance/build.sh.
>>>
>>>
>> The SystemVM image and the agent is tightly coupled with CloudStack, you
>> may have to change things in the build script (if you intend to
>> add/remove/modify packages, files and contents).
>>
>>  How was this testing done in the past?
>>>
>>
>> In the past, I would create a systemvm template, have CloudStack
>> management to use it to boot up SSVMs, VRs etc. and ssh into them from
>> their respective hosts on their link local IP. Then, I would change the
>> internal state of the VM and check with management server to test things
>> and see if it would fix the state itself, execute platform apis etc.
>>
>> There is/was no automation framework to do the testing so it was mostly
>> manually. Any work in this regard would be great.
>>
>> Regards.
>>
>>
>>> Thanks,
>>>
>>> Karl
>>>
>>>  Find out more about ShapeBlue and our range of CloudStack related
>> services
>>
>> IaaS Cloud Design & Build<http://shapeblue.com/
>> iaas-cloud-design-and-build//>
>> CSForge – rapid IaaS deployment framework<http://shapeblue.com/csforge/>
>> CloudStack Consulting<http://shapeblue.com/cloudstack-consultancy/>
>> CloudStack Infrastructure Support<http://shapeblue.com/
>> cloudstack-infrastructure-support/>
>> CloudStack Bootcamp Training Courses<http://shapeblue.com/
>> cloudstack-training/>
>>
>> This email and any attachments to it may be confidential and are intended
>> solely for the use of the individual to whom it is addressed. Any views or
>> opinions expressed are solely those of the author and do not necessarily
>> represent those of Shape Blue Ltd or related companies. If you are not the
>> intended recipient of this email, you must neither take any action based
>> upon its contents, nor copy or show it to anyone. Please contact the sender
>> if you believe you have received this email in error. Shape Blue Ltd is a
>> company incorporated in England & Wales. ShapeBlue Services India LLP is a
>> company incorporated in India and is operated under license from Shape Blue
>> Ltd. Shape Blue Brasil Consultoria Ltda is a company incorporated in Brasil
>> and is operated under license from Shape Blue Ltd. ShapeBlue is a
>> registered trademark.
>>
>>

Re: Testing a Cloudstack Virtual Router (SystemVM).

[Karl Harris]

On Tue, Jul 8, 2014 at 5:04 AM, Rohit Yadav 
wrote:

> Hi Karl,
>
>
> Karl Harris wrote:
>
>> What is the current framework used to test a Cloudstack Virtual Router
>> (SystemVM) in isolation aka without Management Server if any?
>>
>
> AFAIK we don't have any such testing/automation framework within Apache
> CloudStack.
>
>
>  I'd like to call a SystemVM script with a set of configuration parameters
>> (changes for VPCVrr, etc.) and observe the changes to the virtual routers
>> configuration.
>>
>> Since I will eventually need the ethernet connections to be added and
>> deleted I would like to aviod using ethernet to make the connection to the
>> SystemVM image. Ideally I don't want to change the SystemVM image from
>> what
>> is build by tools/appliance/build.sh.
>>
>>
> The SystemVM image and the agent is tightly coupled with CloudStack, you
> may have to change things in the build script (if you intend to
> add/remove/modify packages, files and contents).
>
>
>  How was this testing done in the past?
>>
>
> In the past, I would create a systemvm template, have CloudStack
> management to use it to boot up SSVMs, VRs etc. and ssh into them from
> their respective hosts on their link local IP. Then, I would change the
> internal state of the VM and check with management server to test things
> and see if it would fix the state itself, execute platform apis etc.
>
> There is/was no automation framework to do the testing so it was mostly
> manually. Any work in this regard would be great.
>
> Since cloud-early-config.sh is "hypervisor aware", at least for those that
do not populate /proc/cmdline directly,  did you test each hypervisor
manually?

Regards.
>
>
>> Thanks,
>>
>> Karl
>>
>>  Find out more about ShapeBlue and our range of CloudStack related
> services
>
> IaaS Cloud Design & Build<http://shapeblue.com/
> iaas-cloud-design-and-build//>
> CSForge – rapid IaaS deployment framework<http://shapeblue.com/csforge/>
> CloudStack Consulting<http://shapeblue.com/cloudstack-consultancy/>
> CloudStack Infrastructure Support<http://shapeblue.com/
> cloudstack-infrastructure-support/>
> CloudStack Bootcamp Training Courses<http://shapeblue.com/
> cloudstack-training/>
>
> This email and any attachments to it may be confidential and are intended
> solely for the use of the individual to whom it is addressed. Any views or
> opinions expressed are solely those of the author and do not necessarily
> represent those of Shape Blue Ltd or related companies. If you are not the
> intended recipient of this email, you must neither take any action based
> upon its contents, nor copy or show it to anyone. Please contact the sender
> if you believe you have received this email in error. Shape Blue Ltd is a
> company incorporated in England & Wales. ShapeBlue Services India LLP is a
> company incorporated in India and is operated under license from Shape Blue
> Ltd. Shape Blue Brasil Consultoria Ltda is a company incorporated in Brasil
> and is operated under license from Shape Blue Ltd. ShapeBlue is a
> registered trademark.
>
>

Re: [MERGE] virtual network appliance manager refactorring

[Karl Harris]

Daan,

Is it safe to assume that the most of the refactoring work mentioned
(pushed) in your email is outlined in CLOUDSTACK-7143?

Karl


On Fri, Oct 3, 2014 at 7:22 AM, Daan Hoogland 
wrote:

> H,
>
> I just pushed a huge branch with work that my colleagues did [1]. It is
> prerequisite to adding redundancy to vpc routers. please take it into
> account when doing anything with virtual router functionality as it
> addresses a lot of the way we work with configuring those. Merging will
> have to wait of course but for any related work I'd advice to use it as
> starting point to be joined in the merge later on.
>
> ​It will be followed first by refactorings in the virtual routing resource
> ​and the actual on board router scripts and next by the code to add
> redundancy to the vpc version of the router.
>
> ​thanks,​
>
> ​[1] https://github.com/apache/cloudstack/tree/vpc-refactor​
>
> --
> Daan
>



-- 
Karl O. Harris
Cloud Software Engineer
Sungard Availability Services
Office: 215-446-1772
Cell: 215-264-1855
karl.har...@sungardas.com

Re: [MERGE] virtual network appliance manager refactorring

[Karl Harris]

Here is a update of the work in support of  Cloudstack-764:

The overall idea of this effort is to implement VPC Virtual Redundant
Routing  and automate the unit
tests for system virtual machine for virtual routers both redundant and
non-redundant, for Cloudstack-764.

Current work areas.

Modify system vm bash scripts to implement VPC Virtual redundant routing in
a similar
fashion to existing virtual redundant routing. Basically implementing the
ability for VRR to handle
VPC's dynamic network topology as mention in the Java Refactoring from SP.

Refactored the VeeWee virtual machine build scripts to use Packer. Packer
is used because of its ability
to build a system virtual machine raw file without unsupported "c"
utilities and its additional builders
to generate images for all virtual environments as required.

Initial test framework uses VirtualBox/Vagrant as test harness with the
addition of test scripts for unit testing.
The output of the Packer build in a Vagrant Box is also used for debugging
script changes outside
of unit test framework.

Use the output of the Packer builders as part of an automated system
virtual machine "build/ testing chain"  in support of additional
script changes for virtual routers and/or other Cloudstack system virtual
machine functions.



Karl


On Tue, Oct 7, 2014 at 11:45 AM, Wilder Rodrigues <
wrodrig...@schubergphilis.com> wrote:

> Thanks, Daan! :)
>
> More info here:
>
> Just a quick update on the status of the VPC RVR refactor, which is the
> part 1 of the whole VPC RVR implementation. I have added some documentation
> to the Apache Wiki page. You can find it on the URL below:
>
>
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Refactor+for+Redundant+Virtual+Router+Implementation
>
> Thanks for the diagrams, Antonio!
>
> I will update it later with some few notes that we are working on.
>
> Cheers,
> Wilder
>
> Sent from my iPhone
>
> On 03 Oct 2014, at 19:36, "Daan Hoogland"  daan.hoogl...@gmail.com>> wrote:
>
> yes, and it is good to stress that once again!
>
> On Fri, Oct 3, 2014 at 6:00 PM, David Nalley  da...@gnsa.us>> wrote:
>
> As noted in your PR, please don't merge this immediately into master.
> We're in feature freeze, and master is currently 4.5
>
> Thanks,
>
> --David
>
> On Fri, Oct 3, 2014 at 7:22 AM, Daan Hoogland  >
> wrote:
> H,
>
> I just pushed a huge branch with work that my colleagues did [1]. It is
> prerequisite to adding redundancy to vpc routers. please take it into
> account when doing anything with virtual router functionality as it
> addresses a lot of the way we work with configuring those. Merging will
> have to wait of course but for any related work I'd advice to use it as
> starting point to be joined in the merge later on.
>
> It will be followed first by refactorings in the virtual routing resource
> and the actual on board router scripts and next by the code to add
> redundancy to the vpc version of the router.
>
> thanks,
>
> [1] https://github.com/apache/cloudstack/tree/vpc-refactor
>
> --
> Daan
>
>
>
>
> --
> Daan
>



-- 
Karl O. Harris
Cloud Software Engineer
Sungard Availability Services
Office: 215-446-1772
Cell: 215-264-1855
karl.har...@sungardas.com

Re: [MERGE] virtual network appliance manager refactorring

[Karl Harris]

I have posted a reference pull request
<https://github.com/apache/cloudstack/pull/33> with the current work in
progress using packer to build system virtual machines as well as
generating vagrant boxes for testing. As mentioned in the pull request
comment :This is "a work in progress" and posted for review and comment.

Karl


On Thu, Oct 9, 2014 at 1:51 PM, Karl Harris 
wrote:

>
>
> Here is a update of the work in support of  Cloudstack-764:
>
> The overall idea of this effort is to implement VPC Virtual Redundant
> Routing  and automate the unit
> tests for system virtual machine for virtual routers both redundant and
> non-redundant, for Cloudstack-764.
>
> Current work areas.
>
> Modify system vm bash scripts to implement VPC Virtual redundant routing
> in a similar
> fashion to existing virtual redundant routing. Basically implementing the
> ability for VRR to handle
> VPC's dynamic network topology as mention in the Java Refactoring from SP.
>
> Refactored the VeeWee virtual machine build scripts to use Packer. Packer
> is used because of its ability
> to build a system virtual machine raw file without unsupported "c"
> utilities and its additional builders
> to generate images for all virtual environments as required.
>
> Initial test framework uses VirtualBox/Vagrant as test harness with the
> addition of test scripts for unit testing.
> The output of the Packer build in a Vagrant Box is also used for debugging
> script changes outside
> of unit test framework.
>
> Use the output of the Packer builders as part of an automated system
> virtual machine "build/ testing chain"  in support of additional
> script changes for virtual routers and/or other Cloudstack system virtual
> machine functions.
>
>
>
> Karl
>
>
> On Tue, Oct 7, 2014 at 11:45 AM, Wilder Rodrigues <
> wrodrig...@schubergphilis.com> wrote:
>
>> Thanks, Daan! :)
>>
>> More info here:
>>
>> Just a quick update on the status of the VPC RVR refactor, which is the
>> part 1 of the whole VPC RVR implementation. I have added some documentation
>> to the Apache Wiki page. You can find it on the URL below:
>>
>>
>> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Refactor+for+Redundant+Virtual+Router+Implementation
>>
>> Thanks for the diagrams, Antonio!
>>
>> I will update it later with some few notes that we are working on.
>>
>> Cheers,
>> Wilder
>>
>> Sent from my iPhone
>>
>> On 03 Oct 2014, at 19:36, "Daan Hoogland" > <mailto:daan.hoogl...@gmail.com>> wrote:
>>
>> yes, and it is good to stress that once again!
>>
>> On Fri, Oct 3, 2014 at 6:00 PM, David Nalley > da...@gnsa.us>> wrote:
>>
>> As noted in your PR, please don't merge this immediately into master.
>> We're in feature freeze, and master is currently 4.5
>>
>> Thanks,
>>
>> --David
>>
>> On Fri, Oct 3, 2014 at 7:22 AM, Daan Hoogland > <mailto:daan.hoogl...@gmail.com>>
>> wrote:
>> H,
>>
>> I just pushed a huge branch with work that my colleagues did [1]. It is
>> prerequisite to adding redundancy to vpc routers. please take it into
>> account when doing anything with virtual router functionality as it
>> addresses a lot of the way we work with configuring those. Merging will
>> have to wait of course but for any related work I'd advice to use it as
>> starting point to be joined in the merge later on.
>>
>> It will be followed first by refactorings in the virtual routing resource
>> and the actual on board router scripts and next by the code to add
>> redundancy to the vpc version of the router.
>>
>> thanks,
>>
>> [1] https://github.com/apache/cloudstack/tree/vpc-refactor
>>
>> --
>> Daan
>>
>>
>>
>>
>> --
>> Daan
>>
>
>
>
> --
> Karl O. Harris
> Cloud Software Engineer
> Sungard Availability Services
> Office: 215-446-1772
> Cell: 215-264-1855
> karl.har...@sungardas.com
>



-- 
Karl O. Harris
Cloud Software Engineer
Sungard Availability Services
Office: 215-446-1772
Cell: 215-264-1855
karl.har...@sungardas.com

Re: [GitHub] cloudstack pull request: Feature cenik123 vpcvrr 1.1.1

[Karl Harris]

On Tue, Dec 2, 2014 at 3:50 AM, lsimons  wrote:

> Github user lsimons commented on the pull request:
>
> https://github.com/apache/cloudstack/pull/33#issuecomment-65199170
>
> Hey folks,
>
> Karl thanks for contributing. Looks like quite a bit of work!
>
> Rohit thanks for CC-ing me in :)
>
> It's a bit hard to read the pull request right now and provide review
> comments:
> * Github says there's nearly 7000 changed files so at a guess
> something went wrong there? I had a look, and it looks like
> KarlHarrisSungardAS/cloudstack is quite a ways behind master, which may
> explain that...? It's probably a good idea to make a copy of the feature
> branch, rebase it against current master, squash some of the commits
> together, and then re-send the pull request. Or, start another branch, and
> cherry-pick over just the changes that _should_ be in the change set.
> * git hasn't picked up on the relation between veewee and packer, it's
> probably good idea to give it some more hints. For example it would be good
> to see
>
> https://github.com/KarlHarrisSungardAS/cloudstack/commit/892b11ec0230ce87d14370fd1055ac223096cc77#diff-67bdab8b08f1e110ceabe1a23c3d4011R1
> compared to the veewee equivalent.
> * there's a lot of 'shuffling' and/or adding comments intermixed with
> functional changes. For example
> https://github.com/KarlHarrisSungardAS/cloudstack/commit/7f55a1ef032c29cb955e02c90da43c91739108d7#diff-95748c84d8b6be2da502091e69b748d9L30
> you might think the 'set -x' is getting removed here, but it just moved
> down a bit amidst a few new comments.
> * there's a lot of commits that are seemingly unrelated to the actual
> change (probably cherry-picked from master onto the feature branch?), those
> will need to be filtered out I think.
> * there's a lot of 'archive' commits which have unfinished
> 'checkpoint' code. I imagine all that work gets finished 'later on' (like
> renaming _gitignore to .gitignore is one that I tracked) but it's not so
> easy to see. It'd be great if those things could be squashed together.
>
> I will issue a revised pull request shortlyThanks for the input and
suggestions.

As far as content goes...
>
> 1) Like sebastien says, veewee is in maintenance mode and moving to
> packer (replacing veewee) is definitely a good idea. This looks like a
> straightforward port, which if it works ok seems like the way to go. We
> _should_ make sure to do it in a way that's somewhat compatible with the
> jenkins.buildacloud.org setup. I don't think we could sustain maintenance
> of both packer and veewee builds for long, it'll be a pain to keep changes
> in sync. I'd want to drop veewee use completely.
>
My intent with moving to Packer was to make/continue the systemvm builds
compatible with jenkins. This is part of building a self supporting unit
test framework using Packer/Vagrant. See below.

>
> 2) Testing the systemvm using vagrant is also obviously a good idea
> (we're doing much the same, over at
> https://github.com/schubergphilis/cloudstack/tree/feature/systemvm-persistent-config/tools/vagrant/systemvm
> see
> https://github.com/schubergphilis/cloudstack/commits/feature/systemvm-test
> for an abandoned branch having just test-related commits), though I don't
> understand why we'd need to use vagrant templates? The .box file that we
> get out of the veewee-based systemvm build imports (
> https://github.com/apache/cloudstack/blob/master/tools/appliance/build.sh#L466)
> just fine...
>
> Yes, the use of vagrant templates is a bit redundant given the self
patching nature of the systemvms. I will look at the references above as
our work progresses.


> 3) For the stuff that seems to be planned _beyond_ these changes, it
> might be a good idea to pop by on the development mailing list and discuss
> plans. A few people at Schuberg Philis (my employer, where there's a few
> people working on cloudstack) have been working on redundancy for the
> virtual router for a few months now. We've found that making it work also
> involves a lot of changes outside of the systemvm, too, i.e. changing the
> orchestration logic in the java code to match changed behavior of the vpc
> router (see
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Refactor+for+Redundant+Virtual+Router+Implementation
> /



> https://www.slideshare.net/LeoSimons1/toolkit-posterccceu14-v2 ).
> @spark404 please do have a look at Karl's approach :)
>
 After looking a how Cloudstack implements both public and VPC routers; I
have chosen to concentrate on the systemvm and what is required to create a
VPC redundant router with the minimum changes to the interface between the
system virtual machine (scripts) and the Cloudstack management server. The
idea is to add the ability for the existing VPC routers to route
dynamically configured network topologies (tiers) by using the existing
 Create, Read, Update and Delete (CRUD) network scripts. The goal is to
only add a boolean

Re: Redundant VPC routers

[Karl Harris]

Daan,

Good to hear from you! Hope all is well.

Yes, we should talk, but I'm afraid my schedule is such that I cannot put a
meeting on the calendar until the new year.

We have looked at the Java refactoring work. I seems most of that work was
a true refactoring in that it didn't change the interface used to
manipulate the systemvm's.

We could not find any posted changes to the systemvm's, unless we are
looking in the wrong place. ;-)

Because of the SP Java refactoring effort we have been concentrating on
changing the systemvm and building a system vm unit testing framework using
packer/virtualbox/vagrant and making changes to the scripts inside the
systemvm's without touching any of the Java code.

I would like to take a look at the changes to the systemvm, if any that
have been made by SP for the release (candidate?) you've referenced in your
email.

Regards,

Karl


On Fri, Dec 12, 2014 at 4:39 AM, Daan Hoogland 
wrote:
>
> H Karl, Did you have a look at the work going on @ Schuberg Philis
> yet? It seems to me there is double work going on that is not
> compatible to one another. our work is now at the branch
> feature/systemvm-persistent-config-3 ('-3' because of the painful
> rebase work we are having to do)
>
> As things are going now we are going to have conflicts in our work on
> merging! Maybe we should have a call about this someday soon.
>
> regards,
> --
> Daan
>

Working on CloudStack Jira-764:nTier Apps 2.0 : Redundant Virtual Router for VPC email 1 of 2

[Karl Harris]

I started posting my initial comments in JIRA and was advised
dev@cloudstack.apache.org is the place to post/ask/communicate.

Here is a set of threads which, from this time on, will be continued on
this mailing list:

>From JIRA:

Karl 
Harris<https://issues.apache.org/jira/secure/ViewProfile.jspa?name=karl.harris>
added
a comment - 31/Dec/13 15:47 - edited

My colleagues and I have been tasked by our company, Sungard, to implement
and test the functionality of this JIRA.

We have done some preliminary work and I will outline what we've found and
several questions we have.

We will certainly have more questions/comments, but this is a good start.

Please comment, correct or add to the statements and questions below:

We have referenced:

   1.
   
http://blogs.clogeny.com/understanding-the-redundant-virtual-router-in-citrix-cloudplatform
   2. Cloudstack function spec for RvR
   
https://cwiki.apache.org/confluence/display/CLOUDSTACK/Reundant+Virtual+Router+Functional+Spec
   .
   3. Cloudstack function spec for new VPC features
   
https://cwiki.apache.org/confluence/display/CLOUDSTACK/nTier+Apps+2.0+Functional+Spec
   .
   4. Implemented code for RvR in VirtualNetworkApplianceManagerImpl, as
   well as redundant_router directory of systemvm and in cloud-early-setup.

What we know:

   1. Redundant Virtual Routers (RvR's) are used in CloudStack public
   clouds per item 4 above.
   2. The public RvRs are provisioned with the templates contained in
   redundant_router directory of systemvm.
   3. Keepalived and Conntrackd do most of the "heavy lifting" monitoring
   and transitioning the current RvR's in public clouds.
   4. Keepalived and Contrackd are setup with templates by systemvm.
   5. The setup_router script calls the setup_redundant_router to provision
   a redundant router pair for a vm.
   6. We will need to confirm each router of a redundant pair is
   provisioned under a separate Hypervisor to allow for no single point of
   failure.

Questions:

   1. Are there any other references which might be helpful?
   2. It seems the VirtualNetworkApplianceManagerImpl and associated
   classes should be useable for vpcRvR's are there any gotcha's we should
   know about when using this class hierarchy ?
   3. Are there any other single points of failure other than the unique
   Hypervisor mentioned above?
   4. Can setting up a redundant router pair for a vpc be done by simply
   adding a call to setup_redundant_router script in the setup_vpcrouter
   routine for each vpcRouter marked as redundant?

<https://issues.apache.org/jira/browse/CLOUDSTACK-764#>
<https://issues.apache.org/jira/browse/CLOUDSTACK-764?focusedCommentId=13861692&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13861692>
Karl 
Harris<https://issues.apache.org/jira/secure/ViewProfile.jspa?name=karl.harris>
added
a comment - 03/Jan/14 17:29

Another question:

After re-reading:
http://cloudstack.apache.org/docs/en-US/Apache_CloudStack/4.2.0/html/Admin_Guide/about-zones.html
I have a question about the VPC redundant routers.

Should the Vpc RvR's take into account Zones with respect to not allowing a
redundant router pair to be in the same zone?

The description:
A zone typically corresponds to a single datacenter, although it is
permissible to have multiple zones in a datacenter. The benefit of
organizing infrastructure into zones is to provide physical isolation and
redundancy. For example, each zone can have its own power supply and
network uplink, and the zones can be widely separated geographically
(though this is not required).

seems to suggest router pairs should be in different zones.

Comments?
<https://issues.apache.org/jira/browse/CLOUDSTACK-764#>
<https://issues.apache.org/jira/browse/CLOUDSTACK-764?focusedCommentId=13862885&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13862885>
Daan Hoogland<https://issues.apache.org/jira/secure/ViewProfile.jspa?name=dahn>
added
a comment - 06/Jan/14 09:56

The zone is one way of separating the instances of a rvr. Could in some
use-cases a different cluster/pod/host be enough, maybe?
<https://issues.apache.org/jira/browse/CLOUDSTACK-764#>
<https://issues.apache.org/jira/browse/CLOUDSTACK-764?focusedCommentId=13862893&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13862893>
Daan Hoogland<https://issues.apache.org/jira/secure/ViewProfile.jspa?name=dahn>
added
a comment - 06/Jan/14 10:04

Making sure that a redundant pair is at two different locations could be
done by giving it two system offerings. Not sure if this goes against the
present paradigm (for rvr or offerings)
<https://issues.apache.org/jira/browse/CLOUDSTACK-764#>
<https://issues.apache.org/jira/browse/CLOUDSTACK-764?focusedCommentId=13862897&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpan

Working on CloudStack Jira-764:nTier Apps 2.0 : Redundant Virtual Router for VPC email 2 of 2

[Karl Harris]

-- Forwarded message --
From: Daan Hoogland 
Date: Wed, Jan 15, 2014 at 2:51 PM
Subject: Re: rvr4vpc
To: Karl Harris 
Cc: Christopher Litsinger 


H Karl,

Thanks for sharing. I didn't want to initiate this but I encourage you
to share this on the dev list (not in jira) as things are only
considered 'discussed' if they passed by there.

You speak of '1 Get configuration data on Source Nat Router', I don't
understand why you call the router by this designation. 'Source Nat'
is only one of it's many possible functions.

Apart from the design principles I shared with you I have so far only
a technical implementation detail so far. That is to reserve the
(eth2) interface for the private gateway on the vpc (r)vr. This way
the inteface to configure are somewhat predictable.

As for the design principle to have a statefull router (reboot proof)
the idea is to implement a configuration file that will be uploaded to
the router after which a self-config command is send that will
implement the details of configuring the interfaces, haproxy and
keepalived and maybe more. I think your current assessment of the
working of the RVRs is accurate but it will not be workable for an
implementation for vpc's as they have an unpreditable number of
interfaces.

to bad you can't make it next thursday,
Daan Hoogland


On Wed, Jan 15, 2014 at 3:25 PM, Karl Harris 
wrote:
> Daan,
>
> Sorry for the delayed response but as Christopher mentioned to you in his
> email I am getting my head around the CloudStack software.
> Since I am new to CloudStack but "old" to enterprise level JAVA the task
is
> large but not impossible. I have no experience with running CloudStack but
> considerable experience designing and maintaining large JAVA applications.
>
> I've created what I believe is a very high level abstract of how the
current
> guest VRR's are created for guest networks with the intent of making this
> abstract
> more detailed.
>
> 1 Get configuration data on Source Nat Router  selected as a redundant
> router
>1.1 Public and Guest network identified.
> 2 Both routers are provisioned
>2.1 Software  trys different, regions(?),zones,pods,clusters,hosts in
> that order as the location of the router. Log maximum “distance” apart.
> 3 Keepalived is configured
> 4 Both routers are started
> 5 Keepalived is started
>
> Obviously there is much more that is happening under each of the steps
> above. My intent is to complete this detailed "as is" listing as much as
we
> can. Then  using the "as is" description/sequence
> make a "to-be" addition for VPC's. When I get a consensus on WHAT needs to
> be implemented for the VRR in VPC  then develop HOW best to implement the
> "to-be" addition with the
> existing JAVA code as well as what additional classes need to be
> extended/implemented/created.
>
> Comments, critiques and changes to the above sequence are encouraged.
>
> I plan on posting this to the dev-list/Jira very soon.
>
> I have been using this functional spec as a guide, after discussing this
> with our Systems Engineering people this spec meets our requirements.
>
> Do you have an implementation in mind?
>
> We have an internal Cloud Meeting with conflicts with the cloudstack "day"
> next week so I will not be in attendence.
>
> Karl
>
>
>
>
>
>
>
> On Tue, Jan 14, 2014 at 4:35 PM, Daan Hoogland 
> wrote:
>>
>> Hello overthere in the states,
>>
>> Tomorow I will start some experimenting with redundant vpc routers.
>> This is to check up on any findings and requirements that you might
>> have on this. Once again I would not like to waste work on this as it
>> is really a globally usable feature that is probably universal.
>>
>> please let me know your status on this.
>>
>> If any of you are coming to the cloudstack day in London next week,
>> let's meetup next thursday.
>>
>> kind regards,
>> Daan Hoogland
>>
>
>
>
> --
> Karl O. Harris
> Cloud Software Engineer
> Sungard Availability Services
>




-- 
Karl O. Harris
Cloud Software Engineer
Sungard Availability Services

Fwd: rvr4vpc

[Karl Harris]

Daan,

A little bit of clarification.

Listed below is the paragraph I was referring in this
description<https://people.apache.org/~ke4qqq/docs2/en-US/Apache_CloudStack/4.0/html/Admin_Guide/creating-network-offerings.html>
  :


   - Redundant router capability. (v3.0.3 and greater) Available only when
   Virtual Router is selected as the Source NAT provider. Select this option
   if you want to use two virtual routers in the network for uninterrupted
   connection: one operating as the master virtual router and the other as the
   backup. The master virtual router receives requests from and sends
   responses to the user’s VM. The backup virtual router is activated only
   when the master is down. After the failover, the backup becomes the master
   virtual router. CloudStack deploys the routers on different hosts to ensure
   reliability if one host is down.



So the interpretation should be:

Source Nat needs to be enabled to allow redundant virtual router to be
active and other functions which do not conflict with the Source Nat
function may be enabled as needed.

Do I have it correct?

Karl


-- Forwarded message --
From: Daan Hoogland 
Date: Wed, Jan 15, 2014 at 4:07 PM
Subject: Re: rvr4vpc
To: Karl Harris 
Cc: Christopher Litsinger 


On Wed, Jan 15, 2014 at 9:20 PM, Karl Harris 
wrote:
> I found a reference here which seems to imply only Source Nat Routers can
be
> made redundant in
> guest networks.


I see, AFAIK you misinterpreted the text here; the option 'Source Nat'
needs to be active but i think other options may be active as well.




-- 
Karl O. Harris
Cloud Software Engineer
Sungard Availability Services