Open Stack

Replied in inline.

On Wed, Oct 22, 2014 at 9:33 PM, Flavio Percoco <flavio at redhat.com> wrote:
> On 10/22/2014 02:30 PM, Zhi Yan Liu wrote:
>> Greetings,
>>
>> On Wed, Oct 22, 2014 at 4:56 PM, Flavio Percoco <flavio at redhat.com> wrote:
>>> Greetings,
>>>
>>> Back in Havana a, partially-implemented[0][1], Cinder driver was merged
>>> in Glance to provide an easier and hopefully more consistent interaction
>>> between glance, cinder and nova when it comes to manage volume images
>>> and booting from volumes.
>>
>> With my idea, it not only for VM provisioning and consuming feature
>> but also for implementing a consistent and unified block storage
>> backend for image store.  For historical reasons, we have implemented
>> a lot of duplicated block storage drivers between glance and cinder,
>> IMO, cinder could regard as a full-functional block storage backend
>> from OpenStack's perspective (I mean it contains both data and control
>> plane), glance could just leverage cinder as a unified block storage
>> backend. Essentially, Glance has two kind of drivers, block storage
>> driver and object storage driver (e.g. swift and s3 driver),  from
>> above opinion, I consider to give glance a cinder driver is very
>> sensible, it could provide a unified and consistent way to access
>> different kind of block backend instead of implement duplicated
>> drivers in both projects.
>
> Let me see if I got this right. You're suggesting to have a cinder
> driver in Glance so we can basically remove the
> 'create-volume-from-image' functionality from Cinder. is this right?
>

I don't think we need to remove any feature as an existing/reasonable
use case from end user's perspective, 'create-volume-from-image' is a
useful function and need to keep as-is to me, but I consider we can do
some changes for internal implementation if we have cinder driver for
glance, e.g. for this use case, if glance store image as a volume
already then cinder can create volume effectively - to leverage such
capability from backend storage, I think this case just like ceph
current way on this situation (so a duplication example again).

>> I see some people like to see implementing similar drivers in
>> different projects again and again, but at least I think this is a
>> hurtless and beneficial feature/driver.
>
> It's not as harmless as it seems. There are many users confused as to
> what the use case of this driver is. For example, should users create
> volumes from images? or should the create images that are then stored in
> a volume? What's the difference?

I'm not sure I understood all concerns from those folks, but for your
examples, one key reason I think is that they still think it in
technical way to much. I mean create-image-from-volume and
create-volume-from-image are useful and reasonable _use case_ from end
user's perspective because volume and image are totally different
concept for end user in cloud context (at least, in OpenStack
context), the benefits/purpose of leverage cinder store/driver in
glance is not to change those concepts and existing use case for end
user/operator but to try to help us implement those feature
efficiently in glance and cinder inside, IMO, including low the
duplication as much as possible which as I mentioned before. So, in
short, I see the impact of this idea is on _implementation_ level,
instead on the exposed _use case_ level.

>
> Technically, the answer is probably none, but from a deployment and
> usability perspective, there's a huge difference that needs to be
> considered.

According to my above explanations, IMO, this driver/idea couldn't
(and shouldn't) break existing concept and use case for end
user/operator, but if I still miss something pls let me know.

zhiyan

>
> I'm not saying it's a bad idea, I'm just saying we need to get this
> story straight and probably just pick one (? /me *shrugs*)
>
>>> While I still don't fully understand the need of this driver, I think
>>> there's a bigger problem we need to solve now. We have a partially
>>> implemented driver that is almost useless and it's creating lots of
>>> confusion in users that are willing to use it but keep hitting 500
>>> errors because there's nothing they can do with it except for creating
>>> an image that points to an existing volume.
>>>
>>> I'd like us to discuss what the exact plan for this driver moving
>>> forward is, what is missing and whether it'll actually be completed
>>> during Kilo.
>>
>> I'd like to enhance cinder driver of course, but currently it blocked
>> on one thing it needs a correct people believed way [0] to access
>> volume from Glance (for both data and control plane, e.g. creating
>> image and upload bits). During H cycle I was told cinder will release
>> a separated lib soon, called Brick[0], which could be used from other
>> project to allow them access volume directly from cinder, but seems it
>> didn't ready to use still until now. But anyway, we can talk this with
>> cinder team to get Brick moving forward.
>>
>> [0] https://review.openstack.org/#/c/20593/
>> [1] https://wiki.openstack.org/wiki/CinderBrick
>>
>> I really appreciated if somebody could show me a clear plan/status on
>> CinderBrick, I still think it's a good way to go for glance cinder
>> driver.
>
> +1 Mike? John ? Any extra info here?
>
> If the brick's lib is not going to be released before k-2, I think we
> should just remove this driver until we can actually complete the work.
>
> As it is right now, it doesn't add any benefit and there's nothing this
> driver adds that cannot be done already (creating volumes from images,
> that is).
>
>>> If there's a slight chance it won't be completed in Kilo, I'd like to
>>> propose getting rid of it - with a deprecation period, I guess - and
>>> giving it another chance in the future when it can be fully implemented.
>>>
>>> [0] https://blueprints.launchpad.net/glance/+spec/glance-cinder-driver
>>> [1] https://review.openstack.org/#/c/32864/
>
> Fla
>
>
> --
> @flaper87
> Flavio Percoco
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev