@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?

Hi @steveb8n will look at this first thing

brilliant thanks

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

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

and I also have a mach question

{

 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"]}
 }

this is my Machfile.edn

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

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

guys … trying to use your pack-datomic repo

and it’s barfing on an unknown AMI

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

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

@stijn - haha .. parallel lines!

seems like that image is the AWS ubuntu AMI

We are using pack-datomic

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

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

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

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

Yeah, ubuntu for datomic atm.

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

I don’t think there are universal AMIs

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

There's like, 16 regions.

or 9, depends where I look :thinking_face:

14 in april 2017...

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

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

it would be nice to have ke / value pairs

@raymcdermott how do you mean?

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

but also the locator would be ok

aha, this locator is nice

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

sure, that’s better as it is maintained

so you have 16.04 LTS with and ebs-ssd

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

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

https://cloud-images.ubuntu.com/locator/ec2/releasesTable nice

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

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.

@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.

@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!

@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

(Typing from mobile so excuse inconsistent typing)

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

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.

@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