aristanetworks/cvprac

deploy_device breaks in 2018.1

Closed this issue · 5 comments

dathelen commented

looks like we need to use different API endpoints. Found this out while helping out the SBUX POC.

grybak-arista commented

@dathelen mentioned in this comment #52 (comment) that there may have been some additional changes required for this issue. Should this be reopened?

brokenpackets commented

Do we know if the new api changes are backward-compatible, or should we look into pulling version info with 'cvpInfo/getCvpInfo.do'?

Proposed changes tested against 2018.1.0 and 2018.1.1.

Edit:
Changing the default function behavior back to extend for configlet merge. Existing syntax works as long as input for configlets= variable is a list. Biggest issues with 2018 seem to be the 'id:' kvp not being accepted, and that configlets must be assigned before the topology is saved (one temp session after another is okay as long as save isn't initiated) - If you attempt to assign a configlet after a task has been created to move a device from the undefined container to a regular container, the api gateway will complain that devices in undefined container cannot have configlets assigned to them.

I've added a variable under the deploy_device function to allow the user to select if create_task should be automatically generated during the run, or if they choose to save the topology themselves. True is set as the default so as to match the previous default behavior.

devrobo commented

I would suggest not parsing CVP version info but doing feature inspection. The call worked on the old release and now fails on the new release, is there a way to detect the failure and work around it with the updated CVP API call? If not, can you see if the new call works (feature inspection) and if not then use the old call?

mharista commented

Tested this on 2018.1.1, 2018.2.0 and 2018.2.2 and it works for all three with the current release and develop code.