Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Documentation: driver design #61

Open
JohnStrunk opened this issue Sep 24, 2018 · 0 comments
Open

Documentation: driver design #61

JohnStrunk opened this issue Sep 24, 2018 · 0 comments
Labels

Comments

@JohnStrunk
Copy link
Member

Describe the feature you'd like to have.
The design & modularity of the codebase should be documented.

What is the value to the end user? (why is it a priority?)
Proper documentation will permit a developer to make maximum re-use of existing code for additional driver types while also using robust, approved APIs so as to keep modularity and driver types isolated from one another.

How will we know we have a good solution? (acceptance criteria)

  • The driver-internal APIs should be fully documented (godoc)
  • There should be a single document that provides an overview of these internal interfaces and how they should be used. Providing examples of how the modularity maximizes re-use between GD2 and Heketi glusterfs drivers is highly desirable.

Additional context
This item will need to wait for refactoring for Heketi to be completed.

@JohnStrunk JohnStrunk added this to the GCS-1.0 milestone Sep 24, 2018
@JohnStrunk JohnStrunk removed this from the GCS-1.0 milestone Oct 3, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

1 participant