Hi,
Currently there are two suggested options for the syntax of add/remove brick:
1) gluster v tier <volname> add-brick [replica <count>] [tier-type <hot/cold>] <brick> ...
this syntax shows that its a add-brick operation on a tiered volume through a argument
instead of distinguishing using the command. The separation of tier-type is done through
parsing. When it comes to the parsing of these [replica <count>] [tier-type <hot/cold>] <brick>,
we need to parse between the tier-type, replica count and bricks. All these three variable
make it complicated to parse and get the replica count, tier-type and brick.
currently the parsing is like:
w = str_getunamb (words[3], opwords_cl);
if (!w) {
type = GF_CLUSTER_TYPE_NONE;
.
.
} else if ((strcmp (w, "replica")) == 0) {
type = GF_CLUSTER_TYPE_REPLICATE;
.
.
}
} else if ((strcmp (w, "stripe")) == 0) {
type = GF_CLUSTER_TYPE_STRIPE;
.
.
} else {
.
.
}
we can use the same for replica as long as replica comes before tier-type on the syntax.
and add the parsing for tier-type using words[4] instead of words[3] and repeat the same.
If its a plain distribute then we will be getting tier-type on words[3]. so we have to parse
it again by checking on the wordcount. the word count influences the parsing to a great extent.
Having the tier-type after replica is looking bit off as tier-type is more important here.
So we can have tier-type before replica count. This has to be maintained thorughtout.
And a separate parsing can make this work. Both these will influence the brick_index used
for parsing the brick making the switch using the word_count bit unclear.
This can be done but will add a lot of complications on code.
2) gluster v tier <volname> add-hot-brick/add-cold-brick [replica <count>] <brick> ...
In this syntax, we remove the tier-type from parsing and mention the type on the command.
The parsing remains the same as add-brick parsing. as differentiate between the hot and cold
brick is done by the command
if (!strcmp(words[1], "detach-tier")) {
ret = do_cli_cmd_volume_detach_tier (state, word,
words, wordcount);
goto out;
} else if (!strcmp(words[1], "attach-tier")) {
ret = do_cli_cmd_volume_attach_tier (state, word,
words, wordcount);
goto out;
} else if (!strcmp(words[3], "add-hot-brick")) {
ret = do_cli_cmd_volume_add_hotbr_tier (state, word,
words, wordcount-1);
goto out;
} else if (!strcmp(words[3], "add-cold-brick")) {
ret = do_cli_cmd_volume_add_coldbr_tier (state, word,
words, wordcount-1);
goto out;
}
it get differentiated here and is sent to the respective function. and the parsing remains same.
Let me know which one is the better one to follow.
----- Original Message -----
> From: "Hari Gowtham" <hgowtham@xxxxxxxxxx>
> To: "Atin Mukherjee" <amukherj@xxxxxxxxxx>
> Cc: "gluster-users" <gluster-users@xxxxxxxxxxx>, "gluster-devel" <gluster-devel@xxxxxxxxxxx>
> Sent: Monday, October 3, 2016 4:11:40 PM
> Subject: Re: New commands for supporting add/remove brick and rebalance on tiered volume
>
> Yes. this sounds better than having two separate commands for each tier.
> If i don't get any other better solution will go with this one.
> Thanks Atin.
>
> ----- Original Message -----
> > From: "Atin Mukherjee" <amukherj@xxxxxxxxxx>
> > To: "Hari Gowtham" <hgowtham@xxxxxxxxxx>
> > Cc: "gluster-devel" <gluster-devel@xxxxxxxxxxx>, "gluster-users"
> > <gluster-users@xxxxxxxxxxx>
> > Sent: Monday, October 3, 2016 4:02:42 PM
> > Subject: Re: New commands for supporting add/remove brick
> > and rebalance on tiered volume
> >
> > Hari,
> >
> > I think you misunderstood my statement, probably I shouldn't have mentioned
> > existing semantics. One eg here should clarify it, so this is what I
> > propose:
> >
> > gluster v tier <volname> remove-brick tier-type hot <bricks> start
> >
> > Note that my request was to add an argument i.e tier-type here.
> >
> >
> > On Monday 3 October 2016, Hari Gowtham <hgowtham@xxxxxxxxxx> wrote:
> >
> > > Hi Atin,
> > > Yes, we can do it. the existing semantics need some changes because of
> > > the
> > > attach tier command (gluster volume tier <VOLNAME> attach <BRICK>...) the
> > > parsing has to be changed to accommodate the attach tier command. if used
> > > as I
> > > mentioned then we can use the functions of attach tier generic for adding
> > > brick
> > > also. Other thing with using args is. it needs changes to support the
> > > keywords
> > > like replica <count> also. so when we try to make a generic function for
> > > add
> > > brick on tiered volume and attach tier these keywords like replica
> > > <count>
> > > and
> > > tier-type <hot/cold> will need more changes.
> > >
> > > So i feel its better to have a separate command instead of the args.
> > > If i have been missing any pros from having the args let me know.
> > >
> > > ----- Original Message -----
> > > > From: "Atin Mukherjee" <amukherj@xxxxxxxxxx <javascript:;>>
> > > > To: "Hari Gowtham" <hgowtham@xxxxxxxxxx <javascript:;>>
> > > > Cc: "gluster-devel" <gluster-devel@xxxxxxxxxxx <javascript:;>>,
> > > "gluster-users" <gluster-users@xxxxxxxxxxx <javascript:;>>
> > > > Sent: Monday, October 3, 2016 2:31:40 PM
> > > > Subject: Re: New commands for supporting add/remove
> > > brick and rebalance on tiered volume
> > > >
> > > > On Mon, Oct 3, 2016 at 12:21 PM, Hari Gowtham <hgowtham@xxxxxxxxxx
> > > <javascript:;>> wrote:
> > > >
> > > > > Hi,
> > > > >
> > > > > The current add and remove brick commands aren't sufficient to
> > > > > support
> > > > > add/remove brick on tiered volumes.So the commands need minor changes
> > > > > like mentioning which tier we are doing the operation on. So in order
> > > > > to specify the tier on which we are performing the changes, I thought
> > > > > of using the following commands for add and remove brick
> > > > >
> > > > > adding brick on tiered volume:
> > > > > gluster volume tier <volname> add-hot-brick/add-cold-brick <brick>
> > > > > ...
> > > > > <force>
> > > > >
> > > > > removing brick on tierd volume:
> > > > > gluster volume tier <volname> remove-hot-brick/remove-cold-brick
> > > <brick>
> > > > > ... <start|stop|status|commit|force>
> > > > >
> > > > > I have framed it this way because once we mention details about
> > > > > tiering
> > > > > these commands become specific to tier and the syntax that we follow
> > > for
> > > > > commands are gluster volume component <VOLNAME> ...
> > > > > So i have made sure that the keyword tier comes after volume.
> > > > > Need suggestions to make these commands better.
> > > > >
> > > > > Similarly once we support add/remove brick we will be having
> > > > > rebalance
> > > > > commands and the idea is to support rebalance separately for each
> > > > > tier.
> > > > > So once we will have to rebalance status to display for which we need
> > > > > rebalance commands specific to tier. so these are the commands we
> > > > > have
> > > > > thought of:
> > > > > gluster v tier <VOLNAME> hot-rebalance/cold-rebalance
> > > <start|stop|status>
> > > > >
> > > > > Need your comments regarding this.
> > > > >
> > > >
> > > > Overall it makes sense. Just a comment here. Instead of mentioning
> > > > remove/add/rebalance-hot/cold-brick can we have an additional arg
> > > > called
> > > > tier-type <hot/cold> and continue with the existing semantics like
> > > > remove-brick, add-brick and rebalance?
> > > >
> > > >
> > > > > --
> > > > > Regards,
> > > > > Hari.
> > > > >
> > > > > _______________________________________________
> > > > > Gluster-devel mailing list
> > > > > Gluster-devel@xxxxxxxxxxx <javascript:;>
> > > > > http://www.gluster.org/mailman/listinfo/gluster-devel
> > > > >
> > > >
> > > >
> > > >
> > > > --
> > > >
> > > > --Atin
> > > >
> > >
> > > --
> > > Regards,
> > > Hari.
> > >
> > >
> >
> > --
> > --Atin
> >
>
> --
> Regards,
> Hari.
>
> _______________________________________________
> Gluster-devel mailing list
> Gluster-devel@xxxxxxxxxxx
> http://www.gluster.org/mailman/listinfo/gluster-devel
>
--
Regards,
Hari.
_______________________________________________
Gluster-devel mailing list
Gluster-devel@xxxxxxxxxxx
http://www.gluster.org/mailman/listinfo/gluster-devel
