moby / moby/swarmkit

Generate a service name when CreateService receives none

Open
#3,291 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
Go
Stars
3.7k
Forks
676
Avg merge
4d 9h
Merged PRs (30d)
6

Description

Consider allowing to create a service without a name and generate one in SwarmKit.

Context: Moby currently generates a random service name in ServiceSpecToGRPC:

https://github.com/moby/moby/blob/466f2d2e5d630e51faf574a49e10d4787e3fa099/daemon/cluster/convert/service.go#L168-L182

This is a bit unexpected for a conversion function, and the name is generated only once. If it already exists, SwarmKit returns:

rpc error: code = AlreadyExists desc = name conflicts with an existing object

Moby now needs to detect this error, generate another name and retry the whole CreateService request:

I think it would make more sense for SwarmKit to handle this. It owns the service store and already generates the service ID, so it can assign a unique name as part of creating the service.

We probably don't need to duplicate Moby's friendly names generator. Using the generated service ID, or another GUID-like value, should be enough.

This would also let Moby remove service-name generation from the conversion code and avoid every SwarmKit client having to implement the same retry logic.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start at SwarmKit's CreateService entry point and service store, then review the linked Moby ServiceSpecToGRPC code and PR #53468 for the current name generation and retry behavior. Done means CreateService accepts a missing name, assigns a unique generated name during creation, and allows Moby to remove its duplicate generation and retry logic.

Written by the indexing model from the issue text.

Assessment

Tech stack
go
Domain
backend-api-design, distributed-systems
Issue type
Feature
Difficulty
4/5
Estimated time
3-5 days
Activity status
Active
Clarity
Mostly clear
Newbie friendliness
45/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.