Validating resource specific submissions

[rajkiranrbala]

Though there is a schema defined for resource usage, currently there is no strict way to validate the measures in it. Some resources might need all measures to be submitted all times, but some doesn't.

For example linux-container always needs all the four measures to be submitted at all times

1. current_instance_memory
2. current_running_instances
3. previous_instance_memory
4. previous_running_instances

However object-storage can have any or all of the three measures submitted

1. storage
2. light_api_calls
3. heavy_api_calls

If the metering definition can include an optional field called required as a part of each measure, so that the measures in the submitted usage can be validated.

  measures: [
    {
      name: 'current_instance_memory',
      unit: 'GIGABYTE',
      required: true
    },
    ...],

[cf-gitbot]

We have created an issue in Pivotal Tracker to manage this. You can view the current status of your issue at: https://www.pivotaltracker.com/story/show/118704481.

[KRuelY]

I feel like what you mean is to introduce "bundle" of measure for a metric.

Consider a resource definition where you have 3 measures and 2 metrics: measures:

1. measure A
2. measure B
3. measure C metrics:
4. metric X
5. metric Y

Metric X's meter function requires 2 measures: measure A and measure B.

Metric Y only need measure C.

Require field in measure A and measure B would means we cannot submit measure C without submitting measure A and measure B. So what we need is to bundle measure A and measure B.

[jsdelfino]

AFAIK your meter functions are passed all the measures, so the simple solution here is to just check the presence of the required measures in your meter function and report an error if they're missing. That'll also be consistent with the other errors you'll need to report if for example a particular measure is present but missing some of information required to compute the metric.

[hsiliev]

We should do minimal validation: at least one of the measures in the plan should be present.

Broker creates sample plans that users have to edit. If they forgot to do that Abacus should provide meaningful error. ATM we simply return 201 without business error.

[cf-gitbot]

We have created an issue in Pivotal Tracker to manage this:

https://www.pivotaltracker.com/story/show/151755339

The labels on this github issue will be updated when the story is started.