Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

We need to document our service account and roles story #909

Closed
n3wscott opened this issue Mar 15, 2019 · 7 comments
Closed

We need to document our service account and roles story #909

n3wscott opened this issue Mar 15, 2019 · 7 comments
Labels
kind/doc lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale.
Milestone

Comments

@n3wscott
Copy link
Contributor

I am fairly confused on how we eventing plans to use service accounts and roles. This came up because I was unable to get broker to work without creating a service account and role in my namespace but there was already a cluster role for a service account that does not get installed as part of the normal process.

We need to give a story how we are managing these and when we make a new one.

@n3wscott
Copy link
Contributor Author

@Harwayne
Copy link
Contributor

I think this needs to be more specific. What do you want documented and where?

I believe this came from working with #788 (specifically this comment), so the way Broker & Trigger use ServiceAccounts and RBAC.

You are correct that this is a bug that the Broker says it is ready before its constituent pieces say they are ready, that should be fixed.

But for documentation, that PR did include documentation about exactly what was needed and why: manual setup. Given that the readiness bug needs to be fixed in addition, where would you like to see the ServiceAccount and RBAC documentation put?

@evankanderson
Copy link
Member

Here's a user story and a success test for the contributor persona:

  • I can read a document in knative-eventing's /docs subtree and understand how ServiceAccounts and Roles are used by knative-eventing.
  • From the document, I can correctly predict for a given set of component installs: the number of ServiceAccounts, their names, and what permissions they have.

@evankanderson
Copy link
Member

/kind feature-request

@vaikas
Copy link
Contributor

vaikas commented May 10, 2019

Make this part of the required documentation overhaul for 0.6 release

@vaikas vaikas added this to the v0.9.0 milestone Aug 1, 2019
@akashrv
Copy link
Contributor

akashrv commented Sep 19, 2019

/milestone v0.10.0

@knative-prow-robot knative-prow-robot modified the milestones: v0.9.0, v0.10.0 Sep 19, 2019
@paulrossman paulrossman removed this from the v0.10.0 milestone Oct 30, 2019
@grantr grantr added this to the Backlog milestone Aug 24, 2020
matzew added a commit to matzew/eventing that referenced this issue Oct 27, 2020
* Separate e2e/conf tests

Signed-off-by: Matthias Wessendorf <mwessend@redhat.com>

* Tracing test.............

Signed-off-by: Matthias Wessendorf <mwessend@redhat.com>

* Removing the patch to skip those tests

Signed-off-by: Matthias Wessendorf <mwessend@redhat.com>
@github-actions
Copy link

This issue is stale because it has been open for 90 days with no
activity. It will automatically close after 30 more days of
inactivity. Reopen the issue with /reopen. Mark the issue as
fresh by adding the comment /remove-lifecycle stale.

@github-actions github-actions bot added the lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale. label Dec 26, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/doc lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale.
Projects
None yet
Development

No branches or pull requests

8 participants