operate-first / support

This repo should serve as a central source for users to raise issues/questions/requests for Operate First.
GNU General Public License v3.0
15 stars 25 forks source link

Deploy triage party and add webinar issues #998

Closed HumairAK closed 2 years ago

HumairAK commented 2 years ago

Identify which cluster to deploy triage-party, deploy it there, then add the webinar issues to this if done before webinar deadline.

HumairAK commented 2 years ago

@4n4nd can you update the body of OP to add the webinar issues that should be added.

HumairAK commented 2 years ago

@codificat it seems you are not yet a member of this org, you can make a pr like the one here to add your self to the org (instead of contributors-core it will be triagers see here ), once you are added I can assign you to this issue.

codificat commented 2 years ago

@codificat it seems you are not yet a member of this org, you can make a pr like the one here to add your self to the org (instead of contributors-core it will be triagers see here ), once you are added I can assign you to this issue.

will do, thanks.

Meanwhile, I found that https://github.com/thoth-station/thoth-application/issues/1969 existed, suggesting to deploy to rick

HumairAK commented 2 years ago

nice, @goern can you elaborate on whether this instance can be shared, or is it better to have separate deployments?

codificat commented 2 years ago

@codificat it seems you are not yet a member of this org,

Fixed :partying_face: so, /assign @codificat

I have a question, to make sure I'm not missing something here:

add the webinar issues to this if done before webinar deadline.

What repo(s) would cover all these issues?

4n4nd commented 2 years ago

@codificat this covers all the issues added to this board: https://github.com/orgs/operate-first/projects/39

codificat commented 2 years ago

I have questions / comments about:

nice, @goern can you elaborate on whether this instance can be shared, or is it better to have separate deployments?

Technically yes, we can configure the instance to include all the repos we want (Thoth, AICoE, Operate First...). The question is if that makes sense, because this results in all issues/PRs from all repos mixed in the same views. There is no way to filter by org/repo.

So: should we have separate deployments for separate teams? How do we handle overlapping teams?

@codificat this covers all the issues added to this board: https://github.com/orgs/operate-first/projects/39

This seems to be related to only one repo, hitchhikers-guide, which currently only has 11 open issues. This could/should be part of an operate-first-focused triage-party instance, right?

In summary, let's decide:

HumairAK commented 2 years ago

which instances to deploy

Okay so how about one for thoth and operate-first? Not sure if we need one for AICoE yet or how that would work.

what repos should be covered by each instance

For operate-first, all repos in the operate-first org. I'll let Thoth members comment on their instance.

schwesig commented 2 years ago

These were the ones mentioned in the discussion and set up in my local installation/test

WorkshopBonn_2021-09-21.pdf

4n4nd commented 2 years ago

This could/should be part of an operate-first-focused triage-party instance, right?

Yes

Okay so how about one for thoth and operate-first? Not sure if we need one for AICoE yet or how that would work.

Let's do one instance per github org?

codificat commented 2 years ago

Let's do one instance per github org?

Ok. Will use that one to track the operate-first instance, and https://github.com/thoth-station/thoth-application/issues/1969 for the thoth instance.

I'm still catching up on how to do this properly (please bear with me :innocent: ) but for now I believe I will need two things that I'm not sure about:

HumairAK commented 2 years ago

@codificat the backing storage shouldn't be relevant, these details are abstracted from the pod, which only sees pvcs, you just mount the pvcs to a certain path in the pod and point the cache there.

which github token to use: can you point me to an existing secret? or do we need to create one for this app?

For operate-first we have recently created a bot account for gh access tokens, if you can let me know the scope for this token I can create it and send it over to you over DM.

which cluster to target

let's try putting it on smaug

codificat commented 2 years ago

@codificat the backing storage shouldn't be relevant, these details are abstracted from the pod, which only sees pvcs, you just mount the pvcs to a certain path in the pod and point the cache there.

Sure. In other words, then: I should not specify any storage class in my PVC definition.

For operate-first we have recently created a bot account for gh access tokens, if you can let me know the scope for this token I can create it and send it over to you over DM.

According to the triage-party requirements, it's a GitHub API token with public_repo permissions (read-only).

let's try putting it on smaug

Ok :+1:

Also: will use triage-party.operate-first.cloud for routing, which is already set up to point to smaug.

HumairAK commented 2 years ago

Sure. In other words, then: I should not specify any storage class in my PVC definition.

yeah the nfs server should be the default storage class

According to the triage-party requirements, it's a GitHub API token with public_repo permissions (read-only).

kk