Create v1beta1 types

[nachocano]

Problem
We need to start promoting stable APIs to v1beta1. This issue only involves adding the new types.

Persona:
Developer

Exit Criteria
Stable APIs have v1beta1 types

Additional context (optional)
knative/eventing#2414
knative/eventing#2407
knative/eventing#2466

[nachocano]

For workload identity we added a spec.serviceAccount field to all constructs. That refers to a google service account. @grac3gao proposed to use spec.googleServiceAccount, which is more accurate. I'm wondering if she was right. serviceAccount might be confusing with a typical k8s service account.

Might be worth thinking of what we should use spec.serviceAccount, spec.gsa or spec.googleServiceAccount. I'm currently more inclined for the second one spec.gsa

[nachocano]

my apologies, I was too optimistic, won't be able to make this in the three days I have remaining.
/unassign

[grac3gao-zz]

For workload identity we added a spec.serviceAccount field to all constructs. That refers to a google service account. @grac3gao proposed to use spec.googleServiceAccount, which is more accurate. I'm wondering if she was right. serviceAccount might be confusing with a typical k8s service account.

Might be worth thinking of what we should use spec.serviceAccount, spec.gsa or spec.googleServiceAccount. I'm currently more inclined for the second one spec.gsa

Have talked with Nacho under other thread. #692 (comment).

[Grace]
I am fine with gsa, but I am worried about that it might be too brief for user to understand? Perhaps gServiceAccount would be a choice?

[Nacho]
Yeah gsa might not be correct as well, and gServiceAccount sounds better. I
think we need a third opinion, maybe Adam?

@Harwayne would like to hear your opinions :)

[Harwayne]

For workload identity we added a spec.serviceAccount field to all constructs. That refers to a google service account. @grac3gao proposed to use spec.googleServiceAccount, which is more accurate. I'm wondering if she was right. serviceAccount might be confusing with a typical k8s service account.
Might be worth thinking of what we should use spec.serviceAccount, spec.gsa or spec.googleServiceAccount. I'm currently more inclined for the second one spec.gsa

Have talked with Nacho under other thread. #692 (comment).

[Grace]
I am fine with gsa, but I am worried about that it might be too brief for user to understand? Perhaps gServiceAccount would be a choice?

[Nacho]
Yeah gsa might not be correct as well, and gServiceAccount sounds better. I
think we need a third opinion, maybe Adam?

@Harwayne would like to hear your opinions :)

I tend to prefer longer, unambiguous names personally. My preferences from most liked to least are:

1. spec.googleServiceAccount
2. spec.gServiceAccount
3. spec.gsa
4. spec.serviceAccount (I really dislike this one for the reasons stated in Create v1beta1 types #614 (comment)).

[nachocano]

OK, then let's just call it googleServiceAccount or gServiceAccount. I think you can make the call @grac3gao. And my apologies, because you started with googleServiceAccount in the first place and I told you to change it... Once again, you were right :) Glad that we revisited this early enough...

[grac3gao-zz]

@nachocano No worries:) I created #723 to address it.

[nachocano]

One extra thing before moving to v1beta1, I think we need to rename our pubsub.cloud.google.com and messaging.cloud.google.com API groups to something like pubsub.events.cloud.google.com and messaging.events.cloud.google.com. If maintaining compatibility is too much work, then I'd suggest we just rename before 0.14 cuts, and properly document it in the release notes.
It'd be great if you can pull in Ron, just to confirm...