Add Bulk create and delete operation support by gmicol · Pull Request #223 · CiscoDevNet/ansible-nd

gmicol · 2026-04-08T04:26:10Z

Summary of Changes (backwards compatible with existing modules)

Introduced optional bulk operation support across three layers:

1. Orchestrator Layer (`NDBaseOrchestrator`)

Added supports_bulk_create / supports_bulk_delete class variable flags (default False)
Added create_bulk / delete_bulk methods guarded by a requires_bulk_support decorator — calling them on an unsupported orchestrator raises AttributeError
Added create_bulk_endpoint / delete_bulk_endpoint as conditionally required fields — validated at instantiation via @model_validator, only required when their respective flag is True
Subclasses opt-in by setting the flag and defining the endpoint:

class MyOrchestrator(NDBaseOrchestrator[MyModel]):
    supports_bulk_create: ClassVar[bool] = True
    create_bulk_endpoint = EpMyModelBulkPost

2. Collection Layer (`NDConfigCollection`)

Added add_many() / delete_many() to support batch mutations
delete_many() performs a single index rebuild instead of one per deletion, reducing complexity from O(D×N) to O(N)

3. State Machine Layer (`NDStateMachine`)

Adopted a categorize-then-execute pattern: items are first classified (create/update/delete), then executed in batch
When bulk is supported → single API call for all creates/deletes
When bulk is not supported → falls back to individual API calls transparently
self.sent tracking deferred until after successful API execution to ensure correctness

Bulk support is fully opt-in — existing orchestrators require zero changes.

…g config

…ucture (CiscoDevNet#185)

… Nexus Dashboard v4.1.0 and higher.

…cal_user.

…nherited from future class models. Modify class models for local_user.

…e.py based on comments. Add a get method and get_identifier_value function to NDBaseModel.

…tion of core design adding new methods which will be used in NDConfigCollection and NDNetworkResourceModule classes as well as basic error handling and simple docstrings.

…ign changing existing methods and adding new ones which will be used in NDNetworkResourceModule class as well as basic error handling and simple docstrings.

…of core design changing existing methods and adding new ones which will be used in future as a based for ND network resource modules as well as basic error handling and simple docstrings.

…anges added to NDNetworkResourceModule.

…s for orchestrating crud api operations with model instances and endpoints.

… built-in functionalities. Slightly modify models/base.py to enforce identifiers definitions in NDBaseModel subclasses. Added multiple notes to assert next steps.

…rt endpoints and Pydantic models modification (works for merge and replace states). Add comments for next steps.

…/base.py.

…nts and changes to models/local_user.py and api_endpoints/base.py

…ons methods that work for single_identifier strategy (meant to be overridden if needed).

…or NDNestedModel. Add types.file. Various Renaming and small Modifications across the repo. WIP.

…i_endpoints. Adapt api_endpoints, models, orchestrators accordingly. Integration Tests passing for nd_local_user module. Still WIP.

…ome sanity issues.

…teration of (Mock Pydantic objects/methods) to pass sanity checks for Pydantic importation.

…n issues.

…y issues.

…accordingly

…NDStateMachineand add custom Exception for it in common/exceptions dir. Set json mode for to_diff_dict method in NDBaseModel.

… Add Exception for bulk operations.

shrsr

LGTM

mikewiebe · 2026-04-08T15:28:54Z

@gmicol Are there any changes required to modules that are using this infrastructure currently without bulk APIs? Is it backwards compatible?

gmicol · 2026-04-08T16:15:47Z

@mikewiebe there is no change needed to modules that are using this infrastructure currently without bulk APIs. I made sure it was backwards compatible.

allenrobel

Similar to @mikewiebe, would be good for reviewers if there were a more detailed description of the changes and design decisions in the PR.

allenrobel · 2026-04-08T20:18:48Z

plugins/module_utils/orchestrators/base.py

+
+    @requires_bulk_support("supports_bulk_create")
+    def create_bulk(self, model_instances: List[ModelType], **kwargs) -> ResponseType:
+        pass


Since subclasses are expected to implement these, should we consider raising NotImplementedError rather than pass for create_bulk and delete_bulk? This way, if they are called, but not implemented, we'll catch it right away.

That's a great idea! I will update these methods

allenrobel · 2026-04-08T20:29:25Z