HIL supports a simple extension mechanism, to allow external plugins to implement things we don't want in the HIL core. One obvious example of this is drivers.
Extensions are python modules. The extensions section in hil.cfg
specifies a list of modules to import on startup, for example:
[extensions] hil.ext.driver.switch.dell = hil.ext.driver.switch.complex_vlan = hil.ext.driver.obm.ipmi = some_3rd_party.hil.drivers.obm.robotic_power_button_pusher
If the extension requires any kind of initialization, it may define a function
setup, which will be executed after all extensions have been loaded.
This function must accept arbitrary arguments (for forwards compatibility),
but at present must not rely on the presence or value of any argument.
If the extension needs its own configuration options, it may read them from a section with the same name as the module, e.g.:
[extensions] some_3rd_party.hil.drivers.obm.robotic_power_button_pusher
[some_3rd_party.hil.drivers.obm.robotic_power_button_pusher] push_duration = 3 seconds
Extensions should not make use any part of the HIL source tree that does not explicitly invite it (i.e. everything by default is Private). Components which may be used from extensions will explicitly say so in their documentation, (and describe in detail how they may be used). Extension-approved components currently include:
- Most of hil.network_allocator
- hil.auth
- From hil.model:
- db.Model
- Switch
- The migration framework; see Migrations for an overview.
See the docstrings for each component for details.
Additionally, extensions may add wsgi middleware to the flask
application from their setup function. For example:
app.wsgi_app = my_middleware(app.wsgi_app)
Note that the order in which the setup functions are run is not
defined. As such, if multiple extensions add wsgi middleware the
order in which they are applied is also undefined. Using more than one
such extension is discouraged. An ordering may be defined in the
future.