Changelog

v0.1.2 - 2026-10-05

  • Purging an avi::Tenant waits, for up to 10 minutes, for the service engines registered in it to lose their connection before removing them. In a cloud in no access mode the controller refuses to delete an engine that is still connected (400 Service Engine connected to controller cannot be deleted with no access mode), and it only notices that the VM behind an engine is gone some time after that VM was deleted. An engine still connected after the wait fails the tenant with a message naming it

v0.1.1 - 2026-09-28

  • The model is now generated in full: the entities no controller schema describes - avi::service_engine::base::{EngineLookup,Registration,InterfaceScope}, avi::vrf_context::base::CloudScope and avi::se_image::ServiceEngineImage - are declared with the module factory in inmanta_plugins/avi/resources.py and emitted by make generate along with the schema-driven ones, so model/base.cf is the only hand-written model file left. Same namespaces, same entities, same attributes and defaults: avi::service_engine::base now lives in model/service_engine/base/_init.cf instead of model/service_engine/base.cf, which changes nothing for a model that imports it

  • avi::service_engine::ServiceEngine now writes the attributes a model sets on a registered engine, which is what the last step of the load-balancer creation needs: se_group_ref="/api/serviceenginegroup?name=<group>" moves the engine from the default group of its cloud into the group of its own service. The engine is replaced as a whole (it has no endpoint for a single field) under the same per-engine lock the interfaces use, and name, data_vnics, mgmt_vnic and resources are never written - AVI derives the name from the engine, and the interfaces have resources of their own. An engine the model sets nothing on still only waits for the engine to register, as before

v0.1.0 - 2026-09-17

  • Purging an avi::Tenant first removes the service engines registered in it. An engine registers itself into the tenant whose token it was given, so nothing guarantees the model holds one for every engine that ended up there - and the controller refuses to delete a tenant that one still refers to (400 Cannot delete Tenant ... is referred by:  <engine>), which no later deploy could recover from either

  • avi::service_engine::Interface is identified by a new required name attribute instead of by its mac_address. A cloud only assigns that address when it creates the port behind the interface, so it could never be part of a resource id; keeping it out of the identity lets it be a reference resolved on the agent - from the port’s own mac_address fact, typically - the way engine_name already could be. It is no longer sent in the body either: it identifies the interface rather than being written to it

  • avi::se_image::ServiceEngineImage reports the version of the image the controller serves - the build of its system image, 31.2.2-9059 - as the controller_version fact. inmanta_plugins.avi.resources.se_image_version(client) reads that version off a controller, for a model that names an uploaded copy of the image after it

  • A reference the controller resolved into its absolute form no longer reports as a change against the name based form a model points at it with: the reads ask the controller for the name of what a reference points at (include_name), and references are compared by that name

  • Removing the last BGP peer of an avi::VrfContext now takes it off the controller: an emptied relation is left out of the exported body, which used to read as a field the model does not manage. Resources declare the paths they own exhaustively through the new prune_when_absent

  • initial release of module