Module developed for UCS Director 5.0 porting to 5.1 - changes

[natarajsubramanian]

Hi,

We are trying to port a module which has been tested on UCS Director 5.0 onto version 5.1.

http://www.cisco.com/c/en/us/td/docs/unified_computing/ucs/ucs-director/open-automation-api-guide/5-1/b_UCSD_Open_Automation_Developer_Guide_5_1/b_UCSD_Open_Automation_Developer_Guide5-x_chapter_01.html

The 5.1 open automation guide suggests the difference from the previous release. I do not understand the second row of Table 1 mentioned in the above link as indicated next.

Introduced the createAccountType() class in place of the getCollectors() class.

Replaced the getCollectors() class with the createAccountType() class.

We tried adding a method called createAccountType() in the Module class, but the AbstractCloupiaModule super class does not have any such method that requires to be overriden.

Could someone please help as to what code change is expected.

Regards,

Nataraj

[lkandasa]

Hi Nataraj,

     In Open Automation 5.1, deprecated the getcollectors() method, to add account and collects the inventory of the account , we have introduced the createAccountType() method in FooModule class. And also you cannot port the module developed in UCSD 5.0 to UCSD 5.1. The library jars  in UCSD 5.0 does not support for UCSD 5.1 library jar changes. This is causing  "AbstractCloupiaModule super class does not have any such method that requires to be overriden."

[natarajsubramanian]

Hi Logesh,

Thanks for your reply.

Just few details about the the use of the word "porting" from 5.0 to 5.1

No code changes were done. Since the 5.1 open automation guide mentioned about createAccountType(), we posted the earlier question thinking code change is expected.

The module code was compiled against the 5.1 jars. And no compilation errors were reported.

But when the module was deployed, the module failed internally (inventories not getting populated). Investigation shows that  the module inventory loading internally fails with NoClassDefFoundError for a third-party jar class listed in the module's feature file. But the jar has been packaged as part of the module and the relative path of the jar is correctly mentioned in the feature file.

Could you please help as to why this may happen. Please note that the same module (3rd party jar, feature file) works correctly on 5.0 UCS Director.

Thanks,

Nataraj

[leshanka]

Hi Nataraj,

Which 3rd party jar is causing the issue?

Thank you,

Lekha.

[natarajsubramanian]

Hi Lekha,

The 3rd party jar is jersey-client-1.18

On the appliance, the jar is available at the location  /opt/infra/inframgr/features/<Module-Folder>/lib

From this location it does not work. The entry in the module feature file is "features/<Module-Folder name>/lib/jersey-client-1.18.jar"

When I place the jar directly under /opt/infra/inframgr/ and modify the /opt/infra/inframgr/run.sh script to include this jar on the classpath, only then the inventories get populated as the REST call to the backend servers succeed.

Thanks,

Nataraj

[leshanka]

Hi Nataraj,

To assist you further , would it be possible to get to us through Cisco UCSD contact you may have.

This will enable us to work with you directly.

Thank you,

Lekha.

[leshanka]

Alternately, if you could share your email contact, it will enable quicker resolution of the issue.

Thank you,

Lekha.

[natarajsubramanian]

Hi Lekha,

Due to security policy I will not be able to share my official Id in the forum.

My personal id is subramanian_nataraj@yahoo.com.

You could send any details to this mail id or post in this thread as convenient.

Thanks,

Nataraj