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’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix service name collision or breakage #710

Merged
merged 3 commits into from Feb 13, 2022
Merged

Conversation

iannbing
Copy link
Contributor

@iannbing iannbing commented Feb 11, 2022

Description

This PR fix the issue for service name collision and breakage.
If user attempts to rename a service with an existing name, the form will show a proper error message and disable all other fields until user gives a unique name.

Fixes: #375

Checklist

  • The PR branch is set up to merge into dev instead of master.

@iannbing iannbing temporarily deployed to integration-tests February 11, 2022 14:53 Inactive
@iannbing
Copy link
Contributor Author

Note that the uuid of service is created by FE, which is not ideal. I didn't look deeper to check if how BE process the services. @fruttasecca Feel free to chip in.

[
is_service_definition_valid(service) and sname == service["name"]
for sname, service in services.items()
]
[is_service_definition_valid(service) for _, service in services.items()]
Copy link
Member

Choose a reason for hiding this comment

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

I think it might disrupt some existing logic where it is/was assumed that the dictionary key and service name were interchangeable. Regardless of this, it might not be feasible because then users won't be able to resolve (i.e. dns) to a given service from within a step/kernel, or the logic around that needs to get more complicated.

Essentially we want users to be able to refer to service "redis" as redis, or at least that's what happens currently in the k8s branch, while prek8s it's something like service-<project uuid>-<pipeline uuid>.

Copy link
Member

Choose a reason for hiding this comment

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

I think we want to keep service name uniqueness at the pipeline level

Copy link
Contributor Author

@iannbing iannbing Feb 11, 2022

Choose a reason for hiding this comment

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

Hmm, this means we actually don't allow users to have multiple instances of the same service in a pipeline?

I got it. Will change the PR.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

@fruttasecca BE changes have been removed.

@cypress
Copy link

cypress bot commented Feb 11, 2022



Test summary

88 0 0 0


Run details

Project orchest
Status Passed
Commit 07a720e ℹ️
Started Feb 11, 2022 11:02 PM
Ended Feb 11, 2022 11:56 PM
Duration 54:00 💡
OS Linux Ubuntu - 20.04
Browser Chrome 88

View run in Cypress Dashboard ➡️


This comment has been generated by cypress-bot as a result of this project's GitHub integration settings. You can manage this integration in this project's settings in the Cypress Dashboard

@iannbing iannbing temporarily deployed to integration-tests February 11, 2022 23:01 Inactive
@iannbing iannbing merged commit c04655e into dev Feb 13, 2022
@iannbing iannbing deleted the fix/change-service-name branch February 13, 2022 12:35
@iannbing iannbing added the fix PR fixes a bug label Feb 13, 2022
@iannbing iannbing restored the fix/change-service-name branch February 13, 2022 13:07
@yannickperrenet yannickperrenet deleted the fix/change-service-name branch March 14, 2022 14:28
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
fix PR fixes a bug
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants