Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

  • Dynamic reloading of configuration variables parameters that can be dynamic reloaded.
  • Give priority to scoped overrides of configuration variablesparameters.  Currently, the scopes are Zone, Pod, Cluster, StoragePool, and Account.
  • Allow different components in CloudStack to provide configuration variables parameters without modifying the CloudStack code
  • Easily figure out where the configuration variable parameter was declared and used.

How to Use

Declaring a configuration

...

parameter

cloud-framework-config provides a class, ConfigKey<T>, for configuration variable parameter declaration.  In order to use it, declare it as follows:

...

  • category - A category from which an admin can retrieve related configuration variablesparameters
  • type - Type for the value.  Supported values are Short, Long, Integer, String, Boolean, Date
  • key - Name of the parameter when stored.
  • default - Default value if no override is found.
  • description - A description of what the configuration variable parameter changes and what are the correct values to input.
  • dynamic - Can the configuration value be changed without restarting the server.

...

  • scope - Scope at which overrides can be found for that specific scope.  Currently, the scopes are Zone, Pod, Cluster, StoragePool, and Account.  When a configuration variable parameter has a scope other than Global, override is checked first.  If an override is not found, then the global value is returned.
  • mulitiplier - A convenience value for number valued configuration variables parameter to multiple the set value with this multiplier.  The most useful case for this is if the configurable range is in seconds but actual usage must be in milliseconds.

...

In order to retrieve the value from the configuration variableparameter, perform the following.  Note that if the configuration variable parameter is meant to be used by multiple components, it should probably be declared in a common interface or class.  Note that you should never save the return value if you want to dynamically change if the configurable value is changed.

Code Block
// Use case 1: To retrieve the global value
ManagementHostIPAdr.value();


// Use case 2: To retrieve the variableparameter but first look for the override in zone.  
// Note that this will give an error for this variableparameter as it was not declared as a scoped variableparameter.
ManagementHostIPAdr.valueIn(zoneId);


// Use case 3: To use configuration that's declared by a different component.
public class NotChildOfClusterManager {
    ClusterManager.ManagementHostIPAddr.value();
}


// Use case 4: To use a configuration that you know it's there but you can't compile against.
// I strongly advise against this.  If a developer did not put their configuration variableparameter in
// an interface for you to use, it's best to communicate with that developer and make sure you
// agree on where to place it.
public class NoCompilationAccessToClusterManager {
  @Inject ConfigDepot _depot;
  ConfigKey<?> mgmtAddr = _depot.get("host");
}

...

Code Block
public interface Configurable {

    /**
     * @return The name of the component that provided this configuration
     * variableparameter.  This value is saved in the database so someone can easily
     * identify who provides this variableparameter.
     **/
    String getConfigComponentName();

    /**
     * @return The list of config keys provided by this configuable.
     */
    ConfigKey<?>[] getConfigKeys();
}

...

On startup, ConfigDepotImpl gathers all of the Configurable interfaces and constructs a set of keys.  It checks to see if the key is already in the database.  If not, then it populates the database with the default values.  If a key that is in the database but is no longer found in the key list, the updated field is changed to null.  At which point, an admin can decide to delete the obsolete key.  Going forward, any caching or special implementation will go into ConfigDepotImpl and no other components need to modify the core CloudStack code to add their own configuration variablesparameters.

What to do on CloudStack upgrades?

...