Change Details

Our `GET /environments` endpoint accepts an optional `latestStatus=true` query argument that can be used to make Catalyst reach out to the cluster and refresh the environment's status with the most recent real state. This argument is useful e.g. when Patchdemo retrieves all of its Catalyst wikis on a page load. However Patchdemo is not using the argument at the moment as it adds ~12s to the request in production. After a couple of failed attempts at optimizing the operation, it turned out the main bottleneck was that the multiples request from Catalyst to K3s are eventually throttled by the cluster. A better approach in this case than polling for changes would be to have push events. The `client-go` library we are using to talk to K3s has the concept of "informers", which it seems we can use to add lifecycle hooks to our deployments. Those hooks can then notify Catalyst once a deployment is up and running, or when it goes down: https://medium.com/@jeevanragula/demystifying-kubernetes-informer-streamlining-event-driven-workflows-955285166993 Note that `GET /environments/:id` also accepts `latestStatus` but in that case we probably keep the argument around as a fallback mechanism to get the actual running state of a particular environment in case there are issues with the cluster.

Our `GET /environments` endpoint accepts an optional `latestStatus=true` query parameter that can be used to make Catalyst reach out to the cluster and refresh the environment's status with the most recent real state. This parameter is useful e.g. when Patchdemo retrieves all of its Catalyst wikis on a page load. However Patchdemo is not using the parameter at the moment as it adds ~12s to the request in production. After a couple of failed attempts at optimizing the operation, it turned out the main bottleneck was that the multiples request from Catalyst to K3s are eventually throttled by the cluster. The A better approach in this case than polling for changes would be to have push events. The `client-go` library we are using to talk to K3s has the concept of "informers", which it seems we can use to add lifecycle hooks to our deployments. Those hooks can then notify Catalyst once a deployment is up and running, or when it goes down: https://medium.com/@jeevanragula/demystifying-kubernetes-informer-streamlining-event-driven-workflows-955285166993. At that point we can remove `latestStatus` from `GET /environments`. Note that `GET /environments/:id` also accepts `latestStatus` but in that case we probably keep the parameter around as a fallback mechanism to get the actual running state of a particular environment in case there are issues with the cluster.

Our `GET /environments` endpoint accepts an optional `latestStatus=true` query argumentparameter that can be used to make Catalyst reach out to the cluster and refresh the environment's status with the most recent real state. This argumentparameter is useful e.g. when Patchdemo retrieves all of its Catalyst wikis on a page load. However Patchdemo is not using the argumentparameter at the moment as it adds ~12s to the request in production. After a couple of failed attempts at optimizing the operation, it turned out the main bottleneck was that the multiples request from Catalyst to K3s are eventually throttled by the cluster. The A better approach in this case than polling for changes would be to have push events. The `client-go` library we are using to talk to K3s has the concept of "informers", which it seems we can use to add lifecycle hooks to our deployments. Those hooks can then notify Catalyst once a deployment is up and running, or when it goes down: https://medium.com/@jeevanragula/demystifying-kubernetes-informer-streamlining-event-driven-workflows-955285166993. it turned ouAt the main bottleneck was that the multiples request from Catalyst to K3s are eventually throttled by the clusterat point we can remove `latestStatus` from `GET /environments`. A better approach in this case than polling for changes would be to have push events. The `client-go` library we are using to talk to K3s has the concept of "informers", which it seems we can use to add lifecycle hooks to our deployments. Those hooks can then notify Catalyst once a deployment is up and running, or when it goes down: https://medium.com/@jeevanragula/demystifying-kubernetes-informer-streamlining-event-driven-workflows-955285166993 Note that `GET /environments/:id` also accepts `latestStatus` but in that case we probably keep the argumentparameter around as a fallback mechanism to get the actual running state of a particular environment in case there are issues with the cluster.