- 
                Notifications
    
You must be signed in to change notification settings  - Fork 444
 
Labels
Description
Description
Idea: Automatically generate new CARML modules from the Azure REST API.
To elaborate a bit further:
- The end result will likely be a utility - like a PowerShell script
 - An approach could be to crawl data from
 - Using these sources, it should be possible to determine the parameters for PUT/POST commands and as such use the data to generate the CARML module structure.
 - This structure should contain
- The module folder structure & files
 - Input parameters with metadata
 - The resource implementation itself
 - Child resources (referenced in the parent)
 - Extension resources (like RBAC, Private Endpoints, Diagnostics, Locks,...)
 
 - We should further try to adhear certain design descision we follow such as
- If a resource property is only an object with a single value, the corresponding input parameter should be a simplified combination of the two. For example the property 
something: somethingwhere something is an object with only anidproperty should be simplified tosomething: { id: somethingId }. - In general, we should follow the guidlines specified in the Module Design section of the Wiki
 
 - If a resource property is only an object with a single value, the corresponding input parameter should be a simplified combination of the two. For example the property 
 
Note: The end result will likely not get us 100% of the way as modules usually always have some specifics to them. However, if it gets us already 70% of the way, it would be a big win.
Stretch goal: Have the utility give you a 'diff' - i.e., would there be anything to update for a new API version
Stretch goal: In an ideal world we may even be able to run the function idempotently to add new properties to an existing template (e.g. if a new API version was released).
Implementation takes place in branch users/hack-REST2CARML.
Metadata
Metadata
Assignees
Labels
Type
Projects
Status
Done