Feature changed by: Arthur Guo (gzhy) Feature #311063, revision 5 Title: connect the QA automation system with a cloud provider Hackweek VI: Unconfirmed Priority Requester: Important Requested by: Oliver Ries (ories23) Partner organization: openSUSE.org Description: HAMSTA is able to administer and orchestrate systems that are local to the QA lab. Some tests (e.g. load tests) require numerous additional clients that typically are being provided via VMs or physical HW on the own premises. It would be good if any system could be added as resource to HAMSTA and have tests / scripts executed on it. challenges: porting hamsta-client to different OS', parameterizing test scripts (e.g. $IP) to accommodate changing environments, multicast traffic beyond the (company) firewall / vpn Discussion: #1: Leon Wang (wonleing) (2011-01-19 07:53:41) Can I understand it as: 1. You want hamsta support CentOS/Ubuntu/Windows SUT reinstall 2. You want SUT can accept job without pre-install any hamsta client 3. You want SUT and master can be locate in different companies internet Correct me if I am wrong or miss something. + #2: Arthur Guo (gzhy) (2011-01-19 08:01:58) (reply to #1) + My understanding: 1. no Windows; 2. user install hamsta client; 3. + "different companies" is a business issue; technically an SUT outside + of our firewall, can still be contacted by hamsta master. + Correct me if I am wrong. -- openSUSE Feature: https://features.opensuse.org/311063

Feature changed by: Oliver Ries (ories23) Feature #311063, revision 8 Title: connect the QA automation system with a cloud provider Hackweek VI: Unconfirmed Priority Requester: Important Requested by: Oliver Ries (ories23) Partner organization: openSUSE.org Description: HAMSTA is able to administer and orchestrate systems that are local to the QA lab. Some tests (e.g. load tests) require numerous additional clients that typically are being provided via VMs or physical HW on the own premises. It would be good if any system could be added as resource to HAMSTA and have tests / scripts executed on it. challenges: porting hamsta-client to different OS', parameterizing test scripts (e.g. $IP) to accommodate changing environments, multicast traffic beyond the (company) firewall / vpn Discussion: #1: Leon Wang (wonleing) (2011-01-19 07:53:41) Can I understand it as: 1. You want hamsta support CentOS/Ubuntu/Windows SUT reinstall 2. You want SUT can accept job without pre-install any hamsta client 3. You want SUT and master can be locate in different companies internet Correct me if I am wrong or miss something. #2: Arthur Guo (gzhy) (2011-01-19 08:01:58) (reply to #1) My understanding: 1. no Windows; 2. user install hamsta client; 3. "different companies" is a business issue; technically an SUT outside of our firewall, can still be contacted by hamsta master. Correct me if I am wrong. #4: Oliver Ries (ories23) (2011-01-20 00:02:34) Good assessment of the weak initial request :) + #5: Oliver Ries (ories23) (2011-01-20 00:06:36) + Additionally, and IMHO most difficult, HAMSTA would leverage the + EC2/Rackspace/... API to dynamically create and start a VM out there. + This should be implemented in a layer where the specific provider API + will be implemented in specific classes. This also will have to provide + a mechanism to choose which provider (EC2/Rackspace) will be used -- openSUSE Feature: https://features.opensuse.org/311063

Feature changed by: James Tan (jatan11) Feature #311063, revision 10 Title: connect the QA automation system with a cloud provider Hackweek VI: Unconfirmed Priority Requester: Important Requested by: Oliver Ries (ories23) Partner organization: openSUSE.org Description: HAMSTA is able to administer and orchestrate systems that are local to the QA lab. Some tests (e.g. load tests) require numerous additional clients that typically are being provided via VMs or physical HW on the own premises. It would be good if any system could be added as resource to HAMSTA and have tests / scripts executed on it. challenges: porting hamsta-client to different OS', parameterizing test scripts (e.g. $IP) to accommodate changing environments, multicast traffic beyond the (company) firewall / vpn Discussion: #1: Leon Wang (wonleing) (2011-01-19 07:53:41) Can I understand it as: 1. You want hamsta support CentOS/Ubuntu/Windows SUT reinstall 2. You want SUT can accept job without pre-install any hamsta client 3. You want SUT and master can be locate in different companies internet Correct me if I am wrong or miss something. #2: Arthur Guo (gzhy) (2011-01-19 08:01:58) (reply to #1) My understanding: 1. no Windows; 2. user install hamsta client; 3. "different companies" is a business issue; technically an SUT outside of our firewall, can still be contacted by hamsta master. Correct me if I am wrong. #4: Oliver Ries (ories23) (2011-01-20 00:02:34) Good assessment of the weak initial request :) #5: Oliver Ries (ories23) (2011-01-20 00:06:36) Additionally, and IMHO most difficult, HAMSTA would leverage the EC2/Rackspace/... API to dynamically create and start a VM out there. This should be implemented in a layer where the specific provider API will be implemented in specific classes. This also will have to provide a mechanism to choose which provider (EC2/Rackspace) will be used #6: Lukas Lipavsky (llipavsky) (2011-01-20 08:10:21) (reply to #5) Wow, finally something challenging ;-) So in general, you want hamsta to: 1) control existing pool of machines - what it does already 2) access different clouds (private and external) and create/modify/delete VMs there and add control them For this, we need to (apart from the layer which woudl shield all different APIs): * somehow manage the account(credentials) for all external (paid) clouds (this is PITA) - this should have some limitations, so we will not by mistake/bug create 1000 VMs in EC2 * create image store(s) (seems impractical to me to always use reinstall in this case) - and automate it so that new images gets created automatically (or just by one click) * make a central point - currently, we have hamsta in each location, this seems to be a but impractical that each instance have access to the cloud individually, we could use some "agregator"/"master hamsta" I'm sure there will be more... Nice, I like it ;-) + #7: James Tan (jatan11) (2011-01-25 00:42:56) + We upload, create, start, and stop EC2 instances in SUSE Studio so we + can share some experiences here. The Rightscale library + (http://rightaws.rubyforge.org/) supports a number of cloud providers, + including EC2 but not Rackspace. + Rackspace is on our radar as well, so perhaps we can pool resources to + work on a shared abstraction library. -- openSUSE Feature: https://features.opensuse.org/311063