Skip to end of metadata
Go to start of metadata
 
  • Replace the gray cursive text with the actual content.
  • Remove non-applicable sections or insert N/A.

 


High Level Functional Overview and Design Specifications

Problem Statement

Implement storage driver for ScaleIO storage array based on Southbound SDK.

Implement ScaleIODiscoveryDriver based on DliscoveryDriver API.

Implement ScaleIOStoragerDriver based on BlockStorageDriver API.

Use ScaleIO Rest API as access point to ScaleIO array.

 

 

  • Background. assumptions.

    • What is the problem, why is it important?
    • Relevant use cases (from the user perspective).

Functional Requirements

    • Specific requirements.
    • Include JIRA IDs where applicable:
JIRA ID1-Line DescriptionComments, notes, etc.
 Implement ScaleIODiscoveryDriver based on DliscoveryDriver API 

Implement discover storage system, storage pools, storage ports, storage volumes.

 
 Implement ScaleIOStoragerDriver based on BlockStorageDriver API

 Implement storage volume get/create/expand/delete/export/unexport.

Implement API for snaps, clones, mirrors.

Current Status

Previous Work

  • Review SDK
  • Review existing test cases
  • design test plan and test cases (Note: the test plan will be general, including test plans for operations that are not supported in ScaleIO) (Welcome to review (smile))
JIRA IDTaskAssign toDelivery Dates
COP-17716Test cases for Driver-Discover FunctionsVarun RajgopalDone
COP-17717Test cases for Driver-Block Volume Operations and Block snapshot OperationsTaylor CuiltyDone
COP-17718Test cases for Driver-Block Clone and Export OperationsPrathamesh PramodDone
COP-17719Test cases For Driver - Block mirror OperationsShujin WuDone

 

 

  • Implementation Design (Welcome to review (smile) )
JIRA IDTaskAssign toStatus
COP-17791Design implementation of discovery operationsVarun RajgopalDone
COP-17790Design implementation of basic volume operationsTaylor CuiltyDone
COP-17789Design implementation of block export and clone operationsPrathamesh PramodDone
COP-17787Design implementation of block snapshot operationsShujin WuDone
  • Implementation Status
JIRA IDTaskAssign toStatusApproved
     
COP-18460Implementation of DiscoveryVarun RajgopalPull Request Approved

COP-19234

Implementation of snapshot/consistency group snapshot operationsShujin Wu

Pull Request

Approved

COP-19455

Implementation of volume provisioningTaylor CuiltyPull Request Approved

COP-18943

Implementation of Clone OperationPrathamesh PatkarPull Request Approved
 Implementation of Export Operation

Shujin Wu

Taylor Cuilty

Waiting for host discovery support to continue


 
  • Integration Test 
JIRA IDTASKAssign toStatus
COP-20986Integration Test: discover/volume provisioning/snapshot/cloneShujin WuDone

 

Current Work

Export operations implementation - Block by host discovery support.

Weekly Team Plan

Tuesday:  Weekly planning meeting.

Specify and create JIRA tasks during the meeting.

If needed, review the work from the previous week.

Friday: Weekly review meeting

Review the work for the week. Since we are in a state of designing, we will review each other's design and generate doc for others to review.

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?

Mirror Operations and Export Operations are not supported in ScaleIO

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

                 Tentative Plan:                

                 10/23/2015  Finish test cases design and ready for review

                 10/30/2015  Finalize test cases design

                 11/13/2015  Finish implementation design and ready for review

                 11/20/2015  Finalize the implementation design

                 12/04/2015  Code complete

                 

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

     Development Lead:

Evgeny Roytman

     Development Team:

Shujin Wu

Prathamesh Patkar

Varun Rajgopal

Taylor Cuilty

Testing Strategy

Driver code should be unit tested method by method.

Should comply with performance requirements for storage drivers.

Documentation Strategy

We will generate the documents for test plan and implementation design.

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

 

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.
    
    
    
    





 

 

  • No labels

3 Comments

  1. Hi guys, I scanned this rather quickly. On the design side, there isn't too much detail to comment on. But that is mostly driven my the Southbound which I reviewed a while ago. Please update here as you come across issues you need to work through.

    I looked at the first two test case documents... here are my comments:

    Test Case Feedback:

    Discovery Use Case 4

    1. a.       – has reference to Pools that should be Ports

    test case 5:

    1. a.       Successfully discovery array
    2. b.      Break communication link to array. Upon rediscovery the array status should become not_ok.
    1. d.      Restore communication link
    2. e.      Upon rediscovery, the status of the array should go back to ok
    3. Verify you can do the same thing with a port, i.e. force it offline, and see the status go to not_ok after rediscovery, and then restore the port online, and verify status returns to ok.

     

    Block Volume / Snapshots Test Cases

    You already have a good mix of positive / negative test cases. Make sure you cover some operations where you have lost connectivity to the array.

    About verification with debug code “For example, in expand volume, we need to compare the capacity of the newly expanded volume to the specified capacity.” I would suggest unless the validation is really expensive, go ahead and do it all the time. Don’t assume the array code is always perfect, we see bugs there from time to time, and things like sizes not being what was expected will cause errors further along.

  2. Are we moving to this approach and removing native SIO support?

  3. Moving to unscheduled as I believe this work is at a standstill.