Feature #2612

Frontend should advertise its monitoring URL to factory

Added by Burt Holzman over 8 years ago. Updated over 8 years ago.

Douglas Strain
Target version:
Start date:
Due date:
% Done:


Estimated time:


An Igor idea: the frontend could advertise its monitoring URL via another attribute in the ClassAd to the factory.

Related issues

Related to GlideinWMS - Feature #2858: Linking Frontend monitoring from Factory monitoringClosed07/30/2012


#1 Updated by Douglas Strain over 8 years ago

This is commited to branch_v2plus (175dd78). Next up, transferring to master branch.

#2 Updated by Igor Sfiligoi over 8 years ago

Looked at the patch, and I don't like it a bit.

Do you really must put this in the XML file?
It will make upgrades miserable.

Plus, how do we make sure the value there is actually reasonable?
For the stage area, it is easy; things will catastrophically fail, but for monitoring?

Plus, complaint #2;
you changed the interface to the functions in

That module is used by other products, e.g. the glideTester,
so your change will likely break that.
Please re-factor the code so that this new parameter is optional, for backwards compatibility.

#3 Updated by Igor Sfiligoi over 8 years ago

Plus, it is not integrated with the installer, so the field in the XML file will likely be the default, which has no guarantee to be the right one.

#4 Updated by Douglas Strain over 8 years ago

Ok... well, where else can we put it besides XML? We can't harvest this automatically, since the web server could be on a NFS share and on a different machine. Did you want to hack it out of the stage Web URL (ie MonitoringUrl = stage URL with s/stage/monitor/)? That seems like a hack. I am open to suggestions.

I also see only one reference to the descript function in branch_v2plus
[dstrain@dhcp-131-225-82-134 glideinwms]$ find . -exec grep glideinFrontendInterface.FrontendDescript \{\} \; -print

What is glideTester? I've never heard of that.

#5 Updated by Igor Sfiligoi over 8 years ago

First, about the
Let me repeat it: it should be considered a library module, which can be used by others.
So any change must be backwards compatible.

As for the XML, I agree it would be nice to have a way to provide a different location, if needed;
but we must not make upgrades a pain.
Plus, we need integration with the installer, too.

An easy way to achieve this would be to derive the monitor.web_base out of stage.web_base;
99+% of the time they are very close to one another.
Until we have a proper integration with the installer, I would do this derivation in the code, without exposing it to the user.

Afterwards, we just need a good default.
(i.e. same thing, but actually written back into the xml file)

#6 Updated by Douglas Strain over 8 years ago

I have added the changes in branch_v2plus_2612. They are tested in RPM and tarball versions. The new implementation is the following:

- monitoring web url can be specified in XML: <monitor ... web_base_url="..." />
- If none is specified, it uses the stage web_base_url with "stage" replaced by "monitor"
- XML does not write this back to the original XML or require a value.
- It is pushed to the factory in glideclient classad as the WebMonitoringURL.

Will this suffice?

#7 Updated by Douglas Strain over 8 years ago

Oh, also, about glideinFrontendInterface changes. There are changes, but the only change is the addition of an accessor function to add the monitoring web url. The init and all other interfaces are left unchanged. If the accessor is not called, the default is the stage url with "monitor" replaced for "stage".

#8 Updated by Igor Sfiligoi over 8 years ago

  • Status changed from New to Accepted

Yes, the code changes look good.


#9 Updated by Douglas Strain over 8 years ago

  • Status changed from Accepted to Resolved

This code has been merged in.

#10 Updated by Parag Mhashilkar over 8 years ago

  • Target version changed from v2_7_x to v2_6

#11 Updated by Parag Mhashilkar over 8 years ago

  • Status changed from Resolved to Closed

Also available in: Atom PDF