Hey Colin,
I added Config#get(String) to the KIP.
Ismael
On Mon, May 8, 2017 at 6:47 PM, Colin McCabe wrote:
>
> Good idea. Should we add a Config#get(String) that can get the value of
> a specific ConfigEntry?
>
Hi Jason,
Thanks for the feedback. I agree that it's useful and reasonably simple to
implement. So, I've updated the KIP.
Ismael
On Wed, May 10, 2017 at 10:48 PM, Jason Gustafson
wrote:
> Hey Ismael,
>
> Thanks for the KIP. The use of the Describe API might be a little limited
> if it always r
Hey Ismael,
Thanks for the KIP. The use of the Describe API might be a little limited
if it always returns the full set of topics for the requested resource. I
wonder if we can let the client provide a list of the configs they are
interested in. Perhaps something like this:
DescribeConfigs Reques
On Sun, May 7, 2017, at 20:18, Ismael Juma wrote:
> Thanks for the feedback Colin. Comments inline.
>
> On Sun, May 7, 2017 at 9:29 PM, Colin McCabe wrote:
> >
> > Hmm. What's the behavior if I try to list the configuration for a topic
> > that doesn't exist? It seems like in this case, the who
I meant, ListConfigs to DescribeConfigs. :)
On Mon, May 8, 2017 at 4:50 PM, Ismael Juma wrote:
> Quick update, I renamed ListAcls to DescribeAcls (and related classes and
> methods) as that is more consistent with other protocols (like ListGroups
> and DescribeGroups).
>
> Ismael
>
> On Mon, May
Quick update, I renamed ListAcls to DescribeAcls (and related classes and
methods) as that is more consistent with other protocols (like ListGroups
and DescribeGroups).
Ismael
On Mon, May 8, 2017 at 2:17 PM, Ismael Juma wrote:
> Hi James,
>
> Yes, we will have a place where we perform validatio
Hi James,
Yes, we will have a place where we perform validation independently of the
policy. This will be quite basic in the initial version, but we can improve
it over time. We will be able to do better than `ConfigCommand` because we
will have access to the broker topic configs. Without access t
The KIP talks about allowing the user to provide a AlterConfigsPolicy. I assume
that even if the user does not provide a custom policy, that there are some
basic validation that the broker will do by default?
The reason I'm asking is I'm thinking ahead to
https://issues.apache.org/jira/browse/K
Thanks for the feedback Colin. Comments inline.
On Sun, May 7, 2017 at 9:29 PM, Colin McCabe wrote:
>
> Hmm. What's the behavior if I try to list the configuration for a topic
> that doesn't exist? It seems like in this case, the whole request has
> to return an error, and nothing gets listed.
On Fri, May 5, 2017, at 19:24, Ismael Juma wrote:
> Hi Colin,
>
> Thanks for the review. Comments inline.
>
> On Fri, May 5, 2017 at 9:45 PM, Colin McCabe wrote:
>
> > As Jun commented, it's probably more consistent to use
> > Collection, unless this really needs to be an ordered
> > list. Tha
Hi James,
On Sun, May 7, 2017 at 8:36 AM, James Cheng wrote:
> Makes sense, and I don't have any concerns about it. Actually, I'm excited
> for the capability. That means you can completely tell how a topic is
> configured, without needing to have any knowledge of how the broker is
> configured.
> On May 6, 2017, at 11:27 AM, Ismael Juma wrote:
>
> Hi James,
>
> Yes, that's right, it will return all config values. For topic configs,
> that means falling back to the respective broker config value, which could
> also be a default. If we fallback to the broker config (whether it's a
> def
Hi James,
Yes, that's right, it will return all config values. For topic configs,
that means falling back to the respective broker config value, which could
also be a default. If we fallback to the broker config (whether it's a
default or not), is_default will be true. Does this make sense? And do
Hi Ismael,
Thanks for the KIP.
I see that in the ListConfigs Response protocol, that configs have an
is_default field. Does that mean that it will include *all* config values,
instead of just overridden ones?
As an example, kafka-config.sh --describe on a topic will, right now, only show
over
Hi Colin,
Thanks for the review. Comments inline.
On Fri, May 5, 2017 at 9:45 PM, Colin McCabe wrote:
> As Jun commented, it's probably more consistent to use
> Collection, unless this really needs to be an ordered
> list. That way people can use any container they want.
>
Agreed, updated the
Hi Jun,
Thanks for the review.
1. Yes, a Set would work too. I updated to take Collection for consistency
as Colin said.
2. That was a typo, it should have been a boolean indicating whether we
should only perform validation. Updated the KIP.
Thanks,
Ismael
On Fri, May 5, 2017 at 6:35 PM, Jun Ra
Hi Ismael,
Thanks for the KIP. This will be a great improvement.
> public class AdminClient {
>public ListConfigsResult listConfigs(List entities,
> ListConfigsOptions options);
>public AlterConfigsResult alterConfigs(Map>
> configs,
>
Hi, Ismael,
Thanks for the KIP. Looks good overall. Just a couple of minor comments.
1. Should AdminClient.listConfigs() take a set of ConfigEntity instead of a
list?
2. validateOnly(boolean timeout): Should the time be Integer?
Jun
On Thu, May 4, 2017 at 7:32 PM, Ismael Juma wrote:
> Hi al
Hi all,
We've posted "KIP-133: List and Alter Configs Admin APIs" for discussion:
https://cwiki.apache.org/confluence/display/KAFKA/KIP-133%3A+List+and+Alter+Configs+Admin+APIs
This completes the first batch of AdminClient APIs so that topic, config
and ACL management is supported.
Please take
19 matches
Mail list logo
