Egress Billing Rollout [Parent]

[travis]

Rollout Plan

Phase 1

Egress Traffic Tracking Without Billing

During this phase, we will deploy the system to the Dev, Staging, and Production environments to begin tracking egress traffic without charging customers. This is possible because Stripe's new Billing Meter API allows us to record metrics for customers even if they are not associated with a price, which is critical for our existing customer base—we need to verify that everything is functioning correctly before initiating billing.

Tasks

• Implement a feature flag in the Freeway project to track egress traffic.
• Add GATEWAY_PRINCIPAL_KEY to the Freeway Staging deployment config (manually added).
• Deploy the system to the Staging environment.
• Conduct end-to-end testing in Staging to ensure all components work as expected.
• Loading test in Staging environment.
• Fix opentelemetry issue caused in the execution of the invocation #176
• Add GATEWAY_PRINCIPAL_KEY to the Freeway Production deployment config (manually added).
• Update the Production Stripe API with the new Billing Meter to track egress traffic.
• 🗂️ Infra to bill users for egress #135
• Deploy the egress billing system to the Production environment. #220
• Controlled rollout of traffic to new indexing service [Parent] #222
• Unify upload-service / w3up repos [Parent] #262
• Verify we are tracking egress traffic without billing customers #261

Phase 2

• Egress Rollout - Phase 2 - Billing Activation #187

[fforbeck]

Test Plan: Egress Tracking System – Rollout Phase 1

Objective

Validate the Egress Tracking System functionality in the staging environment without billing the customer. This test ensures that egress traffic is correctly recorded in the DynamoDB table and is properly sent to Stripe, linked to the customer account.

---

Scope

The test will:

• Verify content serving capability.
• Confirm egress events are recorded in the egress_traffic DynamoDB table.
• Ensure egress events are sent to Stripe, associated with the correct customer account.

---

Prerequisites

1. Access Requirements:

   • Ensure you have access to the Freeway staging environment.
   • Verify the local agent is configured and authenticated to the staging environment:

     export W3UP_SERVICE_DID=did:web:staging.web3.storage
     export W3UP_SERVICE_URL=https://staging.up.web3.storage
     export W3UP_RECEIPTS_ENDPOINT=https://staging.up.web3.storage

   • Add these env vars before authenticating your client. If you already authenticated without adding these env vars, make sure you backup your w3cli.json from the ~/.config/w3access:

   cd ~/.config/w3access
   cp w3cli.json w3cli.json-backup
   rm w3cli.json

   • And then authenticate the Agent again after exporting the new env vars. By default the Agent is authenticated to Production environment.

   w3 login user@domain

2. Scripts:

   • delegate-serve.js script in the Freeway is available and functioning.

3. Environment Configuration:

   • DynamoDB staging table (staging-w3infra-egress-traffic) is accessible.
   • Staging Stripe environment is configured with test API keys.

4. Required Details:

   • Content CID to test the serve functionality.
   • Staging Gateway URL: https://freeway-staging.dag.haus is up and running.

---

Test Steps

Step 1: Create a New Space

1. Run the delegate-serve.js script in the Freeway project:

   node delegate-serve.js --token=<YOUR_TOKEN> --accountDID=did:mailto:<DOMAIN>:<USER> --gatewayDID=did:web:staging.w3s.link

   • Expected Output:
     • The script creates a new "space".
     • Outputs a delegation stub required for the gateway request.

2. Confirm in the logs script delegation of the space/content/serve/* capability to the staging gateway, e.g:

   Delegation: space/content/serve/* with did:key:...

---

Step 2: Prepare Gateway Request

• Use the delegation stub generated in Step 1 as a query parameter in the gateway request.
• The request will simulate the delegation being retrieved by the gateway.

Example Request:

curl -X GET "https://freeway-staging.dag.haus/ipfs/<CONTENT_CID>?stub_space=did:key:<SPACE_ID>&stub_delegation=<DELEGATION>&authToken=<AUTH_TOKEN>"

Replace:

• <CONTENT_CID>: Content identifier.
• <SPACE_ID>: Space DID from generated by the script.
• <DELEGATION>: Stub delegation generated by the script.
• <AUTH_TOKEN>: Valid authentication token you provided to the delete_serve.js script.

---

Step 3: Validate the Results

Expected Results:

1. HTTP Response:

   • The content is successfully served.
   • The HTTP status code is 200.

2. DynamoDB Recording:

   • Check the staging-w3infra-egress-traffic table in DynamoDB for a new entry corresponding to the request:
     • Ensure it contains the SPACE, RESOURCE, SERVED_AT, BYTES, CUSTOMER and CAUSE attributes.

3. Stripe Integration:

   • Verify the egress event is sent to the test Stripe environment with the correct byte count.
   • Confirm the event is linked to the customer you found in staging-w3infra-egress-traffic.

Notes

• The test simulates a delegation retrieval process, which will be replaced with actual storage in future implementations.
• Billing functionality is not activated in this phase. Ensure that no charges are applied during the test.

[fforbeck]

To complete this task we need to complete:

• 🗂️ Infra to bill users for egress #135

[fforbeck]

Blocked:

• We need the Indexer Service running in production and retrieving content with the space info, and the consolidation of the w3up and upload-service repos must be completed.
• we are NOT going to get spaces from the indexer either until we finish the upload service / w3up merge and migrate over the changes to write directly into the indexer with spaces in the location claims.