Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We鈥檒l occasionally send you account related emails.

Already on GitHub? Sign in to your account

Prevent users from deploying fly tomls with duplicate service definitions #3522

Open
wants to merge 2 commits into
base: master
Choose a base branch
from

Conversation

gwuah
Copy link
Contributor

@gwuah gwuah commented May 3, 2024

Change Summary

Users sometimes end up defining multiple services for the same protocol & port.
This harmless mistake would cause health-checks to fail because of only one of these services get picked by flaps.
To fix this, I'm introducing some client-side validation to flag these issues.

They would now see this warning/help text 馃憞

Service [tcp-1738] has 2 duplicate definitions. To resolve this, merge them into 1 service.

References
https://community.fly.io/t/health-checks-failing-with-failed-to-get-vm/18077
https://community.fly.io/t/unable-to-perform-health-checks/19604
https://community.fly.io/t/health-checks-always-failing/19641/2

@gwuah gwuah marked this pull request as ready for review May 3, 2024 23:03
@lubien
Copy link
Member

lubien commented May 3, 2024

@gwuah do you know if this validation also checks if a http_service and a regular service use the same port? I feel like this could be a common source of misconception.

@gwuah
Copy link
Contributor Author

gwuah commented May 3, 2024

@lubien yes it does. The thing is, http services are actually tcp services.
They are converted to tcp services in flyctl before we send them to flaps.

Copy link
Member

@lubien lubien left a comment

Choose a reason for hiding this comment

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

LGTM!

Copy link
Member

@dangra dangra left a comment

Choose a reason for hiding this comment

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

+1 to adding more service validations

A few Q:

  1. What happens when the similar services are for different process groups?
  2. Should it validate for external port duplication too?

@gwuah
Copy link
Contributor Author

gwuah commented May 7, 2024

@dangra I think the process group remark is valuable, so I've added support for that. f0539a1
Duplicate external ports however, I think we can ignore them for now and merge this.

processes = ["web"]

[[services.ports]]
port = 80
Copy link
Member

Choose a reason for hiding this comment

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

this is the kind of invalid config example for duplicated external ports I was referring to.

In this case, the app service and the web service both will listen on port 80. To which group should fly-proxy send the request?

[[services]]
internal_port = 1738
protocol = "tcp"
processes = ["web"]
Copy link
Member

Choose a reason for hiding this comment

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

I would add a more complete case, for example a service that belongs to two process groups, and then another service that only belong to one of them. Both services listen on tcp-1738, and the validation must fail only for the process group that is common to both services.

func (cfg *Config) getServiceDeduplicationKey(s Service) string {
processes := s.Processes
if len(processes) == 0 {
processes = []string{fly.MachineProcessGroupApp}
Copy link
Member

@dangra dangra May 7, 2024

Choose a reason for hiding this comment

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

in the context of appConfig, the default process group is cfg.defaultGroupName, this is important to avoid bugs when the configuration is flattened.

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.

None yet

3 participants