search

kfatehi / ydm

yet another Docker management tool
ISC License
9 stars 3 forks source link

simpler definition of drops #13

Closed jaredly closed 10 years ago

jaredly commented 10 years ago

It would be really cool if a drop definition could just be JSON, with common necessary logic abstracted out. Is that likely to be possible? And then more complex drops could you raw js.

jaredly commented 10 years ago

for example, configuration for fig can be as simple as

gitlab:
  image:  sameersbn/gitlab:latest
  links:
   - redis:redisio
  ports:
   - "80:80"
   - "10022:22"
redis:
  image: sameersbn/redis:latest
kfatehi commented 10 years ago

agreed, and i think it is possible, as long as good helpers are written. for example this method https://github.com/keyvanfatehi/dew/blob/master/drops/postgresql.js#L16 tailUntilMatch() would be a very common pattern for many images and could be turned into JSON probably -- but code's so much better suited for it I think ? needs more eyes and experiences i guess.

kfatehi commented 10 years ago

my message went through before i saw you post about fig.

something about fig bothers me... it seems to take an overly simplistic view of the docker ecosystem -- it doesn't seem to take into account the fact that many images are reporting various pieces of information in different ways or requiring various inputs in different ways... different output methods, different input methods, e.g. thru logs, envvars, link-assumed envvars, expected files in volumes, command line options, auto-generated port numbers and ip addresses, post-install configuration introspection etc. fig is not powerful enough to enable a person to handle these scenarios.

that said, i can see something like fig where we're passing in methods and arguments and gathering callback data ... then you just write the method on Scope... but this needs to be catalyzed from more experience. i dont think its important to become "more like fig", rather i think we should just allow passing in json as a config like you said in #12 and allow the drop definition itself to be as complex as necessary.

kfatehi commented 10 years ago

closing because this is a long-term discussion and aspiration rather than an actual problem preventing functionality. ydm is designed less to provide a DSL or config format, but more for allowing one to glue docker stuff together through source code. for something to perhaps aspire to, where it's still source code but a very focused DSL has been baked, check http://www.terraform.io/