Domain management with TestShell 4.8 SP3

[Quali-Community]

General

About domains management in TestShell 4.8 SP3

 

The definition of a domain.

For many customers the term domain (regardless of TestShell) represents a silo of equipment.

For example, at a service provider: The Cisco Domain would contain all the Cisco equipment.

In some cases the silo definition doesn't work well with TestShell and may generate management overhead for the admin.

The domain in TestShell is more oriented towards the test-bed silo.
A Cisco test-bed would include Cisco equipment, Traffic equipment, L1 ports and some equipment by other vendors (if interoperability testing is conducted)

It's important to note that, in TestShell, the same equipment will and can appear in multiple domains where reserving the equipment defines and protects the user who is using the equipment at that time.

 

Introducing the project domain concept.

In TestShell 4.8 SP3 we've added the ability to define domains which enable view-only rights to users and domains which allow the users to actually reserve the equipment. These capabilities are combined with a change where the user will see all the devices from all view-only domains regardless of the domain he logs in to. As long as the domain was associated to his user group.

With these capabilities the admin has an additional allocation control layer he can use to manage the devices in TestShell.

Some examples:

• Scenario - Users can see all but work only with allocated equipment to their project
  • Admin
    • All user groups are associated to the Global Domain in view-only mode.
    • The admin creates an additional domain dedicated to the project,
      associates the domain to the specific user group,
      and sets the association so that the "view-only" is not checked
• User
  • The user can see all the equipment in the lab
  • The user should log  into the project domain and will be able to reserve equipment from that domain
  • The user can ask the admin to add more equipment to his project (since he can see the rest)
  • The user can build a topology from view-only resources and ask the admin to add the whole topology to his project domain
  • Scenario - Users can see a sub-set of the lab and only work with allocated equipment to their project
    • Admin
      • Creates a set of domains according to his own logic (vendors, geography, etc…)
      • Associates relevant domains to relevant user groups with view-only rights.
      • Creates additional project level domains (usually these are cross the original view-only domains),
        associates the domains to the user groups without the view-only selected
• User
  • The user can see equipment from the different domains his groups are associated with.
  • The user can only reserve from the specific domain he logged into and is not in view-only
  • If the user wants to work on multiple projects at the same time, open multiple TestShell clients.
  • Users should have access to everything
    • Admin
      • Associate all groups to the global domain without the view-only selected
• Users
  • Can see all and reserve all

 

When should project domains be used.

If a team is going to work on a testing cycle with a test-bed for the next 3 to 6 months, the admin should build a project domain for it.

The team can then coordinate internally and interact with their equipment via reservations.

Many ex-Gale users are used to have a reservation for the project level. This reservation was shared and they would need to coordinate manually.

The project level domain is equivalent to this project level reservation, only we provide the additional level of reservations under them.

Introducing this approach may reduce the requirement for sharing topologies, although there are additional use cases that aren't solved by the flow described.

---

 (Quali) - 05/14/2013 06:41 AM

·  2851  ·