Facilities Integration: Meeting Summary 1/24/2019

Added by Josh Juneau 6 months ago

We had some good discussions regarding the FESS Software/Systems Portfolio (In-Progress), software and systems review process, and location data standards.

Please continue to fill out the REDMINE wiki containing the FESS Software/Systems Portfolio, as time allows. This is an important step towards our ability to accurately review any future software or systems requests. I appreciate everyone taking the time to list any software that FESS is using which is not yet identified on the wiki page.

Software\Systems Portfolio:

We discussed some of the questions that need to be present on the software/systems request form. We are outlining each of the required questions as a first step towards choosing the best system to use for capturing these requests. We captured the questions and required features of the request form on the wiki, so please review and bring any additional suggestions to the next meeting, which is scheduled for 2/7/2019.

Request Form Questions and Requirements:

We began discussing the migration of the laboratory systems to utilization of the new location data standards. In this meeting, Dawn presented a brief overview of the location data, why it is important, and how it will impact some of the other FESS (and laboratory wide) systems. It is important that not only new systems implement the location standards, but existing systems also contain the same standard data. As a first step, we are planning to take a development version of FAMIS and update the locations to utilize the new standards, since FAMIS is one of the systems that will be impacted the most and it is utilized lab-wide by other divisions/sections. The next system to be converted will likely be Sunflower.

Lastly, we should finalize the project charter soon, so if you have any suggestions for changes or additions to the charter then please let the group know.

Facilities Integration: Meeting Summary - 1/10/2019

Added by Josh Juneau 6 months ago

Thanks for attending the first Facilities Integration Team meeting yesterday. We had some great discussions regarding the overall goals for this team, as well as good ideas on how to proceed with reviewing new requests. I’ve attached the IN PROGRESS project charter for your review. Please remember that we wish to keep the project charter high level at this time, and not very long. The overall goal for the team is to develop and implement a process for reviewing software, specialized hardware, and database enhancement requests (I’ll refer to everything together as “technical solutions”) for FESS. Please review the attached charter again and let the group know if you have any comments.

We also discussed adding a few new members to the group: Josh Kenney (Engineering), Jason Countryman (FM), Brian Petersohn (FM). Please let me know if you have any objections to adding any of these individuals to the group. If we add these three, we will have representatives from each part of FESS, so I believe that the team will be able to do an even better job of performing successful technical solution reviews.

We discussed some different options for generating a form that would allow FESS employees to submit technical solution reviews. The following options were discussed:

- Service Now (seems to be the least suitable for our requirement)
- Engineering Comment and Compliance
- Survey 1 2 3
- Online FAMIS Work Order Submission Form

I believe Dawn is going to put together a demo of Survey 1,2,3 for us…so thanks to Dawn for doing that. We can review and select one of these options at the next meeting.

Lastly, we discussed the need to put together a portfolio of FESS Software/Applications/Database Solutions. I believe that everyone agreed to move forward with using REDMINE for this purpose (at least for now), so I created a REDMINE repository and Wiki page to capture the FESS Portfolio. Please use your SERVICES username/password for access.

Protocol Compiler: New Release (v1.1)

Added by Richard Neswold about 1 year ago

A new version of the Protocol Compiler is available. It has been tagged with 'v1.1' so, if you have it checked out, you can get this version by specifying the tag:

$ git checkout v1.1

It hasn't yet been released in the console environment.

The protocol compiler is documented in the project's Wiki:

Changes from the previous version:

  • Although there have been updates to the protocol compiler over the past ten years, we never associated releases with a version number. With this release we're starting so bugs can be reported against a known version. We've arbitrarily chose this first version to be "1.1".
  • The version keyword still works, but now also generates a warning since it is deprecated. It will be completely removed in v1.2.
  • The names of anonymous structures have been simplified. Although this could cause compilation errors, most code accesses fields in the structure rather than specifying the structure by name.
  • The C++ generator understands two, new options: --c++-header-only and --c++-source-only, which prevents the generator from producing both a header and a source file.
  • The C++ generator moves some internal functions deeper in its namespaces so that two or more protocols can be used in an application. Previously an application using more than one protocol would get "duplicate symbol" errors from the linker.
  • The Erlang generator now defines enumerations using the type() directive.
  • The Erlang generator generates more-efficient unmarshal functions.

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

Added by Randy Reitz about 1 year 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 year 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 over 1 year 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,



Also available in: Atom