From jakub at scholz.cz Fri Apr 13 02:31:46 2018 From: jakub at scholz.cz (Jakub Scholz) Date: Thu, 12 Apr 2018 22:31:46 -0400 Subject: [Strimzi] RC1 of Strimzi 0.3.0 available Message-ID: Hi, The Release Candidate 1 for the first Strimzi 0.3.0 is now available. If you are interested have a look at the release candidate and give us your feedback: https://github.com/strimzi/strimzi/releases/tag/0.3.0-rc1 Thanks & Regards Jakub -------------- next part -------------- An HTML attachment was scrubbed... URL: From Przemyslaw.Budzik at sabre.com Fri Apr 13 05:10:57 2018 From: Przemyslaw.Budzik at sabre.com (Budzik, Przemyslaw) Date: Fri, 13 Apr 2018 05:10:57 +0000 Subject: [Strimzi] RC1 of Strimzi 0.3.0 available In-Reply-To: References: Message-ID: Jakub, Which version would you recommend using in our case ? One of the teams is now installing Strimzi in our DEV environment. Thanks, Przemek From: strimzi-bounces at redhat.com [mailto:strimzi-bounces at redhat.com] On Behalf Of Jakub Scholz Sent: Friday, April 13, 2018 4:32 AM To: strimzi at redhat.com Subject: [Strimzi] RC1 of Strimzi 0.3.0 available Hi, The Release Candidate 1 for the first Strimzi 0.3.0 is now available. If you are interested have a look at the release candidate and give us your feedback: https://github.com/strimzi/strimzi/releases/tag/0.3.0-rc1 Thanks & Regards Jakub -------------- next part -------------- An HTML attachment was scrubbed... URL: From jakub at scholz.cz Fri Apr 13 12:44:27 2018 From: jakub at scholz.cz (Jakub Scholz) Date: Fri, 13 Apr 2018 08:44:27 -0400 Subject: [Strimzi] RC1 of Strimzi 0.3.0 available In-Reply-To: References: Message-ID: Hi, Well, it is a release candidate. So while I hope that there will be no issues, there is always possibility. But feel free to give it a try. It doesn't bring any significant new features, but it improves a bit the resilience with which the controller reacts to different problems and situations. If you didn't experienced any issues with 0.2.0, you can just stay with it. I hope the final release will be done early next week. Thanks & Regards Jakub On Fri, Apr 13, 2018 at 1:10 AM, Budzik, Przemyslaw < Przemyslaw.Budzik at sabre.com> wrote: > Jakub, > > > > Which version would you recommend using in our case ? One of the teams is > now installing Strimzi in our DEV environment. > > > > Thanks, > > Przemek > > > > *From:* strimzi-bounces at redhat.com [mailto:strimzi-bounces at redhat.com] *On > Behalf Of *Jakub Scholz > *Sent:* Friday, April 13, 2018 4:32 AM > *To:* strimzi at redhat.com > *Subject:* [Strimzi] RC1 of Strimzi 0.3.0 available > > > > Hi, > > > > The Release Candidate 1 for the first Strimzi 0.3.0 is now available. > > > > If you are interested have a look at the release candidate and give us > your feedback: > > https://github.com/strimzi/strimzi/releases/tag/0.3.0-rc1 > > > > Thanks & Regards > > Jakub > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Przemyslaw.Budzik at sabre.com Mon Apr 16 08:24:12 2018 From: Przemyslaw.Budzik at sabre.com (Budzik, Przemyslaw) Date: Mon, 16 Apr 2018 08:24:12 +0000 Subject: [Strimzi] RC1 of Strimzi 0.3.0 available In-Reply-To: References: Message-ID: Thank you Jakub. I have a question. Is there any way to bind namespace with topic in terms of authorization? Consider a scenario. 1. Team A creates a topic called ?reservations?. They own the config map and of course they can publish to this topic. 2. Team B is interested in consuming A?s messages. I am guessing if they know the name of the topic, they can use it ? Ideally since they are in the namespace B, we?d like to be able to say they can, but others can?t. Also I mean we give them read, but not write. Most likely it?s the creator of topic writing and other namespaces (or the same) consuming. If that is not supported, is that on your roadmap ? From: Jakub Scholz [mailto:jakub at scholz.cz] Sent: Friday, April 13, 2018 2:44 PM To: Budzik, Przemyslaw Cc: strimzi at redhat.com; Chylek, Artur ; Wnuk, Norbert Subject: Re: [Strimzi] RC1 of Strimzi 0.3.0 available Hi, Well, it is a release candidate. So while I hope that there will be no issues, there is always possibility. But feel free to give it a try. It doesn't bring any significant new features, but it improves a bit the resilience with which the controller reacts to different problems and situations. If you didn't experienced any issues with 0.2.0, you can just stay with it. I hope the final release will be done early next week. Thanks & Regards Jakub On Fri, Apr 13, 2018 at 1:10 AM, Budzik, Przemyslaw > wrote: Jakub, Which version would you recommend using in our case ? One of the teams is now installing Strimzi in our DEV environment. Thanks, Przemek From: strimzi-bounces at redhat.com [mailto:strimzi-bounces at redhat.com] On Behalf Of Jakub Scholz Sent: Friday, April 13, 2018 4:32 AM To: strimzi at redhat.com Subject: [Strimzi] RC1 of Strimzi 0.3.0 available Hi, The Release Candidate 1 for the first Strimzi 0.3.0 is now available. If you are interested have a look at the release candidate and give us your feedback: https://github.com/strimzi/strimzi/releases/tag/0.3.0-rc1 Thanks & Regards Jakub -------------- next part -------------- An HTML attachment was scrubbed... URL: From ppatiern at redhat.com Mon Apr 16 14:56:01 2018 From: ppatiern at redhat.com (Paolo Patierno) Date: Mon, 16 Apr 2018 16:56:01 +0200 Subject: [Strimzi] RC1 of Strimzi 0.3.0 available In-Reply-To: References: Message-ID: Hi, I kicked the tires to the release a little bit, I didn't find any major issues using it. I tried with different actions for testing the CC resiliency and if we are able to exchange messages between clients inside the cluster now that we are using the DNS names (from headless services) for advertising listeners. +1 from me. Thanks, Paolo. On Fri, Apr 13, 2018 at 4:31 AM, Jakub Scholz wrote: > Hi, > > The Release Candidate 1 for the first Strimzi 0.3.0 is now available. > > If you are interested have a look at the release candidate and give us > your feedback: > https://github.com/strimzi/strimzi/releases/tag/0.3.0-rc1 > > Thanks & Regards > Jakub > > _______________________________________________ > Strimzi mailing list > Strimzi at redhat.com > https://www.redhat.com/mailman/listinfo/strimzi > > -- PAOLO PATIERNO PRINCIPAL SOFTWARE ENGINEER, MESSAGING & IOT Red Hat -------------- next part -------------- An HTML attachment was scrubbed... URL: From jakub at scholz.cz Tue Apr 17 11:52:26 2018 From: jakub at scholz.cz (Jakub Scholz) Date: Tue, 17 Apr 2018 13:52:26 +0200 Subject: [Strimzi] RC2 of Strimzi 0.3.0 available Message-ID: Hi, RC2 fixes the following problems from RC1: - Constant rolling update of Kafka and Zookeeper with persistent storage on Kubernetes (PR #384 ). - Inconsistencies when user attempts to change the storage type for running cluster (PR #386 ) If you are interested have a look at the release candidate and give us your feedback: https://github.com/strimzi/strimzi/releases/tag/0.3.0-rc2 Thanks & Regards Jakub -------------- next part -------------- An HTML attachment was scrubbed... URL: From jakub at scholz.cz Tue Apr 17 16:42:26 2018 From: jakub at scholz.cz (Jakub Scholz) Date: Tue, 17 Apr 2018 18:42:26 +0200 Subject: [Strimzi] RC1 of Strimzi 0.3.0 available In-Reply-To: References: Message-ID: One of the problems is that the config map is a namespaced resource. But if you want a Kafka cluster which serves multiple namespaces then Kafka topic is not namespaced resource. That means a lot of complications. For example what should we do when the same topic is configured within different namespaces? So I do not think we can see the presence of the config map for given topic in the namespace as a proof of ownership for the topic. I think that the general idea is quite good. But the implementation might not be trivial. I think I will need some more time to think about it. Either way this is far beyond the 0.3.0 scope. Thanks Jakub On Mon, Apr 16, 2018 at 10:24 AM, Budzik, Przemyslaw < Przemyslaw.Budzik at sabre.com> wrote: > Thank you Jakub. I have a question. Is there any way to bind namespace > with topic in terms of authorization? Consider a scenario. > > > > 1. Team A creates a topic called ?reservations?. They own the config > map and of course they can publish to this topic. > 2. Team B is interested in consuming A?s messages. I am guessing if > they know the name of the topic, they can use it ? Ideally since they are > in the namespace B, we?d like to be able to say they can, but others > can?t. Also I mean we give them read, but not write. Most likely it?s the > creator of topic writing and other namespaces (or the same) consuming. > > > > If that is not supported, is that on your roadmap ? > > > > *From:* Jakub Scholz [mailto:jakub at scholz.cz] > *Sent:* Friday, April 13, 2018 2:44 PM > *To:* Budzik, Przemyslaw > *Cc:* strimzi at redhat.com; Chylek, Artur ; Wnuk, > Norbert > *Subject:* Re: [Strimzi] RC1 of Strimzi 0.3.0 available > > > > Hi, > > > > Well, it is a release candidate. So while I hope that there will be no > issues, there is always possibility. But feel free to give it a try. It > doesn't bring any significant new features, but it improves a bit the > resilience with which the controller reacts to different problems and > situations. If you didn't experienced any issues with 0.2.0, you can just > stay with it. > > > > I hope the final release will be done early next week. > > > > Thanks & Regards > > Jakub > > > > On Fri, Apr 13, 2018 at 1:10 AM, Budzik, Przemyslaw < > Przemyslaw.Budzik at sabre.com> wrote: > > Jakub, > > > > Which version would you recommend using in our case ? One of the teams is > now installing Strimzi in our DEV environment. > > > > Thanks, > > Przemek > > > > *From:* strimzi-bounces at redhat.com [mailto:strimzi-bounces at redhat.com] *On > Behalf Of *Jakub Scholz > *Sent:* Friday, April 13, 2018 4:32 AM > *To:* strimzi at redhat.com > *Subject:* [Strimzi] RC1 of Strimzi 0.3.0 available > > > > Hi, > > > > The Release Candidate 1 for the first Strimzi 0.3.0 is now available. > > > > If you are interested have a look at the release candidate and give us > your feedback: > > https://github.com/strimzi/strimzi/releases/tag/0.3.0-rc1 > > > > Thanks & Regards > > Jakub > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Przemyslaw.Budzik at sabre.com Wed Apr 18 06:23:38 2018 From: Przemyslaw.Budzik at sabre.com (Budzik, Przemyslaw) Date: Wed, 18 Apr 2018 06:23:38 +0000 Subject: [Strimzi] RC1 of Strimzi 0.3.0 available In-Reply-To: References: Message-ID: What you wrote makes me think that we should create topic configmaps in Strimzi cluster namespace then. It could be an APB creating that. Stll I don?t know how to implement topic authorization. Which method would you recommend? From: Jakub Scholz [mailto:jakub at scholz.cz] Sent: Tuesday, April 17, 2018 6:42 PM To: Budzik, Przemyslaw Cc: strimzi at redhat.com; Chylek, Artur ; Wnuk, Norbert Subject: Re: [Strimzi] RC1 of Strimzi 0.3.0 available One of the problems is that the config map is a namespaced resource. But if you want a Kafka cluster which serves multiple namespaces then Kafka topic is not namespaced resource. That means a lot of complications. For example what should we do when the same topic is configured within different namespaces? So I do not think we can see the presence of the config map for given topic in the namespace as a proof of ownership for the topic. I think that the general idea is quite good. But the implementation might not be trivial. I think I will need some more time to think about it. Either way this is far beyond the 0.3.0 scope. Thanks Jakub On Mon, Apr 16, 2018 at 10:24 AM, Budzik, Przemyslaw > wrote: Thank you Jakub. I have a question. Is there any way to bind namespace with topic in terms of authorization? Consider a scenario. 1. Team A creates a topic called ?reservations?. They own the config map and of course they can publish to this topic. 2. Team B is interested in consuming A?s messages. I am guessing if they know the name of the topic, they can use it ? Ideally since they are in the namespace B, we?d like to be able to say they can, but others can?t. Also I mean we give them read, but not write. Most likely it?s the creator of topic writing and other namespaces (or the same) consuming. If that is not supported, is that on your roadmap ? From: Jakub Scholz [mailto:jakub at scholz.cz] Sent: Friday, April 13, 2018 2:44 PM To: Budzik, Przemyslaw > Cc: strimzi at redhat.com; Chylek, Artur >; Wnuk, Norbert > Subject: Re: [Strimzi] RC1 of Strimzi 0.3.0 available Hi, Well, it is a release candidate. So while I hope that there will be no issues, there is always possibility. But feel free to give it a try. It doesn't bring any significant new features, but it improves a bit the resilience with which the controller reacts to different problems and situations. If you didn't experienced any issues with 0.2.0, you can just stay with it. I hope the final release will be done early next week. Thanks & Regards Jakub On Fri, Apr 13, 2018 at 1:10 AM, Budzik, Przemyslaw > wrote: Jakub, Which version would you recommend using in our case ? One of the teams is now installing Strimzi in our DEV environment. Thanks, Przemek From: strimzi-bounces at redhat.com [mailto:strimzi-bounces at redhat.com] On Behalf Of Jakub Scholz Sent: Friday, April 13, 2018 4:32 AM To: strimzi at redhat.com Subject: [Strimzi] RC1 of Strimzi 0.3.0 available Hi, The Release Candidate 1 for the first Strimzi 0.3.0 is now available. If you are interested have a look at the release candidate and give us your feedback: https://github.com/strimzi/strimzi/releases/tag/0.3.0-rc1 Thanks & Regards Jakub -------------- next part -------------- An HTML attachment was scrubbed... URL: From jakub at scholz.cz Wed Apr 18 10:16:52 2018 From: jakub at scholz.cz (Jakub Scholz) Date: Wed, 18 Apr 2018 12:16:52 +0200 Subject: [Strimzi] [Release] Strimzi 0.3.0 Message-ID: Strimzi 0.3.0 is now available. Main changes since 0.2.0: - Improved Cluster controller resiliency - DNS names used for advertised listeners - Improved test coverage - Improved documentation - Configuring default Docker images in Cluster Controller For more details go to http://strimzi.io/ and/or https://github.com/ strimzi/strimzi/releases/tag/0.3.0 Thanks to everyone who help with this release. Jakub -------------- next part -------------- An HTML attachment was scrubbed... URL: From jakub at scholz.cz Wed Apr 18 10:18:11 2018 From: jakub at scholz.cz (Jakub Scholz) Date: Wed, 18 Apr 2018 12:18:11 +0200 Subject: [Strimzi] [Release] Strimzi 0.3.0 In-Reply-To: References: Message-ID: Hmm, the link was still pointing to the 0.2.0 release. Here is the correct link: https://github.com/strimzi/strimzi/releases/tag/0.3.0 Sorry Jakub On Wed, Apr 18, 2018 at 12:16 PM, Jakub Scholz wrote: > Strimzi 0.3.0 is now available. Main changes since 0.2.0: > - Improved Cluster controller resiliency > - DNS names used for advertised listeners > - Improved test coverage > - Improved documentation > - Configuring default Docker images in Cluster Controller > > For more details go to http://strimzi.io/ and/or h > ttps://github.com/strimzi/strimzi/releases/tag/0.3.0 > > > Thanks to everyone who help with this release. > > Jakub > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Przemyslaw.Budzik at sabre.com Mon Apr 30 10:24:09 2018 From: Przemyslaw.Budzik at sabre.com (Budzik, Przemyslaw) Date: Mon, 30 Apr 2018 10:24:09 +0000 Subject: [Strimzi] RC1 of Strimzi 0.3.0 available In-Reply-To: References: Message-ID: Jakub, We are trying to install Strmzi in our DEV cluster. The thing is that there are certain restrictions and we?ve come across a problem: $ oc create -f 02-role.yaml Error from server (Forbidden): error when creating "02-role.yaml": roles.rbac.authorization.k8s.io "strimzi-cluster-controller-role" is forbidden: attempt to grant extra privileges: [PolicyRule{Resources:["events"], APIGroups:[""], Verbs:["create"]} PolicyRule{Resources:["replicationcontrollers"], APIGroups:["extensions"], Verbs:["get"]} PolicyRule{Resources:["replicationcontrollers"], APIGroups:["extensions"], Verbs:["list"]} PolicyRule{Resources:["replicationcontrollers"], APIGroups:["extensions"], Verbs:["watch"]} PolicyRule{Resources:["replicationcontrollers"], APIGroups:["extensions"], Verbs:["create"]} PolicyRule{Resources:["replicationcontrollers"], APIGroups:["extensions"], Verbs:["delete"]} PolicyRule{Resources:["replicationcontrollers"], APIGroups:["extensions"], Verbs:["patch"]} PolicyRule{Resources:["replicationcontrollers"], APIGroups:["extensions"], Verbs:["update"]} PolicyRule{Resources:["deploymentconfigs/status"], APIGroups:["apps.openshift.io"], Verbs:["create"]} PolicyRule{Resources:["deploymentconfigs/status"], APIGroups:["apps.openshift.io"], Verbs:["delete"]} PolicyRule{Resources:["deploymentconfigs/status"], APIGroups:["apps.openshift.io"], Verbs:["patch"]} PolicyRule{Resources:["deploymentconfigs/status"], APIGroups:["apps.openshift.io"], Verbs:["update"]} PolicyRule{Resources:["deploymentconfigs/finalizers"], APIGroups:["apps.openshift.io"], Verbs:["get"]} PolicyRule{Resources:["deploymentconfigs/finalizers"], APIGroups:["apps.openshift.io"], Verbs:["list"]} PolicyRule{Resources:["deploymentconfigs/finalizers"], APIGroups:["apps.openshift.io"], Verbs:["watch"]} PolicyRule{Resources:["deploymentconfigs/finalizers"], APIGroups:["apps.openshift.io"], Verbs:["create"]} PolicyRule{Resources:["deploymentconfigs/finalizers"], APIGroups:["apps.openshift.io"], Verbs:["delete"]} PolicyRule{Resources:["deploymentconfigs/finalizers"], APIGroups:["apps.openshift.io"], Verbs:["patch"]} PolicyRule{Resources:["deploymentconfigs/finalizers"], APIGroups:["apps.openshift.io"], Verbs:["update"]} PolicyRule{Resources:["imagestreams/status"], APIGroups:["image.openshift.io"], Verbs:["create"]} PolicyRule{Resources:["imagestreams/status"], APIGroups:["image.openshift.io"], Verbs:["delete"]} PolicyRule{Resources:["imagestreams/status"], APIGroups:["image.openshift.io"], Verbs:["patch"]} PolicyRule{Resources:["imagestreams/status"], APIGroups:["image.openshift.io"], Verbs:["update"]}] user=&{SG0556477 ? What we are wondering is if all permissions (https://github.com/strimzi/strimzi/blob/master/examples/install/cluster-controller/02-role.yaml) are required? For example we don?t need to install Strimzi in other namespaces. We want to start with only operating within one namespace. Do you think we may reduce permissions (which?) and hence solve the issue (temporarily until our admins give us cluster admin role). Also, we observed that after installing Strimzi, there is one ZK pod. Should it not be more e.g. 3 for HA ? What topology would you recommend for a start (3+3 ? ) Piotr, Krzysztof ? please add if needed. Przemek From: Jakub Scholz [mailto:jakub at scholz.cz] Sent: Tuesday, April 17, 2018 6:42 PM To: Budzik, Przemyslaw Cc: strimzi at redhat.com; Chylek, Artur ; Wnuk, Norbert Subject: Re: [Strimzi] RC1 of Strimzi 0.3.0 available One of the problems is that the config map is a namespaced resource. But if you want a Kafka cluster which serves multiple namespaces then Kafka topic is not namespaced resource. That means a lot of complications. For example what should we do when the same topic is configured within different namespaces? So I do not think we can see the presence of the config map for given topic in the namespace as a proof of ownership for the topic. I think that the general idea is quite good. But the implementation might not be trivial. I think I will need some more time to think about it. Either way this is far beyond the 0.3.0 scope. Thanks Jakub On Mon, Apr 16, 2018 at 10:24 AM, Budzik, Przemyslaw > wrote: Thank you Jakub. I have a question. Is there any way to bind namespace with topic in terms of authorization? Consider a scenario. 1. Team A creates a topic called ?reservations?. They own the config map and of course they can publish to this topic. 2. Team B is interested in consuming A?s messages. I am guessing if they know the name of the topic, they can use it ? Ideally since they are in the namespace B, we?d like to be able to say they can, but others can?t. Also I mean we give them read, but not write. Most likely it?s the creator of topic writing and other namespaces (or the same) consuming. If that is not supported, is that on your roadmap ? From: Jakub Scholz [mailto:jakub at scholz.cz] Sent: Friday, April 13, 2018 2:44 PM To: Budzik, Przemyslaw > Cc: strimzi at redhat.com; Chylek, Artur >; Wnuk, Norbert > Subject: Re: [Strimzi] RC1 of Strimzi 0.3.0 available Hi, Well, it is a release candidate. So while I hope that there will be no issues, there is always possibility. But feel free to give it a try. It doesn't bring any significant new features, but it improves a bit the resilience with which the controller reacts to different problems and situations. If you didn't experienced any issues with 0.2.0, you can just stay with it. I hope the final release will be done early next week. Thanks & Regards Jakub On Fri, Apr 13, 2018 at 1:10 AM, Budzik, Przemyslaw > wrote: Jakub, Which version would you recommend using in our case ? One of the teams is now installing Strimzi in our DEV environment. Thanks, Przemek From: strimzi-bounces at redhat.com [mailto:strimzi-bounces at redhat.com] On Behalf Of Jakub Scholz Sent: Friday, April 13, 2018 4:32 AM To: strimzi at redhat.com Subject: [Strimzi] RC1 of Strimzi 0.3.0 available Hi, The Release Candidate 1 for the first Strimzi 0.3.0 is now available. If you are interested have a look at the release candidate and give us your feedback: https://github.com/strimzi/strimzi/releases/tag/0.3.0-rc1 Thanks & Regards Jakub -------------- next part -------------- An HTML attachment was scrubbed... URL: From jakub at scholz.cz Mon Apr 30 10:44:23 2018 From: jakub at scholz.cz (Jakub Scholz) Date: Mon, 30 Apr 2018 12:44:23 +0200 Subject: [Strimzi] RC1 of Strimzi 0.3.0 available In-Reply-To: References: Message-ID: Hi Przemek, The permissions in this role are all needed by Strimzi. They are not cluster wide, but on OpenShift you need cluster admin to create the role. As an alternative, you can use the existing role "edit" which should already exist in your cluster. To do that, just ignore the 02-role.yaml file and modify the 03-binding.yaml file. In this file, replace the reference to the role "strimzi-cluster-controller-role" with the role named "edit" and create the binding. That should give Strimzi and its service account all the permissions it needs. As for the number of ZK nodes - in the examples folder we have two config maps. The config map kafka-ephemeral.yaml is using non-persisitent emptyDir storage and is more or less supposed to be used for development ad testing purposes. It has by default only 1 ZK node. You can always modify the ConfigMap to add more ZK nodes - normally you should use odd number of ZK nodes, so increasing it to 3 or 5 would be reasonable. There is another ConfigMap in the examples folder - kafka-persistent.yaml . This one is using persistent volumes and has by default 3 Zookeeper nodes. But again, even here you can modify it according to your needs. Thanks & Regards Jakub On Mon, Apr 30, 2018 at 12:24 PM, Budzik, Przemyslaw < Przemyslaw.Budzik at sabre.com> wrote: > Jakub, > > > > We are trying to install Strmzi in our DEV cluster. The thing is that > there are certain restrictions and we?ve come across a problem: > > > > $ oc create -f 02-role.yaml > > Error from server (Forbidden): error when creating "02-role.yaml": > roles.rbac.authorization.k8s.io "strimzi-cluster-controller-role" is > forbidden: attempt to grant extra privileges: [PolicyRule{Resources:["events"], > APIGroups:[""], Verbs:["create"]} PolicyRule{Resources:["replicationcontrollers"], > APIGroups:["extensions"], Verbs:["get"]} PolicyRule{Resources:["replicationcontrollers"], > APIGroups:["extensions"], Verbs:["list"]} PolicyRule{Resources:["replicationcontrollers"], > APIGroups:["extensions"], Verbs:["watch"]} PolicyRule{Resources:["replicationcontrollers"], > APIGroups:["extensions"], Verbs:["create"]} PolicyRule{Resources:["replicationcontrollers"], > APIGroups:["extensions"], Verbs:["delete"]} PolicyRule{Resources:["replicationcontrollers"], > APIGroups:["extensions"], Verbs:["patch"]} PolicyRule{Resources:["replicationcontrollers"], > APIGroups:["extensions"], Verbs:["update"]} PolicyRule{Resources:["deploymentconfigs/status"], > APIGroups:["apps.openshift.io"], Verbs:["create"]} PolicyRule{Resources:["deploymentconfigs/status"], > APIGroups:["apps.openshift.io"], Verbs:["delete"]} PolicyRule{Resources:["deploymentconfigs/status"], > APIGroups:["apps.openshift.io"], Verbs:["patch"]} PolicyRule{Resources:["deploymentconfigs/status"], > APIGroups:["apps.openshift.io"], Verbs:["update"]} PolicyRule{Resources:[" > deploymentconfigs/finalizers"], APIGroups:["apps.openshift.io"], > Verbs:["get"]} PolicyRule{Resources:["deploymentconfigs/finalizers"], > APIGroups:["apps.openshift.io"], Verbs:["list"]} PolicyRule{Resources:[" > deploymentconfigs/finalizers"], APIGroups:["apps.openshift.io"], > Verbs:["watch"]} PolicyRule{Resources:["deploymentconfigs/finalizers"], > APIGroups:["apps.openshift.io"], Verbs:["create"]} PolicyRule{Resources:[" > deploymentconfigs/finalizers"], APIGroups:["apps.openshift.io"], > Verbs:["delete"]} PolicyRule{Resources:["deploymentconfigs/finalizers"], > APIGroups:["apps.openshift.io"], Verbs:["patch"]} PolicyRule{Resources:[" > deploymentconfigs/finalizers"], APIGroups:["apps.openshift.io"], > Verbs:["update"]} PolicyRule{Resources:["imagestreams/status"], > APIGroups:["image.openshift.io"], Verbs:["create"]} > PolicyRule{Resources:["imagestreams/status"], APIGroups:[" > image.openshift.io"], Verbs:["delete"]} PolicyRule{Resources:["imagestreams/status"], > APIGroups:["image.openshift.io"], Verbs:["patch"]} PolicyRule{Resources:["imagestreams/status"], > APIGroups:["image.openshift.io"], Verbs:["update"]}] user=&{SG0556477 ? > > > > What we are wondering is if all permissions (https://github.com/strimzi/ > strimzi/blob/master/examples/install/cluster-controller/02-role.yaml) are > required? For example we don?t need to install Strimzi in other namespaces. > We want to start with only operating within one namespace. Do you think we > may reduce permissions (which?) and hence solve the issue (temporarily > until our admins give us cluster admin role). > > Also, we observed that after installing Strimzi, there is one ZK pod. > Should it not be more e.g. 3 for HA ? What topology would you recommend for > a start (3+3 ? ) > > Piotr, Krzysztof ? please add if needed. > > Przemek > > > > *From:* Jakub Scholz [mailto:jakub at scholz.cz] > *Sent:* Tuesday, April 17, 2018 6:42 PM > > *To:* Budzik, Przemyslaw > *Cc:* strimzi at redhat.com; Chylek, Artur ; Wnuk, > Norbert > *Subject:* Re: [Strimzi] RC1 of Strimzi 0.3.0 available > > > > One of the problems is that the config map is a namespaced resource. But > if you want a Kafka cluster which serves multiple namespaces then Kafka > topic is not namespaced resource. That means a lot of complications. For > example what should we do when the same topic is configured within > different namespaces? So I do not think we can see the presence of the > config map for given topic in the namespace as a proof of ownership for the > topic. > > > > I think that the general idea is quite good. But the implementation might > not be trivial. I think I will need some more time to think about it. > Either way this is far beyond the 0.3.0 scope. > > > > Thanks > > Jakub > > > > > > On Mon, Apr 16, 2018 at 10:24 AM, Budzik, Przemyslaw < > Przemyslaw.Budzik at sabre.com> wrote: > > Thank you Jakub. I have a question. Is there any way to bind namespace > with topic in terms of authorization? Consider a scenario. > > > > 1. Team A creates a topic called ?reservations?. They own the config > map and of course they can publish to this topic. > 2. Team B is interested in consuming A?s messages. I am guessing if > they know the name of the topic, they can use it ? Ideally since they are > in the namespace B, we?d like to be able to say they can, but others > can?t. Also I mean we give them read, but not write. Most likely it?s the > creator of topic writing and other namespaces (or the same) consuming. > > > > If that is not supported, is that on your roadmap ? > > > > *From:* Jakub Scholz [mailto:jakub at scholz.cz] > *Sent:* Friday, April 13, 2018 2:44 PM > *To:* Budzik, Przemyslaw > *Cc:* strimzi at redhat.com; Chylek, Artur ; Wnuk, > Norbert > *Subject:* Re: [Strimzi] RC1 of Strimzi 0.3.0 available > > > > Hi, > > > > Well, it is a release candidate. So while I hope that there will be no > issues, there is always possibility. But feel free to give it a try. It > doesn't bring any significant new features, but it improves a bit the > resilience with which the controller reacts to different problems and > situations. If you didn't experienced any issues with 0.2.0, you can just > stay with it. > > > > I hope the final release will be done early next week. > > > > Thanks & Regards > > Jakub > > > > On Fri, Apr 13, 2018 at 1:10 AM, Budzik, Przemyslaw < > Przemyslaw.Budzik at sabre.com> wrote: > > Jakub, > > > > Which version would you recommend using in our case ? One of the teams is > now installing Strimzi in our DEV environment. > > > > Thanks, > > Przemek > > > > *From:* strimzi-bounces at redhat.com [mailto:strimzi-bounces at redhat.com] *On > Behalf Of *Jakub Scholz > *Sent:* Friday, April 13, 2018 4:32 AM > *To:* strimzi at redhat.com > *Subject:* [Strimzi] RC1 of Strimzi 0.3.0 available > > > > Hi, > > > > The Release Candidate 1 for the first Strimzi 0.3.0 is now available. > > > > If you are interested have a look at the release candidate and give us > your feedback: > > https://github.com/strimzi/strimzi/releases/tag/0.3.0-rc1 > > > > Thanks & Regards > > Jakub > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: