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
> be used. Otherwise, the host's address will be used to add the brick.
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
of the feature.
Sorry, I missed these before!
>> Would you add a feature page section regarding modification
>> Vdsm/Engine API?
>> One last comment - may I ask that new APIs accept both ipv4
>> 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.