Yoke metrics to app context - backend changes

[amurphy-cl]

Currently, when UpGrade is used with multiple app contexts, all metrics from all contexts are visible to the user. Metrics should be specific to the app context, and when defining metrics within an experiment, the user should not see metrics for different app contexts other than the one defined for a given experiment.

Add app context to metrics structure. Metrics will not share app contexts.

Notes from the meeting

• Add new key to json structure that contains app-context
• Backwards compatibility
  • Logging won’t check app context when importing old experiments
  • We will remove and redefine metrics according to context, since data is already there, rather than support backwards compatibility
• Importing old experiments
  • Will error if metrics are not present in schema
  • Metrics queries are imported currently, will continue to import

[amurphy-cl]

@VivekFitkariwala any other refinement needed here?

[VivekFitkariwala]

This restriction should not be applied when adding logs because that will break the existing experiments.

@amurphy-cl this is good.

[VivekFitkariwala]

For the structure of the post Metrics we have two structures

{
MetricUnit : [{
 groupClass: 'groupClass1',
 allowedKeys: ['allowedKey1'],
 attributes: [{
   metric: 'metric1',
   key: 'key1',
   datatype: 'datatype1',
   allowedValues: ['allowedValue1']
 }]
}]
context: ['context1']
}

The context is common for all the Metrics

The second one

MetricUnit : [{
 groupClass: 'groupClass1',
 context: ['context1']
 allowedKeys: ['allowedKey1'],
 attributes: [{
   metric: 'metric1',
   key: 'key1',
   context: ['context1']
   datatype: 'datatype1',
   allowedValues: ['allowedValue1']
 }]
}]

The context is per Metrics

cc - @amurphy-cl @danoswaltCL @bcb37 @RidhamShah

[VivekFitkariwala]

In the client lib should we update the addMetrics or are we going to remove this from client lib? Based on this issue

cc - @amurphy-cl @bcb37 @danoswaltCL @RidhamShah

[danoswaltCL]

My view is that we either have to remove it or expand it, just "add" isn't really enough for giving the client the tools to manage their metrics.

I think it may be simpler to remove this capability if there isn't a good use case for why this is easier than 'admin' CRUD operations, it's already a little odd to have 2 endpoints do exactly the same thing.

"Who" is authorized to change metrics state for that app-context, a google-authenticated individual user using a Google-Credential generated token, or a client-application system user using our API Token?

[amurphy-cl]

Decision: use first structure so metrics will be exclusive to context. Also will remove addMetrics from the client library.

[RidhamShah]

@amurphy-cl @danoswaltCL Do we want to use pre-defined metrics from the .env file. If yes, then we may need to update it as it should contain context now.

[danoswaltCL]

yeah it's definitely useful for dev/testing at least so we don't have to reload metrics when destroying dbs, so let's update it. We'll update in our env configs.

[RidhamShah]

The new metrics structure of env file

METRICS = [
     {
          metrics: [
               {
                    metric: totalTimeSeconds, 
                    datatype: 'continuous'
               },
               {
                    metric: 'workspaceCompletionStatus',
                    ...
               },
               {
                    groupClass: 'addWorkspace',
                    allowedKeys: ['level1', 'level2'],
                    ...
               }
          ],
          contexts: [ context1, context2 ]
     },
     {
          metrics: [ ... ]
          contexts: [ ... ]
     }
]

[ppratikcr7]

@danoswaltCL QA: Seems to work as expected. The context chip based click and search doesn't seem to work. We do have this feature in Experiment, Segment & Feature Flag Pages. Should we create another ticket for this?

[ppratikcr7]

Creating a separate ticket for the above issue.

[ppratikcr7]

QA passed.