onyx

FYI: alternative Onyx :onyx: chat is at <https://gitter.im/onyx-platform/onyx> ; log can be found at <https://clojurians-log.clojureverse.org/onyx/index.html>
kenny 2018-06-29T16:37:03.000460Z

Can org.clojure/test.check be set to :scope "test" and org.clojure/clojurescript & org.clojure/clojure set to :scope "provided" in onyx-spec?

lucasbradstreet 2018-06-29T16:40:36.000123Z

Yes, that seems fine

sparkofreason 2018-06-29T17:15:00.000422Z

Just updated our cluster after a crash, getting this exception. Any idea what that means?

lucasbradstreet 2018-06-29T17:16:29.000373Z

@dave.dixon looks like that’s a case where we fail fast and your container / monitored java should start back up

lucasbradstreet 2018-06-29T17:18:06.000013Z

It seems to be due to initial failures connecting to Zk, and then having it fail again when it tries to start the connection. We may be able to improve this case.

sparkofreason 2018-06-29T17:18:27.000365Z

It's stuck in CrashLoopBackOff in k8s, error keeps repeating. I'll check ZK.

lucasbradstreet 2018-06-29T17:22:35.000125Z

Actually this part of the message suggests something else: “org.apache.zookeeper.KeeperException.create KeeperException.java: 103 org.apache.zookeeper.KeeperException$UnimplementedException: KeeperErrorCode = Unimplemented for /onyx code: -6 path: "/onyx"

lucasbradstreet 2018-06-29T17:23:09.000324Z

UnimplementedException - May need to know what version of onyx and ZK you’re on.

sparkofreason 2018-06-29T17:30:43.000083Z

Onyx 0.13.0.0. We're running ZK as a hosted service via CloudKarafka, I'll try to find out what's happening there. It was all working fine just an hour ago.

lucasbradstreet 2018-06-29T17:31:53.000120Z

Ah weird then. Either way it definitely seems like something to do with ZK but I’m not much help past that.

sparkofreason 2018-06-29T17:36:40.000053Z

Can you think of anything I might have been able to do to cause this?

lucasbradstreet 2018-06-29T17:43:50.000293Z

One possibility is that we did bump the ZK client library in 0.13.0 so that we could support SSL. It’s supposed to be backwards compatible, but it’s possible that there is a bad interaction with the hosted ZK version

lucasbradstreet 2018-06-29T17:44:16.000103Z

That might be preventing you from seeing the true error

lucasbradstreet 2018-06-29T17:46:22.000201Z

You could try excluding org.apache.curator/curator-client and org.apache.curator/curator-framework from the onyx dependency, and provide [org.apache.curator/curator-framework "2.9.1"] in your deps to get back the old library, and try again

sparkofreason 2018-06-29T18:14:45.000164Z

That yields this. Do I need to add a curator-client dep as well?

lucasbradstreet 2018-06-29T18:15:31.000512Z

Oof. Looks like there are other deps that will need to be overridden. I’ll check with the diff again

sparkofreason 2018-06-29T18:16:53.000129Z

FWIW - I'm pretty sure the previous working version was onyx 0.13.0.0 as well.

lucasbradstreet 2018-06-29T18:17:27.000456Z

Yeah, I’m mostly hoping to resolve the unimplemented exception issue so we can get at the real error

lucasbradstreet 2018-06-29T18:18:44.000127Z

You may need to exclude org.apache.zookeeper/zookeeper and use “3.4.10” instead

lucasbradstreet 2018-06-29T18:19:41.000422Z

All my testing thus far has found the curator/zk deps we bumped to be fine, but I don’t really have any other ideas for debugging it

lucasbradstreet 2018-06-29T18:20:05.000229Z

I guess you could try connecting to zk with the cli and listing /onyx and see if you’re able to poke around there

sparkofreason 2018-06-29T18:38:02.000430Z

I rolled back to the container image that was working before, and it still works, so it must be something that we changed recently.

lucasbradstreet 2018-06-29T18:38:33.000251Z

Ah ok. Dependencies seem the most likely cause.

sparkofreason 2018-06-29T19:34:42.000398Z

BTW, the big change is that we moved to using tools-deps, which seems to change how deps are resolved.

j0ni 2018-06-29T20:37:32.000300Z

hello all - I'm using a docker-compose setup based closely on the one generated by the +docker flag to the leiningen onyx template - and the config.edn is currently the one which was generated. I'm seeing a lot of DEBUG level logs from the peer container though, which this

:onyx.log/config #profile {:default nil
                             :docker {:level :info}}
looks like it should preclude

j0ni 2018-06-29T20:38:27.000093Z

it's this kind of thing:

DEBUG org.apache.zookeeper.ClientCnxn - Got ping response for sessionid: 0x1644d383a3d0001 after 1ms
which looks like it's not generated originally by timbre

j0ni 2018-06-29T20:40:25.000340Z

any ideas how to turn down logging to INFO?