Brick does not have to take over the decisions in order to be a useful repository for the code. The motivation for this work is to avoid having the dm setup code copied wholesale into cinder, where it becomes difficult to keep in sync with the code in nova.
Cinder needs a copy of this code since it is on the data path for certain operations (create from image, copy to image, backup/restore, migrate). I suggest a design where the worker code is in brick but the decisions stay in nova. This enables code sharing while not substantially altering the nova plan - it also encourages strong back-compatibility guarantees with on disk formats since the dm setup part off the code will be slightly more difficult to modify. On 20 Nov 2015 13:10, "Daniel P. Berrange" <berra...@redhat.com> wrote: > On Fri, Nov 20, 2015 at 03:22:04AM +0000, Li, Xiaoyan wrote: > > Hi all, > > > > To fix bug [1][2] in Cinder, Cinder needs to use > nova/volume/encryptors[3] > > to attach/detach encrypted volumes. > > > > To decrease the code duplication, I raised a BP[4] to move encryptors to > > os-brick[5]. > > > > Once it is done, Nova needs to update to use the common library. This > > is BP raised. [6] > > You need to proposal a more detailed spec for this, not merely a blueprint > as there are going to be significant discussion points here. > > In particular for the QEMU/KVM nova driver, this proposal is not really > moving in a direction that is aligned with our long term desire/plan for > volume encryption and/or storage management in Nova with KVM. While we > currently use dm-crypt with volumes that are backed by block devices, > this is not something we wish to use long term. Increasingly the storage > used is network based, and while we use in-kernel network clients for > iSCSI/NFS, we use an in-QEMU client for RBD/Gluster storage. QEMU also > has support for in-QEMU clients for iSCSI/NFS and it is likely we'll use > them in Nova in future too. > > Now encryption throws a (small) spanner in the works as the only way to > access encrypted data right now is via dm-crypt, which obviously doesn't > fly when there's no kernel block device to attach it to. Hence we are > working in enhancement to QEMU to let it natively handle LUKS format > volumes. At which point we'll stop using dm-crypt for for anything and > do it all in QEMU. > > Nova currently decides whether it wants to use the in-kernel network > client, or an in-QEMU network client for the various network backed > storage drivers. If os-brick takes over encryption setup with dm-crypt, > then it would potentially be taking the decision away from Nova about > whether to use in-kernel or in-QEMU clients, which is not desirable. > Nova must retain control over which configuration approach is best > for the hypervisor it is using. > > Regards, > Daniel > -- > |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ > :| > |: http://libvirt.org -o- http://virt-manager.org > :| > |: http://autobuild.org -o- http://search.cpan.org/~danberr/ > :| > |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc > :| > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
