Unset all upper constraints files #72

MoteHue · 2025-10-23T11:48:46Z

No description provided.

gemini-code-assist · 2025-10-23T11:49:03Z

Summary of Changes

Hello @MoteHue, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request removes the hardcoded default OpenStack upper constraints file from various Ansible roles. By unsetting these variables, the roles will no longer implicitly enforce a specific set of Python dependency versions, providing greater flexibility in managing package installations. This change allows for more dynamic dependency resolution or requires explicit constraint definition by the user, adapting to different deployment environments or OpenStack releases.

Highlights

Removed Default Upper Constraints: The default _upper_constraints_file variable has been unset across nine different OpenStack Ansible roles. Previously, these variables pointed to https://releases.openstack.org/constraints/upper/2024.1.
Updated Documentation: The README.md for the os_projects role was updated to remove the example usage of the os_projects_upper_constraints_file variable, reflecting its removal from the defaults.

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature	Command	Description
Code Review	`/gemini review`	Performs a code review for the current pull request in its current state.
Pull Request Summary	`/gemini summary`	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help	`/gemini help`	Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here.

You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.

Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

gemini-code-assist

Code Review

This pull request removes the hardcoded default upper constraints file URL from various Ansible roles, which is a good step towards making the roles more flexible. My review focuses on improving the consistency of how these unset variables are defined. I've suggested explicitly setting them to an empty string ("") to align with existing patterns in the codebase, which enhances clarity and maintainability.

gemini-code-assist · 2025-10-23T11:50:19Z

roles/os_container_clusters/defaults/main.yml

 os_container_clusters_templates: []
 # Upper constraints file for installation of python dependencies.
-os_container_clusters_upper_constraints_file: https://releases.openstack.org/constraints/upper/2024.1
+os_container_clusters_upper_constraints_file:


For consistency with other variables in the collection (e.g., os_images_dib_upper_constraints_file in roles/os_images/defaults/main.yml), it would be better to explicitly set this to an empty string ("") rather than null (which is what an empty value becomes in YAML). This makes the intent clearer and maintains a consistent style across the roles.

os_container_clusters_upper_constraints_file: ""

gemini-code-assist · 2025-10-23T11:50:20Z

roles/os_deploy_templates/defaults/main.yml


 # Upper constraints file for installation of Python dependencies.
-os_deploy_templates_upper_constraints_file: https://releases.openstack.org/constraints/upper/2024.1
+os_deploy_templates_upper_constraints_file:


For consistency with other variables in the collection (e.g., os_images_dib_upper_constraints_file in roles/os_images/defaults/main.yml), it would be better to explicitly set this to an empty string ("") rather than null (which is what an empty value becomes in YAML). This makes the intent clearer and maintains a consistent style across the roles.

os_deploy_templates_upper_constraints_file: ""

gemini-code-assist · 2025-10-23T11:50:20Z

roles/os_images/defaults/main.yml


 # Use Caracal upper constraints
-os_images_upper_constraints_file: https://releases.openstack.org/constraints/upper/2024.1
+os_images_upper_constraints_file:


For consistency with os_images_dib_upper_constraints_file in this same file, it would be better to explicitly set this to an empty string ("") rather than null (which is what an empty value becomes in YAML). This makes the intent clearer and maintains a consistent style.

os_images_upper_constraints_file: ""

gemini-code-assist · 2025-10-23T11:50:20Z

roles/os_networks/defaults/main.yml


 # Upper constraints file for installation of Python dependencies.
-os_networks_upper_constraints_file: https://releases.openstack.org/constraints/upper/2024.1
+os_networks_upper_constraints_file:


For consistency with other variables in the collection (e.g., os_images_dib_upper_constraints_file in roles/os_images/defaults/main.yml), it would be better to explicitly set this to an empty string ("") rather than null (which is what an empty value becomes in YAML). This makes the intent clearer and maintains a consistent style across the roles.

os_networks_upper_constraints_file: ""

gemini-code-assist · 2025-10-23T11:50:20Z

roles/os_openstackclient/defaults/main.yml

 os_openstackclient_version:
 # Upper constraints file for installation of openstackclient.
-os_openstackclient_upper_constraints_file: https://releases.openstack.org/constraints/upper/2024.1
+os_openstackclient_upper_constraints_file:


For consistency with other variables in the collection (e.g., os_images_dib_upper_constraints_file in roles/os_images/defaults/main.yml), it would be better to explicitly set this to an empty string ("") rather than null (which is what an empty value becomes in YAML). This makes the intent clearer and maintains a consistent style across the roles.

os_openstackclient_upper_constraints_file: ""

gemini-code-assist · 2025-10-23T11:50:20Z

roles/os_openstacksdk/defaults/main.yml

 os_openstacksdk_version:
 # Upper constraints file for installation of openstacksdk.
-os_openstacksdk_upper_constraints_file: https://releases.openstack.org/constraints/upper/2024.1
+os_openstacksdk_upper_constraints_file:


For consistency with other variables in the collection (e.g., os_images_dib_upper_constraints_file in roles/os_images/defaults/main.yml), it would be better to explicitly set this to an empty string ("") rather than null (which is what an empty value becomes in YAML). This makes the intent clearer and maintains a consistent style across the roles.

os_openstacksdk_upper_constraints_file: ""

gemini-code-assist · 2025-10-23T11:50:20Z

roles/os_projects/defaults/main.yml

 # 'quotas': Optional dict mapping quota names to their values.
 os_projects: [] # noqa var-naming[no-role-prefix]
-os_projects_upper_constraints_file: https://releases.openstack.org/constraints/upper/2024.1
+os_projects_upper_constraints_file:


For consistency with other variables in the collection (e.g., os_images_dib_upper_constraints_file in roles/os_images/defaults/main.yml), it would be better to explicitly set this to an empty string ("") rather than null (which is what an empty value becomes in YAML). This makes the intent clearer and maintains a consistent style across the roles.

os_projects_upper_constraints_file: ""

gemini-code-assist · 2025-10-23T11:50:20Z

roles/os_ratings/defaults/main.yml

 os_ratings_venv:
 # Upper constraints file for installation of Python dependencies.
-os_ratings_upper_constraints_file: https://releases.openstack.org/constraints/upper/2024.1
+os_ratings_upper_constraints_file:


For consistency with other variables in the collection (e.g., os_images_dib_upper_constraints_file in roles/os_images/defaults/main.yml), it would be better to explicitly set this to an empty string ("") rather than null (which is what an empty value becomes in YAML). This makes the intent clearer and maintains a consistent style across the roles.

os_ratings_upper_constraints_file: ""

gemini-code-assist · 2025-10-23T11:50:21Z

roles/os_volumes/defaults/main.yml


 # A file or URL containing Python upper constraints.
-os_volumes_upper_constraints_file: https://releases.openstack.org/constraints/upper/2024.1
+os_volumes_upper_constraints_file:


For consistency with other variables in the collection (e.g., os_images_dib_upper_constraints_file in roles/os_images/defaults/main.yml), it would be better to explicitly set this to an empty string ("") rather than null (which is what an empty value becomes in YAML). This makes the intent clearer and maintains a consistent style across the roles.

os_volumes_upper_constraints_file: ""

jovial · 2025-10-28T16:05:21Z

My personal feeling is that there should some version locking, ideally with a CI job that bumps that version when there is a new release, otherwise you are going to get unrepeatable behavior - works on one day and broken on next. This is especially true since we refresh the venv on every run. I imagine using upper constraints was an attempt at doing version locking. It might better just to the constraints from the latest stable release?

MoteHue · 2025-11-13T13:59:23Z

My personal feeling is that there should some version locking, ideally with a CI job that bumps that version when there is a new release, otherwise you are going to get unrepeatable behavior - works on one day and broken on next. This is especially true since we refresh the venv on every run. I imagine using upper constraints was an attempt at doing version locking. It might better just to the constraints from the latest stable release?

We have a PR for 2025.1: #71
Or do you mean upstream latest, 2025.2 and soon to be 2026.1

g0rgamesh · 2025-11-19T10:43:04Z

Generally I would be in favor as it breaks every once in a while when the upper constraints branch goes into unmaintained, but I am concerned that just pulling from whatever is the latest and greatest upstream would yield more breakages.

Unset all upper constraints files

49fc661

MoteHue requested a review from a team as a code owner October 23, 2025 11:48

gemini-code-assist bot reviewed Oct 23, 2025

View reviewed changes

Unset all upper constraints files #72

Are you sure you want to change the base?

Unset all upper constraints files #72

Uh oh!

Conversation

MoteHue commented Oct 23, 2025

Uh oh!

gemini-code-assist bot commented Oct 23, 2025

Summary of Changes

Highlights

Footnotes

Uh oh!

gemini-code-assist bot left a comment

Choose a reason for hiding this comment

Code Review

Uh oh!

gemini-code-assist bot Oct 23, 2025

Choose a reason for hiding this comment

Uh oh!

gemini-code-assist bot Oct 23, 2025

Choose a reason for hiding this comment

Uh oh!

gemini-code-assist bot Oct 23, 2025

Choose a reason for hiding this comment

Uh oh!

gemini-code-assist bot Oct 23, 2025

Choose a reason for hiding this comment

Uh oh!

gemini-code-assist bot Oct 23, 2025

Choose a reason for hiding this comment

Uh oh!

gemini-code-assist bot Oct 23, 2025

Choose a reason for hiding this comment

Uh oh!

gemini-code-assist bot Oct 23, 2025

Choose a reason for hiding this comment

Uh oh!

gemini-code-assist bot Oct 23, 2025

Choose a reason for hiding this comment

Uh oh!

gemini-code-assist bot Oct 23, 2025

Choose a reason for hiding this comment

Uh oh!

jovial commented Oct 28, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

MoteHue commented Nov 13, 2025

Uh oh!

g0rgamesh commented Nov 19, 2025

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

jovial commented Oct 28, 2025 •

edited

Loading