Upgrading the Interface (XML)

  1. Coordinate with the major stakeholders at the Commissioning Activities Planning (CAP) meeting to discuss a new release.

  2. Determine a date for deploying to the summit and work backwards to arrive at a date for closing the necessary work (usually XML).

    • Keep in mind dates for observing runs and special overnight work within the observatory.

    • The approximate look back time is two weeks from the end of work to summit deployment.

    • This period may be longer if extra testing or other circumstances require it.

    • Further instructions will be provided in Setting a Schedule.

  3. Present the schedule at the CAP meeting at least one week in advance of the work closure deadline.

  4. Go over the work in the appropriate release in the CAP Jira project.

    • This is identified by label of: ts_xml X.Y.

  5. Ensure that all work merged in the ts_xml repository has a ticket associated with it in the release.

  6. The scripts outlined in the Preparing for a XML Release of the vanward package can assist in aiding with the previous two steps.

  7. Send a reminder about the work closure deadline at least one day prior (if possible) and the day of the closure (definitely).

  8. Ensure that all work tickets are closed when the deadline passes.

  9. Work with the Telescope and Site build engineer on the day of the artifact build to go over any potentially open work and sign off on all software versions being used.

Upgrading SAL

While upgrading SAL usually coincides with an upgrade to the XML, it does not have to be the case. An upgrade for SAL may use the previous cycle’s XML version in order to limit the potential for surprises. The primary developer (Dave Mills) for SAL is responsible for ensuring the necessary work is completed and the new version is ready.

Upgrading DDS (OpenSplice)

Upgrading the communication backplane via updating the OpenSplice version requires care and extra lead time. The DDS oversight committee (Dave Mills, Russell Owens, Tiago Ribeiro, Michael Reuter [advisory]) will make the determination if a new version of OpenSplice is ready for incorporation into a new cycle. This determination requires dedicated testing from the main members of committee to ensure readiness. Cycle builds upgrading OpenSplice have longer testing periods split into two phases. The first phase builds a smaller section of the control system components and deploys them for testing on the TTS. Work is done to ensure that this small system is operating within the normal parameters. The second phase happens when the full system is built as part of the standard deployment operations.

Setting a Schedule

While below is an example, use your best judgment to set dates and make sure the major stakeholders are informed of the schedule by the CAP meeting.

  • Close of release work : Day 1.

  • Artifact (RPMs/JARs) build on Day 2.

  • Build conda packages and deployment artifacts Day 3 to Day 5.

  • Initial deployment to TTS on Day 8 with all CSCs available on TTS by Day 11 at noon PT.

  • Integration testing from afternoon of Day 11 to Day 12.

  • Summit deployment on the afternoon of Day 16.

From the time that the work closes to the end of deployment artifact is about one week. When things go well, the time can be slightly shorter, but the one week time frame allows for issues to be discovered and resolved. The gap between the initial TTS deployment and all CSCs available is to give the developers enough time to react to changes in the interface. If possible, try to inform folks of those changes ahead of time, but this is not always possible. Integration testing is confined to a day and a half in order to not keep the TTS closed for general use for too long. The summit deployment time is always after 5 PM summit time the following Wednesday after the TTS deployment.