-
Notifications
You must be signed in to change notification settings - Fork 759
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
[Story] Bicep Parameters File #7301
Comments
This was mentioned on the comments in the community call, but just adding my two cents here. The file name extension for the params file, in my opinion, should remain as .bicep. Logic should be introduced to a .bicep file to reverse the param file logic of "using", for example "usedby" or similar. Thus tying the two files together. I know there was mention of introducing inherited or root structure param files, I presume the approach here would be parent and child, again the same logic of tying files together could be used. My main point I guess is, I don't see the value in introducing a new file name extension as well as having to specify the file within the code itself. |
A parameter file is a great idea. Thank you for working on it. I am just throwing out my two thoughts about it.
Example
|
@wedoazure The direction of linking the files (pointing the parameters at the Bicep template) was something we discussed thoroughly, and we came to this decision because through our interviews, we recognized that it was more common to have multiple parameter files used for one Bicep file. In the future, with inherited parameter files, we hope to make parameters more reusable. |
|
@sydkar But I am curious about the use cases to pass variable values from the parameters file. If you pass values to both parameters and variables from the same file(or from outside of the template), what is the difference between parameters and variables? |
@musaugurlu |
I agree with @musaugurlu regarding the exclusion of As a user of both Bicep and Terraform (and seeing the similarities between the two), it would make sense to keep the param file as simple as possible, similar to the Terraform As such, whilst I understand the thinking behind supporting vars and functions within the param file, I think this type of logic (beyond loading values from other file sources) should occur in the deployment template instead. However, I can see the benefit of linking a param file to the associated bicep template with the Thinking about file naming, rather than using a specific file name, it might work well to use Thinking about other use cases for the Thinking about this in the context of a GitOps process, this would allow CODEOWNERS to be used to control who can make changes to parameters for each environment, and for the "safe defaults". If you can provide a way to flag a variable in the "safe defaults" as mandatory, you could then alter the merge behaviour to stop an environment owner overriding a safe default. The only difficulty I can see with this is how to enforce the correct order of dependencies. For the proposed feature "I can use a VS Code action to generate a Bicep parameter file based off a Bicep template" it would be useful to automatically add all parameters with default values where present. If no default is specified, the type should be specified so the developer knows what is expected. Great to see this on the backlog though, and thank you for continuing to make these great additions to bicep! |
@krowlandson We have also looked into the extension and came to the conclusion that having a separate extension would be better as it would create a clear distinction for the language server to provide syntax validation. We are planning to eventually be able to automatically load the bicep template when the parameter file is deployed, as you described. Your suggestion on chaining multiple parameter files together is something we are looking into and hoping to implement sometime in the future. We understand the want to be able to link multiple params files for a deployment and think it is an important capability to have. Finally, to your point on the generated parameter file, I like your suggestions, and they align with the current behavior of ARM parameter generation, so we will be sure to keep these in mind! |
Super excited to see this being worked on. Currently, parameters make my bicep files look TERRIBLE, taking up dozens up dozens of lines at the top of my files. Great start here! Do I understand this correct that I will be able to convert my bicep file to having a seperate file for my parameters? See here for the before https://github.com/Azure/azure-quickstart-templates/blob/master/application-workloads/azure-gamedev/gamedev-vm/main.bicep After main.bicepusing main.parameters.bicep
module gamedevvm './nestedtemplates/gamedev-vm.bicep' = {
name: 'gamingDevVM'
params: {
location: location
vmSize: vmSize
adminName: administratorLogin
adminPass: passwordAdministratorLogin
osType: osType
gameEngine: gameEngine
remoteAccessTechnology: remoteAccessTechnology
_artifactsLocation: _artifactsLocation
_artifactsLocationSasToken: _artifactsLocationSasToken
}
} main.parameters.bicep@description('Deployment Location')
param location string = resourceGroup().location
@description('The base URI where artifacts required by this template are located including a trailing \'/\'')
param _artifactsLocation string = deployment().properties.templateLink.uri
@description('The sasToken required to access _artifactsLocation.')
@secure()
param _artifactsLocationSasToken string = ''
@description('Select Game Engine Version')
@allowed([
'ue_4_27_2'
'ue_5_0_1'
])
param gameEngine string = 'ue_4_27_2'
@description('Select Operating System')
@allowed([
'win10'
'ws2019'
])
param osType string = 'win10'
@description('Select Virtual Machine Skew')
@allowed([
'Standard_NC4as_T4_v3'
'Standard_NC8as_T4_v3'
'Standard_NC16as_T4_v3'
'Standard_NC64as_T4_v3'
'Standard_NV6'
'Standard_NV12'
'Standard_NV24'
'Standard_NV12s_v3'
'Standard_NV24s_v3'
'Standard_NV48s_v3'
])
param vmSize string = 'Standard_NV12s_v3'
@description('Administrator Login for access')
param administratorLogin string
@description('Administrator Password for access')
@secure()
param passwordAdministratorLogin string
@description('Remote Access technology')
@allowed([
'RDP'
'Teradici'
'Parsec'
])
param remoteAccessTechnology string = 'RDP' |
But... even given the new option for a parameters file, I still find the syntex for parameters to be extremely bloated, because of all the annotations that are allowed. Even if each annotation collapses to a single line, the rate of lines per parameters is still always greater then 1:1. (meaning if I add one parameter, it adds at least 3 lines to my file if I include description and new line) The bicep formatter already collapses code after the "=". I would be nice to leverage this syntex for parameters too. Particularly with some hopes in the future where parameter types can be more advanced. ExtendedCollapsed(the collapse would be even more perfect, if instead of '...' we showed the preview of the text on the single line, as well as collapse that extra '}' in with the rest, but was going to make that its own request) |
I also do not think it is likely that this issue will be solved as first requested, but improving how parameters are defined could resolve it. #4184 |
[Idea] Don't generate parameter in parameter files if default value is function like, param par_instance_number string = substring((uniqueString(subscription().id)),0,2)
param par_base_name string = substring((subscription().subscriptionId),0,4)
|
Or create them commented out to simplify use if someone wants to override? |
I'm not sure whether this was the true intent of the parameters file option in Bicep, but it raises an interesting point around another value add we could get from Bicep. Terraform (sorry, not sorry) uses the concept of a "root module" whereby all files within the root module directory are evaluated as a whole when determining what to deploy. This allows developers to break apart code into multiple files. A common pattern is to have a file per resource type, or a file for specific groups of variables, etc. This makes the code easier to maintain for large deployments. Taking the idea from @dciborow, it would be awesome if Bicep would allow the compilation of a deployment from multiple files. This could enable re-use of code without having to formally make it a "module". Why might you want to do this? Each Bicep module translates to an ARM "deployment". Each ARM deployment can take a while to start, resulting in unnecessary provisioning delays (especially when no changes are needed). But more importantly, delays in replication across the platform (eventual consistency) can also make it problematic when deploying dependent resources across multiple deployments. This can result in failed deployments despite using a "valid" template, resulting in a poor user experience. Similar to my idea above of allowing "parameter chaining", making use of the Modules can then be used for more specific scenarios like when a change of deployment scope is needed, or for parallel deployment of batches of the same group of resources, etc. |
@krowlandson -- I think the scenario you are describing is covered in #363. Can you confirm? |
@mimachniak -- we cannot allow non-deterministic functions in the parameters file because we need to be able to generate a JSON parameters file with only hardcoded, static values. Also, FWIW, can't parameters like this be a variable in the template itself? Do you want the parameter to always be that value or would that depend on who is deploying the bicep file? |
Certainly seems so @alex-frankel... I think the only difference would be that #363 implies that Bicep evaluates "all files in the specified directory" (which is aligned to the Terraform approach) whilst I was suggesting that Both seem valid scenarios. |
First Release - PlansHere are the features we're proposing for the first official release (combination of the "Summer" & "MVP" section - with some MVP pieces cut out). Most of the "Summer" work has already been completed, which is why it's not included here. Basic Language FeaturesCode Completion and Navigation
Code Completion and Navigation (Verify these are already done)
Environment Variables
Bicep Parameter File Generation
Compatibility with Current Tooling
Other
|
Is bicepparams available for testing with a feature flag in bicepconfig.json? |
@stephaniezyen / @Usman0111 -- do we have an easy way to test this out yet? I know at one point it required building the extension from source, but not sure if that is still the case. |
@akata72 we will enable the vs code extension to provide intellisense for |
< edit > I found this on the TODO list ✅ </ edit > Any plan for: convert json param file to bicepparam file? A decompile for json param. |
Thank you for all the effort. You are doing a really great job making Bicep truly awesome! Creating parameter files in bicep format is certainly an interesting feature which will make the whole bicep approach more consistent. And speaking of consistency, as commented in the past community call:
I would appreciate if someone could elaborate what the rationale is behind the choice for an additional file extension.
Thank you again and keep the good work! |
Value replacement is really hard with valid json. Example: {
"$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentParameters.json#",
"contentVersion": "1.0.0.0",
"parameters": {
"intValueParam": {
"value": ${env:something}
},
"otherIntValueParam": {
"value": ${referenceToSomeOtherParameterPassedByCLI}
}
}
} I think this is the most obvious example. Some of the replacement can be done with current tolling using ReplaceTokens task but writing JSON-based parameter file is PITA because authoring tooling complains when supplied values does not match with paramter types and the JSON is not valid. |
@JorgeDios -- to put it simply, the rules are different for what is valid For those that would prefer everything be a |
I would like to see a tooling to extract parameter values from bicepparams at some point. Use case:
|
@alex-frankel -- Thank you for the clear and concise clarification. I totally understand now why it has been chosen to use a new file extension. To me, it was a matter of uniformity. The whole purpose of a file extension is to indicate the file format so the parser / system knows how to process it. I was therefore assuming that the bicep format would be enriched to identify what was being declared as parameter input. However, if I understand you correctly, a different approach is implemented: a A matter of taste / style, I guess. Or may be a way to reduce complexity of the overall bicep implementation... |
Does it make sense to include the ability to include the {
"$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentParameters.json#",
"contentVersion": "1.0.0.0",
"parameters": {
"Prefix": {
"value": "AEU1",
"metadata": {
"description": "region prefix e.g. acu1 or aeu1"
}
}
}
} @description('region prefix e.g. acu1 or aeu1')
param prefix = 'AEU1' |
I like what I am reading here, but admittedly still consider myself a neophyte with Bicep. We do use objects as parameters, will this be covered with .bicepparam? |
I had indeed the same question. We provide our ops teams with several parameter input files which are used in combination with parent modules calling child modules for resource deployment. It would be very helpful to have the possibility to add descriptions to the parameter files because it will save the ops teams a lot of time. They don't need to go to check either the readme.md of the parent module or the parameter description in the parent module. The parameter files now are quite hard to read because they consist of quite large sets of parameters. It's not always clear from the parameter name alone what the parameter is about. The ppl filling out the parameter files are usually also not into the details of the workings of the parent modules etc. |
Not sure if this has already been considered but what would be really great is to reference secrets via key vault (similar to Azure Container Apps secrets references pointing to a secret URI in a key vault) and they get pulled out automatically during deployment. Arguably that would require ARM support but that would be the ultimate feature to avoid sprinkling secrets all over the place during deployments and having to take care to not accidentally leak them via logging, temp file artifacts or command line parameter snooping via |
Key vault references is already supported by ARM/ JSON paramter files: https://learn.microsoft.com/en-us/azure/azure-resource-manager/templates/template-tutorial-use-key-vault and by Bicep: https://learn.microsoft.com/en-us/azure/azure-resource-manager/bicep/bicep-functions-resource#getsecret There is a ticket (and PR) to provide |
Hello, I am facing the following issue: I defined multiple parameters in the Bicep file, and one of the parameters has a validation (can be valueA or valueB). I want to pass a value for this parameter inline (calculate logic with powershell and decide what the value will be during runtime), while I have a parameter file as well (static values). |
First Release: #9567
Bicep Parameter Files
Bicep Parameters has been one of our most requested features. During the summer, the Bicep team will be building a prototype of what this experience looks like, with the intention to ship the MVP described below if we get a positive reaction.
Goals
Non-Goals
Requirements
Summer
Basic Language Features
Syntax
param paramName = value
to set a parameter value from the Bicep templateusing 'path/filename.bicep'
to select which Bicep template file to point at in order to find available parameters//
or/**/
Compilation/CLI
Code Completion and Navigation
param
Example
MVP
Basic Language Features
Code Completion and Navigation
String Replacement and Expressions
${varName}
to do string replacement in parameter files${varName}
uniqueString()
andcontains()
to dynamically set a parameterresourceGroup().id
Environment Variables
Load Functions
loadFileAsBase64()
,loadTextContent()
, andloadJsonContent()
to bring in values from other filesBicep Parameter File Generation
.bicep
to Bicep parametersCompatibility with Current Tooling
Future Tasks
These features may require further investigation and we intend to spend more time to provide a detailed spec that reflects their functionality to the fullest extent. We would love to hear further feedback on these items!
Modular Parameters
import
directiveSetting Deployment Properties in Param Files
getSecret()
getSecret()
function in the parameter file to access Key Vault secretsOpen Questions
Appendix
support parameters files natively in bicep (399)
The text was updated successfully, but these errors were encountered: