What's the use case of KVM Scope @ Policy level ?

As per docs, KVM scope value can take values Org, Env, Proxy or Policy. Just wondering why does some one need KVM scope at policy level ? Policy level means i can set the KVM and read KVM only using same policy ?

Or Is it useful along with shared flows concept ?

Solved Solved
1 4 734
1 ACCEPTED SOLUTION

Anil, you are possibly referring to this documentation.

It's a good question, and the short answer is "mmmm.... ahem....mmmrrrrph".

In other words, I don't have a good, short answer for you.

Just thinking about it, I agree with you that it makes no sense to have a KVM scoped to "policy". Notice that the documentation does not explain the KVM semantics when "policy" Scope is used. The doc defines "environment" scope and "apiproxy" scope, but not "organization" scope or "policy" scope. We can easily imagine the meaning of "organization" scope, but ... policy scope?

Looking into it, the implementation of the KVM does not actually scope any KVM to the policy level. OK good, then it's a simple matter of a documentation error, right? Well,..... not so fast. Actually, the KeyValueMapOperations policy configuration does allow the keyword "policy" to be used within the Scope element. So the documentation, as far as it goes, is actually correct. Where the doc falls down is explaining what that means.

So what happens when the word "policy" is used? The KVM is scoped to a specific apiproxy revision.

Wow. Not what I would expect from that keyword. I think this is the largest violation of the Principle of Least Astonishment that I have ever seen in any interface in Apigee Edge. The keyword is wrong, and confusing.

The actual set of scopes and the keywords to use within the Scope element is:

actual scopekeyword within <Scope> element
organizationorganization
environmentenvironment
apiproxyapiproxy
apiproxy revisionpolicy


Notice anything strange about that last row? 🙂 . The appropriate keyword should be "revision", or maybe "apiproxy_revision" if you lean toward prolixity. But you cannot use that keyword today in the policy configuration; the policy validation logic will reject it.

I think all of this is true, but I'm not certain. I need to run some tests. If all of the above is confirmed, I'll file a bug to get the implementation fixed to allow "revision" scope, and a separate bug to get the documentation amended. Regardless, I will update here when I have more information.

In the meantime, use the "policy" keyword in the Scope element in a KVM policy to specify "apiproxy revision" scope.

ps: I don't know of any customers using "apiproxy revision" scope for KVM. Though we can easily imagine use cases.

EDIT: All of the above is confirmed. Here's the bug: b/69573052 .

View solution in original post

4 REPLIES 4

Anil, you are possibly referring to this documentation.

It's a good question, and the short answer is "mmmm.... ahem....mmmrrrrph".

In other words, I don't have a good, short answer for you.

Just thinking about it, I agree with you that it makes no sense to have a KVM scoped to "policy". Notice that the documentation does not explain the KVM semantics when "policy" Scope is used. The doc defines "environment" scope and "apiproxy" scope, but not "organization" scope or "policy" scope. We can easily imagine the meaning of "organization" scope, but ... policy scope?

Looking into it, the implementation of the KVM does not actually scope any KVM to the policy level. OK good, then it's a simple matter of a documentation error, right? Well,..... not so fast. Actually, the KeyValueMapOperations policy configuration does allow the keyword "policy" to be used within the Scope element. So the documentation, as far as it goes, is actually correct. Where the doc falls down is explaining what that means.

So what happens when the word "policy" is used? The KVM is scoped to a specific apiproxy revision.

Wow. Not what I would expect from that keyword. I think this is the largest violation of the Principle of Least Astonishment that I have ever seen in any interface in Apigee Edge. The keyword is wrong, and confusing.

The actual set of scopes and the keywords to use within the Scope element is:

actual scopekeyword within <Scope> element
organizationorganization
environmentenvironment
apiproxyapiproxy
apiproxy revisionpolicy


Notice anything strange about that last row? 🙂 . The appropriate keyword should be "revision", or maybe "apiproxy_revision" if you lean toward prolixity. But you cannot use that keyword today in the policy configuration; the policy validation logic will reject it.

I think all of this is true, but I'm not certain. I need to run some tests. If all of the above is confirmed, I'll file a bug to get the implementation fixed to allow "revision" scope, and a separate bug to get the documentation amended. Regardless, I will update here when I have more information.

In the meantime, use the "policy" keyword in the Scope element in a KVM policy to specify "apiproxy revision" scope.

ps: I don't know of any customers using "apiproxy revision" scope for KVM. Though we can easily imagine use cases.

EDIT: All of the above is confirmed. Here's the bug: b/69573052 .

Thanks for that clarification on "policy," @Dino! I added a parenthetical note next to "policy" on the <Scope> element description.

Thank you @Floyd Jones for quickly updating same on docs. +1

Fantastic Answer @Dino !!!! Feel like upvoting same +50 times ! Since i can do only once, +50 community reward points from my side 🙂