Open Stack

Hi arkady,

Ok understood your point.

However, as an operator and administrator of a really large deployment I
disagree with this statement as a lot of our company's admins and operators
indeed rely a lot on the dashboard rather than the CLI for a lot of daily
tasks.

Not everyone is willing to goes with the CLI each time it need to perform
some relatively short tasks.
About the TripleO UI and configuration management, tracability could
definitely be an addition to the array with a column resuming at least the
three last modifications.

Even if the foundation is providing deployment guidelines and reference
designs it shouldn't be something enforced as every users will have for
sure different use case.

Anyway, thanks everyone for your answers, that's really interesting to get
your insights.

Le lun. 18 déc. 2017 à 16:20, <Arkady.Kanevsky at dell.com> a écrit :

> Flint,
>
> Horizon is targeted to a user not administrator/operator.
>
> The closest we have is TripleO UI .
>
> Whatever change in any node configuration from OpenStack down to OS to HW
> need to be recorded in whatever method used to set openstack in order to be
> able to handle upgrade.
>
> Thanks,
>
> Arkady
>
>
>
> *From:* Flint WALRUS [mailto:gael.therond at gmail.com]
> *Sent:* Monday, December 18, 2017 7:29 AM
> *To:* openstack-operators at lists.openstack.org
> *Subject:* [Openstack-operators] Openstack operational configuration
> improvement.
>
>
>
> 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.
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20171218/26e4d9aa/attachment.html>