Activity log for bug #1527018

Date Who What changed Old value New value Message
2015-12-17 01:52:45 ZongKai LI bug added bug
2015-12-17 11:05:07 OpenStack Infra grenade: status New In Progress
2015-12-17 11:05:07 OpenStack Infra grenade: assignee ZongKai LI (lzklibj)
2015-12-18 07:18:26 ZongKai LI description A recent grenade test output for l3.filters in log: http://logs.openstack.org/55/246855/14/check/gate-grenade-dsvm-neutron/5bc1026/logs/etc/neutron/rootwrap.d/l3.filters.txt.gz new CommandFilter is added in neutron patch: https://review.openstack.org/#/c/246855/14/etc/neutron/rootwrap.d/l3.filters as a compared, tempest update it, but grenade doesn't: http://logs.openstack.org/55/246855/14/check/gate-tempest-dsvm-neutron-dvr/d982908/logs/etc/neutron/rootwrap.d/l3.filters.txt.gz A recent grenade test output for l3.filters in log: http://logs.openstack.org/55/246855/14/check/gate-grenade-dsvm-neutron/5bc1026/logs/etc/neutron/rootwrap.d/l3.filters.txt.gz new CommandFilter is added in neutron patch: https://review.openstack.org/#/c/246855/14/etc/neutron/rootwrap.d/l3.filters as a compared, tempest update it, but grenade doesn't: http://logs.openstack.org/55/246855/14/check/gate-tempest-dsvm-neutron-dvr/d982908/logs/etc/neutron/rootwrap.d/l3.filters.txt.gz ### update ### Based on recent mail-list discuss, we consider that as a common part of neutron code, filters under rootwrap.d shouldn't be considered as common configures. It make sense to make neutron rootwrap.d filters always be upgraded/updated when grenade test runs. Date: Thu, 17 Dec 2015 10:46:47 -0700 From: Carl Baldwin <carl@ecbaldwin.net> To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev@lists.openstack.org> Subject: Re: [openstack-dev] [neutron][grenade] l3.filters fail to update at test server Message-ID: <CALiLy7pzAvPQLv_A+KiRDWPaNsARO098tQVwinWZvjWR+gPT8g@mail.gmail.com> Content-Type: text/plain; charset=UTF-8 On Thu, Dec 17, 2015 at 5:12 AM, Ihar Hrachyshka <ihrachys@redhat.com> wrote: > I believe that we should always unconditionally update filters with new > versions when doing upgrades. Filters should not actually be considered > configuration files in the first place since they are tightly coupled with > the code that triggers commands. +1. I was actually very surprised to learn how this is handled and had the same thought. Carl
2015-12-18 07:26:03 ZongKai LI summary l3.filters is not updated when neutron code changes neutron rootwarp is not updated when neutron code changes
2021-03-29 19:59:22 Martin Kopec grenade: status In Progress Incomplete