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
>>> 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
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
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.
>>> 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.
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
>>>>> 4. You're using the terminology "role", but it might be
>>>>> as we have "roles" with regards to permissions. Consider
>>>>> "storage usage" and not "storage role" in the
>>>> Well, we've already been using this terminology for a while now
>>>> concerning display/migration roles for networks... That's probably
>>>> 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
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.