Replied in inline. On Wed, Oct 22, 2014 at 9:33 PM, Flavio Percoco <[email protected]> wrote: > On 10/22/2014 02:30 PM, Zhi Yan Liu wrote: >> Greetings, >> >> On Wed, Oct 22, 2014 at 4:56 PM, Flavio Percoco <[email protected]> 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 > [email protected] > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev _______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
