Skip to content
This repository has been archived by the owner on Apr 17, 2023. It is now read-only.

Implemented namespace deletion #1938

Merged
merged 2 commits into from
Aug 14, 2018
Merged

Conversation

mssola
Copy link
Collaborator

@mssola mssola commented Aug 10, 2018

This commit fixes one of the oldest requests we've had: being able to
delete a namespace. It also introduces an API endpoint for it.

Fixes #767

Signed-off-by: Miquel Sabaté Solà [email protected]

@mssola
Copy link
Collaborator Author

mssola commented Aug 10, 2018

To do:

  • Fix weird delay when deleting a namespace with repositories. This looks like one of those connection limits errors we've had sometimes...
  • Add UI button to delete namespaces 🙃 (now it's only done through API).

@mssola
Copy link
Collaborator Author

mssola commented Aug 10, 2018

Fixed by raising the default puma workers. This is really ugly, but it looks unavoidable on a raw puma setup.

In order to improve this for 2.5, I propose to leave the task of deleting manifests (which is the part of the code taking connections) to the garbage collector. This way, deleting namespaces/images/tags will work on a DB level, and then the garbage collector will delete the dangling manifests. What do you think @vitoravelino ?

@vitoravelino
Copy link
Contributor

In order to improve this for 2.5, I propose to leave the task of deleting manifests (which is the part of the code taking connections) to the garbage collector. This way, deleting namespaces/images/tags will work on a DB level, and then the garbage collector will delete the dangling manifests. What do you think?

It totally makes sense. This could also be applied when deleting a repository too. 👍

@@ -52,6 +52,16 @@ def create?
(APP_CONFIG.enabled?("user_permission.create_namespace") || user.admin?) && push?
end

def destroy?
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is allowing any namespace to be destroyed if user is admin and delete is enabled. That is not true as described in destroy service object code.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We can further discuss this on Monday. I believe that those checks have to be performed on the service, rather than on the policy. This is because an error on a personal namespace is, an error semantically speaking, not something disallowed for some users (i.e. related to authentication or authorization).

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We need to fix this in the authorization level somehow to avoid showing the delete button when deletion would be denied. That's why I suggested it here.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure I'm following 😕 In order to show/hide the delete button, you need some code in the authorization level? Isn't it possible to get this right from a helper somehow?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I do use a helper for that but I usually reuse the logic from the policies. That's what I've been doing for other cases. We've been strict in other policies rules but not in this one. What's the line between having stuff being done inside policies or not?

Copy link
Collaborator Author

@mssola mssola Aug 13, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fair point. The distinction is on the semantics imho. It's not about "you are not authorized to perform this", rather "what you are trying to do is not possible because of reason X". In this case, it's not possible because we don't want to implement personal namespace removal until we don't implement user removal.

@mssola
Copy link
Collaborator Author

mssola commented Aug 10, 2018

Squashed. I've added a Signed-Off in the first commit 😉

@mssola mssola force-pushed the delete-namespaces branch 2 times, most recently from 83133d6 to bb864eb Compare August 13, 2018 12:12

// TODO: refactor bootstrap popover to a component
$(this.$el).on('inserted.bs.popover', DELETE_BTN, () => {
console.log('delete carai');
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Haha.

@@ -8,6 +8,10 @@ def can_manage_namespace?(namespace, user)
NamespacePolicy.new(user, namespace).update?
end

def can_destroy_namespace?(namespace, user)
NamespacePolicy.new(user, namespace).destroy?
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@vitoravelino all that would take is to update this method so it also checked personal namespaces, no?

@mssola
Copy link
Collaborator Author

mssola commented Aug 13, 2018

@vitoravelino I just implemented what I mentioned here. Could you review again?

@@ -8,6 +8,10 @@ def can_manage_namespace?(namespace, user)
NamespacePolicy.new(user, namespace).update?
end

def can_destroy_namespace?(namespace, user)
NamespacePolicy.new(user, namespace).destroy? && !User.exists?(namespace: namespace)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It worked partially. Just need to check for global namespaces to deny that too.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That is true. We are not checking this in neither the policy nor the service. Where should we put this check 🤔 ? I'd say that you could argue for both in this case:

  1. If you put it on the policy, it means that no one is authorized to delete a global namespace. It means that this will never happen (e.g. it's not like the personal namespace case because in that case we may eventually allow that).
  2. If you put it on the service, it means that what you are trying to do is semantically wrong, regardless of your credentials.

On this I would favor option 1, but I'm not sure. @vitoravelino what do you think?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@mssola option 1 sounds better.

vitoravelino
vitoravelino previously approved these changes Aug 13, 2018
Copy link
Contributor

@vitoravelino vitoravelino left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Besides my last comment, everything working as expected. This is super nice! Kudos! 🎉

This commit fixes one of the oldest requests we've had: being able to
delete a namespace. It also introduces an API endpoint for it. There are
two exceptions when it comes to deleting a namespace:

1. Personal namespaces cannot be removed. In the future we might
   implement user removal, and then it will make sense to re-iterate on
   this.
2. Global namespaces cannot be removed, because they are meant to be
   guaranteed by everyone using the registry.

Fixes SUSE#767

Signed-off-by: Miquel Sabaté Solà <[email protected]>
Signed-off-by: Vítor Avelino <[email protected]>
This is needed to keep up with the requirements of deleting namespaces.

Signed-off-by: Miquel Sabaté Solà <[email protected]>
@mssola
Copy link
Collaborator Author

mssola commented Aug 14, 2018

@vitoravelino done! Let's wait for Travis now 😄

@vitoravelino vitoravelino merged commit eb33db6 into SUSE:master Aug 14, 2018
@mssola mssola deleted the delete-namespaces branch August 14, 2018 11:25
@mssola
Copy link
Collaborator Author

mssola commented Aug 14, 2018

And with that, there are no more features left for 2.4. Let's start hunting bugs until the final release! 😋

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

How do we destroy a namespace?
2 participants