Differences between revisions 1 and 2
Revision 1 as of 2008-03-08 14:19:52
Size: 2503
Editor: scott
Comment:
Revision 2 as of 2011-08-26 04:10:16
Size: 2503
Editor: localhost
Comment: converted to 1.6 markup
Deletions are marked like this. Additions are marked like this.
Line 11: Line 11:
In practice, unlimited-instance jobs are quite rare and difficult to use since any number can be running at once thus contention of resources and locking become an issue. While the ["Resources"] specification attempts to resolve the locking issues, this would cause new instances to be queued after the active one instead of just re-using the active one. In practice, unlimited-instance jobs are quite rare and difficult to use since any number can be running at once thus contention of resources and locking become an issue. While the [[Resources]] specification attempts to resolve the locking issues, this would cause new instances to be queued after the active one instead of just re-using the active one.

Please check the status of this specification in Launchpad before editing it. If it is Approved, contact the Assignee or another knowledgeable person before making changes.

Summary

Jobs currently fall into two broad types: singletons, where only one instance of the job may be active at any one time; and instance jobs where any number may be active, and all start requests start a new instance. This specification proposes the addition of a third type, jobs where the number of instances is limited by giving each a unique name; only a new name will start a new instance.

Rationale

In practice, unlimited-instance jobs are quite rare and difficult to use since any number can be running at once thus contention of resources and locking become an issue. While the Resources specification attempts to resolve the locking issues, this would cause new instances to be queued after the active one instead of just re-using the active one.

Use cases

  • The getty job must have one instance running for each virtual and serial console; each should respawn and restart individually.

  • The apache job must normally only have one instance running, but if an alternate config file is specified, that can specify different ports or IP addresses so multiple instances with different configurations are permitted.

Scope

This scope of this specification is limited to the addition of an intermediate instance limitation between singleton and unlimited; no other issues are addressed.

Design

  • Instances shall be limited by a unique name assigned to each.
  • The name pattern shall be specified by an optional argument to the instance stanza:

    instance ...
  • When no argument is present, the instances are unlimited.
  • The instance name itself shall be created by expanding variable references in the configured name pattern:
    instance $TTY
    instance $CONFFILE
  • Only one instance of any name may be active at one time. Should the start request generate an instance name that is already active, it will be ignored if the instance goal is start or that instance will be restarted if it is stop.

Implementation

Data preservation and migration

These changes are backwards compatible with the previous behaviour, since they only add new functionality.


NamedInstances (last edited 2011-08-26 04:10:16 by localhost)