App installation behavior

User-installed apps

If you are manually installing an App that doesn't normally come pre-installed on an APIC, the behavior around that installation varies, depending on the following situations:

• If you do not already have this App installed on your APIC, then this is considered a fresh installation and the App is installed on your APIC in the normal fashion.

• If you already have this App installed on your APIC and the App currently installed on your APIC is an earlier version of the App, then the upload of this later version of the App to your APIC triggers an upgrade of the App on your APIC.

• If you already have this App installed on your APIC and the App currently installed on your APIC is a later version of the App, then the upload of this earlier version of the App to your APIC triggers a downgrade of the App on your APIC.

Pre-packaged apps

When you upgrade or downgrade all of the APICs in a cluster to a new APIC image, the plugin-handler checks for pre-packaged Apps images that come with that new APIC image.

• If the plugin-handler finds that an App is available in the new APIC image but that App is not currently installed on your APICs, then the plugin-handler triggers the installation of that App on your APICs.

• If the plugin-handler finds that an App is available in the new APIC image and that App is already installed on your APICs, the plugin-handler then checks if the App that is available in the new APIC image is an earlier or later release than the App currently installed on your APICs:

  • If the version of the App in the new APIC image is a later release than the App currently installed in your APICs, then the plugin-handler triggers an upgrade or downgrade for that App on your APICs. Beginning with release 5.2(3), pre-packaged Apps get upgraded or downgraded to whatever App images are bundled in the APIC image after all of the APICs are upgraded or downgraded in a setup, regardless of what version of those Apps were running on that setup before the APICs got upgraded or downgraded.

  • If the version of the App in the new APIC image is an earlier release than the App currently installed in your APICs, then the plugin-handler takes no action with the App on your APICs. The plugin-handler does not downgrade the App on your APICs to that earlier version that is available in the new APIC image. This is done so that you can install newer versions of an App, where the version of an App that you install might be later than the version that comes pre-packaged with an APIC image, and the plugin-handler won't automatically overwrite the later version of that App currently on your APICs with an earlier version.

For example, assume the APICs in a cluster are running on release version 1.2(3), and the pre-packaged App AcmeApp is available for APIC release 1.2(3), where 4.5(6) is the version of AcmeApp that is normally pre-packaged on APICs running on release 1.2(3).

Assume that you want to upgrade the AcmeApp at some later date and the latest version of AcmeApp, the 4.6(1) version of AcmeApp, is available at the App Center. You then manually download and install that latest version of AcmeApp so that the APICs and the AcmeApp are at the following versions:

• The APICs in the cluster are still running on APIC release 1.2(3)

• The AcmeApp on these APICs is now updated to AcmeApp version 4.6(1)

Now assume that you decide to upgrade the APIC from release 1.2(3) to release 1.2(4) at another date later on. However, for APICs running on 1.2(4), the version of AcmeApp that is normally pre-packaged is version 4.5(7). In that case, the plugin-handler would not make any changes to the version of AcmeApp running on your APIC, because your APIC already has a version of AcmeApp running on it [version 4.6(1)] that is later than the 4.5.(7) version that would normally come pre-packaged with APIC release 1.2(4).

Note that you can change the Apps policy for pre-packaged Apps:

• Through the REST API, you can change the Apps policy for pre-packaged Apps by modifying the apPrepackagedPlugins MO using one of the following three options:

  • install-all: This is the default value. This option installs or upgrades pre-packaged Apps in the manner that is described above.

    
    POST {{apic-url}}/api/policymgr/mo/.xml
    
    <polUni>
      <apPluginPolContainer>
          <apPrepackagedPlugins PrepackagedAppsAction="install-all"/>
      </apPluginPolContainer>
    </polUni>
    

  • remove-all: This option removes all pre-packaged Apps from APIC.

    
    POST {{apic-url}}/api/policymgr/mo/.xml
    
    <polUni>
      <apPluginPolContainer>
          <apPrepackagedPlugins PrepackagedAppsAction="remove-all"/>
      </apPluginPolContainer>
    </polUni>
    

  • skip-installation: This option disables the plugin-handler from automatically installing or upgrading pre-packaged Apps in future APIC image upgrades.

    
    POST {{apic-url}}/api/policymgr/mo/.xml
    
    <polUni>
      <apPluginPolContainer>
          <apPrepackagedPlugins PrepackagedAppsAction="skip-installation"/>
      </apPluginPolContainer>
    </polUni>
    

• Through the APIC GUI:

  1. Navigate to Apps > Installed Apps.

     The Apps page is displayed.

  2. Click on the Settings icon ( ), then choose Change Prepackaged Apps Policy.

     The Change Prepackaged Apps Policy page appears.

  3. Choose one of the following options (see the options descriptions above in the REST API information):

     • Install All

     • Remove All

     • Skip Installation

Working with Hidden Pre-Packaged Apps

For any App that you install, whether it is a user-installed App or a pre-packaged App, you can usually see that App displayed in the Apps window in the APIC GUI, which you can view by navigating to Apps > Installed Apps.

You can perform certain actions for Apps displayed in this window, such as opening, enabling, or deleting those Apps.

However, there are certain pre-packaged Apps that might be installed on your APICs but are not displayed in the Apps window in the APIC GUI, such as the ApicVision App that became available beginning with release 5.2(1). While these hidden Apps won't appear in the Apps window, they might appear in the Faults window if there is an issue with that App (Apps > Faults).

Note

The pre-packaged ApicVision App that became available with release 5.2(1) is not available for download through the App store, so do not make changes to or delete the ApicVision App. Contact Cisco TAC support if you have any issues or faults with the pre-packaged ApicVision App.

You can locate and work with these hidden pre-packaged Apps through Visore, the APIC Object Store Browser that you can use to directly query Managed Objects (MOs). For more information on Visore, see Application Policy Infrastructure Controller Visore Tool Introduction.

You can access Visore by appending /visore.html to the URL that you would normally use to log into your APIC GUI:

https://<APIC or Switch IP ADDRESS>/visore.html

After you have logged into Visore, the Object Store window is displayed.

From there, you can query the MO for any Apps installed on your APICs by entering apPlugin in the Class or DN or URL field and clicking Run Query. Visore returns output showing the number of objects found for this MO, which is the total number of Apps that are installed on your APICs, including hidden Apps that aren't displayed in the Apps window in the normal APIC GUI.

For example, the information provided in the Apps window in the example above shows two Apps installed, whereas the information returned from the apPlugin query in Visore shows three objects found for the Apps MO. Comparing the two lists of Apps, you can see that the ApicVision App is not shown in the Apps window in the normal APIC GUI but is displayed in the Visore output, so that means that the ApicVision App is a hidden pre-packaged App.

You can now get more information on this hidden pre-packaged App through certain fields displayed in the Visore output, such as the pluginSt field that shows your desired state for the App and the operSt field that shows the operational state for the App.

For example, you could verify that an App is up and running if you see the following for an App:

• No faults are shown for this App in the Faults window (Apps > Faults)

• The state in the operSt field is shown as active

• The state in the pluginSt field is shown as active

In addition, you should pick a security domain when you enable an App, and the securityDomains field is populated with that value when you enable an App as described below (when you set the pluginSt field to active for an instance of an apPlugin MO). Note that the plugin-handler selects all as the security domain for infra Apps (for Apps that are set to infra in the appType field in the apPlugin MO instance).

Because you can't view these hidden Apps in the Apps window in the normal APIC GUI, you are not able to perform certain actions such as opening, enabling, or deleting the hidden Apps through the APIC GUI. However, you can perform these actions on a hidden App through the REST API:

• To enable a hidden App, send a post with XML such as the following example:

  
  <?xml version="1.0" encoding="UTF-8"?>
  <!-- /api/plgnhandler/mo/.xml -->
  <apPluginContr>
      <apPlugin appCtxRoot="{{vendordomain}}_{{appid}}" pluginSt="active" securityDomains="{{security-domains}}"/>
  </apPluginContr>
  
  

  Where the pluginSt is active.

• To disable a hidden App, send a post with XML such as the following example:

  
  <?xml version="1.0" encoding="UTF-8"?>
  <!-- /api/plgnhandler/mo/.xml -->
  <apPluginContr>
      <apPlugin appCtxRoot="{{vendordomain}}_{{appid}}" pluginSt="inactive"/>
  </apPluginContr>
  

  Where the pluginSt is inactive.

  Note the following:

  • The security domain is not needed when disabling a hidden App.

  • To find the appCtxRoot value for an App for either of the posts shown above, query for instances of the apPlugin MO and use the entry in the appCtxRoot field in the instance of the apPlugin MO that corresponds to your App of interest.

    To get this information, log in to your APIC through ssh as an admin user and enter the moquery -c apPlugin | grep appCtxRoot command:

    
    # moquery -c apPlugin | grep appCtxRoot
    appCtxRoot           : Cisco_NIBASE
    appCtxRoot           : Cisco_ApicVision
    

• To delete a hidden App, send a post with XML such as the following example:

  
  <?xml version="1.0" encoding="UTF-8"?>
  <!-- /api/node/mo/.xml -->
  <firmwareRepo>
      <firmwareFirmware name="{{vendordomain}}_{{appid}}" deleteIt="true"/>
  </firmwareRepo>