Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

High Level Functional Overview and Design Specifications

Problem Statement

Background

CoprHD supports provisioning of compute resources on Vblock infrastructure.The goal of this project is to

    • simplify for users the provisioning of Vblock compute resources through CoprHD by
      • reducing the need to depend on element managers for often used operations
      • reducing the number of compute virtual pools users need to setup
    • increase the usability of catalog services by improving pre-check validations and error messages
    • improve reliability of Vblock catalog services

What is the problem, and why is it important?

    • CoprHD does not provide a mechanism to execute some often used operations on Vblock infrastructure , like ability to move certain management operations like moving a host from one compute UCS blade to another on the same UCS.
    • What is the problem, why is it important?
    • Relevant use cases (from the user perspective).
    • CoprHD does not allow using multiple service profile templates with the same compute virtual pool thus forcing user to create multiple pools.
    • Vblock support does not have sufficient validations to prevent certain misconfigurations that could lead to order failures.

Addressing the above issues would improve the usability and reliability of the product for Vblock users.


Functional Requirements

    • Specific requirements.
    • Include JIRA IDs where applicable:
JIRA ID1-Line DescriptionComments, notes, etc.
COP-27294

Release blade/activate blade service

Epic
COP-31758

Implement solution for Release blade/activate service

Story
COP-31243

Leia: vBlock Improvements and Quality Enhancements

Epic
COP-29765Ability to provision from same CVP using multiple service profile templates
COP-29757User wants boot volume datastore name to match boot volume name
COP-28947Fail host provision if ServiceProfile name in use
COP-28922Check ServiceProfileTemplate is ok for blades before provisioning
COP-28744As a storage admin, I'd like to get a better error message when the OS fails to install on a UCS blade so I can fix the issue myself rather than open a ticket.All information we have s already being displayed. So we will reject this?
COP-23466Not able to update privileges for the UCS user in ViPRShould this be changed to a bug?



...

Appropriate locking needs to be implemented so that the HostToComputeElementMatcher that runs as part of UCS, VCenter and ESX discovery does not remove the blade mapping of the host that is being provisioned.


< UI screenshot to be added>

<Flow chart to represent the workflow to be added>


Improvement 2: Ability to provision from same compute pool using multiple service profile templates

...

To maintain backward compatibility and not change anything for current users who do not need this feature, Compute Virtual Pools will continue to have an association to a maximum of one SPT per UCS. However, advanced users who have admin privileges will have the option at the time of provisioning to choose another SPT and thus over-ride the SPT selection in the virtual pool. This will allow multiple SPTs to be used with the same compute virtual pool.

<UI screenshot of CVP - template selection>

<UI screenshot of current Provisioning - CVP selection >

<UI screenshot of Proposed provisioning - CVP selection and optional SPT selection>

Improvement 3: Boot volume datastore name should match boot volume name

When a host is provisioned through Vblock catalog services, CoprHD creates a boot volume from which the host can boot. When ESX image is installed on this volume, a datastore by the name "datastore1" is created on this boot volume. The requirement is to change the default datastore name "datastore1" to the name of the boot volume.

<This can be achieved by renaming the datastore in the first boot script.>

Improvement 4: Fail host provisioning if service profile name is already in use.

When a host is provisioned through Vblock catalog service, a service profile with the same name as the host being provisioned is created on the UCS.

The current logic is such that if a service profile by the same name as the host being provisioned exists on the UCS, CoprHD appends "_1" to the name and creates the service profile.

Proposal is to change this behavior to fail provisioning if a service profile by the same name already exists on the UCS. User can either delete the existing service profile on the UCS or change the name of the host being provisioned to continue provisioning.

 

Improvement 5: Pre-check during provisioning to validate service profile template being used is okay.

Currently, CoprHD validates the service profile template selected is valid for use with the specified varrays

  1. at the time of creation of the compute virtual pool.
  2. at the time of provisioning - while selecting blades from the compute virtual pool as part of the CREATEHOST task.

    The ask is to validate the service profile template as part of provisioning pre-Check.

               Not certain yet that there is much value-add in this preCheck - the order will currently fail in the createHost task; with preCheck, it will fail before the task is initiated. Ofcourse, if the preCehck validation includes more than the validation in createHost, there will be value. Need to investigate.

Exclusions and Limitations

...

       The following are being excluded:

    • Adding or removing vlans on already provisioned hosts
    • Setting up ESX networking for hosts

Future Work and Related Projects

...

This project is neither dependent on other projects nor are other projects dependent on this.

Implementation Strategy

Implementation Timeframe

    • What are the milestones (code complete, code ready for review, code ready to commit)?
    • How much time will be needed to test this change and address all the issues after the initial commit?
    • Is this a multi-phase project?

Virtual Team

Testing Strategy

    • How are you going to ensure good quality?
    • Does this change require any specific performance and scale testing?
    • Does this change require security scans?

...

    • Is this change backward compatible? Could incompatibilities be avoided? If not, what changes will have customer and CoprHD QE apply to their automation software developed against the old APIs?

Other components and component interaction

    • If the change spans multiple components and/or changes interaction between components, can it create any new problems?
    • Does this change affect dependencies between services?
    • Does it change startup or shutdown order?
    • Does it require any new management interfaces?
    • New APIs to be developed for releaseBlade and associateBlade operations.
    • API to be modified for allowing specifying an SPT at the time of provisioning

Other components and component interaction

  • NA

Persistence model


    • Are schema changes need in dbsvc or coordinatorsvc?
    • If so, what is the upgrade procedure?Is the schema migration (conversion) going to be reliable and scalable?
    • Does this change affect disk usage?

...

    • Are there any other special considerations regarding upgrades? Think twice - this is rarely obvious (wink)

    • Will we need any new tools to debug or repair system if the upgrade code specific to this change fails?

Performance

    •  Can this change adversely affect performance? If so, how are you going to test it? Is there a way to test this early, before the entire implementation is ready?NA

Scalability and resource consumption

    • Will it scale? How long will essential operations take at the scale of O(10,000,000)? How are you going to test it?
    • Will specific performance at scale testing be required?
    • Does this change have impact on memory and CPU usage? How does memory and CPU usage scale with the number of objects?

Security

  • Are there any implications for CoprHD security?
  • Will new security scans be required?NA

Security

  • NA

Deployment and serviceability

...