Subscribe is the Schema for the Subscribes API. Provides a resource to create a tcmq subscribe
Type
CRD
Group
tcmq.tencentcloud.crossplane.io
Version
v1alpha1
apiVersion: tcmq.tencentcloud.crossplane.io/v1alpha1
kind: Subscribe
SubscribeSpec defines the desired state of Subscribe
No description provided.
The number of BindingKey cannot exceed 5, and the length of each BindingKey cannot exceed 64 bytes. This field indicates the filtering policy for subscribing to and receiving messages. Each BindingKey includes up to 15 dots (namely up to 16 segments).
The number of BindingKey cannot exceed 5, and the length of each BindingKey cannot exceed 64 bytes. This field indicates the filtering policy for subscribing to and receiving messages. Each BindingKey includes up to 15 dots (namely up to 16 segments).
Reference to a Queue to populate endpoint.
Policies for referencing.
Selector for a Queue to populate endpoint.
Policies for selection.
Message body tag (used for message filtering). The number of tags cannot exceed 5, and each tag can contain up to 16 characters. It is used in conjunction with the MsgTag parameter of (Batch)PublishMessage. Rules: 1. If FilterTag is not configured, no matter whether MsgTag is configured, the subscription will receive all messages published to the topic; 2. If the array of FilterTag values has a value, only when at least one of the values in the array also exists in the array of MsgTag values (i.e., FilterTag and MsgTag have an intersection) can the subscription receive messages published to the topic; 3. If the array of FilterTag values has a value, but MsgTag is not configured, then no message published to the topic will be received, which can be considered as a special case of rule 2 as FilterTag and MsgTag do not intersect in this case. The overall design idea of rules is based on the intention of the subscriber.
Message body tag (used for message filtering). The number of tags cannot exceed 5, and each tag can contain up to 16 characters. It is used in conjunction with the MsgTag parameter of (Batch)PublishMessage. Rules: 1. If FilterTag is not configured, no matter whether MsgTag is configured, the subscription will receive all messages published to the topic; 2. If the array of FilterTag values has a value, only when at least one of the values in the array also exists in the array of MsgTag values (i.e., FilterTag and MsgTag have an intersection) can the subscription receive messages published to the topic; 3. If the array of FilterTag values has a value, but MsgTag is not configured, then no message published to the topic will be received, which can be considered as a special case of rule 2 as FilterTag and MsgTag do not intersect in this case. The overall design idea of rules is based on the intention of the subscriber.
Reference to a Topic to populate topicName.
Policies for referencing.
Selector for a Topic to populate topicName.
Policies for selection.
THIS IS A BETA FIELD. It will be honored unless the Management Policies feature flag is disabled. InitProvider holds the same fields as ForProvider, with the exception of Identifier and other resource reference fields. The fields that are in InitProvider are merged into ForProvider when the resource is created. The same fields are also added to the terraform ignore_changes hook, to avoid updating them after creation. This is useful for fields that are required on creation, but we do not desire to update them after creation, for example because of an external controller is managing them, like an autoscaler.
The number of BindingKey cannot exceed 5, and the length of each BindingKey cannot exceed 64 bytes. This field indicates the filtering policy for subscribing to and receiving messages. Each BindingKey includes up to 15 dots (namely up to 16 segments).
The number of BindingKey cannot exceed 5, and the length of each BindingKey cannot exceed 64 bytes. This field indicates the filtering policy for subscribing to and receiving messages. Each BindingKey includes up to 15 dots (namely up to 16 segments).
Reference to a Queue to populate endpoint.
Policies for referencing.
Selector for a Queue to populate endpoint.
Policies for selection.
Message body tag (used for message filtering). The number of tags cannot exceed 5, and each tag can contain up to 16 characters. It is used in conjunction with the MsgTag parameter of (Batch)PublishMessage. Rules: 1. If FilterTag is not configured, no matter whether MsgTag is configured, the subscription will receive all messages published to the topic; 2. If the array of FilterTag values has a value, only when at least one of the values in the array also exists in the array of MsgTag values (i.e., FilterTag and MsgTag have an intersection) can the subscription receive messages published to the topic; 3. If the array of FilterTag values has a value, but MsgTag is not configured, then no message published to the topic will be received, which can be considered as a special case of rule 2 as FilterTag and MsgTag do not intersect in this case. The overall design idea of rules is based on the intention of the subscriber.
Message body tag (used for message filtering). The number of tags cannot exceed 5, and each tag can contain up to 16 characters. It is used in conjunction with the MsgTag parameter of (Batch)PublishMessage. Rules: 1. If FilterTag is not configured, no matter whether MsgTag is configured, the subscription will receive all messages published to the topic; 2. If the array of FilterTag values has a value, only when at least one of the values in the array also exists in the array of MsgTag values (i.e., FilterTag and MsgTag have an intersection) can the subscription receive messages published to the topic; 3. If the array of FilterTag values has a value, but MsgTag is not configured, then no message published to the topic will be received, which can be considered as a special case of rule 2 as FilterTag and MsgTag do not intersect in this case. The overall design idea of rules is based on the intention of the subscriber.
Reference to a Topic to populate topicName.
Policies for referencing.
Selector for a Topic to populate topicName.
Policies for selection.
THIS IS A BETA FIELD. It is on by default but can be opted out through a Crossplane feature flag. ManagementPolicies specify the array of actions Crossplane is allowed to take on the managed and external resources. This field is planned to replace the DeletionPolicy field in a future release. Currently, both could be set independently and non-default values would be honored if the feature flag is enabled. If both are custom, the DeletionPolicy field will be ignored. See the design doc for more information: https://github.com/crossplane/crossplane/blob/499895a25d1a1a0ba1604944ef98ac7a1a71f197/design/design-doc-observe-only-resources.md?plain=1#L223 and this one: https://github.com/crossplane/crossplane/blob/444267e84783136daa93568b364a5f01228cacbe/design/one-pager-ignore-changes.md
ProviderConfigReference specifies how the provider that will be used to create, observe, update, and delete this managed resource should be configured.
Policies for referencing.
PublishConnectionDetailsTo specifies the connection secret config which contains a name, metadata and a reference to secret store config to which any connection details for this managed resource should be written. Connection details frequently include the endpoint, username, and password required to connect to the managed resource.
WriteConnectionSecretToReference specifies the namespace and name of a Secret to which any connection details for this managed resource should be written. Connection details frequently include the endpoint, username, and password required to connect to the managed resource. This field is planned to be replaced in a future release in favor of PublishConnectionDetailsTo. Currently, both could be set independently and connection details would be published to both without affecting each other.
SubscribeStatus defines the observed state of Subscribe.
No description provided.
The number of BindingKey cannot exceed 5, and the length of each BindingKey cannot exceed 64 bytes. This field indicates the filtering policy for subscribing to and receiving messages. Each BindingKey includes up to 15 dots (namely up to 16 segments).
The number of BindingKey cannot exceed 5, and the length of each BindingKey cannot exceed 64 bytes. This field indicates the filtering policy for subscribing to and receiving messages. Each BindingKey includes up to 15 dots (namely up to 16 segments).
Message body tag (used for message filtering). The number of tags cannot exceed 5, and each tag can contain up to 16 characters. It is used in conjunction with the MsgTag parameter of (Batch)PublishMessage. Rules: 1. If FilterTag is not configured, no matter whether MsgTag is configured, the subscription will receive all messages published to the topic; 2. If the array of FilterTag values has a value, only when at least one of the values in the array also exists in the array of MsgTag values (i.e., FilterTag and MsgTag have an intersection) can the subscription receive messages published to the topic; 3. If the array of FilterTag values has a value, but MsgTag is not configured, then no message published to the topic will be received, which can be considered as a special case of rule 2 as FilterTag and MsgTag do not intersect in this case. The overall design idea of rules is based on the intention of the subscriber.
Message body tag (used for message filtering). The number of tags cannot exceed 5, and each tag can contain up to 16 characters. It is used in conjunction with the MsgTag parameter of (Batch)PublishMessage. Rules: 1. If FilterTag is not configured, no matter whether MsgTag is configured, the subscription will receive all messages published to the topic; 2. If the array of FilterTag values has a value, only when at least one of the values in the array also exists in the array of MsgTag values (i.e., FilterTag and MsgTag have an intersection) can the subscription receive messages published to the topic; 3. If the array of FilterTag values has a value, but MsgTag is not configured, then no message published to the topic will be received, which can be considered as a special case of rule 2 as FilterTag and MsgTag do not intersect in this case. The overall design idea of rules is based on the intention of the subscriber.
Conditions of the resource.
subscribe
apiVersion: tcmq.tencentcloud.crossplane.io/v1alpha1
kind: Subscribe
metadata:
annotations:
meta.upbound.io/example-id: tcmq/v1alpha1/subscribe
labels:
testing.upbound.io/example-name: subscribe
name: subscribe
spec:
forProvider:
endpointSelector:
matchLabels:
testing.upbound.io/example-name: queue
notifyContentFormat: SIMPLIFIED
protocol: queue
subscriptionName: subscription_name
topicNameSelector:
matchLabels:
testing.upbound.io/example-name: topic