[Gluster-devel] New commands for supporting add/remove brick and rebalance on tiered volume
Hari Gowtham
hgowtham at redhat.com
Mon Oct 24 06:29:51 UTC 2016
I forgot to mention that with the first approach we need a separate tier
add brick parser. If we add these changes to the existing add-brick parser,
then the major changes are :
The word count for normal add-brick and tier-add-brick are totally different.
As the word count messes up, we need to put tier-add-brick parsing into a separate
function now itself.
We can support multiple tier even with the second approach. this doesn't need much
changes in parsing. the existing one can be used with minor tweaks. and can be rewritten
any time to separate it from add-brick parsing.
else if (!strcmp(words[3], "add-hot-brick")) {
ret = do_cli_cmd_volume_add_hotbr_tier (state, word,
words, wordcount-1);
goto out;
This is the only part that will need change. We need to add similar
function so that in that function we can set the dict to mention whether its
hot or cold, or in this case the tier-id.
The tier-id wont need a huge change in the cli part as it is already designed similarly
to add hot or cold brick. Based on this dict value we are making changes to the volfile.
Having it as per the second aproach we can add arguments later if a specific function
needs a specific argument.
----- Original Message -----
> From: "Dan Lambright" <dlambrig at redhat.com>
> To: "Hari Gowtham" <hgowtham at redhat.com>
> Cc: "Atin Mukherjee" <amukherj at redhat.com>, "gluster-users" <gluster-users at gluster.org>, "gluster-devel"
> <gluster-devel at gluster.org>
> Sent: Saturday, October 22, 2016 10:57:21 PM
> Subject: Re: [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
> >
>
--
Regards,
Hari.
More information about the Gluster-devel
mailing list