[layers v2] Make underpinnings of azd layer-aware
- Dominant language
- Go
- Stars
- 569
- Forks
- 364
- Avg merge
- 2d 18h
- Merged PRs (30d)
- 130
Description
Part of #9765.
NOTE: this issue is work that other consumers (like Azure Foundry) will need, and should be scheduled first.
There's a few pieces here:
- We need to add in functions, to our RPC layer, so extensions can add/edit/update layers, services and infra entries.
- Existing RPC functions need to allow for a layer parameter as part of their request. We're not abandoning the existing flat format for non-layered provisioning, so layer is optional.
- Layer should also be included in results, which implies we're extending any existing data models to also include layer information.
- We need to make the RPC layer functions write to the "layered provisioning v1.5" format, where `layer` is a top-level attribute, like this:
```yaml
# new format (layered provisioning v1.5)
layers:
- name: layer-a
infra:
# same format as 'infra' today, just nested in a layer instead of at the root
services:
# same format as 'services' today, just nested in a layer instead of at the root
```
- We'll need to make a call about what the right way is to handle the old layered provisioning format, since it didn't include services before and is not entirely forward compatible.
- We'll also need to keep an eye on PR #9747, where @vhvb1989 is working out how we properly ship RPC changes that are in-progress (i.e., beta) and then how they're properly promoted once they're ready.
Once this is done, extensions shouldn't have to know anything about how azure.yaml is structured, apart from understanding the basic envelope for an 'infra' component (i.e., `infra: { provider, path }`), for instance.
Contributor guide
Assessment
This issue has not been assessed yet.