You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@pulsar.apache.org by Apache Pulsar Slack <ap...@gmail.com> on 2018/01/04 11:31:11 UTC
Slack digest for #general - 2018-01-04
2018-01-03 18:03:54 UTC - Matteo Merli: > There are many valuable discussions that will go away. If these conversations were in email on the Apache servers then other developers would benefit for years...
@David Fisher As I mentioned on the list, I wrote a small script to create the mail digest. <https://github.com/merlimat/slack-email-digest>
If someone is able to help putting this in a “cron” job running somewhere (eg: AppEngine, Heroku, …) it would be great, since I don’t have much experience there.
----
2018-01-03 21:16:47 UTC - Daniel Ferreira Jorge: Hello again, I'm developing a Helm chart to deploy pulsar on kubernetes (When it is ready I will send PR) and I have some doubts about the metadata initialization. In the docs, it is said that the metadata should be initialized on zookeeper by issuing "bin/pulsar initialize-cluster-metadata" right after the zookeeper.yaml is deployed but before the other components. And, if you take a look at bookie.yaml on line 96 (<https://github.com/apache/incubator-pulsar/blob/f5d2a4dce88460be46f1687a28bf1ed2d4944b4e/kubernetes/generic/bookie.yaml#L96>) there is "another" metadata initialization. Are they the same?
----
2018-01-03 21:17:54 UTC - Ali Ahmed: No they are not the same , if the bin/pulsar initialize-cluster-metadata is done the bookeeper init is not needed
----
2018-01-03 21:26:10 UTC - Daniel Ferreira Jorge: ah ok. Is the bin/pulsar initialize-cluster-metadata absolutely necessary then? Or maybe, could it be executed after everything (bookies, brokers, etc) is up?
----
2018-01-03 21:26:51 UTC - Ali Ahmed: it’s necessary before the brokers start
----
2018-01-03 21:27:15 UTC - Daniel Ferreira Jorge: ok great, thanks
----
2018-01-03 21:28:15 UTC - Ali Ahmed: so suggested sequence will be ``start zookeeper - > start bookies - > initialize-cluster-metadata - > start brokers``
----
2018-01-03 21:28:48 UTC - Ali Ahmed: do you have a github repo where you are hosting your helm chart ?
----
2018-01-03 21:29:35 UTC - Daniel Ferreira Jorge: I have a fork of pulsar om my pc.. not on GH yet
----
2018-01-03 21:29:42 UTC - Ali Ahmed: ok
----
2018-01-03 21:30:05 UTC - Daniel Ferreira Jorge: but I think I can finish the charts by tomorrow... maybe friday
----
2018-01-03 21:30:10 UTC - Daniel Ferreira Jorge: then I will do a PR
----
2018-01-04 03:41:02 UTC - Sijie Guo: @Ali Ahmed I think the sequence is wrong. it should be “start zk -> initialize-cluster-metadata > start bk -> start brokers”.
+1 : Rajan Dhabalia, Matteo Merli
----
2018-01-04 08:58:18 UTC - Ivan Kelly: would be nice if both sequences worked
----
2018-01-04 09:00:09 UTC - Matteo Merli: so, I think that we added the `bin/bookkeeper shell metaformat --nonInteractive || true;` in the bookies `initContainer` phase just for that
----
2018-01-04 09:01:03 UTC - Matteo Merli: the `metaformat` will just bail out if the metadata is already there and the `|| true` will make it ignore the error code
----
2018-01-04 09:01:35 UTC - Matteo Merli: the only disadvantage is that we try that each time the container is restarted, but it’s not a big deal
----
2018-01-04 09:03:25 UTC - Matteo Merli: the only thing about `initialize-cluster-metadata` is that we need some info when executing it, especially in cases when doing a multi-cluster deployment (eg: clusterName and url for the cluster). If these infos could be configured in the Helm chart, we could easily automate that part too
----
2018-01-04 10:20:10 UTC - Daniel Ferreira Jorge: What I'm doing is, in the zookeeper statefulset, I loop until ruok == imok, then I execute the initialize-cluster-metadata. The other components will have a init container that wait for the zookeeper service to be ready. Only then the components are deployed. Will this work?
----
2018-01-04 10:22:14 UTC - Matteo Merli: I think it should work, even if the broker start between ZK is up and before initialize-cluster-metadata is done, I believe it shouldn’t cause any problem
----
2018-01-04 10:29:16 UTC - Daniel Ferreira Jorge: @Matteo Merli If I can start all the components and only then initialize the metadata would be much easier. There would not have to be a init container waiting for zoo in all components. From what you said, it appears that this is the case?
----
2018-01-04 10:30:04 UTC - Matteo Merli: Sure, though it might be printing ZK connection errors for a while
----
2018-01-04 10:30:52 UTC - Matteo Merli: (in any case, in the initial deployment the most time is spent in fetch the pulsar docker image in all the nodes
----
2018-01-04 10:31:19 UTC - Matteo Merli: so I would assume, most containers will actually try to start around the same time
----
2018-01-04 10:45:07 UTC - Daniel Ferreira Jorge: Just making sure: If I initialize metadata last of all, zookeeper will be running, brokers and bookies will know where zookeeper and will be able to connect to zookeeper, but the metadata won't be there. This is ok, right?
----
2018-01-04 10:46:31 UTC - Matteo Merli: correct, so some of the things might not be working (eg: creating namespaces, changing policies, etc)
----
2018-01-04 10:47:35 UTC - Daniel Ferreira Jorge: ok, but once the metadata is initialized everything will start working.
----
2018-01-04 10:53:55 UTC - Daniel Ferreira Jorge: Also, would it be possible to make the docker image be a little more flexible in accepting custom config? What I mean is the script apply-config-from-env.py only replaces config strings that is already there. It should also append new strings to the bottom of the config files. We cannot easily insert custom config for any component. We would have to manually enter the containers and change it.
----
2018-01-04 10:55:13 UTC - Daniel Ferreira Jorge: This makes the pulsar kubernetes deployment more of a "demo" than something ready for production
----
2018-01-04 11:02:07 UTC - Matteo Merli: Sure, it was not there initially since we cannot just replace all the variable from ENV as they are, because there is a bunch of unrelated stuff. For BookKeeper we followed a slightly different approach, in which variable with prefix `BK_xxx` are ending up in the config file as `xxx`
----
2018-01-04 11:03:06 UTC - Matteo Merli: Do you have any suggestion for approaches to this?
----
2018-01-04 11:04:01 UTC - Matteo Merli: Also, is there any particular variable you are thinking of? All the possible variables should already be in the conf file, uncommented and with default value set
----