[Feature request] Expose enterprise license expiration date

[kunisen]

Proposal

Use case. Why is this important?

Use case

Can we expose enterprise license expiration date into configmap elastic-licensing?

Why is this important?

Currently it looks like we have no direct way to know license expiration date of ECK enterprise license.

Per documentation,

Given Enterprise licenses are container licenses that include multiple licenses for individual Elasticsearch clusters with shorter expiry. Therefore, you will see a different expiry in Kibana or via the Elasticsearch _license API.

It would be quite useful if we could expose the enterprise license expiration date, when we run this:

kubectl -n elastic-system get configmap elastic-licensing -o json | jq .data

An expected result here could be:

{
  "eck_license_level": "enterprise",
  "enterprise_resource_units": "1",
  "max_enterprise_resource_units": "10",
  "timestamp": "2020-01-03T23:38:20Z",
  "total_managed_memory": "3.22GB",
  "expiry_date": "20xx-xx-xxT23:59:59.999Z"   <<=== we want to have this line
}

Workaround at this moment

The secret name eck-license is based on the documentation.

# First, get base64 encoded license data
kubectl -n elastic-system get secrets eck-license -o json | jq .data

# We get sth like this:
{
  "my-enterprise-license.json": "base64 encoded license string"
}

# Then, decode it and view
echo "base64 encoded license string" | base64 --decode

Environment

• ECK version:

1.8

• Kubernetes information:

Not related, but if needed, we use GKE.

Side note

Related ticket

#3973

Other good to have

It's also good to include this info in ECK-diagnostics.
But that's a different story and we will open another issue for this.

[bytebilly]

I fully support this request, as I'm getting more and more similar requests from customers.

I found a one-liner to get the date:

kubectl get secret eck-license -n elastic-system -o go-template='{{ range .data }}{{ . | base64decode }}{{end}}' | jq '.license.expiry_date_in_millis / 1000 | strftime("%Y-%m-%d")'

However, I strongly feel that this information is extremely useful in the default output of the configmap!