Open Stack

On Sun, Apr 9, 2017 at 6:36 PM, Stephen Hindle <shindle at llnw.com> wrote:
> On Fri, Apr 7, 2017 at 3:00 PM, Doug Hellmann <doug at doughellmann.com> wrote:
>>
>> Although I was a proponent of having the reload feature address
>> that issue, I'm not sure the complexity of the current implementation
>> is something we want to hang on to. In the new spec, I propose an
>> alternative treatment, which is to not cache mutable values in the
>> first place so the service never needs to receive a signal to reload.
>> The reload API is retained, and simply discards *everything* and
>> starts the configuration object over as though it was being freshly
>> created. This will be a big change, but the feature is new I think
>> the propose behavior better fits the spirit of the need anyway. Please
>> provide feedback if you think otherwise.
>>
>
> I'm still concerned about how this handles non-OpenStack services.
> Kolla currently provides containers for MySQL, RabbitMQ, Ceph, etc.  I
> agree with Paul Belanger, creating a 'special snowflake' for OpenStack
> config would be bad.  Personally, I agree something like confd could
> be used to keep configs 'out' of the containers, by generating them at
> run time.  This could work for both OS and Non-OS services, giving a
> consistent mechanism.

I still don't see anything wrong that would block us to make OpenStack
services talking to etcd directly, while some non-OpenStack services
wouldn't.
In fact, while oslo.db would get the config from etcd, confd (used by
some non-OpenStack services) would also use etcd backend.

The major thing with confd that I don't like is the fact that it uses
Templates files (like Kolla and some other projects are using). We
don't want to maintain templates files as OpenStack options tend to
change every time.
That's one of the major reasons why we think oslo.db could directly
talk to etcd to store the parameters / values.

>
>
> --
> Stephen Hindle - Senior Systems Engineer
> 480.807.8189 480.807.8189
> www.limelight.com Delivering Faster Better
>
> Join the conversation
>
> at Limelight Connect
>
> --
> The information in this message may be confidential.  It is intended solely
> for
> the addressee(s).  If you are not the intended recipient, any disclosure,
> copying or distribution of the message, or any action or omission taken by
> you
> in reliance on it, is prohibited and may be unlawful.  Please immediately
> contact the sender if you have received this message in error.
>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



-- 
Emilien Macchi