EnhReq: Need ability to retrieve history of changes for Azure App Config keys

[andrejusc]

Related command

As of today - I could retrieve some configured entry and fields of names and last_modified in form like this:

az appconfig feature show -n <name> --key .appconfig.featureflag/<flag> --fields name last_modified

but I cannot find a way to retrieve history of changes, which I could see in Azure UI.

Is your feature request related to a problem? Please describe.

It's a problem of expected OOTB AZ CLI capabilities here.

Describe the solution you'd like

Not sure if --history option is used in some other AZ CLI commands. But potentially would like to be able to do like this:

az appconfig feature show -n <name> --key .appconfig.featureflag/<flag> --fields name last_modified state --history

Describe alternatives you've considered

The only known alternative so far is Azure Portal UI, which is inconvenient for better automation.

Additional context

N/A

[yonzhan]

Thank you for opening this issue, we will look into it.

[microsoft-github-policy-service]

Thanks for the feedback! We are routing this to the appropriate team for follow-up. cc @shenmuxiaosen, @avanigupta.

[avanigupta]

Hi @andrejusc, would az appconfig revision command work for you?
https://learn.microsoft.com/en-us/cli/azure/appconfig/revision?view=azure-cli-latest

[andrejusc]

@avanigupta - it works only partially as in my original command az appconfig feature show - I could specify state in fields, but for az appconfig revision command - I could only specify value like such:

az appconfig revision list -n <name> --key <key> --fields key value last_modified

and then it would require additional parsing of value output line to decipher if it's enabled/disabled:

"value": "{\"id\":\"MyFlagKey\",\"description\":\"MyFlagKey to test\",\"enabled\":false,\"conditions\":{\"client_filters\":[]}}"

and I'd like to be able to retrieve state in revisions history as separate entity without a need for post-parsing and also be able to retrieve/filter out in initial call only entries when it's false or true. Could that be achieved?

[avanigupta]

We currently don't support revision history specifically for feature flags. However, you could still filter on the state by parsing the value field using the --query argument that's available for all Azure CLI commands.

[andrejusc]

@avanigupta - but how to do that? I'm reading that JMESPath, which is used for --query logic doesn't support inner JSON parsing. So how to retrieve then via --query value of enabled from my above example?

I could potentially achieve that via Linux jq tool (it has fromjson method for parsing capability for inner JSON), but I'd like to avoid using that here.

As retrieval here is not straightforward - I still see then value of this enhancement request to be implemented/considered.

[andrejusc]

@avanigupta - could this request be prioritized by some means?

[albertofori]

Hi @andrejusc,
Thank you for reaching out. Currently, listing revision is only supported in the format of key-values since the provided supported fields are those that are always present in the base configuration setting to maintain uniformity when listing revisions for configuration of different types.

The idea to add a --history flag to the appconfig feature show, while helpful, introduces an inconsistency in the return type from a show command. In one case we return a single object, but with a flag, we might return a list of objects.
A workaround that I might suggest would be akin to what you mentioned earlier by parsing the value of the feature flag.

Using jq in linux, you could use this command to get all feature flags with their last modified date and state:

az appconfig revision list -n <store-name> --key <feature-flag-key> | jq ".[] | {modified_date: .lastModified, enabled: .value | fromjson | .enabled}

I hope this helps.

[andrejusc]

Hi @albertofori - having already quite powerful --query approach for various AZ CLI commands - I'd like to avoid using 3rd party tools like jq at all cost (even if I'm using such myself in some of Ubuntu distros). Reduce of dependencies will make overall experience much better and also more cross platform friendly.

Not sure why it's a problem of consistency here - I assume single object or array of objects are 2 main JSON variations in responses anyway. And it's down to consumer then based on provided documentation to process that response one way or another. But main point here - is to avoid extra parsing need altogether as it's not the expectation with already flexible AZ CLI commands/options/filters/etc.

[avanigupta]

Not sure why it's a problem of consistency here - I assume single object or array of objects are 2 main JSON variations in responses anyway

In Azure CLI, show commands are standardized to show the properties of a single resource. To list multiple instances of a resource, we have to use list commands. That's the reason we don't want to introduce a something like a --show-history flag for show commands.

However, your point is valid that we should provide an easier way to get the history of feature flags without parsing json values using 3rd party tools. We are considering the best way to design this feature to meet your needs and Azure CLI standards.