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.ther...@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@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators > _______________________________________________ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
