« Back to Technical Discussions

Looks like bug in UCSM 1.4 (using XMLAPI)

Combination View Flat View Tree View
Threads [ Previous | Next ]
Could anyone throw some light ove the issue mentioned in the below url
 
https://supportforums.cisco.com/thread/2104817
 
 
Thanks
Dilip

Answered in the support forums, posted here as well

Dilip,

The API is operating correctly, processing the XML that was sent to approriately. The XML code is setting the Floppy object boot order to 1 which resulted in what you see in the boot policy shown in the GUI.

The GUI builds the XML based on what is requested and "helps" the GUI user, in the case of a boot policy by modifying the order number of the above or below boot option depending upon which direction the boot option is moved.

The XML code sent to the UCS Manager by the GUI will send the code for ALL the affected boot objects. The code your application needs to do the same.

If you want the Floppy to be order 1 then the boot object that is order 1 needs to become the order of what the Floppy was, in your picture that would be the Local Disk.

You code needs to look like this, the difference is the addition of the Local Disk object. Also please notice that I am changing a boot policy called "localboot" not "default"

<configConfMos inHierarchical="true" cookie="1316615902/0221f3e1-beae-4958-9589-26bc704654f7">
<inConfigs>
<pair key ="org-root/boot-policy-localboot">
<lsbootPolicy name="localboot" descr="Modified by GaleForce Adapter" purpose="operational" dn="org-root/boot-policy-localboot" rebootOnUpdate="no" enforceVnicName="no">
<lsbootVirtualMedia rn="read-write-vm" order="1" access="read-write" />
<lsbootStorage order="2" rn="storage">
<lsbootLocalStorage rn="local-storage"/>
</lsbootStorage>
</lsbootPolicy>
</pair>
</inConfigs>
</configConfMos>

Hope that helps.

John

Thanks for response John,
I agree that UCSM is woking as designed in this case.However, If we look at a real scenario, where I don't have access to GUI and I have to change boot order (s), then
UCSM must update the boot order(s) accordingly. Since it would be harsh to remember the boot orders of all the media types and do the swapping of boot orders superficially.
From API user point of view, If I post my XML of changing boot order. there are two case which a user expects
a) UCS should return the error code with description for e.g 'boot order already assigned to another object'
b) It should swap the boot order(s) If I update any of the boot order

As UCSM is a very smart tool, and at this point I am observing some manual work which could be done internally as well.
If we say non-technically, It is not a bug and functioning as designed whereas from a user point of view, I would like to request you to mark it as a feature in future release

You should query and get the boot policy that you are looking to change first, determine the boot orders affected then do your updates accordingly.

The API allows for manipulation of multiple objects at the same time, what would happen if I attempted to change the boot order of 3 boot objects at the same time, what would be swapped then?

Instead of swapping I think the API should respond to a request that causes multiple use of the same boot order with an error. For example if I try to utilize the same boot order in a boot policy in the CLI, the CLI responds with this error.

Software Error: Order should be unique among bootdevices.

Regards,
John

Sounds good!
Atleast, CLI understand my situation...

Thanks for your time John