Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Table of Contents

Introduction

This page lists three tables with typical tasks that are required for a SIMP release:

...

  • Some test tasks from the initial release candidate table may need to be added to an interim release candidate or final release tablesubsequent tables, when the bugs fixed could impact the test results.

  • Some test and documentation tasks may be omitted because the scope of the release is very targeted (e.g., a patch SIMP release).

...

  • the list of supported OSs changes

  • manual tests have been automated

  • new capabilities must be added to the integration regression test list.

Table Conventions

Unless otherwise noted, the following conventions apply to each table:

  • Stories are indicated with a <number> ID, whereas subtasks to a story are indicated with <parent number>-.<child number> ID.

  • The Blocker field of a story is used to indicate that this story/subtask requires the listed stories/subtasks to be completed before it can be done.

  • The Story Points field of a subtask may contain an initial guess at the appropriate story points for that subtask. Adjust as needed!

  • When Y appears in one of the OS fields of a story (e.g. EL8) , that story will be replicated for the permutation noted.

  • When Y appears in one of the OS fields of a subtask, that subtask will be replicated for the permutation noted within the story.

  • N, -, and a blank entry are all treated as ‘do not replicate’ indicators.

  • The Notes field will not be included in the ticket and is intended for maintainers of these tables.

Initial Release Candidate Tickets

The table below lists the typical tasks that are required for the initial release candidate (e.g., ‘Alpha’). The largest number of bugs are found during the initial release candidate. So, some of the tasks may have to be repeated after bugs are fixed and some of the tasks may be blocked until bugs are fixed. The sprint planning for this release should be flexible, accordingly.

ID

Ticket Summary (< 100 chars)

Description

Component

Blockers

Story Points

EL7

EL8

OEL7

OEL8

RH7

RH8

Notes

1

Release Components

Identify components to be released, verify tests pass, push annotated tags, update SIMP release confluence page. https://simp.readthedocs.io/en/latest/contributors_guide/maintenance/Tagging_and_Releasing_Components.html

-

3

-

-

-

-

-

-

1.1

Identify components to release

-

1

-

-

-

-

-

-

1.2

Release components

1.1

2

-

-

-

-

-

-

102

Create initial SIMP changelog

simp-doc

8

-

-

-

-

-

-

10.1

Create changelog

6

-

-Examine changes made to the simp-core project since the previous SIMP release tag (e.g., SIMP-6.5.0-1), as well as changes made to its SIMP dependencies listed in the Puppetfile.pinned.

For simp-core changes, examine the following:

  • simp-core changes noted in its git logs

  • src/assets/simp/build/simp.spec %changelog changes

For changes for an individual SIMP component, examine changes noted both in its git logs and its CHANGELOG file or %changelog section of its build/<component>.spec file. The changes to examine are those from the version listed in the Puppetfile.pinned of the last SIMP release.

simp-doc

8

-

-

-

-

10.2

Review changes

2

-

-

-

-

-

-

2

Update simp-core pre-release tests with release-specific changes

Update simp-core
  • This changelog needs to be done early because it informs what release-specific tests need to be executed and which sections of the documentation may need updates.

  • This is a tedious, time-consuming job!

  • Liz and Jeanne both have utilities to gather the changes.

  • The deps:changelog rake task in simp-core should not be used because it does not accurately take into account individual component changes.

2.1

Create changelog

6

-

-

-

-

-

-

2.2

Review changes

2.1

2

-

-

-

-

-

-

3

Update simp-core pre-release tests with release-specific changes

Update simp-core default, ipa, install_from_tar, and simp_lite acceptance test suites for release-specific changes. This includes updating the nodesets and .gitlab-ci.yml for any changes to the supported OSs.

simp-core

-

5

-

-

-

-

-

-

Ideally, this should be done after the initial changelog has been generated, as the changelog informs the work to be done.

Tests will be executed for the appropriate OSs permutations in the nodeset, but separate tickets per OS should not be created.

23.1

Update tests and nodesets

-

4

-

-

-

-

-

-

23.2

Review updates

23.2

1

-

-

-

-

-

-

34

Update simp-packer with release-specific changes

Update simp-packer for release-specific changes. Be sure to tag the previous simp-packer version, if the updates will break testing functionality built for the prior SIMP release.

simp-packer

-

3

-

-

-

-

-

-

Ideally, this should be done after the initial changelog has been generated, as the changelog informs the work to be done.

34.1

Update code and documentation

-

2

-

-

-

-

-

-

3-4.2

Review changes

34.1

1

-

-

-

-

-

-

115

Identify release-specific tests and document documentation updates

Based on the initial Changelog for the release, identify (1) integration tests that must be done with a fully configured SIMP server and (if necessary) clients and (2) simp-doc documentation that may be affected by the changes. The tests should be tests that are not adequately tested in component acceptance tests.

102

7

-

-

-

-

-

-

115.1

Determine release-specific manual tests

4

115.2

Determine simp-doc pages that need to be reviewed for accuracy or revised

Identify pages that require an indepth examination.in-depth examination or major revision

2

-

-

-

-

-

-

115.3

Create tickets for each test and simp-doc page review

5.1, 5.2

1

-

-

-

-

-

-

46

Update simp-core with released components

Update simp-core files (Puppetfile.pinned, metadata.json, src/assets/simp/build/simp.spec) and verify ISOs can be built and the default, ipa, and simp_lite acceptance test suites pass.

You must set the SIMP_FULL_MATRIX variable to have all the tests run in a GitLab.

simp-core

1, 23

3

-

-

-

-

-

-

46.1

Update files , build ISOs and execute testsand build ISOs for supported OSs

You may need to update package lists for the ISO builds.

-

2

-

-

-

-

-

-

46.2

Review updates

4Verify acceptance tests

Verify the default, ipa, and simp_lite acceptance tests pass with new components. No major test revisions should be needed.

6.1

1

-

-

-

-

-

-5

Tests should already been updated for major changes in ID 3 in this table.

6.3

Review updates

Make sure to verify versions in Puppetfile.pinned, metdata.json and src/assets/simp/build/simp.spec.

6.2

1

-

-

-

-

-

-

7

Create test ISO, and publish the ISO and its tar file

simp-core

46

2

Y

Y

-

-

-

-

This step may actually have to be done several times before we get to an initial release candidate build that can be published. If additional tickets are warranted, they can be created on the fly.

57.1

Build ISO

Use official RPM signing keys when the artifacts are to be published anywhere at simp-project.com.

-

1

Y-Y

-

-

-

-

-

57.2

Publish artifacts

Interim artifacts may be published to unstable folders at simp-project.com or other unofficial shared locations.

57.1

1

-

-

-

-

-

-

68

Validate ISO by building packer boxes (BIOS and UEFI)

Use simp-packer to build SIMP server packer boxes. Basic bootstrap validation is done as part of the packer build.

57

Y

Y

-

-

-

-

6

8.1

Build

Validate ISO by building packer boxes (BIOS)

Use simp-packer to build SIMP server packer boxes. Basic bootstrap validation is done as part of the packer build.

  • BIOS boot box

with
  • FIPS-enabled

and
  • , encrypted disk

  • BIOS boot box FIPS-enabled, unencrypted disk

  • BIOS boot box FIPS-disabled, encrypted disk

  • BIOS boot box FIPS-disabled, unencrypted disk

7

Y

Y

-

-

-

-

6

8.2

Build BIOS boot box with FIPS enabled and unencrypted disk

-

-

-

-

-

-

-

6.3

Build BIOS boot box with FIPS disabled and encrypted disk

-

-

-

-

-

-

-

6.4

Build BIOS boot box with FIPS disabled and unencrypted disk

Validate ISO by building packer boxes (UEFI)

Use simp-packer to build SIMP server packer boxes. Basic bootstrap validation is done as part of the packer build.

  • UEFI boot box FIPS-enabled, encrypted disk

  • UEFI boot box FIPS-enabled, unencrypted disk

  • UEFI boot box FIPS-disabled, encrypted disk

  • UEFI boot box FIPS-disabled, unencrypted disk

9

Verify installation from RPMs in tar file

Run simp-core’s install_from_tar test using the tar file generated from an ISO build.

simp-core

7

-

-

-

-

-

-

-

69.5

Build UEFI boot box with FIPS enabled and encrypted disk

-

-

-

-

-

-

-

6.6

Build UEFI boot box with FIPS enabled and unencrypted disk

1

Execute test

See https://github.com/simp/simp-core/blob/master/spec/acceptance/suites/README.md for description of environment variables that can be set to point to the tar file.

1

Y

Y

-

-

-

-

10

-

-

-

6.7

Build UEFI boot box with FIPS disabled and encrypted disk

-Create upgrade instructions

Document any steps that are needed outside of the generic upgrade instructions.  Also look for any unusual messages emitted during RPM upgrade.

simp-doc

7

10

Y

Y

-

-

-

-

10.1

Manually execute upgrade with FIPS enabled

4

-

-

-

-

-

-

6-8

Build UEFI boot box

10.2

Manually execute upgrade with FIPS disabled and unencrypted disk

-1

-

-

-

-

-

-

7

Verify installation from RPMs in tar file

Run simp-core’s install_from_tar test

simp-core

5

10.3

Write upgrade instructions

4

-

-

-

-

-

-

-

-

7-1

Execute test

See https://github.com/simp/simp-core/blob/master/spec/acceptance/suites/README.md for description of environment variables that can be set to point to the tar file

1

Y

Y

10.4

Review instructions

Review the instructions for clarity, grammar, spelling, formatting, etc. Verification will be done in a separate ticket

10.3

1

-

-

-

-

-

-

811

Create Verify upgrade instructionsDocument any steps

that are needed outside of the generic upgrade instructions.  Also look for any unusual messages emitted during RPM upgrade.Verify upgrade instructions and make any necessary adjustments to them.

simp-doc4

10

Y

Y

-

-

-

-

8-11.1

Manually execute upgrade with FIPS enabled

4Execute instructions

2

-

-

-

-

-

-

8-11.2

Manually execute upgrade with FIPS disabledUpdate instructions

1

-

-

-

-

-

-

8-3

Write upgrade instructions

4

-

-

-

-

-

-

8-4

Review instructions

Review the instructions for clarity, grammar, spelling, formatting, etc. Verification will be done in a separate ticket

1

-12

Verify PXE boot UEFI

Manually verify clients can PXE boot (UEFI) from a SIMP-managed tftpboot server. https://simp-project.atlassian.net/browse/SIMP-6925 contains links to tickets with descriptions of what others have done previously to test these capabilities.

  • Verify PXE boot (UEFI) FIPS enabled, disk encrypted, same OS as tftpboot server

  • Verify PXE boot (UEFI) FIPS enabled, disk unencrypted, same OS as tftpboot server

  • Verify PXE boot (UEFI) FIPS disabled, disk encrypted, same OS as tftpboot server

  • Verify PXE boot (UEFI) FIPS disabled, disk unencrypted, same OS as tftpboot server

  • Verify PXE boot (UEFI) FIPS enabled, disk encrypted, clients from tftpboot server of different OS

7

Y

Y

-

-

-

-

-

9

Verify upgrade instructions

Verify upgrade instructions and make any necessary adjustments to them.

simp-doc

8

Y

Y

-

-

-

-

9-1

Execute instructions

2

-

-

-

-

-

-

9-2

Update instructions

1

-

-

-

-

-

-

13

Verify PXE boot UEFI

TODO: Automate these tests

13

Verify PXE boot BIOS

Manually verify clients can PXE boot (UEFIBIOS) from a SIMP-managed tftpboot server

5

Y

Y

-

-

-

-

13-1

Verify PXE boot (UEFI) FIPs

  • Verify PXE boot (BIOS) FIPS enabled, disk encrypted, same OS as tftpboot server

-

-

-

-

-

-

13-2

13-3

  • Verify PXE boot (

UEFI
  • BIOS)

FIPs
  • FIPS enabled, disk unencrypted, same OS as tftpboot server

-

-

-

-

-

-

  • Verify PXE boot (

UEFI
  • BIOS)

FIPs
  • FIPS disabled, disk encrypted, same OS as tftpboot server

-

-

-

-

-

-

13-4

  • Verify PXE boot (

UEFI
  • BIOS)

FIPs

13-5

PVerify XE boot (UEFI) FIPs
  • FIPS disabled, disk unencrypted, same OS as tftpboot server

-

-

-

-

-

-

  • Verify PXE boot (BIOS) FIPS enabled, disk encrypted, clients from tftpboot server of different OS

-7

Y

Y

-

-

-

--

ODO: Finish automation of these tests

14

Verify PXE boot BIOSnon-standard ISO UEFI boot options

Manually verify clients can PXE boot (BIOS) from a SIMP-managed tftpboot serverthe choose your own partitions and minimum installation ISO boot options

7

Y

Y

-

-

-

-

14-.1

Verify PXE boot (BIOS) FIPs enabled, disk encrypted, same OS as tftpboot serverthe choose your own partitions option

-

-

-

-

-

-

14-.2

Verify PXE boot (BIOS) FIPs enabled, disk unencrypted, same OS as tftpboot serverthe minimum installation option

-

-

-

-

-

-

14-3

Verify PXE boot (BIOS) FIPs disabled, disk encrypted, same OS as tftpboot server

-

-15

Verify non-standard ISO BIOS boot options

Manually verify the ‘choose your own partitions' and ‘minimum installation’ ISO boot options

7

Y

Y

-

-

-

-

14-4

Verify PXE boot (BIOS) FIPs disabled, disk unencrypted, same OS as tftpboot server

15.1

Verify the choose your own partitions option

-

-

-

-

-

-

14-5

Verify PXE boot (BIOS) FIPs enabled, disk encrypted, clients from tftpboot server of different OS

15.2

Verify the minimum installation option

-

-

-

-

-

-

15

Verify non-standard ISO UEFI boot options

Manually verify the choose your own partitions and minimum installation ISO boot options

516

Dogfood released modules and assets

Use released modules in development environments that exercise as many of the modules as possible. Install RPMs of released assets on SIMP servers.

6

Y

Y

-

-

-

-

15-16.1

Verify the choose your own partitions optionDeploy modules to development environments

Update Puppetfiles for development environments and deploy the modules.

-

-

-

-

-

-

15-2

Verify the minimum installation option

16.2

Install asset RPMs on SIMP server

Install RPMs and watch for any RPM installation error messages.

-

-

-

-

-

-

16

Verify non-standard ISO BIOS boot options

Manually verify the ‘choose your own partitions' and ‘minimum installation’ ISO boot options

5

Y

Y

.3

Examine logs for issues

16.1, 16.2

-

-

-

-

16

-

1

Verify the choose your own partitions option

-

-

-

-

-

-

16-2

Verify the minimum installation option17

Execute misc manual tests

Miscellaneous tests that are not addressed (fully) with automation.

6

Y

Y

-

-

-

-

-

-

17

Dogfood released modules and assets

Use released modules in development environments that exercise as many of the modules as possible. Install RPMs of released assets on SIMP servers.

5

Y

Y

-

-

-

-

17-1

Deploy modules to development environments

Update Puppetfiles for development environments and deploy the modules.

17.1

Verify rsyslog local and forwarded logging in simp-core default suite

simp-core's default suite has an extensive rsyslog integration test for local logging and log forwarding that does not use a mock sender ('logger'). Due to rsyslog itself, the rsyslog forwarding verifications have proven to be unreliable. As a stopgap measure, the tests were modified to skip any rsyslog test that fails in the simp-core default suite, in lieu of failing. Unfortunately, this has the potential to hide actual problems. So this ticket is to verify manually that all the failed checks executed in this test actually work.

1

-

-

-

-

-

-

17-2

Install asset RPMs on SIMP server

Install RPMs and watch for any RPM installation error messages.

-

-

-

-

-

-

17-3

Examine logs for issues

.2

Verify compliance report in simp-core default suite

Examine the compliance report generated by the simp-core default suite and verify there are no incorrect mappings or unexpected non-compliance. (There will be some non-compliance for overrides that allow the test to run.)

1

-

-

-

-

-

--

18

23

Execute misc manual tests

Miscellaneous tests that are not addressed (fully) with automationVerify poss scenario

Manually verify SIMP server and a client operate under the expected security measures when the SIMP server is bootstrapped with the ‘poss’ scenario.

Y

Y

-

-

-

-

23-1

Verify rsyslog local and forwarded logging in simp-core default suite

simp-core's default suite has an extensive rsyslog integration test for local logging and log forwarding that does not use a mock sender ('logger'). Due to rsyslog itself, the rsyslog forwarding verifications have proven to be unreliable. As a stopgap measure, the tests were modified to skip any rsyslog test that fails in the simp-core default suite, in lieu of failing. Unfortunately, this has the potential to hide actual problems. So this ticket is to verify that all the checks executed in this test actually work.

1

-

-

-

-

-

-

23-2

Verify compliance report in simp-core default suite

Examine the compliance report generated by the simp-core default suite and verify there are no incorrect mappings or unexpected non-compliance. (There will be some non-compliance for overrides that allow the test to run.)

1

-

-

-

-

-

-

24

Verify poss scenario

Manually verify SIMP server and a client operate under the expected security measures when the SIMP server is bootstrapped with the ‘poss’ scenario.

Y

Y

-

-

-

-

Verify using a SIMP server and kickstart client with the same OS.

24-1

Bootstrap a SIMP server and verify all security measures are enforced.

24-2

Kick a client and verify no security measures are enforced

  • If the auditd service is running, it has no rules no rules. ('auditctl -l' returns 'No rules’)

  • If the firewalld service is running, the default zone is not the 99_simp zone. ('firewall-cmd --get-default-zone' returns 'public')

  • haveged

    Verify using a SIMP server and kickstart client with the same OS.

    TODO: Automate this test

    18.1

    Bootstrap a SIMP server and verify all security measures are enforced.

    -

    -

    -

    -

    -

    -

    18.2

    Kick a client and verify no security measures are enforced

    ID

    Ticket Summary (< 100 chars)

    Description

    Component

    Blockers

    Story Points

    EL7

    EL8

    OEL7

    OEL8

    RH7

    RH8

    Notes

    1

    Release Components

    Identify components to be released, verify tests pass, push annotated tags, update SIMP release confluence page. https://simp.readthedocs.io/en/latest/contributors_guide/maintenance/Tagging_and_Releasing_Components.html

    -

    • If the auditd service is running, it has no rules. ('auditctl -l' returns 'No rules’)

    • If the firewalld service is running, the default zone is not the 99_simp zone. ('firewall-cmd --get-default-zone' returns 'public')

    • haveged service does not exist. ('systemctl status haveged' returns 'Unit haveged.service could not be found.')

    • logrotate configuration, /etc/logrotate.conf, does not have 'include /etc/logrotate.simp.d'

    • pam configuration, /etc/pam.d/system-auth does not have "This file managed by Puppet"

    • SIMP-specific PKI directories, /etc/pki/simp/ and /etc/pki/simp_apps/, do not exist.

    • sssd service should not be running and should not be configured. ( 'systemctl status sssd' returns 'Active: inactive (dead) and there is no/etc/sssd/sssd.conf)

    • stunnel service does not exist. ( 'systemctl status havegedstunnel' returns 'Unit havegedstunnel.service could not be found.')

    • logrotate configuration, rsyslog service may be running but is not configured for SIMP, i.e.
      /etc/logrotatersyslog.conf , does not have 'include $IncludeConfig /etc/logrotatersyslog.simp.d'pam configuration, /*.conf'

    • tcpwrappers is not configured on OSs that support tcpwrappers. (If /etc/pam.d/system-auth does not have "This file managed by Puppet"

    • SIMP-specific PKI directories, /etc/pki/simp/ and /etc/pki/simp_apps/, do not exist.

    • sssd service should not be running and should not be configured. ( 'systemctl status sssd' returns 'Active: inactive (dead) and there is no/etc/sssd/sssd.conf)

    • stunnel service does not exist. ( 'systemctl status stunnel' returns 'Unit stunnel.service could not be found.')

    • rsyslog service may be running but is not configured for SIMP, i.e.
      /etc/rsyslog.conf does not have '$IncludeConfig /etc/rsyslog.simp.d/*.conf'

    • tcpwrappers is not configured on OSs that support tcpwrappers. (If /etc/hosts.allow exists, it is just comments. Same for /etc/hosts.deny )

    Interim Release Candidate Tickets

    The table below lists the typical tasks that are required for the interim release candidates (e.g., ‘Beta’, ‘RC1’). Fewer and fewer bugs are found with each interim release candidate. Accordingly, any manual integration testing should be targeted to verification of the bug fixes, whereas as many automated integration tests as resources allow should be executed! Be sure to examine the manual tests in this table and the initial release candidate tickets table and customize before generating tickets.

    • hosts.allow exists, it is just comments. Same for /etc/hosts.deny )

    -

    -

    -

    -

    -

    -

    19

    Benchmark with SCAP scan

    This test is intended to find deficiencies in the enforced DISA STIG security settings for SIMP modules

    Y

    Y

    -

    -

    -

    -

    19.1

    Execute scan and analyze results

    Execute the SCAP scan on a FIPS-enabled, disk-encrypted SIMP server packer box for which compliance has been enforced and then analyze the results for any SIMP deficiencies. Looking for system configuration that is not correctly configured for which the compliance report does not indicate an exception. Check may reveal component behavior or component compliance data that needs to be updated.

    -

    -

    -

    -

    -

    -

    19.2

    Create tickets for deficiencies

    Create tickets for any component deficiencies found.

    -

    -

    -

    -

    -

    -

    Interim Release Candidate Tickets

    The table below lists the typical tasks that are required for the interim release candidates (e.g., ‘Beta’, ‘RC1’). Fewer and fewer bugs are found with each interim release candidate. Any manual integration testing should be targeted to verification of the bug fixes, whereas as many automated integration tests as resources allow should be executed!

    Depending upon the bug fixes included in this release candidate, tests identified in the initial release tickets table may need to be re-executed. So, be sure to add those tasks to your copy of this table before generating tickets.

    ID

    Ticket Summary (< 100 chars)

    Description

    Component

    Blockers

    Story Points

    EL7

    EL8

    OEL7

    OEL8

    RH7

    RH8

    Notes

    1

    Release Components

    Identify components to be released, verify tests pass, push annotated tags, update SIMP release confluence page. https://simp.readthedocs.io/en/latest/contributors_guide/maintenance/Tagging_and_Releasing_Components.html

    -

    3

    -

    -

    -

    -

    -

    -

    1.1

    Identify components to release

    -

    1

    -

    -

    -

    -

    -

    -

    1.2

    Release components

    1.1

    2

    -

    -

    -

    -

    -

    -

    2

    Update simp-core with released components

    Update simp-core files (Puppetfile.pinned, metadata.json, src/assets/simp/build/simp.spec) and verify ISOs can be built and the default, ipa, and simp_lite acceptance test suites pass.

    You must set the SIMP_FULL_MATRIX variable to have all the tests run in a GitLab.

    simp-core

    1

    3

    -

    -

    -

    -

    -

    -

    2.1

    Update files and build ISOs for supported OSs

    You may need to update package lists for the ISO builds.

     

    -

    2

    -

    -

    -

    -

    -

    -

     

    2.2

    Verify acceptance tests

    Verify the default, ipa, and simp_lite acceptance tests pass with new components. No major test revisions should be needed.

     

    2.1

    1

    -

    -

    -

    -

    -

    -

    2.3

    Review updates

    Make sure to verify versions in Puppetfile.pinned, metdata.json and src/assets/simp/build/simp.spec.

     

    2.2

    1

    -

    -

    -

    -

    -

    -

     

    3

    Create test ISO, and publish the ISO and its tar file

    simp-core

    2

    2

    Y

    Y

    -

    -

    -

    -

    3.1

    Build ISO

    Use official RPM signing keys when the artifacts are to be published anywhere at simp-project.com.

    -

    1

    -

    -

    -

    -

    -

    -

    3.2

    Publish artifacts

    Interim artifacts may be published to unstable folders at simp-project.com or other unofficial shared locations.

    3.1

    1

    -

    -

    -

    -

    -

    -

    4

    Validate ISO by building packer boxes (BIOS and UEFI)

    Use simp-packer to build SIMP server packer boxes. Basic bootstrap validation is done as part of the packer build.

    3

    Y

    Y

    -

    -

    -

    -

    4.1

    Validate ISO by building packer boxes (BIOS)

    Use simp-packer to build SIMP server packer boxes. Basic bootstrap validation is done as part of the packer build.

    • BIOS boot box FIPS-enabled, encrypted disk

    • BIOS boot box FIPS-enabled, unencrypted disk

    • BIOS boot box FIPS-disabled, encrypted disk

    • BIOS boot box FIPS-disabled, unencrypted disk

    4.2

    Validate ISO by building packer boxes (UEFI)

    Use simp-packer to build SIMP server packer boxes. Basic bootstrap validation is done as part of the packer build.

    • UEFI boot box FIPS-enabled, encrypted disk

    • UEFI boot box FIPS-enabled, unencrypted disk

    • UEFI boot box FIPS-disabled, encrypted disk

    • UEFI boot box FIPS-disabled, unencrypted disk

    5

    Verify installation from RPMs in tar file

    Run simp-core’s install_from_tar test

    simp-core

    2

    -

    -

    -

    -

    -

    -

    -

    This test can be omitted if there are no changes to component packaging since the previous candidate. Component behavior is already tested by the simp-core default suite with each simp-core check-in.

    5.1

    Execute test

    See https://github.com/simp/simp-core/blob/master/spec/acceptance/suites/README.md for description of environment variables that can be set to point to the tar file

    1

    Y

    Y

    -

    -

    -

    -

    6

    Update Changelog for bug fixes

    simp-doc

    2

    3

    -

    -

    -

    -

    -

    -

    6.1-1

    Identify components to releasebug fixes and update changelog

    -

    12

    -

    -

    -

    -

    -

    -

    1-6.2

    Release componentsReview changes

    16.1

    21

    -

    -

    -

    -

    -

    -

    4

    Update simp-core with released components

    Update simp-core files (Puppetfile.pinned, metadata.json, src/assets/simp/build/simp.spec) and verify ISOs can be built and the default, ipa, and simp_lite acceptance test suites pass.

    You must set the SIMP_FULL_MATRIX variable to have all the tests run in a GitLab.

    simp-core

    1

    37

    Dogfood released modules and assets

    Use released modules in development environments that exercise as many of the modules as possible. Install RPMs of released assets on SIMP servers.

    2

    Y

    Y

    -

    -

    -

    -

    7.1

    Deploy modules to development environments

    Update Puppetfiles for development environments and deploy the modules.

    -

    -

    -

    -

    -

    -

    7.2

    Install asset RPMs on SIMP server

    Install RPMs and watch for any RPM installation error messages.

    -

    -

    -

    -

    -

    -

    4-1

    Update files, build ISOs and execute tests

    -

    2

    7.3

    Examine logs for issues

    -

    -

    -

    -

    -

    -

    -

    4-2

    Review updates

    4.1

    1

    -

    -

    -

    -

    -

    -

    5

    Create test ISO, and publish the ISO and its tar file

    simp-core

    4

    2

    Y

    Y

    -

    -

    -

    -

    5-1

    Build ISO

    Use official RPM signing keys when the artifacts are to be published anywhere at simp-project.com.

    -

    1

    -

    -

    -

    -

    -

    -

    5-2

    Publish artifacts

    Interim artifacts may be published to unstable folders at simp-project.com or other unofficial shared locations.

    1

    -

    -

    -

    -

    -

    -

    6

    Validate ISO by building packer boxes

    Use simp-packer to build SIMP server packer boxes. Basic bootstrap validation is done as part of the packer build.

    5

    Y

    Y

    Release Tickets

    The table below lists the typical tasks that are required for the final release. By the time we get to this phase of the release process, there are few, if any bugs found, and very little manual testing is required. There are quite a number of documentation review tickets, however. The user documentation tickets are required for each major release, nice-to-have for each minor release, and not necessary for each patch release. They will need to be updated each time the user documentation undergoes structural changes.

    As with interim releases, depending upon the bug fixes included in this release candidate, tests identified in the initial release tickets table may need to be re-executed. So, be sure to copy in those tasks into your copy of this table before generating tickets.

    ID

    Ticket Summary (< 100 chars)

    Description

    Component

    Blockers

    Story Points

    EL7

    EL8

    OEL7

    OEL8

    RH7

    RH8

    Notes

    1

    Release Components

    Identify components to be released, verify tests pass, push annotated tags, update SIMP release confluence page. https://simp.readthedocs.io/en/latest/contributors_guide/maintenance/Tagging_and_Releasing_Components.html

    NOTE: This excludes simp-doc, which is addressed a separate ticket after all documentation updates have been completed.

    -

    3

    -

    -

    -

    -

    6-1

    Build BIOS boot box with FIPS enabled and encrypted disk

    -

    --

    -

    1.1

    Identify components to release

    -

    1

    -

    -

    -

    -

    -

    6

    -

    2

    Build BIOS boot box with FIPS enabled and unencrypted disk

    1.2

    Release components

    1.1

    2

    -

    -

    -

    -

    -

    -

    2

    Update simp-

    6-3

    Build BIOS boot box with FIPS disabled and encrypted disk

    -

    -

    -

    -

    -

    -

    -

    6-4

    Build BIOS boot box with FIPS disabled and unencrypted disk

    -

    core with released components

    Update simp-core files (Puppetfile.pinned, metadata.json, src/assets/simp/build/simp.spec) and verify ISOs can be built and the default, ipa, and simp_lite acceptance test suites pass.

    You must set the SIMP_FULL_MATRIX variable to have all the tests run in a GitLab.

    All components in the Puppetfile.pinned except simp-doc should be referencing a GitHub tag. simp-doc is addressed in another ticket.

    simp-core

    1

    3

    -

    -

    -

    -

    -

    -

    6-5

    Build UEFI boot box with FIPS enabled and encrypted disk

    -

    2.1

    Update files and build ISOs for supported OSs

    You may need to update package lists for the ISO builds.

     

    -

    2

    -

    -

    -

    -

    -

    -

    6-6

    Build UEFI boot box with FIPS enabled and unencrypted disk

    -

    -

    -

     

    2.2

    Verify acceptance tests

    Verify the default, ipa, and simp_lite acceptance tests pass with new components. No major test revisions should be needed.

     

    2.1

    1

    -

    -

    -

    -

    6

    -

    7

    Build UEFI boot box with FIPS disabled and encrypted disk

    -

    -

    -

    -

    -

    -

    -

    6-8

    Build UEFI boot box with FIPS disabled and unencrypted disk

    -

    2.3

    Review updates

    Make sure to verify versions in Puppetfile.pinned, metdata.json and src/assets/simp/build/simp.spec.

     

    2.2

    1

    -

    -

    -

    -

    -

    -

    73

    Verify installation from RPMs in tar file

    Run simp-core’s install_from_tar test

    simp-core

    5

    -

    -

    -

    -

    -

    -

    -

    This test can be omitted if there are no changes to component packaging since the previous candidate. Component behavior is already tested by the simp-core default suite with each simp-core check-in.

    7-1

    Execute test

    See https://github.com/simp/simp-core/blob/master/spec/acceptance/suites/README.md for description of environment variables that can be set to point to the tar file

    1

    Y

    Ysimp/simp_core meta module

    Verify that the simp/simp_core meta module has appropriate dependencies and its dependencies have all been published to PuppetForge by running the install_from_core_module test suite.

    2

    -

    -

    -

    -

    -

    -

    3.1

    Execute check for PuppetForge publication

    Execute ‘bundle exec rake puppetfile:check’ and examine output to identify any modules that have not been published to PuppetForge

    -

    -

    -

    -

    -

    12

    Update Changelog for bug fixes

    simp-doc1

    3

    -

    .2

    Publish any missing modules to PuppetForge

    -

    -

    -

    -

    -

    12

    -

    1

    Identify bug fixes and update changelog

    -

    2

    3.3

    Update the install_from_core_module test with any release-specific changes

    -

    -

    -

    -

    -

    -

    12-2

    Review changes

    12.1

    1

    3.4

    Execute the install_from_core_module test

    -

    -

    -

    -

    -

    -

    174

    Dogfood released modules and assets

    Use released modules in development environments that exercise as many of the modules as possible. Install RPMs of released assets on SIMP servers.

    52

    Y

    Y

    -

    -

    -

    -

    17-4.1

    Deploy modules to development environments

    Update Puppetfiles for development environments and deploy the modules.

    -

    -

    -

    -

    -

    -

    17-4.2

    Install asset RPMs on SIMP server

    Install RPMs and watch for any RPM installation error messages.

    -

    -

    -

    -

    -

    -

    17-4.3

    Examine logs for issues

    -

    -

    -

    -

    -

    -

    Final Release Tickets

    The table below lists the typical tasks that are required for the final release. By the time we get to this phase of the release process, there are few, if any bugs found, and very little manual testing is required. There are quite a number of documentation review tickets, however.

    ID

    Ticket Summary (< 100 chars)

    Description

    Component

    Blockers

    Story Points

    EL7

    EL8

    OEL7

    OEL8

    RH7

    RH8

    Notes

    1

    Release Components

    Identify components to be released, verify tests pass, push annotated tags, update SIMP release confluence page. https://simp.readthedocs.io/en/latest/contributors_guide/maintenance/Tagging_and_Releasing_Components.html

    NOTE: simp-doc is addressed in its own ticket.

    -

    35

    Update Changelog for bug fixes

    simp-doc

    2

    3

    -

    -

    -

    -

    -

    -

    5.1

    Identify bug fixes and update changelog

    -

    2

    -

    -

    -

    -

    -

    -

    5.2

    Review changes

    5.1

    1

    -

    -

    -

    -

    -

    -

    6

    Review ‘Quick Start’ Guide

    Review and update as necessary. This is a general review to make sure the information is accurate and intelligible.

    simp-doc

    -

    -

    1

    -

    -

    1

    Identify

    components to release-

    -

    6.1

    -Review and update

    -

    -

    -

    -

    -

    1

    -

    6.2

    Release componentsReview changes

    16.12

    -

    -

    -

    -

    -

    -

    12

    Update Changelog for bug fixes

    7

    Review ‘Getting Started’ Guide

    Review and update as necessary. This is a general review to make sure the information is accurate and intelligible.

    simp-doc

    1

    3

    -

    -

    -

    -

    -

    -

    12-7.1

    Identify bug fixes Review and update changelog

    -

    2

    -

    -

    -

    -

    -

    -

    12-7.2

    Review changes

    127.12

    1

    -

    -

    -

    -

    -

    -

    218

    Review user documentationGeneral review of user documentation. Intent is ‘User Guide’

    Review and update as necessary. This is a general review to make sure the information is current accurate and intelligible. Does not include ‘Changelog’, ‘Contributing to SIMP’, ‘Security Concept of Operations’, ‘Security Control Mapping’, ‘Vulnerability Supplement’ and ‘License’ sections.

    simp-doc

    -

    -

    -

    -

    -

    -

    This is required for each major release, nice-to-have for each minor release, and not necessary for each patch release.

    Subtasks should correspond to major sections of the documentation, an will need to be updated accordingly when the docs structure changes.

    21

    -

    8.1

    Review ‘Quick Start’Review and update as necessary

    -

    -

    -

    -

    -

    -

    21-3

    Review ‘Getting Started’

    8.2

    Review changes

    8.2

    -

    -

    -

    -

    -

    -

    8.3

    Review Upgrade Instructions

    Ensure nothing has changed since the original

    9

    Review ‘HOWTO’

    Review and update as necessary. This is a general review to make sure the information is accurate and intelligible.

    simp-doc

    -

    -

    -

    -

    -

    21

    -

    4

    Review ‘User Guide’

    9.1

    Review and update as necessary

    -

    -

    -

    -

    -

    -

    21-59.2

    Review ‘HOWTO’Review and update as necessarychanges

    9.2

    -

    -

    -

    -

    -

    -

    21-6

    10

    Review ‘FAQ’

    Review and update as necessary. This is a general review to make sure the information is accurate and intelligible.

    simp-doc

    -

    -

    -

    -

    -

    21

    -

    7

    Review ‘Help’ and ‘Contact’ sections

    10.1

    Review and update as necessary

    -

    -

    -

    -

    -

    -

    21-810.2

    Review ‘Glossary of Terms’Review and update as necessarychanges

    10.2

    -

    -

    -

    -

    -

    -

    2211

    Review security documentationGeneral review of security-related documentation. Intent is ‘Help’ and ‘Contact’ sections

    Review and update as necessary. This is a general review to make sure the information is current accurate and intelligible.

    simp-doc

    -

    -

    -

    -

    -

    -

    11.1

    Review and update

    -

    -

    -

    This is required for each major release, nice-to-have for each minor release, and not necessary for each patch release.

    Subtasks should correspond to major sections of the documentation, an will need to be updated accordingly when the docs structure changes.

    22-1

    Review ‘Security Concept of Operations’-

    -

    -

    11.2

    Review changes

    11.2

    -

    -

    -

    -

    -

    -

    12

    Review ‘Glossary of Terms’

    Review and update as necessary. This is a general review to make sure the information is accurate and intelligible.

    simp-doc

    -

    -

    -

    -

    -

    22

    -

    2

    Review ‘Security Control Mapping’

    12.1

    Review and update as necessary

    -

    -

    -

    -

    -

    -

    12.2

    Review changes

    12.2

    -

    -

    -

    -

    -

    22-3

    Review ‘Vulnerability Supplement’

    Review and update as necessary

    --

    13

    Review ‘Security Concept of Operations’

    Review and update as necessary. This is a general review to make sure the information is accurate and intelligible.

    simp-doc

    -

    -

    -

    -

    -23

    Finalize simp-doc

    23-1

    Remove any reference to release candidates

    23-2

    Release

    4

    Update simp-core with released components, including simp-doc

    Update simp-core files (Puppetfile.pinned, metadata.json, src/assets/simp/build/simp.spec) and verify ISOs can be built and the default, ipa, and simp_lite acceptance test suites pass.

    You must set the SIMP_FULL_MATRIX variable to have all the tests run in a GitLab.

    All components in the Puppetfile.pinned should be referencing a GitHub tag.

    simp-core

    1

    3

    -

    -

    13.1

    Review and update

    -

    -

    -

    -

    -

    -

    13.2

    Review changes

    13.2

    -

    -

    -

    -

    -

    -

    14

    Review ‘Security Control Mapping’

    Review and update as necessary. This is a general review to make sure the information is accurate and intelligible.

    simp-doc

    -

    -

    -

    -

    -

    -

    14.1

    Review and update

    -

    -

    -

    -

    -

    -

    14.2

    Review changes

    14.2

    -

    -

    -

    -

    4-1

    Update files, build ISOs and execute tests

    -

    2-

    -

    15

    Review ‘Vulnerability Supplement’

    Review and update as necessary. This is a general review to make sure the information is accurate and intelligible.

    simp-doc

    -

    -

    -

    -

    -

    -

    4-2

    Review updates

    Make sure there are no version discrepancies in the Puppetfile.pinned, metadata.json and simp.spec files.

    4.1

    1

    15.1

    Review and update

    -

    -

    -

    -

    -

    -

    18

    Verify simp/simp_core meta module

    Verify that the simp/simp_core meta module has appropriate dependencies and its dependencies have all been published to PuppetForge by running the install_from_core_module test suite.

    4

    18-1

    Execute check for PuppetForge publication

    Execute ‘bundle exec rake puppetfile:check’ and examine output to identify any modules that have not been published to PuppetForge

    18-2

    Publish any missing modules to PuppetForge

    18-3

    Update the install_from_core_module test with any release-specific changes

    18-4

    Execute the install_from_core_module test

    17

    Dogfood released modules and assets

    Use released modules in development environments that exercise as many of the modules as possible. Install RPMs of released assets on SIMP servers.

    5

    Y

    Y

    -

    15.2

    Review changes

    15.2

    -

    -

    -

    -

    -

    -

    16

    Finalize simp-doc

    16.1

    Remove any reference to release candidates

    16.2

    Release

    16.2

    17

    Update simp-core with released simp-doc and verify versions

    Update simp-core Puppetfile.pinned

    All components in the Puppetfile.pinned should be referencing a GitHub tag.

    simp-core

    1

    3

    -

    -

    -

    -

    -

    -

    17-1

    Deploy modules to development environments

    .1

    Update Puppetfiles for development environments and deploy the modules.files and build ISOs

    -

    2

    -

    -

    -

    -

    -

    -

    17-.2

    Install asset RPMs on SIMP server

    Install RPMs and watch for any RPM installation error messages.

    -

    -

    -

    -

    -

    -

    17-3

    Examine logs for issuesVerify versions

    Make sure there are no version discrepancies in the Puppetfile.pinned, metadata.json and src/assets/simp/build/simp.spec files.

    17.1

    1

    -

    -

    -

    -

    -

    -

    -

    5TODO: Automate this task

    18

    Create final ISO, verify with simp-packer, and publish the ISOs and their tar files

    This is the final build and spot check via simp-packer.

    simp-core

    417

    Y

    Y

    -

    -

    -

    -

    5-18.1

    Build ISO

    Use official RPM signing keys when the artifacts are to be published anywhere at simp-project.com.

    -

    1

    -

    -

    -

    -

    -

    -

    5-18.2

    Build BIOS boot box with FIPS enabled and encrypted disk

    518.1

    -

    -

    -

    -

    -

    -

    5-18.3

    Build BIOS boot box with FIPS enabled and unencrypted disk

    518.1

    -

    -

    -

    -

    -

    -

    5-18.4

    Build BIOS boot box with FIPS disabled and encrypted disk

    518.1

    -

    -

    -

    -

    -

    -

    18.5-5

    Build BIOS boot box with FIPS disabled and unencrypted disk

    518.1

    -

    -

    -

    -

    -

    -

    5-18.6

    Build UEFI boot box with FIPS enabled and encrypted disk

    518.1

    -

    -

    -

    -

    -

    -

    5-18.7

    Build UEFI boot box with FIPS enabled and unencrypted disk

    518.1

    -

    -

    -

    -

    -

    -

    5-18.8

    Build UEFI boot box with FIPS disabled and encrypted disk

    518.1

    -

    -

    -

    -

    -

    -

    5-18.9

    Build UEFI boot box with FIPS disabled and unencrypted disk

    518.1

    -

    -

    -

    -

    -

    -

    5-18.10

    Publish artifacts

    Final artifacts that have passed simp-packer validation are published to official release folders at simp-project.com.

    518.2, 518.3, 518.4, 518.5, 518.6, 518.7, 518.8, 518.9

    1

    -

    -

    -

    -

    -

    -

    19

    Announce release

    5

    -

    -

    -

    -

    -

    -

    19.1

    Announce on mailing lists

    -

    -

    -

    -

    -

    -

    20

    Post-release: Verify RPM publication

    Verify RPMs have been uploaded to simp-project.com. This includes Puppet module RPMs, SIMP application RPMs, and any other auxiliary, application RPMs.

    -

    -

    20
    -

    -

    -

    -

    -

    20.1

    Verify Puppet module RPMs have been published

    Execute ‘bundle exec rake puppetfile:check’ and examine output to identify any modules that have not been published to simp-project.com.

    20-

    -

    -

    -

    -

    -

    -

    20.2

    Verify other RPMs have been published

    Run the install_from_rpm test. See https://github.com/simp/simp-core/blob/master/spec/acceptance/suites/README.md . If a nodeset for the OS under test does not exist, create it.


    Y

    Y

    -

    -

    -

    -

    20-.3

    Publish any missing RPMs

    -

    -

    -

    -

    -

    -