Jonathanhe/workload network

[jonathanhe-msft]

---

This checklist is used to make sure that common guidelines for a pull request are followed.

General Guidelines

• Have you run azdev style <YOUR_EXT> locally? (pip install azdev required)
• Have you run python scripts/ci/test_index.py -q locally?

For new extensions:

• My extension description/summary conforms to the Extension Summary Guidelines.

About Extension Publish

There is a pipeline to automatically build, upload and publish extension wheels.
Once your PR is merged into master branch, a new PR will be created to update src/index.json automatically.
The precondition is to put your code inside this repo and upgrade the version in the PR but do not modify src/index.json.

[yonzhan]

vmware

[cataggar]

Please change one argument that I commented on, then this can be moved out of draft.

I'm not sure how several of these -id arguments should be handled. I'll have to differ to the CLI team reviewer. The guidelines recommend:

ID Arguments:
Arguments that end in -id should be GUIDs.
Arguments that expect ARM IDs should omit -id but call out that an ARM ID is allowed in the help text. These are often used as part of the "name or ID" convention (i.e: --storage-account can often accept a storage account name OR ARM ID).
https://github.com/Azure/azure-cli/blob/dev/doc/command_guidelines.md#argument-naming-conventions

Since these strings are not GUIDs, should the -id suffix's be removed?

[cataggar]

@zhoxing-ms, can you please review? See my earlier questions about the ids.

[zhoxing-ms]

Please change one argument that I commented on, then this can be moved out of draft.

I'm not sure how several of these -id arguments should be handled. I'll have to differ to the CLI team reviewer. The guidelines recommend:

ID Arguments:
Arguments that end in -id should be GUIDs.
Arguments that expect ARM IDs should omit -id but call out that an ARM ID is allowed in the help text. These are often used as part of the "name or ID" convention (i.e: --storage-account can often accept a storage account name OR ARM ID).
https://github.com/Azure/azure-cli/blob/dev/doc/command_guidelines.md#argument-naming-conventions

Since these strings are not GUIDs, should the -id suffix's be removed?

That's a good point! If they are not GUIDs, please remove the suffix of -id, otherwise users will be confused about the input value

[zhoxing-ms]

@jonathanhe-msft Could you please fix those CI issues?

[jonathanhe-msft]

@jonathanhe-msft Could you please fix those CI issues?

@zhoxing-ms All CI issues have been fixed

[zhoxing-ms]

It looks good overall, but I have one small question: The file recording the release note is usually HISTORY.rst, and this one is CHANGELOG.md. May I ask can CHANGELOG.md be modified to HISTORY.rst?

[cataggar]

but I have one small question: The file recording the release note is usually HISTORY.rst, and this one is CHANGELOG.md. May I ask can CHANGELOG.md be modified to HISTORY.rst?

Please, let's not change that. A CHANGELOG.md is commonly used in Python long descriptions too. It reads better on Github.

azure-cli-extensions/src/vmware/setup.py

Lines 15 to 23 in ae1689b

	with open('CHANGELOG.md', encoding='utf-8') as f:
	changelog = f.read()
	setup(
	name='vmware',
	version=VERSION,
	description='Azure VMware Solution commands.',
	long_description=readme + '\n\n' + changelog,
	long_description_content_type='text/markdown',

[zhoxing-ms]

@jonathanhe-msft @cataggar In fact, we can modify the file name referenced in setup.py, such as code link

with open1('HISTORY.md', 'r', encoding='utf-8') as f:
    HISTORY = f.read()

For readability, we can only change the file name to HISTORY.md, and the file type can still be mark down. In this way, it can be consistent with the release notes of other extensions.
This is my personal suggestion. If you think it can be adopted, please submit a new PR to modify it, thanks