Allow access to new PKI APIs v2

[fmarco76]

PKI has a plan to re-implement REST APIs using different libraries and supporting only JSON format. The new APIs have a different path, /v2, and when ready the current implementation will be deprecated.

These APIs will not be back-ported to other branches and for the moment the APIs will not be for external use but the CLI will be progressively migrated to the new API endpoints so these have to be accessible.

For reference: https://github.com/dogtagpki/pki/wiki/CA-REST-API-v2

[fmarco76]

@edewata FYI

[rcritten]

Thanks for the patch.

What is the timeline on the PKI change? certmonger still relies on the XML-RPC API. I started looking into it but the JSON C libraries aren't all that user-friendly for parsing the PKI JSON format.

Can you expand the commit message per https://www.freeipa.org/page/Contribute/Code#create-pull-request-on-github

Your description in the PR should be fine + a Pagure ticket so we know what initiated the change.

You also need to increment the VERSION in the config file so it is updated during upgrade. We'll need to set a new minimum version of pki in freeipa.spec.in.

[fmarco76]

What is the timeline on the PKI change? certmonger still relies on the XML-RPC API. I started looking into it but the JSON C libraries aren't all that user-friendly for parsing the PKI JSON format.

The goal is to re-implement all VLV based operations for RHEL10 using paged search or other approaches. The other operations will come later. together with a reorganisation/improvement on the APIs layout. We will deprecate current XML based APIs when we have the full set in the new v2. By the way, since we are working on the API if we could modify them to be easier to work for IPA we could discuss.

Can you expand the commit message per https://www.freeipa.org/page/Contribute/Code#create-pull-request-on-github

Your description in the PR should be fine + a Pagure ticket so we know what initiated the change.

OK

You also need to increment the VERSION in the config file so it is updated during upgrade. We'll need to set a new minimum version of pki in freeipa.spec.in.
I'll check this.

[rcritten]

What is your definition of "deprecated"? Does it mean "going away eventually" or "it will be removed along with v2"?

Is the version of API discoverable? That would help us support multiple versions of PKI without having to rely completely on package n-v-r.

[fmarco76]

Your description in the PR should be fine + a Pagure ticket so we know what initiated the change.

@rcritten I have opened this issue: https://pagure.io/freeipa/issue/9564 and updated the commit with the PR message.

You also need to increment the VERSION in the config file so it is updated during upgrade. We'll need to set a new minimum version of pki in freeipa.spec.in.

Not sure on this point freeipa.spec.in has the minimum pki_version to 10.10.5. Until you are not using the new APIs there are no compatibility problems. Maybe we can modify the proxy to pass v2 information only when pki version is higher of a the current version. Is this needed now or we can leave this configuration customisation for future update?

What is your definition of "deprecated"? Does it mean "going away eventually" or "it will be removed along with v2"?

For deprecated we mean ¨going away eventually¨. Even all the commands will use the new APIs we will keep the oild one unless some new change brake them.

Is the version of API discoverable? That would help us support multiple versions of PKI without having to rely completely on package n-v-r.

We have not in program to support the full HATEOAS principle but if it is need in some places we could add something.

[rcritten]

Note: we'll want to set a new PKI minimum version for the v2 support to coordinate with this PR.