Hello team,
While researching for an operator, piece of code which runs as a container and
launches microservice in correct order to bring up a specific service, I came
across a need to have helm charts/packages be stored and served from a
centralized location. Since I could not find a ready-to-go solution I am
proposing to introduce an internal helm-repository container along with
helm-repository-service and persistent storage.
It should behave something similar to Docker private registry. In this case
operator, can rely on service object to locate helm-repository and fetch
microservice packages it requires to bring up its service.
Here is in general overview of bringing up helm-repository:
1. Init container of helm-repository POD is responsible of initializing and
populating persistent storage with charts/packages.
1.1 Init container retrieves charts/packages bits via: (some ideas,
new/better ideas are welcome). All these methods could be passed as a parameter.
1.1.1 using git clone of kolla-kubernetes
1.1.2 using tar file stored on some internal web server
1.1.3 from the configmap where tar file is attached
1.2 Init container generates required packages information
2. Main container starts serving packages to operators or other entities.
Here is the reason for using persistent storage:
1. In case container gets restarted/killed, when it comes back up it has to use
exactly the same set of packages as before to preserve consistency. It will go
through init process only if persistent storage is empty.
2. Possibility in future to update the repo with new version of packages and
then not going through the replay of all past updates from the original version
baked into the image.
Appreciate your comments suggestions and critic ;-)
Thank you
Serguei
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [email protected]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
