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

[Karl Harris <ka...@sungardas.com>]

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 <ka...@sungard.com>wrote:

>
>
> ---------- Forwarded message ----------
> From: Daan Hoogland <da...@gmail.com>
> Date: Wed, Jan 15, 2014 at 2:51 PM
> Subject: Re: rvr4vpc
> To: Karl Harris <ka...@sungard.com>
> Cc: Christopher Litsinger <ch...@sungard.com>
>
>
> 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 <ka...@sungard.com>
> 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 <da...@gmail.com>
> > 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
>
>

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

[Daan Hoogland <da...@gmail.com>]

hey Karl,

A colleague at Schuberg Philis does tests in vbox as well so this must
be feasilble. I don't know what the initial implementers at citrix did
but it can't be to far off. As for unit tests for shell scripts look
for one of two sh-unit framework I know. And look further, there might
be more. I am all for it.

https://github.com/akesterson/shunit
or
https://code.google.com/p/shunit2/


regards

On Wed, May 28, 2014 at 5:49 PM, Karl Harris <ka...@sungardas.com> wrote:
> 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 <ka...@sungard.com>wrote:
>
>>
>>
>> ---------- Forwarded message ----------
>> From: Daan Hoogland <da...@gmail.com>
>> Date: Wed, Jan 15, 2014 at 2:51 PM
>> Subject: Re: rvr4vpc
>> To: Karl Harris <ka...@sungard.com>
>> Cc: Christopher Litsinger <ch...@sungard.com>
>>
>>
>> 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 <ka...@sungard.com>
>> 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 <da...@gmail.com>
>> > 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
>>
>>



-- 
Daan