[Strimzi] RC1 of Strimzi 0.3.0 available

Mon Apr 30 10:44:23 UTC 2018

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
<https://github.com/strimzi/strimzi/blob/master/examples/configmaps/cluster-controller/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
<https://github.com/strimzi/strimzi/blob/master/examples/configmaps/cluster-controller/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 <Przemyslaw.Budzik at sabre.com>
> *Cc:* strimzi at redhat.com; Chylek, Artur <Artur.Chylek at sabre.com>; Wnuk,
> Norbert <Norbert.Wnuk at sabre.com>
> *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 <Przemyslaw.Budzik at sabre.com>
> *Cc:* strimzi at redhat.com; Chylek, Artur <Artur.Chylek at sabre.com>; Wnuk,
> Norbert <Norbert.Wnuk at sabre.com>
> *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: <http://listman.redhat.com/archives/strimzi/attachments/20180430/a7c350b6/attachment.htm>