Bundle incompatibility; revise not working

[rpevertsminvwsnl]

When creating a bundle with Gateway version 11.1.2, policy comments are bundled with:

".properties": {
".left.comment": "comment1"
".right.comment": "comment2",
}

When creating a bundle with Gateway version 11.2.1, policy comments are bundled with:

"_leftComment": "comment1",
"_rightComment": "comment2"

This seems to be the case regardless of specified policy schema in graphman.

Bundles created with 11.1.2 can be imported in GW version 11.2.1, however, bundles created with 11.2.1 are rejected when importing to 11.1.2 with the following message:

"description": "Error creating or updating SERVICE entity, Field (_rightComment) config is missing for the bean com.l7tech.policy.assertion.composite.OneOrMoreAssertion"

This is also the case for field _leftComment and other assertions like AllAssertion, SetvariableAssertion, Include, FalseAssertion, etc.

graphman revise does not modify this comment structure when revising with --options.schema v11.1.2. (also, but nonrelated, it seems to always output json format, regardless of policyCodeFormat).

Since we are in an upgrade cycle in out DTAP environment and the Development & Test gateways are upgraded, whilst the Acceptance and Production gateways are not, this is impacting our deployment strategy.

Is there something we could do to mitigate this behaviour. We're working with graphman version 2.0.19 at the moment, however we did some testing with 2.0.22 but ran into the same issue.

[graju256]

@rpevertsminvwsnl

Latest releases do support the old bundles, but not the other way. Original intent of the revise command is to port the old bundles to the latest gateway releases if at all any deprecated features are removed from the support.

We should not consider migrating the gateway configuration from latest releases to the older ones. May I know the reason why are we trying this unsupported migration path?

Thanks.

[rpevertsminvwsnl]

The unsupported migration path is however the logical one in a DTAP environment. In such an environment, you would first upgrade Development, and later Test, Acceptance and Production. Our upgrade policy is to normally leave one week between these tiers, so the complete cycle duration is one month.

We have upgraded Development, but since the bundles created there (regardless of specified graphman --options.schema version) use the _leftComment, _rightComment, _Children structure, these cannot be imported in 11.1.2. So now fixes and changes cannot be DTAP deployed.

[graju256]

@rpevertsminvwsnl

There are two problems here.

• Graphman is aggressively closing its gap from release to release. You will always see some additions with the latest release. We must be careful not to use latest features (i.e., new entity types or fields that are not present with the older releases) while porting the bundles from newer to older releases.

• Policy as code is made available as GA feature since 11.2. The noticed differences are part of the standardization of it since 11.2 release. Either way, noticed changes can be manageable within the graphman-client. Beyond that, there's no guarantee about the 100% compatibility without the server side changes.

Let me see what I can do for this.

[rpevertsminvwsnl]

We are well aware of the limitation of using new additions/features during an upgrade cycle. In a way, upgrading in a TAPD order would then also make sense. I'm wondering how other customers are handling this limitation? What is the recommended strategy of upgrading DTAP environments? Anyway, since our D & T are already upgraded, for us changing a strategy will not fix our current issue.

Many thanks that you will look into it.

[ecelen-minvws]

@graju256 Isn't the schema version that is set in the graphman config or that you can pass via the command line meant to ensure that your bundles always remain compatible with a schema version?

[graju256]

@ecelen-minvws

Effect of the --options.schema or schema option from the configuration is confined to the graphman-client alone. It is not carried until the connecting gateway (graphman).

[graju256]

@rpevertsminvwsnl

There are two ways you could get it work around:

1. Use policy code format as XML
2. Use the post-review extension

We've come across similar ask previously and prepared the extension based solution.

[graju256]

@rpevertsminvwsnl We will incorporate the solution in the next graphman-client release for this. Please open a support ticket for quick hotfix based solution.