Fork me on GitHub
#portkey
<
2018-03-06
>
cgrand16:03:26

an ironic ❤️

viesti16:03:20

HAL seems to gather those types of ❤️

cgrand16:03:20

that’s the “good” old decision (for output) to state that 1-items lists can be simplified to the item alone

cgrand16:03:33

This decision has so many benefits: • when looking at samples you may overlook the fact that you may get several values for a field • if simplification is mandatory (or coder is mislead) then code outputting this stuff gets more complex because of a branch to check of there’s only one item • reader code has to deal with both cases all of these for saving two chars!

stathissideris16:03:48

@cgrand I just discovered aws-clj-sdk, thanks for the good work! I noticed that only a subset of the SDK is currently supported. Since you have machine-readable descriptions to generate from, what’s preventing you from supporting everything?

cgrand17:03:37

in general or bad schemas practices?

viesti17:03:49

I have fond memories of simple use of xml documents for a project file format for a desktop app, I guess bad practices kill minds, but there's needless complexity in xml (it being a markup language)

cgrand17:03:41

yeah it’s a good markup language (mixed context etc.) that has been abused as a data language.

cgrand17:03:05

so APIs were broader than required for data, allowing too many issues and the creation of a cottage industry to fix them through complexity

stathissideris16:03:44

and another question: I noticed you’re generating specs as well, could that lead to a good way of mocking AWS services for testing some day?

viesti16:03:51

I guess mocking the data is one part, but testing against state and side-effects (some APIs don’t reflect changes immediately) is another thing to consider

cgrand16:03:34

@stathissideris AWS services do not all use the same protocol, so you have to write a code generator for each protocol. Most of the time a generator|portocol is used by many services.

stathissideris16:03:39

@viesti yes, I sure it’s not as easy as having specs for the API, but it’s a good basis I guess!

viesti16:03:41

there’s https://github.com/juxt/mach but it doesn’t have the concept of state tracking like Terraform

cgrand16:03:21

@baptiste-from-paris is working on the query protocol atm

viesti17:03:06

haven’t actually used Mach (read: have not forced my colleagues to it :)) but should have another look, it can be used to make playing with Terraform nicer

stathissideris17:03:08

@cgrand understood! that explains the “protocol” issues on github

cgrand17:03:37
replied to a thread:xml?

in general or bad schemas practices?

stathissideris17:03:00

@viesti yeah, I know about mach, but I’m thinking stand-alone clojure. Also terraform does not support the whole of AWS, it sounds like aws-clj-sdk some day will

cgrand17:03:45

on specs: before a hiatus in dev I was working in splitting/refining generated specs

viesti17:03:17

yeah, the goal is to find a nice description of stuff in AWS as data and then a way to put that data into the APIs

cgrand17:03:13

see branch wip-before-end-of-2017

viesti17:03:45

at some point I was toying with the idea of using weavejester’s integrant for defining the aws stack, as if to start/stop services with it

stathissideris17:03:17

@viesti haha, that blew my mind a little 🙂

stathissideris17:03:41

but then you’d have to persist the system structure somehow

cgrand17:03:05

@stathissideris so all that is missing is someone willing (and having time) to tackle these protocols

stathissideris17:03:08

because you want your clojure program to stop at some point without taking the remote stack with it

viesti17:03:42

might end up with something like terraform, having previous state persisted somewhere, being able to diff it, and use this “lib” as a way to start new parts

stathissideris17:03:44

@cgrand yeah, makes sense…

stathissideris17:03:32

yeah I suspect when all protocols are in place, basic terraform-like functionality is a short hop

stathissideris17:03:01

but then you have the problem of sharing the infrastructure state between multiple operators, locking etc

stathissideris17:03:05

(terraform does it with dynamobdb and s3)

valtteri17:03:29

What’s wrong with CloudFormation? 😮

stathissideris17:03:29

@valtteri does it let you update existing stacks in a declarative manner?

cgrand17:03:34

re: locking, would it be naive to go with an immutable description and a mutable reference (and a conditional write on it).

stathissideris17:03:47

@cgrand I think the problem is more how you share state between multiple users on different machines, terraform enables that scenario

cgrand17:03:24

@stathissideris I think that’s what I’m talking about too; nevermind I’m no infrastructure expert

stathissideris17:03:15

@cgrand me neither, I’m a devops hack at most 🙂

viesti17:03:35

I guess Cloudformation solves this by having runner inside the aws environment and having it not run multiple copies of a stack

viesti17:03:31

should probably look more into Cloudformation, but have been on Terraform track for now (after some maybe misguided fat fetching use of Ansible)

viesti17:03:04

One tends to make modules in Terraform, each with own state, so less overlap

viesti17:03:48

but hmm, would need some time for thought on aws-clj-sdk

dominicm18:03:50

Cloudformation has something equivalent to modules too

valtteri19:03:50

You can nest stacks in CloudFormation

valtteri19:03:15

and have cross-references between stacks, whether nested or not.

baptiste-from-paris20:03:08

@stathissideris there a 5 “protocol” implement, we’ve done rest-json and I am currently working on queryprotocol

baptiste-from-paris20:03:40

note that all “shapes” are done (aws data structure, kind of a swagger)

baptiste-from-paris20:03:15

so the job right now is to format requests for each kind of protocol

baptiste-from-paris20:03:53

and then to deserialize the response

stathissideris21:03:28

@baptiste-from-paris I really like the project, I wish I had some spare time to contribute!