[openstack-dev] [tripleo] os-cloud-config retirement
jistr at redhat.com
Thu Mar 30 16:35:31 UTC 2017
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.
>> 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
More information about the OpenStack-dev