[lago-devel] [Request for feedback] Adding [Docker] container support to Lago

Jan Lieskovsky jlieskov at redhat.com
Mon Jun 6 11:58:35 UTC 2016


Hello folks,

  since there's motivation Lago to support containers too
(https://github.com/lago-project/lago/issues/149) investigated
the possible ways how this could be implemented.

  Created a WIP PR:
  [1] https://github.com/lago-project/lago/pull/276

but would appreciate a wider feedback from the list prior continuing on that one.

Basically I see three possibilities how [Docker] container support for
Lago could be implemented:

Approach 1)
- Allow Lago container yaml / json init file in "docker-compose.yml" format
- Use available "docker-compose" rpm to perform the underlying actions (IOW
  lago commands would be just wrappers around docker-compose use. E.g.
  lago start == docker-compose up
  lago stop  == docker-compose down)

  As a part of this I have added "prefix-provider" support to lago (first commit
  of [1]). The intention is to define new docker-prefix for lago, which would
  wrap use of docker-compose,

  Advantage: Should be easy to implement
  Disadvantage: Dependency on external docker-compose RPM, which at the moment
                in F22 doesn't support v2 of docker-compose YAML files yet

Approach 2)
- allow "docker-compose.yml" as init json/yaml file for lago container configuration,
- instead of using "docker-compose" create own docker lago vm provider / plugin (using
  python-docker-py implementation to access docker service),

  As part of this I have implemented support for local docker container based provider
  into Lago (commit 2 of [1]).

  Advantage: No dependency on external docker-compose RPM
  Disadvantate: * The need to write own docker-compose.yml file parser (AFAIK
                python-dockerfile-parse doesn't support parsing them [yet)
                * Basically we would duplicate the effort the docker-compose tool
                is doing right now

Approach 3)
- don't allow docker-compose.yml as Lago container json/yml file,
- use rather format instead

  Advantage: No need for docker-compose.yml parser. We can define custom format,
             easily to be parsable.
  Disadvantage: Divergence from commonly used docker-compose.yml files (UX would
             differ as users would need to get accustomed to different format of
             configuration file)

The question is obvious -- can you hopefully provide comments / opinion, which
approach of the above do you like best and why? If having yet another one from
the above ones, please share.

Thank you for your opinions in advance.

Regards, Jan
--
Jan iankko Lieskovsky

P.S.: Having agreed on an approach how this should be implemented will help us
      with adding vagrant support to lago too.



More information about the lago-devel mailing list