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

[David Caro]

On 06/06 07:58, Jan Lieskovsky wrote:
> 
> 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.


Great explanation Jan :)

There are actually two different issues here:

* Using docker containers on lago
* Using docker-compose on lago

I think that we should focus on the first one for now, on getting single docker
containers running on lago environments (that can be done using
VMProviderPlugin). Imo that should be done in a separated python package and
rpm (python-lago-docker or similar, not really relevant the name) to allow
installing it as an extension and not as a requirement so people don't need
docker to run non-docker lago envs.

Once we have those docker providied 'vms' I think that the better approach on
integrating with docker-compose would be using it as a step on preparing the
actual env, and importing it into the lago env (that means running
docker-compose as a step to initialize the env). Not going into details now on
how to do so though (how to handle networks, how to handle deploys...).

> 
> 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.
> _______________________________________________
> lago-devel mailing list
> lago-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/lago-devel

-- 
David Caro

Red Hat S.L.
Continuous Integration Engineer - EMEA ENG Virtualization R&D

Tel.: +420 532 294 605
Email: dcaro at redhat.com
IRC: dcaro|dcaroest@{freenode|oftc|redhat}
Web: www.redhat.com
RHT Global #: 82-62605
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: not available
URL: <http://lists.ovirt.org/pipermail/lago-devel/attachments/20160608/6cc9ce1b/attachment-0001.sig>