@leaflow/sdk 0.162.0 → 0.163.0
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/dist/billing/v1/generated/functions.d.ts +3 -52
- package/dist/billing/v1/generated/functions.js +2 -79
- package/dist/billing/v1/generated/models.d.ts +61 -112
- package/dist/billing/v1/generated/schemas.zod.d.ts +0 -30
- package/dist/billing/v1/generated/schemas.zod.js +0 -46
- package/dist/billing/v1/generated/validators/price.zod.d.ts +39 -6
- package/dist/billing/v1/generated/validators/price.zod.js +5 -5
- package/dist/billing/v1/generated/validators/priceList.zod.d.ts +39 -6
- package/dist/billing/v1/generated/validators/priceSearch.zod.d.ts +2 -0
- package/dist/billing/v1/generated/validators/priceSearch.zod.js +7 -0
- package/dist/canopy/v1/generated/functions.d.ts +1 -1
- package/dist/canopy/v1/generated/functions.js +1 -1
- package/dist/canopy/v1/generated/models.d.ts +1 -1
- package/dist/canopy/v1/generated/validators/modelBilling.zod.js +1 -1
- package/dist/compute/v1/generated/functions.d.ts +1 -1
- package/dist/compute/v1/generated/models.d.ts +2 -2
- package/dist/compute/v1/generated/schemas.zod.d.ts +1 -1
- package/dist/compute/v1/generated/schemas.zod.js +1 -1
- package/dist/compute/v1/generated/validators/allocateFloatingIPRequestBody.zod.d.ts +1 -1
- package/dist/compute/v1/generated/validators/allocateFloatingIPRequestBody.zod.js +1 -1
- package/dist/compute/v1/generated/validators/allocateFloatingIPResponseBody.zod.d.ts +1 -1
- package/dist/compute/v1/generated/validators/allocateFloatingIPResponseBody.zod.js +1 -1
- package/dist/compute/v1/generated/validators/attachDiskRequestBody.zod.d.ts +1 -1
- package/dist/compute/v1/generated/validators/attachDiskRequestBody.zod.js +1 -1
- package/dist/compute/v1/generated/validators/attachFloatingIPRequestBody.zod.d.ts +1 -1
- package/dist/compute/v1/generated/validators/attachFloatingIPRequestBody.zod.js +1 -1
- package/dist/compute/v1/generated/validators/attachPortRequestBody.zod.d.ts +1 -1
- package/dist/compute/v1/generated/validators/attachPortRequestBody.zod.js +1 -1
- package/dist/compute/v1/generated/validators/backupCapacityPack.zod.d.ts +1 -1
- package/dist/compute/v1/generated/validators/backupCapacityPack.zod.js +1 -1
- package/dist/compute/v1/generated/validators/backupCapacityPackListResponseBody.zod.d.ts +1 -1
- package/dist/compute/v1/generated/validators/backupCapacityPackListResponseBody.zod.js +1 -1
- package/dist/compute/v1/generated/validators/backupListResponseBody.zod.d.ts +1 -1
- package/dist/compute/v1/generated/validators/backupListResponseBody.zod.js +1 -1
- package/dist/compute/v1/generated/validators/backupOperation.zod.d.ts +1 -1
- package/dist/compute/v1/generated/validators/backupOperation.zod.js +1 -1
- package/dist/compute/v1/generated/validators/backupResource.zod.d.ts +1 -1
- package/dist/compute/v1/generated/validators/backupResource.zod.js +1 -1
- package/dist/compute/v1/generated/validators/backupService.zod.d.ts +1 -1
- package/dist/compute/v1/generated/validators/backupService.zod.js +1 -1
- package/dist/compute/v1/generated/validators/billingChoice.zod.d.ts +1 -1
- package/dist/compute/v1/generated/validators/billingChoice.zod.js +1 -1
- package/dist/compute/v1/generated/validators/billingComponent.zod.d.ts +1 -1
- package/dist/compute/v1/generated/validators/billingComponent.zod.js +2 -2
- package/dist/compute/v1/generated/validators/billingMeter.zod.d.ts +1 -1
- package/dist/compute/v1/generated/validators/billingMeter.zod.js +1 -1
- package/dist/compute/v1/generated/validators/billingPeriod.zod.d.ts +1 -1
- package/dist/compute/v1/generated/validators/billingPeriod.zod.js +1 -1
- package/dist/compute/v1/generated/validators/billingQuantity.zod.d.ts +1 -1
- package/dist/compute/v1/generated/validators/billingQuantity.zod.js +1 -1
- package/dist/compute/v1/generated/validators/bindFloatingIPRequestBody.zod.d.ts +1 -1
- package/dist/compute/v1/generated/validators/bindFloatingIPRequestBody.zod.js +1 -1
- package/dist/compute/v1/generated/validators/bootDisk.zod.d.ts +1 -1
- package/dist/compute/v1/generated/validators/bootDisk.zod.js +1 -1
- package/dist/compute/v1/generated/validators/cancellationMode.zod.d.ts +1 -1
- package/dist/compute/v1/generated/validators/cancellationMode.zod.js +1 -1
- package/dist/compute/v1/generated/validators/checkoutMode.zod.d.ts +1 -1
- package/dist/compute/v1/generated/validators/checkoutMode.zod.js +1 -1
- package/dist/compute/v1/generated/validators/checkoutOptions.zod.d.ts +1 -1
- package/dist/compute/v1/generated/validators/checkoutOptions.zod.js +1 -1
- package/dist/compute/v1/generated/validators/commandResultResponseBody.zod.d.ts +1 -1
- package/dist/compute/v1/generated/validators/commandResultResponseBody.zod.js +1 -1
- package/dist/compute/v1/generated/validators/consoleOutputResponseBody.zod.d.ts +1 -1
- package/dist/compute/v1/generated/validators/consoleOutputResponseBody.zod.js +1 -1
- package/dist/compute/v1/generated/validators/consoleResponseBody.zod.d.ts +1 -1
- package/dist/compute/v1/generated/validators/consoleResponseBody.zod.js +1 -1
- package/dist/compute/v1/generated/validators/createBackupCapacityPackRequestBody.zod.d.ts +1 -1
- package/dist/compute/v1/generated/validators/createBackupCapacityPackRequestBody.zod.js +1 -1
- package/dist/compute/v1/generated/validators/createBackupCapacityPackResponseBody.zod.d.ts +1 -1
- package/dist/compute/v1/generated/validators/createBackupCapacityPackResponseBody.zod.js +1 -1
- package/dist/compute/v1/generated/validators/createBackupRequestBody.zod.d.ts +1 -1
- package/dist/compute/v1/generated/validators/createBackupRequestBody.zod.js +1 -1
- package/dist/compute/v1/generated/validators/createBackupServiceRequestBody.zod.d.ts +1 -1
- package/dist/compute/v1/generated/validators/createBackupServiceRequestBody.zod.js +1 -1
- package/dist/compute/v1/generated/validators/createBackupServiceResponseBody.zod.d.ts +1 -1
- package/dist/compute/v1/generated/validators/createBackupServiceResponseBody.zod.js +1 -1
- package/dist/compute/v1/generated/validators/createDiskRequestBody.zod.d.ts +1 -1
- package/dist/compute/v1/generated/validators/createDiskRequestBody.zod.js +1 -1
- package/dist/compute/v1/generated/validators/createDiskResponseBody.zod.d.ts +1 -1
- package/dist/compute/v1/generated/validators/createDiskResponseBody.zod.js +1 -1
- package/dist/compute/v1/generated/validators/createImageRequestBody.zod.d.ts +1 -1
- package/dist/compute/v1/generated/validators/createImageRequestBody.zod.js +1 -1
- package/dist/compute/v1/generated/validators/createImageResponseBody.zod.d.ts +1 -1
- package/dist/compute/v1/generated/validators/createImageResponseBody.zod.js +1 -1
- package/dist/compute/v1/generated/validators/createPeeringRequestBody.zod.d.ts +1 -1
- package/dist/compute/v1/generated/validators/createPeeringRequestBody.zod.js +1 -1
- package/dist/compute/v1/generated/validators/createPortRequestBody.zod.d.ts +1 -1
- package/dist/compute/v1/generated/validators/createPortRequestBody.zod.js +1 -1
- package/dist/compute/v1/generated/validators/createPrivateNetworkRequestBody.zod.d.ts +1 -1
- package/dist/compute/v1/generated/validators/createPrivateNetworkRequestBody.zod.js +1 -1
- package/dist/compute/v1/generated/validators/createRouteRequestBody.zod.d.ts +1 -1
- package/dist/compute/v1/generated/validators/createRouteRequestBody.zod.js +1 -1
- package/dist/compute/v1/generated/validators/createSecurityGroupRequestBody.zod.d.ts +1 -1
- package/dist/compute/v1/generated/validators/createSecurityGroupRequestBody.zod.js +1 -1
- package/dist/compute/v1/generated/validators/createSecurityRuleRequestBody.zod.d.ts +1 -1
- package/dist/compute/v1/generated/validators/createSecurityRuleRequestBody.zod.js +1 -1
- package/dist/compute/v1/generated/validators/createSnapshotRequestBody.zod.d.ts +1 -1
- package/dist/compute/v1/generated/validators/createSnapshotRequestBody.zod.js +1 -1
- package/dist/compute/v1/generated/validators/createSubnetRequestBody.zod.d.ts +1 -1
- package/dist/compute/v1/generated/validators/createSubnetRequestBody.zod.js +1 -1
- package/dist/compute/v1/generated/validators/cursorPagination.zod.d.ts +1 -1
- package/dist/compute/v1/generated/validators/cursorPagination.zod.js +1 -1
- package/dist/compute/v1/generated/validators/deleteBackupCapacityPackParams.zod.d.ts +1 -1
- package/dist/compute/v1/generated/validators/deleteBackupCapacityPackParams.zod.js +1 -1
- package/dist/compute/v1/generated/validators/deleteBackupServiceParams.zod.d.ts +1 -1
- package/dist/compute/v1/generated/validators/deleteBackupServiceParams.zod.js +1 -1
- package/dist/compute/v1/generated/validators/deleteDiskParams.zod.d.ts +1 -1
- package/dist/compute/v1/generated/validators/deleteDiskParams.zod.js +1 -1
- package/dist/compute/v1/generated/validators/deleteDiskResponseBody.zod.d.ts +1 -1
- package/dist/compute/v1/generated/validators/deleteDiskResponseBody.zod.js +1 -1
- package/dist/compute/v1/generated/validators/deleteImageParams.zod.d.ts +1 -1
- package/dist/compute/v1/generated/validators/deleteImageParams.zod.js +1 -1
- package/dist/compute/v1/generated/validators/deleteImageResponseBody.zod.d.ts +1 -1
- package/dist/compute/v1/generated/validators/deleteImageResponseBody.zod.js +1 -1
- package/dist/compute/v1/generated/validators/deleteInstanceParams.zod.d.ts +1 -1
- package/dist/compute/v1/generated/validators/deleteInstanceParams.zod.js +1 -1
- package/dist/compute/v1/generated/validators/deleteInstanceResponseBody.zod.d.ts +1 -1
- package/dist/compute/v1/generated/validators/deleteInstanceResponseBody.zod.js +1 -1
- package/dist/compute/v1/generated/validators/deleteSnapshotQuotaParams.zod.d.ts +1 -1
- package/dist/compute/v1/generated/validators/deleteSnapshotQuotaParams.zod.js +1 -1
- package/dist/compute/v1/generated/validators/diskAttachment.zod.d.ts +1 -1
- package/dist/compute/v1/generated/validators/diskAttachment.zod.js +1 -1
- package/dist/compute/v1/generated/validators/diskAttachmentList.zod.d.ts +1 -1
- package/dist/compute/v1/generated/validators/diskAttachmentList.zod.js +1 -1
- package/dist/compute/v1/generated/validators/diskListResponseBody.zod.d.ts +1 -1
- package/dist/compute/v1/generated/validators/diskListResponseBody.zod.js +1 -1
- package/dist/compute/v1/generated/validators/diskOperation.zod.d.ts +1 -1
- package/dist/compute/v1/generated/validators/diskOperation.zod.js +1 -1
- package/dist/compute/v1/generated/validators/diskResource.zod.d.ts +1 -1
- package/dist/compute/v1/generated/validators/diskResource.zod.js +1 -1
- package/dist/compute/v1/generated/validators/diskTypeListResponseBody.zod.d.ts +1 -1
- package/dist/compute/v1/generated/validators/diskTypeListResponseBody.zod.js +1 -1
- package/dist/compute/v1/generated/validators/diskTypePurpose.zod.d.ts +1 -1
- package/dist/compute/v1/generated/validators/diskTypePurpose.zod.js +1 -1
- package/dist/compute/v1/generated/validators/diskTypeResource.zod.d.ts +1 -1
- package/dist/compute/v1/generated/validators/diskTypeResource.zod.js +1 -1
- package/dist/compute/v1/generated/validators/error.zod.d.ts +1 -1
- package/dist/compute/v1/generated/validators/error.zod.js +1 -1
- package/dist/compute/v1/generated/validators/existingBootDisk.zod.d.ts +1 -1
- package/dist/compute/v1/generated/validators/existingBootDisk.zod.js +1 -1
- package/dist/compute/v1/generated/validators/floatingIPListResponseBody.zod.d.ts +1 -1
- package/dist/compute/v1/generated/validators/floatingIPListResponseBody.zod.js +1 -1
- package/dist/compute/v1/generated/validators/floatingIPOperation.zod.d.ts +1 -1
- package/dist/compute/v1/generated/validators/floatingIPOperation.zod.js +1 -1
- package/dist/compute/v1/generated/validators/floatingIPResource.zod.d.ts +1 -1
- package/dist/compute/v1/generated/validators/floatingIPResource.zod.js +1 -1
- package/dist/compute/v1/generated/validators/getInstanceConsoleOutputParams.zod.d.ts +1 -1
- package/dist/compute/v1/generated/validators/getInstanceConsoleOutputParams.zod.js +1 -1
- package/dist/compute/v1/generated/validators/iPv4Binding.zod.d.ts +1 -1
- package/dist/compute/v1/generated/validators/iPv4Binding.zod.js +1 -1
- package/dist/compute/v1/generated/validators/iPv4PoolListResponseBody.zod.d.ts +1 -1
- package/dist/compute/v1/generated/validators/iPv4PoolListResponseBody.zod.js +1 -1
- package/dist/compute/v1/generated/validators/iPv4PoolResource.zod.d.ts +1 -1
- package/dist/compute/v1/generated/validators/iPv4PoolResource.zod.js +1 -1
- package/dist/compute/v1/generated/validators/iPv6ResponseBody.zod.d.ts +1 -1
- package/dist/compute/v1/generated/validators/iPv6ResponseBody.zod.js +1 -1
- package/dist/compute/v1/generated/validators/imageListResponseBody.zod.d.ts +1 -1
- package/dist/compute/v1/generated/validators/imageListResponseBody.zod.js +1 -1
- package/dist/compute/v1/generated/validators/imageOperation.zod.d.ts +1 -1
- package/dist/compute/v1/generated/validators/imageOperation.zod.js +1 -1
- package/dist/compute/v1/generated/validators/imageResource.zod.d.ts +1 -1
- package/dist/compute/v1/generated/validators/imageResource.zod.js +1 -1
- package/dist/compute/v1/generated/validators/imageVisibility.zod.d.ts +1 -1
- package/dist/compute/v1/generated/validators/imageVisibility.zod.js +1 -1
- package/dist/compute/v1/generated/validators/instanceListResponseBody.zod.d.ts +1 -1
- package/dist/compute/v1/generated/validators/instanceListResponseBody.zod.js +1 -1
- package/dist/compute/v1/generated/validators/instanceOperation.zod.d.ts +1 -1
- package/dist/compute/v1/generated/validators/instanceOperation.zod.js +1 -1
- package/dist/compute/v1/generated/validators/instanceResource.zod.d.ts +1 -1
- package/dist/compute/v1/generated/validators/instanceResource.zod.js +1 -1
- package/dist/compute/v1/generated/validators/instanceRestriction.zod.d.ts +1 -1
- package/dist/compute/v1/generated/validators/instanceRestriction.zod.js +1 -1
- package/dist/compute/v1/generated/validators/instanceTypeListResponseBody.zod.d.ts +1 -1
- package/dist/compute/v1/generated/validators/instanceTypeListResponseBody.zod.js +1 -1
- package/dist/compute/v1/generated/validators/instanceTypeResource.zod.d.ts +1 -1
- package/dist/compute/v1/generated/validators/instanceTypeResource.zod.js +1 -1
- package/dist/compute/v1/generated/validators/launchInstanceRequestBody.zod.d.ts +1 -1
- package/dist/compute/v1/generated/validators/launchInstanceRequestBody.zod.js +1 -1
- package/dist/compute/v1/generated/validators/launchInstanceResponseBody.zod.d.ts +1 -1
- package/dist/compute/v1/generated/validators/launchInstanceResponseBody.zod.js +1 -1
- package/dist/compute/v1/generated/validators/listAvailabilityZonesParams.zod.d.ts +1 -1
- package/dist/compute/v1/generated/validators/listAvailabilityZonesParams.zod.js +1 -1
- package/dist/compute/v1/generated/validators/listBackupCapacityPacksParams.zod.d.ts +1 -1
- package/dist/compute/v1/generated/validators/listBackupCapacityPacksParams.zod.js +1 -1
- package/dist/compute/v1/generated/validators/listBackupsParams.zod.d.ts +1 -1
- package/dist/compute/v1/generated/validators/listBackupsParams.zod.js +1 -1
- package/dist/compute/v1/generated/validators/listDiskTypesParams.zod.d.ts +1 -1
- package/dist/compute/v1/generated/validators/listDiskTypesParams.zod.js +1 -1
- package/dist/compute/v1/generated/validators/listDisksParams.zod.d.ts +1 -1
- package/dist/compute/v1/generated/validators/listDisksParams.zod.js +1 -1
- package/dist/compute/v1/generated/validators/listFloatingIpsParams.zod.d.ts +1 -1
- package/dist/compute/v1/generated/validators/listFloatingIpsParams.zod.js +1 -1
- package/dist/compute/v1/generated/validators/listImagesParams.zod.d.ts +1 -1
- package/dist/compute/v1/generated/validators/listImagesParams.zod.js +1 -1
- package/dist/compute/v1/generated/validators/listInstanceDisksParams.zod.d.ts +1 -1
- package/dist/compute/v1/generated/validators/listInstanceDisksParams.zod.js +1 -1
- package/dist/compute/v1/generated/validators/listInstancePortsParams.zod.d.ts +1 -1
- package/dist/compute/v1/generated/validators/listInstancePortsParams.zod.js +1 -1
- package/dist/compute/v1/generated/validators/listInstanceTypesParams.zod.d.ts +1 -1
- package/dist/compute/v1/generated/validators/listInstanceTypesParams.zod.js +1 -1
- package/dist/compute/v1/generated/validators/listInstancesParams.zod.d.ts +1 -1
- package/dist/compute/v1/generated/validators/listInstancesParams.zod.js +1 -1
- package/dist/compute/v1/generated/validators/listIpv4PoolsParams.zod.d.ts +1 -1
- package/dist/compute/v1/generated/validators/listIpv4PoolsParams.zod.js +1 -1
- package/dist/compute/v1/generated/validators/listOperationLogsParams.zod.d.ts +1 -1
- package/dist/compute/v1/generated/validators/listOperationLogsParams.zod.js +1 -1
- package/dist/compute/v1/generated/validators/listPeeringsParams.zod.d.ts +1 -1
- package/dist/compute/v1/generated/validators/listPeeringsParams.zod.js +1 -1
- package/dist/compute/v1/generated/validators/listPortsParams.zod.d.ts +1 -1
- package/dist/compute/v1/generated/validators/listPortsParams.zod.js +1 -1
- package/dist/compute/v1/generated/validators/listPrivateNetworksParams.zod.d.ts +1 -1
- package/dist/compute/v1/generated/validators/listPrivateNetworksParams.zod.js +1 -1
- package/dist/compute/v1/generated/validators/listRegionsParams.zod.d.ts +1 -1
- package/dist/compute/v1/generated/validators/listRegionsParams.zod.js +1 -1
- package/dist/compute/v1/generated/validators/listRoutesParams.zod.d.ts +1 -1
- package/dist/compute/v1/generated/validators/listRoutesParams.zod.js +1 -1
- package/dist/compute/v1/generated/validators/listSecurityGroupRulesParams.zod.d.ts +1 -1
- package/dist/compute/v1/generated/validators/listSecurityGroupRulesParams.zod.js +1 -1
- package/dist/compute/v1/generated/validators/listSecurityGroupsParams.zod.d.ts +1 -1
- package/dist/compute/v1/generated/validators/listSecurityGroupsParams.zod.js +1 -1
- package/dist/compute/v1/generated/validators/listSnapshotsParams.zod.d.ts +1 -1
- package/dist/compute/v1/generated/validators/listSnapshotsParams.zod.js +1 -1
- package/dist/compute/v1/generated/validators/listSubnetsParams.zod.d.ts +1 -1
- package/dist/compute/v1/generated/validators/listSubnetsParams.zod.js +1 -1
- package/dist/compute/v1/generated/validators/money.zod.d.ts +1 -1
- package/dist/compute/v1/generated/validators/money.zod.js +1 -1
- package/dist/compute/v1/generated/validators/newBootDisk.zod.d.ts +1 -1
- package/dist/compute/v1/generated/validators/newBootDisk.zod.js +1 -1
- package/dist/compute/v1/generated/validators/newCompute.zod.d.ts +1 -1
- package/dist/compute/v1/generated/validators/newCompute.zod.js +1 -1
- package/dist/compute/v1/generated/validators/newFloatingIP.zod.d.ts +1 -1
- package/dist/compute/v1/generated/validators/newFloatingIP.zod.js +1 -1
- package/dist/compute/v1/generated/validators/nextFreeCidrResponseBody.zod.d.ts +1 -1
- package/dist/compute/v1/generated/validators/nextFreeCidrResponseBody.zod.js +1 -1
- package/dist/compute/v1/generated/validators/offsetPagination.zod.d.ts +1 -1
- package/dist/compute/v1/generated/validators/offsetPagination.zod.js +1 -1
- package/dist/compute/v1/generated/validators/operationLogListResponseBody.zod.d.ts +1 -1
- package/dist/compute/v1/generated/validators/operationLogListResponseBody.zod.js +1 -1
- package/dist/compute/v1/generated/validators/operationLogResource.zod.d.ts +1 -1
- package/dist/compute/v1/generated/validators/operationLogResource.zod.js +1 -1
- package/dist/compute/v1/generated/validators/peeringListResponseBody.zod.d.ts +1 -1
- package/dist/compute/v1/generated/validators/peeringListResponseBody.zod.js +1 -1
- package/dist/compute/v1/generated/validators/peeringOperation.zod.d.ts +1 -1
- package/dist/compute/v1/generated/validators/peeringOperation.zod.js +1 -1
- package/dist/compute/v1/generated/validators/peeringResource.zod.d.ts +1 -1
- package/dist/compute/v1/generated/validators/peeringResource.zod.js +1 -1
- package/dist/compute/v1/generated/validators/portAddress.zod.d.ts +1 -1
- package/dist/compute/v1/generated/validators/portAddress.zod.js +1 -1
- package/dist/compute/v1/generated/validators/portAttachment.zod.d.ts +1 -1
- package/dist/compute/v1/generated/validators/portAttachment.zod.js +1 -1
- package/dist/compute/v1/generated/validators/portAttachmentList.zod.d.ts +1 -1
- package/dist/compute/v1/generated/validators/portAttachmentList.zod.js +1 -1
- package/dist/compute/v1/generated/validators/portListResponseBody.zod.d.ts +1 -1
- package/dist/compute/v1/generated/validators/portListResponseBody.zod.js +1 -1
- package/dist/compute/v1/generated/validators/portOperation.zod.d.ts +1 -1
- package/dist/compute/v1/generated/validators/portOperation.zod.js +1 -1
- package/dist/compute/v1/generated/validators/portResource.zod.d.ts +1 -1
- package/dist/compute/v1/generated/validators/portResource.zod.js +1 -1
- package/dist/compute/v1/generated/validators/powerRequest.zod.d.ts +1 -1
- package/dist/compute/v1/generated/validators/powerRequest.zod.js +1 -1
- package/dist/compute/v1/generated/validators/privateNetworkListResponseBody.zod.d.ts +1 -1
- package/dist/compute/v1/generated/validators/privateNetworkListResponseBody.zod.js +1 -1
- package/dist/compute/v1/generated/validators/privateNetworkResource.zod.d.ts +1 -1
- package/dist/compute/v1/generated/validators/privateNetworkResource.zod.js +1 -1
- package/dist/compute/v1/generated/validators/rebootInstanceRequestBody.zod.d.ts +1 -1
- package/dist/compute/v1/generated/validators/rebootInstanceRequestBody.zod.js +1 -1
- package/dist/compute/v1/generated/validators/rebuildInstanceRequestBody.zod.d.ts +1 -1
- package/dist/compute/v1/generated/validators/rebuildInstanceRequestBody.zod.js +1 -1
- package/dist/compute/v1/generated/validators/rebuildInstanceResponseBody.zod.d.ts +1 -1
- package/dist/compute/v1/generated/validators/rebuildInstanceResponseBody.zod.js +1 -1
- package/dist/compute/v1/generated/validators/regionListResponseBody.zod.d.ts +1 -1
- package/dist/compute/v1/generated/validators/regionListResponseBody.zod.js +1 -1
- package/dist/compute/v1/generated/validators/regionResource.zod.d.ts +1 -1
- package/dist/compute/v1/generated/validators/regionResource.zod.js +1 -1
- package/dist/compute/v1/generated/validators/releaseFloatingIPResponseBody.zod.d.ts +1 -1
- package/dist/compute/v1/generated/validators/releaseFloatingIPResponseBody.zod.js +1 -1
- package/dist/compute/v1/generated/validators/releaseFloatingIpParams.zod.d.ts +1 -1
- package/dist/compute/v1/generated/validators/releaseFloatingIpParams.zod.js +1 -1
- package/dist/compute/v1/generated/validators/releaseResource.zod.d.ts +1 -1
- package/dist/compute/v1/generated/validators/releaseResource.zod.js +1 -1
- package/dist/compute/v1/generated/validators/releaseSetItem.zod.d.ts +1 -1
- package/dist/compute/v1/generated/validators/releaseSetItem.zod.js +1 -1
- package/dist/compute/v1/generated/validators/renameBackupRequestBody.zod.d.ts +1 -1
- package/dist/compute/v1/generated/validators/renameBackupRequestBody.zod.js +1 -1
- package/dist/compute/v1/generated/validators/renameDiskRequestBody.zod.d.ts +1 -1
- package/dist/compute/v1/generated/validators/renameDiskRequestBody.zod.js +1 -1
- package/dist/compute/v1/generated/validators/renameImageRequestBody.zod.d.ts +1 -1
- package/dist/compute/v1/generated/validators/renameImageRequestBody.zod.js +1 -1
- package/dist/compute/v1/generated/validators/renameInstanceRequestBody.zod.d.ts +1 -1
- package/dist/compute/v1/generated/validators/renameInstanceRequestBody.zod.js +1 -1
- package/dist/compute/v1/generated/validators/renamePrivateNetworkRequestBody.zod.d.ts +1 -1
- package/dist/compute/v1/generated/validators/renamePrivateNetworkRequestBody.zod.js +1 -1
- package/dist/compute/v1/generated/validators/renameSecurityGroupRequestBody.zod.d.ts +1 -1
- package/dist/compute/v1/generated/validators/renameSecurityGroupRequestBody.zod.js +1 -1
- package/dist/compute/v1/generated/validators/renameSnapshotRequestBody.zod.d.ts +1 -1
- package/dist/compute/v1/generated/validators/renameSnapshotRequestBody.zod.js +1 -1
- package/dist/compute/v1/generated/validators/resetPasswordRequestBody.zod.d.ts +1 -1
- package/dist/compute/v1/generated/validators/resetPasswordRequestBody.zod.js +1 -1
- package/dist/compute/v1/generated/validators/resetPasswordResponseBody.zod.d.ts +1 -1
- package/dist/compute/v1/generated/validators/resetPasswordResponseBody.zod.js +1 -1
- package/dist/compute/v1/generated/validators/resizeDiskRequestBody.zod.d.ts +1 -1
- package/dist/compute/v1/generated/validators/resizeDiskRequestBody.zod.js +1 -1
- package/dist/compute/v1/generated/validators/resizeDiskResponseBody.zod.d.ts +1 -1
- package/dist/compute/v1/generated/validators/resizeDiskResponseBody.zod.js +1 -1
- package/dist/compute/v1/generated/validators/resizeInstanceRequestBody.zod.d.ts +1 -1
- package/dist/compute/v1/generated/validators/resizeInstanceRequestBody.zod.js +1 -1
- package/dist/compute/v1/generated/validators/resizeInstanceResponseBody.zod.d.ts +1 -1
- package/dist/compute/v1/generated/validators/resizeInstanceResponseBody.zod.js +1 -1
- package/dist/compute/v1/generated/validators/resourceCancellation.zod.d.ts +1 -1
- package/dist/compute/v1/generated/validators/resourceCancellation.zod.js +1 -1
- package/dist/compute/v1/generated/validators/restoreBackupRequestBody.zod.d.ts +1 -1
- package/dist/compute/v1/generated/validators/restoreBackupRequestBody.zod.js +1 -1
- package/dist/compute/v1/generated/validators/revertDiskRequestBody.zod.d.ts +1 -1
- package/dist/compute/v1/generated/validators/revertDiskRequestBody.zod.js +1 -1
- package/dist/compute/v1/generated/validators/routeListResponseBody.zod.d.ts +1 -1
- package/dist/compute/v1/generated/validators/routeListResponseBody.zod.js +1 -1
- package/dist/compute/v1/generated/validators/routeResource.zod.d.ts +1 -1
- package/dist/compute/v1/generated/validators/routeResource.zod.js +1 -1
- package/dist/compute/v1/generated/validators/runCommandRequestBody.zod.d.ts +1 -1
- package/dist/compute/v1/generated/validators/runCommandRequestBody.zod.js +1 -1
- package/dist/compute/v1/generated/validators/securityGroupListResponseBody.zod.d.ts +1 -1
- package/dist/compute/v1/generated/validators/securityGroupListResponseBody.zod.js +1 -1
- package/dist/compute/v1/generated/validators/securityGroupResource.zod.d.ts +1 -1
- package/dist/compute/v1/generated/validators/securityGroupResource.zod.js +1 -1
- package/dist/compute/v1/generated/validators/securityRuleListResponseBody.zod.d.ts +1 -1
- package/dist/compute/v1/generated/validators/securityRuleListResponseBody.zod.js +1 -1
- package/dist/compute/v1/generated/validators/securityRuleResource.zod.d.ts +1 -1
- package/dist/compute/v1/generated/validators/securityRuleResource.zod.js +1 -1
- package/dist/compute/v1/generated/validators/setFloatingIPBandwidthRequestBody.zod.d.ts +1 -1
- package/dist/compute/v1/generated/validators/setFloatingIPBandwidthRequestBody.zod.js +1 -1
- package/dist/compute/v1/generated/validators/setFloatingIPBandwidthResponseBody.zod.d.ts +1 -1
- package/dist/compute/v1/generated/validators/setFloatingIPBandwidthResponseBody.zod.js +1 -1
- package/dist/compute/v1/generated/validators/setInstanceLabelsRequestBody.zod.d.ts +1 -1
- package/dist/compute/v1/generated/validators/setInstanceLabelsRequestBody.zod.js +1 -1
- package/dist/compute/v1/generated/validators/setInstanceNotesRequestBody.zod.d.ts +1 -1
- package/dist/compute/v1/generated/validators/setInstanceNotesRequestBody.zod.js +1 -1
- package/dist/compute/v1/generated/validators/setSnapshotQuotaRequestBody.zod.d.ts +1 -1
- package/dist/compute/v1/generated/validators/setSnapshotQuotaRequestBody.zod.js +1 -1
- package/dist/compute/v1/generated/validators/setSnapshotQuotaResponseBody.zod.d.ts +1 -1
- package/dist/compute/v1/generated/validators/setSnapshotQuotaResponseBody.zod.js +1 -1
- package/dist/compute/v1/generated/validators/snapshotListResponseBody.zod.d.ts +1 -1
- package/dist/compute/v1/generated/validators/snapshotListResponseBody.zod.js +1 -1
- package/dist/compute/v1/generated/validators/snapshotOperation.zod.d.ts +1 -1
- package/dist/compute/v1/generated/validators/snapshotOperation.zod.js +1 -1
- package/dist/compute/v1/generated/validators/snapshotQuota.zod.d.ts +1 -1
- package/dist/compute/v1/generated/validators/snapshotQuota.zod.js +1 -1
- package/dist/compute/v1/generated/validators/snapshotResource.zod.d.ts +1 -1
- package/dist/compute/v1/generated/validators/snapshotResource.zod.js +1 -1
- package/dist/compute/v1/generated/validators/subnetListResponseBody.zod.d.ts +1 -1
- package/dist/compute/v1/generated/validators/subnetListResponseBody.zod.js +1 -1
- package/dist/compute/v1/generated/validators/subnetResource.zod.d.ts +1 -1
- package/dist/compute/v1/generated/validators/subnetResource.zod.js +1 -1
- package/dist/compute/v1/generated/validators/suggestSubnetCidrParams.zod.d.ts +1 -1
- package/dist/compute/v1/generated/validators/suggestSubnetCidrParams.zod.js +1 -1
- package/dist/compute/v1/generated/validators/terminationPolicy.zod.d.ts +1 -1
- package/dist/compute/v1/generated/validators/terminationPolicy.zod.js +1 -1
- package/dist/compute/v1/generated/validators/zoneListResponseBody.zod.d.ts +1 -1
- package/dist/compute/v1/generated/validators/zoneListResponseBody.zod.js +1 -1
- package/dist/compute/v1/generated/validators/zoneResource.zod.d.ts +1 -1
- package/dist/compute/v1/generated/validators/zoneResource.zod.js +1 -1
- package/dist/routes.d.ts +0 -16
- package/dist/routes.js +0 -18
- package/package.json +1 -1
- package/dist/billing/v1/generated/validators/listRatesHeaders.zod.d.ts +0 -13
- package/dist/billing/v1/generated/validators/listRatesHeaders.zod.js +0 -11
- package/dist/billing/v1/generated/validators/listRatesParams.zod.d.ts +0 -20
- package/dist/billing/v1/generated/validators/listRatesParams.zod.js +0 -22
- package/dist/billing/v1/generated/validators/rateList.zod.d.ts +0 -56
- package/dist/billing/v1/generated/validators/rateList.zod.js +0 -14
- package/dist/billing/v1/generated/validators/rateSearch.zod.d.ts +0 -20
- package/dist/billing/v1/generated/validators/rateSearch.zod.js +0 -38
|
@@ -13,6 +13,7 @@ export const priceSearchCurrencyMin = 3;
|
|
|
13
13
|
export const priceSearchCurrencyMax = 3;
|
|
14
14
|
export const priceSearchIdsMax = 200;
|
|
15
15
|
export const priceSearchPlanIdsMax = 200;
|
|
16
|
+
export const priceSearchDimensionsMax = 200;
|
|
16
17
|
export const priceSearchPageMax = 2147483647;
|
|
17
18
|
export const priceSearchPageSizeMax = 200;
|
|
18
19
|
export const PriceSearch = zod
|
|
@@ -37,6 +38,12 @@ export const PriceSearch = zod
|
|
|
37
38
|
product_id: ProductID.optional(),
|
|
38
39
|
type: PriceType.optional().describe("Narrows to one price type."),
|
|
39
40
|
usage_type: UsageType.optional().describe("Narrows to one usage type."),
|
|
41
|
+
dimensions: zod
|
|
42
|
+
.array(zod.record(zod.string(), zod.string().min(1)))
|
|
43
|
+
.min(1)
|
|
44
|
+
.max(priceSearchDimensionsMax)
|
|
45
|
+
.optional()
|
|
46
|
+
.describe("Narrows each price's `rates` to these dimension value sets, given as on order lines and usage; prices are not filtered by it. A set no rate has adds nothing."),
|
|
40
47
|
page: zod
|
|
41
48
|
.int()
|
|
42
49
|
.min(1)
|
|
@@ -439,7 +439,7 @@ export declare const getListModelsUrl: () => string;
|
|
|
439
439
|
*
|
|
440
440
|
* `context_length` and `max_output_tokens` are advisory. The server does not truncate on their basis, and the request body is forwarded upstream unchanged.
|
|
441
441
|
*
|
|
442
|
-
* Canopy returns no amounts: each model's `billing` names the Billing plan and the rate dimensions its token usage is priced at. Read the rates from
|
|
442
|
+
* Canopy returns no amounts: each model's `billing` names the Billing plan and the rate dimensions its token usage is priced at. Read the rates from the `rates` of the plan's prices in Billing's `search-prices`.
|
|
443
443
|
* @summary List the available models
|
|
444
444
|
*/
|
|
445
445
|
export declare const listModels: (options?: RequestInit, fetchFn?: typeof globalThis.fetch) => Promise<listModelsResponse>;
|
|
@@ -440,7 +440,7 @@ export const getListModelsUrl = () => {
|
|
|
440
440
|
*
|
|
441
441
|
* `context_length` and `max_output_tokens` are advisory. The server does not truncate on their basis, and the request body is forwarded upstream unchanged.
|
|
442
442
|
*
|
|
443
|
-
* Canopy returns no amounts: each model's `billing` names the Billing plan and the rate dimensions its token usage is priced at. Read the rates from
|
|
443
|
+
* Canopy returns no amounts: each model's `billing` names the Billing plan and the rate dimensions its token usage is priced at. Read the rates from the `rates` of the plan's prices in Billing's `search-prices`.
|
|
444
444
|
* @summary List the available models
|
|
445
445
|
*/
|
|
446
446
|
export const listModels = async (options, fetchFn) => {
|
|
@@ -346,7 +346,7 @@ export interface ModelMeter {
|
|
|
346
346
|
dimensions: ModelMeterDimensions;
|
|
347
347
|
}
|
|
348
348
|
/**
|
|
349
|
-
* How requests to a model are billed: under the service's subscription, on the Billing plan `plan_id`, one rate for each token kind. Read the rates from Billing with `search-prices` for the plan
|
|
349
|
+
* How requests to a model are billed: under the service's subscription, on the Billing plan `plan_id`, one rate for each token kind. Read the rates from Billing with `search-prices` for the plan, narrowing each price's `rates` with each meter's `dimensions`.
|
|
350
350
|
*
|
|
351
351
|
* Each token kind is priced on its own. `input` excludes cached input, which is `cache_read`, and `output` excludes reasoning the provider reports separately, which is `reasoning`; a request is billed for each kind it used.
|
|
352
352
|
*/
|
|
@@ -50,4 +50,4 @@ export const ModelBilling = zod
|
|
|
50
50
|
.array(ModelMeter)
|
|
51
51
|
.describe("One entry for each of the five token kinds, in the order input, output, cache_read, cache_write, reasoning."),
|
|
52
52
|
})
|
|
53
|
-
.describe("How requests to a model are billed: under the service's subscription, on the Billing plan `plan_id`, one rate for each token kind. Read the rates from Billing with `search-prices` for the plan
|
|
53
|
+
.describe("How requests to a model are billed: under the service's subscription, on the Billing plan `plan_id`, one rate for each token kind. Read the rates from Billing with `search-prices` for the plan, narrowing each price's `rates` with each meter's `dimensions`.\n\nEach token kind is priced on its own. `input` excludes cached input, which is `cache_read`, and `output` excludes reasoning the provider reports separately, which is `reasoning`; a request is billed for each kind it used.");
|
|
@@ -11,7 +11,7 @@
|
|
|
11
11
|
* ## Conventions
|
|
12
12
|
*
|
|
13
13
|
* - **Purchases.** A purchase that creates resources returns them together with the `checkout_session_id` of its Billing Checkout Session and, once checkout completes, its `order_id`. They are readable at once and start as `pending`: checkout may not be complete, the order has not been accepted, nothing exists in the cloud, no inventory such as an address is held, and fields known only after allocation, such as addresses, are null. Once Billing accepts the order, a resource becomes `provisioning` and then reaches its usual status, such as `active` or `available`. When the Checkout Session expires, the order is declined, canceled or expires, or creation fails, the resource ends `failed` and `failure_reason` states why; the charge for a resource that failed after acceptance is refunded. Read the Checkout Session and the order in Billing for checkout and payment progress.
|
|
14
|
-
* - **Commercial terms.** Compute returns no amounts. Catalog items, such as instance types, disk types and public IP pools, and the region's own products carry `billing`: the Billing plan an order line for them is sold under, the dimensions the line carries, how its quantity is counted for each usage type, and the meters its metered price reads. Read their prices from Billing with `search-prices
|
|
14
|
+
* - **Commercial terms.** Compute returns no amounts. Catalog items, such as instance types, disk types and public IP pools, and the region's own products carry `billing`: the Billing plan an order line for them is sold under, the dimensions the line carries, how its quantity is counted for each usage type, and the meters its metered price reads. Read their prices and rates from Billing with `search-prices`, quote a purchase or a change with Billing's `get-quote` using the same lines, and estimate metered usage with Billing's `estimate-usage`. A purchase chooses its terms with `billing`, which applies to all of its components.
|
|
15
15
|
* - **Checkout.** `checkout` is passed to Billing unchanged. Omit it for automatic checkout, which completes checkout within the request and pays from eligible credit grants and balance; insufficient funds refuse the request with HTTP 422 `BILLING_INSUFFICIENT_FUNDS`, and nothing is created. With `checkout.mode` set to `deferred`, the resources are returned `pending` with an open Checkout Session and no order, even for a zero total; nothing is created until the customer completes checkout in Billing, where a promotion code can be applied, and the order is paid.
|
|
16
16
|
* - **Operations.** Requests such as starting, stopping, attaching or deleting return HTTP 202 with the resource as it is when the request is accepted. While an operation runs, the resource's `operation` field names it; the field is null once the operation has finished, and the resource then shows the result. A resource with an operation in progress refuses another operation with HTTP 409 `COMPUTE_RESOURCE_BUSY`; an operation involving two resources, such as attaching a disk, is refused when either has one. A purchased change, such as a resize, is an operation from the moment its Checkout Session is created until the change is applied, the session expires or its order is canceled. Renaming and replacing labels or notes are not operations and are accepted at any time.
|
|
17
17
|
* - **Billing relationships.** A purchased resource records its `checkout_session_id` and, once checkout completes, its `order_id`, `order_item_id` and `subscription_id`. The subscription is `pending` until the order is accepted, `provisioning` while the resource is created, and `active` once it is delivered. Bandwidth is a property of its floating IP, not a separate resource. Snapshots use a purchased per-region count quota, and backups are metered on the region's backup service; neither has an order or subscription of its own.
|
|
@@ -11,7 +11,7 @@
|
|
|
11
11
|
* ## Conventions
|
|
12
12
|
*
|
|
13
13
|
* - **Purchases.** A purchase that creates resources returns them together with the `checkout_session_id` of its Billing Checkout Session and, once checkout completes, its `order_id`. They are readable at once and start as `pending`: checkout may not be complete, the order has not been accepted, nothing exists in the cloud, no inventory such as an address is held, and fields known only after allocation, such as addresses, are null. Once Billing accepts the order, a resource becomes `provisioning` and then reaches its usual status, such as `active` or `available`. When the Checkout Session expires, the order is declined, canceled or expires, or creation fails, the resource ends `failed` and `failure_reason` states why; the charge for a resource that failed after acceptance is refunded. Read the Checkout Session and the order in Billing for checkout and payment progress.
|
|
14
|
-
* - **Commercial terms.** Compute returns no amounts. Catalog items, such as instance types, disk types and public IP pools, and the region's own products carry `billing`: the Billing plan an order line for them is sold under, the dimensions the line carries, how its quantity is counted for each usage type, and the meters its metered price reads. Read their prices from Billing with `search-prices
|
|
14
|
+
* - **Commercial terms.** Compute returns no amounts. Catalog items, such as instance types, disk types and public IP pools, and the region's own products carry `billing`: the Billing plan an order line for them is sold under, the dimensions the line carries, how its quantity is counted for each usage type, and the meters its metered price reads. Read their prices and rates from Billing with `search-prices`, quote a purchase or a change with Billing's `get-quote` using the same lines, and estimate metered usage with Billing's `estimate-usage`. A purchase chooses its terms with `billing`, which applies to all of its components.
|
|
15
15
|
* - **Checkout.** `checkout` is passed to Billing unchanged. Omit it for automatic checkout, which completes checkout within the request and pays from eligible credit grants and balance; insufficient funds refuse the request with HTTP 422 `BILLING_INSUFFICIENT_FUNDS`, and nothing is created. With `checkout.mode` set to `deferred`, the resources are returned `pending` with an open Checkout Session and no order, even for a zero total; nothing is created until the customer completes checkout in Billing, where a promotion code can be applied, and the order is paid.
|
|
16
16
|
* - **Operations.** Requests such as starting, stopping, attaching or deleting return HTTP 202 with the resource as it is when the request is accepted. While an operation runs, the resource's `operation` field names it; the field is null once the operation has finished, and the resource then shows the result. A resource with an operation in progress refuses another operation with HTTP 409 `COMPUTE_RESOURCE_BUSY`; an operation involving two resources, such as attaching a disk, is refused when either has one. A purchased change, such as a resize, is an operation from the moment its Checkout Session is created until the change is applied, the session expires or its order is canceled. Renaming and replacing labels or notes are not operations and are accepted at any time.
|
|
17
17
|
* - **Billing relationships.** A purchased resource records its `checkout_session_id` and, once checkout completes, its `order_id`, `order_item_id` and `subscription_id`. The subscription is `pending` until the order is accepted, `provisioning` while the resource is created, and `active` once it is delivered. Bandwidth is a property of its floating IP, not a separate resource. Snapshots use a purchased per-region count quota, and backups are metered on the region's backup service; neither has an order or subscription of its own.
|
|
@@ -132,7 +132,7 @@ export interface BillingMeter {
|
|
|
132
132
|
dimensions?: BillingMeterDimensions;
|
|
133
133
|
}
|
|
134
134
|
/**
|
|
135
|
-
* How one order line of an item is sold in Billing. Give `plan_id` to Billing's `search-prices` for its prices,
|
|
135
|
+
* How one order line of an item is sold in Billing. Give `plan_id` to Billing's `search-prices` for its prices, with `dimensions` to narrow the `rates` of a price that delegates to a rate card. Quote a purchase or a change with Billing's `get-quote` using these values, the quantity this describes and the chosen terms, and estimate metered usage with `estimate-usage` and `meters`.
|
|
136
136
|
*/
|
|
137
137
|
export interface BillingComponent {
|
|
138
138
|
/** The Billing plan the line is ordered under. */
|
|
@@ -11,7 +11,7 @@
|
|
|
11
11
|
* ## Conventions
|
|
12
12
|
*
|
|
13
13
|
* - **Purchases.** A purchase that creates resources returns them together with the `checkout_session_id` of its Billing Checkout Session and, once checkout completes, its `order_id`. They are readable at once and start as `pending`: checkout may not be complete, the order has not been accepted, nothing exists in the cloud, no inventory such as an address is held, and fields known only after allocation, such as addresses, are null. Once Billing accepts the order, a resource becomes `provisioning` and then reaches its usual status, such as `active` or `available`. When the Checkout Session expires, the order is declined, canceled or expires, or creation fails, the resource ends `failed` and `failure_reason` states why; the charge for a resource that failed after acceptance is refunded. Read the Checkout Session and the order in Billing for checkout and payment progress.
|
|
14
|
-
* - **Commercial terms.** Compute returns no amounts. Catalog items, such as instance types, disk types and public IP pools, and the region's own products carry `billing`: the Billing plan an order line for them is sold under, the dimensions the line carries, how its quantity is counted for each usage type, and the meters its metered price reads. Read their prices from Billing with `search-prices
|
|
14
|
+
* - **Commercial terms.** Compute returns no amounts. Catalog items, such as instance types, disk types and public IP pools, and the region's own products carry `billing`: the Billing plan an order line for them is sold under, the dimensions the line carries, how its quantity is counted for each usage type, and the meters its metered price reads. Read their prices and rates from Billing with `search-prices`, quote a purchase or a change with Billing's `get-quote` using the same lines, and estimate metered usage with Billing's `estimate-usage`. A purchase chooses its terms with `billing`, which applies to all of its components.
|
|
15
15
|
* - **Checkout.** `checkout` is passed to Billing unchanged. Omit it for automatic checkout, which completes checkout within the request and pays from eligible credit grants and balance; insufficient funds refuse the request with HTTP 422 `BILLING_INSUFFICIENT_FUNDS`, and nothing is created. With `checkout.mode` set to `deferred`, the resources are returned `pending` with an open Checkout Session and no order, even for a zero total; nothing is created until the customer completes checkout in Billing, where a promotion code can be applied, and the order is paid.
|
|
16
16
|
* - **Operations.** Requests such as starting, stopping, attaching or deleting return HTTP 202 with the resource as it is when the request is accepted. While an operation runs, the resource's `operation` field names it; the field is null once the operation has finished, and the resource then shows the result. A resource with an operation in progress refuses another operation with HTTP 409 `COMPUTE_RESOURCE_BUSY`; an operation involving two resources, such as attaching a disk, is refused when either has one. A purchased change, such as a resize, is an operation from the moment its Checkout Session is created until the change is applied, the session expires or its order is canceled. Renaming and replacing labels or notes are not operations and are accepted at any time.
|
|
17
17
|
* - **Billing relationships.** A purchased resource records its `checkout_session_id` and, once checkout completes, its `order_id`, `order_item_id` and `subscription_id`. The subscription is `pending` until the order is accepted, `provisioning` while the resource is created, and `active` once it is delivered. Bandwidth is a property of its floating IP, not a separate resource. Snapshots use a purchased per-region count quota, and backups are metered on the region's backup service; neither has an order or subscription of its own.
|
|
@@ -11,7 +11,7 @@
|
|
|
11
11
|
* ## Conventions
|
|
12
12
|
*
|
|
13
13
|
* - **Purchases.** A purchase that creates resources returns them together with the `checkout_session_id` of its Billing Checkout Session and, once checkout completes, its `order_id`. They are readable at once and start as `pending`: checkout may not be complete, the order has not been accepted, nothing exists in the cloud, no inventory such as an address is held, and fields known only after allocation, such as addresses, are null. Once Billing accepts the order, a resource becomes `provisioning` and then reaches its usual status, such as `active` or `available`. When the Checkout Session expires, the order is declined, canceled or expires, or creation fails, the resource ends `failed` and `failure_reason` states why; the charge for a resource that failed after acceptance is refunded. Read the Checkout Session and the order in Billing for checkout and payment progress.
|
|
14
|
-
* - **Commercial terms.** Compute returns no amounts. Catalog items, such as instance types, disk types and public IP pools, and the region's own products carry `billing`: the Billing plan an order line for them is sold under, the dimensions the line carries, how its quantity is counted for each usage type, and the meters its metered price reads. Read their prices from Billing with `search-prices
|
|
14
|
+
* - **Commercial terms.** Compute returns no amounts. Catalog items, such as instance types, disk types and public IP pools, and the region's own products carry `billing`: the Billing plan an order line for them is sold under, the dimensions the line carries, how its quantity is counted for each usage type, and the meters its metered price reads. Read their prices and rates from Billing with `search-prices`, quote a purchase or a change with Billing's `get-quote` using the same lines, and estimate metered usage with Billing's `estimate-usage`. A purchase chooses its terms with `billing`, which applies to all of its components.
|
|
15
15
|
* - **Checkout.** `checkout` is passed to Billing unchanged. Omit it for automatic checkout, which completes checkout within the request and pays from eligible credit grants and balance; insufficient funds refuse the request with HTTP 422 `BILLING_INSUFFICIENT_FUNDS`, and nothing is created. With `checkout.mode` set to `deferred`, the resources are returned `pending` with an open Checkout Session and no order, even for a zero total; nothing is created until the customer completes checkout in Billing, where a promotion code can be applied, and the order is paid.
|
|
16
16
|
* - **Operations.** Requests such as starting, stopping, attaching or deleting return HTTP 202 with the resource as it is when the request is accepted. While an operation runs, the resource's `operation` field names it; the field is null once the operation has finished, and the resource then shows the result. A resource with an operation in progress refuses another operation with HTTP 409 `COMPUTE_RESOURCE_BUSY`; an operation involving two resources, such as attaching a disk, is refused when either has one. A purchased change, such as a resize, is an operation from the moment its Checkout Session is created until the change is applied, the session expires or its order is canceled. Renaming and replacing labels or notes are not operations and are accepted at any time.
|
|
17
17
|
* - **Billing relationships.** A purchased resource records its `checkout_session_id` and, once checkout completes, its `order_id`, `order_item_id` and `subscription_id`. The subscription is `pending` until the order is accepted, `provisioning` while the resource is created, and `active` once it is delivered. Bandwidth is a property of its floating IP, not a separate resource. Snapshots use a purchased per-region count quota, and backups are metered on the region's backup service; neither has an order or subscription of its own.
|
|
@@ -11,7 +11,7 @@
|
|
|
11
11
|
* ## Conventions
|
|
12
12
|
*
|
|
13
13
|
* - **Purchases.** A purchase that creates resources returns them together with the `checkout_session_id` of its Billing Checkout Session and, once checkout completes, its `order_id`. They are readable at once and start as `pending`: checkout may not be complete, the order has not been accepted, nothing exists in the cloud, no inventory such as an address is held, and fields known only after allocation, such as addresses, are null. Once Billing accepts the order, a resource becomes `provisioning` and then reaches its usual status, such as `active` or `available`. When the Checkout Session expires, the order is declined, canceled or expires, or creation fails, the resource ends `failed` and `failure_reason` states why; the charge for a resource that failed after acceptance is refunded. Read the Checkout Session and the order in Billing for checkout and payment progress.
|
|
14
|
-
* - **Commercial terms.** Compute returns no amounts. Catalog items, such as instance types, disk types and public IP pools, and the region's own products carry `billing`: the Billing plan an order line for them is sold under, the dimensions the line carries, how its quantity is counted for each usage type, and the meters its metered price reads. Read their prices from Billing with `search-prices
|
|
14
|
+
* - **Commercial terms.** Compute returns no amounts. Catalog items, such as instance types, disk types and public IP pools, and the region's own products carry `billing`: the Billing plan an order line for them is sold under, the dimensions the line carries, how its quantity is counted for each usage type, and the meters its metered price reads. Read their prices and rates from Billing with `search-prices`, quote a purchase or a change with Billing's `get-quote` using the same lines, and estimate metered usage with Billing's `estimate-usage`. A purchase chooses its terms with `billing`, which applies to all of its components.
|
|
15
15
|
* - **Checkout.** `checkout` is passed to Billing unchanged. Omit it for automatic checkout, which completes checkout within the request and pays from eligible credit grants and balance; insufficient funds refuse the request with HTTP 422 `BILLING_INSUFFICIENT_FUNDS`, and nothing is created. With `checkout.mode` set to `deferred`, the resources are returned `pending` with an open Checkout Session and no order, even for a zero total; nothing is created until the customer completes checkout in Billing, where a promotion code can be applied, and the order is paid.
|
|
16
16
|
* - **Operations.** Requests such as starting, stopping, attaching or deleting return HTTP 202 with the resource as it is when the request is accepted. While an operation runs, the resource's `operation` field names it; the field is null once the operation has finished, and the resource then shows the result. A resource with an operation in progress refuses another operation with HTTP 409 `COMPUTE_RESOURCE_BUSY`; an operation involving two resources, such as attaching a disk, is refused when either has one. A purchased change, such as a resize, is an operation from the moment its Checkout Session is created until the change is applied, the session expires or its order is canceled. Renaming and replacing labels or notes are not operations and are accepted at any time.
|
|
17
17
|
* - **Billing relationships.** A purchased resource records its `checkout_session_id` and, once checkout completes, its `order_id`, `order_item_id` and `subscription_id`. The subscription is `pending` until the order is accepted, `provisioning` while the resource is created, and `active` once it is delivered. Bandwidth is a property of its floating IP, not a separate resource. Snapshots use a purchased per-region count quota, and backups are metered on the region's backup service; neither has an order or subscription of its own.
|
|
@@ -11,7 +11,7 @@
|
|
|
11
11
|
* ## Conventions
|
|
12
12
|
*
|
|
13
13
|
* - **Purchases.** A purchase that creates resources returns them together with the `checkout_session_id` of its Billing Checkout Session and, once checkout completes, its `order_id`. They are readable at once and start as `pending`: checkout may not be complete, the order has not been accepted, nothing exists in the cloud, no inventory such as an address is held, and fields known only after allocation, such as addresses, are null. Once Billing accepts the order, a resource becomes `provisioning` and then reaches its usual status, such as `active` or `available`. When the Checkout Session expires, the order is declined, canceled or expires, or creation fails, the resource ends `failed` and `failure_reason` states why; the charge for a resource that failed after acceptance is refunded. Read the Checkout Session and the order in Billing for checkout and payment progress.
|
|
14
|
-
* - **Commercial terms.** Compute returns no amounts. Catalog items, such as instance types, disk types and public IP pools, and the region's own products carry `billing`: the Billing plan an order line for them is sold under, the dimensions the line carries, how its quantity is counted for each usage type, and the meters its metered price reads. Read their prices from Billing with `search-prices
|
|
14
|
+
* - **Commercial terms.** Compute returns no amounts. Catalog items, such as instance types, disk types and public IP pools, and the region's own products carry `billing`: the Billing plan an order line for them is sold under, the dimensions the line carries, how its quantity is counted for each usage type, and the meters its metered price reads. Read their prices and rates from Billing with `search-prices`, quote a purchase or a change with Billing's `get-quote` using the same lines, and estimate metered usage with Billing's `estimate-usage`. A purchase chooses its terms with `billing`, which applies to all of its components.
|
|
15
15
|
* - **Checkout.** `checkout` is passed to Billing unchanged. Omit it for automatic checkout, which completes checkout within the request and pays from eligible credit grants and balance; insufficient funds refuse the request with HTTP 422 `BILLING_INSUFFICIENT_FUNDS`, and nothing is created. With `checkout.mode` set to `deferred`, the resources are returned `pending` with an open Checkout Session and no order, even for a zero total; nothing is created until the customer completes checkout in Billing, where a promotion code can be applied, and the order is paid.
|
|
16
16
|
* - **Operations.** Requests such as starting, stopping, attaching or deleting return HTTP 202 with the resource as it is when the request is accepted. While an operation runs, the resource's `operation` field names it; the field is null once the operation has finished, and the resource then shows the result. A resource with an operation in progress refuses another operation with HTTP 409 `COMPUTE_RESOURCE_BUSY`; an operation involving two resources, such as attaching a disk, is refused when either has one. A purchased change, such as a resize, is an operation from the moment its Checkout Session is created until the change is applied, the session expires or its order is canceled. Renaming and replacing labels or notes are not operations and are accepted at any time.
|
|
17
17
|
* - **Billing relationships.** A purchased resource records its `checkout_session_id` and, once checkout completes, its `order_id`, `order_item_id` and `subscription_id`. The subscription is `pending` until the order is accepted, `provisioning` while the resource is created, and `active` once it is delivered. Bandwidth is a property of its floating IP, not a separate resource. Snapshots use a purchased per-region count quota, and backups are metered on the region's backup service; neither has an order or subscription of its own.
|
|
@@ -11,7 +11,7 @@
|
|
|
11
11
|
* ## Conventions
|
|
12
12
|
*
|
|
13
13
|
* - **Purchases.** A purchase that creates resources returns them together with the `checkout_session_id` of its Billing Checkout Session and, once checkout completes, its `order_id`. They are readable at once and start as `pending`: checkout may not be complete, the order has not been accepted, nothing exists in the cloud, no inventory such as an address is held, and fields known only after allocation, such as addresses, are null. Once Billing accepts the order, a resource becomes `provisioning` and then reaches its usual status, such as `active` or `available`. When the Checkout Session expires, the order is declined, canceled or expires, or creation fails, the resource ends `failed` and `failure_reason` states why; the charge for a resource that failed after acceptance is refunded. Read the Checkout Session and the order in Billing for checkout and payment progress.
|
|
14
|
-
* - **Commercial terms.** Compute returns no amounts. Catalog items, such as instance types, disk types and public IP pools, and the region's own products carry `billing`: the Billing plan an order line for them is sold under, the dimensions the line carries, how its quantity is counted for each usage type, and the meters its metered price reads. Read their prices from Billing with `search-prices
|
|
14
|
+
* - **Commercial terms.** Compute returns no amounts. Catalog items, such as instance types, disk types and public IP pools, and the region's own products carry `billing`: the Billing plan an order line for them is sold under, the dimensions the line carries, how its quantity is counted for each usage type, and the meters its metered price reads. Read their prices and rates from Billing with `search-prices`, quote a purchase or a change with Billing's `get-quote` using the same lines, and estimate metered usage with Billing's `estimate-usage`. A purchase chooses its terms with `billing`, which applies to all of its components.
|
|
15
15
|
* - **Checkout.** `checkout` is passed to Billing unchanged. Omit it for automatic checkout, which completes checkout within the request and pays from eligible credit grants and balance; insufficient funds refuse the request with HTTP 422 `BILLING_INSUFFICIENT_FUNDS`, and nothing is created. With `checkout.mode` set to `deferred`, the resources are returned `pending` with an open Checkout Session and no order, even for a zero total; nothing is created until the customer completes checkout in Billing, where a promotion code can be applied, and the order is paid.
|
|
16
16
|
* - **Operations.** Requests such as starting, stopping, attaching or deleting return HTTP 202 with the resource as it is when the request is accepted. While an operation runs, the resource's `operation` field names it; the field is null once the operation has finished, and the resource then shows the result. A resource with an operation in progress refuses another operation with HTTP 409 `COMPUTE_RESOURCE_BUSY`; an operation involving two resources, such as attaching a disk, is refused when either has one. A purchased change, such as a resize, is an operation from the moment its Checkout Session is created until the change is applied, the session expires or its order is canceled. Renaming and replacing labels or notes are not operations and are accepted at any time.
|
|
17
17
|
* - **Billing relationships.** A purchased resource records its `checkout_session_id` and, once checkout completes, its `order_id`, `order_item_id` and `subscription_id`. The subscription is `pending` until the order is accepted, `provisioning` while the resource is created, and `active` once it is delivered. Bandwidth is a property of its floating IP, not a separate resource. Snapshots use a purchased per-region count quota, and backups are metered on the region's backup service; neither has an order or subscription of its own.
|
|
@@ -11,7 +11,7 @@
|
|
|
11
11
|
* ## Conventions
|
|
12
12
|
*
|
|
13
13
|
* - **Purchases.** A purchase that creates resources returns them together with the `checkout_session_id` of its Billing Checkout Session and, once checkout completes, its `order_id`. They are readable at once and start as `pending`: checkout may not be complete, the order has not been accepted, nothing exists in the cloud, no inventory such as an address is held, and fields known only after allocation, such as addresses, are null. Once Billing accepts the order, a resource becomes `provisioning` and then reaches its usual status, such as `active` or `available`. When the Checkout Session expires, the order is declined, canceled or expires, or creation fails, the resource ends `failed` and `failure_reason` states why; the charge for a resource that failed after acceptance is refunded. Read the Checkout Session and the order in Billing for checkout and payment progress.
|
|
14
|
-
* - **Commercial terms.** Compute returns no amounts. Catalog items, such as instance types, disk types and public IP pools, and the region's own products carry `billing`: the Billing plan an order line for them is sold under, the dimensions the line carries, how its quantity is counted for each usage type, and the meters its metered price reads. Read their prices from Billing with `search-prices
|
|
14
|
+
* - **Commercial terms.** Compute returns no amounts. Catalog items, such as instance types, disk types and public IP pools, and the region's own products carry `billing`: the Billing plan an order line for them is sold under, the dimensions the line carries, how its quantity is counted for each usage type, and the meters its metered price reads. Read their prices and rates from Billing with `search-prices`, quote a purchase or a change with Billing's `get-quote` using the same lines, and estimate metered usage with Billing's `estimate-usage`. A purchase chooses its terms with `billing`, which applies to all of its components.
|
|
15
15
|
* - **Checkout.** `checkout` is passed to Billing unchanged. Omit it for automatic checkout, which completes checkout within the request and pays from eligible credit grants and balance; insufficient funds refuse the request with HTTP 422 `BILLING_INSUFFICIENT_FUNDS`, and nothing is created. With `checkout.mode` set to `deferred`, the resources are returned `pending` with an open Checkout Session and no order, even for a zero total; nothing is created until the customer completes checkout in Billing, where a promotion code can be applied, and the order is paid.
|
|
16
16
|
* - **Operations.** Requests such as starting, stopping, attaching or deleting return HTTP 202 with the resource as it is when the request is accepted. While an operation runs, the resource's `operation` field names it; the field is null once the operation has finished, and the resource then shows the result. A resource with an operation in progress refuses another operation with HTTP 409 `COMPUTE_RESOURCE_BUSY`; an operation involving two resources, such as attaching a disk, is refused when either has one. A purchased change, such as a resize, is an operation from the moment its Checkout Session is created until the change is applied, the session expires or its order is canceled. Renaming and replacing labels or notes are not operations and are accepted at any time.
|
|
17
17
|
* - **Billing relationships.** A purchased resource records its `checkout_session_id` and, once checkout completes, its `order_id`, `order_item_id` and `subscription_id`. The subscription is `pending` until the order is accepted, `provisioning` while the resource is created, and `active` once it is delivered. Bandwidth is a property of its floating IP, not a separate resource. Snapshots use a purchased per-region count quota, and backups are metered on the region's backup service; neither has an order or subscription of its own.
|
|
@@ -11,7 +11,7 @@
|
|
|
11
11
|
* ## Conventions
|
|
12
12
|
*
|
|
13
13
|
* - **Purchases.** A purchase that creates resources returns them together with the `checkout_session_id` of its Billing Checkout Session and, once checkout completes, its `order_id`. They are readable at once and start as `pending`: checkout may not be complete, the order has not been accepted, nothing exists in the cloud, no inventory such as an address is held, and fields known only after allocation, such as addresses, are null. Once Billing accepts the order, a resource becomes `provisioning` and then reaches its usual status, such as `active` or `available`. When the Checkout Session expires, the order is declined, canceled or expires, or creation fails, the resource ends `failed` and `failure_reason` states why; the charge for a resource that failed after acceptance is refunded. Read the Checkout Session and the order in Billing for checkout and payment progress.
|
|
14
|
-
* - **Commercial terms.** Compute returns no amounts. Catalog items, such as instance types, disk types and public IP pools, and the region's own products carry `billing`: the Billing plan an order line for them is sold under, the dimensions the line carries, how its quantity is counted for each usage type, and the meters its metered price reads. Read their prices from Billing with `search-prices
|
|
14
|
+
* - **Commercial terms.** Compute returns no amounts. Catalog items, such as instance types, disk types and public IP pools, and the region's own products carry `billing`: the Billing plan an order line for them is sold under, the dimensions the line carries, how its quantity is counted for each usage type, and the meters its metered price reads. Read their prices and rates from Billing with `search-prices`, quote a purchase or a change with Billing's `get-quote` using the same lines, and estimate metered usage with Billing's `estimate-usage`. A purchase chooses its terms with `billing`, which applies to all of its components.
|
|
15
15
|
* - **Checkout.** `checkout` is passed to Billing unchanged. Omit it for automatic checkout, which completes checkout within the request and pays from eligible credit grants and balance; insufficient funds refuse the request with HTTP 422 `BILLING_INSUFFICIENT_FUNDS`, and nothing is created. With `checkout.mode` set to `deferred`, the resources are returned `pending` with an open Checkout Session and no order, even for a zero total; nothing is created until the customer completes checkout in Billing, where a promotion code can be applied, and the order is paid.
|
|
16
16
|
* - **Operations.** Requests such as starting, stopping, attaching or deleting return HTTP 202 with the resource as it is when the request is accepted. While an operation runs, the resource's `operation` field names it; the field is null once the operation has finished, and the resource then shows the result. A resource with an operation in progress refuses another operation with HTTP 409 `COMPUTE_RESOURCE_BUSY`; an operation involving two resources, such as attaching a disk, is refused when either has one. A purchased change, such as a resize, is an operation from the moment its Checkout Session is created until the change is applied, the session expires or its order is canceled. Renaming and replacing labels or notes are not operations and are accepted at any time.
|
|
17
17
|
* - **Billing relationships.** A purchased resource records its `checkout_session_id` and, once checkout completes, its `order_id`, `order_item_id` and `subscription_id`. The subscription is `pending` until the order is accepted, `provisioning` while the resource is created, and `active` once it is delivered. Bandwidth is a property of its floating IP, not a separate resource. Snapshots use a purchased per-region count quota, and backups are metered on the region's backup service; neither has an order or subscription of its own.
|
|
@@ -11,7 +11,7 @@
|
|
|
11
11
|
* ## Conventions
|
|
12
12
|
*
|
|
13
13
|
* - **Purchases.** A purchase that creates resources returns them together with the `checkout_session_id` of its Billing Checkout Session and, once checkout completes, its `order_id`. They are readable at once and start as `pending`: checkout may not be complete, the order has not been accepted, nothing exists in the cloud, no inventory such as an address is held, and fields known only after allocation, such as addresses, are null. Once Billing accepts the order, a resource becomes `provisioning` and then reaches its usual status, such as `active` or `available`. When the Checkout Session expires, the order is declined, canceled or expires, or creation fails, the resource ends `failed` and `failure_reason` states why; the charge for a resource that failed after acceptance is refunded. Read the Checkout Session and the order in Billing for checkout and payment progress.
|
|
14
|
-
* - **Commercial terms.** Compute returns no amounts. Catalog items, such as instance types, disk types and public IP pools, and the region's own products carry `billing`: the Billing plan an order line for them is sold under, the dimensions the line carries, how its quantity is counted for each usage type, and the meters its metered price reads. Read their prices from Billing with `search-prices
|
|
14
|
+
* - **Commercial terms.** Compute returns no amounts. Catalog items, such as instance types, disk types and public IP pools, and the region's own products carry `billing`: the Billing plan an order line for them is sold under, the dimensions the line carries, how its quantity is counted for each usage type, and the meters its metered price reads. Read their prices and rates from Billing with `search-prices`, quote a purchase or a change with Billing's `get-quote` using the same lines, and estimate metered usage with Billing's `estimate-usage`. A purchase chooses its terms with `billing`, which applies to all of its components.
|
|
15
15
|
* - **Checkout.** `checkout` is passed to Billing unchanged. Omit it for automatic checkout, which completes checkout within the request and pays from eligible credit grants and balance; insufficient funds refuse the request with HTTP 422 `BILLING_INSUFFICIENT_FUNDS`, and nothing is created. With `checkout.mode` set to `deferred`, the resources are returned `pending` with an open Checkout Session and no order, even for a zero total; nothing is created until the customer completes checkout in Billing, where a promotion code can be applied, and the order is paid.
|
|
16
16
|
* - **Operations.** Requests such as starting, stopping, attaching or deleting return HTTP 202 with the resource as it is when the request is accepted. While an operation runs, the resource's `operation` field names it; the field is null once the operation has finished, and the resource then shows the result. A resource with an operation in progress refuses another operation with HTTP 409 `COMPUTE_RESOURCE_BUSY`; an operation involving two resources, such as attaching a disk, is refused when either has one. A purchased change, such as a resize, is an operation from the moment its Checkout Session is created until the change is applied, the session expires or its order is canceled. Renaming and replacing labels or notes are not operations and are accepted at any time.
|
|
17
17
|
* - **Billing relationships.** A purchased resource records its `checkout_session_id` and, once checkout completes, its `order_id`, `order_item_id` and `subscription_id`. The subscription is `pending` until the order is accepted, `provisioning` while the resource is created, and `active` once it is delivered. Bandwidth is a property of its floating IP, not a separate resource. Snapshots use a purchased per-region count quota, and backups are metered on the region's backup service; neither has an order or subscription of its own.
|
|
@@ -11,7 +11,7 @@
|
|
|
11
11
|
* ## Conventions
|
|
12
12
|
*
|
|
13
13
|
* - **Purchases.** A purchase that creates resources returns them together with the `checkout_session_id` of its Billing Checkout Session and, once checkout completes, its `order_id`. They are readable at once and start as `pending`: checkout may not be complete, the order has not been accepted, nothing exists in the cloud, no inventory such as an address is held, and fields known only after allocation, such as addresses, are null. Once Billing accepts the order, a resource becomes `provisioning` and then reaches its usual status, such as `active` or `available`. When the Checkout Session expires, the order is declined, canceled or expires, or creation fails, the resource ends `failed` and `failure_reason` states why; the charge for a resource that failed after acceptance is refunded. Read the Checkout Session and the order in Billing for checkout and payment progress.
|
|
14
|
-
* - **Commercial terms.** Compute returns no amounts. Catalog items, such as instance types, disk types and public IP pools, and the region's own products carry `billing`: the Billing plan an order line for them is sold under, the dimensions the line carries, how its quantity is counted for each usage type, and the meters its metered price reads. Read their prices from Billing with `search-prices
|
|
14
|
+
* - **Commercial terms.** Compute returns no amounts. Catalog items, such as instance types, disk types and public IP pools, and the region's own products carry `billing`: the Billing plan an order line for them is sold under, the dimensions the line carries, how its quantity is counted for each usage type, and the meters its metered price reads. Read their prices and rates from Billing with `search-prices`, quote a purchase or a change with Billing's `get-quote` using the same lines, and estimate metered usage with Billing's `estimate-usage`. A purchase chooses its terms with `billing`, which applies to all of its components.
|
|
15
15
|
* - **Checkout.** `checkout` is passed to Billing unchanged. Omit it for automatic checkout, which completes checkout within the request and pays from eligible credit grants and balance; insufficient funds refuse the request with HTTP 422 `BILLING_INSUFFICIENT_FUNDS`, and nothing is created. With `checkout.mode` set to `deferred`, the resources are returned `pending` with an open Checkout Session and no order, even for a zero total; nothing is created until the customer completes checkout in Billing, where a promotion code can be applied, and the order is paid.
|
|
16
16
|
* - **Operations.** Requests such as starting, stopping, attaching or deleting return HTTP 202 with the resource as it is when the request is accepted. While an operation runs, the resource's `operation` field names it; the field is null once the operation has finished, and the resource then shows the result. A resource with an operation in progress refuses another operation with HTTP 409 `COMPUTE_RESOURCE_BUSY`; an operation involving two resources, such as attaching a disk, is refused when either has one. A purchased change, such as a resize, is an operation from the moment its Checkout Session is created until the change is applied, the session expires or its order is canceled. Renaming and replacing labels or notes are not operations and are accepted at any time.
|
|
17
17
|
* - **Billing relationships.** A purchased resource records its `checkout_session_id` and, once checkout completes, its `order_id`, `order_item_id` and `subscription_id`. The subscription is `pending` until the order is accepted, `provisioning` while the resource is created, and `active` once it is delivered. Bandwidth is a property of its floating IP, not a separate resource. Snapshots use a purchased per-region count quota, and backups are metered on the region's backup service; neither has an order or subscription of its own.
|
|
@@ -11,7 +11,7 @@
|
|
|
11
11
|
* ## Conventions
|
|
12
12
|
*
|
|
13
13
|
* - **Purchases.** A purchase that creates resources returns them together with the `checkout_session_id` of its Billing Checkout Session and, once checkout completes, its `order_id`. They are readable at once and start as `pending`: checkout may not be complete, the order has not been accepted, nothing exists in the cloud, no inventory such as an address is held, and fields known only after allocation, such as addresses, are null. Once Billing accepts the order, a resource becomes `provisioning` and then reaches its usual status, such as `active` or `available`. When the Checkout Session expires, the order is declined, canceled or expires, or creation fails, the resource ends `failed` and `failure_reason` states why; the charge for a resource that failed after acceptance is refunded. Read the Checkout Session and the order in Billing for checkout and payment progress.
|
|
14
|
-
* - **Commercial terms.** Compute returns no amounts. Catalog items, such as instance types, disk types and public IP pools, and the region's own products carry `billing`: the Billing plan an order line for them is sold under, the dimensions the line carries, how its quantity is counted for each usage type, and the meters its metered price reads. Read their prices from Billing with `search-prices
|
|
14
|
+
* - **Commercial terms.** Compute returns no amounts. Catalog items, such as instance types, disk types and public IP pools, and the region's own products carry `billing`: the Billing plan an order line for them is sold under, the dimensions the line carries, how its quantity is counted for each usage type, and the meters its metered price reads. Read their prices and rates from Billing with `search-prices`, quote a purchase or a change with Billing's `get-quote` using the same lines, and estimate metered usage with Billing's `estimate-usage`. A purchase chooses its terms with `billing`, which applies to all of its components.
|
|
15
15
|
* - **Checkout.** `checkout` is passed to Billing unchanged. Omit it for automatic checkout, which completes checkout within the request and pays from eligible credit grants and balance; insufficient funds refuse the request with HTTP 422 `BILLING_INSUFFICIENT_FUNDS`, and nothing is created. With `checkout.mode` set to `deferred`, the resources are returned `pending` with an open Checkout Session and no order, even for a zero total; nothing is created until the customer completes checkout in Billing, where a promotion code can be applied, and the order is paid.
|
|
16
16
|
* - **Operations.** Requests such as starting, stopping, attaching or deleting return HTTP 202 with the resource as it is when the request is accepted. While an operation runs, the resource's `operation` field names it; the field is null once the operation has finished, and the resource then shows the result. A resource with an operation in progress refuses another operation with HTTP 409 `COMPUTE_RESOURCE_BUSY`; an operation involving two resources, such as attaching a disk, is refused when either has one. A purchased change, such as a resize, is an operation from the moment its Checkout Session is created until the change is applied, the session expires or its order is canceled. Renaming and replacing labels or notes are not operations and are accepted at any time.
|
|
17
17
|
* - **Billing relationships.** A purchased resource records its `checkout_session_id` and, once checkout completes, its `order_id`, `order_item_id` and `subscription_id`. The subscription is `pending` until the order is accepted, `provisioning` while the resource is created, and `active` once it is delivered. Bandwidth is a property of its floating IP, not a separate resource. Snapshots use a purchased per-region count quota, and backups are metered on the region's backup service; neither has an order or subscription of its own.
|
|
@@ -11,7 +11,7 @@
|
|
|
11
11
|
* ## Conventions
|
|
12
12
|
*
|
|
13
13
|
* - **Purchases.** A purchase that creates resources returns them together with the `checkout_session_id` of its Billing Checkout Session and, once checkout completes, its `order_id`. They are readable at once and start as `pending`: checkout may not be complete, the order has not been accepted, nothing exists in the cloud, no inventory such as an address is held, and fields known only after allocation, such as addresses, are null. Once Billing accepts the order, a resource becomes `provisioning` and then reaches its usual status, such as `active` or `available`. When the Checkout Session expires, the order is declined, canceled or expires, or creation fails, the resource ends `failed` and `failure_reason` states why; the charge for a resource that failed after acceptance is refunded. Read the Checkout Session and the order in Billing for checkout and payment progress.
|
|
14
|
-
* - **Commercial terms.** Compute returns no amounts. Catalog items, such as instance types, disk types and public IP pools, and the region's own products carry `billing`: the Billing plan an order line for them is sold under, the dimensions the line carries, how its quantity is counted for each usage type, and the meters its metered price reads. Read their prices from Billing with `search-prices
|
|
14
|
+
* - **Commercial terms.** Compute returns no amounts. Catalog items, such as instance types, disk types and public IP pools, and the region's own products carry `billing`: the Billing plan an order line for them is sold under, the dimensions the line carries, how its quantity is counted for each usage type, and the meters its metered price reads. Read their prices and rates from Billing with `search-prices`, quote a purchase or a change with Billing's `get-quote` using the same lines, and estimate metered usage with Billing's `estimate-usage`. A purchase chooses its terms with `billing`, which applies to all of its components.
|
|
15
15
|
* - **Checkout.** `checkout` is passed to Billing unchanged. Omit it for automatic checkout, which completes checkout within the request and pays from eligible credit grants and balance; insufficient funds refuse the request with HTTP 422 `BILLING_INSUFFICIENT_FUNDS`, and nothing is created. With `checkout.mode` set to `deferred`, the resources are returned `pending` with an open Checkout Session and no order, even for a zero total; nothing is created until the customer completes checkout in Billing, where a promotion code can be applied, and the order is paid.
|
|
16
16
|
* - **Operations.** Requests such as starting, stopping, attaching or deleting return HTTP 202 with the resource as it is when the request is accepted. While an operation runs, the resource's `operation` field names it; the field is null once the operation has finished, and the resource then shows the result. A resource with an operation in progress refuses another operation with HTTP 409 `COMPUTE_RESOURCE_BUSY`; an operation involving two resources, such as attaching a disk, is refused when either has one. A purchased change, such as a resize, is an operation from the moment its Checkout Session is created until the change is applied, the session expires or its order is canceled. Renaming and replacing labels or notes are not operations and are accepted at any time.
|
|
17
17
|
* - **Billing relationships.** A purchased resource records its `checkout_session_id` and, once checkout completes, its `order_id`, `order_item_id` and `subscription_id`. The subscription is `pending` until the order is accepted, `provisioning` while the resource is created, and `active` once it is delivered. Bandwidth is a property of its floating IP, not a separate resource. Snapshots use a purchased per-region count quota, and backups are metered on the region's backup service; neither has an order or subscription of its own.
|
|
@@ -11,7 +11,7 @@
|
|
|
11
11
|
* ## Conventions
|
|
12
12
|
*
|
|
13
13
|
* - **Purchases.** A purchase that creates resources returns them together with the `checkout_session_id` of its Billing Checkout Session and, once checkout completes, its `order_id`. They are readable at once and start as `pending`: checkout may not be complete, the order has not been accepted, nothing exists in the cloud, no inventory such as an address is held, and fields known only after allocation, such as addresses, are null. Once Billing accepts the order, a resource becomes `provisioning` and then reaches its usual status, such as `active` or `available`. When the Checkout Session expires, the order is declined, canceled or expires, or creation fails, the resource ends `failed` and `failure_reason` states why; the charge for a resource that failed after acceptance is refunded. Read the Checkout Session and the order in Billing for checkout and payment progress.
|
|
14
|
-
* - **Commercial terms.** Compute returns no amounts. Catalog items, such as instance types, disk types and public IP pools, and the region's own products carry `billing`: the Billing plan an order line for them is sold under, the dimensions the line carries, how its quantity is counted for each usage type, and the meters its metered price reads. Read their prices from Billing with `search-prices
|
|
14
|
+
* - **Commercial terms.** Compute returns no amounts. Catalog items, such as instance types, disk types and public IP pools, and the region's own products carry `billing`: the Billing plan an order line for them is sold under, the dimensions the line carries, how its quantity is counted for each usage type, and the meters its metered price reads. Read their prices and rates from Billing with `search-prices`, quote a purchase or a change with Billing's `get-quote` using the same lines, and estimate metered usage with Billing's `estimate-usage`. A purchase chooses its terms with `billing`, which applies to all of its components.
|
|
15
15
|
* - **Checkout.** `checkout` is passed to Billing unchanged. Omit it for automatic checkout, which completes checkout within the request and pays from eligible credit grants and balance; insufficient funds refuse the request with HTTP 422 `BILLING_INSUFFICIENT_FUNDS`, and nothing is created. With `checkout.mode` set to `deferred`, the resources are returned `pending` with an open Checkout Session and no order, even for a zero total; nothing is created until the customer completes checkout in Billing, where a promotion code can be applied, and the order is paid.
|
|
16
16
|
* - **Operations.** Requests such as starting, stopping, attaching or deleting return HTTP 202 with the resource as it is when the request is accepted. While an operation runs, the resource's `operation` field names it; the field is null once the operation has finished, and the resource then shows the result. A resource with an operation in progress refuses another operation with HTTP 409 `COMPUTE_RESOURCE_BUSY`; an operation involving two resources, such as attaching a disk, is refused when either has one. A purchased change, such as a resize, is an operation from the moment its Checkout Session is created until the change is applied, the session expires or its order is canceled. Renaming and replacing labels or notes are not operations and are accepted at any time.
|
|
17
17
|
* - **Billing relationships.** A purchased resource records its `checkout_session_id` and, once checkout completes, its `order_id`, `order_item_id` and `subscription_id`. The subscription is `pending` until the order is accepted, `provisioning` while the resource is created, and `active` once it is delivered. Bandwidth is a property of its floating IP, not a separate resource. Snapshots use a purchased per-region count quota, and backups are metered on the region's backup service; neither has an order or subscription of its own.
|
|
@@ -11,7 +11,7 @@
|
|
|
11
11
|
* ## Conventions
|
|
12
12
|
*
|
|
13
13
|
* - **Purchases.** A purchase that creates resources returns them together with the `checkout_session_id` of its Billing Checkout Session and, once checkout completes, its `order_id`. They are readable at once and start as `pending`: checkout may not be complete, the order has not been accepted, nothing exists in the cloud, no inventory such as an address is held, and fields known only after allocation, such as addresses, are null. Once Billing accepts the order, a resource becomes `provisioning` and then reaches its usual status, such as `active` or `available`. When the Checkout Session expires, the order is declined, canceled or expires, or creation fails, the resource ends `failed` and `failure_reason` states why; the charge for a resource that failed after acceptance is refunded. Read the Checkout Session and the order in Billing for checkout and payment progress.
|
|
14
|
-
* - **Commercial terms.** Compute returns no amounts. Catalog items, such as instance types, disk types and public IP pools, and the region's own products carry `billing`: the Billing plan an order line for them is sold under, the dimensions the line carries, how its quantity is counted for each usage type, and the meters its metered price reads. Read their prices from Billing with `search-prices
|
|
14
|
+
* - **Commercial terms.** Compute returns no amounts. Catalog items, such as instance types, disk types and public IP pools, and the region's own products carry `billing`: the Billing plan an order line for them is sold under, the dimensions the line carries, how its quantity is counted for each usage type, and the meters its metered price reads. Read their prices and rates from Billing with `search-prices`, quote a purchase or a change with Billing's `get-quote` using the same lines, and estimate metered usage with Billing's `estimate-usage`. A purchase chooses its terms with `billing`, which applies to all of its components.
|
|
15
15
|
* - **Checkout.** `checkout` is passed to Billing unchanged. Omit it for automatic checkout, which completes checkout within the request and pays from eligible credit grants and balance; insufficient funds refuse the request with HTTP 422 `BILLING_INSUFFICIENT_FUNDS`, and nothing is created. With `checkout.mode` set to `deferred`, the resources are returned `pending` with an open Checkout Session and no order, even for a zero total; nothing is created until the customer completes checkout in Billing, where a promotion code can be applied, and the order is paid.
|
|
16
16
|
* - **Operations.** Requests such as starting, stopping, attaching or deleting return HTTP 202 with the resource as it is when the request is accepted. While an operation runs, the resource's `operation` field names it; the field is null once the operation has finished, and the resource then shows the result. A resource with an operation in progress refuses another operation with HTTP 409 `COMPUTE_RESOURCE_BUSY`; an operation involving two resources, such as attaching a disk, is refused when either has one. A purchased change, such as a resize, is an operation from the moment its Checkout Session is created until the change is applied, the session expires or its order is canceled. Renaming and replacing labels or notes are not operations and are accepted at any time.
|
|
17
17
|
* - **Billing relationships.** A purchased resource records its `checkout_session_id` and, once checkout completes, its `order_id`, `order_item_id` and `subscription_id`. The subscription is `pending` until the order is accepted, `provisioning` while the resource is created, and `active` once it is delivered. Bandwidth is a property of its floating IP, not a separate resource. Snapshots use a purchased per-region count quota, and backups are metered on the region's backup service; neither has an order or subscription of its own.
|
|
@@ -11,7 +11,7 @@
|
|
|
11
11
|
* ## Conventions
|
|
12
12
|
*
|
|
13
13
|
* - **Purchases.** A purchase that creates resources returns them together with the `checkout_session_id` of its Billing Checkout Session and, once checkout completes, its `order_id`. They are readable at once and start as `pending`: checkout may not be complete, the order has not been accepted, nothing exists in the cloud, no inventory such as an address is held, and fields known only after allocation, such as addresses, are null. Once Billing accepts the order, a resource becomes `provisioning` and then reaches its usual status, such as `active` or `available`. When the Checkout Session expires, the order is declined, canceled or expires, or creation fails, the resource ends `failed` and `failure_reason` states why; the charge for a resource that failed after acceptance is refunded. Read the Checkout Session and the order in Billing for checkout and payment progress.
|
|
14
|
-
* - **Commercial terms.** Compute returns no amounts. Catalog items, such as instance types, disk types and public IP pools, and the region's own products carry `billing`: the Billing plan an order line for them is sold under, the dimensions the line carries, how its quantity is counted for each usage type, and the meters its metered price reads. Read their prices from Billing with `search-prices
|
|
14
|
+
* - **Commercial terms.** Compute returns no amounts. Catalog items, such as instance types, disk types and public IP pools, and the region's own products carry `billing`: the Billing plan an order line for them is sold under, the dimensions the line carries, how its quantity is counted for each usage type, and the meters its metered price reads. Read their prices and rates from Billing with `search-prices`, quote a purchase or a change with Billing's `get-quote` using the same lines, and estimate metered usage with Billing's `estimate-usage`. A purchase chooses its terms with `billing`, which applies to all of its components.
|
|
15
15
|
* - **Checkout.** `checkout` is passed to Billing unchanged. Omit it for automatic checkout, which completes checkout within the request and pays from eligible credit grants and balance; insufficient funds refuse the request with HTTP 422 `BILLING_INSUFFICIENT_FUNDS`, and nothing is created. With `checkout.mode` set to `deferred`, the resources are returned `pending` with an open Checkout Session and no order, even for a zero total; nothing is created until the customer completes checkout in Billing, where a promotion code can be applied, and the order is paid.
|
|
16
16
|
* - **Operations.** Requests such as starting, stopping, attaching or deleting return HTTP 202 with the resource as it is when the request is accepted. While an operation runs, the resource's `operation` field names it; the field is null once the operation has finished, and the resource then shows the result. A resource with an operation in progress refuses another operation with HTTP 409 `COMPUTE_RESOURCE_BUSY`; an operation involving two resources, such as attaching a disk, is refused when either has one. A purchased change, such as a resize, is an operation from the moment its Checkout Session is created until the change is applied, the session expires or its order is canceled. Renaming and replacing labels or notes are not operations and are accepted at any time.
|
|
17
17
|
* - **Billing relationships.** A purchased resource records its `checkout_session_id` and, once checkout completes, its `order_id`, `order_item_id` and `subscription_id`. The subscription is `pending` until the order is accepted, `provisioning` while the resource is created, and `active` once it is delivered. Bandwidth is a property of its floating IP, not a separate resource. Snapshots use a purchased per-region count quota, and backups are metered on the region's backup service; neither has an order or subscription of its own.
|
|
@@ -11,7 +11,7 @@
|
|
|
11
11
|
* ## Conventions
|
|
12
12
|
*
|
|
13
13
|
* - **Purchases.** A purchase that creates resources returns them together with the `checkout_session_id` of its Billing Checkout Session and, once checkout completes, its `order_id`. They are readable at once and start as `pending`: checkout may not be complete, the order has not been accepted, nothing exists in the cloud, no inventory such as an address is held, and fields known only after allocation, such as addresses, are null. Once Billing accepts the order, a resource becomes `provisioning` and then reaches its usual status, such as `active` or `available`. When the Checkout Session expires, the order is declined, canceled or expires, or creation fails, the resource ends `failed` and `failure_reason` states why; the charge for a resource that failed after acceptance is refunded. Read the Checkout Session and the order in Billing for checkout and payment progress.
|
|
14
|
-
* - **Commercial terms.** Compute returns no amounts. Catalog items, such as instance types, disk types and public IP pools, and the region's own products carry `billing`: the Billing plan an order line for them is sold under, the dimensions the line carries, how its quantity is counted for each usage type, and the meters its metered price reads. Read their prices from Billing with `search-prices
|
|
14
|
+
* - **Commercial terms.** Compute returns no amounts. Catalog items, such as instance types, disk types and public IP pools, and the region's own products carry `billing`: the Billing plan an order line for them is sold under, the dimensions the line carries, how its quantity is counted for each usage type, and the meters its metered price reads. Read their prices and rates from Billing with `search-prices`, quote a purchase or a change with Billing's `get-quote` using the same lines, and estimate metered usage with Billing's `estimate-usage`. A purchase chooses its terms with `billing`, which applies to all of its components.
|
|
15
15
|
* - **Checkout.** `checkout` is passed to Billing unchanged. Omit it for automatic checkout, which completes checkout within the request and pays from eligible credit grants and balance; insufficient funds refuse the request with HTTP 422 `BILLING_INSUFFICIENT_FUNDS`, and nothing is created. With `checkout.mode` set to `deferred`, the resources are returned `pending` with an open Checkout Session and no order, even for a zero total; nothing is created until the customer completes checkout in Billing, where a promotion code can be applied, and the order is paid.
|
|
16
16
|
* - **Operations.** Requests such as starting, stopping, attaching or deleting return HTTP 202 with the resource as it is when the request is accepted. While an operation runs, the resource's `operation` field names it; the field is null once the operation has finished, and the resource then shows the result. A resource with an operation in progress refuses another operation with HTTP 409 `COMPUTE_RESOURCE_BUSY`; an operation involving two resources, such as attaching a disk, is refused when either has one. A purchased change, such as a resize, is an operation from the moment its Checkout Session is created until the change is applied, the session expires or its order is canceled. Renaming and replacing labels or notes are not operations and are accepted at any time.
|
|
17
17
|
* - **Billing relationships.** A purchased resource records its `checkout_session_id` and, once checkout completes, its `order_id`, `order_item_id` and `subscription_id`. The subscription is `pending` until the order is accepted, `provisioning` while the resource is created, and `active` once it is delivered. Bandwidth is a property of its floating IP, not a separate resource. Snapshots use a purchased per-region count quota, and backups are metered on the region's backup service; neither has an order or subscription of its own.
|
|
@@ -11,7 +11,7 @@
|
|
|
11
11
|
* ## Conventions
|
|
12
12
|
*
|
|
13
13
|
* - **Purchases.** A purchase that creates resources returns them together with the `checkout_session_id` of its Billing Checkout Session and, once checkout completes, its `order_id`. They are readable at once and start as `pending`: checkout may not be complete, the order has not been accepted, nothing exists in the cloud, no inventory such as an address is held, and fields known only after allocation, such as addresses, are null. Once Billing accepts the order, a resource becomes `provisioning` and then reaches its usual status, such as `active` or `available`. When the Checkout Session expires, the order is declined, canceled or expires, or creation fails, the resource ends `failed` and `failure_reason` states why; the charge for a resource that failed after acceptance is refunded. Read the Checkout Session and the order in Billing for checkout and payment progress.
|
|
14
|
-
* - **Commercial terms.** Compute returns no amounts. Catalog items, such as instance types, disk types and public IP pools, and the region's own products carry `billing`: the Billing plan an order line for them is sold under, the dimensions the line carries, how its quantity is counted for each usage type, and the meters its metered price reads. Read their prices from Billing with `search-prices
|
|
14
|
+
* - **Commercial terms.** Compute returns no amounts. Catalog items, such as instance types, disk types and public IP pools, and the region's own products carry `billing`: the Billing plan an order line for them is sold under, the dimensions the line carries, how its quantity is counted for each usage type, and the meters its metered price reads. Read their prices and rates from Billing with `search-prices`, quote a purchase or a change with Billing's `get-quote` using the same lines, and estimate metered usage with Billing's `estimate-usage`. A purchase chooses its terms with `billing`, which applies to all of its components.
|
|
15
15
|
* - **Checkout.** `checkout` is passed to Billing unchanged. Omit it for automatic checkout, which completes checkout within the request and pays from eligible credit grants and balance; insufficient funds refuse the request with HTTP 422 `BILLING_INSUFFICIENT_FUNDS`, and nothing is created. With `checkout.mode` set to `deferred`, the resources are returned `pending` with an open Checkout Session and no order, even for a zero total; nothing is created until the customer completes checkout in Billing, where a promotion code can be applied, and the order is paid.
|
|
16
16
|
* - **Operations.** Requests such as starting, stopping, attaching or deleting return HTTP 202 with the resource as it is when the request is accepted. While an operation runs, the resource's `operation` field names it; the field is null once the operation has finished, and the resource then shows the result. A resource with an operation in progress refuses another operation with HTTP 409 `COMPUTE_RESOURCE_BUSY`; an operation involving two resources, such as attaching a disk, is refused when either has one. A purchased change, such as a resize, is an operation from the moment its Checkout Session is created until the change is applied, the session expires or its order is canceled. Renaming and replacing labels or notes are not operations and are accepted at any time.
|
|
17
17
|
* - **Billing relationships.** A purchased resource records its `checkout_session_id` and, once checkout completes, its `order_id`, `order_item_id` and `subscription_id`. The subscription is `pending` until the order is accepted, `provisioning` while the resource is created, and `active` once it is delivered. Bandwidth is a property of its floating IP, not a separate resource. Snapshots use a purchased per-region count quota, and backups are metered on the region's backup service; neither has an order or subscription of its own.
|
|
@@ -11,7 +11,7 @@
|
|
|
11
11
|
* ## Conventions
|
|
12
12
|
*
|
|
13
13
|
* - **Purchases.** A purchase that creates resources returns them together with the `checkout_session_id` of its Billing Checkout Session and, once checkout completes, its `order_id`. They are readable at once and start as `pending`: checkout may not be complete, the order has not been accepted, nothing exists in the cloud, no inventory such as an address is held, and fields known only after allocation, such as addresses, are null. Once Billing accepts the order, a resource becomes `provisioning` and then reaches its usual status, such as `active` or `available`. When the Checkout Session expires, the order is declined, canceled or expires, or creation fails, the resource ends `failed` and `failure_reason` states why; the charge for a resource that failed after acceptance is refunded. Read the Checkout Session and the order in Billing for checkout and payment progress.
|
|
14
|
-
* - **Commercial terms.** Compute returns no amounts. Catalog items, such as instance types, disk types and public IP pools, and the region's own products carry `billing`: the Billing plan an order line for them is sold under, the dimensions the line carries, how its quantity is counted for each usage type, and the meters its metered price reads. Read their prices from Billing with `search-prices
|
|
14
|
+
* - **Commercial terms.** Compute returns no amounts. Catalog items, such as instance types, disk types and public IP pools, and the region's own products carry `billing`: the Billing plan an order line for them is sold under, the dimensions the line carries, how its quantity is counted for each usage type, and the meters its metered price reads. Read their prices and rates from Billing with `search-prices`, quote a purchase or a change with Billing's `get-quote` using the same lines, and estimate metered usage with Billing's `estimate-usage`. A purchase chooses its terms with `billing`, which applies to all of its components.
|
|
15
15
|
* - **Checkout.** `checkout` is passed to Billing unchanged. Omit it for automatic checkout, which completes checkout within the request and pays from eligible credit grants and balance; insufficient funds refuse the request with HTTP 422 `BILLING_INSUFFICIENT_FUNDS`, and nothing is created. With `checkout.mode` set to `deferred`, the resources are returned `pending` with an open Checkout Session and no order, even for a zero total; nothing is created until the customer completes checkout in Billing, where a promotion code can be applied, and the order is paid.
|
|
16
16
|
* - **Operations.** Requests such as starting, stopping, attaching or deleting return HTTP 202 with the resource as it is when the request is accepted. While an operation runs, the resource's `operation` field names it; the field is null once the operation has finished, and the resource then shows the result. A resource with an operation in progress refuses another operation with HTTP 409 `COMPUTE_RESOURCE_BUSY`; an operation involving two resources, such as attaching a disk, is refused when either has one. A purchased change, such as a resize, is an operation from the moment its Checkout Session is created until the change is applied, the session expires or its order is canceled. Renaming and replacing labels or notes are not operations and are accepted at any time.
|
|
17
17
|
* - **Billing relationships.** A purchased resource records its `checkout_session_id` and, once checkout completes, its `order_id`, `order_item_id` and `subscription_id`. The subscription is `pending` until the order is accepted, `provisioning` while the resource is created, and `active` once it is delivered. Bandwidth is a property of its floating IP, not a separate resource. Snapshots use a purchased per-region count quota, and backups are metered on the region's backup service; neither has an order or subscription of its own.
|
|
@@ -11,7 +11,7 @@
|
|
|
11
11
|
* ## Conventions
|
|
12
12
|
*
|
|
13
13
|
* - **Purchases.** A purchase that creates resources returns them together with the `checkout_session_id` of its Billing Checkout Session and, once checkout completes, its `order_id`. They are readable at once and start as `pending`: checkout may not be complete, the order has not been accepted, nothing exists in the cloud, no inventory such as an address is held, and fields known only after allocation, such as addresses, are null. Once Billing accepts the order, a resource becomes `provisioning` and then reaches its usual status, such as `active` or `available`. When the Checkout Session expires, the order is declined, canceled or expires, or creation fails, the resource ends `failed` and `failure_reason` states why; the charge for a resource that failed after acceptance is refunded. Read the Checkout Session and the order in Billing for checkout and payment progress.
|
|
14
|
-
* - **Commercial terms.** Compute returns no amounts. Catalog items, such as instance types, disk types and public IP pools, and the region's own products carry `billing`: the Billing plan an order line for them is sold under, the dimensions the line carries, how its quantity is counted for each usage type, and the meters its metered price reads. Read their prices from Billing with `search-prices
|
|
14
|
+
* - **Commercial terms.** Compute returns no amounts. Catalog items, such as instance types, disk types and public IP pools, and the region's own products carry `billing`: the Billing plan an order line for them is sold under, the dimensions the line carries, how its quantity is counted for each usage type, and the meters its metered price reads. Read their prices and rates from Billing with `search-prices`, quote a purchase or a change with Billing's `get-quote` using the same lines, and estimate metered usage with Billing's `estimate-usage`. A purchase chooses its terms with `billing`, which applies to all of its components.
|
|
15
15
|
* - **Checkout.** `checkout` is passed to Billing unchanged. Omit it for automatic checkout, which completes checkout within the request and pays from eligible credit grants and balance; insufficient funds refuse the request with HTTP 422 `BILLING_INSUFFICIENT_FUNDS`, and nothing is created. With `checkout.mode` set to `deferred`, the resources are returned `pending` with an open Checkout Session and no order, even for a zero total; nothing is created until the customer completes checkout in Billing, where a promotion code can be applied, and the order is paid.
|
|
16
16
|
* - **Operations.** Requests such as starting, stopping, attaching or deleting return HTTP 202 with the resource as it is when the request is accepted. While an operation runs, the resource's `operation` field names it; the field is null once the operation has finished, and the resource then shows the result. A resource with an operation in progress refuses another operation with HTTP 409 `COMPUTE_RESOURCE_BUSY`; an operation involving two resources, such as attaching a disk, is refused when either has one. A purchased change, such as a resize, is an operation from the moment its Checkout Session is created until the change is applied, the session expires or its order is canceled. Renaming and replacing labels or notes are not operations and are accepted at any time.
|
|
17
17
|
* - **Billing relationships.** A purchased resource records its `checkout_session_id` and, once checkout completes, its `order_id`, `order_item_id` and `subscription_id`. The subscription is `pending` until the order is accepted, `provisioning` while the resource is created, and `active` once it is delivered. Bandwidth is a property of its floating IP, not a separate resource. Snapshots use a purchased per-region count quota, and backups are metered on the region's backup service; neither has an order or subscription of its own.
|
|
@@ -11,7 +11,7 @@
|
|
|
11
11
|
* ## Conventions
|
|
12
12
|
*
|
|
13
13
|
* - **Purchases.** A purchase that creates resources returns them together with the `checkout_session_id` of its Billing Checkout Session and, once checkout completes, its `order_id`. They are readable at once and start as `pending`: checkout may not be complete, the order has not been accepted, nothing exists in the cloud, no inventory such as an address is held, and fields known only after allocation, such as addresses, are null. Once Billing accepts the order, a resource becomes `provisioning` and then reaches its usual status, such as `active` or `available`. When the Checkout Session expires, the order is declined, canceled or expires, or creation fails, the resource ends `failed` and `failure_reason` states why; the charge for a resource that failed after acceptance is refunded. Read the Checkout Session and the order in Billing for checkout and payment progress.
|
|
14
|
-
* - **Commercial terms.** Compute returns no amounts. Catalog items, such as instance types, disk types and public IP pools, and the region's own products carry `billing`: the Billing plan an order line for them is sold under, the dimensions the line carries, how its quantity is counted for each usage type, and the meters its metered price reads. Read their prices from Billing with `search-prices
|
|
14
|
+
* - **Commercial terms.** Compute returns no amounts. Catalog items, such as instance types, disk types and public IP pools, and the region's own products carry `billing`: the Billing plan an order line for them is sold under, the dimensions the line carries, how its quantity is counted for each usage type, and the meters its metered price reads. Read their prices and rates from Billing with `search-prices`, quote a purchase or a change with Billing's `get-quote` using the same lines, and estimate metered usage with Billing's `estimate-usage`. A purchase chooses its terms with `billing`, which applies to all of its components.
|
|
15
15
|
* - **Checkout.** `checkout` is passed to Billing unchanged. Omit it for automatic checkout, which completes checkout within the request and pays from eligible credit grants and balance; insufficient funds refuse the request with HTTP 422 `BILLING_INSUFFICIENT_FUNDS`, and nothing is created. With `checkout.mode` set to `deferred`, the resources are returned `pending` with an open Checkout Session and no order, even for a zero total; nothing is created until the customer completes checkout in Billing, where a promotion code can be applied, and the order is paid.
|
|
16
16
|
* - **Operations.** Requests such as starting, stopping, attaching or deleting return HTTP 202 with the resource as it is when the request is accepted. While an operation runs, the resource's `operation` field names it; the field is null once the operation has finished, and the resource then shows the result. A resource with an operation in progress refuses another operation with HTTP 409 `COMPUTE_RESOURCE_BUSY`; an operation involving two resources, such as attaching a disk, is refused when either has one. A purchased change, such as a resize, is an operation from the moment its Checkout Session is created until the change is applied, the session expires or its order is canceled. Renaming and replacing labels or notes are not operations and are accepted at any time.
|
|
17
17
|
* - **Billing relationships.** A purchased resource records its `checkout_session_id` and, once checkout completes, its `order_id`, `order_item_id` and `subscription_id`. The subscription is `pending` until the order is accepted, `provisioning` while the resource is created, and `active` once it is delivered. Bandwidth is a property of its floating IP, not a separate resource. Snapshots use a purchased per-region count quota, and backups are metered on the region's backup service; neither has an order or subscription of its own.
|
|
@@ -11,7 +11,7 @@
|
|
|
11
11
|
* ## Conventions
|
|
12
12
|
*
|
|
13
13
|
* - **Purchases.** A purchase that creates resources returns them together with the `checkout_session_id` of its Billing Checkout Session and, once checkout completes, its `order_id`. They are readable at once and start as `pending`: checkout may not be complete, the order has not been accepted, nothing exists in the cloud, no inventory such as an address is held, and fields known only after allocation, such as addresses, are null. Once Billing accepts the order, a resource becomes `provisioning` and then reaches its usual status, such as `active` or `available`. When the Checkout Session expires, the order is declined, canceled or expires, or creation fails, the resource ends `failed` and `failure_reason` states why; the charge for a resource that failed after acceptance is refunded. Read the Checkout Session and the order in Billing for checkout and payment progress.
|
|
14
|
-
* - **Commercial terms.** Compute returns no amounts. Catalog items, such as instance types, disk types and public IP pools, and the region's own products carry `billing`: the Billing plan an order line for them is sold under, the dimensions the line carries, how its quantity is counted for each usage type, and the meters its metered price reads. Read their prices from Billing with `search-prices
|
|
14
|
+
* - **Commercial terms.** Compute returns no amounts. Catalog items, such as instance types, disk types and public IP pools, and the region's own products carry `billing`: the Billing plan an order line for them is sold under, the dimensions the line carries, how its quantity is counted for each usage type, and the meters its metered price reads. Read their prices and rates from Billing with `search-prices`, quote a purchase or a change with Billing's `get-quote` using the same lines, and estimate metered usage with Billing's `estimate-usage`. A purchase chooses its terms with `billing`, which applies to all of its components.
|
|
15
15
|
* - **Checkout.** `checkout` is passed to Billing unchanged. Omit it for automatic checkout, which completes checkout within the request and pays from eligible credit grants and balance; insufficient funds refuse the request with HTTP 422 `BILLING_INSUFFICIENT_FUNDS`, and nothing is created. With `checkout.mode` set to `deferred`, the resources are returned `pending` with an open Checkout Session and no order, even for a zero total; nothing is created until the customer completes checkout in Billing, where a promotion code can be applied, and the order is paid.
|
|
16
16
|
* - **Operations.** Requests such as starting, stopping, attaching or deleting return HTTP 202 with the resource as it is when the request is accepted. While an operation runs, the resource's `operation` field names it; the field is null once the operation has finished, and the resource then shows the result. A resource with an operation in progress refuses another operation with HTTP 409 `COMPUTE_RESOURCE_BUSY`; an operation involving two resources, such as attaching a disk, is refused when either has one. A purchased change, such as a resize, is an operation from the moment its Checkout Session is created until the change is applied, the session expires or its order is canceled. Renaming and replacing labels or notes are not operations and are accepted at any time.
|
|
17
17
|
* - **Billing relationships.** A purchased resource records its `checkout_session_id` and, once checkout completes, its `order_id`, `order_item_id` and `subscription_id`. The subscription is `pending` until the order is accepted, `provisioning` while the resource is created, and `active` once it is delivered. Bandwidth is a property of its floating IP, not a separate resource. Snapshots use a purchased per-region count quota, and backups are metered on the region's backup service; neither has an order or subscription of its own.
|
|
@@ -11,7 +11,7 @@
|
|
|
11
11
|
* ## Conventions
|
|
12
12
|
*
|
|
13
13
|
* - **Purchases.** A purchase that creates resources returns them together with the `checkout_session_id` of its Billing Checkout Session and, once checkout completes, its `order_id`. They are readable at once and start as `pending`: checkout may not be complete, the order has not been accepted, nothing exists in the cloud, no inventory such as an address is held, and fields known only after allocation, such as addresses, are null. Once Billing accepts the order, a resource becomes `provisioning` and then reaches its usual status, such as `active` or `available`. When the Checkout Session expires, the order is declined, canceled or expires, or creation fails, the resource ends `failed` and `failure_reason` states why; the charge for a resource that failed after acceptance is refunded. Read the Checkout Session and the order in Billing for checkout and payment progress.
|
|
14
|
-
* - **Commercial terms.** Compute returns no amounts. Catalog items, such as instance types, disk types and public IP pools, and the region's own products carry `billing`: the Billing plan an order line for them is sold under, the dimensions the line carries, how its quantity is counted for each usage type, and the meters its metered price reads. Read their prices from Billing with `search-prices
|
|
14
|
+
* - **Commercial terms.** Compute returns no amounts. Catalog items, such as instance types, disk types and public IP pools, and the region's own products carry `billing`: the Billing plan an order line for them is sold under, the dimensions the line carries, how its quantity is counted for each usage type, and the meters its metered price reads. Read their prices and rates from Billing with `search-prices`, quote a purchase or a change with Billing's `get-quote` using the same lines, and estimate metered usage with Billing's `estimate-usage`. A purchase chooses its terms with `billing`, which applies to all of its components.
|
|
15
15
|
* - **Checkout.** `checkout` is passed to Billing unchanged. Omit it for automatic checkout, which completes checkout within the request and pays from eligible credit grants and balance; insufficient funds refuse the request with HTTP 422 `BILLING_INSUFFICIENT_FUNDS`, and nothing is created. With `checkout.mode` set to `deferred`, the resources are returned `pending` with an open Checkout Session and no order, even for a zero total; nothing is created until the customer completes checkout in Billing, where a promotion code can be applied, and the order is paid.
|
|
16
16
|
* - **Operations.** Requests such as starting, stopping, attaching or deleting return HTTP 202 with the resource as it is when the request is accepted. While an operation runs, the resource's `operation` field names it; the field is null once the operation has finished, and the resource then shows the result. A resource with an operation in progress refuses another operation with HTTP 409 `COMPUTE_RESOURCE_BUSY`; an operation involving two resources, such as attaching a disk, is refused when either has one. A purchased change, such as a resize, is an operation from the moment its Checkout Session is created until the change is applied, the session expires or its order is canceled. Renaming and replacing labels or notes are not operations and are accepted at any time.
|
|
17
17
|
* - **Billing relationships.** A purchased resource records its `checkout_session_id` and, once checkout completes, its `order_id`, `order_item_id` and `subscription_id`. The subscription is `pending` until the order is accepted, `provisioning` while the resource is created, and `active` once it is delivered. Bandwidth is a property of its floating IP, not a separate resource. Snapshots use a purchased per-region count quota, and backups are metered on the region's backup service; neither has an order or subscription of its own.
|
|
@@ -11,7 +11,7 @@
|
|
|
11
11
|
* ## Conventions
|
|
12
12
|
*
|
|
13
13
|
* - **Purchases.** A purchase that creates resources returns them together with the `checkout_session_id` of its Billing Checkout Session and, once checkout completes, its `order_id`. They are readable at once and start as `pending`: checkout may not be complete, the order has not been accepted, nothing exists in the cloud, no inventory such as an address is held, and fields known only after allocation, such as addresses, are null. Once Billing accepts the order, a resource becomes `provisioning` and then reaches its usual status, such as `active` or `available`. When the Checkout Session expires, the order is declined, canceled or expires, or creation fails, the resource ends `failed` and `failure_reason` states why; the charge for a resource that failed after acceptance is refunded. Read the Checkout Session and the order in Billing for checkout and payment progress.
|
|
14
|
-
* - **Commercial terms.** Compute returns no amounts. Catalog items, such as instance types, disk types and public IP pools, and the region's own products carry `billing`: the Billing plan an order line for them is sold under, the dimensions the line carries, how its quantity is counted for each usage type, and the meters its metered price reads. Read their prices from Billing with `search-prices
|
|
14
|
+
* - **Commercial terms.** Compute returns no amounts. Catalog items, such as instance types, disk types and public IP pools, and the region's own products carry `billing`: the Billing plan an order line for them is sold under, the dimensions the line carries, how its quantity is counted for each usage type, and the meters its metered price reads. Read their prices and rates from Billing with `search-prices`, quote a purchase or a change with Billing's `get-quote` using the same lines, and estimate metered usage with Billing's `estimate-usage`. A purchase chooses its terms with `billing`, which applies to all of its components.
|
|
15
15
|
* - **Checkout.** `checkout` is passed to Billing unchanged. Omit it for automatic checkout, which completes checkout within the request and pays from eligible credit grants and balance; insufficient funds refuse the request with HTTP 422 `BILLING_INSUFFICIENT_FUNDS`, and nothing is created. With `checkout.mode` set to `deferred`, the resources are returned `pending` with an open Checkout Session and no order, even for a zero total; nothing is created until the customer completes checkout in Billing, where a promotion code can be applied, and the order is paid.
|
|
16
16
|
* - **Operations.** Requests such as starting, stopping, attaching or deleting return HTTP 202 with the resource as it is when the request is accepted. While an operation runs, the resource's `operation` field names it; the field is null once the operation has finished, and the resource then shows the result. A resource with an operation in progress refuses another operation with HTTP 409 `COMPUTE_RESOURCE_BUSY`; an operation involving two resources, such as attaching a disk, is refused when either has one. A purchased change, such as a resize, is an operation from the moment its Checkout Session is created until the change is applied, the session expires or its order is canceled. Renaming and replacing labels or notes are not operations and are accepted at any time.
|
|
17
17
|
* - **Billing relationships.** A purchased resource records its `checkout_session_id` and, once checkout completes, its `order_id`, `order_item_id` and `subscription_id`. The subscription is `pending` until the order is accepted, `provisioning` while the resource is created, and `active` once it is delivered. Bandwidth is a property of its floating IP, not a separate resource. Snapshots use a purchased per-region count quota, and backups are metered on the region's backup service; neither has an order or subscription of its own.
|
|
@@ -11,7 +11,7 @@
|
|
|
11
11
|
* ## Conventions
|
|
12
12
|
*
|
|
13
13
|
* - **Purchases.** A purchase that creates resources returns them together with the `checkout_session_id` of its Billing Checkout Session and, once checkout completes, its `order_id`. They are readable at once and start as `pending`: checkout may not be complete, the order has not been accepted, nothing exists in the cloud, no inventory such as an address is held, and fields known only after allocation, such as addresses, are null. Once Billing accepts the order, a resource becomes `provisioning` and then reaches its usual status, such as `active` or `available`. When the Checkout Session expires, the order is declined, canceled or expires, or creation fails, the resource ends `failed` and `failure_reason` states why; the charge for a resource that failed after acceptance is refunded. Read the Checkout Session and the order in Billing for checkout and payment progress.
|
|
14
|
-
* - **Commercial terms.** Compute returns no amounts. Catalog items, such as instance types, disk types and public IP pools, and the region's own products carry `billing`: the Billing plan an order line for them is sold under, the dimensions the line carries, how its quantity is counted for each usage type, and the meters its metered price reads. Read their prices from Billing with `search-prices
|
|
14
|
+
* - **Commercial terms.** Compute returns no amounts. Catalog items, such as instance types, disk types and public IP pools, and the region's own products carry `billing`: the Billing plan an order line for them is sold under, the dimensions the line carries, how its quantity is counted for each usage type, and the meters its metered price reads. Read their prices and rates from Billing with `search-prices`, quote a purchase or a change with Billing's `get-quote` using the same lines, and estimate metered usage with Billing's `estimate-usage`. A purchase chooses its terms with `billing`, which applies to all of its components.
|
|
15
15
|
* - **Checkout.** `checkout` is passed to Billing unchanged. Omit it for automatic checkout, which completes checkout within the request and pays from eligible credit grants and balance; insufficient funds refuse the request with HTTP 422 `BILLING_INSUFFICIENT_FUNDS`, and nothing is created. With `checkout.mode` set to `deferred`, the resources are returned `pending` with an open Checkout Session and no order, even for a zero total; nothing is created until the customer completes checkout in Billing, where a promotion code can be applied, and the order is paid.
|
|
16
16
|
* - **Operations.** Requests such as starting, stopping, attaching or deleting return HTTP 202 with the resource as it is when the request is accepted. While an operation runs, the resource's `operation` field names it; the field is null once the operation has finished, and the resource then shows the result. A resource with an operation in progress refuses another operation with HTTP 409 `COMPUTE_RESOURCE_BUSY`; an operation involving two resources, such as attaching a disk, is refused when either has one. A purchased change, such as a resize, is an operation from the moment its Checkout Session is created until the change is applied, the session expires or its order is canceled. Renaming and replacing labels or notes are not operations and are accepted at any time.
|
|
17
17
|
* - **Billing relationships.** A purchased resource records its `checkout_session_id` and, once checkout completes, its `order_id`, `order_item_id` and `subscription_id`. The subscription is `pending` until the order is accepted, `provisioning` while the resource is created, and `active` once it is delivered. Bandwidth is a property of its floating IP, not a separate resource. Snapshots use a purchased per-region count quota, and backups are metered on the region's backup service; neither has an order or subscription of its own.
|
|
@@ -11,7 +11,7 @@
|
|
|
11
11
|
* ## Conventions
|
|
12
12
|
*
|
|
13
13
|
* - **Purchases.** A purchase that creates resources returns them together with the `checkout_session_id` of its Billing Checkout Session and, once checkout completes, its `order_id`. They are readable at once and start as `pending`: checkout may not be complete, the order has not been accepted, nothing exists in the cloud, no inventory such as an address is held, and fields known only after allocation, such as addresses, are null. Once Billing accepts the order, a resource becomes `provisioning` and then reaches its usual status, such as `active` or `available`. When the Checkout Session expires, the order is declined, canceled or expires, or creation fails, the resource ends `failed` and `failure_reason` states why; the charge for a resource that failed after acceptance is refunded. Read the Checkout Session and the order in Billing for checkout and payment progress.
|
|
14
|
-
* - **Commercial terms.** Compute returns no amounts. Catalog items, such as instance types, disk types and public IP pools, and the region's own products carry `billing`: the Billing plan an order line for them is sold under, the dimensions the line carries, how its quantity is counted for each usage type, and the meters its metered price reads. Read their prices from Billing with `search-prices
|
|
14
|
+
* - **Commercial terms.** Compute returns no amounts. Catalog items, such as instance types, disk types and public IP pools, and the region's own products carry `billing`: the Billing plan an order line for them is sold under, the dimensions the line carries, how its quantity is counted for each usage type, and the meters its metered price reads. Read their prices and rates from Billing with `search-prices`, quote a purchase or a change with Billing's `get-quote` using the same lines, and estimate metered usage with Billing's `estimate-usage`. A purchase chooses its terms with `billing`, which applies to all of its components.
|
|
15
15
|
* - **Checkout.** `checkout` is passed to Billing unchanged. Omit it for automatic checkout, which completes checkout within the request and pays from eligible credit grants and balance; insufficient funds refuse the request with HTTP 422 `BILLING_INSUFFICIENT_FUNDS`, and nothing is created. With `checkout.mode` set to `deferred`, the resources are returned `pending` with an open Checkout Session and no order, even for a zero total; nothing is created until the customer completes checkout in Billing, where a promotion code can be applied, and the order is paid.
|
|
16
16
|
* - **Operations.** Requests such as starting, stopping, attaching or deleting return HTTP 202 with the resource as it is when the request is accepted. While an operation runs, the resource's `operation` field names it; the field is null once the operation has finished, and the resource then shows the result. A resource with an operation in progress refuses another operation with HTTP 409 `COMPUTE_RESOURCE_BUSY`; an operation involving two resources, such as attaching a disk, is refused when either has one. A purchased change, such as a resize, is an operation from the moment its Checkout Session is created until the change is applied, the session expires or its order is canceled. Renaming and replacing labels or notes are not operations and are accepted at any time.
|
|
17
17
|
* - **Billing relationships.** A purchased resource records its `checkout_session_id` and, once checkout completes, its `order_id`, `order_item_id` and `subscription_id`. The subscription is `pending` until the order is accepted, `provisioning` while the resource is created, and `active` once it is delivered. Bandwidth is a property of its floating IP, not a separate resource. Snapshots use a purchased per-region count quota, and backups are metered on the region's backup service; neither has an order or subscription of its own.
|
|
@@ -11,7 +11,7 @@
|
|
|
11
11
|
* ## Conventions
|
|
12
12
|
*
|
|
13
13
|
* - **Purchases.** A purchase that creates resources returns them together with the `checkout_session_id` of its Billing Checkout Session and, once checkout completes, its `order_id`. They are readable at once and start as `pending`: checkout may not be complete, the order has not been accepted, nothing exists in the cloud, no inventory such as an address is held, and fields known only after allocation, such as addresses, are null. Once Billing accepts the order, a resource becomes `provisioning` and then reaches its usual status, such as `active` or `available`. When the Checkout Session expires, the order is declined, canceled or expires, or creation fails, the resource ends `failed` and `failure_reason` states why; the charge for a resource that failed after acceptance is refunded. Read the Checkout Session and the order in Billing for checkout and payment progress.
|
|
14
|
-
* - **Commercial terms.** Compute returns no amounts. Catalog items, such as instance types, disk types and public IP pools, and the region's own products carry `billing`: the Billing plan an order line for them is sold under, the dimensions the line carries, how its quantity is counted for each usage type, and the meters its metered price reads. Read their prices from Billing with `search-prices
|
|
14
|
+
* - **Commercial terms.** Compute returns no amounts. Catalog items, such as instance types, disk types and public IP pools, and the region's own products carry `billing`: the Billing plan an order line for them is sold under, the dimensions the line carries, how its quantity is counted for each usage type, and the meters its metered price reads. Read their prices and rates from Billing with `search-prices`, quote a purchase or a change with Billing's `get-quote` using the same lines, and estimate metered usage with Billing's `estimate-usage`. A purchase chooses its terms with `billing`, which applies to all of its components.
|
|
15
15
|
* - **Checkout.** `checkout` is passed to Billing unchanged. Omit it for automatic checkout, which completes checkout within the request and pays from eligible credit grants and balance; insufficient funds refuse the request with HTTP 422 `BILLING_INSUFFICIENT_FUNDS`, and nothing is created. With `checkout.mode` set to `deferred`, the resources are returned `pending` with an open Checkout Session and no order, even for a zero total; nothing is created until the customer completes checkout in Billing, where a promotion code can be applied, and the order is paid.
|
|
16
16
|
* - **Operations.** Requests such as starting, stopping, attaching or deleting return HTTP 202 with the resource as it is when the request is accepted. While an operation runs, the resource's `operation` field names it; the field is null once the operation has finished, and the resource then shows the result. A resource with an operation in progress refuses another operation with HTTP 409 `COMPUTE_RESOURCE_BUSY`; an operation involving two resources, such as attaching a disk, is refused when either has one. A purchased change, such as a resize, is an operation from the moment its Checkout Session is created until the change is applied, the session expires or its order is canceled. Renaming and replacing labels or notes are not operations and are accepted at any time.
|
|
17
17
|
* - **Billing relationships.** A purchased resource records its `checkout_session_id` and, once checkout completes, its `order_id`, `order_item_id` and `subscription_id`. The subscription is `pending` until the order is accepted, `provisioning` while the resource is created, and `active` once it is delivered. Bandwidth is a property of its floating IP, not a separate resource. Snapshots use a purchased per-region count quota, and backups are metered on the region's backup service; neither has an order or subscription of its own.
|
|
@@ -11,7 +11,7 @@
|
|
|
11
11
|
* ## Conventions
|
|
12
12
|
*
|
|
13
13
|
* - **Purchases.** A purchase that creates resources returns them together with the `checkout_session_id` of its Billing Checkout Session and, once checkout completes, its `order_id`. They are readable at once and start as `pending`: checkout may not be complete, the order has not been accepted, nothing exists in the cloud, no inventory such as an address is held, and fields known only after allocation, such as addresses, are null. Once Billing accepts the order, a resource becomes `provisioning` and then reaches its usual status, such as `active` or `available`. When the Checkout Session expires, the order is declined, canceled or expires, or creation fails, the resource ends `failed` and `failure_reason` states why; the charge for a resource that failed after acceptance is refunded. Read the Checkout Session and the order in Billing for checkout and payment progress.
|
|
14
|
-
* - **Commercial terms.** Compute returns no amounts. Catalog items, such as instance types, disk types and public IP pools, and the region's own products carry `billing`: the Billing plan an order line for them is sold under, the dimensions the line carries, how its quantity is counted for each usage type, and the meters its metered price reads. Read their prices from Billing with `search-prices
|
|
14
|
+
* - **Commercial terms.** Compute returns no amounts. Catalog items, such as instance types, disk types and public IP pools, and the region's own products carry `billing`: the Billing plan an order line for them is sold under, the dimensions the line carries, how its quantity is counted for each usage type, and the meters its metered price reads. Read their prices and rates from Billing with `search-prices`, quote a purchase or a change with Billing's `get-quote` using the same lines, and estimate metered usage with Billing's `estimate-usage`. A purchase chooses its terms with `billing`, which applies to all of its components.
|
|
15
15
|
* - **Checkout.** `checkout` is passed to Billing unchanged. Omit it for automatic checkout, which completes checkout within the request and pays from eligible credit grants and balance; insufficient funds refuse the request with HTTP 422 `BILLING_INSUFFICIENT_FUNDS`, and nothing is created. With `checkout.mode` set to `deferred`, the resources are returned `pending` with an open Checkout Session and no order, even for a zero total; nothing is created until the customer completes checkout in Billing, where a promotion code can be applied, and the order is paid.
|
|
16
16
|
* - **Operations.** Requests such as starting, stopping, attaching or deleting return HTTP 202 with the resource as it is when the request is accepted. While an operation runs, the resource's `operation` field names it; the field is null once the operation has finished, and the resource then shows the result. A resource with an operation in progress refuses another operation with HTTP 409 `COMPUTE_RESOURCE_BUSY`; an operation involving two resources, such as attaching a disk, is refused when either has one. A purchased change, such as a resize, is an operation from the moment its Checkout Session is created until the change is applied, the session expires or its order is canceled. Renaming and replacing labels or notes are not operations and are accepted at any time.
|
|
17
17
|
* - **Billing relationships.** A purchased resource records its `checkout_session_id` and, once checkout completes, its `order_id`, `order_item_id` and `subscription_id`. The subscription is `pending` until the order is accepted, `provisioning` while the resource is created, and `active` once it is delivered. Bandwidth is a property of its floating IP, not a separate resource. Snapshots use a purchased per-region count quota, and backups are metered on the region's backup service; neither has an order or subscription of its own.
|