moltzaum opened a new issue #2592: Dangling Federations and Federation Structure URL: https://github.com/apache/trafficcontrol/issues/2592 `POST /cdns/foo/federations/` Does not connect a deliveryservice, but it should. The method to connect deliveryservies is via `POST federations/:id/deliveryservices` However, the only way to get the required id is by checking the response from the first post. Logically, this should be one step, especially due to the visibility limitation on federations. If a post to `cdns/foo/federations` does not save the id (due to user error), it is impossible to see or delete the dangling federation that was just created. The Visibility Limitation on Federations: `GET /cdns/foo/federations` limits the scope of a search by cdn. If no ds is linked, no cdn is associated. `GET /cdns/foo/federations/:id` currently ignores the scope of foo, but _theoretically_ tenacy via the ds should also limit the scope meaning a federation with no linked ds will not show up. Tenacy is relatively new, so I don't think this is currently the case. However, it is clear either way that it doesn't make sense to verify the id by a GET request like this. I was initially going to try creating an optional deliveryservice field in the json request (matching the same structure of the GET response below). I was thinking that the optional field could be made required in a new major version, but I'm not certain it is the best solution due to the awkward structure. ``` { "ttl": 48, "id": 3, "description": "the description", "cname": "new.cname.", "deliveryService": { "xmlId": "ds1", "id": 81 } } ``` Ideally, "deliveryservice" would be a list of ids in a similar fashion to the` federations/:id/deliveryservices` endpoint, but I'm hesitant to create a different structure between POST and GET responses. (contrary to the json above, federations and deliveryservices are a many to many relationship) Back to my primary point, the overall goal I had in exploring this topic is ensuring a federation is always visible from some perspective. A new GET endpoint for all detached/unassociated federations is possible, but didn't seem to make the most sense to me. A different approach that I think is perhaps more valid is having stronger connections between the cdn name specified in the url and the federation. For instance: `POSTing to /cdns/cdn1/federations`, then linking to ds2 (corresponding to cdn2) has absolutely NO relation to cdn1, other than there is a related tenant (except in the current implementation, cdn1 is completely ignored by the handler). If posting to cdn1 actually associated a federation with the ds directly associated with cdn1 I think that would make much more sense, however it would change behavior. What is the likelyhood that something like this can be implemented?
---------------------------------------------------------------- This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: [email protected] With regards, Apache Git Services
