[jira] [Commented] (KUDU-2573) Fully support Chrony in place of NTP
[
https://issues.apache.org/jira/browse/KUDU-2573?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16942402#comment-16942402
]
Alexey Serbin commented on KUDU-2573:
-
This might be useful if trying to run {{chronyd}} as a replacement for
{{ntpd}}. Basically, that's about making {{chronyd}} to behave like {{ntpd}}:
https://chrony.tuxfamily.org/faq.html#_can_code_chronyd_code_be_configured_to_control_the_clock_like_code_ntpd_code
> Fully support Chrony in place of NTP
>
>
> Key: KUDU-2573
> URL: https://issues.apache.org/jira/browse/KUDU-2573
> Project: Kudu
> Issue Type: New Feature
>Reporter: Grant Henke
>Priority: Major
>
> This is to track fully supporting Chrony in place of NTP. Given Chrony is the
> default in RHEL7+, running Kudu with Chrony is likely to be more common.
> The work should entail:
> * identifying and fixing or documenting any differences or gaps
> * removing the experimental warnings from the documentation
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (KUDU-2852) Push predicate evaluation into more CFile decoders
[ https://issues.apache.org/jira/browse/KUDU-2852?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16942365#comment-16942365 ] Andrew Wong commented on KUDU-2852: --- [~abukor] Are you working on this? I'd like to hand it off to [~bankim], if you don't mind. > Push predicate evaluation into more CFile decoders > -- > > Key: KUDU-2852 > URL: https://issues.apache.org/jira/browse/KUDU-2852 > Project: Kudu > Issue Type: Improvement > Components: cfile, perf >Reporter: Andrew Wong >Assignee: Attila Bukor >Priority: Major > Labels: newbie > > Commit c0f3727 added an optimization to push predicate evaluation into the > CFile decoders without fully materializing the contents of each cblock. It > did this with dictionary-encoded blocks, but the optimization can be applied > to any other encoding types too. > A low hanging fruit is RLE decoders, which should be able to evaluate the > predicate for each run instead of materializing each cell and then applying > the predicate. > KUDU-736 also notes that we may be able to apply some predicates on > bitshuffled data. > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (KUDU-1007) Add CreateIfNotExists API for tables
[ https://issues.apache.org/jira/browse/KUDU-1007?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sandish Kumar HN reassigned KUDU-1007: -- Assignee: Sandish Kumar HN > Add CreateIfNotExists API for tables > > > Key: KUDU-1007 > URL: https://issues.apache.org/jira/browse/KUDU-1007 > Project: Kudu > Issue Type: New Feature > Components: client >Affects Versions: Feature Complete >Reporter: Mike Percy >Assignee: Sandish Kumar HN >Priority: Major > Labels: hackathon-feedback, roadmap-candidate > > People want a non-racy API to create tables if needed without having to > handle java exceptions -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (KUDU-2962) Fix kudu::itest::FindTabletFollowers() test utility function
Alexey Serbin created KUDU-2962:
---
Summary: Fix kudu::itest::FindTabletFollowers() test utility
function
Key: KUDU-2962
URL: https://issues.apache.org/jira/browse/KUDU-2962
Project: Kudu
Issue Type: Improvement
Components: test
Reporter: Alexey Serbin
The {{kudu::itest::FindTabletFollowers()}} function is unsafe: it uses
{{kudu::itest::FindTabletLeader()}} to generate the result as a complement to
tablet servers hosting the leader replica, but it doesn't sanitize the set of
tablet servers to make sure it contains only tablet servers hosting replicas of
the specified tablet.
For example, if you have a cluster with 10 tablet servers, and a tablet with 3
tablet replicas, passing the map for all tablet servers in the 10-node cluster
would result in {{FindTabletFollowers()}} reporting 9 followers. Whoops!
It's necessary to either fix the implementation of this utility function to
sanitize its first argument, or simply get rid of it.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (KUDU-2914) Rebalance tool support moving replicas from some specific tablet servers
[ https://issues.apache.org/jira/browse/KUDU-2914?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16941809#comment-16941809 ] YifanZhang edited comment on KUDU-2914 at 10/1/19 1:09 PM: --- Thanks for [~aserbin]'s suggestion, it's very useful. I have two questions. If we let the master replace all replicas at the tablet server, how to know when the whole replacement process ends, do we need to keep checking whether all relicas have been removed? And if it is possible to mark multiple tablet servers as 'decomissioned'? I mean mark two or more replicas of a tablet with the REPLACE attribute. was (Author: zhangyifan27): Thanks for [~aserbin]'s suggestions, it's very useful. I have tow questions. If we let the master replace all replicas at the tablet server, how to know when the whole replacement process ends, do we need to keep checking whether all relicas have been removed? And if it is possible to mark multiple tablet servers as 'decomissioned'? I mean mark two or more replicas of a tablet with the REPLACE attribute. > Rebalance tool support moving replicas from some specific tablet servers > > > Key: KUDU-2914 > URL: https://issues.apache.org/jira/browse/KUDU-2914 > Project: Kudu > Issue Type: Improvement > Components: CLI >Reporter: YifanZhang >Assignee: YifanZhang >Priority: Minor > > When we need to remove some tservers from a kudu cluster (maybe just for > saving resources or replacing these servers with new servers), it's better to > move all replicas on these tservers to other tservers in a cluster in > advance, instead of waiting for all replicas kicked out and evicting new > replicas. This can be achieved by rebalance tool supporting specifying > 'blacklist_tservers'. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (KUDU-2914) Rebalance tool support moving replicas from some specific tablet servers
[ https://issues.apache.org/jira/browse/KUDU-2914?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16941809#comment-16941809 ] YifanZhang commented on KUDU-2914: -- Thanks for [~aserbin]'s suggestions, it's very useful. I have tow questions. If we let the master replace all replicas at the tablet server, how to know when the whole replacement process ends, do we need to keep checking whether all relicas have been removed? And if it is possible to mark multiple tablet servers as 'decomissioned'? I mean mark two or more replicas of a tablet with the REPLACE attribute. > Rebalance tool support moving replicas from some specific tablet servers > > > Key: KUDU-2914 > URL: https://issues.apache.org/jira/browse/KUDU-2914 > Project: Kudu > Issue Type: Improvement > Components: CLI >Reporter: YifanZhang >Assignee: YifanZhang >Priority: Minor > > When we need to remove some tservers from a kudu cluster (maybe just for > saving resources or replacing these servers with new servers), it's better to > move all replicas on these tservers to other tservers in a cluster in > advance, instead of waiting for all replicas kicked out and evicting new > replicas. This can be achieved by rebalance tool supporting specifying > 'blacklist_tservers'. -- This message was sent by Atlassian Jira (v8.3.4#803005)
