Open Stack

That makes sense. I've submitted a blueprint to see if the community thinks
it's a good idea:
https://blueprints.launchpad.net/horizon/+spec/volume-attach-default-auto


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

> 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/9393c0a8/attachment.html>