lago-project / lago Goto Github PK
View Code? Open in Web Editor NEWAd-hoc virtual testing environment framework
Home Page: http://lago.readthedocs.org
License: GNU General Public License v2.0
Ad-hoc virtual testing environment framework
Home Page: http://lago.readthedocs.org
License: GNU General Public License v2.0
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
It was being worked on https://gerrit.ovirt.org/#/c/45437/
Instead it usually fails with KeyError for 'gw' key as Prefix._allocate_subnets() fails silently
Work started at https://gerrit.ovirt.org/#/c/45890
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
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!
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.
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
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:
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
#29 provides simple means of reporting progess of the download of the large templates.
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
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.
It does not have any arguments, probably messed up during the cli renaming
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=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.
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.
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
Started work here: https://gerrit.ovirt.org/#/c/45500/
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)
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:
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
Started work here: https://gerrit.ovirt.org/#/c/49337/
Started work here https://gerrit.ovirt.org/45500
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=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@59411f1vacant = _create_ip( net['gw'], set(range(2, 255)).difference( set( [ int(ip.split('.')[-1]) for ip in allocated ] ) ).pop() )
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=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.
Just use "" as the domain name, it will create the prefix and fail on doing anything else, it should at least warn
As they would be useful out of ovirt too, was being worked on here: https://gerrit.ovirt.org/#/c/45433/
That is needed when using virt-builder generated templates as the root partition is /dev/sda3 and it's name is not 'root'.
So when you change the template in the remote, it will not pull in the changes until you cleanup the cache
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.
Was being worked here https://gerrit.ovirt.org/#/c/45434/
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
That's because the vm does not have a serial pty connected
Was being worked on here: https://gerrit.ovirt.org/#/c/46162/
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.
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:
%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') .
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:
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:
Then reboot:
This ensures that lago remains working after reboot.
$ 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
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.
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
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=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
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...
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
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.