Uploaded image for project: 'Subscription Watch'
  1. Subscription Watch
  2. SWATCH-1202

Implement subscription_measurements table

XMLWordPrintable

    • False
    • Hide

      None

      Show
      None
    • False
    • BIZ-610 - ROSA-HCP

      As a developer, I want subscription data structures to support measurements other than sockets/cores, so that I can store both SaaS contract subscription data and traditional RHEL, OpenShift, etc. subscription data in the same place, and so that the subscription API can be updated to support more metrics.

      Create a new table subscription_measurements having the following columns:

      PK? Column name type comments
      Y subscription_id varchar(255) FK to subscription
      Y start_date Timestamp with time zone FK to subscription
      Y metric_id varchar(255) Swatch-specific metric identifier
      Y measurement_type varchar(255) Used to record hypervisor or other categories of measurement
        value Double precision The provided capacity

      Populate the table from existing data in subscription_capacity, according to the following logic:

      subscription_capacity column Resulting row comments
      sockets metric_id: SOCKETS
      measurement_type: PHYSICAL
      value: $sockets
      Create row if sockets > 0
      hypervisor_sockets metric_id: SOCKETS
      measurement_type: HYPERVISOR
      value: $hypervisor_sockets
      Create row if hypervisor_sockets > 0
      cores metric_id: CORES
      measurement_type: PHYSICAL
      value: $cores
      Create row if cores > 0
      hypervisor_cores metric_id: CORES
      measurement_type: HYPERVISOR
      value: $hypervisor_cores
      Create row if hypervisor_cores > 0

      Add has_unlimited_usage column to the subscription table, and populate it via values in subscription_capacity.

      Afterwards, refactor the subscription_capacity table:

      • remove primary key
      • drop all columns, except for product_id, subscription_id, and begin_date
      • rename begin_date to start_date for consistency
      • set primary key to product_id, subscription_id, start_date
      • make primary key a foreign key to subscriptions
      • rename the table to subscription_product_ids

      DONE:

      • DB changes implemented as liquibase migrations
      • JPA entities created & updated
      • queries updated to use the new tables/entities=
      • Update rhsm-subscriptions-egress to add the new subscriptions_measurements table

      TODO: determine the fate of subscription_capacity_view

      QE:
      Regression Test should be sufficient

              awood1@redhat.com Alex Wood
              khowell@redhat.com Kevin Howell
              Trayvon McKnight Trayvon McKnight
              Votes:
              0 Vote for this issue
              Watchers:
              5 Start watching this issue

                Created:
                Updated:
                Resolved: