Don't introduce a brand new ServiceName

[h2zh]

Current pattern

Field	Pattern
prefix	[Origin] “/origins/” + hostname + optional(‘:’ + port) [Cache] “/caches/” + sitename
sitename	os.hostname OR set by config param
service name	now it's just a function that gets sitename (not a field in any json)
webURL	schema + hostname + optional(‘:’ + port)

I think it is unnecessary to introduce a new pattern (hostname:port) for "ServiceName", breaking its interchangeability with "Sitename". This extra field will add confusions to JSONs across Pelican, especially "ServiceName" and "Sitename" look similar. Also, port can change so this is an unstable identifier.

Instead of "ServiceName", brokerEndpoints TTLCache should label its key as service's network address (hostname:port) - derive from URL.Host(for Origin)/WebURL.Host(for Cache). It's more straightforward to reflect the actual usage of this key - keep URL as URL - rather than creating new term "ServiceName". In this way, when broker is enabled and a TCP connection is initialized, the broker dialer will first strip the service's network address from the URL, then check if it is in brokerEndpoints. If so, it will establish the connection via broker. Thus, we have to use the service's network address as key for brokerEndpoints, but it is not necessarily mean that we need to make it as "ServiceName". Other map data structure may use different field as the key. For example, sitename is the key for filteredServers.

Above all, creating a "service name" that's really just a rebranded URL adds confusion without significant benefit.

[h2zh]

@bbockelm Appreciate your thoughts on this analysis!

[bbockelm]

Instead of "ServiceName", brokerEndpoints TTLCache should label its key as service's network address (hostname:port) - derive from URL.Host(for Origin)/WebURL.Host(for Cache).

This is the problem. To use the broker, a service must have a unique name in the federation (used to route requests to it) and prove it is associated with the federation (by signing a token with a private key associated with the public key in the registry for that name).

The service's "network address" is not particularly meaningful name as it may not be addressable on the public internet.

I agree about the confusion between "site name" and "service name". "Service name" implies there's a name for the service, which is not true if there are multiple services running in one pelican instance. "site name" also implies we have some well-defined concept of a site, which might not be true. I scribbled some notes 2 weeks ago about a different terminology scheme that I thought was in the right direction (I used ID and Name).

• Server: a single instance of the Pelican software providing one or more services to the data federation.
  • Example: Running process inside a container that can be contacted on port 8443.
• Service: a set of functionality provided by the server.
  • Decided by the server, registered with the registry. Requires federation administrator approval to change.
  • Example: cache, origin, director, registry.
• ID: A persistent unique identifier for the server within the federation.
  • Randomly generated, 7 digits, [0-9a-z].
  • Must be unique within the federation.
  • Decided by the server, registered with the registry. Requires federation administrator approval to change.
  • Example: 18f1jk5
• Endpoints: One or more DNS names (hostname with optional port; if port is missing, assumed to be 443) that the server can be contacted at.
  • Must be unique within the federation.
  • Decided by the server, communicated to the director.
  • Example: osdf-uw-cache.svc.osg-htc.org:8443
• Name: Human-friendly.
  • Must be unique within the federation.
  • Decided by the server, registered with the registry. Requires federation administrator approval to change.
  • Director queries the registry to get the name information.
  • Example: UW_OSDF_CACHE

[h2zh]

I think this terminology scheme is a great master plan! Here are my understandings and a few questions popped up in my head:

ID should be named after ServerID and added to the namespace table in Registry.

type Namespace struct {
    ID            int                    `json:"id" gorm:"primaryKey"` // Existing
    ServerID      string                 `json:"serverId" gorm:"unique uniqueIndex"` // New
    Prefix        string                
    Pubkey        string   
}

Endpoints should be a new DB table persisted in Registry, and link to namespace table via ServerID, to support multiple endpoints per server while enabling efficient lookup. This schema allows easy CRUD operations as Endpoints can change with deployment.

type Endpoint struct {
    ID          int    `json:"id" gorm:"primaryKey"`
    ServerID string    `json:"serverId" gorm:"index"`
    Address     string `json:"address" gorm:"uniqueIndex"` // hostname:port
    CreatedAt   time.Time `json:"createdAt"`
    UpdatedAt   time.Time `json:"updatedAt"`
    DeletedAt   time.Time   `json:"deletedAt"`
}

In this way, the broker workflow would be like the pseudo code as below:

// Use Server ID as key, not hostname:port
brokerEndpoints.Set(serverID, brokerInfo)

// When establishing connections:
serverID := getServerIDFromRegistry(endpoint(as hostname:port))
// Verify the token 
if pubkey, err := getPubkeyFromRegistry(serverID); err != nil {
}
if ok, err := verifyToken(token, publicKey); err != nil {
}
if brokerInfo, exists := brokerEndpoints.Get(serverID); exists {
    // Use broker
}

Above all, I think the first step would be adding ServerID(ID) to Registry's namespace table. We can:

1. Add a new column ServerID to namespace table
2. Modify the code to generate new ServerID when new server namespace registers.
3. Avoid re-registration for existing server namespace: The fed admin can run a DB script to populate ServerID for each existing server. Then the servers can get this ServerID along with the latest sitename from Registry via this flow Persist a Pelican service's registered name #2300 (require slightly modification)

[williamnswanson]

If the ID is supposed to be unique in the federation, wouldn't it make sense for the Registry to assign the ID to the server, rather than have the server need to "guess" what IDs are available for it to use?

For Endpoints, would they be specified per-service (or at the server level with a mapping to one or more services), or would they be for contacting anything/everything on a server?

[h2zh]

Thanks for the inputs! @williamnswanson Yes, I also agree that ID should be generated on the Registry side and then inform the Server.

The endpoint is for everything on that server. A server may have multiple endpoints (e.g. multi DNS for load balancing), and multiple services (rarely though, the only case I know is fed-in-a-box for testing only). I'm thinking of creating seperate tables for endpoint and service, to support the 1-to-many relation between server and endpoints/server and services.

[CannonLock]

@h2zh @bbockelm How is this going to translate to the admins?

I am getting the impression that we could use the ID for the prefix and completely abstract the idea of a Cache and Origin Prefix from the user. Making the new Origin/Cache form:

Name
Pubkey
Description
Security Contact User Id