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 - &gt; start bookies - &gt;  initialize-cluster-metadata - &gt; 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 -&gt; initialize-cluster-metadata &gt; start bk -&gt; 
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
----

Reply via email to