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 > <bdobre...@mirantis.com <mailto:bdobre...@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 > <bpiotrow...@mirantis.com <mailto:bpiotrow...@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 > <adide...@mirantis.com <mailto:adide...@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 > <sgolovat...@mirantis.com <mailto:sgolovat...@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 > <aschu...@mirantis.com <mailto:aschu...@mirantis.com>> > wrote: > > On Wed, Jan 20, 2016 at 9:02 AM, Matthew Mosesohn > <mmoses...@mirantis.com > <mailto:mmoses...@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-requ...@lists.openstack.org?subject:unsubscribe > > <http://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://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://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://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://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://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 > -- Best regards, Bogdan Dobrelya, Irc #bogdando __________________________________________________________________________ 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
