2020-03-04 10:35:30 UTC - Konstantinos Papalias: Hi @Devin G. Bost thanks for the insight, can you elaborate a bit more on what you mean with a `Pulsar consumer` for deploying functions ? Is there any source code you could share as a reference if it's not sensitive info ? ---- 2020-03-04 10:39:42 UTC - Konstantinos Papalias: I can see already many limitations with approach 2) since the standalone is not registering functions with the admin API, therefore no monitoring and management for free :slightly_smiling_face:, so your alternative solution sounds interesting. Is it a thin http client that registers the functions ? ---- 2020-03-04 13:50:04 UTC - Devin G. Bost: Yes, it’s basically a thin http client that registers functions by hitting the admin API’s http endpoint directly. In our implementation, we’re subscribing to a Pulsar topic (in a docker container) that receives the data with the details of the function we’re uploading, and then it hits the admin http endpoint to perform the upload. ok_hand : Konstantinos Papalias ---- 2020-03-04 13:51:03 UTC - Devin G. Bost: <http://pulsar.apache.org/functions-rest-api/?version=2.5.0#operation/updateFunction> ---- 2020-03-04 13:52:31 UTC - Devin G. Bost: BTW, there’s a dead link (<http://pulsar.apache.org/en/admin-rest-api/#/>) on this page: <https://pulsar.apache.org/docs/en/admin-api-overview/> ---- 2020-03-04 13:56:43 UTC - Konstantinos Papalias: Thanks for the information, so in effect you are actually using approach 1) as well, which is to register functions via the Admin API. Although you have taken the extra step of streamlining the deployment :slightly_smiling_face: ---- 2020-03-04 13:57:58 UTC - Konstantinos Papalias: Given the opportunity, which type of function runtime do you favour the most? Do you prefer the use of Kubernetes Runtime for resource isolation, or not really ? ---- 2020-03-04 16:06:34 UTC - Luis Muniz: @Luis Muniz has joined the channel ---- 2020-03-04 17:26:47 UTC - Sijie Guo: Can you create a github issue? ---- 2020-03-04 17:26:59 UTC - Devin G. Bost: Sure thing. ---- 2020-03-04 17:27:54 UTC - Devin G. Bost: <https://github.com/apache/pulsar/issues/6470> ---- 2020-03-04 20:17:36 UTC - Addison Higham: oh hey, would you look at that, got out of sync ZKs again on my beta cluster so I can actually poke it ---- 2020-03-04 20:27:49 UTC - Addison Higham: so, here is what it looks like: • I have 5 nodes, 2 of which are out of sync (but do appear to be in sync with each other? both in the same weird state) • new writes/updates to new keys in both sides of the "split brain" work, so if I make changes to a leader, those keys show up the bad followers • new writes/update to new keys to the bad followers ALSO show up on the leader • if I try and delete or update a node that doesn't exist on the leader I get an error code `KeeperErrorCode = NoNode` • I can make changes to existing nodes on the bad followers, they do appear to go through to the rest of the nodes • For nodes that doesn't exist on the bad members, changes made on good members DO NOT get replicated to the bad members ---- 2020-03-04 20:55:03 UTC - Addison Higham: I don't see anything weird in the logs during these sorts of problems ---- 2020-03-05 04:47:24 UTC - sindhushree: has anyone published the results of this benchmarks? ---- 2020-03-05 07:11:04 UTC - Devin G. Bost: I want to clarify that I'm not talking about the Java Admin API. I'm talking about the REST Admin API. There's a big difference. ---- 2020-03-05 07:12:06 UTC - Devin G. Bost: I personally don't have enough experience with Kubernetes because we ended up running a bare metal docker implementation, but I've heard really good things about Pulsar on Kubernetes. ----
