Record and display count of entrypoint config connections in deployment status report

[catsby]

This PR adds the count of entrypoint connections streaming configuration updates per deployment to deployment status reports. At this time there is no practical way of correlating the gRPC connection to a specific instance or pod in a deployment, so for now we simply display the current count of connections.

There are some caveats or limitations here:

• To my knowledge this is the only situation where we include information from the Waypoint server into a status report of a deployment/app/project. We do this by first generate a status report, the logic for which is implemented in the plugins and executed by a runner. After completion we capture the report and add the count by querying the instances for a deployment from the Waypoint server, and then modify the status report and re-upsert it with the count. The approach taken is a bit naive and a little brute force-ish for now, and only applies to status reports for deployments (not releases, etc). If we decide to include future metrics from the Waypoint server in status reports, we may want to consider a more elegant/flexible solution that could work for all report types, but for now we don't anticipate any more additions.
• As mentioned we have no easy way of correlating a instance recorded on the server as receiving entrypoint configuration updates and say a specific pod in a deployment, so at this time we can't deduce which pods are connected and which are not.
• The server doesn't immediately know how many deployment "instances" there should be, as things like replica_count are handled by the plugin.
• The burden is unfortunately left to the user to know if the count is correct, but hopefully surfacing the count can be a helpful indicator in debugging applications
• Extracting information about Entrypoint being disabled, either by using disable_entrypoint in the build or by using the environment variable WAYPOINT_CEB_DISABLE was rather difficult, so I settled with displaying the count for now. Perhaps a follow up PR could come with this information after I circle back internally and this PR is reviewed.

Example of output before this change:

» Deployment Summary
APP NAME        VERSION WORKSPACE       PLATFORM        ARTIFACT        LIFECYCLE STATE
web             v5      default         kubernetes      id:5            SUCCESS

After:

» Deployment Summary
APP NAME        VERSION WORKSPACE       PLATFORM        ARTIFACT        LIFECYCLE STATE ENTRYPOINT CONNECTIONS
web             v1      default         kubernetes      id:1            SUCCESS         1

Full output:

Current status for application "web" in project "nginx-project" in server context "localhost:9701".

» Application Summary
APP     WORKSPACE       DEPLOYMENT STATUS       DEPLOYMENT CHECKED      RELEASE STATUS  RELEASE CHECKED
web     default         ✔ READY                 now                     ✔ READY         now


» Deployment Summary
APP NAME        VERSION WORKSPACE       PLATFORM        ARTIFACT        LIFECYCLE STATE ENTRYPOINT CONNECTIONS
web             v1      default         kubernetes      id:1            SUCCESS         1


» Deployment Resources Summary
TYPE            NAME                    PLATFORM        HEALTH  TIME CREATED
deployment      web-v1                  kubernetes      READY   31 seconds ago
pod             web-v1-77d95c4cd-b74t2  kubernetes      READY   31 seconds ago


» Release Summary
APP NAME        VERSION WORKSPACE       PLATFORM        ARTIFACT        LIFECYCLE STATE
web             v1      default         kubernetes      id:1            SUCCESS


» Release Resources Summary
TYPE    NAME    PLATFORM        HEALTH  TIME CREATED
service web     kubernetes      READY   19 seconds ago

[evanphx]

My only comment is if we should call this entrypoint. I'd probably call it instance.

[briancain]

Looks good to me! I wrote out a question that we both had that hopefully the team can think about and answer. Otherwise makes sense 😄

[briancain]

We had a question here for the wider team - It would be nice if Status Reports had some kind of pre-Upsert hook for adding information like active entrypoint connections to a report that a plugin typically wouldn't have access to at the time the Status Report is generated. @catsby and I figured for now since it's just one extra piece of data, it's probably OK to do a double Upsert and append this data later after the plugin has already upserted its report.

In the future though, it would be nice if we had something a bit more generic in place with our system to add data like this. But if someone has a good idea of how to easily achieve that, we're all ears!

Finally - maybe a double Upsert isn't a huge deal here if the cost is low to modify an existing report in the db with a little bit of extra information here.

[catsby]

My only comment is if we should call this entrypoint. I'd probably call it instance.

@evanphx I can see the reasoning behind this. On the other hand, this count represents the number of instances that have established a connection with the Waypoint server. If for instance there's an issue and the entrypoint cannot connect to the Waypoint server (firewall rules, et. al.) then the count would be zero, which could imply that no instances are running. Does that make sense?

[izaaklauer]

This looks great!

In the future, it would be nice to build on this this to change the status report's overall health if we don't have instances and shouldn't have instances. I don't think many new users will know enough to check that field under status reports and recognize it means they need to look at their firewall rules.

Totally recognize "shouldn't" is the hard part - there are multiple ways to disable the CEB (at build-time or deploy-time), and they aren't all visible to us now at this point where we're adding the connected instance count.

[mitchellh]

I would just name this instances_count cause that's what we're measuring. If we change how we measure that in the future its less leaky than "entrypoint config connections."

[hashicorp-cla]

All committers have signed the CLA.