TIssueV2: Tissue <-> ServiceNow integration v7 (May 23, 2018). (1 comment)

Added by Randy Reitz 15 days ago

A brief summary of the new features:
1) New - Communication Type - E-Mail (default) or ServiceNow

a) Required for Detector Configuration
b) Optional for Issue Configuration – Inherits from Detector if not set.

2) Tissue remediation approvals still honored.

If remediation is revoked after ServiceNow's three day delay to close a
resolved incident, a new incident will be opened.

3) Closing a ServiceNow Tissue event will not resolve the incident, but will add Work Notes saying the event was remediated.
4) Incident is assigned to the Support Group of the Configuration Item (CI).

If the CI does not have a support group, the Incident is assigned to the Service Desk.

5) The Email Template text is put into the incident Short Description and Description.

Additional information about the CI is added as Work Notes.
The Tissue Email Template recipient list is used to populate the ServiceNow Incident watch list.


Added by Michael Zalokar about 1 month ago

On 2017-9-5 VRF polling of the routers went into production.

See CHG000000012762.

Fermi Redmine: Assorted outages Thursday Dec 21

Added by Marc Mengel 6 months ago

The system (ccdcvs) that we run on, and the database servers we use will be down various times Thursday morning between 7am and noon.

ccdcvsvm System/Process Owners,

This is a reminder that it's patching time again for ccdcvsvm, according to the agreed upon schedule.
Only a reboot is required. Downtime will be <30 minutes.
The system will be rebooted on Thursday, 12/21/17, at 7:00AM CDT.


Linux Server Support Group

There is a planned downtime scheduled for tomorrow, Thursday, Dec. 21; from 8 a.m. to noon Central Time.

As part of this downtime, ECF will be performing kernel updates and reboots on a variety of systems, including servers ifdb04, ifdb05, and ifdb06.

Please expect downtime for the following databases:

Hosted on ifdb04 (ifdbdev):

  • nova_hardware_dev
  • nova_hardware_int
  • nova_hardware_drop
  • nova_dev
  • nova_ashriver_dev
  • nova_ecl_dev
  • bamon_dev
  • microboone_dev
  • artdaq_db01_dev
  • ifb_dev
  • larsoft_dev
  • ci_art_dev
  • ci_g2_dev
  • ci_mu2e_dev
  • lariat_dev
  • dune35t_dev
  • pdune_hardware_dev
  • dune_colldb_dev
  • lariat_dqm_dev
  • mu2e_ucon_dev
  • gm2_conditions_dev
  • artdaq_db02_dev
  • mnvcon_int
  • pomsdev
  • pdunesp_dev
  • icarus_hardware_dev

Hosted on ifdb05 (ifdbprod, ifdbprod2):

  • nova_prod
  • nova_ecl_prd
  • nova_ashriver_prd
  • novapro_ecl_prd
  • nova_hardware
  • bamon_prd
  • larsoft_prd
  • ci_nova_prd
  • ci_art_prd
  • ci_gwms_prd
  • ci_minerva_prd
  • ci_genie_prd
  • ci_g2_prd
  • ci_mu2e_prd
  • dune35t_prod
  • pdune_hardware_prd
  • dune_colldb_prd
  • lariat_prd
  • lariat_dqm_prd
  • lariatcalib_prod
  • microboone_prod
  • hootgibson_prod
  • mu2e_hardware_prd
  • pomsprd
  • mu2e_ucon_prod
  • mnvcon_int
  • mnvcon_prd
  • pdunesp_prod
  • gm2_online_prod
  • gm2_conditions_prod
  • icarus_prd

Hosted on ifdb06 (ifdbrep):

  • nova_prod
  • nova_ecl_prd
  • nova_ashriver_prd
  • novapro_ecl_prd
  • nova_hardware
  • nova_prod (replication from novadcs-far-logger to ifdb06)
  • nova_prod (replication from novadaq-near-db-01 to novadaq-near-db-02, to ifdb06)
  • nova_prod (replication from novadaq-far-db-03 to novadaq-far-db-04, to ifdb06)
  • nova_prod (replication from novadcs-near-logger-101)
  • pdunesp_prod
  • gm2_online_prod
  • gm2_conditions_prod *

Databases replicated from ubdaq-prod-smc to uboonedaq-seb-10 to ifdb06:

  • procdb
  • procdb_sn
  • slowmoncon_archive
  • slowmoncon
  • slowmoncon_alarm
  • slowmoncon_log
  • runconfdb
  • eandatests
  • mrttests
  • rctests
  • rctestsdev
  • rctestskazu
  • testprocdb
  • testrunconfdb

Please distribute this message to those in your organization who may be impacted.

Thank you,


MECAR: 1.2 Second Ramp studies

Added by Kevin Martin over 1 year ago

When the first 1.2s $2A ramp was tried, MECAR ramped to around 4000A and then tripped off with a No Current Halt. We determined that the PS were not ramping up as they should have.

I remembered that some of the Real Time Events in MECAR have negative time offsets. Upon checking I realized that the Bend Bus Anticipation Event Offset was set to -50mSec. Because the initial DC section of the ramp has been shortened from 80mSec to 42mSec this means the this event doesn't even occur. This is bad.

As a test I shortened the Bend Bus Anticipation Event Offset to -40mSec. This seems to be working.

The quad bus's Anticipation Event Offset had a similar but opposite problem. The Quad Bus Anticipation Event Offsets were set to 69mSec. Because the PS are ramping earlier this was causing the Quad Bus Tier 0 to not turn on in time. I have set the Horz and Vert Anticipation Event Offsets to 10mSec. This seems to be working.


Also available in: Atom