You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In case the flocker driver supports other profiles (not only the hardcoded gold, silver and bronze),
I suggest to add a new API in the IBlockDeviceAPI that return the supported profile by the driver.
And then flockerctl could use it to present the supported profile of the driver. for example "flockerctl list-profiles"
The text was updated successfully, but these errors were encountered:
Again, here what do you think about contributing a patch to Flocker based on the work that you did? Would this be of interest? We would be happy to accept a contribution and give you and your work credit in our project.
If you are, a first step would to write up a simple proposal in another issue, this would speed up getting it into flocker for sure.
In a the current Kubernetes world, StorageClasses have to be registered by the Kubernetes administrator.
Kubernetes users can then query the Kubernetes API for the list of available StorageClasses.
It seems to me that in a production deployment, the Kubernetes / Mesos / Docker Datacentre administrator would want tight control over which storage profiles are available; and they'd probably only want to make a subset of profiles available to each category of applications / developers.
So I'm not yet convinced that this should be part of the Flocker API.
I agree with you that "Kubernetes .... administrator would want tight control over which storage profiles are available"
But the question is how the administrator knows what are the available storage profiles?
And I think that he should ask Flocker what are the available profiles that supported by the flocker driver. So now he will define the relevant profiles in the Kubernetes.
In case the flocker driver supports other profiles (not only the hardcoded gold, silver and bronze),
I suggest to add a new API in the IBlockDeviceAPI that return the supported profile by the driver.
And then flockerctl could use it to present the supported profile of the driver. for example "flockerctl list-profiles"
The text was updated successfully, but these errors were encountered: