From 6351e055a3f5e9d958db70d5f283eab1676ee962 Mon Sep 17 00:00:00 2001 From: vishal Date: Thu, 21 May 2020 20:28:41 -0400 Subject: [PATCH] Improve connectivity debugging docs --- docs/cluster-management/update.md | 2 +- docs/guides/subdomain-https-setup.md | 18 +++++++++++++++++- 2 files changed, 18 insertions(+), 2 deletions(-) diff --git a/docs/cluster-management/update.md b/docs/cluster-management/update.md index 4f463768a7..5e2b5a9793 100644 --- a/docs/cluster-management/update.md +++ b/docs/cluster-management/update.md @@ -35,4 +35,4 @@ cortex cluster up In production environments, you can upgrade your cluster without downtime if you have a service in front of your Cortex cluster (for example, you can [configure API Gateway as a proxy service](../guides/api-gateway.md)): first spin up your new cluster, then update your client-facing service to route traffic to your new cluster, and then spin down your old cluster. -If you've set up HTTPS by specifying an SSL Certificate for a subdomain in your cluster configuration, you can upgrade your cluster with minimal downtime: first spin up a new cluster, then update the A record in your subdomain hosted zone to point to the API loadbalancer of your new cluster. Wait at least 60 seconds before spinning down the old cluster because DNS entries for loadbalancers refresh every 60 seconds (see [here](https://docs.aws.amazon.com/elasticloadbalancing/latest/userguide/how-elastic-load-balancing-works.html#request-routing) for more details). +If you've set up HTTPS by specifying an SSL Certificate for a subdomain in your cluster configuration, you can upgrade your cluster with minimal downtime: first spin up a new cluster, then update the A record in your subdomain hosted zone to point to the API loadbalancer of your new cluster. Wait at least a 24 to 48 hours before spinning down your old cluster to allow old DNS cache to be flushed. diff --git a/docs/guides/subdomain-https-setup.md b/docs/guides/subdomain-https-setup.md index 1bc8dffa12..7a27817488 100644 --- a/docs/guides/subdomain-https-setup.md +++ b/docs/guides/subdomain-https-setup.md @@ -130,7 +130,7 @@ Go to the hosted zone you created in the [Route 53 console](https://console.aws. ### Using your new endpoint -You may now use your subdomain in place of your API load balancer endpoint in your client. For example, this curl request: +Wait a few minutes to allow the DNS changes to propagate. You may now use your subdomain in place of your API load balancer endpoint in your client. For example, this curl request: ```bash curl http://a5044e34a352d44b0945adcd455c7fa3-32fa161d3e5bcbf9.elb.us-west-2.amazonaws.com/iris-classifier -X POST -H "Content-Type: application/json" -d @sample.json @@ -139,9 +139,25 @@ curl http://a5044e34a352d44b0945adcd455c7fa3-32fa161d3e5bcbf9.elb.us-west-2.amaz Would become: ```bash +# replace loadbalancer url with your subdomain curl https://api.cortexlabs.dev/iris-classifier -X POST -H "Content-Type: application/json" -d @sample.json ``` +### Debugging connectivity issues + +You may encounter connectivity issues due to cached DNS records that haven't expired yet. It could take anywhere from a few minutes to 48 hours for DNS cache to completely refresh. + +You could run into connectivity issues if you make a request to your API without waiting long enough after step 17. + +To test connectivity try the following steps: +1. Deploy any api (e.g. iris-classifier). +1. Make an HTTPS GET request to the your api e.g. `curl https://api.cortexlabs.dev/iris-classifier` or enter the url in your browser. +1. If you run into an error such as `curl: (6) Could not resolve host: api.cortexlabs.dev` wait a few minutes and make the HTTPS Get request from another device that hasn't made a request to that url in a while. A successful request looks like this: +``` +{"message":"make a prediction by sending a post request to this endpoint with a json payload",...} +``` + + ### Cleanup Spin down your Cortex cluster.