lago-project / lago Goto Github PK

Moved from https://bugzilla.redhat.com/show_bug.cgi?id=1277658

Description of problem:
If you remove and reinstall lago, the gid for the lago group will change, and any templates created before will become unwitable for the rest of users (as they will remain owned by the previous gid)

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1.install lago and run once
2.remove lago
3.install again and run again

Actual results:
Error with unable to write to template cache dir

Expected results:
Correct run

For example, if you have:

"sources": {
     "local": {
        "args": {"baseurl": "http://127.0.0.1:8181"},
        "type": "http"
    }
}

When pulling in templates it will just append the path as "http://127.0.0.1:8181templatename

Moved from https://bugzilla.redhat.com/show_bug.cgi?id=1286801

Like any virtualization infrastructure, Lago needs a way to setup things like IP addresses, root passwords and hostnames inside the VMs.
cloud-init seems to be the standard way to do this which is supported by most of the images provided by distribution makers.

At the very least Lago needs to be able to disable cloud-init inside images to prevent long boot times for images that contain it.

#29 provides simple means of reporting progess of the download of the large templates.

Moved from https://bugzilla.redhat.com/show_bug.cgi?id=1278552

Right now the locally generated repo is passed to the hosts through http, that requires lago to start a process serving it on http, it would be easier and avoid port conflicts and allow using it offline to mount it on the hosts through an iso (or whatever)

Work started at https://gerrit.ovirt.org/#/c/45890

It was being worked on https://gerrit.ovirt.org/#/c/45437/

Just use "" as the domain name, it will create the prefix and fail on doing anything else, it should at least warn

Moved from https://bugzilla.redhat.com/show_bug.cgi?id=1279069

Description of problem:
When running the reposync command, if for any reason it breaks, it leaves a lockfile in the reposync dir that never gets cleaned up, making any other future run stck waiting for it to disappear

Moved from https://bugzilla.redhat.com/show_bug.cgi?id=1278553

Right now there are a few points where lago might collide with itself when running it in parallel in the same host, make sure that it does not happen.

That might allow us to use more than one executor in jenkins for example (the bm hosts are big enough for the load to not be an issue). Not so useful for the devs as the load might be too big for a common laptop.

That is needed when using virt-builder generated templates as the root partition is /dev/sda3 and it's name is not 'root'.

Description of problem:
When following the Lago README and setting up a repo file on EL7 with the following URL:

http://resources.ovirt.org/repos/lago/rpm/el$releasever

The repo doesn't work, and yum returns the following error:

http://resources.ovirt.org/repos/lago/rpm/el7Workstation/repodata/repomd.xml: [Errno 14] HTTP Error 404 - Not Found
Trying other mirror.

A symlink needs to be created from el7Workstation to el7, probably for el7Server too.

Description of problem:
Some hosts are in EST time zone, some on IST time zone. This makes it a bit more difficult to debug:
[ykaul@ykaul deployment-basic_suite_3.6]$ lagocli shell lago_basic_suite_3_6_host1
2015-12-29 16:08:15,793 - root - DEBUG - Running 9ac790ba on lago_basic_suite_3_6_host1: true
2015-12-29 16:08:15,813 - root - DEBUG - Command 9ac790ba on lago_basic_suite_3_6_host1 returned with 0
[root@lago_basic_suite_3_6_host1 ~]# date
Tue Dec 29 09:08:17 EST 2015
[root@lago_basic_suite_3_6_host1 ~]# exit
exit
[ykaul@ykaul deployment-basic_suite_3.6]$ lagocli shell lago_basic_suite_3_6_host0
2015-12-29 16:08:22,008 - root - DEBUG - Running 9e7be670 on lago_basic_suite_3_6_host0: true
2015-12-29 16:08:22,025 - root - DEBUG - Command 9e7be670 on lago_basic_suite_3_6_host0 returned with 0
[root@lago_basic_suite_3_6_host0 ~]# date
Tue Dec 29 09:08:22 EST 2015
[root@lago_basic_suite_3_6_host0 ~]# exit
exit
[ykaul@ykaul deployment-basic_suite_3.6]$ lagocli shell lago_basic_suite_3_6_engine
2015-12-29 16:08:34,602 - root - DEBUG - Running a5fd9a10 on lago_basic_suite_3_6_engine: true
2015-12-29 16:08:34,649 - root - DEBUG - Command a5fd9a10 on lago_basic_suite_3_6_engine returned with 0
[root@lago_basic_suite_3_6_engine ~]# date
Tue Dec 29 14:08:34 IST 2015
[root@lago_basic_suite_3_6_engine ~]# exit
exit
[ykaul@ykaul deployment-basic_suite_3.6]$ lagocli shell lago_basic_suite_3_6_storage-iscsi
2015-12-29 16:08:46,031 - root - DEBUG - Running accd8512 on lago_basic_suite_3_6_storage-iscsi: true
2015-12-29 16:08:46,050 - root - DEBUG - Command accd8512 on lago_basic_suite_3_6_storage-iscsi returned with 0
[root@lago_basic_suite_3_6_storage-iscsi ~]# date
Tue Dec 29 16:08:46 IST 2015
[root@lago_basic_suite_3_6_storage-iscsi ~]# exit
exit
[ykaul@ykaul deployment-basic_suite_3.6]$ lagocli shell lago_basic_suite_3_6_storage-nfs
2015-12-29 16:08:52,682 - root - DEBUG - Running b0c444c6 on lago_basic_suite_3_6_storage-nfs: true
2015-12-29 16:08:52,693 - root - DEBUG - Command b0c444c6 on lago_basic_suite_3_6_storage-nfs returned with 0
[root@lago_basic_suite_3_6_storage-nfs ~]# date
Tue Dec 29 16:08:52 IST 2015

migrated from https://bugzilla.redhat.com/show_bug.cgi?id=1294661

As they would be useful out of ovirt too, was being worked on here: https://gerrit.ovirt.org/#/c/45433/

Moved from https://bugzilla.redhat.com/show_bug.cgi?id=1285270

Description of problem:
CirrOS (https://launchpad.net/cirros) provides all the bits we need to launch a VM with Cloud-Init support (which we can actually login to as well).

We may need to look at guest agent support for it, though.

It is also VERY small, making it consumable, we can put it on Glance, the export domain, etc.

David Caro 2015-11-25 05:48:41 EST

there's already a cirros image in the git repo (7Mb) used for the lago functional tests, but yes, the guest agent does not work properly there so it's only used for the basic functional ones (start/stop/shell and a couple more).

You want to use it as base image for the second level vms? (lago starts the vdsm hosts, and inside those, the second level vms to test the vm creation and migration in ovirt)

Yaniv Kaul 2015-11-25 05:55:05 EST

(In reply to David Caro from comment #1)

You want to use it as base image for the second level vms? (lago starts the
vdsm hosts, and inside those, the second level vms to test the vm creation
and migration in ovirt)

Right - that was the idea behind it. Looks like, as there's no packages manager even, it'd be quite a challenge not only to port but also to install the guest agent there. I guess the better solution is Fedora's cloud image (https://getfedora.org/cloud/download/) - quite bigger, but completely operational for our needs (and fully supported upstream).

I therefore rephrased the request - we should have both, use cirros for whatever doesn't involve any guest work, and Fedora for the rest. Or we can settle on a single one - Fedora cloud image?

David Caro 2015-11-25 05:59:13 EST

That's exactly what we are doing for the lago functional tests (the ones that run when you change lago code). >We use the cirros for basic functional (run on each patch, is quite fast) and fedora cloud for the full functional tests.

We can do something similar for the ovirt-system-tests yes

Description of problem:

See https://bugzilla.redhat.com/show_bug.cgi?id=1218151#c3 for specific details.

Version-Release number of selected component (if applicable):
0.5

How reproducible:
Sometimes?

Migrated from: https://bugzilla.redhat.com/show_bug.cgi?id=1294625

Traceback (most recent call last):
File "/usr/lib/python2.7/site-packages/lago/cmd.py", line 535, in main
cli_plugins[args.verb].do_run(args)
File "/usr/lib/python2.7/site-packages/lago/plugins/cli.py", line 169, in do_run
self._do_run(*_vars(args))
File "/usr/lib/python2.7/site-packages/lago/log_utils.py", line 599, in wrapper
func(_args, **kwargs)
File "/usr/lib/python2.7/site-packages/lago/cmd.py", line 119, in do_init
shutil.rmtree(prefix)
File "/usr/lib64/python2.7/shutil.py", line 228, in rmtree
if os.path.islink(path):
File "/usr/lib64/python2.7/posixpath.py", line 135, in islink
st = os.lstat(path)
TypeError: coercing to Unicode: need string or buffer, Prefix found

Was being worked here https://gerrit.ovirt.org/#/c/45434/

Instead it usually fails with KeyError for 'gw' key as Prefix._allocate_subnets() fails silently

Started work here: https://gerrit.ovirt.org/#/c/49337/

Moved from https://bugzilla.redhat.com/show_bug.cgi?id=1277656

Right now there's no way to configure lago system options like repo caches, template caches and such, adding a way to specify a conf file where to override any of those hardcoded values will add a lot of ease on adapting it to unexpected systems

Moved from https://bugzilla.redhat.com/show_bug.cgi?id=1272045

Description of problem:
Initializing workspace fails

Steps to Reproduce:
1.

lagocli init /
$PWD/testd-eployment /
/usr/share/ovirtlago/config/virt/centos7.json /
--template-repo-path=$PWD/lago-template-repositories/office.json

Actual results:

2015-10-15 13:43:49,651 - root - DEBUG - Running command: qemu-img create -f qcow2 -b /home/tlitovsk/workspace/ci/lago_var/store/in_office_repo:centos7_host:v5 /home/tlitovsk/workspace/ci/lago_run/test-deployment/images/host0_root.qcow2
2015-10-15 13:43:49,651 - root - DEBUG - Running command: ['qemu-img', 'create', '-f', 'qcow2', '-b', u'/home/tlitovsk/workspace/ci/lago_var/store/in_office_repo:centos7_host:v5', u'/home/tlitovsk/workspace/ci/lago_run/test-deployment/images/host0_root.qcow2']
2015-10-15 13:43:49,750 - root - DEBUG - command exit with 0
2015-10-15 13:43:49,751 - root - DEBUG - command stdout: Formatting '/home/tlitovsk/workspace/ci/lago_run/test-deployment/images/host0_root.qcow2', fmt=qcow2 size=53687091200 backing_file='/home/tlitovsk/workspace/ci/lago_var/store/in_office_repo:centos7_host:v5' encryption=off cluster_size=65536 lazy_refcounts=off refcount_bits=16

2015-10-15 13:43:49,751 - root - INFO - Successfully created disk at /home/tlitovsk/workspace/ci/lago_run/test-deployment/images/host0_root.qcow2
2015-10-15 13:43:49,753 - root - ERROR - Error occured, aborting
Traceback (most recent call last):
  File "/usr/bin/lagocli", line 531, in main
    func(args)
  File "/usr/bin/lagocli", line 78, in do_init
    prefix.virt_conf(virt_conf, repo, store)
  File "/usr/lib/python2.7/site-packages/lago/__init__.py", line 348, in virt_conf
    self._config_net_topology(conf)
  File "/usr/lib/python2.7/site-packages/lago/__init__.py", line 220, in _config_net_topology
    self._allocate_ips_to_nics(conf)
  File "/usr/lib/python2.7/site-packages/lago/__init__.py", line 202, in _allocate_ips_to_nics
    net['gw'],
KeyError: 'gw'

Expected results:
success

Additional info:
version : lago-0.2-153_g948690d.fc22.noarch.rpm

Yaniv Bronhaim 2015-10-22 06:50:30 EDT

we don't always have gw declared in the specific net value. here you use :

"nets": {
    "lago": {
        "type": "nat",
        "dhcp": {
            "start": 100,
            "end": 254
        },
        "management": true
    }
}

which does not state the gateway - so we should use default value in lago/__init__.py line 202
its part of commit lago@59411f1

            vacant = _create_ip(                                            
                net['gw'],                                                  
                set(range(2, 255)).difference(                              
                    set(                                                    
                        [                                                   
                            int(ip.split('.')[-1]) for ip in allocated      
                        ]                                                   
                    )                                                       
                ).pop()                                                     
            )   

Moved from https://bugzilla.redhat.com/show_bug.cgi?id=1283344

If we could use snapshots or similar and allow dependencies between templates, the disk space required on the client (and alas, the amount of data to download) would drop a lot, for example having a base centos-7 template, and a host and engine template that depend on it, but are just a snapshot on top of it, so they only occupy the extra space of the installation and configuration instead of duplicating it completely.

Started work here https://gerrit.ovirt.org/45500

Moved from https://bugzilla.redhat.com/show_bug.cgi?id=1285986

Description of problem:
while installing lago on FC23 I have:

Installazione in corso: python-lago-ovirt-0.4-0.4.fc23.noarch 3/4
FirewallD is not running
FirewallD is not running
FirewallD is not running
avvertimento: scriptlet %post(python-lago-ovirt-0.4-0.4.fc23.noarch) fallita, uscita con stato 252
Non-fatal POSTIN scriptlet failure in rpm package python-lago-ovirt
Non-fatal POSTIN scriptlet failure in rpm package python-lago-ovirt

Rpms shouldn't mess with the firewall in %post. Especially it shouldn't open ports without user consent.

I see in %post:
if [ "$1" -eq 1 ]; then
firewall-cmd --reload
firewall-cmd --permanent --zone=public --add-service=lago
firewall-cmd --reload
fi

Adding lago to services in firewalld is a security issue and should be dropped.
It's admin task to open it if needed.

See https://fedoraproject.org/wiki/PackagingDrafts/ScriptletSnippets/Firewalld
about firewalld reload.

version: lago-0.4

Started work here: https://gerrit.ovirt.org/#/c/45500/

Moved from https://bugzilla.redhat.com/show_bug.cgi?id=1285988

installing lago 0.4 try to mess with firewalld even if firewalld is not used as firewall manager on the system.

lago rpms shouldn't assume that firewalld is the system firewall manager.

Moved from https://bugzilla.redhat.com/show_bug.cgi?id=1279962

Description of problem:
For example, from a dir or similar, using repoman probably to fetch them and compose the repo that will be passed onto the vms
Barak Korren 2015-11-11 05:43:26 EST

How will the CLI/API UX for this look like? How does it compare to current CLI/API?

David Caro 2015-11-11 05:52:18 EST

Still to be define, but as a first step, adding an option to reposetup to specify any repoman source is a must imo:
lago reposetup --extra-source dir:path/to/my/custom/rpms

David Caro 2015-11-11 05:53:44 EST

I'd also remove the vdsm/engine/ioprocess specific options and associated code, and if needed, do that in another cli verb (like build or similar), but that's another issue

Eyal Edri 2015-11-26 08:30:09 EST

does this bug includes consuming rpms from a workflow or previous job that will generate rpms per patch/commit?

David Caro 2015-11-26 09:13:34 EST

Not so specifically, but will allow to use any rpms on disk or remotely, what opens the possibility to reuse whatever build-artifacts builds (allowing that flow) but also any other flow that get's you some rpms

Description of problem:
Currently the code @ ovirtlago/testlib.py is:
143 def assert_true_within(func, timeout):
144 with utils.EggTimer(timeout) as timer:
145 while not timer.elapsed():
146 try:
147 if func():
148 return
149 except Exception:
150 pass
151 raise AssertionError('Timed out')

Specifically, there is a tight loop there, which consumes CPU needlessly - occupying both the client and the target of func() (for example, checking something on the engine).

Simple patch:

23 import time
...

144 def assert_true_within(func, timeout):
145 with utils.EggTimer(timeout) as timer:
146 while not timer.elapsed():
147 try:
148 if func():
149 return
150 time.sleep(1)
151 except Exception:
152 pass
153 raise AssertionError('Timed out')

solves this, by adding a 1 sec. sleep between retries (practically, can even extend to 3 or 5 seconds).

Version-Release number of selected component (if applicable):
0.5
Collapse All Comments

Migrated from: https://bugzilla.redhat.com/show_bug.cgi?id=1294653

So when you change the template in the remote, it will not pull in the changes until you cleanup the cache

Description of problem:
I tried to setup lago a few days ago and I think the docs need improvement, here were the parts that I think should be changed:

1. Ordering to avoid reboots. Currently several reboots are needed to get a working system this can be reduced:
   • Changing config to enable nested.
   • Changing SELinux to be permissive.
   • Enabling libvirt by default.
   • Users permissions changes.

Then reboot:

• Changing BIOS if needed.
• Check libvirt enabled.
• Check SELinux permissive.

This ensures that lago remains working after reboot.

1. You do not suggest a default user name to use for lago and list it in the examples. I chose user name lago, which was not a good idea which many users will do.
2. There is no way to know the default prefixes and how to change them.
   """
   Make sure that the qemu user has execution rights to the dir where you will be creating the prefixes, you can try it out with:

$ sudo -u qemu ls /path/to/the/destination/dir
"""
There is no way for me to know what path to check and what prefixes are used. Please make this more explicit.

Migrated from: https://bugzilla.redhat.com/show_bug.cgi?id=1294464

Find out how to alleviate the issue until libvirt addresses the problem on their side

Moved from https://bugzilla.redhat.com/show_bug.cgi?id=1287260

Description of problem:

Sometimes the ci jobs fail to run the functional tests when doing the prefix startup, and they fail with:

19:15:08 not ok 8 basic.full_run: start everything at once
19:15:08 # (from function `helpers.equals' in file tests/functional/helpers.bash, line 49,
19:15:08 #  in test file tests/functional/basic.bats, line 126)
19:15:08 #   `helpers.equals "$status" '0'' failed
19:15:08 # RUNNING:lagocli start
19:15:08 # WARNING: current session does not belong to lago group.
19:15:08 # 2015-12-01 19:14:13,413 - root - INFO - Creating network lago_functional_tests
19:15:08 # 2015-12-01 19:14:17,934 - root - INFO - Starting VM lago_functional_tests_vm01
19:15:08 # libvirt: QEMU Driver error : monitor socket did not show up: No such file or directory
19:15:08 # 2015-12-01 19:15:04,689 - root - INFO - Destroying network lago_functional_tests
19:15:08 # 2015-12-01 19:15:08,351 - root - ERROR - Error occured, aborting
19:15:08 # Traceback (most recent call last):
19:15:08 #   File "/usr/bin/lagocli", line 528, in main
19:15:08 #     func(args)
19:15:08 #   File "/usr/bin/lagocli", line 85, in wrapper
19:15:08 #     return func(lago.Prefix(os.getcwd()), args)
19:15:08 #   File "/usr/bin/lagocli", line 93, in wrapper
19:15:08 #     return func(prefix, args)
19:15:08 #   File "/usr/bin/lagocli", line 106, in do_start
19:15:08 #     prefix.start()
19:15:08 #   File "/usr/lib/python2.7/site-packages/lago/__init__.py", line 594, in start
19:15:08 #     self.virt_env.start()
19:15:08 #   File "/usr/lib/python2.7/site-packages/lago/virt.py", line 138, in start
19:15:08 #     vm.start()
19:15:08 #   File "/usr/lib/python2.7/site-packages/lago/virt.py", line 756, in start
19:15:08 #     self._env.libvirt_con.createXML(self._libvirt_xml())
19:15:08 #   File "/usr/lib64/python2.7/site-packages/libvirt.py", line 3611, in createXML
19:15:08 #     if ret is None:raise libvirtError('virDomainCreateXML() failed', conn=self)
19:15:08 # libvirtError: monitor socket did not show up: No such file or directory
19:15:08 # 1 == 0

David Caro 2016-01-26 04:37:55 EST

This seems to be an issue in libvirt, that is not able to create the per-user socket fast enough (or the client does not wait enough time for it to appear), see https://bugzilla.redhat.com/show_bug.cgi?id=1301391

Moved from https://bugzilla.redhat.com/show_bug.cgi?id=1285358

Description of problem:
Lago uses sudo by placing a file called 'lago' in '/etc/sudoers.d'
That file allows users that belong to the 'lago' group to invoke various commands with root permissions without entering a password.

A file placed in '/etc/sudoers.d' which is lexicographically bigger then 'lago' can override the Lago sudo settings, effectively making lago fail or stop and ask the user for a sudo password.

This happens for example on RHEL7 CSB where the file 'redhat-internal-user-sudo' is placed in '/etc/sudoers.d' to grand the user full root access with a password.

Steps to Reproduce:

1. Install Lago
2. place the file '/etc/sudoers.d/rago' with the following content:

%lago    ALL=(ALL)   ALL

Actual results:
Lago stops and tries to ask for a sudo password (occasionally it is impossible to enter because Lago blocks TTY access for the commands it runs internally)

Expected results:
Laog should just run

Additional info:
As a temporary work-around the 'lago' file was copied to 'z_lago'.
Long-term Lago should not rely on 'sudo' and instead have its own privileged helper accessed via PolicyKit.

Yaniv Kaul 2015-12-21 05:01:01 EST

Barak, this is what I have now:
[root@ykaul ~]# cd /etc/sudoers.d/
[root@ykaul sudoers.d]# ls
lago
[root@ykaul sudoers.d]# cat lago
%lago ALL = (qemu) NOPASSWD: /usr/bin/chmod
%lago ALL = NOPASSWD: /usr/sbin/brctl addbr *
%lago ALL = NOPASSWD: /usr/sbin/brctl delbr *
%lago ALL = NOPASSWD: /usr/sbin/brctl show *
%lago ALL = NOPASSWD: /usr/sbin/brctl stp *
%lago ALL = NOPASSWD: /usr/sbin/ip link set dev *
%lago ALL = NOPASSWD: /usr/sbin/ip link set dev *

I we need, we can add more commands, but I'm not thrilled by ALL...

Barak Korren 2015-12-21 05:25:37 EST

Yaniv,

This 'ALL' is located in the the host pattern part of the rule not the command pattern...

Or are you talking about what I specified to put in the 'rago' file to reproduce the bug? You don't need that....

If Lago is prompting you for 'sudo' password, it means the rules you see in '/etc/sudoers.d/lago' are actually overridden and are not applied to your system. You can apply the work-around specified above (copy the file to a lexicographically bigger name like '/etc/sudoers.d/z_lago') .

Description of problem:
There is nowhere to go to get a simple answer to the question "What is Lago" and more importantly "What can it do for me"

Expected results:
There should be a one-paragraph answer featured prominently at the beginning of the README file and on the top of every page we thing people will come top to lean about Lago.

Description of problem:
In order for lago tests development to start being developed by various teams,
we need to provide a clear and easy README on how to write test for lago.

we'll need to take the 1st dev team in baby steps and make them familiar with the system and how to write and run tests, so they can continue on their own to do it and close the gaps on tests.

migrated from: https://bugzilla.redhat.com/show_bug.cgi?id=1283517

It does not have any arguments, probably messed up during the cli renaming

Description of problem:
Lago installation README needs to include a minimum and recomended hardware specs for running lago on.

Something like:
Minimum: 12GB Ram, 2 CPU?
Recomended: 32GB, 4 CPU...

Description of problem:
Right now you have to know beforehand when using a disk template which partition will be used as root partition, but that info is better place with the disk image metadata in the repo.

Moved from https://bugzilla.redhat.com/show_bug.cgi?id=1283982

Description of problem:
today when you run lago for the first time, it downloads a very big template files, sometimes a few GB of data.

Its not uncommon to get a network error in the middle or the download will stop for various reasons.

Today, if a download of a template is stopped in the middle, lago can't resume where it stopped, and re-download it again.

If possible, it will be great if lago would support resume for downloads of templates via torrent or any other mechanism for resuming downloads.

Moved from https://bugzilla.redhat.com/show_bug.cgi?id=1285729

Seems like I'm suffering from https://bugzilla.redhat.com/show_bug.cgi?id=1149904 :

In basic_suite_3.6/engine-answer-file.conf , the value
OSETUP_RPMDISTRO/enableUpgrade=none:None
Should be:
OSETUP_RPMDISTRO/enableUpgrade=bool:False

I'm not sure how it did not bother me before today!

Not sure this goes here, maybe will move to lago-poject/lago-images

Moved from https://bugzilla.redhat.com/show_bug.cgi?id=1273026
Description of problem:
The hosts templates are fc20 based
this version is no longer supported by ovirt

Was being worked on here: https://gerrit.ovirt.org/#/c/46162/

Moved from: https://bugzilla.redhat.com/show_bug.cgi?id=1279962

Description of problem:
For example, from a dir or similar, using repoman probably to fetch them and compose the repo that will be passed onto the vms

Barak Korren 2015-11-11 05:43:26 EST

How will the CLI/API UX for this look like? How does it compare to current CLI/API?

David Caro 2015-11-11 05:52:18 EST

Still to be defined, but as a first step, adding an option to reposetup to specify any repoman source is a must imo:

lago reposetup --extra-source dir:path/to/my/custom/rpms

David Caro 2015-11-11 05:53:44 EST

I'd also remove the vdsm/engine/ioprocess specific options and associated code, and if needed, do that in another cli verb (like build or similar), but that's another issue

Eyal Edri 2015-11-26 08:30:09 EST

does this bug includes consuming rpms from a workflow or previous job that will generate rpms per patch/commit?

David Caro 2015-11-26 09:13:34 EST

Not so specifically, but will allow to use any rpms on disk or remotely, what opens the possibility to reuse whatever build-artifacts builds (allowing that flow) but also any other flow that get's you some rpms

That's because the vm does not have a serial pty connected

That command only works right now from the ovirt plugin, and only for vdsm/engine defined hosts. It would be useful also for other host types.

Description of problem:
There's no value in running the hosts, the storage with 4 vCPUs. Especially on my low end hosts, it may cause CPU contention.

Version-Release number of selected component (if applicable):
0.5

Additional info:
Change /usr/lib/ptrhon2.7/site-packages/lago/virt.py :
682 '@vcpu@': self._spec.get('vcpu', 4),
683 '@cpu@': self._spec.get('cpu', 4),

to:
682 '@vcpu@': self._spec.get('vcpu', 2),
683 '@cpu@': self._spec.get('cpu', 2),

Should fix that.

Migrated from: https://bugzilla.redhat.com/show_bug.cgi?id=1294624

Moved from https://bugzilla.redhat.com/show_bug.cgi?id=1272034

Those two dirs tend to be very large in size and files may collide between projects
Not everybody has free 20GB on their / dir
They should reside in the working directory.