Add labels to ODS projects for cleanup 🧹

[felipecruz91]

Is your feature request related to a problem? Please describe. OpenShift clusters, over time, end up with 100+ ODS projects that are difficult to keep track of what the owner is. This is important when it comes to deleting old and unused projects to free up resources in the cluster.

Describe the solution you'd like The Prov App could define labels when creating the ODS project in OpenShift. For instance, it could add:

ods.project.owner: foo@bar.com ods.project.type: [default|kanban|EDProject]

This way, we could identify what projects belong to what users with oc get projects -l ods.project.owner=foo@bar.com

Additional context The aforementioned fields can be populated from the Prov App form.

Would like to hear your thoughts on this @clemensutschig @michaelsauter

[michaelsauter]

Sounds interesting - the question is what labels should be applied, and how to make that flexible enough ...

[stitakis]

I find it interesting too... additionally you will need to modify in ods-core https://github.com/opendevstack/ods-core/blob/master/create-projects/create-projects.sh to add the labels on/after project creation

[felipecruz91]

I've been looking into using the first project admin in the PROJECT_ADMINS list as owner of the project but just realized that labels do not allow using @ as part of it.

$ kubectl label namespace test 'ods.project.owner=foo@bar.com'
error: invalid label value: "'ods.project.owner=foo@bar.com'": a valid label must be an empty string or consist of alphanumeric characters, '-', '_' or '.', and must start and end with an alphanumeric character (e.g. 'MyValue',  or 'my_value',  or '12345', regex used for validation is '(([A-Za-z0-9][-A-Za-z0-9_.]*)?[A-Za-z0-9])?')

So I have replaced the '@' symbol with 'at'.

[metmajer]

@felipecruz91 we have work in progress with @michaelsauter already using a labelling standard... will have to find it

[michaelsauter]

@metmajer I think you are referring to https://github.com/opendevstack/ods-quickstarters/issues/512. However, that is about resources within a project, while I believe @felipecruz91 suggestion is for labels on the project itself.

[felipecruz91]

Thanks for clarifying @michaelsauter. My suggestion here is to use ods.project.owner to define what the owner of the project is.

I think it is nice to define the label name following a hierarchy from ods, followed by the type of object project, and finally the subject owner. Hopefully, this will avoid any conflicts or clashes with other labels that the infra team want to specify in the future.

[segator]

what about opendevstack.org/project.owner ? any metadata is welcome, this will be helpfully in the future for querying and tracability. thanks @felipecruz91 for the idea

[jafarre-bi]

I've been looking into using the first project admin in the PROJECT_ADMINS list as owner of the project but just realized that labels do not allow using @ as part of it.

$ kubectl label namespace test 'ods.project.owner=foo@bar.com'
error: invalid label value: "'ods.project.owner=foo@bar.com'": a valid label must be an empty string or consist of alphanumeric characters, '-', '_' or '.', and must start and end with an alphanumeric character (e.g. 'MyValue',  or 'my_value',  or '12345', regex used for validation is '(([A-Za-z0-9][-A-Za-z0-9_.]*)?[A-Za-z0-9])?')

So I have replaced the '@' symbol with 'at'.

A project admin user can be defined when provisioning the project, but I am not sure whether it will always be present. Otherwise, the first admin in the group is a good idea.

I like @segator proposal of opendevstack.org/project.owner. An alternative could be project.opendevstack.org/owner or even .../owner.email.

[stitakis]

@felipecruz91 is this item still planned for ODS 4.0.0 or we could move it to ODS 4.1.0?

[felipecruz91]

@metmajer Would you reply to the previous comment?

[metmajer]

@felipecruz91 this sounds super useful. However, there were issues with the service account permissions. @clemensutschig knows more. If there is no quick solution ahead, we will have to defer.