OpenStack Public Cloud WG

Deletion of entire project

Bug #1771582 reported by Tobias Rydberg
38
This bug affects 9 people
Affects Status Importance Assigned to Milestone
OpenStack Public Cloud WG
Confirmed
Critical
Unassigned

Bug Description

Deletion of projects/users - possibility to block request if resources exists, AND possibility to escalade request to delete all underlaying resources

"(Tomas Vondra): Is ospurge not enough?
(Nick Jones): Last time I checked ospurge required direct DB access. An API would be preferable IMO. JG: Set the quota to zero might help
(samueldmq): What if each service implemented an admin API call to delete resources for given project ID? (Nick Salvisberg): @samueldmq: like neutron purge?
(samueldmq): @Nick if that is a REST API call, yes, like that.

(adriant): We (Catalyst) are working on a user triggerable (or more destructive admin triggerable) workflow in Adjutant (https://github.com/openstack/adjutant) that will delete a project, and all it's resources. (see the referenced gerrit review)

(tobberydberg) I like the idea of API call to something like neutron purge. If that can be fired from a single keystone API call to all underlaying components, that better.

(mnaser): https://github.com/openstack/ospurge"

Reference:
Adjutant project termination: https://review.openstack.org/#/c/477707/

Revision history for this message
John Garbutt (johngarbutt) wrote :

Please use os-purge, and lets get feedback.

If there are APIs missing in the projects to make this tool work well, lets get that feedback and fix it :)

Tobias Rydberg (tobberydberg)
Changed in openstack-publiccloud-wg:
status: New → Confirmed
Tobias Rydberg (tobberydberg)
Changed in openstack-publiccloud-wg:
importance: Undecided → Critical
Revision history for this message
Doug Hellmann (doug-hellmann) wrote :

ospurge uses shade, not direct database access. Using a standalone tool like that to orchestrate removing a project across a cloud seems like a reasonable design, so it would be useful to understand why a central API is more desirable.

Revision history for this message
Tobias Rydberg (tobberydberg) wrote :

I see that we should really create a new description of this "cross project issue", and leave out technical solutions as discussed in Denver.

Personally, using something like ospurge could be fine, if it's something that is under maintenance (especially security maintenance) and something "official", if not it will be hard to put into production. Could be that it's functionality is moved into the openstack client as well. What I know of right now regarding ospurge is that that's not the case, please correct me if I'm wrong.

Also, same functionality should be available for the web REST API to serve operators that integrate that way.

Revision history for this message
Doug Hellmann (doug-hellmann) wrote :

You're correct that ospurge is not managed by an official project team today. With some support from users, I'm sure we could find a home for it. And of course not being official doesn't mean it isn't maintained.

Before we talk about making the project official, or creating a REST API, it would be useful to know if it actually meets the technical needs. Does it even work? :-)

I'm also curious about how deleting things that are shared and in use by other tenants should work. That's the area where I expect we might have to do some cross-project work, to define what happens in those cases. For example, if I upload an image to glance and mark it shared, and someone else boots a server from it, can I delete the image? Are there other similar cases?

Revision history for this message
Tobias Rydberg (tobberydberg) wrote :

A lot of outstanding questions indeed. As you say, shared stuff is hard to know what to do with. Billing/usage data is also important to keep track on for some period of time even though a project doesn't exist anymore...

We will submit a Forum session for this to Berlin that we hope to get to the schedule and also that there will be a lot of operators in the room.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.
Subscribing...

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.