Core Commiter Weekly Interlock - January 16th,2017
Agenda:
- 1.0.0 Release
- Process - how are the builds labeled?
- A re-build is really just a rebuild of the OVA with the new version inside of it. (bits for RackHD are still the same). In the past OnRack would rebuild the OVA and then verify that the OVA would load and have the correct version number.
- We need a process that does the above in an automated fashion. At a minimum verify version number is correct and we can do a simple OS Install.
- Release candidate on a daily basis that will go through continuous integration testing with OS Install, also have a nightly regression test on those bits.
- Build will happen at 6:00 PM EST on the Friday of sprint end. We will have a final release candidate.
- What is the post OVA and post docker test that happens after build? AI Former user (Deleted) (need to understand this process)
- If RackHD loads and runs we will post the release, with test results. At some point later (TBD) QRB will go through the test failures and attempt to create bugs with release notes.
- Currently no OS Install on the release candidate (manually ran by Erika over the weekend - some issues with ESXI 5.5 ) .
- Need to add OS Install on the release candidate (Assuming the Quality Review board has not indicated a P1 issue). QRB needs to notify CC group on major issues that could stop the release.
- P1 - RackHD fails to load
- P2 - Feature failure - document what failure is and will be fixed in future release. AI QRB to create.
- Consensus is 1.0.0 has been approved for release AI Former user (Deleted) to kick of the re-build with version and verify that RackHD loads with correct version. Can a tool be written to automate deployment, and verification the release number is correct AI Former user (Deleted)
- Who makes the call on the bumping of version? When?
- Pending PR Reviews
- AI Paul Scharlach to talk to Roland about on-taskgraph container build failures in dockerhub
- Roundtable