That is definitely confusing that the --bootstrap-server option works only when it is before the upgrade part. Maybe it is worth opening a JIRA for it?
Jakub On Fri, Oct 20, 2023 at 7:40 AM Soukal, Jiří <j.sou...@quadient.com.invalid> wrote: > Hello Jakub, > > Thank you for reply. I have tried the --bootstrap-server option before but > have used it incorrectly. > > this gives unrecognized arguments: '--bootstrap-server' > ./bin/kafka-features.sh upgrade --metadata 3.6 --bootstrap-server > [server:port] > > but this works: > ./bin/kafka-features.sh --bootstrap-server [server:port] upgrade > --metadata 3.6 > > This is doable using declarative Kubernetes job. > > Thank you very much, I appreciate your help. > > Jiri > > From: Jakub Scholz <ja...@scholz.cz> > Sent: Thursday, October 19, 2023 5:18 PM > To: users@kafka.apache.org > Subject: [External Email] Re: Upgrading Kafka Kraft in Kubernetes > > Hi Jiří, > > Why can't you run it from another Pod? You should be able to specify > --bootstrap-server and point it to the brokers to connect to. You can also > pass further properties to it using the --command-config option. It should > be also possible to use it from the Admin API > < > https://kafka.apache.org/36/javadoc/org/apache/kafka/clients/admin/Admin.html#updateFeatures(java.util.Map > < > https://kafka.apache.org/36/javadoc/org/apache/kafka/clients/admin/Admin.html#updateFeatures(java.util.Map > >,org.apache.kafka.clients.admin.UpdateFeaturesOptions)> > directly from anywhere if needed. > > But there is indeed no way to manage this declaratively in the Kafka > properties file as it was possible with inter.broker.protocol.version. It > also works a bit differently than the inter.broker.protocol.version worked > before KRaft: > * I think it does more checking whether all nodes in the cluster support > the version etc. > * You can't really downgrade it easily (at least not safely). > > So maybe it is better you cannot just change some environment variables as > that might result in crash-looping pods. > > Jakub > > > On Thu, Oct 19, 2023 at 2:58 PM Soukal, Jiří <j.sou...@quadient.com.invalid > <mailto:j.sou...@quadient.com.invalid>> > wrote: > > > Hello all, > > Final step of the upgrade procedure is to run command like: > > > > "./bin/kafka-features.sh upgrade --metadata 3.6" > > > > In the Kubernetes world, which works in the desired state configuration > > (yamls and its the upper level abstractions), this is quite complicated. > > > > The first thing I tried to find is if I can call it from another kafka > pod > > while specifying a server to connect to, however it is not possible. It > > needs to be run from withing the running kafka pod. This leads to > executing > > to the pod or running the kubectl exec (e.g. kubectl exec kafka-0 -n > cloud > > -- bin/kafka-configs.sh ... ) > > > > However, this command is also imperative instead of declarative. > > > > Question: Is there another approach? E.g. driving the metadata version > via > > ENV variable or file configuration? > > > > It seems like it was designed without Kubernetes world in mind. > > >
