search

opendevstack / ods-provisioning-app

Provisioning app, which triggers project and component provisions (including Jira / Confluence / BitBucket and OCP resource creation)
Apache License 2.0
15 stars 20 forks source link

OpenShift Project Removal: Automated Decommission Process #166

Open stephenkehoe opened 5 years ago

stephenkehoe commented 5 years ago

Primary Request: OpenDevStack to have the capability to retire/delete/decomission OpenShift projects automatically.

Secondary Request: Proof of Concept\Temporary Project: Time bound projects for 90 days that will be removed automatically.

clemensutschig commented 5 years ago

@stephenkehoe - what we can support is a specific project type - that you can query for .. but NO automated removal. that job needs to be built elsewhere - but can use the new /delete operations of the provision app

stephenkehoe commented 5 years ago

@clemensutschig - If there is the capability for a project owner to delete the entire stack Atlassian and OpenShift project from the provision app that would be a nice addition. Potentially Dangerous, but something they need to take ownership on. We can't chase people down to clean up their unused workloads.

Would this be driven by a MyShop\ServiceNow request form?

The second request was thinking down to road how to handle temporary requests like Test\POCs. Things tend to just sit out there and never get cleaned up. Since we don't own the project it's not clear to INF if they can be removed.

Just trying to avoid container sprawl :)

apeltzer commented 2 years ago

Would be great to enable users (after a sanity check / warning / ...) to delete the entire stack, either from the existing provision app ("deprovision") or via ServiceNow.

metmajer commented 2 years ago

@stephenkehoe as discussed, time-boxed sandbox environments are on the roadmap and their creation will follow the same process we're using for deploying regular environments.

@apeltzer a simple deletion is not possible in all cases, usually a more complex decommissioning including documentation generation will be needed. With the availability of sandbox environments, the need for decommissioning should be less high. At the moment, we don't have this on the roadmap.

AlberTajuelo commented 2 years ago

It would be great to have this feature 👍

tbugfinder commented 2 years ago

A sandbox environment isn't comparable with an automated decommissioning. It sounds like the technical details would get implemented anyway for the time-boxed environments. As this project is also about using automation for documentation, the decommissioning should be on the roadmap. As a developer I can change (add / remove) packages, code, tests, resources, etc. from my environment but the decommissioning isn't supported?