Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
 
Tip
  • Replace the gray cursive text with the actual content.
  • Remove non-applicable sections or insert N/A.


Table of Contents

High Level Functional Overview and Design Specifications

Problem Statement

  • CoprHD has an integration with OpenStack Cinder, calling it a OpenStack southbound integration to manage all third party storage systems supported and managed by OpenStack Cinder.
  • This solution is not fully tested for various customer use cases, for e.g Add host to cluster, remove host from cluster were not real part of the test plan and were never tested.
  • VPLEX+Cinder support is introduced from Darth, however the qualification and test effort carried out was targeted to a single customer. There is a need to cover all cases and scenarios supported by VPLEX.
  • VPLEX + Cinder + RP support is claimed but the testing is not done to cover various RP configurations.
  • There are quite number of jiras which are in unresolved state, since the priority was to fix it if there exists a customer hence they had taken a backseat. 

Functional Requirements

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

Jira
showSummaryfalse
serverJIRA (coprhd.atlassian.net)
serverId3fc4ccf3-31c9-3c03-a5a5-a7af23ae9d07
keyCOP-31668

Openstack SB Quality Hardening

Jira
showSummaryfalse
serverJIRA (coprhd.atlassian.net)
serverId3fc4ccf3-31c9-3c03-a5a5-a7af23ae9d07
keyCOP-31666

Reread the code written for Cinder southbound integration

Jira
showSummaryfalse
serverJIRA (coprhd.atlassian.net)
serverId3fc4ccf3-31c9-3c03-a5a5-a7af23ae9d07
keyCOP-31669

Inject Failures/Errors in SB Cinder Integration code and validate results

Design Approach / High Level Implementation Details

    • Hash-out the design and high level implementation ideas
    • Are there any alternative design one should consider? Is this the optimal one?
    • What are the user visible changes? Will this change break user's script or automation code? Will it impact CoprHD QE automation scripts?
    • What are the changes to CoprHD components and component interaction? Are teams responsible for these other components on boards with this change?
    • What are the changes to persistent data? Will it require special consideration during upgrades?
    • Please use consistent and precise nomenclature / terminology.
    • Please include diagrams and illustrations if applicable.

Exclusions and Limitations

    • Which requirements and/or functionality are deliberately excluded from this project?

Future Work and Related Projects

    • Is this change setting ground for a future project? In other words, are there projects that depend on tis change?
    • Does this change depend on other projects? 

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

    • Who will work on this change?
    • Does the virtual team span multiple physical teams? If so, how are you going to share responsibilities and ensure consistency? 

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?

Documentation Strategy

    • What are the necessary changes to CoprHD documentation?

Impact Evaluation

Public APIs and public functionality (end-user impact)

    • 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?

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?

Upgrades

    • 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?

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?

Deployment and serviceability

    • Will any error messages associated with this feature include "friendly" names for the elements involved, rather than just opaque URIs?

Developer impact, dependencies and conditional inclusion

    • What is the impact on build time?
    • Is there any impact on integration with IDEs (Eclipse and IntelliJ)?
    • Are there any new third party dependencies? If so, please list these dependencies here:
Package NamePackage VersionLicenseURLDescription of the package and what it is used for















    • Shall this feature by included with a special build-time flag?
    • Shall this feature be enabled only under certain run-time condition?

Reviewed and Approved By

NameDateVoteComments, remarks, etc.

































  • The members of the CoprHD Technical Steering Committee (TSC) have been automatically added to your reviewer list
    • A majority of them must approve this document before the feature can be merged to a project integration branch (e.g. integration-*, release-*, master)
    • Please un-check the boxes next to their names when your document is ready for their review
  • Please refer to Design Approval Guidance for information on additional reviewers who should be added and the approval process