This repository has been archived by the owner on Jul 24, 2019. It is now read-only.
-
Notifications
You must be signed in to change notification settings - Fork 41
Add support for Cinder fake backend #270
Closed
Closed
Changes from all commits
Commits
File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -189,12 +189,18 @@ To deploy Openstack-Helm in development mode, ensure you've created a minikube-a | |
/var/lib/docker | ||
``` | ||
|
||
As a result of this guidence, we recommend creating the following for MariaDB like shown below. | ||
As a result of this guidance, we recommend creating the following for MariaDB like shown below. | ||
|
||
``` | ||
sudo mkdir -p /data/openstack-helm/mariadb | ||
``` | ||
|
||
|
||
### Change Cinder Backend | ||
|
||
Currently, Cinder uses Ceph for the RBD backend out of the box. To avoid Ceph in development mode, developers can use the Cinder 'Fake' backend by both adding the `fake` driver to the list of [enabled backends](https://github.com/att-comdev/openstack-helm/blob/master/cinder/values.yaml#L87) in Cinder's values.yaml file, and changing the `enabled` flag under `fake` to true. The Fake backend allows developers to create volumes and log events. In the future, the Fake backend will be replaced with the LVM backend in development mode to allow developers to create and attach volumes to instances. | ||
|
||
|
||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. i'd like to see a simpler one liner for development as an example (something cut and paste for developers), i.e.:
it just makes things so much easier for developers who are looking for quick cut/paste instructions. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Ok. Sounds good |
||
### Label Minikube Node | ||
|
||
Be sure to label your minikube node according to the documentation in our installation guide (this remains exactly the same). | ||
|
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
i'd like to see what @alanmeadows recommends, but i would imagine a structure that could allow for multiple backends to be enabled simultaneously would be desired, like:
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree it looks a little unwieldy in its current state here. It can support multiple backends as is, but a developer would have to add another entry under the current 'enabled:' list. Currently there's a function in Helm-toolkit that handles dissecting these lists and entering them in the service configuration files, which relies on them being scoped how they are now. I can look into handling them in the manner you suggest because I agree, it does appear more readable.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yup, ok...i get it. so a good thing to do would be to document the plans for how to use backends more generally (for anything). let me come up with a doc structure that i think would cover this well, and then we can tackle it more generally. sound good?