[CONDUIT #PGY-808322]: Upcoming NCEP CONDUIT maintenance

Hi Carissa,

re:
> All we see the issue with TIGGE. While the grib insert was working, it
> turns out that user LDM didn't have permissions to get the TIGGE data
> from data2. We again will fix this issue and apologize for the
> unexpected outage.

OK, thanks for the update.

re:
> On the positive, we just turned on the feed to CONDUIT Boulder. I think
> we should see data for the 18Z GFS just starting up. Please confirm on
> your side.

Excellent!

re:
> echo '212628: [22895]: conduit.sh: end ssh ncep-ldm0 -l ldm
> ncep_bin/gribinsert.sh
> /vg0/ncep/data/nccf/com/gfs/prod/gfs.2014012718/gfs.t18z.pgrbf03.grib2 NMC2

re:
> Are your plans to pull from both Boulder CONDUIT and NCWCP(college park)
> CONDUIT from now on? Or do you switch an IP to only point back to
> Boulder?

I was originally planning on leaving the redundant REQUESTs active.  I
have to convince myself that there will be no unexpected consequences
in this approach (there doesn't see like there should be), and then
make a more informed decision.

re:
> And in case we have to many threads going Boulder CONDUIT is
> back and I confirmed with an ldmadmin watch that data is getting into LDM.

Excellent.  I see data showing up from the Boulder CONDUIT top level
in real-time statistics volume plots for one of the real server
nodes in our relay cluster, idd.unidata.ucar.edu:

uni14.unidata.ucar.edu
http://www.unidata.ucar.edu/cgi-bin/rtstats/iddstats_vol_nc?CONDUIT+uni14.unidata.ucar.edu

So far, everything looks good.

re:
> The issue with the misnamed 2.5 GFS > FH204 will be resolved, but we
> will need to go through our normal change process. Expect that change to
> go forward next week. Again, the change will match the same name as Boulder.

Hmm...  Because the products should have the same MD5 signature, it may be
best for Unidata top level CONDUIT relays to turn off the feed from
conduit.ncep.noaa.gov until the issue with misnamed 2.5 degree GFS grids
(grid 002) is resolved.  Why?  The products that will flow in the
CONDUIT feed will be the first ones that make it into the requesting machine's
queue.  The identical products that are tried to be inserted into the
queue _after_ the first one is accepted will be rejected as being a duplicate.
This situation would result in some of the 2.5 degree GFS grids having
one Product ID, and the others a different Product ID.  This could (and
appears to be is) bad depending on the extended regular expression that
a site is using to process the data (e.g., Penn State).  I will advise
the Unidata top level relays to turn off their REQUEST(s) to
conduit.ncep.noaa.gov until the misnaming issue has been addressed.

re:
> The issue with the TIGGE data2 permission also has to go through the
> normal change process. Also expect that to be resolved next week.

This is another reason that REQUEST(s) to conduit.ncep.noaa.gov should
be turned off.  In fact, I just turned ours off here in Unidata.

Cheers,

Tom
--
****************************************************************************
Unidata User Support                                    UCAR Unidata Program
(303) 497-8642                                                 P.O. Box 3000
address@hidden                                   Boulder, CO 80307
----------------------------------------------------------------------------
Unidata HomePage                       http://www.unidata.ucar.edu
****************************************************************************


Ticket Details
===================
Ticket ID: PGY-808322
Department: Support CONDUIT
Priority: Normal
Status: Open