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

[v2] connector status not populated #1732

Open
nluaces opened this issue Oct 17, 2024 · 2 comments
Open

[v2] connector status not populated #1732

nluaces opened this issue Oct 17, 2024 · 2 comments
Assignees

Comments

@nluaces
Copy link
Member

nluaces commented Oct 17, 2024

Describe the bug
After creating a connector the STATUS field (the one that is printed) is not populated. The fields related with the conditions are populated correctly.

How To Reproduce
Steps to reproduce the behavior:
1- create a connector
2- check its status with kubectl or the CLI.

Expected behavior
If the connector was created successfully it should show "OK" on the status field.

Additional context

$ kubectl get connectors -A                                                                                                                                                        
NAMESPACE   NAME       ROUTING KEY   PORT   HOST   SELECTOR      STATUS   MATCHING LISTENER COUNT
east        backend    backend       8080          app=backend            
east        backend2   backend       8080          app=backend            
east        backend3   backend3      8080          app=backend        
kubectl describe connector backend3 -n east                                                                                                                                      
Name:         backend3
Namespace:    east
Labels:       <none>
Annotations:  <none>
API Version:  skupper.io/v1alpha1
Kind:         Connector
Metadata:
  Creation Timestamp:  2024-10-17T15:03:52Z
  Generation:          1
  Managed Fields:
    API Version:  skupper.io/v1alpha1
    Fields Type:  FieldsV1
    fieldsV1:
      f:status:
        .:
        f:conditions:
    Manager:      controller
    Operation:    Update
    Subresource:  status
    Time:         2024-10-17T15:03:52Z
    API Version:  skupper.io/v1alpha1
    Fields Type:  FieldsV1
    fieldsV1:
      f:spec:
        .:
        f:port:
        f:routingKey:
        f:selector:
        f:type:
    Manager:         skupper
    Operation:       Update
    Time:            2024-10-17T15:03:52Z
  Resource Version:  955
  UID:               109830fb-f86e-419a-b837-c82d1e992cad
Spec:
  Port:         8080
  Routing Key:  backend3
  Selector:     app=backend
  Type:         tcp
Status:
  Conditions:
    Last Transition Time:  2024-10-17T15:03:52Z
    Message:               OK
    Observed Generation:   1
    Reason:                OK
    Status:                True
    Type:                  Configured
Events:                    <none>
@grs
Copy link
Member

grs commented Oct 17, 2024

At present the status is only set to OK when ready and the connector is only ready when configured and matched. So the behaviour observed is what the code is currently 'supposed' to do.

I guess the question is how the status message should be set. One option would be to set a message that indicates any unmet conditions if the resource is not ready. E.g. in this case a status of 'not matched' or similar. Thoughts?

@nluaces
Copy link
Member Author

nluaces commented Oct 17, 2024

That sounds good to me. I ran into this by trying two cases:

  1. Creating a connector with a site.
  2. Creating a connector without having a site in place. Because there is no router created to configure a connector, the connector never reaches the condition of "Configured" and (in this case) the CLI times out. The status is also empty.

A not matched status is correct in both cases, is a way to inform the user that at least the resource was created with no issues. I still think that the second case is different, but perhaps the CLI should be more verbose about it ("the connector will not be configured until a site is created") and also it should not wait for a given status.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants