Bug 863193 - [RFE] Expose configuration values over API/SDK/CLI
[RFE] Expose configuration values over API/SDK/CLI
Status: CLOSED WONTFIX
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: RFEs (Show other bugs)
3.1.0
Unspecified Unspecified
unspecified Severity low
: ---
: ---
Assigned To: Scott Herold
yeylon@redhat.com
infra
: FutureFeature, Reopened
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-10-04 12:01 EDT by Stephen Gordon
Modified: 2016-04-18 02:58 EDT (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2015-11-22 03:22:15 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: Infra
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
sherold: Triaged+


Attachments (Terms of Use)

  None (edit)
Description Stephen Gordon 2012-10-04 12:01:35 EDT
Description of problem:

It would be useful to allow at least read only access to configuration values to clients accessing the system via API/SDK/CLI. Write access, assuming proper access filtering, should also be considered though.

Obviously clients running *on* the RHEV-M have the ability to run rhevm-config out of process to retrieve this information as a workaround, but this doesn't help remote clients.
Comment 1 Itamar Heim 2012-10-04 16:18:50 EDT
alon - i remember we discussed this, but not the conclusion?
Comment 2 Alon Bar-Lev 2012-10-04 16:45:19 EDT
Yes.

I had this in the TODO... :)

VIEWS

1. Non-persistent standard configuration.

2. Persistent standard configuration.

3. None-persistent internal configuration.

4. Persistent internal configuration.

ACTIONS

Get
Set (cluster)
Revert to default (cluster)

if cluster is not supported, we need "Commit" and store changes in session. But I think rest supports this properly.

TYPES

Standard configuration:

What we currently hold in ovirt-engine property file. These are exposed to users.

Internal configuration:

This is a view for all configuration parameters, can be accessed via (example): 

 engine-config --internal ...

It is required for GSS support for parameters which are not exposed.

PERSISTENCE

I don't think it is a must to provide persistence, as a tool can be used to access the database directly. But it would be nice.

CMDLINE

usage: engine-config
    [--scope=persist|nonpersist|all]
    [--internal]
    [--list]
    [--get variable]
    [--get variable]
    [--get variable]
    [--set variable[.version]=value]
    [--set variable[.version]=value]
    [--set variable[.version]=value]
    [--setdef variable[.version]=value]
    [--setdef variable[.version]=value]
    [--setdef variable[.version]=value]

if version is not specified default is XXXX.

get command will output values to stdout in the format:

    variable.version=value

set/setdef commands will be done within single transaction (cluster).

list will output variables to stdout in the format:

    variable.version

FUTURE

We probably need set from file/stdin to allow complex values, such as iptables rules.
Comment 3 Itamar Heim 2012-10-05 10:51:31 EDT
please note the config values are not considered a stable API, and may change between versions.
also note ConfigValues are the backend ones, some allowd to be configured by config tool and some considerd internal ones.

there is also ConfigurationValues, which contains only the enums we allowed clients to read from the engine (for admin/user portal).

so need to rethink these semantics for the API (maybe user level api only provides ConfigurationValues and admin api all the non internal ConfigValues), etc.
Comment 4 Itamar Heim 2012-10-05 10:52:58 EDT
alon - you are describing an engine-config tool in comment 2.
is this on top of the SDK/API? part of the current CLI?
Comment 5 Stephen Gordon 2012-10-05 10:57:27 EDT
(In reply to comment #3)
> please note the config values are not considered a stable API, and may
> change between versions.

Right, I was thinking/expecting that we might offer a "config" collection containing "key" resources or something like that. The API schema shouldn't be tied to whatever key/value pairs happen to be supported on a given version - but if for some reason I want to tie my client script to the use of a given config value I should be able to.
Comment 6 Alon Bar-Lev 2012-10-05 10:58:33 EDT
(In reply to comment #4)
> alon - you are describing an engine-config tool in comment 2.
> is this on top of the SDK/API? part of the current CLI?

I described the SDK/API of the engine.
If we have this SDK/API there is no reason not to use it in engine-config utility, and drop the proprietary interface.
Comment 7 Alon Bar-Lev 2012-10-05 11:00:40 EDT
(In reply to comment #5)
> (In reply to comment #3)
> > please note the config values are not considered a stable API, and may
> > change between versions.
> 
> Right, I was thinking/expecting that we might offer a "config" collection
> containing "key" resources or something like that. The API schema shouldn't
> be tied to whatever key/value pairs happen to be supported on a given
> version - but if for some reason I want to tie my client script to the use
> of a given config value I should be able to.

I am not following you.

The "config" model is key.version = value search path is key.version and if not found key.DEFAULT_VERSION.

How come you have an API which is disconnected from the model?
Comment 8 Stephen Gordon 2012-10-07 19:35:11 EDT
(In reply to comment #7)
> 
> I am not following you.
> 
> The "config" model is key.version = value search path is key.version and if
> not found key.DEFAULT_VERSION.
>
> How come you have an API which is disconnected from the model?

That's arguably not how we expose it to users though. Users don't set:

rhevm-config -s key.version=value

They set:

rhevm-config -s key=value [--cver=version]

Ultimately how you choose to represent value/version in the API is completely up to engineering, I was simply commenting on what I expect at the top level as a user based on the way we interact with the existing interface to the configuration.
Comment 9 Itamar Heim 2012-10-08 02:11:21 EDT
nit: version had a period character in it. I'd go with key:version if this approach is taken to avoid period being overloaded.
Comment 10 Alon Bar-Lev 2012-10-08 03:35:24 EDT
(In reply to comment #8)
> (In reply to comment #7)
> That's arguably not how we expose it to users though. Users don't set:
> 
> rhevm-config -s key.version=value
> 
> They set:
> 
> rhevm-config -s key=value [--cver=version]
> 

I think that using an suffix to parameter for multi value key is better than adding parameters or API fields.

So I think, it is much easier/friendly to provide a user interface of:

engine-config -s key=value
engine-config -s key.version=value

Or... ':' for that matter, or better '@'... key@version.. :)
Comment 11 Stephen Gordon 2012-10-09 09:13:29 EDT
Either way we're going to be adding API fields though if we process this RFE, as these keys/versions/values are not exposed at all currently. That is what this request is for. I'd really see Michael's input here on how this could/should be represented in a RESTful way.
Comment 12 Michael Pasternak 2013-02-03 04:27:46 EST
(In reply to comment #11)
> Either way we're going to be adding API fields though if we process this
> RFE, as these keys/versions/values are not exposed at all currently. That is
> what this request is for. I'd really see Michael's input here on how this
> could/should be represented in a RESTful way.

Simon,

I have RFE on this targeted for 3.3 (Bug 838270),

- RFE has API modelling 
- /config. collection will be exposed in a same way (as any other collection)
  in SDKs/CLI
- it will have 'reload' action to refresh engine cache
- to implement this RFE in a bidirectional manner, i need the ability
  to update vdc_options table via backend
- open question is: do we support this for non-admin users

(btw, i agree with Alon that once we expose this via api/sdk/cli there is
no need for extra tool to manage config, but if it's tend to be used in engine-config, e.g before engine is running, not api nor sdk/cli will help, as backend
yet not running and engine-config should be able to configure the backend on DB level)
Comment 13 Itamar Heim 2014-06-16 10:56:31 EDT
Closing old bugs. If this issue is still relevant/important in current version, please re-open the bug.
Comment 14 Yaniv Kaul 2015-11-10 11:12:35 EST
Alon, why was the RFE re-opened?
Comment 15 Alon Bar-Lev 2015-11-10 11:23:11 EST
(In reply to Yaniv Kaul from comment #14)
> Alon, why was the RFE re-opened?

because requested functionality is not provided, if you do not want to provide this close it individually not during mass cleanup.
Comment 16 Yaniv Kaul 2015-11-22 03:22:15 EST
(In reply to Alon Bar-Lev from comment #15)
> (In reply to Yaniv Kaul from comment #14)
> > Alon, why was the RFE re-opened?
> 
> because requested functionality is not provided, if you do not want to
> provide this close it individually not during mass cleanup.

Closing for now - there is no demand from customer for this and I suspect we won't get to do it.

Note You need to log in before you can comment on or make changes to this bug.