launcher-application
launcher-application copied to clipboard
Add the possibility to add labels to created namespaces (project)
for istio it's needed that projects are created with a specific label. We could perhaps add label meta data in the catalog and set that on the created project
What kind of labels would we need here?
Are they fixed-value labels? Or do they need dynamic values?
Would it be okay to set those labels on all/some top-level/important objects we create (DeploymentConfig, Service, Route etc) or would we need some kind of system to specifically specify where we want to put those labels?
we need here
Label added to the project/namespace -> oc label namespace default istio-injection=enabled
Are they fixed-value labels? Or do they need dynamic values?
We don't need dynamic values for the moment but fixed-values. Due to the time constraint to have such feature available asap, I would propose that when the istio namespace/project is created for the git flow then the label istio-injection=enabled is then added.
Would it be okay to set those labels on all/some top-level/important objects we create (DeploymentConfig, Service, Route etc) or would we need some kind of system to specifically specify where we want to put those labels?
For the future, it could be interesting that we propose a screen where user could see the by default labels, part of the Openshift template and where he/she could add new labels using a pop-up list to specify to which resource the label should be then added @quintesse
where he/she could add new labels using a pop-up list to specify to which resource the label should be then added
Is that something we can expect the user to understand what it does / how to use @cmoulliard ?
understand what it does
As the launcher tool is part of our strategy to help developers to develop their cloud native applications, a certain level of knowledge about kubernetes concepts are required and label or annotations are part of that
Looking at current Launcher, setting labels would certainly be an advanced option. (And rightfully so. A lot of Kubernetes is intentionally designed in a way that the application doesn't need to know it's running inside Kubernetes. Plus Launcher also serves OSIO, which is even more removed from Kubernetes.)
Indeed, if OSIO for example removed "community" boosters and left only the "redhat" ones because the choice could confuse users then I think labels/annotations are a very advanced option. Not saying we shouldn't add it, but I wonder how many people would know how to use it. (I don't for example ;) )
This topic came up in meetings over the last week and we discussed removing the requirement to label the project. We already have a trello card for this work and I can increase its importance if this is causing you issues.
Can we stay focused on this request When the istio namespace/project is created for the git flow then the label istio-injection=enabled is then added. for the moment as this is required for istio and summit ?
@cmoulliard That's your choice, I'm just letting you know the requirement will disappear soon. Let me know if you want us to raise the priority on the work.
Ok, after way too much time spent debugging to figure out why labels were not being created I today encounter this issue: https://github.com/openshift/origin/issues/3819
Seems setting labels on projects/namespaces is not supported and will most likely never be supported by the openshift rest API responsible for creating projects.
@cmoulliard I suggest that you up the priority on @knrc 's work, it seems the best way to go forward.
Edit: improved wording.
I'm testing an alternative way to set the labels. (Just in case the the other works takes longer than expected). Will let you know how it goes.
Nope, sorry, I don't know why/how it's possible to do so using the oc CLI command, but using fabric8:kubernetes-client I get:
Failure executing: PATCH at: https://192.168.42.42:8443/api/v1/namespaces/xxx. Message: User "developer" cannot patch namespaces in the namespace "xxx": User "developer" cannot "patch" "namespaces" with name "xxx" in project "xxx".
I have a local change which already removes the requirement for labelling projects, this will be pushed live as soon as we deal with an iptables related issue.