Skip to content
This repository has been archived by the owner on May 4, 2019. It is now read-only.

[RFR] Introduce component inheritance #67

Merged
merged 6 commits into from
Jun 5, 2014
Merged

[RFR] Introduce component inheritance #67

merged 6 commits into from
Jun 5, 2014

Conversation

manuquentin
Copy link
Contributor

applications:
    producer:
        type: python
        volumes:
            .: /app
        after_script: python /app/app.py
        custom:
            pip_modules: [pika==0.9.8]

    worker1:
        after_script: python /app/worker.py
        extends: producer

    worker2:
        after_script: python /app/worker.py
        extends: producer
  • Allows component inheritance
  • Add tests on component inheritance
  • Add a rabbitMQ template
  • Add a python/RabbitMQ example with component inheritance

@Cethy
Copy link

Cethy commented Jun 4, 2014

I would suggest to separate the "blueprints" and the actual applications ; with the example you gave, I guess producer is an application like worker1 & worker2 but it doesn't seems straightforward.

How about a "blueprints" section (like "binaries") ?

applications:
    worker1:
        extends: producer
    worker2:
        extends: producer
blueprints:
    producer:
        type: python
        ...

In the same spirit, how about a "volumes" section ? or even better, some kind of "parameter management" ?

@manuquentin
Copy link
Contributor Author

Thanks for the suggestion.
I think adding a blueprints section will introduce complexity in the configuration file (and the builder).
The idea behind the extends param is to clone properties of an application and override some.

Same for volumes, you are free to extends an application that declare multiple volumes to avoid redeclaration of these volumes

@Cethy
Copy link

Cethy commented Jun 4, 2014

For volumes, the problem is quite different IMHO :
In a web app environment, the volumes are shared between the different apps & frontend. If I move my volume, I must edit every entries.
With the help of extends I will only write 2 "types" (app & front) of docker & extends them on other dockers. But even if it's limited to 2 entries, it is still one too many.

@manuquentin
Copy link
Contributor Author

You're right for volumes. Containers sharing the same set of volumes aren't necessary the same type.
There is no notion of inheritance for 2 different things.

I'll think about a volumes entry and implement it in another PR.

@Cethy
Copy link

Cethy commented Jun 4, 2014

great ! 👍

@manuquentin manuquentin changed the title [WIP] Introduce component inheritance [RFR] Introduce component inheritance Jun 5, 2014
manuquentin added a commit that referenced this pull request Jun 5, 2014
[RFR] Introduce component inheritance
@manuquentin manuquentin merged commit 5fb8073 into master Jun 5, 2014
@manuquentin manuquentin deleted the extends branch June 5, 2014 05:23
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants