Open Stack

On Mon, Aug 12, 2013 at 10:52 AM, Fox, Kevin M <kevin.fox at pnnl.gov> wrote:

> It may make the dependency tree a bit weird but Cinder could use Nova to
> do the actual work. Make a bare minimum image that Cinder fires up under
> Nova, attaches the volumes, and then does the partitioning/formatting. Once
> setup, the vm can be terminated. This has the benefit of reusing a lot of
> code in Cinder and Nova. It also would provide a lot of protection from
> dangerous code like formatting from being able to see disks not intended to
> be formatted. The API would live under Cinder as the Nova stuff would
> simply be an implementation detail the user need not know about.
>
> Thanks,
> Kevin
>

There have been a number of things folks have talked about implementing
"worker" instances in Cinder for.  What you're describing would be one of
them.  To be honest though I've never been crazy about the idea of
introducing a Nova dependency in Cinder like that.  Just doesn't seem to me
that in most cases the extra complexity has that great of a return but I
could be wrong.

>
>
> ________________________________________
> From: Greg Poirier [greg.poirier at opower.com]
> Sent: Monday, August 12, 2013 9:37 AM
> To: OpenStack Development Mailing List
> Subject: Re: [openstack-dev] Extension to volume creation (filesystem and
>       label)
>
> On Mon, Aug 12, 2013 at 9:18 AM, John Griffith <
> john.griffith at solidfire.com<mailto:john.griffith at solidfire.com>> wrote:
>
> On Mon, Aug 12, 2013 at 9:15 AM, Vishvananda Ishaya <vishvananda at gmail.com
> <mailto:vishvananda at gmail.com>> wrote:
> This would need to happen on the cinder side on creation. I don't think it
> is safe for nova to be modifying the contents of the volume on attach. That
> said nova does currently set the serial number on attach (for libvirt at
> least) so the volume will show up as:
>
> /dev/disk/by-id/virtio-<uuid>
>
> Although the uuid gets truncated.
>
> Vish
>
> I missed this in my first passthrough. Thanks for pointing that out.
>
> We still like the idea of creating the filesystem (to make block storage
> truly self-service for developers), but we might be able to work around
> that. It seems that my initial feeling that this would be dealt with in
> Cinder was correct, though.
>
> The virtio-<uuid> method Vish described has worked pretty well for me so
> hopefully that will work for you.  I also don't like the idea of doing a
> parition/format on attach in compute, seems like an easy path to
> inadvertently loosing your data.
>
> We could track the state of the filesystem somewhere in the Cinder model.
> Only try to initialize it once.
>
> If you still want to look at adding the partition/format functionality to
> Cinder it's an interesting idea, but to be honest I've discounted it in the
> past because it just seemed "safer" and more flexible to leave it to the
> instance rather than trying to cover all of the possible partition schemes
> and FS types etc.
>
> Oh, we don't want to get super fancy with it. We would probably only
> support one filesystem type and not partitions. E.g. You request a 120GB
> volume and you get a 120GB Ext4 FS mountable by label.
>
> It may potentially not be worth the effort, ultimately. We'll have to
> continue our discussions internally... particularly since now I know where
> a useful identifier for the volume is under the dev fs.
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130812/00fadba3/attachment.html>