[Bugs] [Bug 1294548] Enhancement: The cli could manage state

[bugzilla at redhat.com]

https://bugzilla.redhat.com/show_bug.cgi?id=1294548

Gaurav Kumar Garg <ggarg at redhat.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ggarg at redhat.com,
                   |                            |joe at julianfamily.org
              Flags|                            |needinfo?(joe at julianfamily.
                   |                            |org)



--- Comment #1 from Gaurav Kumar Garg <ggarg at redhat.com> ---
(In reply to Joe Julian from comment #0)
> puppet, salt, etc all manage gluster state from a 3rd party standpoint to
> manage the steps necessary to change a volume, peer state, etc. They do this
> by taking output from the cli, determining state, then passing change
> commands back in to the cli.
> 
> This is something the cli could manage directly. For instance, a volume of:
> 
> Volume Name: myvolume
> Type: Distribute
> Volume ID: 1fb52916-7fbf-4ef3-99e3-ec06b5b6407a
> Status: Started
> Number of Bricks: 1 x 1 = 1
> Transport-type: tcp
> Bricks:
> Brick1: host1:/srv/gluster/myvolume/brick1
> Brick2: host2:/srv/gluster/myvolume/brick1
> 
> A command like:
> 
> gluster volume state myvolume host1:/srv/gluster/myvolume/brick1
> host2:/srv/gluster/myvolume/brick1 host3:/srv/gluster/myvolume/brick1


You can do it in existing GlusterFS code. just by replacing state to add-brick.
I didn't get this RFE request properly. could you explain what's the need of
having state here for adding brick. 



> Would add a 3rd brick on host3.
> 
> Or:
> 
> gluster volume state myvolume replica 2 host1:/srv/gluster/myvolume/brick1
> host3:/srv/gluster/myvolume/brick1 host2:/srv/gluster/myvolume/brick1
> host4:/srv/gluster/myvolume/brick1
> 
> Would convert the distribute volume to a replicated volume. 
> 
> If the bricks were listed in the wrong order, host1, host2, host3, host4,
> the cli should warn and abort without some sort of switch or keyword that
> makes excessive changes complete. With that override option, however, the
> cli would replace brick, migrating the data from 2 to 3, then add brick with
> replica 2.
> 
> Optimally, the state management command would also accept volume options,
> ie.:
> 
> gluster volume state myvolume host1:/srv/gluster/myvolume/brick1
> host2:/srv/gluster/myvolume/brick1 option cluster.eager-lock=enable option
> performance.stat-prefetch=off


If i am not wrong, i think you mean to say that have one state command in
GlusterFS which is so intelligent that in can do any operation based on the
argument passed. If we are adding one more brick then it can add-one more brick
without specifying add-brick keyword in the command, if we are configuring some
option, it can be done without using "gluster set" command, etc. ?

-- 
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.