On 10/14/16, 12:33 PM, "Sean Dague" <s...@dague.net> wrote:

> I kind of wonder if that hints to a better model here instead of the
> deployments running services from master. Instead running periodics and
> moving forward reference hashes every day if tests pass, and not if they
> fail. That would let deployment tools automatically move forward, quite
> close to master, but not get tightly coupled into every change.

FWIW That’s pretty much what OpenStack-Ansible does for our ‘integrated build’.

We have the ‘production style’ deployment pinned to upstream SHA’s which Are 
updated once every two weeks. This allows us to get on with our own development 
instead of being disrupted every time something causes a break upstream. We 
then only have to deal with upstream-related issues when we update SHA pins.

However we do also do more focused, slightly less complex builds on a per role 
(per upstream service) basis which build directly from the upstream branch. 
These have a broader testing spectrum (more platforms, more backends) and due 
to the lower level of complexity in the number of components used in the builds 
they are generally successful unless our own patch is bad.

From my own standpoint I think that if production-type build tests (with 
functional testing) are executed using deployment projects there would need to 

1. A good track record of the builds succeeding without failures due to 
circumstances that are specific to the deployment tool project. Ie The builds 
must be at least as successful as DevStack in its results with as few false 
negatives as possible.
2. Each project using these tests would need a designated liaison to the 
deployment project in order to expedite the triage of issues that arise from 
the tests. The service project person understands the service and the 
deployment project liaison understands the deployment project. Effectively they 
should pair up to quickly triage and resolve any check failures that arise.
3. The tests should not just be a deployment test – they should have some level 
of functional testing too. If this is not the case then all that’s happening is 
that the deployment tooling is being tested – not the effect of the patch to 
the service project.


Rackspace Limited is a company registered in England & Wales (company 
registered number 03897010) whose registered office is at 5 Millington Road, 
Hyde Park Hayes, Middlesex UB3 4AZ. Rackspace Limited privacy policy can be 
viewed at www.rackspace.co.uk/legal/privacy-policy - This e-mail message may 
contain confidential or privileged information intended for the recipient. Any 
dissemination, distribution or copying of the enclosed material is prohibited. 
If you receive this transmission in error, please notify us immediately by 
e-mail at ab...@rackspace.com and delete the original message. Your cooperation 
is appreciated.
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe

Reply via email to