Open Stack

Hi Flint,

I have both hats as an operator of OpenStack and a horizon core.

I understand that GUI support of OpenStack configuration is useful for
some operators. I know several softwares support GUI-based
configurations.

However, I see several challenging points.

First point is how to distribute configuration files configured via
GUI to servers.
Horizon communicates back-end services through REST APIs and is
agnostic of actual server setup.
There is no way for horizon to know how your deployments are. This is
the area that deployment tools (like ansible, tripleo, fuel and so on)
handle.

The second point is the freedom on how configuration files are organized.
We can pass multiple configuration files to individual OpenStack
services, so we cannot assume how configuration files are organized as
upstream.
It also depends on deployment tools.

As the upstream horizon team, horizon provides the plugin mechanism,
so you can start a project as a horizon plugin.
At the moment, the horizon team focuses on supporting OpenStack
so-called "core" services and encourage to implement more GUI supports
as plugins.
You can see many horizon plugins [1] and the configuration support you
propose can be implemented as a horizon plugin.

[1] https://docs.openstack.org/horizon/latest/install/plugin-registry.html

Best Regards,
Akihiro


2017-12-18 22:28 GMT+09:00 Flint WALRUS <gael.therond at gmail.com>:
> Hi everyone, I don't really know if this list is the good one, but I'll have
> my bet on it :D
>
> Here I go.
>
> Since many times now, I'm managing  Openstack platforms, and one things that
> always amazed me is its lack of comprehensive configuration management for
> services within Horizon.
>
> Indeed, you can set and adapt pretty much everything within Horizon or the
> CLI except for the services configuration.
>
> So here is a proposal regarding this issue:
>
> I think of it as a rework of the already existing system information panel
> from the admin dashboard such as:
>
> Within the services tab, each service line would now be a clickable drop
> down containing an additional subarray named configuration and listing the
> whole available configurations options for this service with information
> such as:
> - Current value: default or value. (Dynamically editable by simply clicking
> on it, write the new value on the INI file).
> - Default value: the default sane value. (Not editable default value of the
> option).
> - Reload / Restart button. (a button enforcing the service to reload its
> configuration).
> - Description: None or a short excerpt. (Not editable information about the
> option meaning).
> - Documentation: None or a link to the option documentation. (Not editable).
>
> What do you think of it?
>
> PS: If this discussion should go with the horizon team rather than the
> operational team, could someone help with this one as I didn't find any
> mailing list related endpoint?
>
> Thanks a lot.
>
>
>
> _______________________________________________
> OpenStack-operators mailing list
> OpenStack-operators at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>