Bug 863193

alon - i remember we discussed this, but not the conclusion?

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.

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.

alon - you are describing an engine-config tool in comment 2.
is this on top of the SDK/API? part of the current CLI?

(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.

(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.

(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?

(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.

nit: version had a period character in it. I'd go with key:version if this approach is taken to avoid period being overloaded.

(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.. :)

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.

(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)

Closing old bugs. If this issue is still relevant/important in current version, please re-open the bug.

Alon, why was the RFE re-opened?

(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.

(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.