Re: Testing tools VMs

Luis Gomez <luis.gomez@...>

Hi Carol,

That makes sense to me too, so we can have 2 interfaces per VM:

- Test traffic interface: to connect to other test VM. This is on a private subnet shared only by the VMs and does not need default gw.
- Operation interface: default interface to connect to everything else. This could be on private or public subnet and requires default gw.


-----Original Message-----
From: Carol Sanders [mailto:carol.sanders@...]
Sent: Monday, September 30, 2013 12:11 PM
To: Luis Gomez; Andrew Grimberg; integration-dev@...
Subject: RE: [integration-dev] Testing tools VMs

I agree with all items mentioned with additional consideration: I like to have a separate management interface on each VM than what I'm using for test traffic. Is it possible to have two or three interfaces per VM so that we can keep traffic separate?



-----Original Message-----
From: integration-dev-bounces@... [mailto:integration-dev-bounces@...] On Behalf Of Luis Gomez
Sent: Monday, September 30, 2013 11:39 AM
To: Andrew Grimberg; integration-dev@...
Subject: Re: [integration-dev] Testing tools VMs

Hi Andrew, I will discuss your questions more in detail with Carol but so far this is my idea for the VMs networking:

1) IP interfaces:
The VMs need 1 IP interface that can be used for both: operation of the VM and traffic to other VMs

2) Internal Access:
All VMs must see each other, i.e. be in the same subnet or at least routable among them. They also should see the other servers of ODL for integration with Jenkins, etc...

3) Access to Internet:
It would be good if all VMs have access to Internet so that we can download test packages, upgrade the ODL controller code, etc... If not you can always provision an internal repository with all that is required.

4) Access from Internet for operation (ssh):
A few people (2/3) in the integration team might need to operate the VMs. I am not sure how you do in Linux Foundation: the VMs may be directly reachable if they have public IPs, or we could use a Jump server with public IP (like we do in our Lab in Ericsson) and once we authenticate there we get access to the VMs.

5) General access from Internet, I see 2 scenarios:
- For programming the TCs: I do not see a need (at least in the beginning) because we are very few people doing this now (2/3) but maybe if there is a secure way to access the programming interface, we can open it to Internet
- For reporting: I believe some test tools may generate some web based reports that would useful to access from Internet.

Other integration members, any comments or thoughts about the test environment for ODL...


-----Original Message-----
From: integration-dev-bounces@... [mailto:integration-dev-bounces@...] On Behalf Of Andrew Grimberg
Sent: Monday, September 30, 2013 10:36 AM
To: integration-dev@...
Subject: [integration-dev] Testing tools VMs

Greetings folks,

So last week there was a request for new VMs for doing black box testing.

I understand we're talking about 5 systems. What I've seen is the

VM1: Test management tools
VM2: REST/GUI test generator
VM3: ODL controller
VM4: OF simulator
VM5: Netconf simulator

I've got a few questions about how these are suppposed to be used.

1) How are you expecting to deploy code to these systems?

2) What sort of interface to the systems is being requested?

3) How much space is expected to be needed on the systems as well as the amount of RAM?

4) What is expected to be put on each of the systems. I can sort of figure it out a little bit from the descriptions above, but having it nailed down more will help. I'm assuming I'll need java on all of them but outside of that I don't know what specifically will be needed.

5) What network ports am I going to need to open on the devices?


Andrew J Grimberg
Systems Administrator
The Linux Foundation
integration-dev mailing list

Join to automatically receive all group messages.