<div dir="ltr">Hi,<div>Perhaps it's better to look at neutron-tempest-plugin:</div><div><ul><li>Your case is more a networking issue as I see.</li><li>neutron-tempest-plugin has the option to use other image than cirros with config option <font face="monospace">advanced_image_ref </font><font face="arial, sans-serif">and in neutron gate that is mostly some ubuntu (ubunt16.04 as I see in latest logs)</font></li></ul><div><font face="arial, sans-serif">example:</font></div></div><div><a href="https://storage.gra.cloud.ovh.net/v1/AUTH_dcaab5e32b234d56b626f72581e3644c/zuul_opendev_logs_bf5/713719/3/check/neutron-tempest-plugin-scenario-openvswitch/bf5f249/controller/logs/tempest_conf.txt">https://storage.gra.cloud.ovh.net/v1/AUTH_dcaab5e32b234d56b626f72581e3644c/zuul_opendev_logs_bf5/713719/3/check/neutron-tempest-plugin-scenario-openvswitch/bf5f249/controller/logs/tempest_conf.txt</a><font face="arial, sans-serif"><br></font></div><div><br></div><div>Lajos</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Roman Safronov <<a href="mailto:rsafrono@redhat.com">rsafrono@redhat.com</a>> ezt írta (időpont: 2020. márc. 23., H, 18:55):<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>Actually we need such test because we are testing Openstack as a whole product (including Neutron+openvswitch+OVN+Nova+libvirt+Octavia etc.) that's why I think neutron functional test would be not enough. We are creating tests covering scenarios that our customers tried to use and encountered issues. <br></div><div>For example this is a bug reported downstream on an issue happened in this scenario: <a href="https://bugzilla.redhat.com/show_bug.cgi?id=1707241" target="_blank">https://bugzilla.redhat.com/show_bug.cgi?id=1707241</a><br></div><div></div><div>There were more reported issues on similar use case and we would like to catch such issues before the product is released.</div><div><br></div><div>Anyway, as I said this specific test runs stable in downstream CI on virtual multi node environments with nested virtualization. It usually runs with RHEL8 image but I also tried it with standard Ubuntu-18.04 guest image used by upstream CI gates. The only issue is that keepalive package installation by 'apt install' for some reason does not work when running on upstream gates causing the test to be skipped. I just would like to understand if running 'apt install/yum install' inside VMs spawned by upstream tempest tests is not acceptable at all or I am missing something (maybe proxy settings?).</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Mar 23, 2020 at 5:36 PM Clark Boylan <<a href="mailto:cboylan@sapwetik.org" target="_blank">cboylan@sapwetik.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Sun, Mar 22, 2020, at 9:10 AM, Roman Safronov wrote:<br>
> Hi,<br>
> <br>
> I wrote a tempest test <br>
> <<a href="https://review.opendev.org/#/c/710975/https://review.opendev.org/%23/c/710975/" rel="noreferrer" target="_blank">https://review.opendev.org/#/c/710975/https://review.opendev.org/#/c/710975/</a>)> which requires keepalived to be running inside vm instance.<br>
> The test tries to install keepalived package inside vm by running "apt <br>
> install/yum install".<br>
> However as I see in upstream gates logs this does not work while the <br>
> same code works perfectly in our downstream CI using the same image.<br>
> <br>
> Do vm instances spawned on upstream gates during tests have a route to <br>
> the internet?<br>
> Is there an alternative way that I can use in order to install a <br>
> package?<br>
<br>
By default the tempest jobs use a cirros image. This is a very small, quick to boot linux without a package manager. If you need services to be running in the image typically you'll need to boot a more typical linux installation. Keep in mind that nested virt isn't on by default as it isn't available everywhere and has been flaky in the past. This makes these types of installations very small which may make reliable VRRP testing difficult.<br>
<br>
Thinking out loud here, I'm not sure how much benefit there is to testing VRRP failures in this manner. Do we think that OpenStack sitting on top of libvirt and OVS will somehow produce different results with VRRP than using those tools as is? To put this another way: are we testing OpenStack or are we testing OVS and libvirt?<br>
<br>
One option here may be to construct this as a Neutron functional test and run VRRP on Neutron networks without virtualization mixed in.<br>
<br>
> <br>
> Thanks in advance<br>
> <br>
> -- <br>
> ROMAN SAFRONOV<br>
<br>
</blockquote></div><br clear="all"><div><br></div><br><div dir="ltr"><div dir="ltr"></div></div></div>
</blockquote></div>