[2016-05-30] Lago Weekly Meeting Minutes
by David Caro
oVirt system tests status:
==========================
* 3.6 working
* Master working
* Image Failing due to appliance known issue (engine is not getting installed
on the appliance, fabiand is on it)
* New suite on it's way: Hosted engine (lev is working on it)
**AI**: create a readthedocs page
Last release items:
====================
Lago VM, VMProvider and Service plugins merged and released
Next relase items:
==================
Lago + repoman integration patch was merged, next lago release will require
repoman to be available (ovirt ci-tools repo has the latest version)
Installation howto effort
==========================
* Installed lago on rhel 7.2 (some difficulties with the deps, probably mixed
channels)
* For some reason lago requires ovirtlago on start/stop
Cheers!!
--
David Caro
Red Hat S.L.
Continuous Integration Engineer - EMEA ENG Virtualization R&D
Tel.: +420 532 294 605
Email: dcaro(a)redhat.com
IRC: dcaro|dcaroest@{freenode|oftc|redhat}
Web: www.redhat.com
RHT Global #: 82-62605
8 years, 11 months
[2016-05-26] Weekly lago release 0.19.0
by David Caro
Hi everyone!
A new lago release is out, this one adds the possibility to extend lago with
three new plugins:
* VMPlugin: Allows to modify each and every VM action, useful though when
you want to extend the actions a VM can take, or customize some high
level behavior (like defining a different set of artifacts to collect)
We have lago.vm.DefaultVM (default), ovirtlago.virt.EngineVM
(ovirt-engine), ovirtlago.virt.NodeVM (ovirt-node) and
ovirtlago.virt.HostVM (ovirt-host).
You can specify which one your domain belongs to with the key 'vm-type'
and one of the above values, like:
domains:
my_domain:
vm-type: ovirt-engine
...
* VMProvider: Allows to implement a different set of low-level methods,
like snapshot, or start/stop a vm, to allow to use different
virtualization (or not) systems (only
LocalLibvirtVMProvider (local-libvirt) and SSHVMProvider (ssh) are
implemented right now).
You can specify a custom provider for your domains with the
'vm-provider' key, like:
domains:
my_domain:
vm-provider: local-libvirt
...
* ServicePlugin: This is the class that implements the service-handling
functions for a vm, starting/stopping a service, checking if the
service is enabled, etc.
Current implementations are SystemdService (systemd), SysVInitService
(sysvinit) and SystemdContainerService (systemdcontainer).
You can specify a custom service provider for your domain with the key
'service_provider':
domains:
my_domain:
service_provider: systemd
...
Another important fixed bug is that now copying a directory to a vm works :)
For the latest docs and changelog you can go to the docs page:
http://lago.readthedocs.io/en/0.19/
Enjoy!
--
David Caro
Red Hat S.L.
Continuous Integration Engineer - EMEA ENG Virtualization R&D
Tel.: +420 532 294 605
Email: dcaro(a)redhat.com
IRC: dcaro|dcaroest@{freenode|oftc|redhat}
Web: www.redhat.com
RHT Global #: 82-62605
8 years, 11 months
Lago and Vagrant
by Eric Helms
I recall seeing some discussion of Lago vs Vagrant and how there could be
some leverage between the two. We are currently using Lago in our release
testing pipeline, however, for years now we've been using Vagrant for
deploying developer and production hand-on testing environments. There are
benefits to how we test and build environments to centering on a singular
technology. Thus, I had a few questions I was hoping to get some thoughts
on:
1) What was the outcome of the Lago vs Vagrant discussions?
2) How to reconcile the built up base of Vagrant use within our group with
Lago (or how to sell switching to Lago)?
3) Do you see them as co-existing with different application points?
To give an example of a disconnect where centering technology would
benefit, we do an installation test currently spinning up a Lago based
environment. Users testing our builds are using our existing Vagrant setup
to spin up environments. However, we aren't testing the setup and
configuration users are using and we end up double building the techniques
for setting up environments.
Thanks for any thoughts,
Eric
8 years, 11 months
New 0.18 version is out!
by David Caro
New lago 0.18 version is out, as the last one was done just a couple of days
ago, there are not many changes, just a couple of bugfixes:
* Expanding any vars on any url
* Pinning down the version of yapf used
For the latest docs:
http://lago.readthedocs.io/en/0.18/
Cheers!
--
David Caro
Red Hat S.L.
Continuous Integration Engineer - EMEA ENG Virtualization R&D
Tel.: +420 532 294 605
Email: dcaro(a)redhat.com
IRC: dcaro|dcaroest@{freenode|oftc|redhat}
Web: www.redhat.com
RHT Global #: 82-62605
8 years, 11 months
Lago Demo
by Gal Ben Haim
Hi All,
I wrote a document which demonstrates a basic use case of Lago.
The reader should follow the instructions in the document, and thus
get a sense about Lago's capabilities and ease of use.
This document should guide the user in his first experience, and this is why
I'm not exposing the advanced capabilities of Lago (we will have another document for this).
I would like you to try out the document, and write back a review.
Link to the document: https://github.com/gbenhaim/Lago-Demo
Thanks !
Gal Ben Haim
gbenhaim(a)redhat.com
RHEV DevOps
8 years, 11 months
[2016-05-18] Weekly lago release
by David Caro
Hi everyone!!
Last week's release was delayed a little bit due to the holidays, so we are
releasing today, the new 0.17 version of lago comes with some interesting
improvements:
9253f807: Added possibility to use env vars on disk path and url
c7ff5190: Removed the repo verification code
- replaced by retries and workarounds
61813f2e: Fix wait_for_ssh logic
- now the times and tries when waiting for ssh make more sense, and
have better logging
1ec94d55: Added LAGO_INITFILE_PATH env var when running init
86a8bde1: Setting LAGO_WORKDIR_PATH too on init
7a661154: Copy inside the prefix the deploy scripts
499c9912: Expanding the disks path on vm xml generation
c5f6cafb: Using LAGO_PREFIX_DIR for the disk images too
So the most change is the possibility to use env variables in the init file,
and the addition of the env vars:
* LAGO_PREFIX_DIR
* LAGO_WORKDIR_PATH
* LAGO_INITFILE_PATH (only when running lago init)
That allow you to better specify relative paths to the different files (disks,
scripts, urls...). And that allow to keep the workdir functional even after
renaming them (mv old_workdir new_workdir).
For the updated docs and changelog:
http://lago.readthedocs.io/en/0.17/
For the rpms:
http://resources.ovirt.org/repos/lago/stable/0.0/rpm/
--
David Caro
Red Hat S.L.
Continuous Integration Engineer - EMEA ENG Virtualization R&D
Tel.: +420 532 294 605
Email: dcaro(a)redhat.com
IRC: dcaro|dcaroest@{freenode|oftc|redhat}
Web: www.redhat.com
RHT Global #: 82-62605
8 years, 11 months
Can't run tests with latest Lago & ovirt-system-tests
by Yaniv Kaul
I've updated to the latest ovirt-system-tests, and apparently
commit ed759a62 was breaking things to me. So I've updated Lago to latest
(from
http://resources.ovirt.org/repos/lago/unstable/0.0/latest/rpm/fc23/noarch/
) - which is 0.16.12-1 now, and now things break differently, possibly by
Lago commit ba6dda1e92faf26bc6842a78143ced20ae0546ff
@ Create prefix internal repo: ERROR (in 0:00:00)
Error occured, aborting
Traceback (most recent call last):
File "/usr/lib/python2.7/site-packages/ovirtlago/cmd.py", line 248, in
do_run
self.cli_plugins[args.ovirtverb].do_run(args)
File "/usr/lib/python2.7/site-packages/lago/plugins/cli.py", line 180, in
do_run
self._do_run(**vars(args))
File "/usr/lib/python2.7/site-packages/lago/utils.py", line 584, in
wrapper
return func(*args, **kwargs)
File "/usr/lib/python2.7/site-packages/lago/utils.py", line 595, in
wrapper
return func(*args, prefix=prefix, **kwargs)
File "/usr/lib/python2.7/site-packages/ovirtlago/cmd.py", line 166, in
do_ovirt_reposetup
skip_sync=skip_sync,
File "/usr/lib/python2.7/site-packages/lago/log_utils.py", line 615, in
wrapper
return func(*args, **kwargs)
File "/usr/lib/python2.7/site-packages/ovirtlago/__init__.py", line 423,
in prepare_repo
_sync_rpm_repository(rpm_repo, reposync_yum_config, repos)
File "/usr/lib/python2.7/site-packages/ovirtlago/__init__.py", line 105,
in _sync_rpm_repository
ret, out, _ = utils.run_command(reposync_command)
AttributeError: 'module' object has no attribute 'run_command
Any idea?
8 years, 12 months
