On 30.3.2017 18:02, Bogdan Dobrelya wrote:
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.
That was actually my initial thought as well, but it means more
entanglement between the containers and the bare-metal hosts, and
creates some new issues.
E.g. it makes container image versioning harder. We'd need to implement
additional logic to make sure we use the correct entrypoint version for
a particular container image version (think rolling back to an older
image but still using the newest entrypoint, perhaps those two not being
fully compatible, and having the container crash because of this). This
alone is quite disadvantageous IMO.
Jirka
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
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [email protected]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
