Re: [Openstack-operators] Openstack operational configuration improvement.

[Flint WALRUS]

Thank you very much @Akihiro and @Jeremy

these answers are really useful and constructives.

Akihiro, regarding your two points yes, they for sure will be challenging
and I really plan to work on this feature as a horizon plugin at the
beginning as you mentioned it.

Here what I'm thinking to do to overcome these challenges:

1°/ - Get the information into the keystone catalog that could retrieve
them from the services through a call to the exposed specific APIs
(/vX/service-configs for example).
2°/ - Get each service to expose its configuration values and config
location through a versionned API endpoint (/vX/service-configs url for
example).
3°/ - Horizon retrieve these informations from keystone.

Another solution would be Horizon to retrive these values directly from
each services API, that would however have some impact depending on the
call implementation.

I'm aware that it would imply a lot of work on the openstack services
themself but the plugin could implement a routine that would fill the view
with NaN values and a short informative message within the description
column if it can't grab the values.

Thanks a lot for these informations and insights, I'll work on a PoC and
test it locally, if I come with something usefull I'll show you.

Have a nice day!


Le lun. 18 déc. 2017 à 18:06, Jeremy Stanley  a écrit :

> On 2017-12-19 01:40:50 +0900 (+0900), Akihiro Motoki wrote:
> [...]
> > 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 burgeoning discussions about an etcd backend for oslo.config may
> be relevant to this piece of the problem.
> --
> Jeremy Stanley
> ___
> 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

Re: [Openstack-operators] Openstack operational configuration improvement.

[Jeremy Stanley]

On 2017-12-19 01:40:50 +0900 (+0900), Akihiro Motoki wrote:
[...]
> 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 burgeoning discussions about an etcd backend for oslo.config may
be relevant to this piece of the problem.
-- 
Jeremy Stanley


signature.asc
Description: Digital signature
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] Openstack operational configuration improvement.

[Akihiro Motoki]

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 :
> 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

Re: [Openstack-operators] Openstack operational configuration improvement.

[Flint WALRUS]

@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 <m...@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.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 serv

Re: [Openstack-operators] Openstack operational configuration improvement.

[Matt Joyce]

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

Re: [Openstack-operators] Openstack operational configuration improvement.

[Arkady.Kanevsky]

Flint,
I do support UI method for solution management.
My point is that it is not Horizon one as it is on a different layer.

From: Flint WALRUS [mailto:gael.ther...@gmail.com]
Sent: Monday, December 18, 2017 9:40 AM
To: Kanevsky, Arkady <arkady_kanev...@dell.com>
Cc: openstack-operators@lists.openstack.org
Subject: Re: [Openstack-operators] Openstack operational configuration 
improvement.

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<mailto: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<mailto:gael.ther...@gmail.com>]
Sent: Monday, December 18, 2017 7:29 AM
To: 
openstack-operators@lists.openstack.org<mailto: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

Re: [Openstack-operators] Openstack operational configuration improvement.

[Flint WALRUS]

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

Re: [Openstack-operators] Openstack operational configuration improvement.

[Sławomir Kapłoński]

Hi,

Isn't Fuel or TripleO something what You are looking for?

— 
Best regards
Slawek Kaplonski
sla...@kaplonski.pl



> Wiadomość napisana przez Flint WALRUS  w dniu 
> 18.12.2017, o godz. 14:28:
> 
> 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

Re: [Openstack-operators] Openstack operational configuration improvement.

[Jeremy Stanley]

On 2017-12-18 13:28:46 + (+), Flint WALRUS wrote:
[...]
> 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?

I certainly wouldn't want to discourage discussion among operators
as to what they'd like to see out of any component of OpenStack, but
when the time comes to start discussing the feasibility of
implementation you'll be better off doing so on the
openstack-...@lists.openstack.org mailing list where development of
OpenStack software is more on topic. Add "[horizon]" to the subject
line for more visibility within that team.

You can also sometimes find Horizon team regulars hanging out in the
#openstack-horizon channel on the Freenode IRC network if you need
to bounce ideas off someone in a more synchronous conversation.
-- 
Jeremy Stanley


signature.asc
Description: Digital signature
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

[Openstack-operators] Openstack operational configuration improvement.

[Flint WALRUS]

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