[Kimchi-devel] Guest disk: Allocate storage volume when attaching disk to vm

[Aline Manera]

On 01/12/2016 01:48 PM, Socorro Stoppler wrote:
> Hi Aline,
>
> I'm currently working on this feature.  I have a question below.
>
> On 11/17/2015 05:38 AM, Aline Manera wrote:
>>
>>
>> On 16/11/2015 15:05, Samuel Henrique De Oliveira Guimaraes wrote:
>>>
>>> Hi,
>>>
>>> I’m bit confused here. This is the current workflow:
>>>
>>> ·1 – CD-ROM:
>>>
>>> ·2 – File Path
>>>
>>> ·1 – Disk:
>>>
>>> ·2 – Storage Pool (List in Select element / Combobox)
>>>
>>> ·3 – Storage Volume (List in Select element / Combobox of available 
>>> volumes)
>>>
>>> Then the new design is:
>>>
>>> ·1 – CD-ROM:
>>>
>>> ·2 – File Path
>>>
>>> ·1 – Disk:
>>>
>>> ·2 – Radio button: Create a new disk image
>>>
>>> ·2 – Radio button: Select existing disk image
>>>
>>> ·3 – Radio Button – Existing Storage Pool (List in Select element / 
>>> Combobox)
>>>
>>> 1.4 - Storage Volume (List in Select element / Combobox of available 
>>> volumes)
>>>
>>> ·3 – Radio Button – New Volume
>>>
>>> 1.4 – New Volume
>>>
>>> Is that right?
>>>
>>
>> Almost there:
>>
>> We are proposing the following:
>>
>> 3. New volume
>>     3.1 Select pool to create the new volume
>>     3.2 Specify volume capacity
>>
>> In both case, new disk or existing disk, the user must select the 
>> storage pool.
>> For a new disk, we **don't list** iSCSI and SCSI pools (as they are 
>> read-only). But from an existing disk, we can list all pools.
>
> What storage pools will we be listing when it's a new disk?  For 
> existing disk, we make the call to listStoragePools() which retrieves 
> them all.

Hi Socorro,

Please, do not list iscsi and scsi pools.
You can check the pool type to get that information. Any other pool type 
is allowed.

for pool in listStoragePools():
     if pool.type != iscsi && pool.type != scsi:
         # add to list

>>
>>> Samuel
>>>
>>> *From:*Aline Manera [mailto:alinefm at linux.vnet.ibm.com]
>>> *Sent:* segunda-feira, 16 de novembro de 2015 14:24
>>> *To:* Socorro Stoppler <socorro at linux.vnet.ibm.com>; Paulo Ricardo 
>>> Paz Vital <pvital at linux.vnet.ibm.com>; Samuel Henrique De Oliveira 
>>> Guimaraes <samuel.guimaraes at eldorado.org.br>; Andre Luiz Teodoro 
>>> <andre.teodoro at eldorado.org.br>; Kimchi Devel <kimchi-devel at ovirt.org>
>>> *Subject:* Re: Guest disk: Allocate storage volume when attaching 
>>> disk to vm
>>>
>>>
>>> Adding Samuel and Andre to this discussion and also forward to 
>>> Kimchi ML.
>>>
>>> On 16/11/2015 14:21, Aline Manera wrote:
>>>
>>>
>>>     Hi Socorro,
>>>
>>>     On 12/11/2015 21:20, Socorro Stoppler wrote:
>>>
>>>         Hi Aline,
>>>
>>>         I chatted w/Paulo about the UI portion of this.  He stated
>>>         that the user has the option to select to add a new volume
>>>         (in which the the UI must execute two requests: one to
>>>         create a volume, and other to attach the new volume to the
>>>         guest being edited).  So in this screen (I know it's the old
>>>         UI but this shows better than current new UI :)):
>>>
>>>
>>>
>>>         What do you think of 3.  being radio buttons?  -
>>>
>>>
>>>     I think 2 should be that radio buttons.
>>>
>>>     So:
>>>
>>>     1. Device type
>>>         <disk>
>>>
>>>     2. ( ) Create a new disk image
>>>
>>>         ( ) Select existing disk image
>>>
>>>     3. Storage pool
>>>         <pools>
>>>
>>>     4. Capacity or Volume (depends on selection on 2.)
>>>
>>>     Below is how virt-manage does it.
>>>
>>>
>>>
>>>
>>>             <New Volume> -
>>>                 Volume: Storage volume name of 'new_vol' --- we prob
>>>         do not need to show this in the UI, right?
>>>                 Capacity:  in bytes
>>>                 Format:  qcow2 -- is this the only option we want to
>>>         provide?
>>>                 <Create Button>
>>>
>>>             <Existing Volume> - which consists of current combobox above
>>>
>>>         Also, if user selects to do the new volume, then created it,
>>>         but decided that they didn't want to attach it, is that ok? 
>>>         Not sure of the different scenarios we have
>>>         or if I'm totally missing the intent here.
>>>
>>>         Let me know if you had envisioned something else for this UI.
>>>
>>>         Thanks
>>>         -Socorro
>>>
>>
>
> Thanks!
> -Socorro
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/kimchi-devel/attachments/20160112/c1bcc46c/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 50456 bytes
Desc: not available
URL: <http://lists.ovirt.org/pipermail/kimchi-devel/attachments/20160112/c1bcc46c/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/jpeg
Size: 15775 bytes
Desc: not available
URL: <http://lists.ovirt.org/pipermail/kimchi-devel/attachments/20160112/c1bcc46c/attachment.jpe>