From jakub at scholz.cz Thu May 3 13:53:00 2018 From: jakub at scholz.cz (Jakub Scholz) Date: Thu, 3 May 2018 15:53:00 +0200 Subject: [Strimzi] [Release] Strimzi 0.3.1 Message-ID: Strimzi 0.3.1 is now available. Only change since 0.3.0 is: - Use correct default image for Kafka Connect S2I deployments #416 (Bugfix) For more details go to http://strimzi.io/ and/or https://github.com/strimzi/strimzi/releases/tag/0.3.1 Thanks to everyone who help with this release. Jakub -------------- next part -------------- An HTML attachment was scrubbed... URL: From Przemyslaw.Budzik at sabre.com Mon May 7 10:26:14 2018 From: Przemyslaw.Budzik at sabre.com (Budzik, Przemyslaw) Date: Mon, 7 May 2018 10:26:14 +0000 Subject: [Strimzi] RC1 of Strimzi 0.3.0 available In-Reply-To: References: Message-ID: Thank you Jakub. It worked for us, but we are not sure what may be potentially missing. Two new questions: 1. What do you think about using Istio for TLS and AuthN? Liike so: https://medium.com/jayanthg/transparently-securing-kafka-istio-style-with-up-to-300-higher-performance-than-native-tls-in-aa95731b5d40 2. I suppose ideally each topic partition is located on a separate physical node/storage. Otherwise we have concurrent writes/reads to the same underlying storage (in different files). However in an environment like the one we are building, there may be hundreds of topics multiplied by its replicas (hence very many files) and for sure there will be many residing on the same physical node (and more than 1 accessed a time). I am not able to assess how this would perform given different setup specifics like SSD disks, GlusterFS/NFS etc. etc. Do you see any issues with this approach Przemek From: Jakub Scholz [mailto:jakub at scholz.cz] Sent: Monday, April 30, 2018 12:44 PM To: Budzik, Przemyslaw Cc: strimzi at redhat.com; Pietrucha, Piotr ; Pachowicz, Krzysztof Subject: Re: [Strimzi] RC1 of Strimzi 0.3.0 available 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 > 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 > 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 Sun May 13 12:16:05 2018 From: jakub at scholz.cz (Jakub Scholz) Date: Sun, 13 May 2018 14:16:05 +0200 Subject: [Strimzi] RC1 of Strimzi 0.4.0 available Message-ID: Hi, The Release Candidate 1 for the first Strimzi 0.4.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.4.0-rc1 Thanks & Regards Jakub -------------- next part -------------- An HTML attachment was scrubbed... URL: From jakub at scholz.cz Sun May 13 12:44:59 2018 From: jakub at scholz.cz (Jakub Scholz) Date: Sun, 13 May 2018 14:44:59 +0200 Subject: [Strimzi] RC1 of Strimzi 0.3.0 available In-Reply-To: References: Message-ID: Sorry, I somehow missed this email earlier. I will have a look at the article - we are still working on the encryption and security support. As for the second point ... the usual setup is that a single Kafka node is shared between multiple topics / partitions. Unless you have some exceptionally busy topic, this should work fine. AFAIK it is quite normal to have 100s of partitions on a single node. The storage type question is a bit more complicated. We plan to have support for local SSD disks which are used quite often (Kafka replication can take care of the fault tolerance). Network attached SSDs such as Amazon EBS volumes should also work fine. Things like Gluster or NFS are a bit more complicated. I don't think NFS would work well for Kafka. With Gluster we are yet to do some testing. The challenge with GlusterFS will be that it normally shares the same network for storage as is used by Kafka. So throughput requirements on the network are multiplied. Thanks & Regards Jakub On Mon, May 7, 2018 at 12:26 PM, Budzik, Przemyslaw < Przemyslaw.Budzik at sabre.com> wrote: > Thank you Jakub. It worked for us, but we are not sure what may be > potentially missing. > > Two new questions: > > 1. What do you think about using Istio for TLS and AuthN? Liike so: > https://medium.com/jayanthg/transparently-securing-kafka- > istio-style-with-up-to-300-higher-performance-than- > native-tls-in-aa95731b5d40 > > 2. I suppose ideally each topic partition is located on a separate > physical node/storage. Otherwise we have concurrent writes/reads to the > same underlying storage (in different files). However in an environment > like the one we are building, there may be hundreds of topics multiplied by > its replicas (hence very many files) and for sure there will be many > residing on the same physical node (and more than 1 accessed a time). I am > not able to assess how this would perform given different setup specifics > like SSD disks, GlusterFS/NFS etc. etc. Do you see any issues with this > approach > > Przemek > > > > *From:* Jakub Scholz [mailto:jakub at scholz.cz] > *Sent:* Monday, April 30, 2018 12:44 PM > *To:* Budzik, Przemyslaw > *Cc:* strimzi at redhat.com; Pietrucha, Piotr ; > Pachowicz, Krzysztof > > *Subject:* Re: [Strimzi] RC1 of Strimzi 0.3.0 available > > > > 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: From ppatiern at redhat.com Mon May 14 11:10:31 2018 From: ppatiern at redhat.com (Paolo Patierno) Date: Mon, 14 May 2018 13:10:31 +0200 Subject: [Strimzi] RC1 of Strimzi 0.4.0 available In-Reply-To: References: Message-ID: Hi, I kicked the tyres mainly with focus on new enhanced configuration and resources (cpu and memory) on both minikube and minishift. I opened the following issue related to requests : https://github.com/strimzi/strimzi/issues/436 Probably we want to fix this one before the release and I can work on that. Wdyt ? Thanks, Paolo. On Sun, May 13, 2018 at 2:16 PM, Jakub Scholz wrote: > Hi, > > The Release Candidate 1 for the first Strimzi 0.4.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.4.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 Mon May 14 11:40:01 2018 From: jakub at scholz.cz (Jakub Scholz) Date: Mon, 14 May 2018 13:40:01 +0200 Subject: [Strimzi] RC1 of Strimzi 0.4.0 available In-Reply-To: References: Message-ID: As discussed with Paolo on Slack - this is an existing issue ( https://github.com/strimzi/strimzi/issues/127) planned to be fixed in 0.5.0. This should not be a blocker for 0.4.0. (Just copying this to the mailing list) Jakub On Mon, May 14, 2018 at 1:10 PM, Paolo Patierno wrote: > Hi, > > I kicked the tyres mainly with focus on new enhanced configuration and > resources (cpu and memory) on both minikube and minishift. > I opened the following issue related to requests : > https://github.com/strimzi/strimzi/issues/436 > Probably we want to fix this one before the release and I can work on that. > > Wdyt ? > > Thanks, > Paolo. > > > On Sun, May 13, 2018 at 2:16 PM, Jakub Scholz wrote: > >> Hi, >> >> The Release Candidate 1 for the first Strimzi 0.4.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.4.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 ppatiern at redhat.com Mon May 14 14:41:41 2018 From: ppatiern at redhat.com (Paolo Patierno) Date: Mon, 14 May 2018 16:41:41 +0200 Subject: [Strimzi] RC1 of Strimzi 0.4.0 available In-Reply-To: References: Message-ID: I did some other tests (with Kubernetes as well). Other than the one I noticed (but that will be fixed in 0.5.0) ... my +1 on this release. On Mon, May 14, 2018 at 1:40 PM, Jakub Scholz wrote: > As discussed with Paolo on Slack - this is an existing issue ( > https://github.com/strimzi/strimzi/issues/127) planned to be fixed in > 0.5.0. This should not be a blocker for 0.4.0. > > (Just copying this to the mailing list) > > Jakub > > On Mon, May 14, 2018 at 1:10 PM, Paolo Patierno > wrote: > >> Hi, >> >> I kicked the tyres mainly with focus on new enhanced configuration and >> resources (cpu and memory) on both minikube and minishift. >> I opened the following issue related to requests : >> https://github.com/strimzi/strimzi/issues/436 >> Probably we want to fix this one before the release and I can work on >> that. >> >> Wdyt ? >> >> Thanks, >> Paolo. >> >> >> On Sun, May 13, 2018 at 2:16 PM, Jakub Scholz wrote: >> >>> Hi, >>> >>> The Release Candidate 1 for the first Strimzi 0.4.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.4.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 >> >> >> >> >> > > -- PAOLO PATIERNO PRINCIPAL SOFTWARE ENGINEER, MESSAGING & IOT Red Hat -------------- next part -------------- An HTML attachment was scrubbed... URL: From asorokht at redhat.com Tue May 15 10:12:56 2018 From: asorokht at redhat.com (Andriy Sorokhtey) Date: Tue, 15 May 2018 13:12:56 +0300 Subject: [Strimzi] 0.4.0-rc1 testing completed Message-ID: Hi, I'd like to let you know that Strimzi QE team finished testing of Strimzi release 0.4.0-rc1. No issues were found and we can release 0.4.0. -- Thanks, Andriy Sorokhtey Quality Engineer, Strimzi team -------------- next part -------------- An HTML attachment was scrubbed... URL: From jakub at scholz.cz Tue May 15 19:48:21 2018 From: jakub at scholz.cz (Jakub Scholz) Date: Tue, 15 May 2018 21:48:21 +0200 Subject: [Strimzi] [Release] Strimzi 0.4.0 Message-ID: Strimzi 0.4.0 has been released. The most notable changes since 0.3.1 are: * Better configurability of Kafka, Kafka Connect, Zookeeper * Support for Kubernetes request and limits * Support for JVM memory configuration of all components * Controllers renamed to operators * Improved log verbosity of Cluster Operator * Update to Kafka 1.1.0 List of all issues can be found here: https://github.com/strimzi/strimzi/issues?page=1&q=milestone%3A0.4.0 This release has some backwards incompatible changes: * Cluster Controller and Topic Controller were renamed to Cluster Operator and Topic Operator * Roles, role bindings and service accounts existing from previous deployments can not be reused * The following fields from Kafka ConfigMap have been replaced with new field `kafka-config` * `KAFKA_DEFAULT_REPLICATION_FACTOR` * `KAFKA_OFFSETS_TOPIC_REPLICATION_FACTOR` * `KAFKA_TRANSACTION_STATE_LOG_REPLICATION_FACTOR` * The following fields from Kafka Connect ConfigMap have been replaced with new field `connect-config` * `KAFKA_CONNECT_BOOTSTRAP_SERVERS` * `KAFKA_CONNECT_GROUP_ID` * `KAFKA_CONNECT_KEY_CONVERTER` * `KAFKA_CONNECT_KEY_CONVERTER_SCHEMAS_ENABLE` * `KAFKA_CONNECT_VALUE_CONVERTER` * `KAFKA_CONNECT_VALUE_CONVERTER_SCHEMAS_ENABLE` * `KAFKA_CONNECT_CONFIG_STORAGE_REPLICATION_FACTOR` * `KAFKA_CONNECT_OFFSET_STORAGE_REPLICATION_FACTOR` * `KAFKA_CONNECT_STATUS_STORAGE_REPLICATION_FACTOR` For more details go to http://strimzi.io/ and/or https://github.com/strimzi/strimzi/releases/tag/0.4.0 Thanks to everyone who help with this release. Jakub -------------- next part -------------- An HTML attachment was scrubbed... URL: