[RFC] Add support for Macvtap and Linux Bridge
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@br.ibm.com
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.
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@ovirt.org http://lists.ovirt.org/mailman/listinfo/kimchi-devel
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@ovirt.org http://lists.ovirt.org/mailman/listinfo/kimchi-devel
_______________________________________________ Kimchi-devel mailing list Kimchi-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/kimchi-devel
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@ovirt.org http://lists.ovirt.org/mailman/listinfo/kimchi-devel
_______________________________________________ Kimchi-devel mailing list Kimchi-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/kimchi-devel
_______________________________________________ Kimchi-devel mailing list Kimchi-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/kimchi-devel
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@ovirt.org http://lists.ovirt.org/mailman/listinfo/kimchi-devel
_______________________________________________ Kimchi-devel mailing list Kimchi-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/kimchi-devel
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.
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@br.ibm.com
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 | +--------+
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@ovirt.org http://lists.ovirt.org/mailman/listinfo/kimchi-devel
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@ovirt.org http://lists.ovirt.org/mailman/listinfo/kimchi-devel
-- Jose Ricardo Ziviani ----------------------------- Software Engineer Linux Technology Center - IBM
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@ovirt.org http://lists.ovirt.org/mailman/listinfo/kimchi-devel
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@ovirt.org http://lists.ovirt.org/mailman/listinfo/kimchi-devel
-- Jose Ricardo Ziviani ----------------------------- Software Engineer Linux Technology Center - IBM
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@ovirt.org http://lists.ovirt.org/mailman/listinfo/kimchi-devel
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@ovirt.org http://lists.ovirt.org/mailman/listinfo/kimchi-devel
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@ovirt.org http://lists.ovirt.org/mailman/listinfo/kimchi-devel
participants (7)
-
Aline Manera -
Daniel Henrique Barboza -
Daniel Henrique Barboza -
Jose Ricardo Ziviani -
Ramon Medeiros -
Suresh Babu Angadi -
Walter Niklaus