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.

Sign up for GitHub

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

Jump to bottom

Provide some guidance for CLI-friendly names #425

Merged
merged 1 commit into from
Jan 23, 2018
Merged

Provide some guidance for CLI-friendly names #425

merged 1 commit into from
Jan 23, 2018

Conversation

duglin
Copy link
Contributor

@duglin duglin commented Jan 22, 2018

Closes #305

Signed-off-by: Doug Davis dug@us.ibm.com

@cfdreddbot
Copy link

Hey duglin!

Thanks for submitting this pull request! I'm here to inform the recipients of the pull request that you and the commit authors have already signed the CLA.

@angarg12
Copy link
Contributor

angarg12 commented Jan 22, 2018 •
edited by avade
Loading

LGTM

Approved with PullApprove

1 similar comment
@mattmcneeney
Copy link
Contributor

mattmcneeney commented Jan 22, 2018 •
edited by avade
Loading

LGTM

Approved with PullApprove

pmorie
pmorie reviewed Jan 22, 2018
View reviewed changes
spec.md
@@ -338,6 +338,11 @@ defines a "CLI-friendly" string as a short string that MUST only use lowercase
characters, numbers and hyphens, with no spaces. This will make it easier for
users when they have to type it as an argument on the command line.

For backwards compatibility reasons, this specification does not preclude
Copy link
Contributor

Choose a reason for hiding this comment

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

Should this read "CLI-unfriendly"?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I think it can go either way, but "unfriendly" does has kind of a funny tweak to it so I'll switch it.

Provide some guidance for CLI-friendly names
ca1f8f7 
Closes openservicebrokerapi#305

Signed-off-by: Doug Davis <dug@us.ibm.com>
@duglin
Copy link
Contributor Author

duglin commented Jan 22, 2018

@angarg12 @mattmcneeney re-review needed

@mattmcneeney
Copy link
Contributor

mattmcneeney commented Jan 22, 2018 •
edited by avade
Loading

LGTM

Approved with PullApprove

2 similar comments
@angarg12
Copy link
Contributor

angarg12 commented Jan 23, 2018 •
edited by avade
Loading

LGTM

Approved with PullApprove

@avade
Copy link
Contributor

avade commented Jan 23, 2018 •
edited
Loading

LGTM

Approved with PullApprove

@duglin
Copy link
Contributor Author

duglin commented Jan 23, 2018

just one more needed - @vaikas-google ? @pmorie ?

@duglin
Copy link
Contributor Author

duglin commented Jan 23, 2018

@fmui ?

@fmui
Copy link
Member

fmui commented Jan 23, 2018 •
edited by avade
Loading

LGTM

Approved with PullApprove

1 similar comment
@vaikas
Copy link
Contributor

vaikas commented Jan 23, 2018 •
edited by avade
Loading

LGTM

Approved with PullApprove

@avade
Copy link
Contributor

avade commented Jan 23, 2018

LGTM

@duglin duglin merged commit b2ecf53 into openservicebrokerapi:master Jan 23, 2018
@duglin duglin deleted the Issue305 branch March 2, 2018 03:26
@dotchev
Copy link

dotchev commented Sep 14, 2018

For backwards compatibility reasons, this specification does not preclude the use of CLI-unfriendly strings that might cause problems for command line parsers (or that are not very meaningful to users), such as -. It is therefore RECOMMENDED that implementations avoid such strings.

This seems contradicting with

A CLI-friendly name of the service. MUST only contain alphanumeric characters, periods, and hyphens (no spaces).

The issue we have is that we have many services in CF that use some other characters like _. Now we cannot register these in Service Catalog in K8S.

Status:   ErrorSyncingCatalog - Error syncing catalog from ClusterServiceBroker.Error reconciling ClusterServiceClass (K8S: "367188a4-2511-4038-9be7-9694b05214dc" ExternalName: "simple_service") (broker "simple-broker"): ClusterServiceClass.servicecatalog.k8s.io "367188a4-2511-4038-9be7-9694b05214dc" is invalid: spec.externalName: Invalid value: "simple_service": [-.a-zA-Z0-9]+ (regex used for validation is 'service-name-40d-0983-1b89') @ 2018-09-14 10:16:34 +0000 UTC

@duglin
Copy link
Contributor Author

duglin commented Sep 14, 2018

I was going to open up an issue for this exact situation (the underscore) because we're seeing it too. Apparently CF only verifies that its a string so I'm not sure why the spec places any restrictions at all.

As for those 2 spots in the spec... they're not exactly contradictory. The 2nd one tries to constrain the set of valid characters, the 1st one tries to tell people to be smart about what words they use while using those characters. I think the example given is a good one.... while "-" is a valid character, its really odd (and not friendly) to use just "-" as the service name.

Issue: #603

@teddyking teddyking mentioned this pull request Mar 13, 2020
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@pmorie pmorie pmorie left review comments

Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
9 participants
@duglin @cfdreddbot @angarg12 @mattmcneeney @avade @fmui @vaikas @dotchev @pmorie