CI plan for Manila glusterfs drivers - csabahenk/manila GitHub Wiki
Liberty-1
This phase is reaching it's end so here we provide a summary of how the respective goals have been met.
-
Every driver must have an associated maintainer with contact information. We will create a wiki/etherpad to collect this information.
Done.
-
Maintainers should understand the 3rd party CI requirement and have a plan for how to meet the deadlines. A plan includes how and when any needed materials will be obtained (hardware, other compute resources, accounts, firewall exceptions etc).
Hardware we'd use the OpenStack infra, similar to how GlusterFS-cinder CI does.
-
Maintainers should already be in contact with #openstack-infra and other resources to get help with how to build a CI system if help is needed.
We've figured out the steps required to build CI system with help from the GlusterFS team that setup GlusterFS-cinder CI.
Liberty-2
We are to complete / implement the following items:
common requirements
- test tempest deployment
- basic customization for devstack-plugin-glusterfs to make the deployment suitable for being used as Manila backend
- create tempest rules
glusterfs requirements
- devstack ganesha plugin
glusterfs-native requirements
- ssl specific customization for devstack-plugin-glusterfs
- tempest test cases for cert based access type
Beyond Liberty
The following items will require certain changes in the Manila tempest codebase and thus are more complex than the above items. However, it was indicated that these are not needed to be addressed within Liberty so we categorize it for now as future plan.
- scenario tests: instrumentation for cert based access type; on
guest:
- inject certificate
- install gluster client