Agreed on dashboard use. This is a mistake Google made with their GCP platform. They made their gui a nightmarish ux designed to destroy the souls of their users because they expected folks to use the CLIs... and a lot of the time they didn't... because are you are automating an environment priorities sometimes keep you from figuring out the cli / code workflow for a not often used procedure.
The dashboard working well has an enormous impact on early days of adoption before a user has automated many of their workflows, but it also continues to pay dividends years in when some workflows have failed to be automated as priorities shift. Also there is an innate value in helping users visualize their environment in a shared way. A common geometry to how we think of the stack. -Matt On Mon, Dec 18, 2017 at 10:39 AM, Flint WALRUS <gael.ther...@gmail.com> wrote: > 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.kanev...@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.ther...@gmail.com] >> *Sent:* Monday, December 18, 2017 7:29 AM >> *To:* openstack-operators@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. >> >> >> >> >> > > _______________________________________________ > 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
