On 30.03.2017 15:40, Jiří Stránský wrote: > > What might be interesting is solving the keystone init within containers > along with our container entrypoint situation. We've talked earlier that > we may have to build our custom entrypoints into the images as we > sometimes need to do things that the current entrypoints don't seem fit > for, or don't give us enough control over what happens. This single > optimized python script for endpoint config you mentioned could be one > of such in-image entrypoint scripts. We could build multiple different
I'm concerned of having entry points in-image. Could it be mounted as a hostpath instead, then executed? Custom entry-points could replace existing ones this way. This would allow keep kolla or other images clean from side changes. > scripts like this into a single image and select the right one when > starting the container (defaulting to a script that handles the usual We could use a clean container and mount in that we need. Those entry points looks similar to heat agent hooks, right? I think they should be packaged as a separate artifacts. > "worker" case, in this case Keystone API). > > This gets somewhat similar to the os-cloud-config usecase, but even if > we wanted a separate repo, or even a RPM for these, i suppose it would > be cleaner to just start from scratch rather than repurpose > os-cloud-config. > > Jirka -- Best regards, Bogdan Dobrelya, Irc #bogdando __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev