[Feature review] Select network to be used for glusterfs
Hi all, Please review the feature page for this proposed solution and provide your inputs - http://www.ovirt.org/Features/Select_Network_For_Gluster thanks sahina
Hi Sahina, Some comments: 1. As far as I understand, you might not have an IP available immediately after setupNetworks runs (getCapabilities should run, but it isn't run automatically, afair). 2. Perhaps you should pass not the IP but the name of the network? IPs might change. 3. Adding to "2", perhaps using DNS names is a more valid approach? 4. You're using the terminology "role", but it might be confusing, as we have "roles" with regards to permissions. Consider changing "storage usage" and not "storage role" in the feature page. Thanks, Oved ----- Original Message -----
From: "Sahina Bose" <sabose@redhat.com> To: devel@ovirt.org, "users" <users@ovirt.org> Sent: Monday, January 12, 2015 2:00:16 PM Subject: [ovirt-users] [Feature review] Select network to be used for glusterfs
Hi all,
Please review the feature page for this proposed solution and provide your inputs - http://www.ovirt.org/Features/Select_Network_For_Gluster
thanks sahina
_______________________________________________ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
On 12/01/15 14:44, Oved Ourfali wrote:
Hi Sahina,
Some comments:
1. As far as I understand, you might not have an IP available immediately after setupNetworks runs (getCapabilities should run, but it isn't run automatically, afair). 2. Perhaps you should pass not the IP but the name of the network? IPs might change.
Actually, IP address can indeed change - which would be very bad for gluster functioning! I think moving networks or changing their IP addresses via Setup Networks should be blocked if they're used by gluster bricks.
3. Adding to "2", perhaps using DNS names is a more valid approach? 4. You're using the terminology "role", but it might be confusing, as we have "roles" with regards to permissions. Consider changing "storage usage" and not "storage role" in the feature page.
Well, we've already been using this terminology for a while now concerning display/migration roles for networks... That's probably the terminology to use.
Thanks, Oved
----- Original Message -----
From: "Sahina Bose" <sabose@redhat.com> To: devel@ovirt.org, "users" <users@ovirt.org> Sent: Monday, January 12, 2015 2:00:16 PM Subject: [ovirt-users] [Feature review] Select network to be used for glusterfs
Hi all,
Please review the feature page for this proposed solution and provide your inputs - http://www.ovirt.org/Features/Select_Network_For_Gluster
thanks sahina
_______________________________________________ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
_______________________________________________ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
On Mon, Jan 12, 2015 at 02:59:50PM +0200, Lior Vernia wrote:
On 12/01/15 14:44, Oved Ourfali wrote:
Hi Sahina,
Some comments:
1. As far as I understand, you might not have an IP available immediately after setupNetworks runs (getCapabilities should run, but it isn't run automatically, afair). 2. Perhaps you should pass not the IP but the name of the network? IPs might change.
Actually, IP address can indeed change - which would be very bad for gluster functioning! I think moving networks or changing their IP addresses via Setup Networks should be blocked if they're used by gluster bricks.
In the suggested feature, there is no real storage "role". The "storage role" title means only "default value for glusterfs IP". For example, once a brick was created, nothing protects the admin from accidently removing the storage network, or changing its IP address. Another "proof" that this is not a real "role", is that it affects only GUI: I am guessing that REST API would not make use of it at all. (maybe I'm wrong; for sure, REST must be defined in the feature page) Maybe that's the behavior we want. But alternatively, Engine can enforce a stronger linkage between the brick to the network that it uses. When adding a brick, the dialog would list available networks instead of the specific IP. As long as the brick is being used, the admin would be blocked/warned against deleting the network. I'm missing a discussion regarding the upgrade path. If we would opt to requiring a single storage role network in a cluster, in an upgraded cluster the management network should take this role.
3. Adding to "2", perhaps using DNS names is a more valid approach? 4. You're using the terminology "role", but it might be confusing, as we have "roles" with regards to permissions. Consider changing "storage usage" and not "storage role" in the feature page.
Well, we've already been using this terminology for a while now concerning display/migration roles for networks... That's probably the terminology to use.
Thanks, Oved
----- Original Message -----
From: "Sahina Bose" <sabose@redhat.com> To: devel@ovirt.org, "users" <users@ovirt.org> Sent: Monday, January 12, 2015 2:00:16 PM Subject: [ovirt-users] [Feature review] Select network to be used for glusterfs
Hi all,
Please review the feature page for this proposed solution and provide your inputs - http://www.ovirt.org/Features/Select_Network_For_Gluster
thanks sahina
On 01/12/2015 08:52 PM, Dan Kenigsberg wrote:
On Mon, Jan 12, 2015 at 02:59:50PM +0200, Lior Vernia wrote:
On 12/01/15 14:44, Oved Ourfali wrote:
Hi Sahina,
Some comments:
1. As far as I understand, you might not have an IP available immediately after setupNetworks runs (getCapabilities should run, but it isn't run automatically, afair). 2. Perhaps you should pass not the IP but the name of the network? IPs might change. Actually, IP address can indeed change - which would be very bad for gluster functioning! I think moving networks or changing their IP addresses via Setup Networks should be blocked if they're used by gluster bricks.
In the suggested feature, there is no real storage "role". The "storage role" title means only "default value for glusterfs IP".
For example, once a brick was created, nothing protects the admin from accidently removing the storage network, or changing its IP address.
Another "proof" that this is not a real "role", is that it affects only GUI: I am guessing that REST API would not make use of it at all. (maybe I'm wrong; for sure, REST must be defined in the feature page)
REST API that lists the available networks (with IP addresses) would be used to select the network and pass to the create gluster volume API I'll update the feature page with the REST API changes as well.
Maybe that's the behavior we want. But alternatively, Engine can enforce a stronger linkage between the brick to the network that it uses. When adding a brick, the dialog would list available networks instead of the specific IP. As long as the brick is being used, the admin would be blocked/warned against deleting the network.
Is there a way to block against changing IP address used by a network?
I'm missing a discussion regarding the upgrade path. If we would opt to requiring a single storage role network in a cluster, in an upgraded cluster the management network should take this role.
There would not be any change to existing volumes on upgrade, as bricks have already been added. Users can use the Edit brick option to update the network to be used, if required as mentioned in "Change network used by brick "
3. Adding to "2", perhaps using DNS names is a more valid approach? 4. You're using the terminology "role", but it might be confusing, as we have "roles" with regards to permissions. Consider changing "storage usage" and not "storage role" in the feature page. Well, we've already been using this terminology for a while now concerning display/migration roles for networks... That's probably the terminology to use.
Thanks, Oved
----- Original Message -----
From: "Sahina Bose" <sabose@redhat.com> To: devel@ovirt.org, "users" <users@ovirt.org> Sent: Monday, January 12, 2015 2:00:16 PM Subject: [ovirt-users] [Feature review] Select network to be used for glusterfs
Hi all,
Please review the feature page for this proposed solution and provide your inputs - http://www.ovirt.org/Features/Select_Network_For_Gluster
thanks sahina
Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
On 13/01/15 10:21, Sahina Bose wrote:
On 01/12/2015 08:52 PM, Dan Kenigsberg wrote:
On Mon, Jan 12, 2015 at 02:59:50PM +0200, Lior Vernia wrote:
On 12/01/15 14:44, Oved Ourfali wrote:
Hi Sahina,
Some comments:
1. As far as I understand, you might not have an IP available immediately after setupNetworks runs (getCapabilities should run, but it isn't run automatically, afair). 2. Perhaps you should pass not the IP but the name of the network? IPs might change. Actually, IP address can indeed change - which would be very bad for gluster functioning! I think moving networks or changing their IP addresses via Setup Networks should be blocked if they're used by gluster bricks.
In the suggested feature, there is no real storage "role". The "storage role" title means only "default value for glusterfs IP".
For example, once a brick was created, nothing protects the admin from accidently removing the storage network, or changing its IP address.
Another "proof" that this is not a real "role", is that it affects only GUI: I am guessing that REST API would not make use of it at all. (maybe I'm wrong; for sure, REST must be defined in the feature page)
REST API that lists the available networks (with IP addresses) would be used to select the network and pass to the create gluster volume API
I'll update the feature page with the REST API changes as well.
If REST allows to choose the network used for gluster traffic, then I think so should the GUI - I would not drop the list box from the design in that case.
Maybe that's the behavior we want. But alternatively, Engine can enforce a stronger linkage between the brick to the network that it uses. When adding a brick, the dialog would list available networks instead of the specific IP. As long as the brick is being used, the admin would be blocked/warned against deleting the network.
Is there a way to block against changing IP address used by a network?
Yes, this should be implemented at least in the canDoAction() method of SetupNetworksCommand (most of it is done in the SetupNetworksHelper class). And perhaps this should be blocked in the GUI as well. Note that by the time 3.6 is released, the REST (and probably GUI) are supposed to work with a different backend command that is currently being implemented - so maybe you'll need to modify that instead, or on top of the changes in SetupNetworksHelper.
I'm missing a discussion regarding the upgrade path. If we would opt to requiring a single storage role network in a cluster, in an upgraded cluster the management network should take this role.
There would not be any change to existing volumes on upgrade, as bricks have already been added. Users can use the Edit brick option to update the network to be used, if required as mentioned in "Change network used by brick "
I suspect Dan referred to the upgrade path of the engine itself - if you add a new "Gluster Network" boolean column to the DB, it will initially be null for all current networks. You'd likely need to write an upgrade script to assign the role by default to the existing management networks in each cluster.
3. Adding to "2", perhaps using DNS names is a more valid approach? 4. You're using the terminology "role", but it might be confusing, as we have "roles" with regards to permissions. Consider changing "storage usage" and not "storage role" in the feature page. Well, we've already been using this terminology for a while now concerning display/migration roles for networks... That's probably the terminology to use.
Thanks, Oved
----- Original Message -----
From: "Sahina Bose" <sabose@redhat.com> To: devel@ovirt.org, "users" <users@ovirt.org> Sent: Monday, January 12, 2015 2:00:16 PM Subject: [ovirt-users] [Feature review] Select network to be used for glusterfs
Hi all,
Please review the feature page for this proposed solution and provide your inputs - http://www.ovirt.org/Features/Select_Network_For_Gluster
thanks sahina
Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
On Tue, Jan 13, 2015 at 02:51:34PM +0200, Lior Vernia wrote:
On 13/01/15 10:21, Sahina Bose wrote:
On 01/12/2015 08:52 PM, Dan Kenigsberg wrote:
On Mon, Jan 12, 2015 at 02:59:50PM +0200, Lior Vernia wrote:
On 12/01/15 14:44, Oved Ourfali wrote:
Hi Sahina,
Some comments:
1. As far as I understand, you might not have an IP available immediately after setupNetworks runs (getCapabilities should run, but it isn't run automatically, afair). 2. Perhaps you should pass not the IP but the name of the network? IPs might change. Actually, IP address can indeed change - which would be very bad for gluster functioning! I think moving networks or changing their IP addresses via Setup Networks should be blocked if they're used by gluster bricks.
In the suggested feature, there is no real storage "role". The "storage role" title means only "default value for glusterfs IP".
For example, once a brick was created, nothing protects the admin from accidently removing the storage network, or changing its IP address.
Another "proof" that this is not a real "role", is that it affects only GUI: I am guessing that REST API would not make use of it at all. (maybe I'm wrong; for sure, REST must be defined in the feature page)
REST API that lists the available networks (with IP addresses) would be used to select the network and pass to the create gluster volume API
My question regarded the argument of the add brick API (in Engine level). Is it an IPv4 address (like it seems) or could it be a network name?
I'll update the feature page with the REST API changes as well.
If REST allows to choose the network used for gluster traffic, then I think so should the GUI - I would not drop the list box from the design in that case.
Maybe that's the behavior we want. But alternatively, Engine can enforce a stronger linkage between the brick to the network that it uses. When adding a brick, the dialog would list available networks instead of the specific IP. As long as the brick is being used, the admin would be blocked/warned against deleting the network.
Is there a way to block against changing IP address used by a network?
Yes, this should be implemented at least in the canDoAction() method of SetupNetworksCommand (most of it is done in the SetupNetworksHelper class). And perhaps this should be blocked in the GUI as well.
Note that by the time 3.6 is released, the REST (and probably GUI) are supposed to work with a different backend command that is currently being implemented - so maybe you'll need to modify that instead, or on top of the changes in SetupNetworksHelper.
I'm missing a discussion regarding the upgrade path. If we would opt to requiring a single storage role network in a cluster, in an upgraded cluster the management network should take this role.
There would not be any change to existing volumes on upgrade, as bricks have already been added. Users can use the Edit brick option to update the network to be used, if required as mentioned in "Change network used by brick "
I suspect Dan referred to the upgrade path of the engine itself - if you add a new "Gluster Network" boolean column to the DB, it will initially be null for all current networks. You'd likely need to write an upgrade script to assign the role by default to the existing management networks in each cluster.
yep.
3. Adding to "2", perhaps using DNS names is a more valid approach? 4. You're using the terminology "role", but it might be confusing, as we have "roles" with regards to permissions. Consider changing "storage usage" and not "storage role" in the feature page. Well, we've already been using this terminology for a while now concerning display/migration roles for networks... That's probably the terminology to use.
If I am not mistaken, it could make sense to have a setup with one brick using network A and another - using network B. Does your design support this? I think that this would be particularly important on upgraded clusters, where the management network is already used, but newly created bricks should start using another network. Would you add a feature page section regarding modification to the Vdsm/Engine API? One last comment - may I ask that new APIs accept both ipv4 and ipv6 addresses? There is an ongoing effort to support ipv6 on Vdsm. Dan.
On 01/13/2015 09:45 PM, Dan Kenigsberg wrote:
On Tue, Jan 13, 2015 at 02:51:34PM +0200, Lior Vernia wrote:
On 13/01/15 10:21, Sahina Bose wrote:
On 01/12/2015 08:52 PM, Dan Kenigsberg wrote:
On Mon, Jan 12, 2015 at 02:59:50PM +0200, Lior Vernia wrote:
On 12/01/15 14:44, Oved Ourfali wrote:
Hi Sahina,
Some comments:
1. As far as I understand, you might not have an IP available immediately after setupNetworks runs (getCapabilities should run, but it isn't run automatically, afair). 2. Perhaps you should pass not the IP but the name of the network? IPs might change. Actually, IP address can indeed change - which would be very bad for gluster functioning! I think moving networks or changing their IP addresses via Setup Networks should be blocked if they're used by gluster bricks. In the suggested feature, there is no real storage "role". The "storage role" title means only "default value for glusterfs IP".
For example, once a brick was created, nothing protects the admin from accidently removing the storage network, or changing its IP address.
Another "proof" that this is not a real "role", is that it affects only GUI: I am guessing that REST API would not make use of it at all. (maybe I'm wrong; for sure, REST must be defined in the feature page) REST API that lists the available networks (with IP addresses) would be used to select the network and pass to the create gluster volume API
My question regarded the argument of the add brick API (in Engine level). Is it an IPv4 address (like it seems) or could it be a network name?
I've updated the feature page with the REST API and other comments. On further thought, there will be no change to Add brick API, as the engine will select the network to be used based on the networks setup for the host. If "Storage network" role is associated with any of the networks, this will be used. Otherwise, the host's address will be used to add the brick. There is a NEW API to allow for updation of brick's address.
I'll update the feature page with the REST API changes as well.
If REST allows to choose the network used for gluster traffic, then I think so should the GUI - I would not drop the list box from the design in that case.
See above - have kept REST API consistent.
Maybe that's the behavior we want. But alternatively, Engine can enforce a stronger linkage between the brick to the network that it uses. When adding a brick, the dialog would list available networks instead of the specific IP. As long as the brick is being used, the admin would be blocked/warned against deleting the network. Is there a way to block against changing IP address used by a network?
Yes, this should be implemented at least in the canDoAction() method of SetupNetworksCommand (most of it is done in the SetupNetworksHelper class). And perhaps this should be blocked in the GUI as well.
Note that by the time 3.6 is released, the REST (and probably GUI) are supposed to work with a different backend command that is currently being implemented - so maybe you'll need to modify that instead, or on top of the changes in SetupNetworksHelper.
Ok. Thanks!
I'm missing a discussion regarding the upgrade path. If we would opt to requiring a single storage role network in a cluster, in an upgraded cluster the management network should take this role. There would not be any change to existing volumes on upgrade, as bricks have already been added. Users can use the Edit brick option to update the network to be used, if required as mentioned in "Change network used by brick "
I suspect Dan referred to the upgrade path of the engine itself - if you add a new "Gluster Network" boolean column to the DB, it will initially be null for all current networks. You'd likely need to write an upgrade script to assign the role by default to the existing management networks in each cluster.
yep.
Aah..ok! The "Gluster network" is not a mandatory role. That is, we could have a case where the user does not want to select any network as "Gluster network" and instead choose to continue using host's address for adding bricks. So existing deployments would continue to work as before - without this role assigned to any of the networks.
3. Adding to "2", perhaps using DNS names is a more valid approach? 4. You're using the terminology "role", but it might be confusing, as we have "roles" with regards to permissions. Consider changing "storage usage" and not "storage role" in the feature page. Well, we've already been using this terminology for a while now concerning display/migration roles for networks... That's probably the terminology to use. If I am not mistaken, it could make sense to have a setup with one brick using network A and another - using network B. Does your design support this? I think that this would be particularly important on upgraded clusters, where the management network is already used, but newly created bricks should start using another network.
Would you add a feature page section regarding modification to the Vdsm/Engine API?
One last comment - may I ask that new APIs accept both ipv4 and ipv6 addresses? There is an ongoing effort to support ipv6 on Vdsm.
Dan.
On Thu, Jan 15, 2015 at 12:34:18PM +0530, Sahina Bose wrote:
I've updated the feature page with the REST API and other comments. On further thought, there will be no change to Add brick API, as the engine will select the network to be used based on the networks setup for the host. If "Storage network" role is associated with any of the networks, this will be used. Otherwise, the host's address will be used to add the brick.
<snip> The paragraph above rules out the use case I lay below. Could you relate to it? Isn't it a reasonable use case?
If I am not mistaken, it could make sense to have a setup with one brick using network A and another - using network B. Does your design support this? I think that this would be particularly important on upgraded clusters, where the management network is already used, but newly created bricks should start using another network.
May I repeat my follow request? It would help me understand the content of the feature.
Would you add a feature page section regarding modification to the Vdsm/Engine API?
One last comment - may I ask that new APIs accept both ipv4 and ipv6 addresses? There is an ongoing effort to support ipv6 on Vdsm.
On 01/15/2015 02:27 PM, Dan Kenigsberg wrote:
On Thu, Jan 15, 2015 at 12:34:18PM +0530, Sahina Bose wrote:
I've updated the feature page with the REST API and other comments. On further thought, there will be no change to Add brick API, as the engine will select the network to be used based on the networks setup for the host. If "Storage network" role is associated with any of the networks, this will be used. Otherwise, the host's address will be used to add the brick.
<snip>
The paragraph above rules out the use case I lay below. Could you relate to it? Isn't it a reasonable use case?
If I am not mistaken, it could make sense to have a setup with one brick using network A and another - using network B. Does your design support this? I think that this would be particularly important on upgraded clusters, where the management network is already used, but newly created bricks should start using another network.
On upgraded clusters, the user would have to assign a network with the role "Storage network". Any newly created brick would then start using this, rather than the management network. I'm not sure if the use case where each brick on a host is added using different networks is a common one (apart from the upgrade scenario, that is). If it is, we could provide an Advanced edit option in the UI to select network in Add Bricks dialog. The entity design supports setting different network per brick and the REST API already provides a way to set this as an optional parameter.
May I repeat my follow request? It would help me understand the content of the feature.
Sorry, I missed these before!
Would you add a feature page section regarding modification to the Vdsm/Engine API?
http://www.ovirt.org/Features/Select_Network_For_Gluster#Change_to_VDSM_API http://www.ovirt.org/Features/Select_Network_For_Gluster#Change_to_REST_API
One last comment - may I ask that new APIs accept both ipv4 and ipv6 addresses? There is an ongoing effort to support ipv6 on Vdsm.
Glusterfs does not support ipv6 yet, so addition of bricks using ipv6 addresses would not work. thanks, sahina
On 01/12/2015 06:14 PM, Oved Ourfali wrote:
Hi Sahina,
Some comments:
1. As far as I understand, you might not have an IP available immediately after setupNetworks runs (getCapabilities should run, but it isn't run automatically, afair). 2. Perhaps you should pass not the IP but the name of the network? IPs might change. 3. Adding to "2", perhaps using DNS names is a more valid approach?
To the gluster volume add brick command, the brick information needs to be passed in the form <ip address or host name>:<directory path> So even if we do show the network names in the UI, we will need the underlying IP address to form this command. Regarding DNS names, currently is there a way to query for the DNS aliases for a host? I would need to use hostname in the command above, and assume that the user has setup his DNS outside of oVirt to correctly resolve to internal/external network, correct?
4. You're using the terminology "role", but it might be confusing, as we have "roles" with regards to permissions. Consider changing "storage usage" and not "storage role" in the feature page.
Thanks, Oved
----- Original Message -----
From: "Sahina Bose" <sabose@redhat.com> To: devel@ovirt.org, "users" <users@ovirt.org> Sent: Monday, January 12, 2015 2:00:16 PM Subject: [ovirt-users] [Feature review] Select network to be used for glusterfs
Hi all,
Please review the feature page for this proposed solution and provide your inputs - http://www.ovirt.org/Features/Select_Network_For_Gluster
thanks sahina
_______________________________________________ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
Hi Sahina! :) Cool feature, and I think long-awaited by many users. I have a few comments: 1. In the "Add Bricks" dialog, it seems like the "IP Address" field is a list box - I presume the items contained there are all IP addresses configured on the host's interfaces. 1. a. May I suggest that this contain network names instead of IP addresses? Would be easier for users to think about things (they surely remember the meaning of network names, not necessarily of IP addresses). 1. b. If I correctly understood the mock-up, then configuring a "Storage Network" role only affects the default entry chosen in the list box. Is it really worth the trouble of implementing this added role? It's quite different than display/migration roles, which are used to determine what IP address to use at a later time (i.e. not when configuring the host), when a VM is run/migrated in the cluster. 1. c. A word of warning: sometimes a host interface's IP address is missing in the engine - this usually happens when they're configured for the first time with DHCP, and the setup networks command returns before an IP address is allocated (this can later be resolved by refreshing host capabilities, there's a button for that). So when displaying items in the list box, you should really check that an IP address exists for each network. 2. "Storage Network": if you intend to keep this role in the feature (I don't think it adds a lot of functionality, see article 1b), it might be better to call it "Gluster Network" - otherwise people using virt mode might think this network is gonna be used to communicate with other types of storage domains. Yours, Lior. On 12/01/15 14:00, Sahina Bose wrote:
Hi all,
Please review the feature page for this proposed solution and provide your inputs - http://www.ovirt.org/Features/Select_Network_For_Gluster
thanks sahina
_______________________________________________ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
2. "Storage Network": if you intend to keep this role in the feature (I don't think it adds a lot of functionality, see article 1b), it might be better to call it "Gluster Network" - otherwise people using virt mode might think this network is gonna be used to communicate with other types of storage domains.
+1 on "Storage Network" -> "Gluster Network" (assuming this role is kept, as Lior mentioned).
----- Original Message ----- From: "Lior Vernia" <lvernia@redhat.com> Sent: Monday, January 12, 2015 7:51:05 AM
Hi Sahina! :)
Cool feature, and I think long-awaited by many users. I have a few comments:
1. In the "Add Bricks" dialog, it seems like the "IP Address" field is a list box - I presume the items contained there are all IP addresses configured on the host's interfaces.
1. a. May I suggest that this contain network names instead of IP addresses? Would be easier for users to think about things (they surely remember the meaning of network names, not necessarily of IP addresses).
1. b. If I correctly understood the mock-up, then configuring a "Storage Network" role only affects the default entry chosen in the list box. Is it really worth the trouble of implementing this added role? It's quite different than display/migration roles, which are used to determine what IP address to use at a later time (i.e. not when configuring the host), when a VM is run/migrated in the cluster.
1. c. A word of warning: sometimes a host interface's IP address is missing in the engine - this usually happens when they're configured for the first time with DHCP, and the setup networks command returns before an IP address is allocated (this can later be resolved by refreshing host capabilities, there's a button for that). So when displaying items in the list box, you should really check that an IP address exists for each network.
2. "Storage Network": if you intend to keep this role in the feature (I don't think it adds a lot of functionality, see article 1b), it might be better to call it "Gluster Network" - otherwise people using virt mode might think this network is gonna be used to communicate with other types of storage domains.
Yours, Lior.
On 12/01/15 14:00, Sahina Bose wrote:
Hi all,
Please review the feature page for this proposed solution and provide your inputs - http://www.ovirt.org/Features/Select_Network_For_Gluster
thanks sahina
_______________________________________________ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
On 01/12/2015 06:21 PM, Lior Vernia wrote:
Hi Sahina! :)
Cool feature, and I think long-awaited by many users. I have a few comments:
1. In the "Add Bricks" dialog, it seems like the "IP Address" field is a list box - I presume the items contained there are all IP addresses configured on the host's interfaces.
1. a. May I suggest that this contain network names instead of IP addresses? Would be easier for users to think about things (they surely remember the meaning of network names, not necessarily of IP addresses).
1. b. If I correctly understood the mock-up, then configuring a "Storage Network" role only affects the default entry chosen in the list box. Is it really worth the trouble of implementing this added role? It's quite different than display/migration roles, which are used to determine what IP address to use at a later time (i.e. not when configuring the host), when a VM is run/migrated in the cluster.
If not for "Storage network" role, how would we default which network to use. In fact, we are planning to remove the drop down to choose network from the Add Brick UI, to avoid confusion and just use the network with this role, if available - otherwise use the host address. (host_address in vds_static) Will update page accordingly
1. c. A word of warning: sometimes a host interface's IP address is missing in the engine - this usually happens when they're configured for the first time with DHCP, and the setup networks command returns before an IP address is allocated (this can later be resolved by refreshing host capabilities, there's a button for that). So when displaying items in the list box, you should really check that an IP address exists for each network.
2. "Storage Network": if you intend to keep this role in the feature (I don't think it adds a lot of functionality, see article 1b), it might be better to call it "Gluster Network" - otherwise people using virt mode might think this network is gonna be used to communicate with other types of storage domains.
Could this network be reused for other storage needs also. If not, we can rename it "gluster network"
Yours, Lior.
On 12/01/15 14:00, Sahina Bose wrote:
Hi all,
Please review the feature page for this proposed solution and provide your inputs - http://www.ovirt.org/Features/Select_Network_For_Gluster
thanks sahina
_______________________________________________ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
On 13/01/15 10:18, Sahina Bose wrote:
On 01/12/2015 06:21 PM, Lior Vernia wrote:
Hi Sahina! :)
Cool feature, and I think long-awaited by many users. I have a few comments:
1. In the "Add Bricks" dialog, it seems like the "IP Address" field is a list box - I presume the items contained there are all IP addresses configured on the host's interfaces.
1. a. May I suggest that this contain network names instead of IP addresses? Would be easier for users to think about things (they surely remember the meaning of network names, not necessarily of IP addresses).
1. b. If I correctly understood the mock-up, then configuring a "Storage Network" role only affects the default entry chosen in the list box. Is it really worth the trouble of implementing this added role? It's quite different than display/migration roles, which are used to determine what IP address to use at a later time (i.e. not when configuring the host), when a VM is run/migrated in the cluster.
If not for "Storage network" role, how would we default which network to use. In fact, we are planning to remove the drop down to choose network from the Add Brick UI, to avoid confusion and just use the network with this role, if available - otherwise use the host address. (host_address in vds_static)
If the list box goes, then yeah, somehow you'll have to mark the network used for gluster traffic, so a role would be good. However, if you keep the list box, any order would be fine (maybe alphabetic with the management network as default?).
Will update page accordingly
1. c. A word of warning: sometimes a host interface's IP address is missing in the engine - this usually happens when they're configured for the first time with DHCP, and the setup networks command returns before an IP address is allocated (this can later be resolved by refreshing host capabilities, there's a button for that). So when displaying items in the list box, you should really check that an IP address exists for each network.
2. "Storage Network": if you intend to keep this role in the feature (I don't think it adds a lot of functionality, see article 1b), it might be better to call it "Gluster Network" - otherwise people using virt mode might think this network is gonna be used to communicate with other types of storage domains.
Could this network be reused for other storage needs also. If not, we can rename it "gluster network"
I don't think there are any current plans to incorporate a "storage network" in 3.6, CCing Allon though.
Yours, Lior.
On 12/01/15 14:00, Sahina Bose wrote:
Hi all,
Please review the feature page for this proposed solution and provide your inputs - http://www.ovirt.org/Features/Select_Network_For_Gluster
thanks sahina
_______________________________________________ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
participants (5)
-
Dan Kenigsberg -
Einav Cohen -
Lior Vernia -
Oved Ourfali -
Sahina Bose