Currently, the cloudman chart simply reuses the cloudlaunch chart and overrides the container names etc as required, as cloudlaunch and cloudman are both Django apps with almost identical setups.
This leads to limitations. For example, cloudman has its own configmaps, and when these configmaps are changed the cloudman chart's deployment manifest should have a checksum of the configmap. However, there's no way to do this with the chart now, as the cloudlaunch chart cannot reference variables belonging to the cloudman chart, and therefore, cannot store a hash of cloudman's configmaps.
What we probably need is a Django library chart that both apps can use, and to cleanly separate the two.
Currently, the cloudman chart simply reuses the cloudlaunch chart and overrides the container names etc as required, as cloudlaunch and cloudman are both Django apps with almost identical setups.
This leads to limitations. For example, cloudman has its own configmaps, and when these configmaps are changed the cloudman chart's deployment manifest should have a checksum of the configmap. However, there's no way to do this with the chart now, as the cloudlaunch chart cannot reference variables belonging to the cloudman chart, and therefore, cannot store a hash of cloudman's configmaps.
What we probably need is a Django library chart that both apps can use, and to cleanly separate the two.