OSG Version 1.0.1 Release

The Open Science Grid Operation Center (GOC), OSG Integration Team,
and VDT are pleased to announce the availability of OSG Version 1.0.1
of the OSG middleware stack. Documentation for the OSG release can be
found at https://twiki.grid.iu.edu/bin/view/ReleaseDocumentation/.

Please see the "Why Upgrade?" document at https://twiki.grid.iu.edu/twiki/bin/view/ReleaseDocumentation/WhyUpgrade
for details about what has been added and changed from version 1.0.0
to 1.0.1.

This VDT update is provided as an incremental update. As most of you
know, incremental updates have proven to be troublesome in the past.
We believe this update to be significantly better and more likely to
succeed, but we would like to proceed with caution.

We would like a couple of patient, willing system administrators to
try out the new update process and provide us feedback. (Are you one
of them?) Until then, we will consider the update process to be beta
quality. We'll note here when it leaves beta. There is no harm in not
taking this update immediately if you are not willing to try it out
right away.

Incremental updates (whether done with the new system, or by hand with
Pacman as we used to recommend) are likely to fail if any of a few
conditions are true. Here are the signs you should be aware of:

1) Did you install the VDT from more than one VDT cache? (Look in
$VDT_LOCATION/trusted.caches to see if there is more than one VDT URL
listed there.) Or did you install from more than one OSG cache? If you
are unsure, mail your trusted.caches file to vdt-support@opensciencegrid.org
, and we'll help you out.

2) If you run services (like a CE), did you install as anything other
than root? There are some cases where this might cause problems.
Client installations should be fine.

3) Did you install OSG 1.0 before its official release?

4) Did you install a versionsed ce package. That is, when you run
"pacman -lc", do you see a package named "ce" (which is good) or a
package named ce-1.0.0 (which is bad.)

If you answered yes to any of these questions, you're better off doing
a fresh installation.

Packages Available:
ce - Compute Element
wn-client - Worker Node Client
client - Desktop Client
gums - GUMS
voms - VOMS
vomrs - VOMRS

Job Manager Setup Packages:
Globus-Condor-Setup
Globus-CondorNFSLite-Setup
Globus-LSF-Setup
Globus-PBS-Setup
Globus-SGE-Setup

Optional Packages:
ManagedFork - Condor Managed Fork
squid - Squid Web Caching Service
Glexec - Glexec

We'd like to thank the members of the OSG ITB and VTB teams for the
effort they've put into getting this release ready.

Please Contact the OSG Grid Operations Center with any questions or
concerns at goc@opensciencegrid.org.

Rob Gardner
OSG Integration Coordinator

Rob Quick
OSG Operations Coordinator

Alain Roy
OSG Software Coordinator

Suchandra Thapa
Integration Testbed Coordinator

OSG TWiki, BDII and GOC YUM Repository Instability (Resolved)

The OSG TWiki, BDII and GOC YUM repository experienced some instability today between 14:11 and 14:32 UTC due to a firewall problem in the Indiana University Purdue University Indianapolis machine room. The issue has been resolved by network engineers.

We appreciate your understanding.

VDT and OSG Software Caches Maintance - GOC Ticket # 6724

The VDT and OSG will be updating their software caches in preparation for the OSG 1.0.1 release. During this maintenance period we are asking the OSG community not to pull any software from the OSG software cache. This includes any command beginning 'pacman -get OSG:'. While the cache will be available for internal testing the packages will be in flux and results of any pulled packages may be unstable. We expect this maintenance to last through today and tomorrow.

The GOC will announce the end of this maintenance period and the release of the OSG 1.0.1 package when it is ready.

VDT and OSG Software Caches Maintance - GOC Ticket # 6724

The VDT and OSG will be updating their software caches in preparation for the OSG 1.0.1 release. During this maintenance period we are asking the OSG community not to pull any software from the OSG software cache. This includes any command beginning 'pacman -get OSG:'. While the cache will be available for internal testing the packages will be in flux and results of any pulled packages may be unstable. We expect this maintenance to last through today and tomorrow.

The GOC will announce the end of this maintenance period and the release of the OSG 1.0.1 package when it is ready.

MyOSG Production Release!

The OpenScienceGrid Operations group is proud to release MyOSG (http://myosg.grid.iu.edu/) as a production service starting today. Listed below are some highlights of the initial production release, a small set of use-cases, and upcoming updates you can expect to see.


HIGHLIGHTS

• Goal: MyOSG is designed with the primary goal of providing users, administrators, VO managers, and everyone else, a one-stop location for various pieces of OSG related information.
• Contents of Initial Release: The first production release of MyOSG includes RSV-based status information, status history graphs, availability metrics; resource downtime schedule [set on OIM by site administrators]; a presentation of GIP validation results; and limited Gratia-accounting information.
  
• Other Useful Links: First release's home page also includes links to commonly used OSG services that the GOC provides; we will be happy to add any other links that users would find useful.
  
• Data Formats: MyOSG allows users to quickly select and filter information they are looking for, and then practically every page allows the user to export the selected/filtered data in their preferred format: HTML; Netvibes, Google, etc.; and XML for programmatic interfaces.
  

EXAMPLE USE CASES

1) USER FROM A VO:
Let us say, you are a CDF (VO) user who wants to run jobs on the OSG. You probably want a list of production resources that provide a CE and an SRM, support your VO, and are up at the moment. This link will likely help you get that information. If you care about the validity of GIP information, then you all will need to do is add an additional filter requiring GIP validation status of OK. Once you have the information you are looking for, click the XML link to get the same information in a machine-readable XML format.

2) SITE ADMIN
Let us say, you are the admin of three resources: AGLT2. BNL_ATLAS_2, BNL_ATLAS_2, and you want to follow the health of your resources at one central location. This link will likely help you; and you can subscribe to the feed on your Netvibes home page using the Netvibes subscription link!

3) VO MANAGER
Let us say, you are the manager of the ATLAS VO. You probably are only interested in knowing if any of the resources your VO owns is having problems. This link will likely give you that information -- it lists all resources that are in down, unknown, maintenance states, and are owned at least partially by your VO. The ownership percentage is shown as well.

4) FACILITY MANAGER OR EQUIVALENT
Let us say, you are a top level management person at Indiana University. and you want to keep an eye on all resources in your facility. You probably want to view the state of all your resources every morning on your iGoogle home page. This link provides that information. And the iGoogle subscription link lets you subscribe to this content on your iGoogle home page. VO ownership, VOs supported, and GIP validation status is shown as well.

This link provides availability history graphs for the above resources.

5) OPERATIONS STAFF / OSG TOP-LEVEL MANAGEMENT
GOC staff and top-level management are always concerned about the health of the grid, and watch for resources that are having trouble at any given moment. This link provides information about production resources that are down or under maintenance currently, along with RSV metric information that will help clearly pin-point what in particular in wrong with the resource.

This link provides usage information by various VOs (Gratia-based accounting information) yesterday. This link provides transfer volume information by various VOs, once again based on Gratia-derived accounting information.

6) SERVICE PROVIDES (like GIP team)
Software service providers like the GIP team might want to keep an eye on GIP validation status of all resources in case a major bug is creeping up on a large proportion of resources. In their case, this link will likely help them.

The above use-cases are just a sample set of the potentially large group of audience that might benefit from MyOSG, and are provided to give readers of this post an idea of how they could use MyOSG. Please send comments/suggestions to GOC.


COMING SOON!

We plan to implement the following updates in the near future

1. RSV-based status information for all registered production resources, and ultimately ITB as well. ETA: April 30th 2009
   
2. Environment variable type information (OSG_APP, OSG_DATA, etc.) in the resource summary for users of the soon-to-be-deprecated VORS system (like LIGO, ATLAS). We also expect to add service end-point (a.k.a serviceUri) information in place of, or in addition to the FQDN that is currently displayed. ETA: April 30th 2009
3. In the medium term future (summer), we also expect to put in place an OIM hierarchy selector for the facilities -> sites -> resource_group -> resource hierarchy.
4. In the medium term future (summer/fall), we also expect to add a presentation layer for ReSS based service information
   

FEATURE REQUESTS

If you would like additional features in MyOSG, please put in a request at http://code.google.com/p/osggoc/issues/ and we will consider your request's feasibility.

Once again, please contact the OSG GOC if you have any questions using the contact links on MyOSG!

GUMS Bug when using "vorole" and "role"

Dear OSG Site Administrators,

We are passing along this message from the GUMS development team:

It has been found that the use of "vorole" and "role" for matchFQAN within a VomsUserGroup exposes a bug in GUMS versions 1.2 - 1.3.14. You must therefore NOT use "vorole" or "role" until upgrading to GUMS 1.3.15 (not yet available) or above. Please verify your configuration.

This problem was found because the OSG GUMS template recently used "vorole" in the "geant4-lcgadmin" usergroup, which caused many users from several VOs to not be mapped. This has been changed to "exact" in the OSG GUMS template, so updating using the "gums-create-config --osg-template" command will ensure everything is back on track. NOTE: only use this script if you do not use a custom configuration!

In a year or so, the OSG template may start using "vorole" and "role" with the assumption that people have upgraded their GUMS to 1.3.15+ by then. A warning will be sent out before this is done.

VORS Deprecation Plans

The OSG Grid Operations Center is planning the deprecation of the VORS status monitoring service. VORS status probing will be replaced by an RSV probing system and presentation will be encompassed in the MyOSG pages.

Here are the important dates:

April 15th - MyOSG moves to production.
May 29th - New Resources coming into OSG will no longer be added to the VORS monitoring system.
August 3rd - VORS will be turned off for good.

An OSG Advisory committee has been formed for the smooth transition of the data provided by VORS. Anyone who is using VORS is encouraged to contact the GOC and open a ticket to be sure the functionality being used is replaced in a new form. All other concerns about the deprecation should be forward to the GOC.