...
- New rules enforced: you need a "+2" in a review for merging, but it cannot be your own
- If you are a committer, you can give a "+2" to your own patch
- One "+2" from someone else than submitter is needed
- After this, anyone can merge the patch
- Sonobuoy doesn’t work for arm, so we have 2 options options→ postponed to next meeting
- call the tests directly without sonobuoy on arm hr
- adapt sonobuoy to work on arm (I incline more to this option but seems difficult to do it upstream so we’ll have to figure out a clever solution)
- Documentation strategy
- We have projects lined up to test the Blueprint validation project
- Cristina has promised to document the steps for running the k8s tests
- We need to separate user documentation and developer documentation
- Follow Documentation Sub-Committee requirements (Architecture, User Guide and Release Notes)A user guide as an rst document?
- Proposal to TSC about mandatory tests: https://docs.google.com/presentation/d/1ONU7jmeGVrhbJe2gKRtode1aHKH8teRgfN91LYAPBmo/edit?usp=sharing
- We had a discussion about when a blueprint project can be "mature": is the maturation review before Release 2 or after it? Do we want to have "Mature" projects in Release 2? Assumption is yes
- We need to define what a Blueprint Validation release is, since the different blueprints need to be able to test against a stable set of tests. It would make sense to call the first release "2", so that BluVal Rel.2 would be used to test blueprints for Release 2. Most likely will also need a BlueVal Rel. 2.1 to fix bugs, and then the blueprints could choose any version 2.x (the latest is probably the best choice but there is no pressure to upgrade if an earlier release works)
June 5, 2019
- etcd ha test cases
- Issue is that there are two implementations, depending on how the k8s cluster has been deployed
- It would be better to have a single implementation that would work with both
- Juha and Cristina do not have access to an Airship deployment
- Docker makefile bug
- Fixed now
- UI implementation
- Discussion was about how to push jobs to validate different blueprints in different labs, since there are three kinds:
- The public community lab that runs in UNH-IOL
- 'Private' company labs which can operate in a 'master/agent' Jenkins model
- Company labs that run in a peer model whereby the Edge lab jenkins only pulls and pushes but is not a slave to the LF jenkins.
- All of these will push the results in the LF Nexus, but only the two first ones can take jobs from LF Jenkins (and hence the UI)
- The UI will soon run in a VM with a public IP
- Discussion was about how to push jobs to validate different blueprints in different labs, since there are three kinds:
...