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 <karl.har...@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 <karl.har...@sungard.com>wrote: > >> >> >> ---------- Forwarded message ---------- >> From: Daan Hoogland <daan.hoogl...@gmail.com> >> Date: Wed, Jan 15, 2014 at 2:51 PM >> Subject: Re: rvr4vpc >> To: Karl Harris <karl.har...@sungard.com> >> Cc: Christopher Litsinger <christopher.litsi...@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 <karl.har...@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 <daan.hoogl...@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
