Fork me on GitHub
#mount
<
2016-08-09
>
richiardiandrea18:08:50

and I gather that the :merge clause is merged after

richiardiandrea18:08:17

am I correct in saying that this part is therefore not overridable by system props/env vars?

richiardiandrea18:08:51

it is not correct lol

richiardiandrea18:08:14

it is not overridable by conf and classpath resource file

tolitius18:08:35

if I understand correctly what the question is 🙂 you can set the order in :merge

richiardiandrea18:08:59

no I had a bug yesterday but it is more a bug in my head 😄

tolitius18:08:07

you can do crazy things like:

(load-config :resource "path/within/classpath/to.edn"
             :file "/path/to/some.edn"
             :merge [{:datomic {:url "foo.bar"}} 
                     (from-file "/path/to/another.edn")
                     (from-resource "path/within/classpath/to-another.edn")
                     (parse-runtime-args ...)
                     (from-system-props)
                     (from-env)])

richiardiandrea18:08:23

so I have a conf file

tolitius18:08:26

but in most cases you don't have to

richiardiandrea18:08:37

then I do:

(c/load-config :merge [env/defaults
                         {:version (if-let [version (version!)] version "0.0.0")}])

tolitius18:08:38

ok, conf is an edn file?

richiardiandrea19:08:05

so I expected that my conf file could override the stuff in env/defaults

tolitius19:08:16

env/defaults returns you a map with overriding paths?

richiardiandrea19:08:25

every prop matches

richiardiandrea19:08:39

but conf takes precedence on the :merge clause right?

tolitius19:08:02

hm.. not really, here is the order:

1. classpath resource config
2. file on a file system (pointed by a conf system property or by (load-config :file <path>))
3. custom configurations, maps from various sources, etc.
4. System properties
5. ENV variables

richiardiandrea19:08:25

that's why I was saying...read the docs Andrea!

tolitius19:08:02

that's ok, I don't expect people to read it, it just there for my reference to answer questions quickly 🙂

richiardiandrea19:08:06

the README is consistent

tolitius19:08:52

if you still want to override the defaults, you can add a element to the :merge map

tolitius19:08:11

the way I usually do it is to have a file in a classpath, say config.edn

richiardiandrea19:08:14

yeah now it is super clear

richiardiandrea19:08:37

I will do this:

(defn make-config
  "Creates a default configuration map"
  []
  (merge env/defaults
         (c/load-config :merge [{:version (if-let [version (version!)] version "0.0.0")}])))

tolitius19:08:10

then I would have a (say) dev overrides somewhere under dev-resources/dev-overrides.edn, and then I start things with -Dconf=dev-resources/dev-overrides.edn

tolitius19:08:38

then I can just do (load-config)

tolitius19:08:52

but there are many ways to do it of course

richiardiandrea19:08:55

yes, the thing is, I already have that

richiardiandrea19:08:04

I wanted an external file

richiardiandrea19:08:22

and conf it is very convenient

tolitius19:08:28

where would the file live?

tolitius19:08:35

somewhere on that server

tolitius19:08:33

right, so you can just have config.edn in your classpath (which would be read by default), and just use -Dconf=server-path-to/overrides.edn

richiardiandrea19:08:06

yep, the env/defaults thing is a namespace a-la-Luminus for codeful conf

richiardiandrea19:08:28

so it makes sense to merge it first (no priority)

tolitius19:08:31

I usually have things that I always want to override as:

:server {:application {:version "OVERRIDE ME"}
        :http {:port "OVERRIDE ME"
               :max-channel-memory-size 0
               :max-total-memory-size 0
               :http {:request {:max-chunk-size 8192
   ...

richiardiandrea19:08:51

yeah I keep those there but empty

tolitius19:08:13

and then

:server {:application {:version "1.0"}
          :http {:port "4242"}}
in override.edn

richiardiandrea19:08:33

great yes I am doing the same

richiardiandrea19:08:51

the file is convenient because I can just copy the one in resources

tolitius19:08:54

SERVER__APPLICATION__VERSION=1.0

richiardiandrea19:08:02

and launch java with -Dconf=....

tolitius19:08:11

right, whatever works 🙂

richiardiandrea19:08:30

ah ah, the important is to have the choice and cprop gives you plenty

tolitius19:08:22

yea, I am actually experimenting with Vault ( https://github.com/tolitius/gblog ), and going through my thinking phase on having a cprop extension to it

tolitius19:08:01

since ENV and plain files are not really that good for secrets

richiardiandrea19:08:25

oh that's a wonderful tool did not know it (I mean Ghost)!

richiardiandrea19:08:08

yeah encrypted stuff would be great to integrate in cprop, but at least one piece of info has to be clear text on the server I guess

tolitius19:08:20

not really 🙂

tolitius19:08:38

it could be a temp token, that would only work for you and only one time and only for the next 5 seconds

tolitius19:08:00

to fetch creds to the runtime

tolitius19:08:52

i.e. you would run things like:

export ACCESS_TOKEN=$(./tools/vault/wrap-token.sh /secret/postgres); docker-compose up

tolitius19:08:20

where Vault would wrap the location into a token, which you can set a ttl on

tolitius19:08:32

it would only work for /secret/postgres, and only once

richiardiandrea19:08:10

and encrypting of the info is done with a master key before that (sorry dunno how vault works)

richiardiandrea19:08:53

I guess is basically some sort of bitcoin seeded wallet

tolitius19:08:19

right, when you install Vault you get a root token. you don't have to give it out to others, but you can use it to store secrets in Vault. you also can create a token for someone else to store creds to Vault (no need to use the root token). once creds are set / stored, all the apps that need these creds would only need a temp token

tolitius19:08:47

yea, pretty cool

richiardiandrea19:08:39

it is kind of similar to bitcoin really, as long as you don't lose your master key, you can always generate tokens/public keys to decrypt

richiardiandrea19:08:53

I'll have a look

richiardiandrea19:08:01

thanks for sharing!

tolitius19:08:04

sure, always welcome