-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I need some other opinions on how repo delete should function for repos that exist on a CDS.
Currently, if a repo is deployed on a CDS, it cannot be deleted from the Pulp server until it's unassociated from the CDS. Until recently, the behavior was that unassociate was strictly a server operation; the CDS would delete the repo the next time it syncced and saw the repo was no longer in its list. That's an important note; the CDS never tracked a list of its repositories, it simply syncced what it was told to by the server and deleted whatever was left. At the time it was sufficient. It also made CDS instances easier to deal with. Then we added repo auth, which complicated things. The CDS now needed to keep some track of what repos it had deployed, or at least the authorized ones. During unassociate, the CDS is sent a message saying the auth credentials for that repo were None. That stuff all works and is fine. The problem is what happens if the CDS is down and the repo is deleted on the server. The unassociate call is still required before the delete can occur. But that unassociate call is no longer server-side only and requires talking to the CDS to have it remove the repo auth settings for that repo. That means if the CDS is offline, you can't unassociate. Therefore, if the CDS is offline, you can't delete a repo that is deployed to it. Obviously that's not what we want. When I added global repo auth I introduced the REST idea of "partial content", meaning that the server successfully updated the global repo auth but not all of the CDSes were updated. I guess I could use that here as well. It feels bad to allow the delete if the repo is still on a CDS, but I suppose that's no more bad than allowing a auth update but not having all CDSes pick up that change. Arguably, it's safer than the auth case since the delete will still occur on the next CDS sync. So my ultimate question is if we're comfortable with the partial content approach. I need to get this fixed ASAP for RHUI and will probably have to do it in a few other CDS APIs as well (QE is gonna have a field day doing stuff while CDS instances aren't running and filing bugs). If we are comfortable with it, anyone want to volunteer to review the CDS and repo APIs for where this should be applied? The CLIs will have to be updated as well to look at the returned result (ok v. partial content) and display to the user which CDS instances failed to be updated. But it's gotta happen and I don't know when I'd have time to do it. - -- Jay Dobies RHCE# 805008743336126 Freenode: jdob http://pulpproject.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJNocyBAAoJEOMmcTqOSQHCWrUIAI6sQlsG9HeiZfNLmAgC8jJs S/WWrRSeLxtkUQxP4HPe8GKzHOImp6VIViaDuHQ6On1jg5PDyj7nyxaW2yOgNRis 33HWwnk00HfNRzUb0gSFvdxzOALvTedZUF6w6/Ooa4FFPJjOuuIwAh3jT4+9+l/V yLXwgpd8vdPaxomWE1c2MZFacO/NLiOjGrTQNzBIsErJ59+ixC8qj4KSJXAxvzcY UjN2/K39A9NSM5+KF4joRQ4walFN5bfHy9ZeEsgJEgjOX0VIOHfjSthvgKJP4Usk /GwP1kZsZ6o4yFP67MDL+vBppGddNy1duKJujKrN16zHGa6IJM4R2DGoF5ibp9k= =5Wxj -----END PGP SIGNATURE----- _______________________________________________ Pulp-list mailing list [email protected] https://www.redhat.com/mailman/listinfo/pulp-list
