accumulo-notifications mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Christopher Tubbs (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (ACCUMULO-3089) Create a volume chooser that makes decisions based on table attributes
Date Fri, 26 Sep 2014 19:04:34 GMT

    [ https://issues.apache.org/jira/browse/ACCUMULO-3089?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14149810#comment-14149810
] 

Christopher Tubbs commented on ACCUMULO-3089:
---------------------------------------------

[~busbey] wrote:

bq. Just as a simple example, limiting volumes to particular namespaces would not require
changing when table properties are available. It would also not require changing the table
creation api.

Oh, I see. Yes, absolutely, that would be a simpler example. Certainly, that could be done,
but I don't see how useful it would be. Without any environment, the only choosers possible
are ones that have hard-coded decisions, which would have to be recompiled when the policy
changes, or who rely on external/remote services for configuration. (This is true of the namespace
example, for instance... because there is no way for the chooser to know which namespace it
is making a decision for.) None of our other pluggable components have such limitations, and
we've made it possible to configure each through environment (usually table properties, as
in the case of iterators, constraints, etc.), so I don't see why this addition should be vetoed
here.

So, yes, that's a simpler example... but it's not an example which satisfies the criteria
of this ticket, because this ticket is essentially about creating an example which can make
smarter decisions, based on configuration.

Is "there could be another implementation/example" your only remaining basis for your veto,
or is there something inherently wrong with the idea of giving environment/configuration to
the chooser?

Also, how do you feel about the sub-tasks, the per-table volume chooser (similar to the per-table
balancer), or the example preferred volume chooser? Does breaking it up like that help frame,
change, or address your concerns in any way? To which of those two would your veto apply,
or would it be for both?

bq. For the record, my veto is not based on a misunderstanding.

That seems to express a degree of confidence in one's understanding the other side of the
conversation that I do not believe anybody could ever have. There is *always* a risk you've
misunderstood somebody else's intentions (in this case, my intentions for this ticket I created).
I understand this statement to mean that you do not believe you've misunderstood the intentions.

> Create a volume chooser that makes decisions based on table attributes
> ----------------------------------------------------------------------
>
>                 Key: ACCUMULO-3089
>                 URL: https://issues.apache.org/jira/browse/ACCUMULO-3089
>             Project: Accumulo
>          Issue Type: Improvement
>            Reporter: Christopher Tubbs
>            Assignee: Jenna Huston
>
> Use case:
> User provisions multiple volumes, some with tmpfs drives, some with SSDs, some with traditional
magnetic spindle hard drives. A volume chooser could use attribute information on tables (ACCUMULO-2841)
to decide which volume to choose when creating new tablets.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message