I'm happy to announce a new experimental CI job in Nova's gate. https://review.openstack.org/#/c/381322
== What is this new CI job? The job is called: gate-tripleo-ci-centos-7-nonha-multinode It's non-voting, and only run at demand, using "check experimental". It's deploying 2 nodes: - undercloud [1]: OpenStack cloud used to deploy overcloud(s) - overcloud: OpenStack cloud used to create resources consumed by end-users. If you want to know more about TripleO architecture: http://docs.openstack.org/developer/tripleo-docs/introduction/architecture.html#tripleo The job aims to be stable, but we often have downtimes when something breaks in packaging or infrastructure. It's very possible that you'll see the job red but has nothing to do with your patch. == When to run the CI job? As a Nova developer, when deprecating a feature or some options, or even removing it, I want to test if it breaks systems outside devstack. We are documenting it in Nova developer doc: https://review.openstack.org/#/c/381838/ - Feel free to comment and review! == What to do if TripleO CI job is red? It would not be fair to ask Nova team to debug TripleO jobs, their time is precious and that's not the goal here. Though if something is red, please let us know! Jump on #tripleo channel or ping me on #openstack-nova (or any TripleO folks connected on this channel) and we'll have a look as soon as we can to figure what happens. == CI job is red, but a valid reason. Are we going to block my patch in Nova? The goal here is to report short feedback from deployment tools used in production to projects like Nova. If TripleO job is red because backward compatibility is broken and was not intended to be broken, I think it's fair to block the Nova patch as we might break other users. If TripleO CI job is red because we didn't update our configuration and still use deprecated parameters, it's our responsibility to update TripleO and the patch should not be blocked in Nova. I hope this proposal is fair for everyone, any feedback is welcome here. Thanks for your openness, very appreciated here. -- Emilien Macchi __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev