Open Stack

@ArKady,

My point is exactly the one pointed out by Matt, and he summaries
everything I think about the dashboards usage.
What's the point to multiply dashboards for a solution that's explecting
you to expand it... that's non-sense.

Having multiple dashboard to manage a unique solution is exactly what I
want to avoid for our users as we already experimented that a lot within
our company and that 100% of the time give the death kiss to that solution
as the users want something integrated, even if they're admins or operators.

It would be either illusory or being masochist to think that everyone
involved within an IT Process need to be an engineer or a CLI oriented
profile.

I however do agree with you, tracability need to be done as it is important
to point out what's going on and who did the operation.

My point with this discussion is to have features that are PITA to
manage/operate or which are too obscure within horizon. I spend too much
time within our INI Files or the documentation looking for a specific
option default value. With such option, I would just have to go to the
service, search for the option, reset the custom value to nothing and click
on reload button to this value being used.


Le lun. 18 déc. 2017 à 16:49, Matt Joyce <matt at nycresistor.com> a écrit :

> 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.therond at 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.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.
>>>
>>>
>>>
>>>
>>>
>>
>> _______________________________________________
>> OpenStack-operators mailing list
>> OpenStack-operators at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20171218/2e8e8d33/attachment.html>