Skip to content

Track 3 Tier 1: API how-tos (GetResourceReservations, UndeployApps, RemoveEntitiesFromTopology) + resolution diagnostics - #19

Merged
nahumtimerman merged 2 commits into
mainfrom
docs/track3-tier1-api-howtos
Jul 27, 2026
Merged

Track 3 Tier 1: API how-tos (GetResourceReservations, UndeployApps, RemoveEntitiesFromTopology) + resolution diagnostics#19
nahumtimerman merged 2 commits into
mainfrom
docs/track3-tier1-api-howtos

Conversation

@nahumtimerman

Copy link
Copy Markdown
Collaborator

Fills the highest-priority documentation gaps from the how-to coverage audit: three shipped CloudShell Automation API methods that had no usage documentation, plus the abstract-resolution failure diagnostics that shipped undocumented.

New articles (devguide/available-cs-api/useful-cs-api-examples/)

  • Getting a Resource's ReservationsGetResourceReservations(resourceFullPath, includeHistorical, maxResults); active/pending/completed, pagination (TotalCount vs page), Python example.
  • Undeploying Apps While Keeping the ResourceUndeployApps(resourcesFullPath[]); destroys the cloud-provider VM but keeps the resource (vs delete), bulk-teardown pattern.
  • Removing Entities from a TopologyRemoveEntitiesFromTopology(topologyName, entityIds[]); removes services/abstract resources (+ attached routes) from a blueprint.

Updated

  • Reserving blueprints fails on nonexistent resource conflicts — new "Reading the resolution diagnostics" section explaining the failure notification's View Details breakdown (Unresolvable / Conflict-blocked / Resolved / Routes), correctly scoped: it appears only for truly-unresolvable requirements; conflict-only failures still show the conflict-resolver dialog.

Grounding & validation

  • Every signature, parameter, default, status value, and behavior is verified against the Trunk server code and integration test scenarios (e.g. RestGetResourceReservationsScenarios, RemoveEntitiesFromTopologyScenarios), then adversarially re-checked. Notably UndeployApps takes only resourcesFullPath[] (no reservation id).
  • npm run build passes (only the 3 pre-existing abstract-resources.md broken links remain). Added undeploy/Undeploying/undeploys + pagination terms to .wordlist.txt.

🤖 Generated with Claude Code

nahumtimerman and others added 2 commits July 27, 2026 11:17
Adds usage guides for three previously-undocumented CloudShell Automation API
methods (GetResourceReservations, UndeployApps, RemoveEntitiesFromTopology) and a
troubleshooting section on reading the resolution-failure 'View Details' diagnostic.
Grounded in the server code and integration test scenarios.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
@nahumtimerman
nahumtimerman merged commit 9197818 into main Jul 27, 2026
1 check passed
@nahumtimerman
nahumtimerman deleted the docs/track3-tier1-api-howtos branch July 27, 2026 08:37
nahumtimerman added a commit that referenced this pull request Sep 10, 2026
…inputs, category validation (#24)

Documents the three behavior-changing items that landed on 2026.1 after the
2026.1.0.52 pass (#18) and were not covered by #19-#22.

Python 3 upgraded to 3.13.15 x64 (Trunk CS 189988/189997/189999, backported
in CS 190003). This is the WINDOWS bundled slot only - the Docker ES image
still builds Python 3.9.9, and so do the Linux VA and the from-script ES, so
every page states the platform split rather than a blanket "CloudShell now
uses 3.13". Python 2.7.18 is untouched. Also corrects setting-up-dev-env.md,
which #23 had just updated to say the bundled version is 3.9.9 - true when
it merged on Sep 6, wrong when the upgrade landed on Sep 8.

Global inputs kept on save as blueprint, with the new
KeepResourceGlobalInputsOnSaveAsBlueprint key (CS 189903/189905/189914).
Default is true, which is a behavior change on upgrade: inputs that fronted a
resource requirement used to be dropped and are now visible in the Reserve
dialog and the blueprint editor. Documented as a customer-visible key on the
Server (AppSettingVisibility.Customer, read by ServiceConfigSettingsLoader).

Blueprint import now fails on a category missing from the target domain
instead of silently dropping the association (CS 189942). The
ExportBlueprint/ImportBlueprint page from #22 already stated this, so it
needed no correction - only the release notes did.

Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant