Fork me on GitHub
#juxt
<
2017-09-07
>
steveb8n07:09:14

@jonpither have you had a chance to decide on best next step for Roll? maybe make the AMI public or share just to me for testing?

jonpither07:09:37

Hi @steveb8n will look at this first thing

steveb8n07:09:02

brilliant thanks

steveb8n07:09:37

btw I watched your ClojureTRE talk on it. very good for clarifying the layers

stijn10:09:18

hi @jonpither I'm looking at pack-datomic and was wondering if there's any reason you're using the particular AMI that's specified in https://github.com/juxt/pack-datomic/blob/master/datomic.json

stijn12:09:32

and I also have a mach question

stijn12:09:58

{

 mach/props [datomic-version "0.9.5561.56"
             datomic-dir (str "datomic-pro-" datomic-version)
             jar "target/transactor-lib.jar"
             lib-target (str datomic-dir "/lib/transactor-lib.jar")]

 jar        {product jar
             novelty (or
                       (not (mach.core/file-exists? jar))
                       (mach.core/modified-since jar "src"))
             produce #$ ["lein" "jar"]}

 lib        {product lib-target
             novelty (not (mach.core/file-exists? lib-target))
             depends [jar]
             produce #$ ["cp" jar datomic-lib-target]}

 run        {depends [lib jar]
             update! #$ ["cd" datomic-dir "&&" "./bin/transactor" "-Xmx2g" "dev-transactor.properties"]}
 }

stijn12:09:08

this is my Machfile.edn

stijn12:09:32

If I do a mach run it is starting the transactor before the jar and lib tasks have completed

stijn12:09:20

as a side node: after only half an hour i'm absolutely loving mach 🙂

genRaiy12:09:12

guys … trying to use your pack-datomic repo

genRaiy12:09:25

and it’s barfing on an unknown AMI

genRaiy13:09:05

the code has not been updated for several months, so are you still using this code?

genRaiy13:09:37

oh … forget it … I changed regions and the AMIs are per region

genRaiy13:09:01

@stijn - haha .. parallel lines!

genRaiy13:09:53

seems like that image is the AWS ubuntu AMI

dominicm13:09:53

We are using pack-datomic

genRaiy13:09:15

@dominicm … the AMI in the datomic.json is only available is eu-west-1

dominicm13:09:40

yeah, makes sense. That's where we use it. AMI's seem to be confusing in terms of availability & such.

genRaiy13:09:53

so I think the docs should suggest what you are using (ubuntu latest by the looks of things)

dominicm13:09:56

Is there a way to get AMI's that work everywhere or something?

dominicm13:09:01

Yeah, ubuntu for datomic atm.

stijn13:09:18

no, but maybe you need to make ami a parameter too

genRaiy13:09:30

I don’t think there are universal AMIs

dominicm13:09:32

I think in an ideal world, we'd cover all regions on your behalf based on a case or whatever.

dominicm13:09:09

There's like, 16 regions.

dominicm13:09:46

or 9, depends where I look :thinking_face:

dominicm13:09:46

14 in april 2017...

dominicm13:09:22

14 seems to be a common number. Sticking with that.

dominicm13:09:02

https://cloud-images.ubuntu.com/locator/ec2/ could make a sensible import of this data into the repo & do it that way.

genRaiy13:09:18

it would be nice to have ke / value pairs

genRaiy13:09:16

key: eu-west-1 value: ami-123-whatever

genRaiy13:09:51

but also the locator would be ok

stijn13:09:11

aha, this locator is nice

dominicm13:09:49

I'd have the minor concern of sync if we didn't take advantage of something supposedly consistent like the locator.

genRaiy13:09:39

sure, that’s better as it is maintained

genRaiy13:09:09

so you have 16.04 LTS with and ebs-ssd

genRaiy13:09:43

(actually t2.micro needs HVM so … hvm:ebs-ssd or hvm:instance-store)

dominicm13:09:01

thinking more, easier to filter by version & such, no situation where one is 16.04 and one is 17.04 for example.

genRaiy17:09:42

@dominicm am I right to assume that the storage must be provisioned outside of the pack-datomic?

genRaiy06:09:49

I have checked the original repo that @jonpither mentions in the README from @U0509NKGK and that one includes the DDB storage provisioning so I will go ahead and adapt that one

Drew Verlee21:09:26

Does anyone feel up to the task of comparing Boot with Mach? I have been playing with the idea of trying to help port boot to node in an effort to make clojure a better language for Ops. The main thing i like about boot (though im very much a novice) is the pipeline abstraction. I dont like the idea of tasks depending on each other without any flexibility (something i ran into with Rake). And eventually would like to see a more graph like option, something like what Onyx has. Someone pointed out Mach had this goal of making ops easier in Clojure. So i watched the recent clojurTre video. I still need some time to wrap my head around the idea.

dominicm21:09:21

@drewverlee 👋 they're both coming at the problem from different angles. Boot is flexible, but clearly is designed to get you into a clojure environment. The no caching is obviously slow, this is a motivator to mach. Mach has no pipeline. Mach is just a dependency graph and targets at core. If you've used make, it feels like that.

Drew Verlee21:09:31

@dominicm Thanks! Embarrassingly i haven’t used boot much, from the little i have, i assumed it was fairly agnostic to what types of Boot Tasks you used. Given the feedback i have gotten, its seems likely i’m missing something. I haven’t used Make much either (maybe i’m not a good fit for this task 😞 ), but i have used Rake. I assume the dependency graph is make is where one function is called based on another being called. f -dep--> g, so if we call f, then g gets called first. I’m starting to envision a slightly more flexible model built around the pipeline abstraction that boot uses. I’m just starting to gather information, i don’t want to build something that isn’t useful or wont get used… no point!

dominicm22:09:46

@drewverlee oh, it is agnostic! But in practice, there's a single focus. Rake is more of a "task runner", make is a file target maker. One thing it does is skip work based on file timestamp. C.out <- A.o + B.o <- A.c + B.c Make C.out will look for B.o and A.o, and only remake them if their corresponding .c file was modified. So you can have a situation where it only does cc B.c , followed by ln A.o B.o

dominicm22:09:11

(Typing from mobile so excuse inconsistent typing)

Drew Verlee22:09:43

I think i understand. I dabbled with make back in college.

dominicm22:09:54

Boot throws all caching it in order to guarantee a clean build. One of the BSDs does a clean in their build chain before running make, because they screwed up the dependency somewhere, and can't figure out where. Caching things is hard. Lein does a bad job of it. So immutable files were a good thing from that perspective.

steveb8n23:09:54

@jonpither Rays comment inspired me to check other regions and I found that the Edge AMI is in the Ireland region. I can go through the AMI copy process to replicate it to Sydney but wanted to check-in first to see if you had any other thoughts on this e.g. planning to change AMI? cc @dominicm