On 01/15/2013 10:38 AM, Stephen Burke wrote:
> Testbed Support for GridPP member institutes [mailto:TB-
>> publishing automatically reverts to Production (with no help from
>> us), even though it is still in GOCDB downtime!
> OK, but then presumably it is actually (supposed to be) working? The downtime is after all just an indicative estimate of when the system may be down, it should be common that services come back before the scheduled end time.
Yes, it is _supposed_ to be working. There is a gap between when it is
supposed to be working, and when the admin
decides (and declares) that it is working. It is the gap that is under
discussion.
>> Notes on this: First, as there are two sources to advertise the state of the CE
>> (i.e. via BDII and/or GOCDB), then there is the chance of conflict. Second, this
>> implies that it would be best to assume that one of these is canonical. And
>> third, as the GOCDB is the only one which is fully in our control, then that
>> what is recorded there should be the canonical status of the CE. The other
>> choice, to make the BDII canonical, is not the best thing because it flip/flops
>> automatically as described above. So, in short, trust the GOCDB downtimes.
> the site BDII is completely under the site's control
Yes - let me know the easy way to kick a CE out of the BDII.
On a related note, I want the CE to be "working" so that _I_ can submit
jobs to it through the WMS and see work flow through the system end
to end. Concurrently, I want the CE to be in downtime so others don't
do that. Those are the requirements. What's the best approach?
--
Steve Jones [log in to unmask]
System Administrator office: 220
High Energy Physics Division tel (int): 42334
Oliver Lodge Laboratory tel (ext): +44 (0)151 794 2334
University of Liverpool http://www.liv.ac.uk/physics/hep/
|