This is a multi-part message in MIME format...
------------=_1512641905-10461-119
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
[
https://ovirt-jira.atlassian.net/browse/OVIRT-1788?page=com.atlassian.jir...
]
Barak Korren commented on OVIRT-1788:
-------------------------------------
[~gshereme(a)redhat.com] I don't know enough about how to use Selenium to iterate on
this on my own, so I'll try to guide you through what I think is needed to be done. If
you want more hand-on help from me, you'll need to teach me a little about Selenium
and perhaps give me a small example app I can iterate with...
Here are the things that need to be done
# Enable the OST suit to use docker - this is done by:
## Adding '{{docker}}' to the '{{*.packages}}' file of the suit
## Adding '{{docker}}' to the '{{*.packages}}' file of
'{{check-patch}}' (So code changes to the suit can be tested).
## Add the following to the relevant '{{*.mounts}}' files
{code}/var/run/docker.sock:/var/run/docker.sock{code}
# Start up the Selenium containers from inside the suit and make them able to talk to
oVirt. The readme of the GitHub repo gives examples of '{{docker}}' commands doing
that, but those use the deprecated '{{--link}}' option. I've looked at what
the containers actually do, and is seems that the browser containers simply expect the
'{{HUB_PORT_4444_TCP_ADDR}}' and '{{HUB_PORT_4444_TCP_PORT}}' environment
variables to be defined for them and pointing to the hub container.
A more modern approach to setting this up would be:
## Setup a Docker network to connect the containers together
## Setup the hostnames for the oVirt VMs in the Docker network
## Start up a hub container and expose port 4444 so test suits can connect to it.
## Start up the browser containers and configure the env vars for then so they can find
the hub container
The above could be done with a bunch of Docker commands, but a better approach would be
to use an automation tool such as '{{docker-compose}}'. But given that Ansible is
closer to home for us, and likely to be used by other oVirt components, I think
'{{ansible-containers}}' would be a better choice here.
new ui_sanity scenario for basic_suite -- need multiple firefoxes and
chromium
------------------------------------------------------------------------------
Key: OVIRT-1788
URL:
https://ovirt-jira.atlassian.net/browse/OVIRT-1788
Project: oVirt - virtualization made easy
Issue Type: Improvement
Components: OST
Reporter: Greg Sheremeta
Assignee: infra
I'm writing a suite that does headless UI testing. One goal is to open headless
firefox and actually open the UI, perform a login, make sure things look good, make sure
there are no ui.log errors, etc. I'll also eventually add chromium, which can run
headless now too.
The suite requires several firefox versions to be installed on the test machine, along
with chromium. There are also some binary components required, geckodriver and
chromedriver. These are not packaged.
Ideally the browsers can be installed to /opt/firefox55, /opt/firefox56, /opt/chromium62,
etc. on the machine running the suite. So I think it makes sense to maintain a custom rpm
with all of this.
Where can this rpm live? What is a reliable way to do this? (I know we want to avoid
copr.)
--
This message was sent by Atlassian Jira
(v1001.0.0-SNAPSHOT#100074)
------------=_1512641905-10461-119
Content-Type: text/html; charset="UTF-8"
Content-Disposition: inline
Content-Transfer-Encoding: 7bit
<html><body>
<pre>[
https://ovirt-jira.atlassian.net/browse/OVIRT-1788?page=com.atlassian.jir...
]</pre>
<h3>Barak Korren commented on OVIRT-1788:</h3>
<p>[~gshereme(a)redhat.com] I don't know enough about how to use Selenium to
iterate on this on my own, so I'll try to guide you through what I think is needed to
be done. If you want more hand-on help from me, you'll need to teach me a little about
Selenium and perhaps give me a small example app I can iterate with…</p>
<p>Here are the things that need to be done # Enable the OST suit to use docker
– this is done by: ## Adding ‘{{docker}}’ to the
‘{{*.packages}}’ file of the suit ## Adding
‘{{docker}}’ to the ‘{{*.packages}}’ file of
‘{{check-patch}}’ (So code changes to the suit can be tested). ## Add
the following to the relevant ‘{{*.mounts}}’ files</p>
<pre>{code}/var/run/docker.sock:/var/run/docker.sock{code}</pre>
<p># Start up the Selenium containers from inside the suit and make them able to
talk to oVirt. The readme of the GitHub repo gives examples of
‘{{docker}}’ commands doing that, but those use the deprecated
‘{{--link}}’ option. I've looked at what the containers actually
do, and is seems that the browser containers simply expect the
‘{{HUB_PORT_4444_TCP_ADDR}}’ and
‘{{HUB_PORT_4444_TCP_PORT}}’ environment variables to be defined for
them and pointing to the hub container. A more modern approach to setting this up would
be: ## Setup a Docker network to connect the containers together ## Setup the hostnames
for the oVirt VMs in the Docker network ## Start up a hub container and expose port 4444
so test suits can connect to it. ## Start up the browser containers and configure the env
vars for then so they can find the hub container</p>
<pre>The above could be done with a bunch of Docker commands, but a better approach
would be to use an automation tool such as '{{docker-compose}}'. But given that
Ansible is closer to home for us, and likely to be used by other oVirt components, I think
'{{ansible-containers}}' would be a better choice here.</pre>
<blockquote><h3>new ui_sanity scenario for basic_suite — need
multiple firefoxes and chromium</h3>
<pre> Key: OVIRT-1788
URL:
https://ovirt-jira.atlassian.net/browse/OVIRT-1788
Project: oVirt - virtualization made easy
Issue Type: Improvement
Components: OST
Reporter: Greg Sheremeta
Assignee: infra</pre>
<p>I'm writing a suite that does headless UI testing. One goal is to open
headless firefox and actually open the UI, perform a login, make sure things look good,
make sure there are no ui.log errors, etc. I'll also eventually add chromium, which
can run headless now too. The suite requires several firefox versions to be installed on
the test machine, along with chromium. There are also some binary components required,
geckodriver and chromedriver. These are not packaged. Ideally the browsers can be
installed to /opt/firefox55, /opt/firefox56, /opt/chromium62, etc. on the machine running
the suite. So I think it makes sense to maintain a custom rpm with all of this. Where can
this rpm live? What is a reliable way to do this? (I know we want to avoid
copr.)</p></blockquote>
<p>— This message was sent by Atlassian Jira
(v1001.0.0-SNAPSHOT#100074)</p>
<img
src="https://u4043402.ct.sendgrid.net/wf/open?upn=i5TMWGV99amJbNxJpS...
alt="" width="1" height="1" border="0"
style="height:1px !important;width:1px !important;border-width:0
!important;margin-top:0 !important;margin-bottom:0 !important;margin-right:0
!important;margin-left:0 !important;padding-top:0 !important;padding-bottom:0
!important;padding-right:0 !important;padding-left:0 !important;"/>
</body></html>
------------=_1512641905-10461-119--