[openstack-dev] [Fuel] Relieving CI/gate jenkins bottleneck
Bogdan Dobrelya
bdobrelia at mirantis.com
Fri Jan 22 13:47:17 UTC 2016
And one more thing [0]. We should fix the Rakefile to call unit tests
only for modules being changed by a patch under test. This makes even
more sense bearing in mind the patch [1] which as well disables unit
tests and syntax checks for upstream modules we clone by librarian.
[0] https://bugs.launchpad.net/fuel/+bug/1537063
[1] https://review.openstack.org/#/c/270313
On 22.01.2016 13:56, Bogdan Dobrelya wrote:
> On 22.01.2016 12:19, Matthew Mosesohn wrote:
>> +1 for defaulting to upstream for CI. If we have a strong case where we
>> need to make a patch in order to make unit tests pass, we could switch a
>> module back to review.fuel-infra.org/puppet-modules/..
>> <http://review.fuel-infra.org/puppet-modules/..>.. with a FIXME and a LP
>> bug ID so we can switch it back quickly once the upstream issue is
>> resolved. As far as I know, we don't have to worry about that scenario.
>
> Yes, exactly so. Switching upstream/downstream links of modules in the
> Puppetfile back and forth can be done as often as we need it, with no
> issues at all. With "free bonuses" though! Which is, firstly, it would
> be easier to estimate upstream-to-downstream sync status by just looking
> at the Puppetfile. Secondly, each time one's switching an upstream link
> to a downstream, reviewers may treat this as a "tech dept growing
> alarm!" and perhaps motivate patch authors to contribute changes
> upstream instead (or *faster*) rather than just stashing them
> accumulated downstream.
>
>>
>> -Matthew
>>
>> On Fri, Jan 22, 2016 at 12:51 PM, Bogdan Dobrelya
>> <bdobrelia at mirantis.com <mailto:bdobrelia at mirantis.com>> wrote:
>>
>> Another point is to use upstream links for modules w/o downstream
>> patches.
>> I noticed we *always* put it to the deployment/Puppetfile [0] as
>> "https://review.fuel-infra.org/puppet-modules/...". Why should we?
>> Let's just do the best to reuse upstream modules as is, eventually.
>>
>> [0] https://github.com/openstack/fuel-library/blob/master/deployment/Puppetfile
>>
>> Regards,
>> Bogdan Dobrelya.
>> Irc #bogdando
>>
>> 2016-01-21 11:09 GMT+01:00 Bartlomiej Piotrowski
>> <bpiotrowski at mirantis.com <mailto:bpiotrowski at mirantis.com>>:
>>
>> Let's drop 3.3 as well. 3.4 is oldschool enough for vintage lovers.
>>
>> BP
>>
>> On Thu, Jan 21, 2016 at 11:03 AM, Aleksandr Didenko
>> <adidenko at mirantis.com <mailto:adidenko at mirantis.com>> wrote:
>>
>> Hi,
>>
>> > I also think 3.3 is the version that ships with 14.04.
>>
>> 3.4.3 is shipped with Ubuntu-14.04. I think 3.4, 3.8 and 4
>> should be enough.
>>
>> Regards,
>> Alex
>>
>> On Wed, Jan 20, 2016 at 6:38 PM, Sergii Golovatiuk
>> <sgolovatiuk at mirantis.com <mailto:sgolovatiuk at mirantis.com>>
>> wrote:
>>
>> +1 for 3.3, 3.4, 3.8 and 4
>>
>>
>> --
>> Best regards,
>> Sergii Golovatiuk,
>> Skype #golserge
>> IRC #holser
>>
>> On Wed, Jan 20, 2016 at 6:12 PM, Alex Schultz
>> <aschultz at mirantis.com <mailto:aschultz at mirantis.com>>
>> wrote:
>>
>> On Wed, Jan 20, 2016 at 9:02 AM, Matthew Mosesohn
>> <mmosesohn at mirantis.com
>> <mailto:mmosesohn at mirantis.com>> wrote:
>> > Hi all,
>> >
>> > Unit tests on CI and gate bottleneck are really slowing down commit
>> > progress. We recently had a meeting to discuss possible ways to improve
>> > this, including symlinks, caching git repositories, etc, but one thing we
>> > can do much faster is to simply disable 3.3-3.7 puppet jobs. We don't deploy
>> > Fuel 9.0 (or 8.0) on earlier Puppet versions, so what value is there to the
>> > checks? I propose we remove these tests, and hopefully we will see some
>> > immediate relief.
>> >
>>
>> How about we reduce to 3.3, 3.4, 3.8 and 4? We
>> would remove 3.6 and
>> 3.7 which would reduce the number of jobs by a
>> third The goal of
>> keeping the others was to ensure that if/when we are
>> able to install
>> fuel-library without our version of puppet that a
>> user could use
>> whatever version their environment has. There were
>> some changes
>> between 3.3 and 3.4 (if I remember correctly) so we
>> should keep
>> checking that as it's also the oldest version
>> supported by the
>> upstream puppet openstack modules. I also think 3.3
>> is the version
>> that ships with 14.04. Additionally we used 3.4 in
>> fuel 7 and below
>> so we should keep those around.
>>
>> -Alex
>>
>> > Best Regards,
>> > Matthew Mosesohn
>> >
>> >
>> __________________________________________________________________________
>> > 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
>> >
>>
>> __________________________________________________________________________
>> 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
>>
>>
>>
>> __________________________________________________________________________
>> 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
>>
>>
>>
>> __________________________________________________________________________
>> 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
>>
>>
>>
>> __________________________________________________________________________
>> 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
>>
>>
>>
>> __________________________________________________________________________
>> 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
>>
>>
>>
>>
>> __________________________________________________________________________
>> 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
>>
>
>
--
Best regards,
Bogdan Dobrelya,
Irc #bogdando
More information about the OpenStack-dev
mailing list