Skip to content

Conversation

atrull
Copy link

@atrull atrull commented Aug 1, 2025

This may close issue #302

@atrull atrull requested review from anamer, ayushmjain, prabhu34, q2w and a team as code owners August 1, 2025 08:09
Copy link

google-cla bot commented Aug 1, 2025

Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

View this failed invocation of the CLA check for more information.

For the most up to date status, view the checks section at the bottom of the pull request.

@atrull atrull changed the title Permit optional ports for sidecars so we can run sidecars fix[sidecars]: Permit optional ports for sidecars so we can run sidecars Aug 11, 2025
Copy link
Member

@bharathkkb bharathkkb left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the PR @atrull

Could an alternative be to explicitly specify ports = {} for the other containers?

Comment on lines -58 to 60
ports = optional(object({
name = optional(string, "http1")
container_port = optional(number, 8080)
name = optional(string)
container_port = optional(number)
}), {})
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@q2w PTAL due to default change

Copy link

@krissrex krissrex Aug 25, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could an alternative be to explicitly specify ports = {} for the other containers?

I believe ports = {} then just defaults back to "http1" and 8080, if the default values are kept in variables.tf.

I do not believe optional with a fallback value can be used in any solution of this issue. Any default/fallback values must be set by you re-implementing a fallback inside the main.tf, because this optional does not give you a mechanism to know if the user supplied any value or not; meaning it will always be http1 or a user-specified non-empty value, never empty.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants