|
|
@ -1,6 +1,29 @@ |
|
|
#!/bin/bash |
|
|
#!/bin/bash |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
## |
|
|
|
|
|
## TODO: |
|
|
|
|
|
## - subordinate container should really be able to modify base image of their master |
|
|
|
|
|
## - this could be done through docker-update |
|
|
|
|
|
## - I'm not happy with the current build using 'build/' directory, this should be |
|
|
|
|
|
## changed to: |
|
|
|
|
|
## - always have a base image (specified in metadata), and always have hooks/install |
|
|
|
|
|
## executed and merge in image (like docker-build-charm). |
|
|
|
|
|
## - container base image is ALWAYS the image of the master container... this brings |
|
|
|
|
|
## questions about a double way to express inheritage (through relations as it is |
|
|
|
|
|
## implemented now, or through this base-image ?) |
|
|
|
|
|
## - the name of the scripts for relation (aka relation_name-relation-joined) is bad as |
|
|
|
|
|
## reading the name in a hooks/ dir, there are no way to know if we are the target or |
|
|
|
|
|
## the base of the relation. |
|
|
|
|
|
## - we could leverage a 'relations/' dir on the root of the charm, with both: |
|
|
|
|
|
## 'relations/provide/relation_name' and 'relations/receive/relation_name' |
|
|
|
|
|
## - a very bad point with the actual naming is that we can't have a providing AND |
|
|
|
|
|
## receiving a relation with same name. |
|
|
|
|
|
## - The cache system should keep md5 of docker-compose and other things between runs |
|
|
|
|
|
## - The cache system should use underlying function that have only arguments inputs. |
|
|
|
|
|
## This will allow to cache completely without issues function in time. |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
#:- |
|
|
#:- |
|
|
. /etc/shlib |
|
|
. /etc/shlib |
|
|
#:- |
|
|
#:- |
|
|
|
