Design and create new repo to store rates and invoicing policy changes

[knikolla]

Motivation

• Inputting rate values is a manual process and requires checking and copying the values from the NERC website.
• It makes it hard to track which rates are effective for which period of time. eg. price of A100 SU.
• It's hard to track which policy changes are effective from which date. eg. When to start charging for stopped instances.
• Can't plan changes in value ahead of time.

I propose the creation of a repository nerc-project/rates to store the above missing information.

A possible representation of that information may be (using YAML):

serviceUnitTypes:
  - name: OpenStack CPU
    resources: NERC OpenStack
    specifications:
      - memory: 4096
        vcpus: 1
        startDate: 2022-01-01
    rates:
      - rate: 1.13
        startDate: 2024-01-01
      - rate: 1.12
        startDate: 2023-01-01
        endDate: 2023-12-1

  - name: OpenStack GPUA100
    resources: NERC OpenStack
    specifications:
      - startDate: 2023-01-01
        pciDeviceName: A100
    rates:
      - rate: 100.13
        startDate: 2023-01-01

invoicingPolicies:
  - name: Charge for Stopped Instances
    resources: NERC OpenStack
    values:
      - value: True
        startDate: 2024-05-01
      - value: False
        startDate: 2023-01-01
        endDate: 2024-04-31

[knikolla]

@joachimweyl @Milstein @larsks @naved001 would appreciate your feedback on this.

[larsks]

I am generally in favor of the idea of machine-readable policy (and change control for policy decisions), so I am all for this idea!

I don't know enough about our billing model to comment on the specific example representation you've shown here. I would probably start with a higher level description of the information we want to represent and a description of how it would be consumed, and then use that to inform the design of an appropriate representation.

[joachimweyl]

I also like the idea. Let me know when you need the rates and I can provide them.

[joachimweyl]

Added a temporary estimate of 5, please feel free to change it if it is an inaccurate estimate.

[naved001]

@knikolla why should we have the start and end dates for rates in the manifest itself? Wouldn't the fact that it's checked into git help us track when the rates are changed?

I'd imagine that we create monthly releases from the rate repo and use that for producing a report, so if we wanted to regenerate an old report we can use the appropriate release from the rate repo. Thoughts?

[knikolla]

@naved001 Using the day of merge to git makes it hard to plan rate changes in the future as the change can't be merged until the day it becomes effective.

[knikolla]

Repo avalable at https://github.com/cci-moc/nerc-rates