View Issue Details

IDProjectCategoryView StatusLast Update
0017549CentOS CI[All Projects] generalpublic2020-07-02 06:14
Status assignedResolutionreopened 
Summary0017549: 0017548: OCP4 : , please grant to "fedora-ci-admins" right to manage "events" in namespace: "fedora-ci"
DescriptionHello, this ticket is about OCP4:

We want to specify FQDN for routes .
Services can be exposed securely with:
We need to use ACME/letsencrypt service that issues certificates for routes with https://FQDN.
There is tool for this:

The tool can be installed in different ways: 1) for cluster 2) for namespace.

I am trying to install the tool into our namespace: fedora-ci
But, I cannot create role for our namespace:

The error at this step is:

Error: "acme-openshift-acme" is forbidden: user "" (groups=["fedora-ci-admins" "system:authenticated:oauth" "system:authenticated"]) is attempting to grant RBAC permissions not currently held:
{APIGroups:[""], Resources:["events"], Verbs:["create" "update" "patch"]}

Please grant permission to "fedora-ci-admins" create that role for our namespace.
Because we manage resources in automatic way, it would be great that we have permission to create/remove the above role with our credentials.

Thank you! Regards!
TagsNo tags attached.




2020-06-29 16:11

reporter   ~0037254

Please close this ticket. I created the same one in Centos-CI namespace:


2020-06-29 16:12

reporter   ~0037255

Please ignore previous comment :-(


2020-06-29 16:35

developer   ~0037257

Hi astepano,

Hmm you shouldn't need to do any of this, we already have edge encryption available for use on our routes/ingresses eg:

See the following example route where I have edge encryption enabled:


2020-06-29 16:48


edge_encrypted_route.yaml (654 bytes)


2020-06-29 16:49

developer   ~0037259

Just uploaded the Route as a file, as the only keeps for 24 hours.


2020-06-29 16:52

reporter   ~0037260

@dkriwan, thank you for the reply.

Will it work for "routes" with specified FQDN?
We need support ACME.


2020-06-29 17:06

developer   ~0037262

Aha I misunderstood your request.. Ok I understand what you folks are trying to achieve. Hmm from looking at the I can't see where it is trying to grant access to create/update/patch Events ({APIGroups:[""], Resources:["events"], Verbs:["create" "update" "patch"]}).

Can you try this deployment instead: ?

If that fails, I'll look into granting this extra permission to create Events to your group.


2020-06-29 17:37

reporter   ~0037263

@dkirwan thank you! I installed:
I do not know, there is another place where it requires 'events':
Okay. In one place it is required, in other it is not. Ok, let's close this ticket. I will try to play if it doesn't work, I will open other ticket.


2020-06-29 17:45

developer   ~0037264

Great :D get back to us if you run into trouble.


2020-06-29 20:51

developer   ~0037268

Hi Astepano,

Quick question just to clarify the original query. "Services can be exposed securely with:"

We have the cluster configured with wildcard SSL certs from letsencrypt for * This allows us to terminate SSL at the edge for all routes/ingresses. Is that what you need here?

If so take a look at the Route example I linked earlier, it should have what you need to achieve this :)


2020-06-30 10:05

reporter   ~0037272

@dkirwan hi.
It was a statement from me: services can be exposed securely with: .
In other words: I know, that services can be exposed securely under domain
I just wanted to say: we use a different approach.
Thank you.


2020-07-01 13:41

administrator   ~0037285

@astepano Do we have an idea of which domains outside of we're looking to use here?

I'd really like to be sure we have a good handle on the endpoints where traffic might come in.


2020-07-01 13:48

reporter   ~0037286

Reply to bstinson@.
Example of running site:


2020-07-02 00:33

administrator   ~0037290

ok, so *

Is hosting this on *.ci.fp.o a hard requirement? Or just for looks?


2020-07-02 06:14

reporter   ~0037293

Hello. This is for mobility/flexibility.
Let's take The functionality is hard-bound to the 3.9 cluster. There is no way to flawlessly move the service from to new . We want to break connection between service name with the platform where it is hosted. On the other hand: unification.

Issue History

Date Modified Username Field Change
2020-06-29 16:10 astepano New Issue
2020-06-29 16:10 astepano Status new => assigned
2020-06-29 16:11 astepano Note Added: 0037254
2020-06-29 16:12 astepano Note Added: 0037255
2020-06-29 16:35 dkirwan Note Added: 0037257
2020-06-29 16:48 dkirwan File Added: edge_encrypted_route.yaml
2020-06-29 16:49 dkirwan Note Added: 0037259
2020-06-29 16:52 astepano Note Added: 0037260
2020-06-29 17:06 dkirwan Note Added: 0037262
2020-06-29 17:37 astepano Note Added: 0037263
2020-06-29 17:45 dkirwan Note Added: 0037264
2020-06-29 20:51 dkirwan Note Added: 0037268
2020-06-30 10:05 astepano Note Added: 0037272
2020-06-30 10:50 siddharthvipul1 Status assigned => resolved
2020-06-30 10:50 siddharthvipul1 Resolution open => fixed
2020-07-01 13:41 bstinson Note Added: 0037285
2020-07-01 13:48 astepano Status resolved => feedback
2020-07-01 13:48 astepano Resolution fixed => reopened
2020-07-01 13:48 astepano Note Added: 0037286
2020-07-02 00:33 bstinson Note Added: 0037290
2020-07-02 06:14 astepano Note Added: 0037293
2020-07-02 06:14 astepano Status feedback => assigned