|
|
| # | Tue Jun 03 14:22:18 2008 | garzoglio@fnal.gov - Ticket created | [Reply] | |||||||||||
Hi Burt, Alain, Burt Holzman wrote: > Hi GOC, > > We have noticed that the expiration for stale information in the ITB > BDII is 10 minutes. The CEMon interval by default is also set to 10 > minutes, which leads to sites flaking in and out of BDII. > > Could you increase the interval to something more reasonable (60 > minutes seems ok)? > > And Gabriele, is it ok to change the ce-monitor.xml update time back > to 300s? I believe the default was changed to 600s in the ITB. Burt, Tony and I had an email exchange about this last week: in summary, I don't see a problem for the dbII subscription (raw dialect) to be changed to 300s. Note that we want to keep the ReSS subscription (old classad dialect) to 600 sec to manage the potential rate of incoming classads from sites. Alain, can you please change the generation of the $VDT_LOCATION/etc/glite-ce- monitor/cemonitor-config.xml so that the <subscription> context for is- itb.grid.iu.edu has a policy rate of 300 secs, instead of 600 ? For clarity this is the new context: <subscription id="subscription-http___is-itb_grid_iu_edu_14001- OSG_CE-RAW" monitorConsumerURL="http://is-itb.grid.iu.edu:14001" sslprotocol="SSLv3" retryCount="-1"> <topic name="OSG_CE"> <dialect name="RAW" /> </topic> <policy rate="300"> </policy> </subscription> Burt, Alain, this will publish GIP info to BDII every 300 sec AND invoke GIP once every 600 secs (controlled by the "executionDelay" property of the OSG- CE sensor). I believe that this is the appropriate arrangement (considering also the caching time of GIP), but we can discuss changing that parameter as well. Let us know if you need any additional information. Thanks Gabriele |
||||||||||||||
| # | Tue Jun 03 17:20:15 2008 | roy - Cc parag@fnal.gov added | ||
| # | Tue Jun 03 17:20:15 2008 | roy - Cc garzogli@fnal.gov added | ||
| # | Tue Jun 03 17:20:15 2008 | roy - Cc burt@fnal.gov added | ||
| # | Tue Jun 03 17:20:27 2008 | roy - Cc tlevshin@fnal.gov added | ||
| # | Tue Jun 03 17:20:36 2008 | roy - Fix scheduled CUR added | ||
| # | Tue Jun 03 17:20:52 2008 | roy - Cc garzogli@fnal.gov deleted | ||
| # | Tue Jun 03 17:22:42 2008 | roy - Correspondence added | [Reply] | |
|
Hi, We're closing in on the OSG 1.0 release, and I only want to make essential changes before the release. How important is this? I don't have a good feeling about it from the description below. Any insight you have on this would be useful. If we get it into a test cache, can you test it to make sure it's good? Do we need further ITB testing to ensure it's good before we release? Might this delay the OSG 1.0 release? Thanks, -alain ----------------------------------------------------------------- Alain Roy vdt-support@opensciencegrid.org VDT Support http://vdt.cs.wisc.edu/support.html > Hi Burt, Alain, > > Burt Holzman wrote: > > Hi GOC, > > > > > We have noticed that the expiration for stale information in the ITB > > BDII is 10 minutes. The CEMon interval by default is also set to 10 > > minutes, which leads to sites flaking in and out of BDII. > > > > Could you increase the interval to something more reasonable (60 > > minutes seems ok)? > > > > And Gabriele, is it ok to change the ce-monitor.xml update time back > > to 300s? I believe the default was changed to 600s in the ITB. > Burt, > Tony and I had an email exchange about this last week: in summary, I > don't see a problem for the dbII subscription (raw dialect) to be > changed to 300s. Note that we want to keep the ReSS subscription (old > classad dialect) to 600 sec to manage the potential rate of incoming > classads from sites. > > Alain, > can you please change the generation of the $VDT_LOCATION/etc/glite-ce- > monitor/cemonitor-config.xml so that the <subscription> context for is- > itb.grid.iu.edu has a policy rate of 300 secs, instead of 600 ? > > For clarity this is the new context: > > <subscription id="subscription-http___is-itb_grid_iu_edu_14001- > OSG_CE-RAW" > monitorConsumerURL="http://is-itb.grid.iu.edu:14001" > sslprotocol="SSLv3" > retryCount="-1"> > <topic name="OSG_CE"> > <dialect name="RAW" /> > </topic> > <policy rate="300"> > </policy> > </subscription> > > Burt, Alain, > this will publish GIP info to BDII every 300 sec AND invoke GIP once > every 600 secs (controlled by the "executionDelay" property of the OSG- > CE sensor). I believe that this is the appropriate arrangement > (considering also the caching time of GIP), but we can discuss > changing that parameter as well. > > Let us know if you need any additional information. > > Thanks > Gabriele > > |
||||
| # | Tue Jun 03 17:22:43 2008 | RT_System - Status changed from 'new' to 'open' | ||
| # | Tue Jun 03 17:22:43 2008 | roy - Given to roy | ||
| # | Tue Jun 03 21:07:19 2008 | burt@fnal.gov - Correspondence added | [Reply] | |||||||||||
Alain Roy via RT wrote: > Hi, > > We're closing in on the OSG 1.0 release, and I only want to make > essential changes before the release. How important is this? I don't > have a good feeling about it from the description below. Any insight you > have on this would be useful. > > If we get it into a test cache, can you test it to make sure it's good? > Do we need further ITB testing to ensure it's good before we release? > Might this delay the OSG 1.0 release? Hi Alain, I believe this is important, but maybe not a showstopper. However: there is one more round of GIP bugfixes that need to go into the ITB before I'd consider it validated. I was hoping to hear back from early adopters before I cut a (final) GIP 1.0.0beta5 release, but we may just have to send it out to you ASAP. I've been in training on consecutive Thursdays for the last month, so I apologize if this runs contrary to the ITB party line.. - B |
||||||||||||||
| # | Wed Jun 04 09:36:41 2008 | weigand@fnal.gov - Correspondence added | [Reply] | |||||||||||
xne1 is VTB with 1.10.1b xen9 is ITB with 1.10.1b xen2 is OSG 0.8.0 Gabriele Garzoglio wrote: > Hi Alain, > this change is useful for the ldap group to have continuous presence > of information in the IS. CEMon reports from sites o LDAP every 10 > mins (via the aggregator) AND LDAP discards information every 10 mins: > sometimes, info drops from LDAP for a short time. We want CEMon to > report every 5 mins, to avoid this problem. > > I believe that we should be able to make the change without too much > worry. Essentially, we are asking to change the policy rate for ldap > from 600 (sec) to 300 i.e. you should be changing ONLY 1 number in the > config. If you have a different impression, there is some > misunderstanding. This change should NOT delay the release schedule. > > As far as testing is concerned... Burt, John W., for something so > minor, can we use the daily installations on cms-xen to check that it > is properly reporting? > Maybe Tony can keep an eye on it? > > Cheers > Gabriele > > Alain Roy via RT wrote: >> Hi, >> >> We're closing in on the OSG 1.0 release, and I only want to make >> essential changes before the release. How important is this? I don't >> have a good feeling about it from the description below. Any insight you >> have on this would be useful. >> >> If we get it into a test cache, can you test it to make sure it's good? >> Do we need further ITB testing to ensure it's good before we release? >> Might this delay the OSG 1.0 release? >> >> Thanks, >> -alain >> >> ----------------------------------------------------------------- >> Alain Roy vdt-support@opensciencegrid.org >> VDT Support http://vdt.cs.wisc.edu/support.html >> >> >>> Hi Burt, Alain, >>>>> >>> Burt Holzman wrote: >>> >>>> Hi GOC, >>> Burt,>>>> >>>> We have noticed that the expiration for stale information in the ITB >>>> BDII is 10 minutes. The CEMon interval by default is also set to 10 >>>> minutes, which leads to sites flaking in and out of BDII. >>>> >>>> Could you increase the interval to something more reasonable (60 >>>> minutes seems ok)? >>>> >>>> And Gabriele, is it ok to change the ce-monitor.xml update time back >>>> to 300s? I believe the default was changed to 600s in the ITB. >>>> >>> Tony and I had an email exchange about this last week: in summary, I >>> don't see a problem for the dbII subscription (raw dialect) to be >>> changed to 300s. Note that we want to keep the ReSS subscription (old >>> classad dialect) to 600 sec to manage the potential rate of incoming >>> classads from sites. >>> >>> Alain, >>> can you please change the generation of the $VDT_LOCATION/etc/glite-ce- >>> monitor/cemonitor-config.xml so that the <subscription> context for is- >>> itb.grid.iu.edu has a policy rate of 300 secs, instead of 600 ? >>> >>> For clarity this is the new context: >>> >>> <subscription id="subscription-http___is-itb_grid_iu_edu_14001- >>> OSG_CE-RAW" >>> monitorConsumerURL="http://is-itb.grid.iu.edu:14001" >>> sslprotocol="SSLv3" >>> retryCount="-1"> >>> <topic name="OSG_CE"> >>> <dialect name="RAW" /> >>> </topic> >>> <policy rate="300"> >>> </policy> >>> </subscription> >>> >>> Burt, Alain, >>> this will publish GIP info to BDII every 300 sec AND invoke GIP once >>> every 600 secs (controlled by the "executionDelay" property of the OSG- >>> CE sensor). I believe that this is the appropriate arrangement >>> (considering also the caching time of GIP), but we can discuss >>> changing that parameter as well. >>> >>> Let us know if you need any additional information. >>> >>> Thanks >>> Gabriele >>> >>> >>> >> >> |
||||||||||||||
| # | Wed Jun 04 09:36:53 2008 | garzoglio@fnal.gov - Correspondence added | [Reply] | |||||||||||
Hi Alain, this change is useful for the ldap group to have continuous presence of information in the IS. CEMon reports from sites o LDAP every 10 mins (via the aggregator) AND LDAP discards information every 10 mins: sometimes, info drops from LDAP for a short time. We want CEMon to report every 5 mins, to avoid this problem. I believe that we should be able to make the change without too much worry. Essentially, we are asking to change the policy rate for ldap from 600 (sec) to 300 i.e. you should be changing ONLY 1 number in the config. If you have a different impression, there is some misunderstanding. This change should NOT delay the release schedule. As far as testing is concerned... Burt, John W., for something so minor, can we use the daily installations on cms-xen to check that it is properly reporting? Maybe Tony can keep an eye on it? Cheers Gabriele Alain Roy via RT wrote: > Hi, > > We're closing in on the OSG 1.0 release, and I only want to make > essential changes before the release. How important is this? I don't > have a good feeling about it from the description below. Any insight you > have on this would be useful. > > If we get it into a test cache, can you test it to make sure it's good? > Do we need further ITB testing to ensure it's good before we release? > Might this delay the OSG 1.0 release? > > Thanks, > -alain > > ----------------------------------------------------------------- > Alain Roy vdt-support@opensciencegrid.org > VDT Support http://vdt.cs.wisc.edu/support.html > > >> Hi Burt, Alain, >>> >> Burt Holzman wrote: >> >>> Hi GOC, >> Burt,>>> >>> We have noticed that the expiration for stale information in the ITB >>> BDII is 10 minutes. The CEMon interval by default is also set to 10 >>> minutes, which leads to sites flaking in and out of BDII. >>> >>> Could you increase the interval to something more reasonable (60 >>> minutes seems ok)? >>> >>> And Gabriele, is it ok to change the ce-monitor.xml update time back >>> to 300s? I believe the default was changed to 600s in the ITB. >>> >> Tony and I had an email exchange about this last week: in summary, I >> don't see a problem for the dbII subscription (raw dialect) to be >> changed to 300s. Note that we want to keep the ReSS subscription (old >> classad dialect) to 600 sec to manage the potential rate of incoming >> classads from sites. >> >> Alain, >> can you please change the generation of the $VDT_LOCATION/etc/glite-ce- >> monitor/cemonitor-config.xml so that the <subscription> context for is- >> itb.grid.iu.edu has a policy rate of 300 secs, instead of 600 ? >> >> For clarity this is the new context: >> >> <subscription id="subscription-http___is-itb_grid_iu_edu_14001- >> OSG_CE-RAW" >> monitorConsumerURL="http://is-itb.grid.iu.edu:14001" >> sslprotocol="SSLv3" >> retryCount="-1"> >> <topic name="OSG_CE"> >> <dialect name="RAW" /> >> </topic> >> <policy rate="300"> >> </policy> >> </subscription> >> >> Burt, Alain, >> this will publish GIP info to BDII every 300 sec AND invoke GIP once >> every 600 secs (controlled by the "executionDelay" property of the OSG- >> CE sensor). I believe that this is the appropriate arrangement >> (considering also the caching time of GIP), but we can discuss >> changing that parameter as well. >> >> Let us know if you need any additional information. >> >> Thanks >> Gabriele >> >> >> > > |
||||||||||||||
| # | Wed Jun 04 09:41:48 2008 | tiradani@fnal.gov - Correspondence added | [Reply] | |||||||||||
Hello, I can make the change on those machines and monitor. Just as a side note, the 0.8.0 installations are set to report every 5 minutes by default. The new change would simply restore that behavior for the ldap group in the ITB 0.9.1 (OSG 1.0) release. Thanks, - Anthony Tiradani tiradani@fnal.gov +1 (630) 840-4479 On Wed, 2008-06-04 at 09:34 -0500, John Weigand wrote: > xne1 is VTB with 1.10.1b > xen9 is ITB with 1.10.1b > xen2 is OSG 0.8.0 > > Gabriele Garzoglio wrote: > > Hi Alain, > > this change is useful for the ldap group to have continuous presence > > of information in the IS. CEMon reports from sites o LDAP every 10 > > mins (via the aggregator) AND LDAP discards information every 10 mins: > > sometimes, info drops from LDAP for a short time. We want CEMon to > > report every 5 mins, to avoid this problem. > > > > I believe that we should be able to make the change without too much > > worry. Essentially, we are asking to change the policy rate for ldap > > from 600 (sec) to 300 i.e. you should be changing ONLY 1 number in the > > config. If you have a different impression, there is some > > misunderstanding. This change should NOT delay the release schedule. > > > > As far as testing is concerned... Burt, John W., for something so > > minor, can we use the daily installations on cms-xen to check that it > > is properly reporting? > > Maybe Tony can keep an eye on it? > > > > Cheers > > Gabriele > > > > Alain Roy via RT wrote: > >> Hi, > >> > >> We're closing in on the OSG 1.0 release, and I only want to make > >> essential changes before the release. How important is this? I don't > >> have a good feeling about it from the description below. Any insight you > >> have on this would be useful. > >> > >> If we get it into a test cache, can you test it to make sure it's good? > >> Do we need further ITB testing to ensure it's good before we release? > >> Might this delay the OSG 1.0 release? > >> > >> Thanks, > >> -alain > >> > >> ----------------------------------------------------------------- > >> Alain Roy vdt-support@opensciencegrid.org > >> VDT Support http://vdt.cs.wisc.edu/support.html > >> > >> > >>> Hi Burt, Alain, > >>> >>> > >>> Burt Holzman wrote: > >>> > >>>> Hi GOC, > >>> Burt,> >>>> > >>>> We have noticed that the expiration for stale information in the ITB > >>>> BDII is 10 minutes. The CEMon interval by default is also set to 10 > >>>> minutes, which leads to sites flaking in and out of BDII. > >>>> > >>>> Could you increase the interval to something more reasonable (60 > >>>> minutes seems ok)? > >>>> > >>>> And Gabriele, is it ok to change the ce-monitor.xml update time back > >>>> to 300s? I believe the default was changed to 600s in the ITB. > >>>> > >>> Tony and I had an email exchange about this last week: in summary, I > >>> don't see a problem for the dbII subscription (raw dialect) to be > >>> changed to 300s. Note that we want to keep the ReSS subscription (old > >>> classad dialect) to 600 sec to manage the potential rate of incoming > >>> classads from sites. > >>> > >>> Alain, > >>> can you please change the generation of the $VDT_LOCATION/etc/glite-ce- > >>> monitor/cemonitor-config.xml so that the <subscription> context for is- > >>> itb.grid.iu.edu has a policy rate of 300 secs, instead of 600 ? > >>> > >>> For clarity this is the new context: > >>> > >>> <subscription id="subscription-http___is-itb_grid_iu_edu_14001- > >>> OSG_CE-RAW" > >>> monitorConsumerURL="http://is-itb.grid.iu.edu:14001" > >>> sslprotocol="SSLv3" > >>> retryCount="-1"> > >>> <topic name="OSG_CE"> > >>> <dialect name="RAW" /> > >>> </topic> > >>> <policy rate="300"> > >>> </policy> > >>> </subscription> > >>> > >>> Burt, Alain, > >>> this will publish GIP info to BDII every 300 sec AND invoke GIP once > >>> every 600 secs (controlled by the "executionDelay" property of the OSG- > >>> CE sensor). I believe that this is the appropriate arrangement > >>> (considering also the caching time of GIP), but we can discuss > >>> changing that parameter as well. > >>> > >>> Let us know if you need any additional information. > >>> > >>> Thanks > >>> Gabriele > >>> > >>> > >>> > >> > >> |
||||||||||||||
| # | Wed Jun 04 09:46:47 2008 | garzoglio@fnal.gov - Correspondence added | [Reply] | |||||||||||
Yes, that seems a good test to make. In the end, we'll have to check that the new version of VDT has the right config i.e. nothing got broken by mistake. Since the installation on cms-xen is automatic, it should be easy. Cheers Gabriele Anthony Tiradani wrote: > Hello, > > I can make the change on those machines and monitor. Just as a side > note, the 0.8.0 installations are set to report every 5 minutes by > default. The new change would simply restore that behavior for the ldap > group in the ITB 0.9.1 (OSG 1.0) release. > > Thanks, > > - > Anthony Tiradani > tiradani@fnal.gov > +1 (630) 840-4479 > > > > On Wed, 2008-06-04 at 09:34 -0500, John Weigand wrote: > >> xne1 is VTB with 1.10.1b >> xen9 is ITB with 1.10.1b >> xen2 is OSG 0.8.0 >> >> Gabriele Garzoglio wrote: >> >>> Hi Alain, >>> this change is useful for the ldap group to have continuous presence >>> of information in the IS. CEMon reports from sites o LDAP every 10 >>> mins (via the aggregator) AND LDAP discards information every 10 mins: >>> sometimes, info drops from LDAP for a short time. We want CEMon to >>> report every 5 mins, to avoid this problem. >>> >>> I believe that we should be able to make the change without too much >>> worry. Essentially, we are asking to change the policy rate for ldap >>> from 600 (sec) to 300 i.e. you should be changing ONLY 1 number in the >>> config. If you have a different impression, there is some >>> misunderstanding. This change should NOT delay the release schedule. >>> >>> As far as testing is concerned... Burt, John W., for something so >>> minor, can we use the daily installations on cms-xen to check that it >>> is properly reporting? >>> Maybe Tony can keep an eye on it? >>> >>> Cheers >>> Gabriele >>> >>> Alain Roy via RT wrote: >>> >>>> Hi, >>>> >>>> We're closing in on the OSG 1.0 release, and I only want to make >>>> essential changes before the release. How important is this? I don't >>>> have a good feeling about it from the description below. Any insight you >>>> have on this would be useful. >>>> >>>> If we get it into a test cache, can you test it to make sure it's good? >>>> Do we need further ITB testing to ensure it's good before we release? >>>> Might this delay the OSG 1.0 release? >>>> >>>> Thanks, >>>> -alain >>>> >>>> ----------------------------------------------------------------- >>>> Alain Roy vdt-support@opensciencegrid.org >>>> VDT Support http://vdt.cs.wisc.edu/support.html >>>> >>>> >>>> >>>>> Hi Burt, Alain, >>>> >>>>> >>>>> Burt Holzman wrote: >>>>> >>>>> >>>>>> Hi GOC, >>>>> Burt,>>>>>> >>>>>> We have noticed that the expiration for stale information in the ITB >>>>>> BDII is 10 minutes. The CEMon interval by default is also set to 10 >>>>>> minutes, which leads to sites flaking in and out of BDII. >>>>>> >>>>>> Could you increase the interval to something more reasonable (60 >>>>>> minutes seems ok)? >>>>>> >>>>>> And Gabriele, is it ok to change the ce-monitor.xml update time back >>>>>> to 300s? I believe the default was changed to 600s in the ITB. >>>>>> >>>>>> >>>>> Tony and I had an email exchange about this last week: in summary, I >>>>> don't see a problem for the dbII subscription (raw dialect) to be >>>>> changed to 300s. Note that we want to keep the ReSS subscription (old >>>>> classad dialect) to 600 sec to manage the potential rate of incoming >>>>> classads from sites. >>>>> >>>>> Alain, >>>>> can you please change the generation of the $VDT_LOCATION/etc/glite-ce- >>>>> monitor/cemonitor-config.xml so that the <subscription> context for is- >>>>> itb.grid.iu.edu has a policy rate of 300 secs, instead of 600 ? >>>>> >>>>> For clarity this is the new context: >>>>> >>>>> <subscription id="subscription-http___is-itb_grid_iu_edu_14001- >>>>> OSG_CE-RAW" >>>>> monitorConsumerURL="http://is-itb.grid.iu.edu:14001" >>>>> sslprotocol="SSLv3" >>>>> retryCount="-1"> >>>>> <topic name="OSG_CE"> >>>>> <dialect name="RAW" /> >>>>> </topic> >>>>> <policy rate="300"> >>>>> </policy> >>>>> </subscription> >>>>> >>>>> Burt, Alain, >>>>> this will publish GIP info to BDII every 300 sec AND invoke GIP once >>>>> every 600 secs (controlled by the "executionDelay" property of the OSG- >>>>> CE sensor). I believe that this is the appropriate arrangement >>>>> (considering also the caching time of GIP), but we can discuss >>>>> changing that parameter as well. >>>>> >>>>> Let us know if you need any additional information. >>>>> >>>>> Thanks >>>>> Gabriele >>>>> >>>>> >>>>> >>>>> >>>> |
||||||||||||||
| # | Wed Jun 04 10:11:58 2008 | roy - Correspondence added | [Reply] | |||||||||
On Jun 4, 2008, at 9:36 AM, garzoglio@fnal.gov via RT wrote: > http://vdt.cs.wisc.edu/rt/Ticket/Display.html?id=3576 > > Hi Alain, > this change is useful for the ldap group to have continuous presence > of > information in the IS. CEMon reports from sites o LDAP every 10 mins > (via the aggregator) AND LDAP discards information every 10 mins: > sometimes, info drops from LDAP for a short time. We want CEMon to > report every 5 mins, to avoid this problem. OK, this sounds fairly important. > As far as testing is concerned... Burt, John W., for something so > minor, > can we use the daily installations on cms-xen to check that it is > properly reporting? > Maybe Tony can keep an eye on it? It is a code change, because this is set up in configure_cemon. It's an easy code change, I just want to be very careful at this point. We need to finish up our security fix, then we'll include this. Thanks, -alain |
||||||||||||
| # | Thu Jun 05 17:06:39 2008 | roy - Priority changed from (no value) to '3' | ||
| # | Thu Jun 05 17:07:06 2008 | roy - Subject changed from 'Re: ITB BDII expiration set to 10 minutes' to 'Change CEMon reporting period to five minutes' | ||
| # | Fri Jun 06 15:59:53 2008 | roy - Comments added | [Reply] | |||||||
Commit comment: Based on request from Gabriele, changed RAW subscriptions to have update frequency of 5 minutes (300 seconds) instead of 10 minutes. This is important because our BDII discards information every 10 minutes, so this change will prevent data from occasionally dropping out of the BDII. While I was at it, I added a missing newline to make our configuration files neater. Changed files: U vdt/branches/vdt-1.10.1/Configure-CEMon/vdt/setup/configure_cemon To generate a diff: svn diff -c 7807 file:///p/vdt/workspace/svn |
||||||||||
| # | Fri Jun 06 16:07:24 2008 | roy - Correspondence added | [Reply] | |
|
OK, I've changed the configure_cemon script so that it uses 300 seconds for RAW subscriptions instead of 600 seconds. OLD_CLASSAD subscriptions are unchanged. It's in a test cache. http://vdt.cs.wisc.edu/vdt_11099_cache I've tested it and I'm pretty sure it's good, but if you have time to test it, that's great. We'll release this as part of VDT 1.10.c on Monday. The only thing I don't know how to do is to tell people how to update their existing installations. Configre_cemon isn't smart enough to change the file once a subscription exists, so people have the manually edit the configuration file. I think that's not a big deal right now because it only affects ITB sites. Thanks, -alain ----------------------------------------------------------------- Alain Roy vdt-support@opensciencegrid.org VDT Support http://vdt.cs.wisc.edu/support.html > Alain, > can you please change the generation of the $VDT_LOCATION/etc/glite-ce- > monitor/cemonitor-config.xml so that the <subscription> context for is- > itb.grid.iu.edu has a policy rate of 300 secs, instead of 600 ? > > For clarity this is the new context: > > <subscription id="subscription-http___is-itb_grid_iu_edu_14001- > OSG_CE-RAW" > monitorConsumerURL="http://is-itb.grid.iu.edu:14001" > sslprotocol="SSLv3" > retryCount="-1"> > <topic name="OSG_CE"> > <dialect name="RAW" /> > </topic> > <policy rate="300"> > </policy> > </subscription> > > Burt, Alain, > this will publish GIP info to BDII every 300 sec AND invoke GIP once > every 600 secs (controlled by the "executionDelay" property of the OSG- > CE sensor). I believe that this is the appropriate arrangement > (considering also the caching time of GIP), but we can discuss > changing that parameter as well. > > Let us know if you need any additional information. > > Thanks > Gabriele |
||||
| # | Fri Jun 06 16:20:13 2008 | garzoglio@fnal.gov - Correspondence added | [Reply] | |||||||||||
Hi Burt, Tony, John, Alain, we discussed over email if keeping an eye on John's automatic installation was enough for testing the BDII informatino channel of CEMom. Is this still a good plan? John, are you using the new cache anywhere in your automated installation? http://vdt.cs.wisc.edu/vdt_11099_cache Tony, do you need our help to check if CEMon is reporting properly to bdII? Alain, thank you. Cheers Gabriele Alain Roy via RT wrote: > OK, I've changed the configure_cemon script so that it uses 300 seconds > for RAW subscriptions instead of 600 seconds. OLD_CLASSAD subscriptions > are unchanged. > > It's in a test cache. http://vdt.cs.wisc.edu/vdt_11099_cache > > I've tested it and I'm pretty sure it's good, but if you have time to > test it, that's great. > > We'll release this as part of VDT 1.10.c on Monday. > > The only thing I don't know how to do is to tell people how to update > their existing installations. Configre_cemon isn't smart enough to > change the file once a subscription exists, so people have the manually > edit the configuration file. I think that's not a big deal right now > because it only affects ITB sites. > > Thanks, > -alain > > ----------------------------------------------------------------- > Alain Roy vdt-support@opensciencegrid.org > VDT Support http://vdt.cs.wisc.edu/support.html > > >> Alain, >>> can you please change the generation of the $VDT_LOCATION/etc/glite-ce- >> monitor/cemonitor-config.xml so that the <subscription> context for is- >> itb.grid.iu.edu has a policy rate of 300 secs, instead of 600 ? >> >> For clarity this is the new context: >> >> <subscription id="subscription-http___is-itb_grid_iu_edu_14001- >> OSG_CE-RAW" >> monitorConsumerURL="http://is-itb.grid.iu.edu:14001" >> sslprotocol="SSLv3" >> retryCount="-1"> >> <topic name="OSG_CE"> >> <dialect name="RAW" /> >> </topic> >> <policy rate="300"> >> </policy> >> </subscription> >> >> Burt, Alain, >> this will publish GIP info to BDII every 300 sec AND invoke GIP once >> every 600 secs (controlled by the "executionDelay" property of the OSG- >> CE sensor). I believe that this is the appropriate arrangement >> (considering also the caching time of GIP), but we can discuss >> changing that parameter as well. >> >> Let us know if you need any additional information. >> >> Thanks >> Gabriele >> > > |
||||||||||||||
| # | Fri Jun 06 16:20:13 2008 | parag@fnal.gov - Correspondence added | [Reply] | |||||||||||
Hi Alain, I am installing CeMon from the cache below and will keep it running over the weekend. I will let you know how did the install go in a few minutes. On Fri, 2008-06-06 at 16:07 -0500, Alain Roy via RT wrote: > OK, I've changed the configure_cemon script so that it uses 300 seconds -- > for RAW subscriptions instead of 600 seconds. OLD_CLASSAD subscriptions > are unchanged. > > It's in a test cache. http://vdt.cs.wisc.edu/vdt_11099_cache > > I've tested it and I'm pretty sure it's good, but if you have time to > test it, that's great. > > We'll release this as part of VDT 1.10.c on Monday. > > The only thing I don't know how to do is to tell people how to update > their existing installations. Configre_cemon isn't smart enough to > change the file once a subscription exists, so people have the manually > edit the configuration file. I think that's not a big deal right now > because it only affects ITB sites. > > Thanks, > -alain > > ----------------------------------------------------------------- > Alain Roy vdt-support@opensciencegrid.org > VDT Support http://vdt.cs.wisc.edu/support.html > > > Alain, > > > can you please change the generation of the $VDT_LOCATION/etc/glite-ce- > > monitor/cemonitor-config.xml so that the <subscription> context for is- > > itb.grid.iu.edu has a policy rate of 300 secs, instead of 600 ? > > > > For clarity this is the new context: > > > > <subscription id="subscription-http___is-itb_grid_iu_edu_14001- > > OSG_CE-RAW" > > monitorConsumerURL="http://is-itb.grid.iu.edu:14001" > > sslprotocol="SSLv3" > > retryCount="-1"> > > <topic name="OSG_CE"> > > <dialect name="RAW" /> > > </topic> > > <policy rate="300"> > > </policy> > > </subscription> > > > > Burt, Alain, > > this will publish GIP info to BDII every 300 sec AND invoke GIP once > > every 600 secs (controlled by the "executionDelay" property of the OSG- > > CE sensor). I believe that this is the appropriate arrangement > > (considering also the caching time of GIP), but we can discuss > > changing that parameter as well. > > > > Let us know if you need any additional information. > > > > Thanks > > Gabriele > Thanks & Regards ============================================================= Parag MhashilkarFermi National Accelerator Laboratory, MS 120 Wilson & Kirk Road, Batavia, IL - 60510. Location: Wilson Hall, WH863 Phone: +1 (630) 840-6530 Fax: +1 (630) 840-2783 Email: parag@fnal.gov ============================================================= |
||||||||||||||
| # | Fri Jun 06 16:26:08 2008 | roy - Status changed from 'open' to 'resolved' | ||
| # | Fri Jun 06 16:42:24 2008 | roy - Correspondence added | [Reply] | |||||||||
On Jun 6, 2008, at 4:20 PM, parag@fnal.gov via RT wrote: > http://vdt.cs.wisc.edu/rt/Ticket/Display.html?id=3576 > > Hi Alain, > > I am installing CeMon from the cache below and will keep it running > over > the weekend. I will let you know how did the install go in a few > minutes. Great, thanks! -alain |
||||||||||||
| # | Fri Jun 06 16:42:25 2008 | RT_System - Status changed from 'resolved' to 'open' | ||
| # | Fri Jun 06 16:42:29 2008 | roy - Correspondence added | [Reply] | |||||||||
On Jun 6, 2008, at 4:20 PM, garzoglio@fnal.gov via RT wrote: > http://vdt.cs.wisc.edu/rt/Ticket/Display.html?id=3576 > > Hi Burt, Tony, John, Alain, > we discussed over email if keeping an eye on John's automatic > installation was enough for testing the BDII informatino channel of > CEMom. > Is this still a good plan? I don't have a strong feeling about this. But this change is small enough, then between visual inspection and Parag's tests, I think we can feel pretty confident. -alain |
||||||||||||
| # | Fri Jun 06 16:52:21 2008 | parag@fnal.gov - Correspondence added | [Reply] | |||||||||||
Hi Alain, John, Tony, Installation looks good and I will keep it running for a while. My test setup is not registered/configured to talk to BDII so I can not necessarily confirm the effect of the changes in the configuration value. At least I did not find any problems with installing and starting the CeMon service and having it registered to ReSS. If John is using cache below as part of daily install on cms-xen1, we can see the results on http://is-itb2.grid.iu.edu/cgi-bin/status.cgi Alternatively, if Tony is handling any of the sites registered on the link above and can install VDT from cache below, we can check the effect of changes from 600->300 for that site as well. On Fri, 2008-06-06 at 16:20 -0500, garzoglio@fnal.gov via RT wrote: > Hi Burt, Tony, John, Alain, -- > we discussed over email if keeping an eye on John's automatic > installation was enough for testing the BDII informatino channel of CEMom. > Is this still a good plan? > > John, > are you using the new cache anywhere in your automated installation? > > http://vdt.cs.wisc.edu/vdt_11099_cache > > > Tony, > do you need our help to check if CEMon is reporting properly to bdII? > > Alain, > thank you. > > Cheers > Gabriele > > Alain Roy via RT wrote: > > OK, I've changed the configure_cemon script so that it uses 300 seconds > > > for RAW subscriptions instead of 600 seconds. OLD_CLASSAD subscriptions > > are unchanged. > > > > It's in a test cache. http://vdt.cs.wisc.edu/vdt_11099_cache > > > > I've tested it and I'm pretty sure it's good, but if you have time to > > test it, that's great. > > > > We'll release this as part of VDT 1.10.c on Monday. > > > > The only thing I don't know how to do is to tell people how to update > > their existing installations. Configre_cemon isn't smart enough to > > change the file once a subscription exists, so people have the manually > > edit the configuration file. I think that's not a big deal right now > > because it only affects ITB sites. > > > > Thanks, > > -alain > > > > ----------------------------------------------------------------- > > Alain Roy vdt-support@opensciencegrid.org > > VDT Support http://vdt.cs.wisc.edu/support.html > > > > > >> Alain, > >> >> can you please change the generation of the $VDT_LOCATION/etc/glite-ce- > >> monitor/cemonitor-config.xml so that the <subscription> context for is- > >> itb.grid.iu.edu has a policy rate of 300 secs, instead of 600 ? > >> > >> For clarity this is the new context: > >> > >> <subscription id="subscription-http___is-itb_grid_iu_edu_14001- > >> OSG_CE-RAW" > >> monitorConsumerURL="http://is-itb.grid.iu.edu:14001" > >> sslprotocol="SSLv3" > >> retryCount="-1"> > >> <topic name="OSG_CE"> > >> <dialect name="RAW" /> > >> </topic> > >> <policy rate="300"> > >> </policy> > >> </subscription> > >> > >> Burt, Alain, > >> this will publish GIP info to BDII every 300 sec AND invoke GIP once > >> every 600 secs (controlled by the "executionDelay" property of the OSG- > >> CE sensor). I believe that this is the appropriate arrangement > >> (considering also the caching time of GIP), but we can discuss > >> changing that parameter as well. > >> > >> Let us know if you need any additional information. > >> > >> Thanks > >> Gabriele > >> > > > > > > Hi Burt, Tony, John, Alain, > we discussed over email if keeping an eye on John's automatic > installation was enough for testing the BDII informatino channel of > CEMom. > Is this still a good plan? > > John, > are you using the new cache anywhere in your automated installation? > http://vdt.cs.wisc.edu/vdt_11099_cache > > Tony, > do you need our help to check if CEMon is reporting properly to bdII? > > Alain, > thank you. > > Cheers > Gabriele > > Alain Roy via RT wrote: > > OK, I've changed the configure_cemon script so that it uses 300 seconds > > for RAW subscriptions instead of 600 seconds. OLD_CLASSAD subscriptions > > are unchanged. > > > > It's in a test cache. http://vdt.cs.wisc.edu/vdt_11099_cache > > > > I've tested it and I'm pretty sure it's good, but if you have time to > > test it, that's great. > > > > We'll release this as part of VDT 1.10.c on Monday. > > > > The only thing I don't know how to do is to tell people how to update > > their existing installations. Configre_cemon isn't smart enough to > > change the file once a subscription exists, so people have the manually > > edit the configuration file. I think that's not a big deal right now > > because it only affects ITB sites. > > > > Thanks, > > -alain > > > > ----------------------------------------------------------------- > > Alain Roy vdt-support@opensciencegrid.org > > VDT Support http://vdt.cs.wisc.edu/support.html > > > > > > > Alain, > > > > > can you please change the generation of the $VDT_LOCATION/etc/glite-ce- > > > monitor/cemonitor-config.xml so that the <subscription> context for is- > > > itb.grid.iu.edu has a policy rate of 300 secs, instead of 600 ? > > > > > > For clarity this is the new context: > > > > > > <subscription id="subscription-http___is-itb_grid_iu_edu_14001- > > > OSG_CE-RAW" > > > monitorConsumerURL="http://is-itb.grid.iu.edu:14001" > > > sslprotocol="SSLv3" > > > retryCount="-1"> > > > <topic name="OSG_CE"> > > > <dialect name="RAW" /> > > > </topic> > > > <policy rate="300"> > > > </policy> > > > </subscription> > > > > > > Burt, Alain, > > > this will publish GIP info to BDII every 300 sec AND invoke GIP once > > > every 600 secs (controlled by the "executionDelay" property of the OSG- > > > CE sensor). I believe that this is the appropriate arrangement > > > (considering also the caching time of GIP), but we can discuss > > > changing that parameter as well. > > > > > > Let us know if you need any additional information. > > > > > > Thanks > > > Gabriele > > > > > > > Thanks & Regards ============================================================= Parag MhashilkarFermi National Accelerator Laboratory, MS 120 Wilson & Kirk Road, Batavia, IL - 60510. Location: Wilson Hall, WH863 Phone: +1 (630) 840-6530 Fax: +1 (630) 840-2783 Email: parag@fnal.gov ============================================================= |
||||||||||||||
| # | Fri Jun 06 17:10:17 2008 | weigand@fnal.gov - Correspondence added | [Reply] | |||||||||||
I install for VTB/ITB/OSG.... not directly from VDT except for Condor. I can do a pacman update on the CEMon piece if that is what you need. My opinion has always been that VTB should be pointing to the *99 release which would facilitate this kind of thing but that has never happened. Let me know what you want to do. John Gabriele Garzoglio wrote: > Hi Burt, Tony, John, Alain, > we discussed over email if keeping an eye on John's automatic > installation was enough for testing the BDII informatino channel of CEMom. > Is this still a good plan? > > John, > are you using the new cache anywhere in your automated installation? > http://vdt.cs.wisc.edu/vdt_11099_cache > > Tony, > do you need our help to check if CEMon is reporting properly to bdII? > > Alain, > thank you. > > Cheers > Gabriele > > Alain Roy via RT wrote: >> OK, I've changed the configure_cemon script so that it uses 300 seconds >> for RAW subscriptions instead of 600 seconds. OLD_CLASSAD subscriptions >> are unchanged. >> >> It's in a test cache. http://vdt.cs.wisc.edu/vdt_11099_cache >> >> I've tested it and I'm pretty sure it's good, but if you have time to >> test it, that's great. >> >> We'll release this as part of VDT 1.10.c on Monday. >> >> The only thing I don't know how to do is to tell people how to update >> their existing installations. Configre_cemon isn't smart enough to >> change the file once a subscription exists, so people have the manually >> edit the configuration file. I think that's not a big deal right now >> because it only affects ITB sites. >> >> Thanks, >> -alain >> >> ----------------------------------------------------------------- >> Alain Roy vdt-support@opensciencegrid.org >> VDT Support http://vdt.cs.wisc.edu/support.html >> >> >>> Alain, >>>>> can you please change the generation of the $VDT_LOCATION/etc/glite-ce- >>> monitor/cemonitor-config.xml so that the <subscription> context for is- >>> itb.grid.iu.edu has a policy rate of 300 secs, instead of 600 ? >>> >>> For clarity this is the new context: >>> >>> <subscription id="subscription-http___is-itb_grid_iu_edu_14001- >>> OSG_CE-RAW" >>> monitorConsumerURL="http://is-itb.grid.iu.edu:14001" >>> sslprotocol="SSLv3" >>> retryCount="-1"> >>> <topic name="OSG_CE"> >>> <dialect name="RAW" /> >>> </topic> >>> <policy rate="300"> >>> </policy> >>> </subscription> >>> >>> Burt, Alain, >>> this will publish GIP info to BDII every 300 sec AND invoke GIP once >>> every 600 secs (controlled by the "executionDelay" property of the OSG- >>> CE sensor). I believe that this is the appropriate arrangement >>> (considering also the caching time of GIP), but we can discuss >>> changing that parameter as well. >>> >>> Let us know if you need any additional information. >>> >>> Thanks >>> Gabriele >>> >> >> |
||||||||||||||
| # | Fri Jun 06 17:17:48 2008 | garzoglio@fnal.gov - Correspondence added | [Reply] | |||||||||||
mhmm... would pacman update really test this? Maybe... Would the VTB install get this ? I thought so and this is the 99 release. I guess I'm confused by your comment... The advantage of doing it this way, is that your site is registered with BDII aleady, so someone (Tony?) can check its presence in BDII (...thing that Parag could not do). Tony, what do you think? Thanks Gabriele John Weigand wrote: > I install for VTB/ITB/OSG.... not directly from VDT except for Condor. > > I can do a pacman update on the CEMon piece if that is what you need. > > My opinion has always been that VTB should be pointing to the *99 > release which would facilitate this kind of thing but that has never > happened. > > Let me know what you want to do. > > John > > Gabriele Garzoglio wrote: >> Hi Burt, Tony, John, Alain, >> we discussed over email if keeping an eye on John's automatic >> installation was enough for testing the BDII informatino channel of >> CEMom. >> Is this still a good plan? >> >> John, >> are you using the new cache anywhere in your automated installation? >> http://vdt.cs.wisc.edu/vdt_11099_cache >> >> Tony, >> do you need our help to check if CEMon is reporting properly to bdII? >> >> Alain, >> thank you. >> >> Cheers >> Gabriele >> >> Alain Roy via RT wrote: >>> OK, I've changed the configure_cemon script so that it uses 300 seconds >>> for RAW subscriptions instead of 600 seconds. OLD_CLASSAD subscriptions >>> are unchanged. >>> >>> It's in a test cache. http://vdt.cs.wisc.edu/vdt_11099_cache >>> >>> I've tested it and I'm pretty sure it's good, but if you have time to >>> test it, that's great. >>> We'll release this as part of VDT 1.10.c on Monday. >>> The only thing I don't know how to do is to tell people how to update >>> their existing installations. Configre_cemon isn't smart enough to >>> change the file once a subscription exists, so people have the manually >>> edit the configuration file. I think that's not a big deal right now >>> because it only affects ITB sites. >>> Thanks, >>> -alain >>> >>> ----------------------------------------------------------------- >>> Alain Roy vdt-support@opensciencegrid.org >>> VDT Support http://vdt.cs.wisc.edu/support.html >>> >>> >>>> Alain, >>>>>>> can you please change the generation of the >>>> $VDT_LOCATION/etc/glite-ce- monitor/cemonitor-config.xml so that >>>> the <subscription> context for is- itb.grid.iu.edu has a policy >>>> rate of 300 secs, instead of 600 ? >>>> >>>> For clarity this is the new context: >>>> >>>> <subscription id="subscription-http___is-itb_grid_iu_edu_14001- >>>> OSG_CE-RAW" >>>> monitorConsumerURL="http://is-itb.grid.iu.edu:14001" >>>> sslprotocol="SSLv3" >>>> retryCount="-1"> >>>> <topic name="OSG_CE"> >>>> <dialect name="RAW" /> >>>> </topic> >>>> <policy rate="300"> >>>> </policy> >>>> </subscription> >>>> >>>> Burt, Alain, >>>> this will publish GIP info to BDII every 300 sec AND invoke GIP >>>> once every 600 secs (controlled by the "executionDelay" property >>>> of the OSG- CE sensor). I believe that this is the appropriate >>>> arrangement (considering also the caching time of GIP), but we can >>>> discuss changing that parameter as well. >>>> >>>> Let us know if you need any additional information. >>>> >>>> Thanks >>>> Gabriele >>>> >>> >>> |
||||||||||||||
| # | Fri Jun 06 17:47:27 2008 | weigand@fnal.gov - Correspondence added | [Reply] | |||||||||||
VTB does not point to the 99 release... but to a specific released VDT release. We can do the pacman update. I think Toony did that before and it worked ok. John Gabriele Garzoglio wrote: > mhmm... would pacman update really test this? Maybe... > > Would the VTB install get this ? I thought so and this is the 99 > release. I guess I'm confused by your comment... > > The advantage of doing it this way, is that your site is registered > with BDII aleady, so someone (Tony?) can check its presence in BDII > (...thing that Parag could not do). > > Tony, what do you think? > Thanks > Gabriele > > John Weigand wrote: >> I install for VTB/ITB/OSG.... not directly from VDT except for Condor. >> >> I can do a pacman update on the CEMon piece if that is what you need. >> >> My opinion has always been that VTB should be pointing to the *99 >> release which would facilitate this kind of thing but that has never >> happened. >> >> Let me know what you want to do. >> >> John >> >> Gabriele Garzoglio wrote: >>> Hi Burt, Tony, John, Alain, >>> we discussed over email if keeping an eye on John's automatic >>> installation was enough for testing the BDII informatino channel of >>> CEMom. >>> Is this still a good plan? >>> >>> John, >>> are you using the new cache anywhere in your automated installation? >>> http://vdt.cs.wisc.edu/vdt_11099_cache >>> >>> Tony, >>> do you need our help to check if CEMon is reporting properly to bdII? >>> >>> Alain, >>> thank you. >>> >>> Cheers >>> Gabriele >>> >>> Alain Roy via RT wrote: >>>> OK, I've changed the configure_cemon script so that it uses 300 >>>> seconds >>>> for RAW subscriptions instead of 600 seconds. OLD_CLASSAD >>>> subscriptions >>>> are unchanged. >>>> >>>> It's in a test cache. http://vdt.cs.wisc.edu/vdt_11099_cache >>>> >>>> I've tested it and I'm pretty sure it's good, but if you have time to >>>> test it, that's great. >>>> We'll release this as part of VDT 1.10.c on Monday. >>>> The only thing I don't know how to do is to tell people how to update >>>> their existing installations. Configre_cemon isn't smart enough to >>>> change the file once a subscription exists, so people have the >>>> manually >>>> edit the configuration file. I think that's not a big deal right now >>>> because it only affects ITB sites. >>>> Thanks, >>>> -alain >>>> >>>> ----------------------------------------------------------------- >>>> Alain Roy vdt-support@opensciencegrid.org >>>> VDT Support http://vdt.cs.wisc.edu/support.html >>>> >>>> >>>>> Alain, >>>>>>>>> can you please change the generation of the >>>>> $VDT_LOCATION/etc/glite-ce- monitor/cemonitor-config.xml so that >>>>> the <subscription> context for is- itb.grid.iu.edu has a policy >>>>> rate of 300 secs, instead of 600 ? >>>>> >>>>> For clarity this is the new context: >>>>> >>>>> <subscription id="subscription-http___is-itb_grid_iu_edu_14001- >>>>> OSG_CE-RAW" >>>>> monitorConsumerURL="http://is-itb.grid.iu.edu:14001" >>>>> sslprotocol="SSLv3" >>>>> retryCount="-1"> >>>>> <topic name="OSG_CE"> >>>>> <dialect name="RAW" /> >>>>> </topic> >>>>> <policy rate="300"> >>>>> </policy> >>>>> </subscription> >>>>> >>>>> Burt, Alain, >>>>> this will publish GIP info to BDII every 300 sec AND invoke GIP >>>>> once every 600 secs (controlled by the "executionDelay" property >>>>> of the OSG- CE sensor). I believe that this is the appropriate >>>>> arrangement (considering also the caching time of GIP), but we >>>>> can discuss changing that parameter as well. >>>>> >>>>> Let us know if you need any additional information. >>>>> >>>>> Thanks >>>>> Gabriele >>>>> >>>> >>>> |
||||||||||||||
| # | Mon Jun 09 13:10:04 2008 | roy - Comments added | [Reply] | |
|
Parag gave me the all-clear on this via instant message. |
||||
| # | Mon Jun 09 13:10:05 2008 | roy - Status changed from 'open' to 'resolved' | ||
| # | Thu Jun 12 11:48:06 2008 | garzoglio@fnal.gov - Correspondence added | [Reply] | |||||||||||
Hi Tony, I was wondering if the change on the CEMon registration frequency for LDAP (from 600 to 300 secs) was tested, in the end. Cheers Gabriele John Weigand wrote: > VTB does not point to the 99 release... but to a specific released VDT > release. We can do the pacman update. I think Toony did that before > and it worked ok. > > John > > Gabriele Garzoglio wrote: >> mhmm... would pacman update really test this? Maybe... >> >> Would the VTB install get this ? I thought so and this is the 99 >> release. I guess I'm confused by your comment... >> >> The advantage of doing it this way, is that your site is registered >> with BDII aleady, so someone (Tony?) can check its presence in BDII >> (...thing that Parag could not do). >> >> Tony, what do you think? >> Thanks >> Gabriele >> >> John Weigand wrote: >>> I install for VTB/ITB/OSG.... not directly from VDT except for Condor. >>> >>> I can do a pacman update on the CEMon piece if that is what you need. >>> >>> My opinion has always been that VTB should be pointing to the *99 >>> release which would facilitate this kind of thing but that has never >>> happened. >>> >>> Let me know what you want to do. >>> >>> John >>> >>> Gabriele Garzoglio wrote: >>>> Hi Burt, Tony, John, Alain, >>>> we discussed over email if keeping an eye on John's automatic >>>> installation was enough for testing the BDII informatino channel of >>>> CEMom. >>>> Is this still a good plan? >>>> >>>> John, >>>> are you using the new cache anywhere in your automated installation? >>>> http://vdt.cs.wisc.edu/vdt_11099_cache >>>> >>>> Tony, >>>> do you need our help to check if CEMon is reporting properly to bdII? >>>> >>>> Alain, >>>> thank you. >>>> >>>> Cheers >>>> Gabriele >>>> >>>> Alain Roy via RT wrote: >>>>> OK, I've changed the configure_cemon script so that it uses 300 >>>>> seconds >>>>> for RAW subscriptions instead of 600 seconds. OLD_CLASSAD >>>>> subscriptions >>>>> are unchanged. >>>>> >>>>> It's in a test cache. http://vdt.cs.wisc.edu/vdt_11099_cache >>>>> >>>>> I've tested it and I'm pretty sure it's good, but if you have time to >>>>> test it, that's great. >>>>> We'll release this as part of VDT 1.10.c on Monday. >>>>> The only thing I don't know how to do is to tell people how to update >>>>> their existing installations. Configre_cemon isn't smart enough to >>>>> change the file once a subscription exists, so people have the >>>>> manually >>>>> edit the configuration file. I think that's not a big deal right now >>>>> because it only affects ITB sites. >>>>> Thanks, >>>>> -alain >>>>> >>>>> ----------------------------------------------------------------- >>>>> Alain Roy vdt-support@opensciencegrid.org >>>>> VDT Support http://vdt.cs.wisc.edu/support.html >>>>> >>>>> >>>>>> Alain, >>>>>>>>>>> can you please change the generation of the >>>>>> $VDT_LOCATION/etc/glite-ce- monitor/cemonitor-config.xml so that >>>>>> the <subscription> context for is- itb.grid.iu.edu has a policy >>>>>> rate of 300 secs, instead of 600 ? >>>>>> >>>>>> For clarity this is the new context: >>>>>> >>>>>> <subscription id="subscription-http___is-itb_grid_iu_edu_14001- >>>>>> OSG_CE-RAW" >>>>>> monitorConsumerURL="http://is-itb.grid.iu.edu:14001" >>>>>> sslprotocol="SSLv3" >>>>>> retryCount="-1"> >>>>>> <topic name="OSG_CE"> >>>>>> <dialect name="RAW" /> >>>>>> </topic> >>>>>> <policy rate="300"> >>>>>> </policy> >>>>>> </subscription> >>>>>> >>>>>> Burt, Alain, >>>>>> this will publish GIP info to BDII every 300 sec AND invoke GIP >>>>>> once every 600 secs (controlled by the "executionDelay" property >>>>>> of the OSG- CE sensor). I believe that this is the appropriate >>>>>> arrangement (considering also the caching time of GIP), but we >>>>>> can discuss changing that parameter as well. >>>>>> >>>>>> Let us know if you need any additional information. >>>>>> >>>>>> Thanks >>>>>> Gabriele >>>>>> >>>>> >>>>> |
||||||||||||||
| # | Thu Jun 12 11:48:07 2008 | RT_System - Status changed from 'resolved' to 'open' | ||
| # | Mon Jun 16 12:44:23 2008 | roy - Status changed from 'open' to 'resolved' | ||
Time to display: 3.846968
»|« RT 3.8.2 Copyright 1996-2008 Best Practical Solutions, LLC.