[openstack-dev] [Openstack-operators] Volume attach mountpoints

Jacob Godin jacobgodin at gmail.com
Thu Apr 4 18:06:44 UTC 2013


Just a thought, but maybe Horizon and the nova volume-attach command should
default to 'auto'? That could potentially be less confusing for end users.


On Thu, Apr 4, 2013 at 3:01 PM, Vishvananda Ishaya <vishvananda at gmail.com>wrote:

> Yes it should, this is why the auto assign option was added in folsom:
>
> nova volume-attach test-instance <volume-uuid> auto
>
> Vish
>
> On Apr 4, 2013, at 10:38 AM, Abel Lopez <alopgeek at gmail.com> wrote:
>
> > I've been dealing with lots of confusion from users, mainly because the
> mountpoint they specify in volume-attach really has no bearing onto what
> the guest OS does with the volume.
> >
> > Here's some examples:
> > m1.tiny has no ephemeral disk, Horizon "Suggests" /dev/vdc as the
> mountpoint. The OS assigns the volume to the next available device, which
> is /dev/vdb
> >
> > a flavor with an existing (perhaps unused) ephemeral disk at /dev/vdb,
> and the user specifies /dev/vdb in volume-attach, OS will use the next
> available device, and confuse the user.
> >
> > Windows guests - have no /dev/ - volumes show up as disk1, disk2, etc.
> >
> > Having the mountpoint seems to do more to confuse the users. This is an
> option that really doesn't seem to bring anything to the table. We should
> really just leave device assignment to the guest OS, no?
> >
> > Thoughts?
> > _______________________________________________
> > OpenStack-dev mailing list
> > OpenStack-dev at lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
> _______________________________________________
> OpenStack-operators mailing list
> OpenStack-operators at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130404/bb502cd9/attachment.html>


More information about the OpenStack-dev mailing list