Skip to content
This repository has been archived by the owner on Mar 13, 2021. It is now read-only.

Make the service name used by a core deployer configurable #200

Closed
trisberg opened this issue Nov 22, 2019 · 4 comments · Fixed by #214
Closed

Make the service name used by a core deployer configurable #200

trisberg opened this issue Nov 22, 2019 · 4 comments · Fixed by #214
Assignees
Labels
demo enhancement New feature or request
Milestone

Comments

@trisberg
Copy link
Member

trisberg commented Nov 22, 2019

Currently the deployers generate a service name to keep them unique. This makes it harder to discover services since you can't bind using just the DNS name, you would have to look it up based on labels. We should provide a way to define the actual name used and the end-user would be responsible for avoiding clashes. If user doesn't specify the name, then we should generate one as we do today.

@trisberg trisberg added the enhancement New feature or request label Nov 22, 2019
@trisberg trisberg added this to the v0.5.0 milestone Nov 22, 2019
@trisberg trisberg added this to To do in v0.5.0 project via automation Nov 22, 2019
@jldec
Copy link

jldec commented Nov 22, 2019

Good idea, i like it. Was there a reason not to use the deployer name as the default service name?

@jldec jldec added the demo label Nov 29, 2019
@jldec
Copy link

jldec commented Nov 29, 2019

Example with proposed CLI flag
riff core deployer create inventory --service-name mysvc

If flag is not provided, the current (auto-generated) name is used.
Defaulting to match the deployer name can result in conflicts so avoiding that for now.

glyn added a commit to glyn/system that referenced this issue Nov 29, 2019
@glyn glyn closed this as completed in #214 Nov 29, 2019
v0.5.0 project automation moved this from To do to Done Nov 29, 2019
@jldec jldec changed the title Make the service name used by the deployers configurable Make the service name used by a core deployer configurable Nov 29, 2019
@glyn
Copy link
Contributor

glyn commented Dec 3, 2019

@scothis is questioning this approach - re-opening for further discussion.

@glyn glyn reopened this Dec 3, 2019
v0.5.0 project automation moved this from Done to In progress Dec 3, 2019
glyn added a commit to glyn/system that referenced this issue Dec 3, 2019
@glyn
Copy link
Contributor

glyn commented Dec 3, 2019

The guidance that is being developed in RFC 0006 suggests that we generate a static name (maybe even without suffix) as user-specified names for auto-generated resources create a number of edge cases.

So let's revert the earlier implementation of this issue and follow up with #223.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.