-
Notifications
You must be signed in to change notification settings - Fork 194
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Deployment Stacks: Expose configurable settings for actionOnUnmanage
and denySettings
#4331
base: main
Are you sure you want to change the base?
Conversation
2128026
to
7d3550d
Compare
Azure Dev CLI Install InstructionsInstall scriptsMacOS/Linux
bash:
pwsh:
WindowsPowerShell install
MSI install
Standalone Binary
MSI
Documentationlearn.microsoft.com documentationtitle: Azure Developer CLI reference
|
Provider ProviderKind `yaml:"provider,omitempty"` | ||
Path string `yaml:"path,omitempty"` | ||
Module string `yaml:"module,omitempty"` | ||
DeploymentStacks map[string]any `yaml:"deploymentStacks,omitempty"` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Given that we parse it into a concrete struct azapi.deploymentStackOptions
at a later point in time of execution, would we prefer to simply do the parsing into a structured object here?
I would prefer to avoid options map[string]any
in bicep_provider.go
-- Bicep provider clearly knows what the options should look like, perhaps we would not want this type of error to be caught so late?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree with you but we have a couple of constraints due to the package dependency graph that exist today that may cause circular dependencies. Let me see if there are any other options available.
type StackDeployments struct { | ||
credentialProvider account.SubscriptionCredentialProvider | ||
armClientOptions *arm.ClientOptions | ||
standardDeployments *StandardDeployments | ||
cloud *cloud.Cloud | ||
} | ||
|
||
type deploymentStackOptions struct { | ||
BypassStackOutOfSyncError *bool `yaml:"bypassStackOutOfSyncError,omitempty"` | ||
ActionOnUnmanage *armdeploymentstacks.ActionOnUnmanage `yaml:"actionOnUnmanage,omitempty"` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm a little worried about the approach of adding all the ARM properties to azure.yaml
and the pass-through idea here.
Looking at what we have:
infra:
provider: bicep
deploymentStacks:
bypassStackOutOfSyncError: false
actionOnUnmanage:
managementGroups: delete # delete or detach
resourceGroups: delete # delete or detach
resources: delete # delete or detach
denySettings:
mode: denyDelete # denyDelete, denyWriteAndDelete, none
applyToChildScopes: false # true | false
excludedActions: # List of actions to exclude
- action1
- action2
excludedPrincipals: # List of principals to exclude
- principal1
- principal2
I would have some questions, without understanding the scenario fully, like:
-
Perhaps
bypassStackOutOfSyncError
is a one-time activity (would you really want the same behavior each time?) that would be covered by a--force
gesture to avoid an interactive prompt? -
actionOnUnmanage.managementGroups
. I would some time to look into the docs more, but would this only apply to management group deployments whichazd
doesn't support currently?
From an overall UX standpoint, I think we're taking the stance that "if you're here, you're an advanced user and we're just going to expose all the details of ARM". Another approach is "let's make these advanced features easier to use, or easier to understand -- what are features that a user would care about, with no Bicep or ARM specifics referenced here?" Curious if @ellismg had ideas based on #4307
Add new optional
deploymentStacks
section for the infra provider to pass settings for deployment stacks.Since
azd
supports pluggable infrastructure providers thedeploymentStacks
property within theinfra
section of theazure.yaml
is lazily validated during provision command.Example Usage:
The following is an example showing custom configuration options for deployment stacks.
Default Configuration
The following is the internal defaults for deployment stack options when not overridden within the
azure.yaml
file.bypassStackOutOfSyncError : false
actionOnUnmanage:
delete
for all typesdenySettings:
nil
(No deny settings by default)See official deployment stacks docs for full list of available configuration options.