anthony-c-martin

Spec: ARM Templates using OCI

Problem Statement

Modules (Bicep) or nested deployments (ARM JSON) is a popular mechanism for code reuse. A nested template is represented as a resource defined inside its parent template, containing the full "child template" to execute.

This embedding works well, but creates the following challenge:

• Any changes in size to a child template also increase the size of parent templates. This creates challenges around storage limits and increases memory usage unneccessarily.
• Because child templates are embedded as JSON, line number or positional information is lost when being deployed.
• There is often duplication (e.g. if a child module is referenced multiple times).
• The above problems grow exponentially with the depth of the nested structure.

anthony-c-martin

using System;
using System.IO;
using System.Threading.Tasks;
using System.Collections.Generic;
using System.IO.Abstractions;
using Bicep.Core;
using Bicep.Core.Analyzers.Interfaces;
using Bicep.Core.Analyzers.Linter;
using Bicep.Core.Configuration;
using Bicep.Core.Emit;

anthony-c-martin

Bicep Deploy

anthony-c-martin

Imagine the following Bicep file:

@allowed(['foo'])
param thisMustBeFoo string

param isFooFoo bool

With the following parameters file:

anthony-c-martin

using System;
using System.Linq;
using Bicep.Core.Diagnostics;
using Bicep.Core.Parsing;
using Bicep.Core.PrettyPrint;
using Bicep.Core.PrettyPrint.Options;
using Bicep.Core.Syntax;

public class Program
{

anthony-c-martin

Stacks + Bicep Extensibility

Problem Statement

Deployment Stacks requires the ability to manage the full lifecycle (including deletion) of all resources defined inside a Stack. Currently this is only possible for Azure resources, not extensible ones, due to lack of an id field, and an authentication mechanism for an extensible control plane.

Goals

• Provide an id equivalent which Stacks can use to uniquely identify an extensible resource for change tracking.
• Provide a mechanism to allow Stacks to submit Delete & Get operations against extensible resources.

This spec will be broken down into two parts to cover these separate goals.

anthony-c-martin

• Generate random data
• ToUpper locale differences
• Consume Bicep Types programatically

anthony-c-martin

Idea: First-class 'scope' concept to support Stacks deletion

Concept

Introduce a first-class concept of 'scope' into Bicep for extensible resources, so that Stacks understands ownership, and is able to request deletion of extensible resources that are deployed 'inside' Azure resources.

Why is this necessary?

Stacks currently stores a list of id properties for Azure resources to go and clean up if they are removed from the Stack. Extensible resources generally require authentication with another control plane; details of this are difficult to persist or provide to the Stacks RP in a reusable manner.

Stacks and What-If would probably also benefit from the concept of 'ownership' - e.g. understanding that particular extensible resources are scoped 'within' Azure resources.

anthony-c-martin

Bicep Imports - Cross-Module

Goals

• It should be unambiguous to the compiler which imports are used in a given module file (for validation purposes).
• Minimal boilerplate when passing imports from parent -> child module.
• Transferring information about imports from parent -> child should ideally avoid having to define parameters.
• Specifics of the scope being targeted should preferably be kept out of the Bicep file itself.

Design

Each import consists of optional 'configuration', which must be specified in the file declaring the import (child module), as well as a 'scope'* which must be satisfied by the caller (parent module).

anthony-c-martin

Bicep Extensibility Investigation - Phase 1

This document outlines the changes that are needed to Bicep, ARM Template JSON, and the ARM Deployment engine in order to support the ability to deploy resources outside of the ARM control plane. The Bicep syntax is liable to change, and will go through the normal design process.

Phase 1 relates to enabling a limited number of built-in 1st party providers. Phase 2 will permit the enablement of 3rd party providers.

Purpose / Goals

• Permit authoring and deploying of custom (non-ARM) resource types through Bicep as part of an ARM Template deployment, with a feature set as full as the features available for ARM resources.
• Leave the door open for 3rd party extensibility with a design which is compatible.

Non-goals