[Bug 39415] New: Make configuration settings accessible through the website

https://bugs.winehq.org/show_bug.cgi?id=39415

Bug ID: 39415
           Summary: Make configuration settings accessible through the
                    website
           Product: Wine-Testbot
           Version: unspecified
          Hardware: x86
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P2
         Component: unknown
          Assignee: [e-mail]
          Reporter: [e-mail]
      Distribution: ---

Currently the way to change a configuration setting is to send a patch to
wine-patches and have Alexandre apply it. This is the case for instance for all
the VM host configuration settings ($MaxRevertingVMs,
$MaxRevertsWhileRunningVMs, etc.), but also $JobPurgeDays, $RegistrationQ, etc.
This is not very practical and prevents experimentation or quickly adjusting
the settings when a problem arises.

Instead these should be stored in a Parameters table and be accessible through
an administrator-only section of the website.

[Bug 39415] Make configuration settings accessible through the website

https://bugs.winehq.org/show_bug.cgi?id=39415

Damian  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |[e-mail]

[Bug 39415] Make configuration settings accessible through the website

[WineHQ Bugzilla]

https://bugs.winehq.org/show_bug.cgi?id=39415

--- Comment #1 from François Gouget  ---
One way to handle this would be to add a table like this:
  PK  Class      # User, VMHost, VM, etc.
  PK  Object     # User name / Hostname / VM name, etc.
  PK  Property   # Name of a property of the above object
      Value      # Value for that property

The point of the Class column is to avoid collisions between the properties of
the w1064 VM and those of a malicious w1064 user: the class would ensure they
resolve to ('VM', 'w1064', ...) and ('User', 'w1064', ...) respectively.

Then the API to access those should provide automatic fallbacks so if a the
SleepAfterRevert property is not specified at the VM-level, either the VM-host
one or the global one is used:

my $Props = GetProperties(['VM', 'w1064'], ['VMHost', 'vm2'], ['Global',
'VMHosts']);
  print $Props->{SleepAfterRevert}, "\n";

Should the need arise for array properties (maybe to store user preferences
like VMs to run the tests on) the convention could be to suffix the property
name with ":array" and then ":N" for each entry (colons would otherwise be
forbidden in property names).

GetProperties() would likely provide access to a singleton object that loads
all of a given object's properties at once and then caches them for a few
seconds so that iterating over VMs (for instance) does not cause the VMHost
properties to be reloaded each time (this assumes the Perl ORM does not provide
such functionality).

Of course a SetProperty() method would update the cache appropriately, but of
course that does not help other processes, hence the short-duration case.

Interestingly this new table would have no link to the other TestBot tables,
making this a good testing ground for Perl ORM tests.

[Bug 39415] Make configuration settings accessible through the website

[WineHQ Bugzilla]

https://bugs.winehq.org/show_bug.cgi?id=39415

--- Comment #2 from François Gouget  ---
The GUI may want to hide the per-User settings:
* Once user settings are implemented they are likely to constitute the bulk of
the Settings table owing to both the number of users and the number of settings
per user, particularly depending on how the user's VM preferences are stored.
* Also the administrator should not need to see a user's preferences.

Besides that, accessing this table's content could work through the regular
'CollectionBlock' GUI (though a GUI allowing editing the table directly would
be more user friendly).