[ONNX] Update the default opset to version 14

[justinchuby]

Stack from ghstack (oldest at bottom):

• -> [ONNX] Update the default opset to version 14 #83284
• [ONNX] Update the script for version updates #83283

Update the default opset by running the update_default_opset_version.py script. The update is done in a regularly to ensure we are in sync with the onnx updates. All changes are produced by the script.

[facebook-github-bot]

🔗 Helpful links

• 🧪  See artifacts and rendered test results at hud.pytorch.org/pr/83284
• 📄  Preview Python docs built from this PR
• 📄  Preview C++ docs built from this PR
• ❓Need help or want to give feedback on the CI? Visit our office hours

❌ 1 New Failures

As of commit 221b1db (more details on the Dr. CI page):

Expand to see more

---

• 1/1 failures introduced in this PR

---

🕵️ 1 new failure recognized by patterns

The following CI failures do not appear to be due to upstream breakages

pull / linux-bionic-py3_7-clang8-xla / test (xla, 1, 1, linux.2xlarge) (1/1)

Step: "Test" (full log | diagnosis details)

2022-08-16T16:59:26.6678052Z ##[error]Process completed with exit code 1.

2022-08-16T16:59:26.6638716Z Non-cacheable calls                   0
2022-08-16T16:59:26.6639064Z Non-compilation calls                 0
2022-08-16T16:59:26.6639265Z Unsupported compiler calls            0
2022-08-16T16:59:26.6639482Z Average cache write               0.000 s
2022-08-16T16:59:26.6639884Z Average cache read miss           0.000 s
2022-08-16T16:59:26.6640176Z Average cache read hit            0.000 s
2022-08-16T16:59:26.6640397Z Failed distributed compilations       0
2022-08-16T16:59:26.6640951Z Cache location                  S3, bucket: Bucket(name=ossci-compiler-cache-circleci-v2, base_url=http://ossci-compiler-cache-circleci-v2.s3.amazonaws.com/)
2022-08-16T16:59:26.6641348Z + echo ::endgroup::
2022-08-16T16:59:26.6641819Z ##[endgroup]
2022-08-16T16:59:26.6678052Z ##[error]Process completed with exit code 1.
2022-08-16T16:59:26.6734172Z Prepare all required actions
2022-08-16T16:59:26.6734470Z Getting action download info
2022-08-16T16:59:26.8545818Z ##[group]Run ./.github/actions/get-workflow-job-id
2022-08-16T16:59:26.8546038Z with:
2022-08-16T16:59:26.8546346Z   github-token: ***
2022-08-16T16:59:26.8546520Z env:
2022-08-16T16:59:26.8546692Z   GIT_DEFAULT_BRANCH: master
2022-08-16T16:59:26.8546863Z ##[endgroup]
2022-08-16T16:59:26.8572956Z ##[group]Run nick-fields/retry@71062288b76e2b6214ebde0e673ce0de1755740a
2022-08-16T16:59:26.8573173Z with:

---

This comment was automatically generated by Dr. CI (expand for details).

Please report bugs/suggestions to the (internal) Dr. CI Users group.

Click here to manually regenerate this comment.

[thiagocrepaldi]

Hi @justinchuby, please provide a clear and concise description of why we are changing the default opset. Documenting the reason helps us in the future, when we are debugging problems that are specific to opset version that affects a particular runtime

What is the motivation for the proposal? Changing the default opset can break Caffe2 and any other runtime that consumes. IIRC, it might be because we are trying to stay 3 version behind the latest, is that it?

[justinchuby]

Hi @justinchuby, please provide a clear and concise description of why we are changing the default opset. Documenting the reason helps us in the future, when we are debugging problems that are specific to opset version that affects a particular runtime

What is the motivation for the proposal? Changing the default opset can break Caffe2 and any other runtime that consumes. IIRC, it might be because we are trying to stay 3 version behind the latest, is that it?

Done. PTAL.

The change is done by running the script. As I understand it - yes it is because we want to use the oldest version in the last 18 months (mentioned in the script).

If versions are usually explicitly specified during conversion, I am hoping nothing will break with this change? Do we need an import to verify?

[thiagocrepaldi]

Hi @justinchuby, please provide a clear and concise description of why we are changing the default opset. Documenting the reason helps us in the future, when we are debugging problems that are specific to opset version that affects a particular runtime
What is the motivation for the proposal? Changing the default opset can break Caffe2 and any other runtime that consumes. IIRC, it might be because we are trying to stay 3 version behind the latest, is that it?

Done. PTAL.

The change is done by running the script. As I understand it - yes it is because we want to use the oldest version in the last 18 months (mentioned in the script).

If versions are usually explicitly specified during conversion, I am hoping nothing will break with this change? Do we need an import to verify?

Assuming people use explicit version on the torch.onnx.export call, nothing should break, but the API also allows not setting it, so a break is possible. Although the ONNX converter team know about the policy for updating the opset, the general public probably dont, so expliciting the reason on the PR is always a good idea. Especially for those that do not explicitly specify opset version and spend days debugging a model change they have no idea where it came from :P

[thiagocrepaldi]

The change LGTM.

One aspect that we never discussed when changing opset versions before, but I thought about it now is: Should we add module: BC-breaking or topic: BC breaking Github labels on the PR that changes opset version?

For scripts that use implicit opset version, the opset change can cause BC issues and the PyTorch release notes should explicit that

@BowenBao @shubhambhokare1 any thoughts?

[BowenBao]

The change LGTM.

One aspect that we never discussed when changing opset versions before, but I thought about it now is: Should we add module: BC-breaking or topic: BC breaking Github labels on the PR that changes opset version?

For scripts that use implicit opset version, the opset change can cause BC issues and the PyTorch release notes should explicit that

@BowenBao @shubhambhokare1 any thoughts?

I agree with the BC breaking concern and I think it's the cost we have to pay for moving forward. Good idea to add the BC-breaking tags. Linking the original PR from Gary for reference #73898.

@justinchuby I'm not sure about this line Update the default opset ... to prepare for opset 17 support. Why are these related? If there is no dependency I'd actually recommend separating this PR, as it might get reverted for failing Meta internal tests.

[justinchuby]

I agree with the BC breaking concern and I think it's the cost we have to pay for moving forward. Good idea to add the BC-breaking tags. Linking the original PR from Gary for reference #73898.

@justinchuby I'm not sure about this line Update the default opset ... to prepare for opset 17 support. Why are these related? If there is no dependency I'd actually recommend separating this PR, as it might get reverted for failing Meta internal tests.

Thanks for pointing this out. For some reason I just assumed it is the process when there is a new opset coming out. I have detached #83287

[titaiwangms]

🍺

[malfet]

LGTM, not sure why it has onnx-needs-import label

[justinchuby]

@pytorchbot merge -g

[pytorchmergebot]

@pytorchbot successfully started a merge job. Check the current status here.
The merge job was triggered with the green (-g) flag. This means that your change will be merged once all checks on your PR have passed (ETA: 0-4 Hours). If this is not the intended behavior, feel free to use some of the other merge options in the wiki.
Please reach out to the PyTorch DevX Team with feedback or questions!

[pytorchmergebot]

Merge failed
Reason: Refusing to merge as mandatory check(s) pull failed for rule superuser
Raised by https://github.com/pytorch/pytorch/actions/runs/2884173564

[justinchuby]

@pytorchbot merge -f "unrelated xla build error"

[pytorchmergebot]

@pytorchbot successfully started a merge job. Check the current status here.
The merge job was triggered with the force (-f) flag. This means your change will be merged immediately, bypassing any CI checks (ETA: 1-5 minutes). If this is not the intended behavior, feel free to use some of the other merge options in the wiki.
Please reach out to the PyTorch DevX Team with feedback or questions!