On Mon, Jun 12, 2017 at 8:02 AM, Jiří Stránský <ji...@redhat.com> wrote: > On 9.6.2017 18:51, Flavio Percoco wrote: >> >> A-ha, ok! I figured this was another option. In this case I guess we would >> have 2 options: >> >> 1. Run confd + openstack service in side the container. My concern in this >> case >> would be that we'd have to run 2 services inside the container and >> structure >> things in a way we can monitor both services and make sure they are both >> running. Nothing impossible but one more thing to do. > > > I see several cons with this option: > > * Even if we do this in a sidecar container like Bogdan mentioned (which is > better than running 2 "top-level" processes in a single container IMO), we > still have to figure out when to restart the main service, IIUC. I see confd > in daemon mode listens on the backend change and updates the conf files, but > i can't find a mention that it would be able to restart services. Even if we > implemented this auto-restarting in OpenStack services, we need to deal with > services like MariaDB, Redis, ..., so additional wrappers might be needed to > make this a generic solution. > > * Assuming we've solved the above, if we push a config change to etcd, all > services get restarted at roughly the same time, possibly creating downtime > or capacity issues.
I'm not sure galera1 container would share the same namespace for the key/values of galera2 container (example); I think we would separate namespaces by container names or something unique. > * It complicates the reasoning about container lifecycle, as we have to > start distinguishing between changes that don't require a new container > (config change only) vs. changes which do require it (image content change). > Mutable container config also hides this lifecycle from the operator -- the > container changes on the inside without COE knowing about it, so any > operator's queries to COE would look like no changes happened. > > I think ideally container config would be immutable, and every time we want > to change anything, we'd do that via a roll out of a new set of containers. > This way we have a single way of making changes to reason about, and when > we're doing rolling updates, it shouldn't result in a downtime or tangible > performance drop. (Not talking about migrating to a new major OpenStack > release, which will still remain a special case in foreseeable future.) > >> >> 2. Run confd `-onetime` and then run the openstack service. > > > This sounds simpler both in terms of reasoning and technical complexity, so > if we go with confd, i'd lean towards this option. We'd have to > rolling-replace the containers from outside, but that's what k8s can take > care of, and at least the operator can see what's happening on high level. > > The issues that Michał mentioned earlier still remain to be solved -- config > versioning ("accidentally" picking up latest config), and how to supply > config elements that differ per host. > > Also, it's probably worth diving a bit deeper into comparing `confd > -onetime` and ConfigMaps... > > > Jirka > >> >> >> Either would work but #2 means we won't have config files monitored and >> the >> container would have to be restarted to update the config files. >> >> Thanks, Doug. >> Flavio >> >> >> >> __________________________________________________________________________ >> 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 >> > > > __________________________________________________________________________ > 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 -- Emilien Macchi __________________________________________________________________________ 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