SUSEDellInterlock
This document describes and captured te effort between SUSE and Dell to collaborate on Crowbar 2 development. It outlines the details around a "Ship Ready", as well as the infrastructure needed to enable effective collaboration going forward. Unless these details are of interest to you this document most likely won't be of value to you.
Both Dell and SUSE continue to release product based on the Crowbar 1.x tree. This is problematic for a series of reasons. Meanwhile the Crowbar 2.0 source tree isn't completely functional and ready to replace Crowbar 1.x in the field. A "Ship Ready" product would be in a position to replace Crowbar 1.x in terms of functionality.
Hereby it is important to note that while a "Ship Ready" of Crowbar 2.0 is a milestone, it is NOT the complete and final product. This explains why the "Ship Ready" of Crowbar 2.0 lacks features which will be part of the final Crowbar 2.0 product. Below you will find the "Ship Ready" feature set of Crowbar 2.0, along with the priorities of each team:
| Dell | SUSE | Item | Description / Notes |
|---|---|---|---|
| H | H | Forward-port SUSE fixes | Any fixes made by SUSE to the current 1.x branch should be ported forward to the 2.x branch. |
| H | H | Database Model | The newly implemented CMDB model is complete and working (Chef has been removed as DB dependency). Note: For initial deployment SQLite may be used until SQL Barclamp is available. |
| H | H | Updated Networking | We want to include the newly created network subsystem. The final control mechanism of this system isn't part of a "Ship Ready" product and will continue to be the traditional network.json file until a later milestone. |
| H | H | Enable at least one CMDB | In order to prove/confirm the new abstracted CMDB pattern, Crowbar has to be enabled to use at least one CMDB. For the "Ship Ready" product this should be Chef. Note: We're fine not completely removing all Crowbarisms from the Cookbooks. |
| H | H | Tempest Barclamp | The Tempest Barclamp which currently is part of the Betty branch should be ported and enabled on the Crowbar branch. |
| H | H | Model Tests | All models should have automated tests. Metrics should be generated to show 100% coverage. |
| H | H | Shared "Smoke Tests" | An effort needs to be made to consolidate SUSE's mkcloud and Dell's Smoke Tests. |
| H | H | UI/Integration Tests | We need to make sure to have integration test coverage (BDD). |
| H | H | Use SUSE "SQL Barclamp" | SUSE has enabled Postgresql as part of their SQL Barclamp. This should be consolidated and brought into CB20 common. |
| L | H | FHS compliancy | We should clean up all the FHS violations (https://github.com/crowbar/crowbar/issues/833) in order to be more compliant with generally accepted standards. This will be critical for repo inclusion across the board. |
| L | H | API Tests | Automated tests of all exposed APIs should be done. Metrics should be generated to show 100% coverage. |
| DC | H | Packages / Repositories | Packages in openSUSE as well as SLES are important to the SUSE team. This enables repo installs & appliances via SUSE Studio |
| L | H | Developer Documentation | Critical developer documentation should be updated. TODO: Define what this means exactly. |
| H | L | Minimal changes to CLI & UI | Changing the UI and CLI only minimally will help QA to test. |
| H | L | UEFI Boot | The capability to boot hardware using UEFI is required to support critical hardware platforms. |
| H | L | User Doc Updates | Existing user docs should be brought over and updated minimally to reflect the new functionality/changes. |
| H | DC | Deploy OpenStack using Pull from Source | It should be possible to deploy OpenStack from the source repo of Folsom (Github) using Crowbar |
| H | DC | Dell generated ISO | Dell wants to continue to offer the appliance-style ISO as currently offered on crowbar.zehicle.com |
Once the above "Ship Ready" state has been completed the next milestone will be defined by the features documented below. This list is currently incomplete:
| Dell | SUSE | Item | Description / Notes |
|---|---|---|---|
| L | L | Eliminate Chef as install requirement | Chef should be removed as an installation requirement. As a result this needs to be abstracted into possibly a Chef Barclamp. |
| L | L | Fixing Partioning | Crowbar currently sets up one giant partition everywhere. It is generally good practice to split up a filesystem into a set of partitions in order to isolate / (root) from /var. Hereby we should try and follow the standard. |
Process milestones address anything outside of actual Crowbar code work. These items represent a significant effort for both teams and need to be documented and tracked accordingly. Below you will find details:
For now we've decided to stick use Github Issues for this. TODO: More documentation and process definition needed here.
TODO: More details to follow once we've defined details with Victor's help.
TODO: Is the content below correct?
Code WorkFlow:
- Dev tool or github pull request made to Crowbar Account Repo
- Jenkins detects changes and builds current+pull request:
- Using Public OBS a set of packages and ISOs are generated for validation
- Jenkins kicks new validation of new builds - this can be done concurrently:
- For Public, this will be done in VMs
- For Dell and SUSE, these are on virtual or real hardware.
- Results of the test are updated into the pull request.
- Human reviewer reviews code and once all the tests pass, the request is committed.
- Otherwise from 4, pull request is cancelled and re-submut after fixes.
These can flow into Dell's and SUSE's internal code systems and repeat as needed.