Skip to content
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

[Feature Request]: Align parameter files naming and scenarios #1564

Closed
eriqua opened this issue Jun 21, 2022 · 5 comments
Closed

[Feature Request]: Align parameter files naming and scenarios #1564

eriqua opened this issue Jun 21, 2022 · 5 comments
Labels
[cat] modules category: modules documentation Improvements or additions to documentation enhancement New feature or request

Comments

@eriqua
Copy link
Contributor

eriqua commented Jun 21, 2022

Description

Align on the different use cases we want to cover in our module tests and reflect that in the parameter naming convention. For instance:

  • modules covering multiple services should cover all test scenarios
    • e.g. cognitive services cover both speech and face services. parameter files should cover both use cases, hence include speech.parameters.json and face.parameters.json
  • always include a min.parameters.json to cover only required parameters. For modules covering multiple services this could be duplicated if different services lead to different implementations.
    • e.g. cognitive services cover both speech and face services. parameter files should cover both use cases, hence include speech.min.parameters.json and face.min.parameters.json
  • all modules providing cmk functionality should include a encr.parameters.json (or cmk.parameters.json). For modules covering multiple services this could be duplicated if different services lead to different implementations.

    Discussion needed: we could go for either a "always use encr.parameters.json" for consistency and to clearly show shorter specific examples in the readme or "use it only if required due to incompatibility with other settings" to instead try to include all possible features in the main parameters.json. The latter approach would probably be preferable considering the new dependencies approach. In either case update the Wiki as needed.

  • all modules providing networking functionalities ahould include a net.parameters.json (or similar). For modules covering multiple services this could be duplicated if different services lead to different implementations.

    Discussion needed: same as above.


Update: this is now related to main.test.bicep wrapper modules

@eriqua
Copy link
Contributor Author

eriqua commented Jul 11, 2022

Related to #401 which would be the implementation out of this discussion. I'd also propose to rename current max.parameters.json (analysys services and API management) to parameters.json to have consistency throughout the repo for the main test file. This main test file is a good candidate to be used for the public Bicep registry contribution, so it makes sense to have a consistent naming for that one.

@rahalan
Copy link
Contributor

rahalan commented Oct 20, 2022

Wiki also needs to be updated

@eriqua eriqua added this to the Azure Verified Modules (AVM) - V2 milestone Jul 31, 2023
@AlexanderSehr AlexanderSehr removed this from the Azure Verified Modules (AVM) - V2 milestone May 19, 2024
@AlexanderSehr
Copy link
Contributor

I wonder if this is still relevant given the AVM specs. Thoughts @eriqua?

@eriqua
Copy link
Contributor Author

eriqua commented Jun 2, 2024

@AlexanderSehr I think this is more related to the implementation than it is on the specs definition. I wish that was already the case in AVM. Starting from "the defaults test should only include required parametes" 😄
Modules are still not covering the above 100%, but specs are covering almost all already. However the gap is more on making sure that related AVM specs are fullfilled than about improving the specs coverage.

@AlexanderSehr
Copy link
Contributor

Closing as created as new issues in AVM

@AlexanderSehr AlexanderSehr closed this as not planned Won't fix, can't repro, duplicate, stale Jun 20, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
[cat] modules category: modules documentation Improvements or additions to documentation enhancement New feature or request
Projects
Status: Done
Development

No branches or pull requests

3 participants