Open Stack

Right, it was ubuntu-16.04 rather than ubuntu-18.04 as I said before by
mistake.
As Clark said it might be a NAT issue on devstack nodes.


On Tue, Mar 24, 2020 at 7:32 AM Lajos Katona <katonalala at gmail.com> wrote:

> Hi,
> Perhaps it's better to look at neutron-tempest-plugin:
>
>    - Your case is more a networking issue as I see.
>    - neutron-tempest-plugin has the option to use other image than cirros
>    with config option advanced_image_ref and in neutron gate that is
>    mostly some ubuntu (ubunt16.04 as I see in latest logs)
>
> example:
>
> 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
>
> Lajos
>
> Roman Safronov <rsafrono at redhat.com> ezt írta (időpont: 2020. márc. 23.,
> H, 18:55):
>
>> 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.
>> For example this is a bug reported downstream on an issue happened in
>> this scenario: https://bugzilla.redhat.com/show_bug.cgi?id=1707241
>> There were more reported issues on similar use case and we would like to
>> catch such issues before the product is released.
>>
>> 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?).
>>
>> On Mon, Mar 23, 2020 at 5:36 PM Clark Boylan <cboylan at sapwetik.org>
>> wrote:
>>
>>> On Sun, Mar 22, 2020, at 9:10 AM, Roman Safronov wrote:
>>> > Hi,
>>> >
>>> > I wrote a tempest test
>>> > <
>>> https://review.opendev.org/#/c/710975/https://review.opendev.org/#/c/710975/)>
>>> which requires keepalived to be running inside vm instance.
>>> > The test tries to install keepalived package inside vm by running "apt
>>> > install/yum install".
>>> > However as I see in upstream gates logs this does not work while the
>>> > same code works perfectly in our downstream CI using the same image.
>>> >
>>> > Do vm instances spawned on upstream gates during tests have a route to
>>> > the internet?
>>> > Is there an alternative way that I can use in order to install a
>>> > package?
>>>
>>> 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.
>>>
>>> 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?
>>>
>>> One option here may be to construct this as a Neutron functional test
>>> and run VRRP on Neutron networks without virtualization mixed in.
>>>
>>> >
>>> > Thanks in advance
>>> >
>>> > --
>>> > ROMAN SAFRONOV
>>>
>>>
>>
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20200324/598d9d61/attachment-0001.html>