As a user I want to view the vNICs on my VM

flow:

1. deploy a VM
2. run "get vNICs" command on the VM
3. get as an output list of vNICs

should be possible to connect a VM to multiple VLANs and a VLAN to multiple VMs

each connection should get its own NIC on the VM

connectivity JSON schema for bulk connect/disconnect request and response:
http://qs-srv-confluence:8090/display/QP/Connectivity+Schema

scenarios to check:

1. one reservation with a VM connected to multiple VLANs (3 VLANs to start with)
2. multiple concurrent reservations, each connecting VMs to the same VLAN
3. one reservation with a VLAN connected to multiple VMs (3 VMs to start with)
4. one reservation with a VLAN connected to multiple VMs and to a physical DUT

see design here:
http://qs-srv-confluence:8090/display/QP/Standardize+Logging+in+Shells+and+Solution+Pack

The Shells team (Danny, Olga) has already written a logger that works in this format, please consult with them

As a developer I would like to use recent version of TestShell API wrapped with qualipy.

Acceptance criteria:

1. Tool that creates qualipy based on TestSehll API
2. qualipy creation runs as part of CI process in TeamCity and publishes qualipy with appropriate version

we need to normalize the access to our commands:
1.make sure everything is logged
2.make sure command will get and close the connection properly closes after the command
3.make sure no command will have to implement the retrieving of it's own parameters

Under simulator we've seen over 100 seconds.
We need to improve this number to under 10 seconds.

1. We need to refactor the method "getVCenterInventoryPathAttributeData". Its used by the "DestroyVirtualMachineCommand" class. It should return a model object instead of a dictionary.
   Note: update the unit tests in file "test_cloudshellDataRetrieverService" after the changes.
2. Add unit test to DestroyVirtualMachineCommand execute command.

Once a route is connected and a VLAN ID is selected update the route alias to show "connected, VLAN {ID}"

When disconnecting change the alias to show "disconnected, VLAN {ID}"

see the flow here:
http://qs-srv-confluence:8090/display/QP/App+Orchestration+Flow+-+vCenter+VM+deployment

need the deploy command to only create the VM on the vCenter and then the app orchestration should create the "deployed app" resource based on the results it got from the deploy (no use of the new API yet). the orchestration can be based on the temp app orchestration driver written by Meni.

As a developer I would like to be able to test the vCenterShell isolated from external dependencies, such as pyvmomi, CloudShell and vCenter.

Acceptance criteria:

1. There are a few component tests and check vCenterShell as a whole, mocking external dependencies
2. There is an article describing how it works and how to add a new test

as a user that wants to manually select a vNIC I want to get a list of vNICs to chose from

the command should be associated with the vCenter, should get as input the VM properties and as an output return a list of the vNICs name and network name if such configured on a vNIC

*TBD - don't we put it in the "VM details" of the deployed app?

As an admin I want to load all required information on the vCenter to CloudShell in order to support VM deployment and connectivity

flow:

1. create a "vCenter" resource
2. set "address", "user", "password"
3. run "discover" command
4. populates the templates list in the Template attribute on the Deployment service using (AddRestrictedValue)

ignore the below:
use existing autoload functionality, excluding:

• no sub-resource under the vCenter
• no creation of VM controller
• no update of restricted values in services
• no attributes will be populated

reference for current functionality - http://qs-srv-confluence:8090/display/QP/vCenter+Shell+3.0+-+Design

Currently the strings (attribute names, family/model names, input names etc.) are hard coded, we should use variables for that so it will be easier to change and customize the strings visible to the end user.

As a developer I would like to

1. be able to access resource's properties as class properties
2. to have a model validation to verify that the XML model fit the above class properties

Acceptance criteria:

1. Model XML is commited to github
2. Model Validator runs on every push to the repository and build fails if model does not fit classes and their properties

Add command to power on and power off a deployed app. The command should be on the vCenter and be a connected command so it will be available also on the deployed app. The command will get as an input the vCenter details and the VM UUID and should power on/off the VM. A message should be shown in the reservation output.

Power off here means - Hard Shutdown

the power on/off should update the live status on the deployed app

As a user I would like to be able to access Quali API using encrypted authentication token.

How to demo:
Turn on authentication token mode and run command on an Execution Server

As a developer I would like to be able to test the shell with full end-to-end automation including CloudShell, ES that executes command on Python shell and real vCenter.

Acceptance criteria:

1. End-To-End automation test runs as part of CI
2. There is a document on confluence describing how automation works and how to add a new test

what's available? we might want to get all the vNICs, see what they're connected to and decide accordingly.

When connecting a route to a VM need to get all the connectors currently connected to the VM and select a NIC that isn't already used.

Deploy App ended with status Failed with error: Traceback (most recent call last):
File "C:\Users\nahum-t\AppData\Local\Temp\93e0cf32-dde4-4dc1-8244-9f205a3e11ce\Deploy App.py", line 9, in
appName = resourceDetails["name"]
AttributeError: ResourceContextDetails instance has no attribute 'getitem'

Cloudshell version was latest on trunk, package was created from development branch using run_packager

Per each deployed app this entity will hold information on the VM/s that the app is hosted on. The hosted on entity will be associated with (1) a list of attributes, (2) commands (=scripts), (3) list of NICs

This entity is a new CloudShell entity that will be associated with each Lab Resource (if exists), and GetResourceDetails API command will returns the hosted-on entity's deatils.

Committing to the git project should run unit tests

I want to manage a pool of items (VLANs,etc.) and use API to get items from the pool based on defined selection policy. For now we are implementing a 'numeric' pool, but the architecture should support other types of item (i.e IPs, strings, licenses etc.)

GetItemFromPool([PoolID], [reservationId], [Selection_Criterion], [Isolation_Level])
ReleaseFromPool([PoolID], [reservationId], [Selection_Criterion])

Examples:
GetItemFromPool("Auto-Global",reservationId, Criterion.NextUnusedNumeric, IsolationLevel.Exclusive) - Unavailable to this and other reservations
GetItemFromPool("Auto-Global",reservationId, Criterion.SpecificNumeric(2999), IsolationLevel.Reservation) - Unavailable to other reservations (available to this one)
GetItemFromPool("Auto-Global",reservationId, Criterion.SpecificRanges(2999, 3500), IsolationLevel.None) - Available to everyone

We also want to add to the reservation end event the logic to remove all pool items for that reservaiton Id.

the Deploy command on the deployment service should just call a "Deploy" command on the vCenter resource which should actually create the VM in the vCenter and return the VM Data.

the "delete" command on the VM resource should also move to the vCenter and be a connected command accessible on the deployed app resource (currently use regular connected command with physical connection) *note that scripts might not support connected commands and we'll need to wrap it in a driver

Implement the connect/disconnect VLAN operations on the TBD to support VLAN (create port group, remove port group)
The input is the vnic to connect and the VM

the command should use the default vSwitch (defined on the vCenter, and the vCenter is defined in an attribute on the VM resource)

As a developer I would like a convenient way to access VM object that supports caching.

As a user I want to destroy a VM I created in CloudShell using a "delete" command on the resource that represents it

flow:

1. drag a "deploy vm" service
2. input a template (string)
3. click "deploy"
4. a resource is created with the following attributes - UUID and vCenter
5. click the "delete" command on the VM resource - the VM on the vCenter will be deleted and the resource that represents it in CloudShell will be deleted as well

note: the modeling of the resources in CloudShell is temporary

As a user I want to deploy a VM from a specific template I input and view the VM in CloudShell

flow:

1. drag a "deploy vm" service
2. input a template (string)
3. click "deploy"
4. a resource is created with the following attributes - UUID and vCenter

note: the modeling of the resources in CloudShell is temporary
the VM should be powered On once deployed

As a user I want to deploy a VM from a specific image I input and view the VM in CloudShell

admin flow:

1. create a new app
2. select "deploy from image"
3. input an image path (string). should support both local, shared and web location
4. input a vCenter name
5. save the app in a catalog

consumer flow:

1. open an active reservation
2. drag the app created by the admin
3. click "deploy"
4. a VM is created using the image configured in the app on the vCenter configured in the app
5. the app changes to the "deployed app" and has the VM ID and vCenter name in its host properties.

Test our 'get templates' method on the simulator and measure its performance with a large number of objects.
We need to get an understanding of how much this slows us down to see if its problem.
For example: Performance for 100/1000/5000 objects in the folder.

Implement the connect/disconnect VLAN operations on the TBD to support VLAN (create port group, remove port group)
The input is the vnic to connect and the VM

the command should use the default dvSwitch (defined on the vCenter, and the vCenter is defined in an attribute on the VM resource)

Here are the basic flow:
connect_vm_to_network(network_id, vm)
get_network (assume that network exists)
create_port_group
associate_vm_to_port_group

create_get_network(network_name or network_id)
return network

create_port_group(name, number_of_ports, vlan_type, dvSwitchName, vCenter)
return port_group

delete_port_group(vCenter, dvSwitchName, portGroupName)

Connnect(vlanId (220, 200-220), trunk/access, vm_resource_name)
- Port group name should be generated by
'vm_res_name Auto/Trunk VLAN Id/Range'

vCenter Resource

• Default dvSwitch Path
• Default dvSwitch Name
• Default port group path

Logical_Resource
-HostedInfo <-----> vCenter
-vCenter Name
-UUID + Path

VLAN Service
[VLAN ID]
[Trunk/Access]

The attribute of this VLAN service should be:

• Allocation Ranges (=this attribute's value will be configured by the administrator)
• VLAN ID (user input)
• Interface VLAN Mode (user input)
• Virtual Network (=this attribute will hold the selected VLAN ID / range and won't be user input)
• Isolation Level (=default for this service is Exclusive, non user input)

As a developer I would like to be able to use logging framework with logging level

Logging level should be passed via environment variable: LOGGING_LEVEL

Logging should be initialized in the Bootstrapper and passed as dependency to all the classes

I think you should use an
<addr> element here instead.

As a developer I would like to know what is the current code coverage.

Use coveralls.io service for publishing the coverage
Use the documentation provided here:
https://github.com/coagulant/coveralls-python#usage-travis-ci
Add a badge with coverage of master build to the readme page

The CLI tool should be called' ShellFoundry". For now we will implement a command called 'package' which expects the current directory to be the root directory of a shells project which we define to be structured as:
DataModel
- datamodel.xml
Resource Scripts
metadata.xml

The output should be a valid CloudShell package (zip file) which you can import into CloudShell.

As a user I would like to be able to read documentation of vCenterShell classes and methods.

Directions for investigation:
http://sphinx-doc.org/
https://github.com/integrations/gitbook

Acceptance criteria:

1. Documentation generated as part of CI and published on github
2. Generated documentation is versioned and accessible from github by version

The attribute of this VLAN service should be:

• VLAN ID (user input, mandatory)
• Interface VLAN Mode (none user input, default is Access)
• Virtual Network (=this attribute will hold the selected VLAN ID / range and won't be user input)
• Isolation Level (=default for this service is Shared, non user input, won't be changed)

flow 1 - connect

the flow for connect will be: (1) a connect command is called (2) it sends a GetItemFromPool request (3) it gets the selected VLAN ID (specific/range) as a result and put it on the "Virtual Network" attribute

if user input in "VLAN ID" is a specific number:
GetItemFromPool([PoolID=domainName], [reservationId], [Selection_Criterion=Criterion.NextUnusedNumeric(Vlan_ID)], [Isolation_Level])

if user input in "VLAN ID" is a range:
GetItemFromPool([PoolID=domainName], [reservationId], [Selection_Criterion=SpecificRanges(VLAN_ID)], [Isolation_Level])

*note: in case the "Virtual Network" attribute has a value than steps 2 and 3 in the flow above shouldn't happen

flow 2 - disconnect

the flow for disconnect will be: (1) a disconnect command is called (2) the "Virtual Network" attribute value is kept on the VLAN

note - the item isn't released from the pool in this case

flow 3 - service removal

once this service is removed from the reservation the flow will be: (1) check if there is a value in the "Virtual Network" attribute, if so (2) call ReleaseItemFromPool for the ID/range according to the value in the Virtual Network attribute and the ID of the service itself

As a user I want to deploy a VM from a specific template I input and view the VM in CloudShell

flow:

1. drag a "deploy vm" service
2. input a template (string)
3. click "deploy"
4. a resource is created with the following attributes - UUID and vCenter

note: the modeling of the resources in CloudShell is temporary
the VM should be powered On once deployed

We should save the specific vNic used for a route on the route itself as an attribute. The attribute should be hidden to the end user

The attribute on the route should be called "Target Interface", it should be a string and associated with the rule "Link Configuration".

The value of this attribute will the name of the vNIC selected for this route.

motivation: know which vNIC to disconnect

I think you should use an
<addr> element here instead.

we need to refactor BaseCommand:

1. Remove the abstract execute function, we have no use for it
2. Make sure all the shared functionality of the commands moves to it, like connecting to the VCenter.

http://team:8080/tfs/Quali-Collection/QualiSystems/_workitems/edit/128989

Create a service called "vCenter VM Template" that has a command (script) called "Deploy" which deploys a VM from a selected template. The interface of this command should be aligned with the App Orchestration flow.
Input - app deployment parameters
Output - hosted-on information to be used by the app orchestration (that builds the hotsed-on entity) - host name (=vCenter name), VM identifier (=UUID of VM), list of NICs, location (=path)

the deployment service should have the following attribute:
full path of the template (includes the name of the vCenter)

See the referenced link:
http://qs-srv-confluence:8090/pages/viewpage.action?pageId=4856595

After a VM is deployed and powered On a "Refresh IP" command can be called to get back its IP and present it to the user and the deployed app's address.

The Refresh IP command should get the VM properties as input and set the IP as the deployed app's address.

This command should be associated with the vCenter

This command should be called as part of the App Deploy, after some delay time once the VM is powered on