origin
origin copied to clipboard
openshift
Posting a V1 `ProjectRequest` drops Labels and Annotations
When POSing this (valid JSON, just console.logs like this):
{ kind: 'ProjectRequest',
apiVersion: 'v1',
metadata:
{ name: 'welcomeprojectcloos3y432',
creationTimestamp: null,
annotations: { 'rhmap.io/description': '' } },
labels:
{ 'rhmap.io/env': 'os3',
'rhmap.io/guid': 'ujzozs3h5ldwo4orxsaky432',
'rhmap.io/project': 'ujzozs773araip3o2zi7mwhp',
'rhmap.io/domain': 'testing' },
displayName: 'Welcome Project-cloud' }
both the annotations and labels are dropped. Could use projects API, but using project requests API so regular users can do the creation too.
We need to figure out how to allow label and annotation update on projects for project admins that is "safe". May be whitelist of allowed things to change.
We need to figure out how to allow label and annotation update on projects for project admins that is "safe". May be whitelist of allowed things to change.
Do we want to allow that in our simple project request flow? I think I'm inclined to say that is a more advanced use-case, better suited to custom logic.
At a minimum description and display, and maybe labels, that's all.
On Sep 1, 2015, at 1:43 PM, David Eads [email protected] wrote:
We need to figure out how to allow label and annotation update on projects for project admins that is "safe". May be whitelist of allowed things to change.
Do we want to allow that in our simple project request flow? I think I'm inclined to say that is a more advanced use-case, better suited to custom logic.
— Reply to this email directly or view it on GitHub https://github.com/openshift/origin/issues/3819#issuecomment-136808974.
At a minimum description and display, and maybe labels, that's all.
Display and description are already allowed: https://github.com/openshift/origin/blob/master/pkg/project/api/v1/types.go#L45-L46, I don't think I'd want to open up arbitrary labels for end-user usage. I'd expect the cluster admin to have opinions on what various project labels mean.
It's probably going to be an admin decision. We will have to enable labels for end users as soon as they have more than a few projects. I think we should allow unnamespaced labels to start.
On Sep 2, 2015, at 8:14 AM, David Eads [email protected] wrote:
At a minimum description and display, and maybe labels, that's all.
Display and description are already allowed: https://github.com/openshift/origin/blob/master/pkg/project/api/v1/types.go#L45-L46, I don't think I'd want to open up arbitrary labels for end-user usage. I'd expect the cluster admin to have opinions on what various project labels mean.
— Reply to this email directly or view it on GitHub https://github.com/openshift/origin/issues/3819#issuecomment-137051464.
It's probably going to be an admin decision. We will have to enable labels for end users as soon as they have more than a few projects. I think we should allow unnamespaced labels to start.
How would an admin express that users can choose labels on the projects they request? Also, how should we handle conflicts between labels in the template and labels the user provides?
Actually - I'm starting to think that annotations and labels a users set on project should be namespaced in the namespace object: user sets label "foo=bar" and annotation "biz=baz", they should have "prj.os.io/foo=bar" and "prj.os.baz" on the namespace. The virtual resource is the source of all filtering (i just added label filtering to projects) and so manages that transition. That actually provides the behavior I think we want for projects for end users without any collisions or risks.
On Wed, Sep 2, 2015 at 8:26 AM, David Eads [email protected] wrote:
It's probably going to be an admin decision. We will have to enable labels for end users as soon as they have more than a few projects. I think we should allow unnamespaced labels to start.
How would an admin express that users can choose labels on the projects they request? Also, how should we handle conflicts between labels in the template and labels the user provides?
— Reply to this email directly or view it on GitHub https://github.com/openshift/origin/issues/3819#issuecomment-137055365.
Clayton Coleman | Lead Engineer, OpenShift
@mfojtik make sure that someone doing this considers the repercussions of user-settable labels and annotations on a namespace. Perhaps requiring a known prefix would work.
@soltysh I could really use this :) My testing framework (based on kube and openshift e2e) creates project per namespace and when debugging I set it not to delete automatically. Having to delete every one of them (with generated names) manually sucks. Making labels work would help a lot when cleaning up.
We're running into this in Origin CI as well. We use Jenkins to create a project per image bundle for deploying out to a remote cluster. We would love to be able to label our projects to clean them up. If I'm the requester of the project and can delete it, I should be able to have some means by which I can manage all of the project I've requested. Labels are the k8s approach to this problem elsewhere.
That is known. I want to subdivide the projects I have requested to select between them. I want to oc get projects --selector .... I cannot use the annotation for this without listing and filtering on my end.
Unfortunately this requires us to define either a reserved namespace for labels the user can set, or vice versa, and is not necessarily safe from a backwards compatibility security perspective.
It's still something important we need to do.
On Wed, Dec 27, 2017 at 11:04 AM, Steve Kuznetsov [email protected] wrote:
I want to subdivide the projects I have requested to select between them. I want to oc get projects --selector .... I cannot use the annotation for this without listing and filtering on my end.
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/openshift/origin/issues/3819#issuecomment-354134864, or mute the thread https://github.com/notifications/unsubscribe-auth/ABG_pxrCzABG7N-oSfmbSmHe7HBnGId2ks5tEmqFgaJpZM4FdPnp .
Issues go stale after 90d of inactivity.
Mark the issue as fresh by commenting /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.
Exclude this issue from closing by commenting /lifecycle frozen.
If this issue is safe to close now please do so with /close.
/lifecycle stale
@bjartek this is probably the issue about setting labels in project requests we were discussing today
honestly after 3 years, I'd say people would take namespaced-labels versus waiting longer. there is no way we can do self-discovery without this.
@sttts @Anandnatraj This open issue relates to my JIRA issue https://issues.redhat.com/browse/API-1333
It's 2020 is there any plans to do this? Still a gap in Openshift 4.3.
It's 2022, and this is still a gap 😞