OV SPT sync

[RaviAnushwar]

Hello,

We are planning to migrate/synchronize Server Profile Templates (SPTs) from a source OneView instance to a separate destination OneView instance. We are developing a Python script that interacts with the REST API to automate this process.

Our core challenge is correctly mapping the resource dependencies (Enclosure Groups, Server Hardware Types, Networks, etc.) from the source SPT to the equivalent resources in the destination instance.

When we GET a source SPT via the API, its configuration contains URIs that are specific to the source instance (e.g., serverHardwareTypeUri, enclosureGroupUri, networkUri). We need to replace these with the correct URIs from the destination instance when creating the new SPT

To confirm our understanding of the correct API procedure, we have two questions:

1. When creating a new SPT on the destination instance via the API (POST /rest/server-profile-templates), is it correct that all dependent resources (like the Server Hardware Type, Enclosure Group, and any specified networks) must already exist on the destination?

2. When defining these dependencies in the JSON request body for the POST, can we reference them by their name (e.g., "serverHardwareTypeName": "SY 480 Gen10") and let the OneView API resolve the correct destination URI internally? Or are we required to first manually look up the destination URI for each dependency in our script and then provide it in the request (e.g., "serverHardwareTypeUri": "/rest/server-hardware-types/xyz-...")?

3. Regarding Ongoing Synchronization: After the initial migration, we will need to keep the templates synchronized. What is the officially recommended method to uniquely identify and idempotently update an SPT? Is relying on the name sufficient for updates, or do you recommend a different approach (like using custom attributes as a unique key) to prevent issues if resource names are not unique across our organization?

thanks in advance. 

[DanCernese]

I will confess that the complete answer to your inquiry is complex and I am unprepared tochase it down:  I will, however, shamelessly point out that this feature is already provided in the HPE Compute Ops Management - OneView edition.