chore(deps): pin snowflake to v0.0.3 (#15352)

[rogerpueyo]

The snowflake package used to create a UUID, e.g., for an AGW's /etc/snowflake file has been renamed to snowflake-uuid, and the former snowflake package has been taken over by a completely different piece of software. Pinning the package version to v0.0.3 ensures that we fetch the latest available release of the former snowflake package, before the name change.

Fixes #15352 for Magma v1.8.

Summary

The snowflake package dependency was pinned to v0.0.3 in both bazel/external/requirements.in and orc8r/gateway/python/setup.py. This ensures that the latest release of the former snowflake package is fetched and the /etc/snowflake file is generated correctly.

Test Plan

Tested on a v1.8 AGW in a Vagrant VM. The magmad service no longer complains about the snowflake package as detailed in #15352, and it correctly starts the rest of services. Also, the show_gateway_info.py reports a valid hardware ID (instead of miserably failing).

Additional Information

• This change is backwards-breaking

Security Considerations

For master and upcoming ≥v1.9 Magma releases, the new package name snowflake-uuid shall be used.

[github-actions]

Thanks for opening a PR! 💯

A couple initial guidelines

• All commits must be signed off. This is enforced by DCO check.
• All PR titles must follow the semantic commits format. This is enforced by Semantic PR.

Howto

• Reviews. The "Reviewers" listed for this PR are the Magma maintainers who will shepherd it.
• Checks. All required CI checks must pass before merge.
• Merge. Once approved and passing CI checks, use the ready2merge label to indicate the maintainers can merge your PR.

More info

Please take a moment to read through the Magma project's

• Contributing Conventions for norms around contributed code

If this is your first Magma PR, also consider reading

• Developer Onboarding for onboarding as a new Magma developer
• Development Workflow for guidance on your first pull request
• CI Checks for points of contact for failing or flaky CI checks
• GitHub-to-Slack mappings for Magma maintainers for guidance on how to contact maintainers on Slack

[rogerpueyo]

Hi, @ardzoht ,

Sorry for bothering you. I wonder if you could have a look at this PR. The snowflake dependency is currently a showstopper to deploy Magma's latest stable version, v1.8.

Some CI test failed, but I believe they are unrelated to the PR.

Thanks!

[maxhbr]

For the reviewer:

For backporting we have https://github.com/magma/magma/blob/master/.github/workflows/backport-pull-request.yml, that works based on labels. Not sure if that is still functional.

[rogerpueyo]

Thanks, @maxhbr . Indeed, this commit is not a backport, just a quick fix for v1.8. When I have some time, I plan to send a PR with the proper fix to main, which consists on renaming the snowflake dependency to its current name snowflake-uuid.

[lucasgonze]

@rogerpueyo Thanks for this. I will review today.

[lucasgonze]

Researched the odd history of the package. Verified that 0.0.3 is a reasonable stopping point.

[lucasgonze]

Two problems remaining:

1. A review from @ardzoht was requested, and he is no longer a contributor.
2. A number of tests are failing.

[lucasgonze]

https://magmacore.slack.com/archives/C0191LLL03S/p1707864815948919

1. Do we patch 1.8? If so do we test?
2. My PR approval is from a security perspective. I would also back it in terms of software engineering but testing is out of scope for me.
3. The submitter requested an approval from somebody who is no longer a contributor. We need to remove that approver and either have somebody else step in or just go cowboy without a second review.
4. Unit tests are failing because of CI problems. But that doesn’t mean they would pass without the CI problems. Again, do we want to cowboy this?

[lucasgonze]

@panyogesh Is it possible to include this in the current round of merges?