You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Shifting this to a new topic, since I originally put the below idea/comments in a different issue which was related to parallel execution only because I was tagged in that specific issue.
The original concern was related to how we would do cross resource references for things like dependson.
I had seen some examples where multiple levels of nesting (of languages) e.g. functions are embedded in yaml or json and this was concerning for me, since it's not inviting for me to write/author and maintain. I can understand that if the intent was for this to be an intermediate language, then that would perhaps be required, however I wanted to get an idea on this up front.
Can we please plan now to have an authoring experience based on Bicep Language? People can still use yaml or json, however I feel like the advantages of Bicep is extremely compelling.
More on why I think this is important.
Bicep utilizes "symbolic-name" for cross referencing resources
Bicep has a rich set of functions, manymost of which are implemented within Bicep itself and doesn't rely on the ARM engine
Bicep is designed to build to json
Bicep has custom types and an extensibility model
simple/clean Bicep language for Configurations
avoids embedding other languages in json/yaml Etc.
simple/clean Bicepparam files for ConfigurationData
Some examples
Radius have taken to extend Bicep in a way that would exactly meet the need that I am interested in this core tool of DSC to be extended.
Extension types included as part of this example/concept:
github
kubernetes
utils
example 2 above is the main reason for writing this thread/idea/feature request and I really hope this could get some traction
tagging @anthony-c-martin in case you can get the opportunity to chat with @SteveL-MSFT or @mgreenegit if you haven't had the chance to share each sides of your visions on Configuration Management.
I hope that it's possible for this to be more of a case of not if but when.
I know resources are limited, so perhaps this just becomes a community project up front?
Bicep has always been in our roadmap, but with limited resources won't on that won't happen til later unfortunately. One of the primary reasons we adopted ARM template syntax for the configuration doc is to eventually get to Bicep.
Summary of the new feature / enhancement
Shifting this to a new topic, since I originally put the below idea/comments in a different issue which was related to parallel execution only because I was tagged in that specific issue.
I had seen some examples where multiple levels of nesting (of languages) e.g. functions are embedded in yaml or json and this was concerning for me, since it's not inviting for me to write/author and maintain. I can understand that if the intent was for this to be an intermediate language, then that would perhaps be required, however I wanted to get an idea on this up front.
Can we please plan now to have an authoring experience based on Bicep Language? People can still use yaml or json, however I feel like the advantages of Bicep is extremely compelling.
More on why I think this is important.
manymost of which are implemented within Bicep itself and doesn't rely on the ARM engineBicep
language for ConfigurationsBicepparam
files for ConfigurationDataSome examples
example 2 above is the main reason for writing this thread/idea/feature request and I really hope this could get some traction
Proposed technical implementation details (optional)
for simplicity I will link to the above utils sample in the:
The text was updated successfully, but these errors were encountered: