<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 9:15 AM, Vishvananda Ishaya <span dir="ltr"><<a href="mailto:vishvananda@gmail.com" target="_blank">vishvananda@gmail.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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>
<div><div class="h5"><br>
On Aug 10, 2013, at 10:11 PM, Greg Poirier <<a href="mailto:greg.poirier@opower.com">greg.poirier@opower.com</a>> wrote:<br>
<br>
> Since we can't guarantee that a volume, when attached, will become a specified device name, we would like to be able to create a filesystem and label it (so that we can programmatically interact with it when provisioning systems, services, etc).<br>


><br>
> What we are trying to decide is whether this should be the responsibility of Nova or Cinder. Since Cinder essentially has all of the information about the volume and is already responsible for creating the volume (against the configured backend), why not also give it the ability to mount the volume (assuming support for it on the backend exists), run mkfs.<filesystem_type>, and then use tune2fs to label the volume with (for example) the volume's UUID?<br>


><br>
> This way we can programmatically do:<br>
><br>
> mount /dev/disk/by-label/<UUID> /mnt/point<br>
><br>
> This is more or less a functional requirement for our provisioning service, and I'm wondering also:<br>
><br>
> - Is anyone else doing this already?<br>
> - Has this been considered before?<br>
><br>
> We will gladly implement this and submit a patch against Cinder or Nova. We'd just like to make sure we're heading in the right direction and making the change in the appropriate part of Openstack.<br>
><br>
> Thanks,<br>
><br>
> Greg Poirier<br>
> Opower - Systems Engineering<br>
</div></div>> _______________________________________________<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>
<br>
<br>
_______________________________________________<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>
</blockquote></div><br></div><div class="gmail_extra"><div class="gmail_default" style="font-family:'courier new',monospace">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.</div>

<div class="gmail_default" style="font-family:'courier new',monospace"><br></div><div class="gmail_default" style="font-family:'courier new',monospace">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.  </div>

<div class="gmail_default" style="font-family:'courier new',monospace"><br></div><div class="gmail_default" style="font-family:'courier new',monospace">Thanks,</div><div class="gmail_default" style="font-family:'courier new',monospace">

John</div><br></div></div>