On 13 April 2016 at 09:58, Steven Hardy <sha...@redhat.com> wrote: > On Tue, Apr 12, 2016 at 11:08:28PM +0200, Gabriele Cerami wrote: >> On Fri, 2016-04-08 at 16:18 +0100, Steven Hardy wrote: >> >> > Note we're not using devtest at all anymore, the developer script >> > many >> > folks use is tripleo.sh: >> >> So, I followed the flow of the gate jobs starting from jenkins builder >> script, and it seems like it's using devtest (or maybe something I >> consider to be devtest but it's not, is devtest the part that creates >> some environments, wait for them to be locked by gearman, and so on ?) > > So I think the confusion may step from the fact ./docs/TripleO-ci.rst is > out of date. Derek can confirm, but I think although there may be a few > residual devtest pieces associated with managing the testenv VMs, there's > nothing related to devtest used in the actual CI run itself anymore. > > See this commit: > > https://github.com/openstack-infra/tripleo-ci/commit/a85deb848007f0860ac32ac0096c5e45fe899cc5 > > Since then we've moved to using tripleo.sh to drive most steps of the CI > run, and many developers are using it also. Previously the same was true > of the devtest.sh script in tripleo-incubator, but now that is totally > deprecated and unused (that it still exists in the repo is an oversight). Devtest was used to generate the images that host the testenvs and we should be soon getting rid of this. So I wouldn't spend a lot of time looking at devtest it isn't used during the actual CI runs'
> >> What I meant with "the script I'm using (created by Sagi) is not >> creating the same enviroment" is that is not using the same test env >> (with gearman and such) that the ci scripts are currently using. > > Sure, I guess my point is that for 99% of issues, the method used to create > the VM is not important. We use a slightly different method in CI to > manage the VMs than in most developer environments, but if the requirement > is to reproduce CI failures, you mostly care about deploying the exact same > software, not so much how virsh was driven to create the VMs. Yes, most of our errors can be reproduced outside of the CI environment, but there are cases where we need an identical setup (specifically for some transient errors), what we should do I think is set aside a single test env host for these errors for anybody debugging transient errors. I'll can get something together for this. It wont be for general purpose developing but instead should be limited for use only when debugging transient errors that don't reproduce elsewhere. > > Thanks for digging into this, it's great to have some fresh eyes > highlighting these sorts of issues! :) Yes, its been a while since we had a updodate description of how everything ties together so thanks for this. I've read through it and added a few comments but in general what you have documented is on the right track. > > Steve > > __________________________________________________________________________ > 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 __________________________________________________________________________ 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
