Tuesday, September 17, 2013

GOC Services Update - Tuesday, September 24th, 2013 at 13:00 UTC

The GOC will upgrade the following services beginning Tuesday, September 24th, 2013 at 13:00 UTC. The GOC reserves 8 hours in the unlikely event that unexpected problems are encountered. We encourage users to test affected services before the production release.

OIM 3.23
* Switch from jre-1.6.0-openjdk to java-1.7.0-openjdk
* Added notification suppression for host certificate request tickets if submitter is GridAdmin for the request.

MyOSG 2.16
* Updated various gratia accounting graph names to make it clear that the numbers are wall hours - not cpu hours (MYOSG-70)
* Updating to the latest Perfsonar Matrix jQuery - to fix table width issue.

GOC-TX 1.32
* Upgrading to openjdk 1.7.0
* Adding Jira accessor / converter with GOC Ticket (GOCTX-1)

Ticket 1.68
* Fixed an issue with Login button on some browsers having trouble redirecting to https.
* Added support for notification suppressor for REST interface
* Added capability to override ticket ID displayed on ticket exchange (for Jira). Added jiratest TX config.
* Updated empty object check for search controller throwing php notice

GratiaWeb 1.2-14
* Gratia query that show usage by ProjectName across OSG sites (GratiaWeb-56)
* ProjectName Daily WallHours per Site (GratiaWeb-36)

All Services

There will be OS updates; reboots will be required. Downtime should be minimal, and the usual high-availability mechanisms will be used to reduce service downtime even further and eliminate it in most cases. However, services may experience degraded performance, and the services without HA mechanisms (OIM and Twiki) will still experience brief downtimes.
We will also be switching to sssd rather than nss_ldap/pam_ldap for user authentication on all RHEL5 systems; this will provide scalability and flexibility in security as well as consistency with the RHEL6 systems, which already run sssd rather than nss_ldap/pam_ldap. This will affect only shell logins on systems located at OSG Operations. Locally-defined user logins will be unaffected in any case; we will be moving some of those users to LDAP over time.