Skip to content
This repository has been archived by the owner on Jul 24, 2019. It is now read-only.

Feat: bootstrap services cinder #318

Conversation

jeffaugustine
Copy link

What is the purpose of this pull request?:
Initialize Cinder with a volume type

What issue does this pull request address?:
partial fix for #201

Notes for reviewers to consider:

Specific reviewers for pull request:
@larryrensing @intlabs

@larryrensing
Copy link
Contributor

After thinking about it for a while and bouncing some ideas off others, is this something we really want for a service like cinder? With the work @wilkers-steve is doing here, this bootstrapping job would fail if LVM is enabled with ceph disabled. These bootstrapping jobs should be idempotent regardless of what configurations have been made under the hood. I think cinder is too much of a snowflake to be able to bootstrap with confidence. Thoughts @alanmeadows @intlabs @wilkers-steve @v1k0d3n ?

@intlabs
Copy link
Contributor

intlabs commented Apr 6, 2017

With this implementation, I'm inclined to agree with @larryrensing. It would, however, be possible to get the enabled backends from cinder.conf and then bootstrap the appropriate volume types from there.

@wilkers-steve
Copy link
Contributor

Thanks for working this @jeffaugustine. I agree with @larryrensing and @intlabs that we should reevaluate how we're bootstrapping volume types for cinder. One of the necessary additions for bootstrapping will require polling whether a resource has been successfully created and has a status of ready. I'd like to revisit how Cinder can handle bootstrapping in an idempotent way that will account for all enabled/desired backends instead of with a single top level enabled flag. If @alanmeadows @larryrensing and @intlabs agree, I'd like to see this handled after the move to OpenStack once we have that polling functionality figured out and have a more clear direction on multiple backends.

@v1k0d3n
Copy link
Collaborator

v1k0d3n commented Apr 6, 2017

i'm in favor of waiting until openstack @jeffaugustine. this will give you some breathing room (you don't have to feel rushed), and allow the team to really discuss it further. +1 to @wilkers-steve

@jeffaugustine
Copy link
Author

Alright. I'll close for now with intent to reintroduce once everything is moved over, using a more dynamic approach to choosing what volume type(s) is created.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants