Create a test client for the M1 interface

[davidjwbbc]

Description

Create a command line client that can be used to test the M1 interface of a 5GMS AF. This client shall implement the client side requests for the following M1 APIs and display the results:

• Provisioning Sessions API
  • The Provisioning Session ID assigned by the Application Function (e.g. the Location response) should be printed to the console in response.
• Content Protocols Discovery API
  • The set of downlink/uplink protocols supported by the Application Function should be printed to the console in response.
• Server Certificates Provisioning API
  • The Server Certificate ID assigned by the Application Function (e.g. the Location response) should be printed to the console in response.
• Content Hosting Provisioning APIs
  • The tool should generate a Service Access Information corresponding to the submitted Content Hosting Configuration that includes the Provisioning Session ID.

This will be useful in testing issues #15, #16, #17 & #18.

This should be implemented as command line wrapper application around a core library or Python module which implements the M1 client interface so that the library or Python module can be reused for unit testing. This should not use the openapi-generator bindings so that correct implementation of those bindings can be tested.

Relevant specifications and corresponding clauses

TS 26.512 (v17.2.0):

• 7.1 (General M1 API)
• 7.2 (M1 Provisioning Sessions API)
• 7.3 (M1 Server Certificate Provisioning API)
• 7.5 (M1 Content Protocols Discovery API)
• 7.6 (M1 Content Hosting Provisioning API)
• C.3.1 (M1 Provisioning Sessions OpenAPI YAML)
• C.3.2 (M1 Server Certificate Provisioning OpenAPI YAML)
• C.3.4 (M1 Content Protocols Discovery OpenAPI YAML)
• C.3.5 (M1 Content Hosting Provisioning OpenAPI YAML)

[rjb1000]

Ultimately, we need to provide a usable and maintainable M1 client for normal use. Rather than develop this separately from this test client, I wonder if we can't just combine them into a single tool.

With that ultimate goal in mind, the idea of a hand-coded implementation of the OpenAPI doesn't feel like a good use of effort when the API client binding can be autogenerated.

[davidjwbbc]

Started development on some general use M1 client python classes and will add a testing specific CLI frontend python app.

[davidjwbbc]

I now have one general use python class rt_m1_client.M1Client which can perform the ProvisioningSession and ContentHostingProvisioning operations and return the results as Python types. I still need to add ServerCertificates and ContentProtocolsDiscovery APIs to this.

I'm also planning on creating a rt_m1_client.M1Session class which will manage multiple interactions with the Application Function via the M1Client class in order to provide a higher level access. This will do things like create a ProvisioningSession, provision certificates and setup the ContentHostingConfiguration in one operation, returning one or more ServiceAccessInformation objects for publication. This will provide the higher level access that an Application Provider should need and can then be written into a daemon process to manage configurations.

[davidjwbbc]

M1Client can now perform API operations and interpret responses for:

• ContentHostingProvisioning
• ContentProtocolsDiscovery
• ProvisioningSession
• ServerCertificatesProvisioning

I'm currently testing it with a fixed Python application (i.e. no command line options just a series of test calls) which creates a provisioning session, server certificate and configures Big Buck Bunny through an HTTPS distribution via the content hosting configuration.

At the moment it's not quite working end-to-end so I'm tracking down if this is a problem with the test client or the AF.

Next step is add the M1Session class and create the command line app to control it.

[davidjwbbc]

Got the simple M1 client app working after fixing some AF code issues. Have successfully tested:

• Allocate a new provisioning session.
• Allocate a new AF generated certificate to a provisioning session.
• Create a ContentHostingConfiguration in the provisioning session which uses the allocated certificate.

Have made a start on the M1Session class and CLI app to control it. This CLI will have commands to create a new stream (new provisioning session, check content protocols, allocate certificates if SSL being used, create a ContentHostingConfiguration using an ingest URL and optional media entry point URL suffix), list existing provisioning sessions, renew certificates, destroy a stream/provisioning session and all certificates associated with it.

[davidjwbbc]

The M1 Session tool and M1Session class have been completed and tested as part of the recent release on PR #53. However a couple of the interfaces for renewing certificates have been commented out from the command line interface as they are not ready yet, but there is enough interface present to allow configuration and testing of the 5GMS Application Function.

The renewal should be able to be done by hand by:

1. Create a new certificate (m1-session new-certificate command) with the same details (-d <domain-name-alias> or --csr command line arguments) as the expiring/expired certificate.
2. Modify the ContentHostingConfiguration to swap the expiring/expired certificate-id for the new certificate-id.
3. Use the m1-session set-stream command to update the ContentHostingConfiguration for the provisioning session.

The proposed renewal commands would perform the above tasks automatically and be able to detect the certificates that need renewal then when they get close to expiry. There also needs to be a m1-session del-certificate command to perform housekeeping on the certificates to get rid of any certificates (and keys) not needed anymore.

I'll close this ticket for the Release Candidate and raise a new one for the certificate renewal as a backlog issue.