LexFloatServer log and API enhancements

Floating Licenses
#1
  1. Log output enhancement: similar to how a successful floating license request is followed by a “nnn licenses available” message in the log, follow successful meter attribute increment and decrement requests with a report of the TotalUses value for that meter attribute. This would help to monitor the use of meters and compare high water mark usage to the AllowedUses count provided in the license.
  2. API enhancement: add a GET request that returns the AllowedUses and TotalUses values for meter attributes. It would be nice if we could make a call to get the stats for all meter attributes or for a specific meter attribute. The use case for this is a user who wants to be sure that all required meter attributes are available before starting a program run. Think of a queuing system, where you don’t want to start a queued job if it is going to fail immediately because the license features it needs are already in use by another process.
#2

Hi Gary,

Thanks for the feedback.

These seem to be useful enhancements. We will add these to the LexFloatserver.

Will keep you posted.

#3

Thanks Adnan.
To clarify request 1, printing both AllowedUses and TotalUses in the log would be helpful so that when parsing the log you don’t need to also query the server to find AllowedUses.

#4

One extra request for the log. We write the user’s name into the activation metadata because it is useful to some of our customers to track who is using particular entitlements. We can extract this custom metadata from the cloud license logs, but it doesn’t appear in the LexFloatServer log output. It would be helpful to us if SetFloatingClientMetadata generates a log entry that prints out the metadata (referenced by the activation uuid so that we can match it to a specific activation).

#5

There could be a lot of activation metadata fields, and logging every field with the log is not practical.

#6

Any news on the two enhancements you thought were sensible?

#7

Both of these features will be incorporated into LexFloatServer by the end of this month.

#8

Brilliant, thank you!

#9

Can you share a development progress update? Are you on target for the end of September?

Thanks,
Gary

#10

It’s a bit naughty to send this so late, but these are the kind of API calls that would let us query everything we need from the server.

  1. <api>/metadata - return json blob of all metadata keys and values. Bonus feature would be the ability to query an individual metadata item by adding ?id=uuid or ?key=<metadata_key_name>

  2. <api>/meter-attributes - return json blob of all meter attributes and values. Bonus feature would be the ability to query an individual meter attribute by adding ?id=uuid or ?name=meter_attribute_name

  3. <api>/activations - return json blob of all activations, with all the data that the web view shows plus any custom metadata the activating program has provided. The web view should be fixed to show the latter as well because currently it does not (v4.9.2). The activation data should also track the meter attribute increments owned by each activation so that we have the ability to find out who is using particular license features.

#11

Hi Gary,

We are pleased to inform you that we have successfully implemented the requested features, and we’re excited to share the beta release with you tomorrow. We’ve been diligently working to ensure that these enhancements align with your needs and expectations.

We already have an endpoint /api/floating-licenses which serves the same purpose as requested in 3 except that it does not include the meter attribute count.

Regarding your recent message about the additional API calls and feature requests, we greatly appreciate your continued engagement and valuable input. While we understand the importance of these requests, we want to be transparent and acknowledge that they may not be feasible with the current iteration. Rest assured, we are actively taking note of these suggestions for consideration in our next development cycle.

Your feedback is invaluable to us, and we remain committed to delivering the best possible solutions for your requirements.

Regards,
Ahmad.

#12

Thank you. I very much look forward to trying out the beta. Assuming it all works, we can let you know whether we really need the additional stuff.
Can you confirm whether the beta also addresses the license expiry issue I reported?

#13

Can you confirm whether the beta also addresses the license expiry issue I reported?

I assume you are referring to this post where you mentioned that some(a few hundred out of 7000) clients failed to renew the license.

It is important to convey that the remedy for this issue has been incorporated into the beta build. However, it is worth noting that comprehensive testing for certain specific scenarios remains pending. We will ensure to keep you updated on this.

#14

Hi Gary,

Please download the LexFloatServer beta build from the link below:

This build addresses the issue of license renewal failure. Please make sure to add leaseDurationGracePeriod in the config.yml file. This can have values between 15-60 (secs). For your use case set its value to 60. In case you are sending requests to LexFloatServer using the LexFloatClient make sure to update the LexFloatClient to the latest version as well.

This build includes the /api/server/license-meter-attributes endpoint for retrieving license meter attributes.

Also, the logging has been improved as well.

Regards,
Ahmad.

#15

Thank you Ahmad. We will try to test this as soon as possible.