Re: [openstack-dev] [Fuel] Nominate Alexey Stepanov for fuel-qa and fuel-devops core
e > <http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > > -- > Best regards, > Vladimir Khlyunev > QA engineer, > Mirantis Inc. > > __ > 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 > > > > > -- > Best Regards, > > Alex > > > __ > 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 -- Regards, Dennis Dmitriev QA Engineer, Mirantis Inc. http://www.mirantis.com e-mail/jabber: dis.x...@gmail.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] New version of fuel-devops (2.9.21)
Hi Bogdan, thanks for the question! On 07/12/2016 10:26 AM, Bogdan Dobrelya wrote: > On 07/12/2016 09:24 AM, Bogdan Dobrelya wrote: >> Thank you for a hard work, that's a really great tool. >> >> Anyone who is interested, please note that fuel-devops, despite of the >> name, may be used outside of Fuel and OpenStack as a really fast and >> easy way to spin up VMs for a dev envs. Almost like a Vagrant, although >> it gives you advanced templates [1] which is more flexible at least for >> networking perhaps. >> >> By the way, fuel-devops folks, do you plan to add docs [2] for advanced >> templating as well? >> Some docs with template examples are located in [1]. After merging a couple of important patches [2] [3] , we plan to improve the auto documentation and get the complete manual for all the options, then it can be placed to /fuel-docs/. [1] https://github.com/openstack/fuel-devops/tree/master/doc/source/template_examples [2] https://review.openstack.org/#/c/333224/ [3] https://review.openstack.org/#/c/338496/ > Sorry, here is the correct docs link [3] :-) > >> [1] >> https://specs.openstack.org/openstack/fuel-specs/specs/8.0/template-based-virtual-devops-environments.html >> [2] >> https://git.openstack.org/cgit/openstack/fuel-ccp-installer/tree/utils/jenkins/default30-kargo.yaml > [3] http://docs.openstack.org/developer/fuel-docs/devdocs/devops.html > >> >> On 07/11/2016 08:39 PM, Dennis Dmitriev wrote: >>> Hi All, >>> >>> We are going to update the 'fuel-devops' framework on our product CI to >>> the version 2.9.21. >>> >>> Changes since 2.9.20: >>> >>> * For devops: >>> >>> - Scripts for export and import systest environments, based on >>> external libvirt snapshots [1] >>> - Disable creation of nwfilters by default [2] >>> - Get rid from log.yaml file, logger and it's settings were moved into >>> scripts [3] >>> - Do not use database ids in bridge and interface names, that allows >>> to use several different virtual environments with different set of >>> requirements on the same host [4] [5] [6] >>> >>> * For QA automation: >>> >>> - 'ipaddr' was replaced with 'netaddr' [7] >>> - Use keystoneauth1 package for authorization to Nailgun [8] >>> - Move the method execute_through_host() from fuel-qa to SSHClient [9] >>> - Methods that allow to change boot order and close tray for Node [10] >>> - Lots of SSHClient improvements [11] [12] [13] [14] [15] >>> - Improvements for compatibility with python3 >>> >>> List of all changes can be found on github [16]. >>> >>> [1] https://review.openstack.org/#/c/280573/ >>> [2] https://review.openstack.org/#/c/313082/ >>> [3] https://review.openstack.org/#/c/320366/ >>> [4] https://review.openstack.org/#/c/327082/ >>> [5] https://review.openstack.org/#/c/336057/ >>> [6] https://review.openstack.org/#/c/339811/ >>> [7] https://review.openstack.org/#/c/299428/ >>> [8] https://review.openstack.org/#/c/314505/ >>> [9] https://review.openstack.org/#/c/319920/ >>> [10] https://review.openstack.org/#/c/331660/ >>> [11] https://review.openstack.org/#/c/331120/ >>> [12] https://review.openstack.org/#/c/327656/ >>> [13] https://review.openstack.org/#/c/327180/ >>> [14] https://review.openstack.org/#/c/326462/ >>> [15] https://review.openstack.org/#/c/338161/ >>> [16] - https://github.com/openstack/fuel-devops/compare/2.9.20...release/2.9 >>> >> > -- Regards, Dennis Dmitriev QA Engineer, Mirantis Inc. http://www.mirantis.com e-mail/jabber: dis.x...@gmail.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][QA] Changes in requirements.txt in the fuel-qa repository
Hi all, Recently there was a change in the fuel-qa requirements [1], that can be found in patches for 6.1, 7.0, 8.0, mitaka and master [2] [3] [4] [5] [6]. The goal is to split the requirements for system tests from requirements for fuel-devops, which is mostly the part of the system configuration than the separated package at the moment. This allows to update packages for fuel-qa on every run of system tests automatically, without manual tracking changes in [1]. * To setup a virtual environment, please use [7] instead of [1]. In the [7] is the link to the fuel-devops source with necessary tag. * To update requirements for fuel-qa system tests, there are two ways: - Install necessary packages from [1] (it will be an additional 'pip install' in your deploy script) - Run fuel-qa/utils/jenkin/system_tests.sh with the key -N or export the variable UPDATE_REQUIREMENTS='yes' . In this case, the script system_tests.sh will try to install packages from [1] every run (pip install [1] , without --upgrade), that will keep the requirements for fuel-qa tests up-to-date automatically. Also, there is a requirement for fuel-devops as a package [8], which is also used by system_tests.sh. Fuel-devops is not packaged yet, so [8] cannot be used for install the package, only for control that the necessary version of the package is installed. *Please* check your CI scripts that create virtual environments for fuel-qa tests and update the requirements installation commands as soon as possible! [1] https://raw.githubusercontent.com/openstack/fuel-qa/master/fuelweb_test/requirements.txt [2] https://review.openstack.org/#/c/334552/ [3] https://review.openstack.org/#/c/340319/ [4] https://review.openstack.org/#/c/340332/ [5] https://review.openstack.org/#/c/340323/ [6] https://review.openstack.org/#/c/340325/ [7] https://raw.githubusercontent.com/openstack/fuel-qa/master/fuelweb_test/requirements-devops-source.txt [8] https://raw.githubusercontent.com/openstack/fuel-qa/master/fuelweb_test/requirements-devops.txt -- Regards, Dennis Dmitriev QA Engineer, Mirantis Inc. http://www.mirantis.com e-mail/jabber: dis.x...@gmail.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] New version of fuel-devops (2.9.21)
Hi All, We are going to update the 'fuel-devops' framework on our product CI to the version 2.9.21. Changes since 2.9.20: * For devops: - Scripts for export and import systest environments, based on external libvirt snapshots [1] - Disable creation of nwfilters by default [2] - Get rid from log.yaml file, logger and it's settings were moved into scripts [3] - Do not use database ids in bridge and interface names, that allows to use several different virtual environments with different set of requirements on the same host [4] [5] [6] * For QA automation: - 'ipaddr' was replaced with 'netaddr' [7] - Use keystoneauth1 package for authorization to Nailgun [8] - Move the method execute_through_host() from fuel-qa to SSHClient [9] - Methods that allow to change boot order and close tray for Node [10] - Lots of SSHClient improvements [11] [12] [13] [14] [15] - Improvements for compatibility with python3 List of all changes can be found on github [16]. [1] https://review.openstack.org/#/c/280573/ [2] https://review.openstack.org/#/c/313082/ [3] https://review.openstack.org/#/c/320366/ [4] https://review.openstack.org/#/c/327082/ [5] https://review.openstack.org/#/c/336057/ [6] https://review.openstack.org/#/c/339811/ [7] https://review.openstack.org/#/c/299428/ [8] https://review.openstack.org/#/c/314505/ [9] https://review.openstack.org/#/c/319920/ [10] https://review.openstack.org/#/c/331660/ [11] https://review.openstack.org/#/c/331120/ [12] https://review.openstack.org/#/c/327656/ [13] https://review.openstack.org/#/c/327180/ [14] https://review.openstack.org/#/c/326462/ [15] https://review.openstack.org/#/c/338161/ [16] - https://github.com/openstack/fuel-devops/compare/2.9.20...release/2.9 -- Regards, Dennis Dmitriev QA Engineer, Mirantis Inc. http://www.mirantis.com e-mail/jabber: ddmitr...@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] New version of fuel-devops (2.9.20)
Hi All, We are going to update the 'fuel-devops' framework on our product CI to the version 2.9.20. Changes since 2.9.17: * Fixes: - Fixes related to time synchronization issues: [1], [2], [10] - Fix for 'dos.py create' CLI command [4] - Use 0644 access mode for libvirt volumes created by fuel-devops [8] - Do not raise an exception while removing a libvirt object, if the object is missing in libvirt. Just skip it. [9] - Add timeout parameter to the tcp_ping method [7] * Features: - Allow to pass custom SSH credentials for slave nodes in environment variables: ENV_SLAVE_LOGIN and ENV_SLAVE_PASSWORD [3] - Get unique bridges/interfaces prefixes for each environment on the host using a 3-digits hash calculated from ENV_NAME and DATABASES objects as a salt for names of libvirt bridges and qemu network interfaces [5] - Extend Interface and Network models with methods for blocking traffic (for failover/destructive tests) [6] - Emulate multipath disk devices for libvirt VMs. Environment variable SLAVE_MULTIPATH_DISKS_COUNT is a multiplier for 'system' and 'cinder' volume names for slave nodes. 'multipath_count' key can be used for volumes in YAML template for more flexible configuration [11] - Enable NUMA for libvirt VMs [12]. To use NUMA, the following environment variables should be specified: $ export NUMA_NODES=2 # amount of NUMA nodes on each VM (including Fuel master) $ export DRIVER_ENABLE_ACPI=true # required for NUMA $ export IFACE_0=ens3 # can be required for fuel-qa system tests because of enabled ACPI ... $ export IFACE_5=ens8 All changes since 2.9.17: [13] [1] https://review.openstack.org/#/c/272200/ [2] https://review.openstack.org/#/c/277900/ [3] https://review.openstack.org/#/c/281262/ [4] https://review.openstack.org/#/c/282007/ [5] https://review.openstack.org/#/c/282732/ [6] https://review.openstack.org/#/c/275134/ [7] https://review.openstack.org/#/c/284422/ [8] https://review.openstack.org/#/c/285241/ [9] https://review.openstack.org/#/c/294143/ [10] https://review.openstack.org/#/c/294002/ [11] https://review.openstack.org/#/c/286804/ [12] https://review.openstack.org/#/c/292352/ [13] https://github.com/openstack/fuel-devops/compare/2.9.17...2.9.20 -- Regards, Dennis Dmitriev QA Engineer, Mirantis Inc. http://www.mirantis.com e-mail/jabber: ddmitr...@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][QA] New runner for fuel-qa system tests
Hi all! Please be informed that we merged a new runner for fuel-qa system tests [1] : run_system_test.py Features of new runner: - auto discovering all test in both test suites ([2] and [3]) - show the groups from the test suites - explain content of groups - run the several groups at the same time - combine configuration with the test groups from new suite - run old groups (from [2]) - use runner in utils/jenkins/system_tests.sh IMPORTANT: For old-style system tests from [2] there is no impact. But there was a significant change for template-based tests [3] in the test case declaration: - add @testcase decorator use instead of @factory Here is an example of how test case was changed: [4] Please make the same changes if fuel-qa is used as a module for running your external test cases. [1] https://review.openstack.org/#/c/240016/ [2] https://github.com/openstack/fuel-qa/tree/master/fuelweb_test/tests [3] https://github.com/openstack/fuel-qa/tree/master/system_test/tests [4] https://review.openstack.org/#/c/240016/27/system_test/tests/test_redeploy_after_stop.py -- Regards, Dennis Dmitriev QA Engineer, Mirantis Inc. http://www.mirantis.com e-mail/jabber: dis.x...@gmail.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][QA] What is the preferred way to bootstrap a baremetal node with Fuel on product CI?
Thanks to all for answers! We will leave Fuel master node on a VM for our testing until some specific cases will require it on a baremetal. Ironic looks like a good tool for PXE provisioning and manage other baremetal slaves via IPMI, we will investigate how it could be used in our testing tools later. On 02/10/2016 12:43 PM, Vladimir Kuklin wrote: > Folks > > I think the easiest and the best option here is to boot iPXE or > pxelinux with NFS and put master node image onto an NFS mount. This > one should work seamlessly. > > On Wed, Feb 10, 2016 at 1:36 AM, Andrew Woodward > <awoodw...@mirantis.com <mailto:awoodw...@mirantis.com>> wrote: > > Unless we hope to gain some insight and specific testing by > installing the ISO on a bare-metal node (like UEFI), I'd propose > that we stop testing things that are well tested elsewhere (a > given ISO produces a working fuel master) and just focus on what > we want to test in this environment. > > Along this line, we cold > > a) keep fuel masternode as a VM that is set up with access to the > networks with the BM nodes. We have a good set of tools to build > the master node in a VM already we can just re-use time > > b) use cobbler to control PXE based ISO boot/install, then either > create new profiles in cobbler for various fuel nodes with > different ISO or replace the single download link. (Make sure you > transfer the image over HTTP as TFTP will be slow for such size. > We have some tools and knowledge around using cobbler as this is > effectively what fuel does its self. > > c) fuel on fuel, as an extension of b, we can just use cobbler on > an existing fuel node to provision another fuel node, either from > ISO or even it's own repo's (we just need to send a kickstart) > > d) you can find servers with good BMC or DRAC that we can issue > remote mount commands to the virtual cd-rom > > e) consider using live-cd approach (long implmentation). I've been > asked about supporting this in product where we start an > environment with live-cd, the master node may make it's own home > and then it can be moved off the live-cd when it's ready > > > On Tue, Feb 9, 2016 at 10:25 AM Pavlo Shchelokovskyy > <pshchelokovs...@mirantis.com > <mailto:pshchelokovs...@mirantis.com>> wrote: > > Hi, > > Ironic also supports running it as standalone service, w/o > Keystone/Glance/Neutron/Nova etc integration, deploying images > from HTTP links. Could that be an option too? > > BTW, there is already an official project under OpenStack > Baremetal program called Bifrost [0] that, quoting, "automates > the task of deploying a base image onto a set of known > hardware using Ironic" by installing and configuring Ironic in > standalone mode. > > [0] https://github.com/openstack/bifrost > > Cheers, > > > On Tue, Feb 9, 2016 at 6:46 PM Dennis Dmitriev > <ddmitr...@mirantis.com <mailto:ddmitr...@mirantis.com>> wrote: > > Hi all! > > To run system tests on CI on a daily basis using baremetal > servers > instead of VMs, Fuel admin node also should be bootstrapped. > > There is no a simple way to mount an ISO with Fuel as a > CDROM or USB > device to a baremetal server, so we choose the > provisioning with PXE. > > It could be done in different ways: > > - Configure a libvirt bridge as dnsmasq/tftp server for > admin/PXE network. > Benefits: no additional services to be configured. > Doubts: ISO should be mounted on the CI host (via > fusefs?); a HTTP > or NFS server for basic provisioning should be started in > the admin/PXE > network (on the CI host); > > - Start a VM that is connected to admin/PXE network, and > configure > dnsmasq/tftp there. > Benefits: no additional configuration on the CI host > should be > performed > Doubts: starting the PXE service becomes a little > complicated > > - Use Ironic for manage baremetal nodes. > Benefits: good support for different hardware, > support for > provisioning from ISO 'out of the box'. > Doubts: support for Ironic cannot be implemented in > short terms,
[openstack-dev] [Fuel][QA] What is the preferred way to bootstrap a baremetal node with Fuel on product CI?
Hi all! To run system tests on CI on a daily basis using baremetal servers instead of VMs, Fuel admin node also should be bootstrapped. There is no a simple way to mount an ISO with Fuel as a CDROM or USB device to a baremetal server, so we choose the provisioning with PXE. It could be done in different ways: - Configure a libvirt bridge as dnsmasq/tftp server for admin/PXE network. Benefits: no additional services to be configured. Doubts: ISO should be mounted on the CI host (via fusefs?); a HTTP or NFS server for basic provisioning should be started in the admin/PXE network (on the CI host); - Start a VM that is connected to admin/PXE network, and configure dnsmasq/tftp there. Benefits: no additional configuration on the CI host should be performed Doubts: starting the PXE service becomes a little complicated - Use Ironic for manage baremetal nodes. Benefits: good support for different hardware, support for provisioning from ISO 'out of the box'. Doubts: support for Ironic cannot be implemented in short terms, and there should be performed additional investigations. My question is: what other benefits or doubts I missed for first two ways? Is there other ways to provision baremetal with Fuel that can be automated in short terms? Thanks for any suggestions! -- Regards, Dennis Dmitriev QA Engineer, Mirantis Inc. http://www.mirantis.com e-mail/jabber: dis.x...@gmail.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][QA] added fuel-devops branch 'release/2.9'
Hi all, New branch 'release/2.9' was added to the repository 'fuel-devops' last week. This branch was created to keep supporting 2.9.x code while fuel-devops 3.0.0 will be merged to the 'master' branch. Please create all fixes for fuel-devops v2.9.x directly into 'release/2.9' branch instead of 'master' because of a big difference in code between 2.9.x and 3.0.0 Also please join to review of fuel-devops 3.0.0 patches that implement the flexible object scheme for store and manipulate with data from fuel-devops YAML templates [1]: https://review.openstack.org/274749 New Libvirt Driver Model https://review.openstack.org/274750 New Network Models https://review.openstack.org/274751 Volume model changes https://review.openstack.org/274752 Node model changes https://review.openstack.org/274753 New LibvirtXMLBuilder https://review.openstack.org/274754 Group and Environment changes https://review.openstack.org/274755 shell.py changes https://review.openstack.org/274756 Migration for new model schema. https://review.openstack.org/274757 Update unit tests Update verion to 3.0.0 These patches will be merged all at once after all of them pass review, implementing the new functionality for 'master' branch. Backward compatibility with fuel-devops 2.9.x should be preserved for fuel-qa tests (for Fuel 6.1, 7.0, 8.0), but it is not tested yet. [1] https://github.com/openstack/fuel-specs/blob/master/specs/8.0/template-based-virtual-devops-environments.rst -- Regards, Dennis Dmitriev QA Engineer, Mirantis Inc. http://www.mirantis.com e-mail/jabber: dis.x...@gmail.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] New version of fuel-devops (2.9.17)
Hi All, We are going to update the 'fuel-devops' framework on our product CI to the version 2.9.17. This is bugfix update. Changes since 2.9.16: - Fix for timesync in fuel-devops environments where Fuel keystone password was changed [1] - Fix external snapshots behaviour for cpu mode = host-passthrough [2] All changes since 2.9.16: [3] [1] https://bugs.launchpad.net/fuel/+bug/1534789 [2] https://bugs.launchpad.net/fuel/+bug/1535259 [3] https://github.com/openstack/fuel-devops/compare/2.9.16...master -- Regards, Dennis Dmitriev QA Engineer, Mirantis Inc. http://www.mirantis.com e-mail/jabber: ddmitr...@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] New version of fuel-devops (2.9.16)
Hi All, We are going to update the 'fuel-devops' framework on our product CI to the version 2.9.16 on Friday, 15 Jan. This is bugfix update. Changes since 2.9.15: - Default memory size for Fuel master node updated to 3Gb [1] - Added support for creation Fuel master node with Centos 7 from fuel-devops CLI [2]. - Fix ironic-slave role [3] - A couple of other minor changes. List of all changes can be found on github [4]. [1] - https://review.openstack.org/#/c/258949/ [2] - https://bugs.launchpad.net/fuel/+bug/1524440 [3] - https://bugs.launchpad.net/fuel/+bug/1532124 [4] - https://github.com/openstack/fuel-devops/compare/2.9.15...master -- Regards, Dennis Dmitriev QA Engineer, Mirantis Inc. http://www.mirantis.com e-mail/jabber: ddmitr...@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] new branch stable/2.9 for fuel-devops
+ mos-dev & mos-qa 12.01.2016 13:26, Dennis Dmitriev пишет: > Hi all! > > Framework QA team is going to merge a lot of changes to the > fuel-devops repository [0] , to complete support for template-based > creation of virtual environments [1]. > Current fuel-devops data object model will be modified to support > additional data, that will be required for more flexible virtual > environments or additional fuel-devops drivers like baremetal driver. > > So we would like to make a stable/2.9 branch for current fuel-devops > code with version 2.9.x, and implement our changes in master branch with > fuel-devops version 3.0. > > This changes should not affect CI because fuel-devops updates on CI use > tags instead of branches. For further fuel-devops updates/bugfixes we > will continue to use tags. > > > [0] - https://github.com/openstack/fuel-devops/ > [1] - > https://github.com/openstack/fuel-specs/blob/master/specs/8.0/template-based-virtual-devops-environments.rst > -- Regards, Dennis Dmitriev QA Engineer, Mirantis Inc. http://www.mirantis.com e-mail/jabber: dis.x...@gmail.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] new branch stable/2.9 for fuel-devops
Hi all! Framework QA team is going to merge a lot of changes to the fuel-devops repository [0] , to complete support for template-based creation of virtual environments [1]. Current fuel-devops data object model will be modified to support additional data, that will be required for more flexible virtual environments or additional fuel-devops drivers like baremetal driver. So we would like to make a stable/2.9 branch for current fuel-devops code with version 2.9.x, and implement our changes in master branch with fuel-devops version 3.0. This changes should not affect CI because fuel-devops updates on CI use tags instead of branches. For further fuel-devops updates/bugfixes we will continue to use tags. [0] - https://github.com/openstack/fuel-devops/ [1] - https://github.com/openstack/fuel-specs/blob/master/specs/8.0/template-based-virtual-devops-environments.rst -- Regards, Dennis Dmitriev QA Engineer, Mirantis Inc. http://www.mirantis.com e-mail/jabber: dis.x...@gmail.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][QA] New version of fuel-devops (2.9.15)
+openstack-dev On 12/14/2015 02:40 PM, Dennis Dmitriev wrote: > Hi All, > > We have updated the version of 'fuel-devops' framework to the 2.9.15. > > This is mainly bugfix update. > > Version 2.9.15 will be updated on our product CI during next several days. > > Changes since 2.9.13: > > - Process boolean environment variables like in fuel-qa, new method > get_var_as_bool(); > > - Use CPU mode 'host-passthrough' to get fuel-devops working on newest > CPUs [1]; > > - Fix role names in Node model [2]: > 'admin' => 'fuel_master' > 'slave' => 'fuel-slave' > > - Fix 'dos.py create' CLI command [3]; > > - Fix time synchronization for nodes with systemd [4]; > > - Partial support for external snapshots [5] (Disabled by default) > > - Minor fixes and documentation update > > List of all changes can be found on github [6]. > > [1] - https://bugs.launchpad.net/fuel/+bug/1485047 > [2] - https://bugs.launchpad.net/fuel/+bug/1521271 > [3] - https://bugs.launchpad.net/fuel/+bug/1521520 > [4] - https://bugs.launchpad.net/fuel/+bug/1523523 > [5] - https://review.openstack.org/#/c/235566/ > [6] - https://github.com/openstack/fuel-devops/compare/2.9.13...master > -- Regards, Dennis Dmitriev QA Engineer, Mirantis Inc. http://www.mirantis.com e-mail/jabber: dis.x...@gmail.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] [QA] [Tests] MOS integration tests in SWARM test suite
Hi Timur, Please take into account that Rally/Tempest tests should be added to fuel-qa/system_test/ folder instead of fuel-qa/fuelweb_test/. It is necessary for using template-based approach for this tests. It would be good to move there also sahara/murano tests. 08.12.2015 09:41, Timur Nurlygayanov пишет: > Hi Boris, > > yes, we will use Rally verify command to run Tempest tests, at least > for [1]. It works fine and we want to use it. > > On Tue, Dec 8, 2015 at 4:12 AM, Boris Pavlovic <bpavlo...@mirantis.com > <mailto:bpavlo...@mirantis.com>> wrote: > > Timur, > > I hope you are going to use for [1] and [2] Rally verify command? > > > Best regards, > Boris Pavlovic > > On Mon, Dec 7, 2015 at 6:09 AM, Timur Nurlygayanov > <tnurlygaya...@mirantis.com <mailto:tnurlygaya...@mirantis.com>> > wrote: > > Hi Fuel team, > > we have a lot of automated integration tests for OpenStack > verification and we want to add execution of these tests to > Fuel SWARM test suite (to run these tests on daily basis and > on per commit basis). > > We used our own bash scripts to deploy OpenStack environments > with Fuel before, but now we have no resources to maintain > these scripts. Fuel QA and MOS QA teams invest a lot of > efforts to improve existing QA framework with BVT/SWARM tests. > This is why we want to add our integration automated tests to > SWARM test suite, where we already have good framework to > manage fuel environments. > > We started to move our integration tests to SWARM test suite: > 1. Sahara integration tests with deployment of all available > Sahara cluster / plugins types: > https://review.openstack.org/#/c/248602/ (merged) > 2. Murano integration tests with deployment of all available > Murano applications: > https://review.openstack.org/#/c/249850/(on review) > > We are going to add execution of full Tempest tests suite [1] > and execution of all CLI-based functional tests [2] from > upstream projects. > These tests will be executed on separate hardware server, > where we will have enough resources (for example, integration > Murano and Sahara tests require 32 Gb of RAM on compute nodes > minimum). We already provided this server to fuel CI team. > > We want to merge these tests before MOS 8.0 to do all > acceptance testing with automated tests (and without manual > testing). > > In parallel, we are working on new approach of integration of > third-party functional / integration tests with SWARM test > suite. It is under the discussion now and it will be not > available in the nearest future. > > Please, let me know if you have objections or questions. > > [1] https://bugs.launchpad.net/fuel/+bug/1523515 > [2] https://bugs.launchpad.net/fuel/+bug/1523436 > > -- > > Timur, > Senior QA Engineer > OpenStack Projects > Mirantis Inc > > > __ > 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 > > > > > -- > > Timur, > Senior QA Engineer > OpenStack Projects > Mirantis Inc > > > __ > 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 -- Regards, Dennis Dmitriev QA Engineer, Mirantis Inc. http://www.mirantis.com e-mail/jabber: dis.x...@gmail.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
