----- Original Message -----
> From: "Hari Gowtham" <hgowtham@xxxxxxxxxx>
> To: "Atin Mukherjee" <amukherj@xxxxxxxxxx>
> Cc: "gluster-users" <gluster-users@xxxxxxxxxxx>, "gluster-devel" <gluster-devel@xxxxxxxxxxx>
> 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@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: [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@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: [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@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: [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@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
>
_______________________________________________
Gluster-users mailing list
Gluster-users@xxxxxxxxxxx
http://www.gluster.org/mailman/listinfo/gluster-users
