[openstack-dev] [Fuel][CI] recheck/reverify support for Fuel CI jobs
Hi, I’d like to inform you that all jobs running on Fuel CI (with the exception of fuel-library deployment tests) now support retriggering via “recheck” or “reverify” comments in Gerrit. Exact regex is the same one used in Openstack-Infra’s zuul and can be found here https://github.com/fuel-infra/jenkins-jobs/blob/master/servers/fuel-ci/global.yaml#L3 CI-Team kindly asks you to not abuse this option, unfortunately not every failure could be solved by retriggering. And, to stress this out once again: fuel-library deployment tests don’t support this, so you still have to ask for a retrigger in #fuel-infra irc channel. Thanks for attention. -- Igor Belikov Fuel CI Engineer ibeli...@mirantis.com __ 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
Re: [openstack-dev] [Fuel][CI] recheck/reverify support for Fuel CI jobs
Hi Stanislaw, The reason behind this is simple - deployment tests are heavy. Each deployment test occupies whole server for ~2 hours, for each commit we have 2 deployment tests (for current fuel-library master) and that’s just because we don’t test CentOS deployment for now. If we assume that developers will rertrigger deployment tests only when retrigger would actually solve the failure - it’s still not smart in terms of HW usage to retrigger both tests when only one has failed, for example. And there are cases when retrigger just won’t do it and CI Engineer must manually erase the existing environment on slave or fix it by other means, so it’s better when CI Engineer looks through logs before each retrigger of deployment test. Hope this answers your question. -- Igor Belikov Fuel CI Engineer ibeli...@mirantis.com > On 20 Nov 2015, at 13:57, Stanislaw Bogatkin wrote: > > Hi Igor, > > would you be so kind tell, why fuel-library deployment tests doesn't support > this? Maybe there is a link with previous talks about it? > > On Fri, Nov 20, 2015 at 1:34 PM, Igor Belikov <mailto:ibeli...@mirantis.com>> wrote: > Hi, > > I’d like to inform you that all jobs running on Fuel CI (with the exception > of fuel-library deployment tests) now support retriggering via “recheck” or > “reverify” comments in Gerrit. > Exact regex is the same one used in Openstack-Infra’s zuul and can be found > here > https://github.com/fuel-infra/jenkins-jobs/blob/master/servers/fuel-ci/global.yaml#L3 > > <https://github.com/fuel-infra/jenkins-jobs/blob/master/servers/fuel-ci/global.yaml#L3> > > CI-Team kindly asks you to not abuse this option, unfortunately not every > failure could be solved by retriggering. > And, to stress this out once again: fuel-library deployment tests don’t > support this, so you still have to ask for a retrigger in #fuel-infra irc > channel. > > Thanks for attention. > -- > Igor Belikov > Fuel CI Engineer > ibeli...@mirantis.com <mailto:ibeli...@mirantis.com> > > > > > > > > __ > 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 > <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 __ 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
Re: [openstack-dev] [Fuel][CI] recheck/reverify support for Fuel CI jobs
Alexey, First of all, “refuel” sounds very cool. Thanks for raising this topic, I would like to hear more opinions here. On one hand, different keyword would help to prevent unnecessary infrastructure load, I agree with you on that. And on another hand, using existing keywords helps to avoid confusion and provides expected behaviour for our CI jobs. Far too many times I’ve heard questions like “Why ‘recheck’ doesn’t retrigger Fuel CI jobs?”. So I would like to hear more thoughts here from our developers. And I will investigate how another third party CI systems handle this questions. -- Igor Belikov Fuel CI Engineer ibeli...@mirantis.com > On 20 Nov 2015, at 16:00, Alexey Shtokolov wrote: > > Igor, > > Thank you for this feature. > Afaiu recheck/reverify is mostly useful for internal CI-related fails. And > Fuel CI and Openstack CI are two different infrastructures. > So if smth is broken on Fuel CI, "recheck" will restart all jobs on Openstack > CI too. And opposite case works the same way. > > Probably we should use another keyword for Fuel CI to prevent an extra load > on the infrastructure? For example "refuel" or smth like this? > > Best regards, > Alexey Shtokolov > > 2015-11-20 14:24 GMT+03:00 Stanislaw Bogatkin <mailto:sbogat...@mirantis.com>>: > Igor, > > it is much more clear for me now. Thank you :) > > On Fri, Nov 20, 2015 at 2:09 PM, Igor Belikov <mailto:ibeli...@mirantis.com>> wrote: > Hi Stanislaw, > > The reason behind this is simple - deployment tests are heavy. Each > deployment test occupies whole server for ~2 hours, for each commit we have 2 > deployment tests (for current fuel-library master) and that’s just because we > don’t test CentOS deployment for now. > If we assume that developers will rertrigger deployment tests only when > retrigger would actually solve the failure - it’s still not smart in terms of > HW usage to retrigger both tests when only one has failed, for example. > And there are cases when retrigger just won’t do it and CI Engineer must > manually erase the existing environment on slave or fix it by other means, so > it’s better when CI Engineer looks through logs before each retrigger of > deployment test. > > Hope this answers your question. > > -- > Igor Belikov > Fuel CI Engineer > ibeli...@mirantis.com <mailto:ibeli...@mirantis.com> > >> On 20 Nov 2015, at 13:57, Stanislaw Bogatkin > <mailto:sbogat...@mirantis.com>> wrote: >> >> Hi Igor, >> >> would you be so kind tell, why fuel-library deployment tests doesn't support >> this? Maybe there is a link with previous talks about it? >> >> On Fri, Nov 20, 2015 at 1:34 PM, Igor Belikov > <mailto:ibeli...@mirantis.com>> wrote: >> Hi, >> >> I’d like to inform you that all jobs running on Fuel CI (with the exception >> of fuel-library deployment tests) now support retriggering via “recheck” or >> “reverify” comments in Gerrit. >> Exact regex is the same one used in Openstack-Infra’s zuul and can be found >> here >> https://github.com/fuel-infra/jenkins-jobs/blob/master/servers/fuel-ci/global.yaml#L3 >> >> <https://github.com/fuel-infra/jenkins-jobs/blob/master/servers/fuel-ci/global.yaml#L3> >> >> CI-Team kindly asks you to not abuse this option, unfortunately not every >> failure could be solved by retriggering. >> And, to stress this out once again: fuel-library deployment tests don’t >> support this, so you still have to ask for a retrigger in #fuel-infra irc >> channel. >> >> Thanks for attention. >> -- >> Igor Belikov >> Fuel CI Engineer >> ibeli...@mirantis.com <mailto:ibeli...@mirantis.com> >> >> >> >> >> >> >> >> __ >> 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 >> <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 >> <mailto:openstack-dev-requ...@lists.openstack.org>?subject:unsubscribe >> http://lists.openstack.org/cgi-bin/mailma
Re: [openstack-dev] [Fuel] Dropping python2.6 compatibility
Just want to make a couple of things clear:
1. Openstack-Infra is dropping py26 jobs support, as Andreas said,
so once https://review.openstack.org/#/c/252448/ is merged all openstack
projects
(including Fuel, of course) won’t have py26 gates.
2. We still run py26 tests on Fuel-CI side and don’t plan to drop them along
with
OS-Infra folks, so it’s absolutely possible to have a working py26 CI for the
duration
of Centos 7 migration (or keep it even after that).
> On 03 Dec 2015, at 13:49, Igor Kalnitsky wrote:
>
>> shouldn't we switch tests to work with python2.7 instead of python2.6?
>
> Currently we run tests using both py26 and py27, see the
>
> * gate-fuel-web-python27 (openstack infra)
> * verify-fuel-web-py27 (fuel infra)
>
> So the question is should we drop py26 jobs? I think yes, we should..
> but once CentOS 7 is merged.
>
> I want to notice that, the py26 gate has been removed from openstack
> infra in this patch [1] and due to this bug [2].
>
> Honestly, I have no idea why there were no discussions regarding this
> =/ it looks like Alex Kislitsky is issue reporter.
>
> [1] https://review.openstack.org/#/c/249242/
> [2] https://bugs.launchpad.net/fuel/+bug/1519371
>
> - I
>
> On Thu, Dec 3, 2015 at 12:35 PM, Andreas Jaeger wrote:
>> On 2015-12-03 11:21, Evgeniy L wrote:
>>>
>>> Hi,
>>>
>>> During Fuel master migration to CentOS7 there was found a problem that
>>> tests
>>> get failed [0] for python2.6
>>>
>>> As far as I can see it's a common practise to drop python2.6
>>> compatibility [1],
>>> shouldn't we switch tests to work with python2.7 instead of python2.6?
>>>
>>> It looks like fuelclient will be an exception, because clients continue
>>> supporting
>>> python2.6 [1]
>>
>>
>> Clients are not supporting python 2.6 with Juno EOL anymore. Fuelclient has
>> no 2.6 gates anymore since yesterday.
>>
>> As mentioned already, we're disabling python 2.6 everywhere.
>>
>> Patch to remove it from nearly all repos including fuel is at
>> https://review.openstack.org/#/c/252448/
>>
>> Andreas
>>
>>> Thanks,
>>>
>>> [0] https://review.openstack.org/#/c/251120/
>>> [1]
>>>
>>> https://wiki.openstack.org/wiki/Python3#Python_2:_Python_2.6_support_dropped.2C_Python_2.7_only
>>>
>>>
>>> __
>>> 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
>>>
>>
>>
>> --
>> Andreas Jaeger aj@{suse.com,opensuse.org} Twitter: jaegerandi
>> SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
>> GF: Felix Imendörffer, Jane Smithard, Graham Norton,
>> HRB 21284 (AG Nürnberg)
>>GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126
>>
>>
>> __
>> 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
__
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-dev] [Fuel] branching Mitaka April 6, 2016
Hi, Fuel SCF will be taking place on April 6th, this means that we’re going to create stable/mitaka branches for a number of Fuel repos. PLEASE, take a look at the following list and respond if you think your project should be included or excluded from the list: * fuel-agent * fuel-astute * fuel-library * fuel-main * fuel-menu * fuel-mirror * fuel-nailgun-agent * fuel-noop-fixtures * fuel-octane * fuel-ostf * fuel-plugin-murano * fuel-qa * fuel-ui * fuel-upgrade * fuel-virtualbox * fuel-web * network-checker * python-fuelclient * shotgun -- Igor Belikov Fuel CI Engineer ibeli...@mirantis.com __ 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
Re: [openstack-dev] [Fuel] branching Mitaka April 6, 2016
Hi Sergey, According to Matthew Mosesohn the plan is to delay branching of detach-* plugins. The only plugin scheduled for branching tomorrow seems to be a fuel-plugin-murano. -- Igor Belikov Fuel CI Engineer ibeli...@mirantis.com > On 04 Apr 2016, at 15:11, Sergii Golovatiuk wrote: > > What about plugins? > > For instance: fuel-plugin-detach-keystone > > -- > Best regards, > Sergii Golovatiuk, > Skype #golserge > IRC #holser > > On Mon, Apr 4, 2016 at 1:44 PM, Igor Belikov <mailto:ibeli...@mirantis.com>> wrote: > Hi, > > Fuel SCF will be taking place on April 6th, this means that we’re going to > create stable/mitaka branches for a number of Fuel repos. > > PLEASE, take a look at the following list and respond if you think your > project should be included or excluded from the list: > * fuel-agent > * fuel-astute > * fuel-library > * fuel-main > * fuel-menu > * fuel-mirror > * fuel-nailgun-agent > * fuel-noop-fixtures > * fuel-octane > * fuel-ostf > * fuel-plugin-murano > * fuel-qa > * fuel-ui > * fuel-upgrade > * fuel-virtualbox > * fuel-web > * network-checker > * python-fuelclient > * shotgun > > -- > Igor Belikov > Fuel CI Engineer > ibeli...@mirantis.com <mailto:ibeli...@mirantis.com> > > > __ > 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 > <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 __ 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-dev] [Infra] Generic solution for bare metal testing
Hey Stackers, In Fuel we use bare metal testing for deployment tests. This is essentially a core component of Fuel CI and as much as we like having it around we’d rather spend time and resources integrating with upstream instead of growing and polishing third-party testing solutions. On one of the previous Infra team meetings we discussed the possibility of bringing testing on bare metal nodes to openstack-infra[1]. This is not a new topic, similar question was brought up by Magnum some time ago[2] and there might other times this was discussed. We use bare metal testing for Fuel, I assume that Magnum still wants to use it, TripleO would probably also fit in the picture in some way (though I’m not familiar with current scheme of TripleO CI) - hope this is enough to consider implementation of generic way to use baremetal nodes in CI. The most obvious way to do this seems to be using existing OpenStack service for bare metal provisioning - Ironic. Ironic fits pretty well in existing Infra workflow, Ironic usage (in form of Rackspace's OnMetal) was previously discussed in Magnum thread[2] with the main technical issue being inability to use custom glance images to boot instances. AFAIK the situation didn't change much with OnMetal, but Ironic perfectly supports booting from glance images created by diskimage-builder - which is exactly the way Nodepool currently works for virtual machines. With the work currently going on InfraCloud there's a possibility to properly design and implement bare metal testing, Zuul v3 spec[3] also brings a number of relevant changes to Nodepool. So, summing up some points of possible implementation: * Multiple pools of bare metal nodes under Ironic management are available as a part of InfraCloud * Ironic acts as an additional hypervisor for Nova, providing the ability to use bare metal nodes by booting an instance with a specific flavor * Nodepool manages booting bare metal instances using the images generated with diskimage-builder and stored in Glance * Nodepool also manages redeployment of bare metal nodes - redeploying a glance image on a bare metal node takes only a few minutes, but time may depend on a set of cleaning steps used to redeploy a node * Bare metal instances are exposed to Jenkins (or a different worker in case of Zuul v3) by Nodepool I suppose there are security issues when we talk about running custom code on bare metal slaves, but I'm not sure I understand the difference from running custom code on a virtual machine if bare metal nodes are isolated, don't contain any sensitive data and follow a regular redeployment procedure. I'd like to add that we're ready to start donating hardware from the Fuel CI pool (2 pools in different locations, to be accurate) to see this initiative taking off. Please, share your thoughts and opinions. [1]http://eavesdrop.openstack.org/meetings/infra/2016/infra.2016-03-29-19.03.log.html [2]http://lists.openstack.org/pipermail/openstack-infra/2015-September/003138.html [3]http://specs.openstack.org/openstack-infra/infra-specs/specs/zuulv3.html -- Igor Belikov Fuel CI Engineer ibeli...@mirantis.com __ 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
Re: [openstack-dev] [fuel] Fuel Community ISO 8.0
Hi Ivan, I think this counts as a bug in our community page, thanks for noticing. You can get 8.0 Community ISO using links in status dashboard on https://ci.fuel-infra.org -- Igor Belikov Fuel CI Engineer ibeli...@mirantis.com > On 04 Feb 2016, at 13:53, Ivan Kolodyazhny wrote: > > Hi team, > > I've tried to download Fuel Community ISO 8.0 from [1] and failed. We've got > 2 options there: the latest stable (7.0) and nightly build (9.0). Where can I > download 8.0 build? > > [1] https://www.fuel-infra.org/#fuelget <https://www.fuel-infra.org/#fuelget> > > Regards, > Ivan Kolodyazhny, > http://blog.e0ne.info/ > <http://blog.e0ne.info/>__ > 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
[openstack-dev] [Fuel] Fuel CI maintenance
Hello everyone, We're starting maintenance of Fuel CI Jenkins master to update SSL certificate, Jenkins version and Jenkins plugins. Expected downtime is under 30 minutes. Services affected: - Fuel CI (https://ci.fuel-infra.org <https://ci.fuel-infra.org/> - Jenkins master will be down, Gerrit reviews submitted during the downtime will require manual CI triggering) Thanks for attention. -- Igor Belikov Fuel DevOps ibeli...@mirantis.com __ 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
Re: [openstack-dev] [Fuel] Fuel CI maintenance
Maintenance is over, everything went as planned. For retriggering builds affected by maintenance please contact #fuel-devops in irc. Thanks for attention. -- Igor Belikov Fuel DevOps ibeli...@mirantis.com > On 08 Jul 2015, at 11:03, Igor Belikov wrote: > > Hello everyone, > > We're starting maintenance of Fuel CI Jenkins master to update SSL > certificate, Jenkins version and Jenkins plugins. > Expected downtime is under 30 minutes. > > Services affected: > - Fuel CI (https://ci.fuel-infra.org <https://ci.fuel-infra.org/> - Jenkins > master will be down, Gerrit reviews submitted during the downtime will > require manual CI triggering) > > Thanks for attention. > -- > Igor Belikov > Fuel DevOps > ibeli...@mirantis.com <mailto:ibeli...@mirantis.com> > > > > > __ 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-dev] [Fuel][puppet] Fuel CI for puppet-openstack modules
Hey folks, I'm glad to announce that Fuel CI for puppet-openstack modules is live and running in it's initial stage, you can look at the builds here[0]. It's running in silent mode now to allow us to gather some results and ensure that everything is running stable, so you won't see any comments in your gerrit reviews just yet. At this moment it will be useful mostly for Fuel folks only and will help to keep fuel-library working with the changes merged to upstream modules, but I'm sure it won't be long till these jobs will be able to serve puppet-openstack community as well, providing results of deployment tests for every patchset to a number of puppet-openstack modules. We're running these tests only for the modules used in fuel-library, so the current list of puppet-openstack projects tested by Fuel CI is: * puppet-aodh * puppet-ceilometer * puppet-cinder * puppet-glance * puppet-ironic * puppet-heat * puppet-horizon * puppet-keystone * puppet-murano * puppet-neutron * puppet-nova * puppet-openstacklib * puppet-sahara * puppet-swift At this initial stage we're running fuel-library noop tests and same deployment scenarios that are used for fuel-library tests on Fuel CI, but I suppose we'll move to more specific deployment test cases for each module eventually. [0]https://ci.fuel-infra.org/view/puppet-openstack/ -- Igor Belikov Fuel CI Engineer ibeli...@mirantis.com __ 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-dev] [Fuel][plugins] stable/mitaka branches for plugins
Hey fuelers, We’re getting ready for Mitaka SCF in all things Fuel and plugins are currently a somewhat grey area. So I’d like to discuss which plugins should have stable/mitaka branches. We’re currently testing 3 plugins as a part of Swarm testing suite, so at least these 3 look like hard candidates for branching: - fuel-plugin-detach-database - fuel-plugin-detach-keystone - fuel-plugin-detach-rabbitmq But the list of fuel plugins is huge and many of those plugins were developed by core fuel developers, so I’d like to gather more opinions from plugin developers, fuel developers and fuel QA folks. -- Igor Belikov Fuel CI Engineer ibeli...@mirantis.com __ 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
Re: [openstack-dev] [fuel][puppet] Switching fuel-library to consume stable/mitaka
Hi, > Additionally we will want to ensure that the fuel-ci will work for the > upstream stable/mitaka branches as it currently[0] isn't working since we > haven't cut a stable/mitaka branch for Fuel yet. Igor Belikov has been > notified of the current issues and is looking into a fix. I rolled out the fix to Fuel CI and retriggered tests for the change, thanks for catching this quickly. We don’t plan to tie Fuel CI for puppet-openstack to Fuel branching dates, so Fuel CI will test changes to both master and stable/mitaka branches of puppet-openstack modules using master of fuel-library for now. There still might be some issues with stable/mitaka testing, so feel free to poke me or anyone in #fuel-infra and we’ll try to iron this out as quickly as possible. -- Igor Belikov Fuel CI Engineer ibeli...@mirantis.com > On 22 Mar 2016, at 22:42, Alex Schultz wrote: > > Hey everyone, > > Emilien is in the process of cutting the stable/mitaka branches for all of > the upstream puppet modules. As Fuel approaches SCF, we will want to switch > from the master branches we are currently tracking to leverage the > stable/mitaka branches. In talking with some other folks, I believe the plan > is the following switch fuel-library to leverage stable/mitaka branches prior > to SCF. Once we open master backup for Newton activities, we will switch the > fuel-library master branch back to tracking the upstream master branches > while leaving our stable/mitaka branch pointed to the upstream stable/mitaka > branches. > > As far as these activities are concerned, I believe Ivan Berezovskiy will be > providing a patch to do the switch to stable/mitaka. Additionally we will > want to ensure that the fuel-ci will work for the upstream stable/mitaka > branches as it currently[0] isn't working since we haven't cut a > stable/mitaka branch for Fuel yet. Igor Belikov has been notified of the > current issues and is looking into a fix. > > Please raise any concerns or items that also need to be addressed. > > Thanks, > -Alex > > [0] https://review.openstack.org/#/c/295976/ > <https://review.openstack.org/#/c/295976/>__ > 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
Re: [openstack-dev] [Fuel] removing single mode
Folks, Changes in CI jobs have been made, for master branch of fuel-library we are running CentOS HA + Nova VLAN and Ubuntu HA + Neutron VLAN . Job naming schema has also been changed, so now it includes actual testgroup. Current links for master branch CI jobs are [1] and [2], all other jobs can be found here[3] or will show up in your gerrit reviews. ISO and environments have been updated to the latest ones. [1]https://fuel-jenkins.mirantis.com/job/master.fuel-library.centos.ha_nova_vlan/ <https://fuel-jenkins.mirantis.com/job/master.fuel-library.centos.ha_nova_vlan/> [2]https://fuel-jenkins.mirantis.com/job/master.fuel-library.ubuntu.ha_neutron_vlan/ <https://fuel-jenkins.mirantis.com/job/master.fuel-library.ubuntu.ha_neutron_vlan/> [3]https://fuel-jenkins.mirantis.com <https://fuel-jenkins.mirantis.com/> -- Igor Belikov Fuel DevOps ibeli...@mirantis.com > On 29 Jan 2015, at 13:42, Aleksandr Didenko wrote: > > Mike, > > > Any objections / additional suggestions? > > no objections from me, and it's already covered by LP 1415116 bug [1] > > [1] https://bugs.launchpad.net/fuel/+bug/1415116 > <https://bugs.launchpad.net/fuel/+bug/1415116> > > On Wed, Jan 28, 2015 at 6:42 PM, Mike Scherbakov <mailto:mscherba...@mirantis.com>> wrote: > Folks, > one of the things we should not forget about - is out Fuel CI gating > jobs/tests. [1], [2]. > > One of them is actually runs simple mode. Unfortunately, I don't see details > about tests ran for [1], [2], but I'm pretty sure it's same set as [3], [4]. > > I suggest to change tests. First of all, we need to get rid of simple runs > (since we are deprecating it), and second - I'd like us to run Ubuntu HA + > Neutron VLAN for one of the tests. > > Any objections / additional suggestions? > > [1] > https://fuel-jenkins.mirantis.com/job/master_fuellib_review_systest_centos/ > <https://fuel-jenkins.mirantis.com/job/master_fuellib_review_systest_centos/> > [2] > https://fuel-jenkins.mirantis.com/job/master_fuellib_review_systest_ubuntu/ > <https://fuel-jenkins.mirantis.com/job/master_fuellib_review_systest_ubuntu/> > [3] https://fuel-jenkins.mirantis.com/job/6_0_fuellib_review_systest_centos/ > <https://fuel-jenkins.mirantis.com/job/6_0_fuellib_review_systest_centos/> > [4] https://fuel-jenkins.mirantis.com/job/6_0_fuellib_review_systest_ubuntu/ > <https://fuel-jenkins.mirantis.com/job/6_0_fuellib_review_systest_ubuntu/> > > On Wed, Jan 28, 2015 at 2:28 PM, Sergey Vasilenko <mailto:svasile...@mirantis.com>> wrote: > +1 to replace simple to HA with one controller > > /sv > > __ > 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 > <http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev> > > > > > -- > Mike Scherbakov > #mihgen > > > __ > 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 > <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 __ 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
