Explicit reactive enforcement


Enable policy writers to describe conditions under which Congress should execute specific actions, e.g. when a network is connected to a VM that contains a virus, disconnect it from the internet.

Problem description

Currently Congress takes no direct actions to help a cloud obey the policy that governs it. Today Congress can identify violations of policy but it cannot correct them.

Proposed change

This change enables policy writers to include policy snippets such as the one below to encode instructions for how Congress ought to react to changes in the cloud. It enables the policy writer to dictate that Congress must execute certain actions under certain conditions.

// disconnect a VM from the network whenever it is infected by a virus:

execute[disconnectNetwork(vm, network=net)] :-
  nova:network(vm, net)


This same kind of functionality could be written in a traditional programming language such as Python, instead of encoded as policy. But the benefit of doing it as policy is that we can build analysis tools that help policy authors understand if they have created infinite loops and other undesirable featues.


See example above.

Policy Actions

The purpose of this blueprint is to implement a form of reactive enforcement.

Data Sources


Data model impact


REST API impact

None. This functionality is leveraged by writing policy statements, which the existing API already handles properly.

Security impact

One potential security impact is that Congress typically runs as an administrator and thus all the actions that Congress executes will be as an administrator as well. Thus for the first time a security breach into Congress means a security breach into all of the services that Congress is permitted to execute actions on. Though in OpenStack, a breach of security for Congress means a breach of Keystone, which would still give administrative rights to the other OpenStack services anyway.

Notifications impact


Other end user impact


Performance impact

None for this spec; other, dependent specs have performance impacts.

Other deployer impact


Developer impact




Primary assignee:

<launchpad-id or None>

Other contributors:

<launchpad-id or None>

Work items

  • Modify trigger framework to operate on modal operators directly, e.g. so that we can register a trigger whenever execute[x] changes.

  • Set up a trigger on execute[x]. When that trigger fires, it invokes the action on the appropriate ExecutionDriver.


  • modal-operators-for-policy: enable execute[] syntax

  • policy-triggers: initial version of trigger framework

  • action-execution-interface: add executor driver concept to Congress


This change will require unit tests for the enhanced trigger framework.

It should include tempest tests to test end-to-end functionality.

Documentation impact

This will require a new documentation section for reactive enforcement.