These are great questions. First, let me back up and explain some aspects of our configuration archive feature in Prime Infrastructure, then I'll address your specific questions.
The configuration archive feature saves all of the device config (both running and startup, as well as VLAN or module config if appropriate). These archives are triggered either manually, as scheduled by you, or when certain actions occur. The actions that trigger automatic archiving are when the device is added and first becomes fully managed, and when configuration changes are made through Prime Infrastructure. You can disable these automatic archivals, as well as enable other triggers (like archive after sync), and configure retention by going to Administration > Settings > System Settings, then selecting Inventory > Configuration Archive from the list on the left. These archives are available even when the device is offline or unreachable, because they are persisted in Prime Infrastructure itself.
When you view the device details, and click the Configuration tab, what you're seeing is a close-to live version of the configuration, based on the features that the device pack installed in Prime Infrastructure is aware of. These items are cached in Prime Infrastructure, and so if the cache expires and the device is unreachable, then you will not be able to see them. Also, if configuration is present on the device for a feature that doesn't exist in the device pack you have installed, we will not show it here (but it will still show in the config archive). I hope that explains why you're seeing a difference between those two areas of our UI.
Alright, now let's get to what the ConfigVersions resource does. ConfigVersions returns you metadata about the archives present in the system. So yes, in your case, if you're not seeing any archives in the UI, then it makes sense that ConfigVersions has zero records for you. You can use this resource to...
- Identify the latest config archives by filtering on isLast=true
- Identify all the config archives for a given device by filtering on deviceIpAddress or deviceName
- Identify config archives that represent config changes that were made out-of-band (by filtering on outOfBand=true)
You can do the same thing with the Bulk*ConfigArchives resources; however, since we don't have to fetch and manipulate (like sanitizing for the BulkSanitizedConfigArchives resource) the actual config data, this resource tends to be faster. The IDs for ConfigVersions are the same as for the Bulk*ConfigArchives resource, so once you identify a config archive of interest with ConfigVersions, you can fetch it by ID with Bulk*ConfigArchives (for example, GET /webacs/api/v3/data/BulkSanitizedConfigArchives/12345).
Lastly, there is also the ConfigArchives resource. You didn't mention it in your post, but I'll go ahead and explain it in a little more depth here. The ConfigArchives represents config archive information on a per-device basis. So ConfigVersions is per archive versions, ConfigArchives is per device. The importance of ConfigArchives (in my opinion) is that it lets you know if config archives are being performed on the devices being managed by Prime Infrastructure, and if not, then why. You can use it to watch for bad behaving devices, or areas where the device pack installed doesn't have support for the device. For example, here's what happens when I try to do a config archive of a third party device that my installed device pack doesn't support.
<configArchivesDTO displayName="663675" id="663675">
<deviceIpAddress>172.23.208.110</deviceIpAddress>
<deviceName>Aruba620</deviceName>
<lastMessage>
Fetch running configuration - No device package found for the specified device. Fetch startup configuration - No device package found for the specified device. Fetch VLAN configuration - No device package found for the specified device. Archive configuration - Not Attempted
</lastMessage>
<lastSuccessful>false</lastSuccessful>
</configArchivesDTO>
So you can see that the lastSuccessful response parameter is set to false, and the lastMessage value explains the reason why.
I hope that clarifies all things config archive for you. But if not, please do reach out!
