[JIRA] (OST-39) Run OST against vdsm+Engine on kubernetes
by Yaniv Kaul (oVirt JIRA)
[ https://ovirt-jira.atlassian.net/browse/OST-39?page=com.atlassian.jira.pl... ]
Yaniv Kaul commented on OST-39:
-------------------------------
0. I think it's time to understand if we want to use Lago for Kubevirt or not. I prefer vagrant - it's more common, works out of the box on both Ubuntu and possibly other operating systems (does it have nested virt on Mac or Windows?). I would like to believe that moving to vagrant is actually a good opportunity to start afresh. Lago is not killed by it, and will remain relevant for OST.
1. Ansible is supported today in vagrant. I believe a fair start of support exists in Lago as well - but as Barak pointed out, probably need a bit of Cloud-Init work too perhaps - not sure.
Engine is not containerized for real yet. Once it does, we'll probably deploy it via standard Pod deployment options (saw today ansible-containers, for example - sounds neat).
> Run OST against vdsm+Engine on kubernetes
> -----------------------------------------
>
> Key: OST-39
> URL: https://ovirt-jira.atlassian.net/browse/OST-39
> Project: oVirt system tests
> Issue Type: New Feature
> Reporter: Fabian Deutsch
> Assignee: infra
> Priority: Highest
> Labels: kubevirt
>
> Hey,
> Yaniv Bronheim is building containers for vdsm and engine.
> Lago should become capable of running OST against this setup.
> The basic flow is:
> 1. Normal CentOS
> 2. Install kubernetes
> 3. Deploy engine and vdsm pods
> The pod definitions are here:
> https://gerrit.ovirt.org/gitweb?p=ovirt-container-engine.git;a=tree
> https://gerrit.ovirt.org/gitweb?p=ovirt-container-node.git;a=tree
> A similar script can be found here:
> https://github.com/kubevirt/demo/blob/master/data/bootstrap-kubevirt.sh
> But this script is deploying kubevirt, instead of the engine + vdsm container.
--
This message was sent by Atlassian JIRA
(v1000.718.3#100026)
7 years, 10 months
[JIRA] (OST-39) Run OST against vdsm+Engine on kubernetes
by eyal edri [Administrator] (oVirt JIRA)
[ https://ovirt-jira.atlassian.net/browse/OST-39?page=com.atlassian.jira.pl... ]
eyal edri [Administrator] commented on OST-39:
----------------------------------------------
This is the tool we're using for tracking issues for OST, so its the right place, if needed we can have a trello card pointing to this ticket.
0. Lago. I don't think that the fact Vagrant was used for POC KubeVirt alone is a major advantage to re-do all the work we've done to make OST run with Lago,
Moving to Vagrant will mean investing a lot of efforts and resources ( which we don't have, looking at the Lago+OST headcount ATM ) into making something we already have working for little value IMO and will delay significantly the work to support KubeVirt.
We can consider it once we'll have a full time maintainer for Lago/OST.
1. Once we support Ansible as deploy scripts in OST, which shouldn't be hard after the recent merges to Lago, we can just use the existing Kubenetes playbooks, not sure how using Vagrant makes it simpler.
Ansible for engine - not sure how/what we'll need, but [~fdeutsch] provided us with POD definitions, I'm guessing once you have Kubenetes its just a matter of running / deploying the engine container? ( so according to the request we should have available engine & vdsm in containers, otherwise I didn't understand the request )
> Run OST against vdsm+Engine on kubernetes
> -----------------------------------------
>
> Key: OST-39
> URL: https://ovirt-jira.atlassian.net/browse/OST-39
> Project: oVirt system tests
> Issue Type: New Feature
> Reporter: Fabian Deutsch
> Assignee: infra
> Priority: Highest
> Labels: kubevirt
>
> Hey,
> Yaniv Bronheim is building containers for vdsm and engine.
> Lago should become capable of running OST against this setup.
> The basic flow is:
> 1. Normal CentOS
> 2. Install kubernetes
> 3. Deploy engine and vdsm pods
> The pod definitions are here:
> https://gerrit.ovirt.org/gitweb?p=ovirt-container-engine.git;a=tree
> https://gerrit.ovirt.org/gitweb?p=ovirt-container-node.git;a=tree
> A similar script can be found here:
> https://github.com/kubevirt/demo/blob/master/data/bootstrap-kubevirt.sh
> But this script is deploying kubevirt, instead of the engine + vdsm container.
--
This message was sent by Atlassian JIRA
(v1000.718.3#100026)
7 years, 10 months
[JIRA] (OST-39) Run OST against vdsm+Engine on kubernetes
by eyal edri [Administrator] (oVirt JIRA)
[ https://ovirt-jira.atlassian.net/browse/OST-39?page=com.atlassian.jira.pl... ]
eyal edri [Administrator] commented on OST-39:
----------------------------------------------
[~fdeutsch] Just to emphasis the scope and requirements, let me re-iterate on what we agreed on the email:
A new OST suite will be created which will run the same tests run today in basic suite, the difference will be:
1. Replace deploy scripts for engine + storage with Ansible playbook which will install Kubernetes
2. The Ansible playbook will also need to deploy engine + vdsm as containers in PODS once Kubernetes will be running
3. Not sure how 'add host' should work - will VDSM come ready in a container and already connect to the engine or we'll still need to run 'add host' command to add it? or an alternative 'add host' command.
4. Kubernetes will be running on VMs created by Lago
5. We will consider to use Atomic as OS for the VMs, but CentOS should work as well as starting point.
Please confirm I'm not talking nonsense and we can continue to move towards this goal :)
> Run OST against vdsm+Engine on kubernetes
> -----------------------------------------
>
> Key: OST-39
> URL: https://ovirt-jira.atlassian.net/browse/OST-39
> Project: oVirt system tests
> Issue Type: New Feature
> Reporter: Fabian Deutsch
> Assignee: infra
> Priority: Highest
> Labels: kubevirt
>
> Hey,
> Yaniv Bronheim is building containers for vdsm and engine.
> Lago should become capable of running OST against this setup.
> The basic flow is:
> 1. Normal CentOS
> 2. Install kubernetes
> 3. Deploy engine and vdsm pods
> The pod definitions are here:
> https://gerrit.ovirt.org/gitweb?p=ovirt-container-engine.git;a=tree
> https://gerrit.ovirt.org/gitweb?p=ovirt-container-node.git;a=tree
> A similar script can be found here:
> https://github.com/kubevirt/demo/blob/master/data/bootstrap-kubevirt.sh
> But this script is deploying kubevirt, instead of the engine + vdsm container.
--
This message was sent by Atlassian JIRA
(v1000.718.3#100026)
7 years, 10 months
[JIRA] (OVIRT-753) ovirt-appliance_master_build-artifacts-el7-x86_64 is ignoring failed commands
by eyal edri [Administrator] (oVirt JIRA)
[ https://ovirt-jira.atlassian.net/browse/OVIRT-753?page=com.atlassian.jira... ]
eyal edri [Administrator] updated OVIRT-753:
--------------------------------------------
Resolution: Incomplete
Status: Done (was: Blocked)
no reply since Nov, please re-open if still relevant.
> ovirt-appliance_master_build-artifacts-el7-x86_64 is ignoring failed commands
> -----------------------------------------------------------------------------
>
> Key: OVIRT-753
> URL: https://ovirt-jira.atlassian.net/browse/OVIRT-753
> Project: oVirt - virtualization made easy
> Issue Type: By-EMAIL
> Reporter: sbonazzo
> Assignee: infra
>
> In:
> http://jenkins.ovirt.org/job/ovirt-appliance_master_build-artifacts-el7-x...
> After appliance shutdown:
> *00:15:44.383* [[ -n "1" ]] && [[ "$(virt-sparsify --help)" =~
> --in-place ]] && ( virt-sparsify --in-place
> ovirt-engine-appliance.qcow2 ; ln ovirt-engine-appliance.qcow2
> ovirt-engine-appliance.qcow2.sparse ; )*00:25:53.734* virt-sparsify:
> error: libguestfs error: guestfs_launch failed.*00:25:53.735* This
> usually means the libguestfs appliance failed to start or
> crashed.*00:25:53.735* See
> http://libguestfs.org/guestfs-faq.1.html#debugging-libguestfs*00:25:53.735*
> or run 'libguestfs-test-tool' and post the *complete* output into
> a*00:25:53.735* bug report or message to the libguestfs mailing list.
> The job should have failed here. Instead, the job continues and fails in a
> later stage:
> *00:33:01.284* ls -shal ovirt-engine-appliance.ova*00:33:01.287* 1.4G
> -rwxr-xr-x. 1 root root 1.4G Oct 6 14:13
> ovirt-engine-appliance.ova*00:33:01.288* echo "all" appliance
> done*00:33:01.290* all appliance done*00:33:01.291* + make
> check*00:33:01.299* make -f image-tools/build.mk
> ovirt-engine-appliance-manifest-rpm*00:33:01.305* make[1]: Entering
> directory `/home/jenkins/workspace/ovirt-appliance_master_build-artifacts-el7-x86_64/ovirt-appliance/engine-appliance'*00:33:01.305*
> guestfish --ro -i -a ovirt-engine-appliance.qcow2 sh 'rpm -qa | sort
> -u' > ovirt-engine-appliance-manifest-rpm*00:41:58.044* libguestfs:
> error: appliance closed the connection unexpectedly.*00:41:58.044*
> This usually means the libguestfs appliance crashed.*00:41:58.044* See
> http://libguestfs.org/guestfs-faq.1.html#debugging-libguestfs*00:41:58.045*
> for information about how to debug libguestfs and report
> bugs.*00:41:58.045* libguestfs: error: guestfs_launch
> failed.*00:41:58.045* This usually means the libguestfs appliance
> failed to start or crashed.*00:41:58.045* See
> http://libguestfs.org/guestfs-faq.1.html#debugging-libguestfs*00:41:58.046*
> or run 'libguestfs-test-tool' and post the *complete* output into
> a*00:41:58.046* bug report or message to the libguestfs mailing
> list.*00:41:58.059* make[1]: *** [ovirt-engine-appliance-manifest-rpm]
> Error 1*00:41:58.059* make[1]: Leaving directory
> `/home/jenkins/workspace/ovirt-appliance_master_build-artifacts-el7-x86_64/ovirt-appliance/engine-appliance'*00:41:58.060*
> make: *** [ovirt-engine-appliance-manifest-rpm] Error 2*00:41:58.065*
> Took 2325 seconds
> wasting 20 minutes of jenkins slave time testing something already known
> broken.
> While working on fixing this job, please investigate while it's failing and
> open a separate issue or bugzilla for it.
> --
> Sandro Bonazzola
> Better technology. Faster innovation. Powered by community collaboration.
> See how it works at redhat.com
> <https://www.redhat.com/it/about/events/red-hat-open-source-day-2016>
--
This message was sent by Atlassian JIRA
(v1000.718.3#100026)
7 years, 10 months