<div dir="ltr"><div class="gmail_default" style="font-family:courier new,monospace"><br></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Aug 12, 2013 at 10:52 AM, Fox, Kevin M <span dir="ltr"><<a href="mailto:kevin.fox@pnnl.gov" target="_blank">kevin.fox@pnnl.gov</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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.<br>
<br>
Thanks,<br>
Kevin<br></blockquote><div><br></div><div class="gmail_default" style="font-family:'courier new',monospace">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.</div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<br>
________________________________________<br>
From: Greg Poirier [<a href="mailto:greg.poirier@opower.com">greg.poirier@opower.com</a>]<br>
Sent: Monday, August 12, 2013 9:37 AM<br>
To: OpenStack Development Mailing List<br>
Subject: Re: [openstack-dev] Extension to volume creation (filesystem and label)<br>
<br>
On Mon, Aug 12, 2013 at 9:18 AM, John Griffith <<a href="mailto:john.griffith@solidfire.com">john.griffith@solidfire.com</a><mailto:<a href="mailto:john.griffith@solidfire.com">john.griffith@solidfire.com</a>>> wrote:<br>
<div class="HOEnZb"><div class="h5"><br>
On Mon, Aug 12, 2013 at 9:15 AM, Vishvananda Ishaya <<a href="mailto:vishvananda@gmail.com">vishvananda@gmail.com</a><mailto:<a href="mailto:vishvananda@gmail.com">vishvananda@gmail.com</a>>> wrote:<br>
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:<br>
<br>
/dev/disk/by-id/virtio-<uuid><br>
<br>
Although the uuid gets truncated.<br>
<br>
Vish<br>
<br>
I missed this in my first passthrough. Thanks for pointing that out.<br>
<br>
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.<br>
<br>
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.<br>
<br>
We could track the state of the filesystem somewhere in the Cinder model. Only try to initialize it once.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
</div></div><div class="HOEnZb"><div class="h5">_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br></div></div>