BUG: (P0) Vendor name is a required parameter in flxStatGetUserlist()

[jcheng]

Description:

We understand that this is the same as lc_init() + lc_userlist(), however is there a way for us to get the list of vendor names from lmgrd. Otherwise we will still be required to call lmstat at least once to get this information. Or, alternatively, remove the restriction altogether so we can simply specify the feature name, like lmstat -f <...>.

-Johnson

[greidplatform]

The original requirement was for a replacement for "lmstat" as an API call. What was proposed was effectively the equivalent to "lc_userlist" but for multiple vendor daemons.

What has been supplied requires us to have a complete mapping of vendor daemon to feature line which we don't currently require our users to supply.

We are hoping this is something that can be handled for two reasons:
1) "lmstat -f " does not require to specify the vendor daemon
2) Our previous alternative to lmstat based on the lc_userlist() also worked on multiple vendors while only calling lc_init with a single vendor daemon name (dummy effectively).

Therefore we don't believe the restriction needs to exist and it may represent serious impact if it does.

We would like to understand MV take on this.

Greg

[greidplatform]

Another possibility would be to supplement this by providing a way to get the associated vendor daemon to feature name mappings. Looking through the current APIs, I don't see any sort of way this is regularly provided so I imagine this is non-trivial work.

Greg

[davidz]

We'll have to follow-up with you on the options here.

[davidz]

In addition to adding two new fields, we had to meet two requirements: multi-vendor lc_userlist and maintain lc_userlist performance.

All requests from lc_userlist, lmstat, and flxStatGetUserlist go through lmgrd, and lmgrd must know which vendor daemon to dispatch the request to.

For lc_userlist, a vendor name is hardcoded into the object (because lc_userlist is built into the same object as lc_checkout/lc_checkin) and this hardcoded vendor name is passed to lmgrd. To support multi-vendor stat, we had to eliminate this hardcoding.

For lmstat, it has no hardcoded vendor name. Instead it communicates with lmgrd to find all the vendor daemons supported by lmgrd and asks each of these vendor daemons for the feature(s) is it looking for. This extra communication (one to list all the vendor daemons and two to ask each vendor daemon regardless of whether it supports the specific feature) contributes to the performance overhead of lmstat that we are trying to avoid.

For flxStatGetUserlist, we could not hardcode and did not want to do a vendor daemon discovery and iteration. Therefore, the only choice was to have the vendor name as a parameter.

Clearly this is different from the data required by lmstat or lc_userlist. However, I recall an early conversation in which we agreed that Macrovision could assume that Platform knew the features that were managed by LSF. Since a feature name is not enough to identify a feature (feature name and vendor name is), we felt that Platform would have this information easily available at the time flxStatGetUserlist needed to be called.

David

[davidz]

In a recent status email from Greg, the following suggested implementation appears in the spreadsheet row for this issue:

"If [the vendor name] is NULL, just return user list without considering vendor name which would be consistent with lmstat -f"

The implication of this suggestion is that lmstat -f will stop querying the remaining vendor daemons once it finds the first vendor daemon that has status for the feature specified by -f. However, I tested lmstat and determined that it iterates over all of the vendor daemons supported by lmgrd, even if the first vendor daemon has status for the feature specified by -f. I tested this by having one lmgrd start two different vendor daemons, each serving the same feature name (davidz:f1 and davidz2:f1). I found that lmstat -f f1 queries both servers, it does not stop upon finding davidz:f1.

By flxStatGetUserlist specifying a vendor name, lmgrd can dispatch the request directly to the appropriate vendor daemon.

We agree that lmstat does not require a vendor name, but its performance overhead for that privilege is too high.

[greidplatform]

This is an unfortunate result and will certain create work for us at a very late stage of development. We were hoping for some options but none have been presented.

Our hope lied in the fact that lc_userlist() back in v6 was returning features from other vendor daemon taking only "lm_job" and the feature. Although lm_job was initiallized with a specific vendor daemon, lc_userlist() ignored it and could return for any vendor daemon. Further this use did not incurr the overhead of lmstat therefore we concluded that vendor daemon was not fundamentally required for the lc_userlist() call and was only a limitation for security considerations.

Obvious much could have changed from v6 to the current v10 but we wanted to ensure that all the possibilities were examined. Are we certain we have explored all the options?

Last point, we are flexible when it comes to what the behaviour is when there are two features with the same name from different vendors. This rarely in our experience and I believe we could deal with it in whatever way the data was provided (special case).

We can discuss this further in todays meeting and try to reach a conclusion.

Greg

[davidz]

Last point, we are flexible when it comes to what the behaviour is when there are two features with the same name from different vendors. This rarely in our experience and I believe we could deal with it in whatever way the data was provided (special case).

Greg, I agree with this point. The test I mentioned which used the same feature name from two different vendors was done, not because I thought this is a common case, but it was the only way I knew to show that "lmstat -f f1" continues to query all servers, even though it finds status for f1 in a server prior to the last server.