7:15 a.m.
Kimchi today creates network pool using macvtap. Now, we want the user
to choose if it want Linux Bridge or macvtap.
If you want to understand the pros and cons of this features, we can see
here: https://github.com/kimchi-project/kimchi/wiki/Create-guest-network
Proposal:
Add "mode" option when creating a network pool.
If macvtap is choosed, keep the actual procedure.
If bridge is choosed, create linux bridge using net commands(brctl) and
create network pool pointing to the new bridge.
Create tests for this.
--
Ramon Nunes Medeiros
Kimchi Developer
Linux Technology Center Brazil
IBM Systems & Technology Group
Phone : +55 19 2132 7878
ramonn(a)br.ibm.com
8:36 a.m.
On 10/15/2015 10:15 AM, Ramon Medeiros wrote:
Kimchi today creates network pool using macvtap. Now, we want the
user
to choose if it want Linux Bridge or macvtap.
If you want to understand the pros and cons of this features, we can
see here:
https://github.com/kimchi-project/kimchi/wiki/Create-guest-network
Proposal:
Add "mode" option when creating a network pool.
If macvtap is choosed, keep the actual procedure.
If bridge is choosed, create linux bridge using net commands(brctl)
and create network pool pointing to the new bridge.
Create tests for this.
I approve this proposal, but perhaps we can rely on Ginger to do the
linux bridge? I am worried about having both kimchi and ginger messing
with the network interfaces.
8:49 a.m.
On 15/10/2015 11:36, Daniel Henrique Barboza wrote:
On 10/15/2015 10:15 AM, Ramon Medeiros wrote:
> Kimchi today creates network pool using macvtap. Now, we want the
> user to choose if it want Linux Bridge or macvtap.
>
> If you want to understand the pros and cons of this features, we can
> see here:
> https://github.com/kimchi-project/kimchi/wiki/Create-guest-network
>
> Proposal:
>
> Add "mode" option when creating a network pool.
>
> If macvtap is choosed, keep the actual procedure.
>
> If bridge is choosed, create linux bridge using net commands(brctl)
> and create network pool pointing to the new bridge.
>
> Create tests for this.
>
I approve this proposal, but perhaps we can rely on Ginger to do the
linux bridge? I am worried about having both kimchi and ginger messing
with the network interfaces.
I understand your concern, Daniel! But (I hope) it will be the single
feature in which Kimchi needs to change the host configuration.
_______________________________________________
Kimchi-devel mailing list
Kimchi-devel(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/kimchi-devel
8:55 a.m.
On 10/15/2015 11:49 AM, Aline Manera wrote:
On 15/10/2015 11:36, Daniel Henrique Barboza wrote:
>
>
> On 10/15/2015 10:15 AM, Ramon Medeiros wrote:
>> Kimchi today creates network pool using macvtap. Now, we want the
>> user to choose if it want Linux Bridge or macvtap.
>>
>> If you want to understand the pros and cons of this features, we can
>> see here:
>> https://github.com/kimchi-project/kimchi/wiki/Create-guest-network
>>
>> Proposal:
>>
>> Add "mode" option when creating a network pool.
>>
>> If macvtap is choosed, keep the actual procedure.
>>
>> If bridge is choosed, create linux bridge using net commands(brctl)
>> and create network pool pointing to the new bridge.
>>
>> Create tests for this.
>>
>
> I approve this proposal, but perhaps we can rely on Ginger to do the
> linux bridge? I am worried about having both kimchi and ginger
> messing with the network interfaces.
>
I understand your concern, Daniel! But (I hope) it will be the single
feature in which Kimchi needs to change the host configuration.
Yeah, it was just a 'awareness comment' more than anything. Kimchi needs
to be able to change the host configuration if this will enhance the
user experience. We just need to "take it easy", be as minimalist as
possible, to not end up doing a feature full network management in Kimchi.
For example, if creating a linux bridge using brctl end up conflicting
with something else (Network Manager just popped in my head) , perhaps
we're better of sending a message "a problem happen when creating the
bridge" and let the user handle the situation by himself using Ginger or
other solution.
> _______________________________________________
> Kimchi-devel mailing list
> Kimchi-devel(a)ovirt.org
> http://lists.ovirt.org/mailman/listinfo/kimchi-devel
>
_______________________________________________
Kimchi-devel mailing list
Kimchi-devel(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/kimchi-devel
8:57 a.m.
On 15/10/2015 11:55, Daniel Henrique Barboza wrote:
On 10/15/2015 11:49 AM, Aline Manera wrote:
>
>
> On 15/10/2015 11:36, Daniel Henrique Barboza wrote:
>>
>>
>> On 10/15/2015 10:15 AM, Ramon Medeiros wrote:
>>> Kimchi today creates network pool using macvtap. Now, we want the
>>> user to choose if it want Linux Bridge or macvtap.
>>>
>>> If you want to understand the pros and cons of this features, we
>>> can see here:
>>> https://github.com/kimchi-project/kimchi/wiki/Create-guest-network
>>>
>>> Proposal:
>>>
>>> Add "mode" option when creating a network pool.
>>>
>>> If macvtap is choosed, keep the actual procedure.
>>>
>>> If bridge is choosed, create linux bridge using net commands(brctl)
>>> and create network pool pointing to the new bridge.
>>>
>>> Create tests for this.
>>>
>>
>> I approve this proposal, but perhaps we can rely on Ginger to do the
>> linux bridge? I am worried about having both kimchi and ginger
>> messing with the network interfaces.
>>
>
> I understand your concern, Daniel! But (I hope) it will be the single
> feature in which Kimchi needs to change the host configuration.
Yeah, it was just a 'awareness comment' more than anything. Kimchi
needs to be able to change the host configuration if this will enhance
the user experience. We just need to "take it easy", be as minimalist
as possible, to not end up doing a feature full network management in
Kimchi.
For example, if creating a linux bridge using brctl end up conflicting
with something else (Network Manager just popped in my head) , perhaps
we're better of sending a message "a problem happen when creating the
bridge" and let the user handle the situation by himself using Ginger
or other solution.
Completely agree.
>
>> _______________________________________________
>> Kimchi-devel mailing list
>> Kimchi-devel(a)ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/kimchi-devel
>>
>
> _______________________________________________
> Kimchi-devel mailing list
> Kimchi-devel(a)ovirt.org
> http://lists.ovirt.org/mailman/listinfo/kimchi-devel
_______________________________________________
Kimchi-devel mailing list
Kimchi-devel(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/kimchi-devel
9:12 a.m.
On 15.10.2015 16:49, Aline Manera wrote:
On 15/10/2015 11:36, Daniel Henrique Barboza wrote:
>
>
> On 10/15/2015 10:15 AM, Ramon Medeiros wrote:
>> Kimchi today creates network pool using macvtap. Now, we want the
>> user to choose if it want Linux Bridge or macvtap.
>>
>> If you want to understand the pros and cons of this features, we can
>> see here:
>> https://github.com/kimchi-project/kimchi/wiki/Create-guest-network
>>
>> Proposal:
>>
>> Add "mode" option when creating a network pool.
>>
>> If macvtap is choosed, keep the actual procedure.
>>
>> If bridge is choosed, create linux bridge using net commands(brctl)
>> and create network pool pointing to the new bridge.
>>
>> Create tests for this.
>>
>
> I approve this proposal, but perhaps we can rely on Ginger to do the
> linux bridge? I am worried about having both kimchi and ginger
> messing with the network interfaces.
>
I understand your concern, Daniel! But (I hope) it will be the single
feature in which Kimchi needs to change the host configuration.
Aline, Daniel,
I'm concerned as well here about the potential conflicts
and I think we may have the same issue with VLAN devices.
I don't know how to distinguish if a bridge or VLAN device was created
via Host- or via Guest-Management and therefore we may list and expose
the Guest-Management bridges or VLANs in the Host-Networking area,
assuming the Host Admin knows not to touch them. He has anyhow lots of
tools on his hands to do harm if he is not acting carefull :-)
Can we base on such an assumption ?
> _______________________________________________
> Kimchi-devel mailing list
> Kimchi-devel(a)ovirt.org
> http://lists.ovirt.org/mailman/listinfo/kimchi-devel
>
_______________________________________________
Kimchi-devel mailing list
Kimchi-devel(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/kimchi-devel
8:41 a.m.
Hi Ramon,
From the API documentation:
**URI:** /plugins/kimchi/networks
* **POST**: Create a new Network
* name: The name of the Network
* connection: Specifies how this network should be connected to the
other
networks visible to this host.
* isolated: Create a private, isolated virtual network.
* nat: Outgoing traffic will be routed through the host.
* bridge: All traffic on this network will be bridged through
the indicated interface.
So to create a new network, the user needs to specify the network name
and connection.
The current 'bridge' connection is related to macvtap.
I suggest to change it to create a Linux bridge and add a new connection
type "macvtap" to handle the macvtap bridge.
That way we don't need to add any new parameter in the API.
So the API would be:
# API to create a macvtap bridge
POST /plugins/kimchi/networks {name: macvtap-bridge, connection: macvtap}
# API to create a Linux bridge
POST /plugins/kimchi/networks {name: linux-bridge, connection: bridge}
What do you think about it?
Regards,
Aline Manera
On 15/10/2015 10:15, Ramon Medeiros wrote:
Kimchi today creates network pool using macvtap. Now, we want the
user
to choose if it want Linux Bridge or macvtap.
If you want to understand the pros and cons of this features, we can
see here:
https://github.com/kimchi-project/kimchi/wiki/Create-guest-network
Proposal:
Add "mode" option when creating a network pool.
If macvtap is choosed, keep the actual procedure.
If bridge is choosed, create linux bridge using net commands(brctl)
and create network pool pointing to the new bridge.
Create tests for this.
9:04 a.m.
On 10/15/2015 11:41 AM, Aline Manera wrote:
Hi Ramon,
From the API documentation:
**URI:** /plugins/kimchi/networks
* **POST**: Create a new Network
* name: The name of the Network
* connection: Specifies how this network should be connected to
the other
networks visible to this host.
* isolated: Create a private, isolated virtual network.
* nat: Outgoing traffic will be routed through the host.
* bridge: All traffic on this network will be bridged through
the indicated interface.
So to create a new network, the user needs to specify the network name
and connection.
The current 'bridge' connection is related to macvtap.
I suggest to change it to create a Linux bridge and add a new
connection type "macvtap" to handle the macvtap bridge.
That way we don't need to add any new parameter in the API.
So the API would be:
# API to create a macvtap bridge
POST /plugins/kimchi/networks {name: macvtap-bridge, connection: macvtap}
# API to create a Linux bridge
POST /plugins/kimchi/networks {name: linux-bridge, connection: bridge}
What do you think about it?
That what i was thinking. I will start it
Regards,
Aline Manera
On 15/10/2015 10:15, Ramon Medeiros wrote:
> Kimchi today creates network pool using macvtap. Now, we want the
> user to choose if it want Linux Bridge or macvtap.
>
> If you want to understand the pros and cons of this features, we can
> see here:
> https://github.com/kimchi-project/kimchi/wiki/Create-guest-network
>
> Proposal:
>
> Add "mode" option when creating a network pool.
>
> If macvtap is choosed, keep the actual procedure.
>
> If bridge is choosed, create linux bridge using net commands(brctl)
> and create network pool pointing to the new bridge.
>
> Create tests for this.
>
--
Ramon Nunes Medeiros
Kimchi Developer
Linux Technology Center Brazil
IBM Systems & Technology Group
Phone : +55 19 2132 7878
ramonn(a)br.ibm.com
8:45 a.m.
New subject: [RFC] Create logical pool from existing VG
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.
API:
Collection: /plugins/kimchi/host/vgs
Method: GET
Returns: list of vgnames:
[vgname1, vgname2]
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] }
Resource: /plugins/kimchi/storagepools/vgname
Method: POST
data: { vgname, storagepool_name, type=logical }
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 |
+--------+
8:56 a.m.
New subject: [RFC] Create logical pool from existing VG
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.
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?
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
_______________________________________________
Kimchi-devel mailing list
Kimchi-devel(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/kimchi-devel
9 a.m.
New subject: [RFC] Create logical pool from existing VG
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.
>
> 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.
>
> _______________________________________________
> Kimchi-devel mailing list
> Kimchi-devel(a)ovirt.org
> http://lists.ovirt.org/mailman/listinfo/kimchi-devel
>
--
Jose Ricardo Ziviani
-----------------------------
Software Engineer
Linux Technology Center - IBM
10:12 a.m.
New subject: [RFC] Create logical pool from existing VG
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.
>>
>> 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.
>
>>
>> _______________________________________________
>> Kimchi-devel mailing list
>> Kimchi-devel(a)ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/kimchi-devel
>>
>
11 a.m.
New subject: [RFC] Create logical pool from existing VG
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.
>>>
>>> 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
>>>
>>
>
--
Jose Ricardo Ziviani
-----------------------------
Software Engineer
Linux Technology Center - IBM
11:35 a.m.
New subject: [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
>>>>
>>>
>>
>
1 p.m.
New subject: [RFC] Create logical pool from existing VG
On 15/10/2015 14:35, Suresh Babu Angadi wrote:
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.
Yeap! Wok is only a basic web server! And it should not have those kind
of features.
>>>>> 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
>>>>>
>>>>
>>>
>>
>
12:58 p.m.
New subject: [RFC] Create logical pool from existing VG
On 15/10/2015 14:00, 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.
>>>>
>>>> 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) |
+--------------------------+
Or keep only one Logical entry here and a radio box to switch between VG
or raw disks.
( ) Create from existing LVM ( ) Create from raw disks
Once one of those options is selected more options are displayed below,
in a similar way you did.
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?
Agree.
>
>>
>>>
>>>>
>>>> _______________________________________________
>>>> Kimchi-devel mailing list
>>>> Kimchi-devel(a)ovirt.org
>>>> http://lists.ovirt.org/mailman/listinfo/kimchi-devel
>>>>
>>>
>>
>
3113
days inactive
3113
days old
15 comments
7 participants
participants (7)
-
Aline Manera -
Daniel Henrique Barboza -
Daniel Henrique Barboza -
Jose Ricardo Ziviani -
Ramon Medeiros -
Suresh Babu Angadi -
Walter Niklaus