Problem
We do not have a Duck type that represents a Channel, so you have to deal with Subscribable and Addressable. When dealing with Channel CRD you should just be able to deal with Channelable (Unless you're actually reifing one)
Persona:
System Integrator
Exit Criteria
When our reconcilers can use Channelable Duck Type to access / mutate channels and get their status properly without having to understand what Channel CRD they are operating on.
Time Estimate (optional):
2
Additional context (optional)
This came up in:
#1283
I think we should create a new Duck Type that looks something like this:
type Channelable struct {
metav1.TypeMeta ...
metav1.ObjectMeta ...
Spec ChannelSpec ...
Status Addressable ...
}
So that we have one Duck type that allows us to create Subscriptions to it as well get the Addressable part, since a Channel is both so rather than muck with addressable and subscribable, we have a proper Channelable type that handles spec / status. I think Addressable might not be enough, since we might also need some kind of Subscriptions statuses wired through. If you think this is reasonable, let's create an issue to track this, unless we think this change might be useful to do now.
@Harwayne @n3wscott
Problem
We do not have a Duck type that represents a Channel, so you have to deal with Subscribable and Addressable. When dealing with Channel CRD you should just be able to deal with Channelable (Unless you're actually reifing one)
Persona:
System Integrator
Exit Criteria
When our reconcilers can use Channelable Duck Type to access / mutate channels and get their status properly without having to understand what Channel CRD they are operating on.
Time Estimate (optional):
2
Additional context (optional)
This came up in:
#1283
I think we should create a new Duck Type that looks something like this:
type Channelable struct {
metav1.TypeMeta ...
metav1.ObjectMeta ...
Spec ChannelSpec ...
Status Addressable ...
}
So that we have one Duck type that allows us to create Subscriptions to it as well get the Addressable part, since a Channel is both so rather than muck with addressable and subscribable, we have a proper Channelable type that handles spec / status. I think Addressable might not be enough, since we might also need some kind of Subscriptions statuses wired through. If you think this is reasonable, let's create an issue to track this, unless we think this change might be useful to do now.
@Harwayne @n3wscott