We noticed when deploying metric collective to windows test slaves, that fqdn names used in the metric path were inconsistent. Some would be all UPPER case and others were all lower case. This was really a pain then the difference showed up between 2008rev1 and 2008rev2 slaves. I've patched metric collective to convert fqdn to lower so we should upgrade all the releng windows systems ASAP. This will cause new db files to be created. Since graphte6 handled the new DB creates during the first deploy, I don't think we need to pace the upgrades this time around. Upgrading this should be straight forward. * stop metcollect service * update metcollect.py * start metcollect service After that we can go back and delete all the stale db files. Q, Mark: I'll need your input on how to properly proceed on upgrading.
I think we can just edit the existing GPO. First we will need to replace the source file metcollect.py and change the file copy in the gpo to replace instead of create. Then we can either wait on the next reboot for the service to stop and start, or we can come up with an immediate task some type of item level targeting to trigger the service stop and start. Q, do you have a suggestion on another way to approach this?
Per IRC, Mark will be updating the metcollect.py on all releng windows hosts today. This will cause creates on graphite6 for any hosts that was previously reporting in with a hostname in UPPER case.
Do we need to worry about this on rev1 builders ?
(In reply to Q from comment #3) > Do we need to worry about this on rev1 builders ? Yes. This needs to be applied to all releng windows systems currently deployed with Metrics Collective
There are no more rev1 builders as of bug 975131.
Status: NEW → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.