Fork me on GitHub
#onyx
<
2016-07-28
>
vijaykiran09:07:42

I wish the user guide on the docs, is structured in logical way than just alphabetic order

jeroenvandijk09:07:30

I can’t help to think that this fake-s3 thing would be so much easier to write in Clojure (LOL), but looks useful!

jeroenvandijk09:07:52

(I was a Ruby fanboy once, for the record)

mpenet09:07:01

maybe it's possible to do on top of pithos (it might be "just" implementing a couple of protocols to do stuff in memory/disk)

lucasbradstreet09:07:46

@vijaykiran: sorry about that. We've been meaning to rearrange the docs in Jekyll

jeroenvandijk09:07:16

@mpenet: Sounds like a possibility, although the number of dependencies would scare me https://github.com/exoscale/pithos/blob/master/project.clj#L11

mpenet09:07:31

yeah, it's not exaclty lightweight

mpenet09:07:51

but should be solid given what they use it for

jeroenvandijk09:07:45

If anything, you could probably copy the test suite and build something light weight and know it is of a similar quality

jeroenvandijk09:07:15

(Ok back to work :))

michaeldrogalis14:07:21

@vijaykiran: Working on it, I dislike our current User Guide too. I've been working on compiling it into a one-page document with side-bar anchor links.

michaeldrogalis14:07:44

The more we grow, the more things that were once simple, like publishing docs, get more complex. 😛

dominicm15:07:12

How useful is Onyx on a single peer? It seems like a better way to handle running multiple "handlers" for core.async channels. Or is there something else more suited to this?

gardnervickers15:07:32

Onyx is a great way to model your computation through data!

michaeldrogalis15:07:18

@dominicm: some people use it for this, yes. It's a trade-off, since Onyx brings the full power and complexity of a tool that orchestrates a cluster. The flip side is that you get a very good computational model.

dominicm15:07:23

I guess it makes it easier to horizontally scale later too?

dignati15:07:28

We are still running on only one peer. We chose onyx exactly because of these reasons

michaeldrogalis15:07:34

Correct. Also, if your input data source(s) are remote, you're already dealing with a distributed system, and so you can get fault handling for free.

dominicm15:07:34

You mean input to the channels?

dominicm15:07:40

This is very reassuring. I had dismissed Onyx as something for "later when scale comes" but I want an event based model, so I'll create serious bottlenecks if there's only one processor for it

michaeldrogalis15:07:41

Have a play around with learn-onyx and see if it fits your model. Might be a good fit.

dominicm15:07:53

Will do, thanks!

aaelony17:07:19

learn-onyx is awesome

camechis17:07:35

Does a lifecycle before-task-start run before every segment that runs through that particular task? or does it run once as the job spins up?

dignati17:07:00

No it only runs once

lucasbradstreet17:07:17

it will run any time a peer starts operating on a task

lucasbradstreet17:07:40

so this could happen any time during a job e.g. if a new node starts up.

camechis17:07:37

right, i wasn’t sure if it meant before a segment ran through it. I didn’t want my db connections to get restarted everytime a segment came through. lol

lucasbradstreet17:07:13

I figured, I just wanted to make sure you got the whole picture 🙂

camechis17:07:29

yep, its how i thought it worked but began questioning myself. lol

camechis17:07:33

In the case of a trigger what would I use for the lifecycle/task ?

camechis17:07:30

any hints on this?

gardnervickers18:07:19

It depends what you want to do

gardnervickers18:07:29

Triggers attach to tasks that have windows

camechis18:07:53

@gardnervickers: I am setting a lifecycle before-task to setup some DB connections used by the trigger

camechis18:07:33

so for the lifecycles/task would i use the sync function as well?

gardnervickers18:07:16

No, your lifecycle runs before-task and returns a map that looks like {:db-conn <db-conn>}. That map is merged into the event map. For any triggers that are attached to the same task your lifecycle is attached to, they will receive the event map as an arg, which you can grab the :db-conn out of.

camechis18:07:45

so I am still confused what task would I attach the lifecycle to so the event ( with db conns ) is available in the trigger?

gardnervickers18:07:14

It would be whatever task you’re windowing on.

gardnervickers18:07:27

If you don’t need to do any processing, you can just make a dummy task

camechis18:07:09

ok, i think i see

gardnervickers18:07:20

For the state you created in your lifecycle to be available to your trigger, both the lifecycle and trigger need to be attached to the same task.

lucasbradstreet18:07:05

Your trigger sync function will be supplied the event map

gardnervickers23:07:23

@drewverlee: I meant to chime in earlier and say thanks for the PR on the dashboard. Were you able to connect to it?

drewverlee23:07:21

i haven’t tried it yet, i’m currently struggling to understand why 3 separate datadog processes are running on this server. like who let the dogs out ahhaha 😭