Open Stack

On Mon, Jan 30, 2017 at 01:37:56PM +0100, Attila Darazs wrote:
> In the spirit of "better late than never", here's a summary of our CI Squad
> meeting.
> 
> Time: Thursdays, 15:30-16:30 UTC
> Place: https://bluejeans.com/4113567798/
> 
> 
> Configuration management in TripleO CI
> ======================================
> 
> There was a design meeting organized by Gabrielle (thanks!) to discuss how
> to solve the problem of configuring the new Quickstart jobs.
> 
> There are multiple approaches for this problem, and it's difficult to find a
> balance from having a single definite config file per job (too much
> duplication) to parsing the job name and handling every option with coding
> logic in the testing system (hard to reproduce/know what's happening).
> 
Before you go out an implement some sort of in-repo configuration for testing, I
strongly encourage you to read up on our Zuulv3 spec[3], as we are providing
this functionality.  What is comes down to, you'll be able to focus on writing
tests, where zuul does all the test configuration and provisioning.

[3] https://specs.openstack.org/openstack-infra/infra-specs/specs/zuulv3.html

> What emerged from the still ongoing discussion is identifying three config
> sections:
> 
> * provisioner: e.g. libvirt, OVB or nodepool based jobs and the related
> configution to allow quickstart to work on these systems
>
I would suggest not spending too much time on your provisioner, once zuulv3
lands, it will potentially no longer be needed.  Additionally, if you want to do
provisioning, take a look at the linch-pin project, Clint Savage @ Red Hat has a
ansible provisioner too. Or, leverage the new nodepool APIs to get testing
resources.

> * release: one config file for release, config/release (we already have
> these)
> * config: one config file for general config, config/general_config
> 
> It seems useful to give a neutral name for a certain set of functionalities
> tested in certain CI jobs instead of the misleading names of "ha/nonha"
> (when in fact they test a lot more). "featureset01", "featureset02", etc.
> looks like a good candidate for naming them.
> 
> So we could end up with jobs like "tripleo-ovb-featureset01-newton", with
> the featureset matrix documented somewhere like tripleo-ci.
> 
Again, please look into the zuulv3 spec, I think you'll find some of this is
overlap.
> 
> Smaller topics
> ==============
> 
> * Both the OVB and nodepool jobs are working apart from generic setbacks
> like the python-pandas issue breaking our jobs.
> 
> * Our blocker/bottleneck for transition is now the above discussed
> configuration management.
> 
> * The "Quickstart transition checklist" is now hosted on google docs
> here[1].
> 
> * We are having trouble keeping track of the issues in upstream CI. Using an
> invidual trello board instead of the current etherpad was suggested. We're
> going to try this solution out this week and post updates.
> 
> * Emilien mentioned the new additonal composable upgrades testing in TripelO
> CI[2].
> 
> * We had a bug triage/squashing event last Friday. Started moving bugs from
> the "tripleo-quickstart" project to "tripleo" and tag them as ci/quickstart,
> to ease the scheduling of bugs.
> 
> * Also managed to make a big improvment on the tripleo-quickstart bug count,
> going from 65 open bugs to 42, and from 37 new bugs to 21.
> 
> Full meeting minutes can be found here:
> 
> https://etherpad.openstack.org/p/tripleo-ci-squad-meeting
> 
> Best regards,
> Attila
> 
> [1] https://docs.google.com/document/d/1Mb_t5Qe-Lnh0uaXy0ubX9y4k65Q4D_aw-49eZOqoviQ/edit?pli=1
> [2] https://review.openstack.org/425727
> 
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev