TTGC LBS CUPS Claimer

[vlasebian]

Summary

Add support for TTGC root LBS CUPS.

Changes

• Implement Update method in DCS gateway registry
• Move the gateway Create call before the claim call in the GRPC handler (CUPS API key needs a gateway ID to be created)
• Implement LBS CUPS claimer
• Add two extra configuration values in the TTGC config

Testing

Steps

...

Results

Regressions

...

Notes for Reviewers

I made some changes to the existing flow for claiming in the first two commits (it also affects ttigpros). Now the gateway is created first in the registry before claiming, not after claiming. Without it I cannot implement the Claimer interface for LBS CUPS because the API key that is created for CUPS cannot be created without an existing gateway ID.

The downside to this approach is that there is an extra call made to the IS, but gateway creation is not an intensively used flow.

The other option was to implement the upstream in a similar pattern to the rjs legacy upstream that is planned for removal. Given that, I assumed that's not the way to go about it.

Checklist

• Scope: The referenced issue is addressed, there are no unrelated changes.
• Compatibility: The changes are backwards compatible with existing API, storage, configuration and CLI, according to the compatibility commitments in README.md for the chosen target branch.
• Documentation: Relevant documentation is added or updated.
• Testing: The steps/process to test this feature are clearly explained including testing for regressions.
• Infrastructure: If infrastructural changes (e.g., new RPC, configuration) are needed, a separate issue is created in the infrastructural repositories.
• Changelog: Significant features, behavior changes, deprecations and fixes are added to CHANGELOG.md.
• Commits: Commit messages follow guidelines in CONTRIBUTING.md, there are no fixup commits left.

[vlasebian]

Blocked by https://github.com/TheThingsIndustries/gateway/pull/122.

[vlasebian]

This is not tested e2e yet, I need the PRs in ttgc to be merged yet (the jobs are failing because of the missing GatewayToken in the proto generated files). However I think it's complete enough for a review.

[johanstokking]

The Things Stack is not concerned with LBS CUPS. This adds unnecessary duplication.

From what I see at first glance, is the difference between the existing claim and the newly added logic: 1) the protocol is different and 2) an API key is created (and deleted).

That does not justify new config and a separate claiming process.

Yes, TTS needs to know the protocol to set. And, depending on the protocol, or next to knowing what the protocol is, whether or not an gateway API key needs to be created.

We have two options here:

1. Map EUI range with protocol + whether or not API key needs to be created in TTS.
2. Endpoint in TTGC to return what the protocol is and whether or not a gateway token is required based on a given EUI.

Option 2 is cleanest and more useful also for V4.

[vlasebian]

Okay, I see. I will reevaluate the implementation and drop the new claimer and enhance the existing one. I also like the second option more.

Endpoint in TTGC to return what the protocol is and whether or not a gateway token is required based on a given EUI.

How do you see this call?

If TTS is already authenticated with TTGC through mTLS (correct me if I'm wrong) I guess we can make a GET call to check if the gateway is managed & claimable, and to return the capabilities of that gateway and the protocols it supports. Afterwards we make a claim with all the data TTGC needs for the gateway, for that specific protocol.

Another option would be to modify the Claim response to return the capabilities of the claimed gateway (e.g. all the protocols it supports) and then let TTS update the gateway in TTGC with whatever is needed, in this case the gateway token.

I like option one better because we separate the requirements fetching from the claim itself, but we have to enhance the claim with whatever protocols need. Second option keeps the Claim cleaner.

@johanstokking what do you think?

[johanstokking]

I also prefer option 1.

Indeed this information is required for the LoRa Packet Forwarder profile; not for the claim itself. Maybe you can add an rpc to get the capabilities. This would include the supported protocols (can be multiple). I.e. a list of supported protocols, with a boolean whether a gateway token is required.

Please start with a draft PR with just the API in the concerning repository.