Provide decorators to include the Region and Cloud platform into the emitted events

[voropaevp]

There is no way to include the cloud platform-dependent information into the emitted events.

The suggestion is to add the helper methods for the Subject

• includeCloudRegion( ): Subject - injecting the "region" : string
• includeCloudPlatform( ): Subject - injecting the "region" : enum [ 'gcp', 'aws', null ]

This could be achieved by querying cloud URLs:

• GCP
• AWS
• Addition research is required to identify, methods that are going to work for all deployment types: Kafka, containers, etc.

This functionality will be used by:
snowplow/stream-collector#167
And in other snowplow components, that will use telemetry.

[colmsnowplow]

It seems to me that this is achievable already without a change to the tracker, by adding this information via a custom context.

I think an argument to consider on the topic is that the scala tracker is intended for use in any scala project, and this kind of feature feels specific to a particular set of deployments.

Not that I think this should be the definitive argument, I'd just like to beg the question - is there a good case for instrumenting this as a method of the tracker vs. as a custom event? (or is there a good case vice-versa?)

[colmsnowplow]

I hadn't realised that we already have a module which establishes something of a precedent for this kind of feature: https://github.com/snowplow/snowplow-scala-tracker/tree/master/modules/metadata/src/main/scala/com/snowplowanalytics/snowplow/scalatracker/metadata

I think as long as we gracefully/sensibly handle the case where a method like this is called in some other environment (which doesn't support these things), there's no harm in adding to it. (and I presume the existing design does so)

[voropaevp]

Would the AWS module handle Kafka or EKS deployments?

[colmsnowplow]

I would imagine that we'd need to write something to accommodate Kafka and possibly EKS. Whether that's adapting the existing code or adding new code, I don't know - that surely depends on the detail.

All I'm suggesting is that the most obvious way to extend this feature is to do so using the existing module.