Configuration of plugins

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

Configuration of plugins

grampajohn
Administrator

The Power TAC server is a plugin system. The original idea for game configuration was that the Competition instance would contain all the parameters for the game. This won't work, because until you know which plugins are being used, you cannot know the full set of configurable parameters. The Household Customer model Antonios is building takes an extensive configuration file, not just a few parameters. This will be the case for th GenCo model as well, because you need to configure which individual genco models exist, and each has some parameters like cost and capacity.

Configuration data is needed in four contexts that I can think of:

  1. The set of configurable parameters must be accessible somehow for game setup.
  2. Configuration data is obviously needed to configure the server prior to the start of a game. In this context, there is no particular need to have
  3. Some subset of configuration data must be accessible to broker agents during the game, presumably as part of the initialization protocol.
  4. It must be recorded as part of the game setup for postgame analysis. It will do no good to run games and gather data if we don't know how the server was configured.

Contexts 1 and 4 would be served by simple metadata files that are bundled up with the game logs when a game completes. Only context 3 requires an internal representation of configuration data, so that it may be communicated to brokers. Other configuration data is purposely not available directly to brokers -- for example, the exact setup of customer models is not available. Instead, some statistical aggregate supply-demand data can be produced by running the models ahead of time.

So here's an initial proposal on configuration:

  • Every configurable plugin must document how configuration data is created and stored, and exactly what data is to be communicated to brokers.
  • At initialization time, after actually configuring a plugin, the data to be communicated to brokers is packaged as an appropriate data structure (a map or tree, for example), and attached to the Competition instance as an entry in the parameterMap, keyed by the plugin name. This may require a strict naming convention for plugin names and parameters to brokers can interpret them correctly.
  • Some mechanism needs to be invented to communicate to the CompetitionControlService which files must be bundled up and stored as part of the game record at the end of a game. Probably we can just add a registration method for this.

Please add your thoughts so we can finalize the code and process quickly. Thanks.

John

Reply | Threaded
Open this post in threaded view
|

Re: Configuration of plugins

ddauer
On Sat, Apr 9, 2011 at 9:21 PM, grampajohn [via Power TAC Developers] <[hidden email]> wrote:

So here's an initial proposal on configuration:

  • Every configurable plugin must document how configuration data is created and stored, and exactly what data is to be communicated to brokers.
  • At initialization time, after actually configuring a plugin, the data to be communicated to brokers is packaged as an appropriate data structure (a map or tree, for example), and attached to the Competition instance as an entry in the parameterMap, keyed by the plugin name. This may require a strict naming convention for plugin names and parameters to brokers can interpret them correctly.
  • Some mechanism needs to be invented to communicate to the CompetitionControlService which files must be bundled up and stored as part of the game record at the end of a game. Probably we can just add a registration method for this.

This sounds like it could be done easily by having every plugin implement a "PowerTacPlugin" interface with 
- configDataForBrokers() : Map
- competitionCompletionFilePaths: List
...
which the CompetitionControlService would call when necessary. So there would be no need for registrations by plugins with the CompetitionControlService. Plugins that would not have anything to save or share with brokers would just return null.

David
Reply | Threaded
Open this post in threaded view
|

Re: Configuration of plugins

grampajohn
Administrator
ddauer wrote
This sounds like it could be done easily by having every plugin implement a
"PowerTacPlugin" interface with
- configDataForBrokers() : Map
- competitionCompletionFilePaths: List
...
which the CompetitionControlService would call when necessary. So there
would be no need for registrations by plugins with the
CompetitionControlService. Plugins that would not have anything to save or
share with brokers would just return null.
Interesting idea. This assumes that CompetitionControlService can get the list of plugins somewhere, right? I have not yet discovered this feature of Grails. Shall I create an issue and assign it to you, at least for the CCS portion and perhaps a simple example?

Thanks -

John
Reply | Threaded
Open this post in threaded view
|

Re: Configuration of plugins

ddauer
Interesting idea. This assumes that CompetitionControlService can get the list of plugins somewhere, right? I have not yet discovered this feature of Grails. Shall I create an issue and assign it to you, at least for the CCS portion and perhaps a simple example? 

Yes, this is possible and I can take care of it up until the point at which every plugin actually needs to decide what data to return.

David 
Reply | Threaded
Open this post in threaded view
|

Re: Configuration of plugins

grampajohn
Administrator

Issue #160 is completed. Here's how you configure a plugin:

  1. In grails-app/conf/XxBootStrap.groovy, create an instance of org.powertac.common.PluginConfig.
  2. Set the roleName property to the role your plugin plays in the simulation. For example, the accounting service is called 'AccountingService' and the wholesale market is called 'WholesaleMarket' regardless of the market structure. This naming scheme needs to be formalized and documented somewhere.
  3. If there are or could be multiple implementations of the role for your plugin (this could be the case with customer models, for example), then set the name property to a plugin-specific name to distinguish it from other plugins having the same roleName.
  4. Set the configuration property to a map of attribute:value pairs that represent your parameter settings. Note that both attributes and values must be strings, because that is what GORM will accept.
  5. Save your PluginConfig instance.
  6. In your implementation, read parameters from the PluginConfig. It's a good idea to use property methods for this to avoid embedding dependence on the structure of the map all over your code. There are good examples of this in TariffMarketService and AccountingService.

At startup, brokers will receive a Competition instance containing all the PluginConfig instances that have been created. For each one, they can see the roleName, the name (which may be blank), and the configuration map.

There's a worked-out example of all this in powertac-accounting-service. See conf/AccountingServiceBootStrap.groovy to see how the PluginConfig instances are created. See AccountingService and TariffMarketService to see how parameters are extracted and used in the code. See AccountingServiceTests and TariffMarketServiceTests for examples of setting and testing parameters using this scheme.

Enjoy!

John

Reply | Threaded
Open this post in threaded view
|

Re: Configuration of plugins

chris.flath
Just referencing your latest Issue to this thread:
https://github.com/powertac/powertac-server/issues/189