Error when setting policy rule "description" on BIG-IP v11.6.1

[edarzins]

Setting the "description" parameter on a policy rule succeeds on BIG-IP v12.1.0 but fails on v11.6.1:

"code":400,"message":"Found unexpected json pair at configuration item /ltm/policy/cfcf-routing-policy/rules/cf-uaa-724b8d651b68119b. The json pair is \"description\":\"route: uaa.sys.10.190.24.189.xip.io\".","errorStack":[]

The SDK isn't detecting that this parameter is not valid for v11.6.1, but it should.

[wojtek0806]

It has most likely been added in 12.x in SDK we do not enforce parameter checking unless it is a mandatory parameter required for creation, or other operation. Given the Api changes with each version it would not be scalable. It is up to the caller to use proper optional parameter

[wojtek0806]

@edarzins

[zancas]

I vote we handle known idiosyncrasies where we can conveniently. @edarzins issue is likely to affect other consumers of the SDK, so I think he should roll a fix in the SDK. What's the team think?
@caphrim007

[caphrim007]

@zancas I'm ok with that. In the situations where we know what these idiosyncrasies are (this is one of those cases), I think it's less chatty to handle the case locally instead of sending the request to the device to tell us it's a problem.

[wojtek0806]

i am against this, as this will provide inconsistency, and open up the doors for more problems, it should be up the the SDK consumers to know which parameters they can use, SDK is an interface to REST and should remain as lean as possible. We do enough legwork to enforce mandatory parameters and handle known bugs, but this is as far as we should go.
@zancas @caphrim007

[wojtek0806]

what if said 'parameter' gets changed again and again, do you really want to clutter the code with all those workarounds per version? what is stopping others from asking for more parameters to be checked. This is not scalable, also you are going against the rules we have setup and agreed upon in our dev guide.

[wojtek0806]

the rules are simple you need to know what you are doing if you want to use the SDK, we can cover you from known bugs, and help with mandatory parameters, but rest, it is up to you to figure it out.

[caphrim007]

To answer your questions,

We follow the existing patterns that we have for when things change across versions; defining new. Or, we have a data structure in the resource that defines a set of parameters with overrides for versions where it changes.

There is nothing stopping them for asking for more parameters to be checked. That's the point. Issues that people file are handled as time permits (like every issue) and enhancements are made and released bi-weekly.

It's "just another change". We do all of this today.

[wojtek0806]

this is not the point, the change is good if it is a smart change, but this change is a bad idea