[openstack-dev] [ironic] [infra] RFC: consolidating and extending Ironic CI jobs

Dmitry Tantsur dtantsur at redhat.com
Wed Oct 12 13:10:58 UTC 2016


On 10/12/2016 03:01 PM, Vasyl Saienko wrote:
> Hello Dmitry,
>
> Thanks for raising this question. I think the problem is deeper. There are a lot
> of use-cases that are not covered by our CI like cleaning, adoption etc...

This is nice, but here I'm trying to solve a pretty specific problem: we can't 
reasonably add more jobs to even cover all supported partitioning scenarios.

>
> The main problem is that we need to change ironic configuration to apply
> specific use-case. Unfortunately tempest doesn't allow to change cloud
> configuration during tests run.
>
>
> Recently I've started working on PoC that should solve this problem [0]. The
> main idea is to have ability to change ironic configuration during single gate
> job run, and launch the same tempest tests after each configuration change.
>
> We can't change other components configuration as it will require reinstalling
> whole devstack, so launching flat network and multitenant network scenarios is
> not possible in single job.
>
>
> For example:
>
> 1. Setup devstack with agent_ssh wholedisk ipxe configuration
>
> 2. Run tempest tests
>
> 3. Update localrc to use agent_ssh localboot image

For this particular example, my approach will be much, much faster, as all 
instances will be built in parallel.

>
> 4. Unstack ironic component only. Not whole devstack.
>
> 5. Install/configure ironic component only
>
> 6. Run tempest tests
>
> 7. Repeat steps 3-6 with other Ironic-only configuration change.
>
>
> Running step 4,5 takes near 2-3 minutes.
>
>
> Below is an non-exhaustive list of configuration choices we could try to
> mix-and-match in single tempest run to have a maximal overall code coverage in a
> sibl:
>
>   *
>
>     cleaning enabled / disabled

This is the only valid example, for other cases you don't need a devstack update.

>
>   *
>
>     using pxe_* drivers / agent_* drivers
>
>   *
>
>     using netboot / localboot
>
>   * using partitioned / wholedisk images
>
>
>
> [0] https://review.openstack.org/#/c/369021/
>
>
>
>
> On Wed, Oct 12, 2016 at 3:01 PM, Dmitry Tantsur <dtantsur at redhat.com
> <mailto:dtantsur at redhat.com>> wrote:
>
>     Hi folks!
>
>     I'd like to propose a plan on how to simultaneously extend the coverage of
>     our jobs and reduce their number.
>
>     Currently, we're running one instance per job. This was reasonable when the
>     coreos-based IPA image was the default, but now with tinyipa we can run up
>     to 7 instances (and actually do it in the grenade job). I suggest we use 6
>     fake bm nodes to make a single CI job cover many scenarios.
>
>     The jobs will be grouped based on driver (pxe_ipmitool and agent_ipmitool)
>     to be more in sync with how 3rd party CI does it. A special configuration
>     option will be used to enable multi-instance testing to avoid breaking 3rd
>     party CI systems that are not ready for it.
>
>     To ensure coverage, we'll only leave a required number of nodes "available",
>     and deploy all instances in parallel.
>
>     In the end, we'll have these jobs on ironic:
>     gate-tempest-ironic-pxe_ipmitool-tinyipa
>     gate-tempest-ironic-agent_ipmitool-tinyipa
>
>     Each job will cover the following scenarious:
>     * partition images:
>     ** with local boot:
>     ** 1. msdos partition table and BIOS boot
>     ** 2. GPT partition table and BIOS boot
>     ** 3. GPT partition table and UEFI boot  <*>
>     ** with netboot:
>     ** 4. msdos partition table and BIOS boot <**>
>     * whole disk images:
>     * 5. with msdos partition table embedded and BIOS boot
>     * 6. with GPT partition table embedded and UEFI boot  <*>
>
>      <*> - in the future, when we figure our UEFI testing
>      <**> - we're moving away from defaulting to netboot, hence only one scenario
>
>     I suggest creating the jobs for Newton and Ocata, and starting with Xenial
>     right away.
>
>     Any comments, ideas and suggestions are welcome.
>
>     __________________________________________________________________________
>     OpenStack Development Mailing List (not for usage questions)
>     Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>     <http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe>
>     http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>     <http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev>
>
>
>
>
> __________________________________________________________________________
> 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
>




More information about the OpenStack-dev mailing list