Hari Gowtham
2016-Oct-21 07:52 UTC
[Gluster-users] [Gluster-devel] New commands for supporting add/remove brick and rebalance on tiered volume
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 at redhat.com>
> To: "Atin Mukherjee" <amukherj at redhat.com>
> Cc: "gluster-users" <gluster-users at gluster.org>,
"gluster-devel" <gluster-devel at gluster.org>
> Sent: Monday, October 3, 2016 4:11:40 PM
> Subject: Re: [Gluster-devel] 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 at redhat.com>
> > To: "Hari Gowtham" <hgowtham at redhat.com>
> > Cc: "gluster-devel" <gluster-devel at gluster.org>,
"gluster-users"
> > <gluster-users at gluster.org>
> > Sent: Monday, October 3, 2016 4:02:42 PM
> > Subject: Re: [Gluster-devel] 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 at redhat.com>
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 at redhat.com
<javascript:;>>
> > > > To: "Hari Gowtham" <hgowtham at redhat.com
<javascript:;>>
> > > > Cc: "gluster-devel" <gluster-devel at
gluster.org <javascript:;>>,
> > > "gluster-users" <gluster-users at gluster.org
<javascript:;>>
> > > > Sent: Monday, October 3, 2016 2:31:40 PM
> > > > Subject: Re: [Gluster-devel] New commands for supporting
add/remove
> > > brick and rebalance on tiered volume
> > > >
> > > > On Mon, Oct 3, 2016 at 12:21 PM, Hari Gowtham <hgowtham
at redhat.com
> > > <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 at gluster.org <javascript:;>
> > > > > http://www.gluster.org/mailman/listinfo/gluster-devel
> > > > >
> > > >
> > > >
> > > >
> > > > --
> > > >
> > > > --Atin
> > > >
> > >
> > > --
> > > Regards,
> > > Hari.
> > >
> > >
> >
> > --
> > --Atin
> >
>
> --
> Regards,
> Hari.
>
> _______________________________________________
> Gluster-devel mailing list
> Gluster-devel at gluster.org
> http://www.gluster.org/mailman/listinfo/gluster-devel
>
--
Regards,
Hari.
Dan Lambright
2016-Oct-22 17:27 UTC
[Gluster-users] [Gluster-devel] New commands for supporting add/remove brick and rebalance on tiered volume
----- Original Message -----> From: "Hari Gowtham" <hgowtham at redhat.com> > To: "Atin Mukherjee" <amukherj at redhat.com> > Cc: "gluster-users" <gluster-users at gluster.org>, "gluster-devel" <gluster-devel at gluster.org> > Sent: Friday, October 21, 2016 3:52:34 AM > Subject: Re: [Gluster-devel] New commands for supporting add/remove brick and rebalance on tiered volume > > 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.We might someday have more tiering "types" than "hot and cold". We may have an "archive" tier, for example, or time-based rather than automated, secure/unsecure, etc. We should not assume there is only one hot/cold tier. Someday there could be multiple hot/cold tiers, as in "vol1" below. How to distinguish them? Number each tier according to the leaf's position in the graph, and calling this the "tier-id" would be sensible. Option (1) seems a closer fit to that (we would change "tier-type" to "tier-id"). I'm not sure we are ready to make the jump to "tier-id" rather than "tier-type", thats a different discussion. Overall, I prefer option (1), it seems to more easily keep future options open. vol1 - unsecure --- hot T1 --- cold T2 - secure --- nearline ------ hot T3 ------ cold T4 --- archive T5 vol1 -- hot T1 -- cold T2> > ----- Original Message ----- > > From: "Hari Gowtham" <hgowtham at redhat.com> > > To: "Atin Mukherjee" <amukherj at redhat.com> > > Cc: "gluster-users" <gluster-users at gluster.org>, "gluster-devel" > > <gluster-devel at gluster.org> > > Sent: Monday, October 3, 2016 4:11:40 PM > > Subject: Re: [Gluster-devel] 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 at redhat.com> > > > To: "Hari Gowtham" <hgowtham at redhat.com> > > > Cc: "gluster-devel" <gluster-devel at gluster.org>, "gluster-users" > > > <gluster-users at gluster.org> > > > Sent: Monday, October 3, 2016 4:02:42 PM > > > Subject: Re: [Gluster-devel] 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 at redhat.com> 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 at redhat.com <javascript:;>> > > > > > To: "Hari Gowtham" <hgowtham at redhat.com <javascript:;>> > > > > > Cc: "gluster-devel" <gluster-devel at gluster.org <javascript:;>>, > > > > "gluster-users" <gluster-users at gluster.org <javascript:;>> > > > > > Sent: Monday, October 3, 2016 2:31:40 PM > > > > > Subject: Re: [Gluster-devel] New commands for supporting add/remove > > > > brick and rebalance on tiered volume > > > > > > > > > > On Mon, Oct 3, 2016 at 12:21 PM, Hari Gowtham <hgowtham at redhat.com > > > > <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 at gluster.org <javascript:;> > > > > > > http://www.gluster.org/mailman/listinfo/gluster-devel > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > > > --Atin > > > > > > > > > > > > > -- > > > > Regards, > > > > Hari. > > > > > > > > > > > > > > -- > > > --Atin > > > > > > > -- > > Regards, > > Hari. > > > > _______________________________________________ > > Gluster-devel mailing list > > Gluster-devel at gluster.org > > http://www.gluster.org/mailman/listinfo/gluster-devel > > > > -- > Regards, > Hari. > > _______________________________________________ > Gluster-devel mailing list > Gluster-devel at gluster.org > http://www.gluster.org/mailman/listinfo/gluster-devel >