6 a.m.
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
6:44 a.m.
New subject: [Feature review] Select network to be used for glusterfs
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(a)redhat.com>
To: devel(a)ovirt.org, "users" <users(a)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(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/users
6:59 a.m.
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(a)redhat.com>
> To: devel(a)ovirt.org, "users" <users(a)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(a)ovirt.org
> http://lists.ovirt.org/mailman/listinfo/users
>
_______________________________________________
Users mailing list
Users(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/users
9:22 a.m.
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(a)redhat.com>
>> To: devel(a)ovirt.org, "users" <users(a)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
2:21 a.m.
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(a)redhat.com>
>>> To: devel(a)ovirt.org, "users" <users(a)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(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/users
6:51 a.m.
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(a)redhat.com>
>>>> To: devel(a)ovirt.org, "users" <users(a)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(a)ovirt.org
> http://lists.ovirt.org/mailman/listinfo/users
10:15 a.m.
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.
1:04 a.m.
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.
2:57 a.m.
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.
1:12 a.m.
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
2:12 a.m.
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(a)redhat.com>
> To: devel(a)ovirt.org, "users" <users(a)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(a)ovirt.org
> http://lists.ovirt.org/mailman/listinfo/users
>
6:51 a.m.
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(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/users
7:56 a.m.
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(a)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(a)ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/users
> _______________________________________________
> Users mailing list
> Users(a)ovirt.org
> http://lists.ovirt.org/mailman/listinfo/users
>
2:18 a.m.
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(a)ovirt.org
> http://lists.ovirt.org/mailman/listinfo/users
6:45 a.m.
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(a)ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/users
3543
days inactive
3547
days old
14 comments
5 participants
participants (5)
-
Dan Kenigsberg -
Einav Cohen -
Lior Vernia -
Oved Ourfali -
Sahina Bose