Origin: Posting a V1 `ProjectRequest` drops Labels and Annotations

Created on 22 Jul 2015 · 21Comments · Source: openshift/origin

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.

componenrestapi lifecyclfrozen prioritP1

Source

cianclarke

👍2

Most helpful comment

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.

andyfeller on 20 Sep 2018

👍3

All 21 comments

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.

smarterclayton on 22 Jul 2015

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.

deads2k on 1 Sep 2015

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.

smarterclayton on 1 Sep 2015

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.

deads2k on 2 Sep 2015

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.

smarterclayton on 2 Sep 2015

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?

deads2k on 2 Sep 2015

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

smarterclayton on 2 Sep 2015

@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.

deads2k on 6 Sep 2016

/cc @enj

stevekuznetsov on 8 Apr 2017

@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.

tnozicka on 14 Dec 2017

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.

stevekuznetsov on 25 Dec 2017

👍2

/cc @mfojtik @deads2k @soltysh

stevekuznetsov on 25 Dec 2017

Projects are already annotated with the user who requested them.

enj on 26 Dec 2017

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.

stevekuznetsov on 27 Dec 2017

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 notifications@github.com
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
.

smarterclayton on 31 Dec 2017

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