Re: [Kimchi-devel] [RFC] Create logical pool from existing VG

On 10/15/2015 10:30 PM, Jose Ricardo Ziviani wrote: > > > On 15-10-2015 13:12, Aline Manera wrote: >> >> >> On 15/10/2015 12:00, Jose Ricardo Ziviani wrote: >>> >>> >>> On 15-10-2015 11:56, Aline Manera wrote: >>>> >>>> >>>> On 15/10/2015 11:45, Jose Ricardo Ziviani wrote: >>>>> Hello, >>>>> >>>>> I'm about to write a new feature to Kimchi. It will allow users to >>>>> define any existing volume group as a storage pool, where guests >>>>> will >>>>> be able to create logical volumes into it. NOTE: VGs already in >>>>> use as >>>>> storage pool won't be listed. >>>>> >>>>> I read Pooja's "[RFC] Proposal to manage Physical Volumes on >>>>> Ginger", >>>>> and now I think all LVM code should be implemented in WOK so both >>>>> plugins (Kimchi/Ginger) could take advantages from that. >>>>> I believe the idea was to have "wok" as base framework without having any functionality implemented.

>>>>> API: >>>>> >>>>> Collection: /plugins/kimchi/host/vgs >>>>> Method: GET >>>>> Returns: list of vgnames: >>>>> [vgname1, vgname2] >>>>> >>>> >>>> ACK >>>> >>>>> Resource: /plugins/kimchi/host/vg/vgname >>>>> Method: GET >>>>> Returns: dict >>>>> { vgname, size, free_size, [PV partition list, like: sda4, sdb3], >>>>> [LV >>>>> name list, like: lv_root] } >>>>> >>>> >>>> ACK >>>> >>>>> Resource: /plugins/kimchi/storagepools/vgname >>>>> Method: POST >>>>> data: { vgname, storagepool_name, type=logical } >>>> >>>> I am little bit confused with this API. Usually the POST is done in a >>>> Collection so, something like: >>>> >>>> POST /plugins/kimchi/storagepools {name: pool_name, type: logical, >>>> vgname: vg_name} >>>> >>>> Is that what you are proposing? >>> >>> yes! updating: >>> >>> Collection: /plugins/kimchi/storagepools >>> Method: POST >>> data: {name: pool_name, type: logical, vgname: vg_name} >>> >>>> >>>>> >>>>> The frontend, I think we could have a table indicating all available >>>>> devices available for a logical storage pool, for example: >>>>> >>>>> >>>>> Define a New Storage Pool >>>>> 1. Storage Pool Name >>>>> +-----------------------------------------+ >>>>> | mypool | >>>>> +-----------------------------------------+ >>>>> The name used to identify the storage pools, and it should not be >>>>> empty. >>>>> >>>>> 2. Storage Pool Type >>>>> +-----------+ >>>>> | LOGICAL | >>>>> +-----------+ >>>>> >>>>> 3. Device path >>>>> +-------+-------+---------------+---------------+ >>>>> | |device | size | free size | >>>>> +-------+-------+---------------+---------------+ >>>>> | () | sdb | 50 GiB | 50 GiB | >>>>> +-------+-------+---------------+---------------+ >>>>> | () | sdc | 10 GiB | 8 GiB | >>>>> +-------+-------+---------------+---------------+ >>>>> | () | vg_a | 20 GiB | 18 GiB | >>>>> +-------+-------+---------------+---------------+ >>>>> >>>>> +--------+ >>>>> | Create | >>>>> +--------+ >>>> >>>> May user select multiple VGs to create a logical pool? Or is it >>>> restrict >>>> to one by one, one VG, one logical pool? >>>> Depending on that, we need to redesign the UI >>> >>> Nope, my initial idea is to have 1 device to 1 storage pool. That's is >>> because users can group many partitions (PVs) into one VG. >> >> So I suggest to have separated options: one to create a logical pool >> from raw disks and other one to create a logical pool from an >> existing VG. > > > I see, so we will have: > > 2. Storage Pool Type > +--------------------------+ > | (snip) > | LOGICAL | > | LOGICAL FROM EXISTING VG | > | (snip) | > +--------------------------+ > > and, suppose 'LOGICAL FROM EXISTING VG' is selected > > +-------+---------------+---------------+---------------+ > | | device | size | free size | > +-------+---------------+---------------+---------------+ > | () | vg_a | 20 GiB | 18 GiB | > | () | vg_b | 10 GiB | 5 GiB | > +-------+---------------+---------------+---------------+ > > Any other pool type will keep unchanged. > > Note: I intend to not list VGs without free space available. What do > you think? >> >>> >>>> >>>>> >>>>> _______________________________________________ >>>>> Kimchi-devel mailing list >>>>> Kimchi-devel(a)ovirt.org >>>>> http://lists.ovirt.org/mailman/listinfo/kimchi-devel >>>>> >>>> >>> >> >