Deprecation Notices

Ingress inbound-access schema change

Summary

We are renaming

application/services/ingress-ip-per-instance/access

to

application/services/ingress-ip-per-instance/inbound-access

This was necessary to better distinguish between inbound and outbound access. The original name did not clearly convey directionality. This became evident after introducing outbound‑access rules. The new name aligns with established terminology across the platform.

The field access will be renamed to inbound-access. Any application specification referencing the old name will fail after the enforcement date.

Key Dates

Event	Date
Deprecation Notice Published	2025‑05‑14
Enforcement Date	2025‑07‑13

Affected Interface(s)

• REST API
• supctl CLI

Migration Instructions

# BEFORE
services:
  - name: pop-service
    network:
      ingress-ip-per-instance:
        protocols:
          - name: tcp
            port-ranges: "9000"
        access:
          allow-all: true
      outbound-access:
        allow-all: true

# AFTER
services:
  - name: pop-service
    network:
      ingress-ip-per-instance:
        protocols:
          - name: tcp
            port-ranges: "9000"
        inbound-access:
          allow-all: true
      outbound-access:
        allow-all: true

Replace access: with inbound-access: under every ingress-ip-per-instance block in application specifications.

---

Resource profiles for application owners

Summary

Site providers can limit resource usage for application owner subtenants using resource profiles. These can be associated per tenant or per tenant and sites. In the latter case the resource profiles are associated to the assigned sites for the tenant. Assigned sites represent the sites that are visible for the application owner tenant. The application owner tenant can assign their own labels to an assigned site:

In the current version of the Avassa APIs, as a site provider if you want to restrict resource usage for a tenant for a specific site you name the resource profile directly under assigned-sites for that tenant:

% supctl -v show tenants app-developers assigned-sites robot-1 --fields name,resource-profile
Using profile testing.edge.avassa.dev.
GET /v1/state/tenants/app-developers/assigned-sites/robot-1?fields=name%2Cresource-profile
...

name: robot-1
resource-profile: small

Objects owned by the site provider for a tenant will move to assigned-site/settings in coming releases. In this way, objects owned by the application owner like labels are directly accessible at /tenants/{tenant-name}/assigned-sites/{assigned-site-name}/

Whereas objects managed by the site-provider are available at:

/tenants/{tenant-name}/assigned-sites/{assigned-site-name}/settings

Key Dates

Event	Date
Deprecation Notice Published	2025‑05‑14
Enforcement Date	2025‑07‑13

Affected Interface(s)

• REST API
• supctl CLI

Migration Instructions

Any supctl or REST API call to assign or view a resource profile for an application owner needs to add settings to the path.

/tenants/{tenant-name}/assigned-sites/{assigned-site-name}/

to

/tenants/{tenant-name}/assigned-sites/{assigned-site-name}/settings