Open Stack

Horizon should IMO, I believe there is a config option to turn it on.

We left the cli option mandatory because we would have had to convert it to a --arg from a positional arg which would break existing scripts.

Vish
 
On Apr 4, 2013, at 11:06 AM, Jacob Godin <jacobgodin at gmail.com> wrote:

> 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/4c01b968/attachment.html>