SWATCH-2286: Change Billable Usage Remittance PK to UUID

[Sgitario]

Jira issue: SWATCH-2286

Description

Change the primary key of the to the billable usage remittance records to a UUID, plus existing uniqueness constraint should be maintained.

As part of this pull request, I also had to downgrade the version we're using of postgresql to use the same version than in the stage,prod and ephemeral environments. Before, we were using Postgresql 13 which had some functions to generate UUID that are not by default in Postgresql 12, so I could not spot this when building locally. Using the Postgresql 12 always is safer.

Testing

Setup

0.- podman-compose up
1.- ./gradlew liquibaseUpdate
2. Have some cost events from the past:

INSERT INTO public.events (event_id, timestamp, data, event_type, event_source, instance_id, org_id, metering_batch_id, record_date) VALUES ('527e29b6-321c-4021-a1f4-fcff4326ae2d', '2023-10-18 19:00:00.000000 +00:00', '{"sla": "Premium", "role": "Red Hat Enterprise Linux Server", "usage": "Production", "org_id": "13259775", "event_id": "527e29b6-321c-4021-a1f4-fcff4326ae2d", "timestamp": "2023-10-18T19:00:00Z", "event_type": "snapshot", "expiration": "2023-10-18T20:00:00Z", "instance_id": "i-0d8d5297e354051db", "product_ids": ["69", "204"], "event_source": "cost-management", "measurements": [{"uom": "vCPUs", "value": 1.0}], "service_type": "RHEL System", "hardware_type": "Cloud", "cloud_provider": "AWS", "billing_provider": "aws", "billing_account_id": "746157280291"}', 'snapshot', 'cost-management', 'i-0d8d5297e354051db', '13259775', null, '2023-10-19 15:05:25.594093 +00:00');
INSERT INTO public.events (event_id, timestamp, data, event_type, event_source, instance_id, org_id, metering_batch_id, record_date) VALUES ('bb9aaeb7-8013-412f-9b03-abc93f378585', '2023-10-18 18:00:00.000000 +00:00', '{"sla": "Premium", "role": "Red Hat Enterprise Linux Server", "usage": "Production", "org_id": "13259775", "event_id": "bb9aaeb7-8013-412f-9b03-abc93f378585", "timestamp": "2023-10-18T18:00:00Z", "event_type": "snapshot", "expiration": "2023-10-18T19:00:00Z", "instance_id": "i-0d8d5297e354051db", "product_ids": ["69", "204"], "event_source": "cost-management", "measurements": [{"uom": "vCPUs", "value": 1.0}], "service_type": "RHEL System", "hardware_type": "Cloud", "cloud_provider": "AWS", "billing_provider": "aws", "billing_account_id": "746157280291"}', 'snapshot', 'cost-management', 'i-0d8d5297e354051db', '13259775', null, '2023-10-19 15:05:25.593136 +00:00');
INSERT INTO public.events (event_id, timestamp, data, event_type, event_source, instance_id, org_id, metering_batch_id, record_date) VALUES ('2a3d273e-7811-4be8-b7b0-8304ac04c119', '2023-10-18 18:00:00.000000 +00:00', '{"sla": "Premium", "role": "Red Hat Enterprise Linux Server", "usage": "Production", "org_id": "13259775", "event_id": "2a3d273e-7811-4be8-b7b0-8304ac04c119", "timestamp": "2023-10-18T18:00:00Z", "event_type": "snapshot", "expiration": "2023-10-18T19:00:00Z", "instance_id": "i-0bfdf751c6b771e2f", "product_ids": ["69", "204"], "event_source": "cost-management", "measurements": [{"uom": "vCPUs", "value": 1.0}], "service_type": "RHEL System", "hardware_type": "Cloud", "cloud_provider": "AWS", "billing_provider": "aws", "billing_account_id": "746157280291"}', 'snapshot', 'cost-management', 'i-0bfdf751c6b771e2f', '13259775', null, '2023-10-19 15:05:26.095938 +00:00');

3. Have a subscription and offering:

INSERT INTO public.offering (sku, product_name, product_family, cores, sockets, hypervisor_cores, hypervisor_sockets, role, sla, usage, description, has_unlimited_usage, derived_sku) VALUES ('RH02781HR', 'RHEL Server', 'RHEL', null, 2, null, null, 'Red Hat Enterprise Linux Server', 'Premium', 'Production', 'Red Hat Enterprise Linux for Third Party Linux Migration with Extended Life Cycle Support (On-Demand, Hourly Production Support)', false, '');

INSERT INTO public.subscription (sku, org_id, subscription_id, quantity, start_date, end_date, billing_provider_id, subscription_number, billing_provider, billing_account_id) VALUES ('RH02781HR', '13259775', '12592043', 1, '2023-10-17 04:00:00.000000 +00:00', '2023-11-17 04:59:59.999000 +00:00', '9c9ediyijsij3tnxrtwfdqb7w;b44i9vdwLqs;568056954830', '12592200', 'aws', '746157280291');

Steps

1.Start three apps:
swatch-core:

RHSM_SUBSCRIPTIONS_ENABLE_SYNCHRONOUS_OPERATIONS=true DEV_MODE=true PROM_URL=http://localhost:8082/api/metrics/v1/telemeter/api/v1 SWATCH_CONTRACTS_INTERNAL_SERVICE=http://localhost:8882 SERVER_PORT=8001 SPRING_PROFILES_ACTIVE=worker,kafka-queue,api,capacity-ingress,rh-marketplace,kafka-queue,rhsm-conduit ./gradlew clean :bootRun

swatch-contract:

SERVER_PORT=8882 QUARKUS_MANAGEMENT_ENABLED=false ./gradlew  :swatch-contracts:quarkusDev

swatch-aws:

SWATCH_INTERNAL_SUBSCRIPTION_ENDPOINT=http://localhost:8001/api/rhsm-subscriptions/v1 QUARKUS_MANAGEMENT_ENABLED=false ./gradlew swatch-producer-aws:quarkusDev

2. Execute hourly tally:

http POST ":8001/api/rhsm-subscriptions/v1/internal/tally/hourly?org=13259775&start=2023-10-19T15:00Z&end=2023-10-19T16:00Z" x-rh-swatch-psk:placeholder

Verification

1. You should see new entries in the billable_usage_remittance table with the new column uuid populated.

[Sgitario]

For reviewers, the following item cannot be done because the result is an aggregation of billable usages, so we cannot provide the UUID of a single billable usage.

• OpenAPI update - billable usage responses for GET /internal/remittance/accountRemittances updated to show the UUID

[Sgitario]

About "Rollout plan needs to make sure this work does not try to deploy while billable usage is being calculated. ", the previous billable usage messages (without the uuid), it should work as expected, simply the uuid will be null. Therefore, I don't think we need a rollout plan here.

[barnabycourt]

@Sgitario Part of the done criteria states that "every existing billable usage remittance DB record has a UUID populated". Is there a part of the migration I am missing that takes care of this?

[Sgitario]

@Sgitario Part of the done criteria states that "every existing billable usage remittance DB record has a UUID populated". Is there a part of the migration I am missing that takes care of this?

Yes and no. I covered that part using the migration you see and I confirmed that populates the existing records, but after trying to fix the same migration for hsql, I accidentally removed the defaultComputedValue property... Will update the PR shortly.
Thanks for spotting

[Sgitario]

@Sgitario Part of the done criteria states that "every existing billable usage remittance DB record has a UUID populated". Is there a part of the migration I am missing that takes care of this?

Yes and no. I covered that part using the migration you see and I confirmed that populates the existing records, but after trying to fix the same migration for hsql, I accidentally removed the defaultComputedValue property... Will update the PR shortly. Thanks for spotting

PR updated.
The "defaultComputedValue" was working fine for postgresql, but definetively broken for HSQL, so I had to make the migration a little bit more complicated with up to 5 steps. I confirmed that this is working for stage data and it takes less than few seconds to finish.

[TrayvonMcKnight]

/retest

[mstead]

Functions correctly, but I'd like to see a couple things addressed:

1. The first commit in this PR (downgrade postgresql instance to 12) should have some context in the commit message as to why this change was required. Does this relate to SWATCH-2286?

2. Is there a reason why the uuid is generated with @PrePersist instead of simply annotating the uuid field with @GeneratedValue(strategy = GenerationType.AUTO)? Using @GeneratedValue seems a little cleaner IMO.

[Sgitario]

Functions correctly, but I'd like to see a couple things addressed:

1. The first commit in this PR (downgrade postgresql instance to 12) should have some context in the commit message as to why this change was required. Does this relate to SWATCH-2286?

Added

2. Is there a reason why the uuid is generated with @PrePersist instead of simply annotating the uuid field with @GeneratedValue(strategy = GenerationType.AUTO)? Using @GeneratedValue seems a little cleaner IMO.

At first, I tried with @GeneratedValue and didn't work on tests, but I think I was using a test without the SpringBoot context and that's why. As you said, @GeneratedValue should be the way to go. Changed and thanks for spotting!

PR updated with these two changes.

[barnabycourt]

Has this upgrade been tested against a prod sized dataset to determine how long the migration might take?

[Sgitario]

Has this upgrade been tested against a prod sized dataset to determine how long the migration might take?

It was tested using Stage that has 90k records. Using the prod data that has 141k records took around 5-6 seconds in total:

Running Changeset: liquibase/202403131500-change-pk-from-billable-usage-remittance.xml::202403131500-1::jcarvaja
[2024-03-18 06:16:34] INFO [liquibase.ui] Running Changeset: liquibase/202403131500-change-pk-from-billable-usage-remittance.xml::202403131500-1::jcarvaja
[2024-03-18 06:16:34] INFO [liquibase.changelog] Primary key dropped from billable_usage_remittance
[2024-03-18 06:16:35] INFO [liquibase.changelog] Unique constraint added to billable_usage_remittance(org_id, product_id, metric_id, accumulation_period, sla, usage, billing_provider,billing_account_id, remittance_pending_date)
[2024-03-18 06:16:35] INFO [liquibase.changelog] ChangeSet liquibase/202403131500-change-pk-from-billable-usage-remittance.xml::202403131500-1::jcarvaja ran successfully in 1298ms
Running Changeset: liquibase/202403131500-change-pk-from-billable-usage-remittance.xml::202403131500-2::jcarvaja
[2024-03-18 06:16:35] INFO [liquibase.ui] Running Changeset: liquibase/202403131500-change-pk-from-billable-usage-remittance.xml::202403131500-2::jcarvaja
[2024-03-18 06:16:35] INFO [liquibase.changelog] Columns uuid(UUID) added to billable_usage_remittance
[2024-03-18 06:16:35] INFO [liquibase.changelog] ChangeSet liquibase/202403131500-change-pk-from-billable-usage-remittance.xml::202403131500-2::jcarvaja ran successfully in 4ms
Running Changeset: liquibase/202403131500-change-pk-from-billable-usage-remittance.xml::202403131500-3::jcarvaja
[2024-03-18 06:16:35] INFO [liquibase.ui] Running Changeset: liquibase/202403131500-change-pk-from-billable-usage-remittance.xml::202403131500-3::jcarvaja
[2024-03-18 06:16:39] INFO [liquibase.changelog] Custom SQL executed
[2024-03-18 06:16:39] INFO [liquibase.changelog] ChangeSet liquibase/202403131500-change-pk-from-billable-usage-remittance.xml::202403131500-3::jcarvaja ran successfully in 4137ms
Running Changeset: liquibase/202403131500-change-pk-from-billable-usage-remittance.xml::202403131500-5::jcarvaja
[2024-03-18 06:16:39] INFO [liquibase.ui] Running Changeset: liquibase/202403131500-change-pk-from-billable-usage-remittance.xml::202403131500-5::jcarvaja
[2024-03-18 06:16:40] INFO [liquibase.changelog] Primary key added to billable_usage_remittance (uuid)
[2024-03-18 06:16:40] INFO [liquibase.changelog] ChangeSet liquibase/202403131500-change-pk-from-billable-usage-remittance.xml::202403131500-5::jcarvaja ran successfully in 315ms

[TrayvonMcKnight]

/retest

[Sgitario]

/retest

[TrayvonMcKnight]

https://drive.google.com/file/d/1xJp8NVKGCr-TpKTSBfhc5cHwLOO_gTP_/view?usp=drive_link

IQE Testing Steps

1. application.rhsm_subscriptions.create_mock_subscription( product_id=product_id, billing_provider=billing_provider, billing_account_id=billing_account_id, start_day=(datetime.date.today() - datetime.timedelta(days=10)).strftime("%Y-%m-%d"), )

2. application.rhsm_subscriptions.create_metering_event( product_id=product_id, **data )

3. application.rhsm_subscriptions.sync_tally_hourly( product_id=product_id, perform_metering=False, wait=True, wait_for_remittance=True )

4. application.rhsm_subscriptions.get_account_remittance( product_id=product_id, metricId=metric, billingProvider=billing_provider, billingAccountId=billing_account_id, )

UUID present in the remittance records.