Re: [openstack-dev] [infra] Problem with Jenkins

[Inessa Vasilevskaya]

Hi,
I believe the scenario was as follows: firstly
TestNodeAttributes.test_hugepages_distribution failed with

2017-01-25 08:11:20.155868 | E   ProgrammingError:
(psycopg2.ProgrammingError) relation "node_cluster_plugins" does not exist

and all other tests failed because of InternalError due to aborted
transaction caused by first failure.

It explains why all following tests failed but not the other successful run
though.

On Wed, Jan 25, 2017 at 10:06 AM, Anastasiya Balobashina <
atolochk...@mirantis.com> wrote:

> Hello!
>
> I have 2 similar patches with different change_id. On the first case
> Jenkins has failed: https://review.openstack.org/#/c/422481/ , on the
> second case Jenkins has successfully passed:https://review.
> openstack.org/#/c/424553/ . I can not understand the reason for it.
> Besides all test that failed in the first case was run in the same thread.
> Can anybody help me?
>
> --
> Best regards,
> Balobashina Anastasia
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Best regards,
Inessa Vasilevskaya
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Neutron] Broken port rule masking: let's have it fixed?

[Inessa Vasilevskaya]

Hello,

Apologies for multiple posts, forgot to set proper subject in previous one.

I'd like to turn attention to the broken port rule masking problem [1],
which affects 2 projects so far:
neutron (mitaka+ with ovs firewall driver configuration) and
networking-ovs-dpdk [2].

To keep it short: the existing port masking implementation is broken and in
several cases it will either leave a range of ports open (causing
unrestricted access) or make some ports inaccessible (when they should be
open) because of bad tp_src value being generated.

2 solutions have been proposed so far:
* The "low-level one" with O(log n) complexity by IWAMOTO Toshihiro and me
[2]
* The "high-level one" with O(n^2) complexity by Jakub Libosvar [3]

As long as the bug looks like a security vulnerability and is kind of
critical for ovs firewall feature, maybe we should choose one algorithm to
go on with and have this fixed in Newton?

[1] https://bugs.launchpad.net/neutron/+bug/1611991
[2] https://review.openstack.org/#/c/353782/30
[3] https://review.openstack.org/#/c/353782/16

Best regards,
Inessa Vasilevskaya
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Neutron]

[Inessa Vasilevskaya]

Hello,

I'd like to turn attention to the broken port rule masking problem [1],
which affects 2 projects so far:
neutron (mitaka+ with ovs firewall driver configuration) and
networking-ovs-dpdk [2].

To keep it short: the existing port masking implementation is broken and in
several cases it will either leave a range of ports open (causing
unrestricted access) or make some ports inaccessible (when they should be
open) because of bad tp_src value being generated.

2 solutions have been proposed so far:
* The "low-level one" with O(log n) complexity by IWAMOTO Toshihiro and me
[2]
* The "high-level one" with O(n^2) complexity by Jakub Libosvar [3]

As long as the bug looks like a security vulnerability and is kind of
critical for ovs firewall feature, maybe we should choose one algorithm to
go on with and have this fixed in Newton?

[1] https://bugs.launchpad.net/neutron/+bug/1611991
[2] https://review.openstack.org/#/c/353782/30
[3] https://review.openstack.org/#/c/353782/16

Best regards,
Inessa Vasilevskaya
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron] OVSDB native interface as default in gate jobs

[Inessa Vasilevskaya]

Yes, of_interface has 'native' option as well.
I have plans to dig into the matter further by looking at native ovsdb
interface state (a naive change of config didn't pass some functional
tests, need investigation [1]) and running some performance tests in
different configurations of of_interface and ovsdb_interface options
(dsvm-fullstack [2] and rally tests are by now all I can think of).
And yes, I have plans to document my findings once I'll become more
acquainted with the subject.

[1] https://review.openstack.org/#/c/299655/
[2] https://review.openstack.org/#/c/299380/

Inessa

On Thu, Mar 31, 2016 at 9:47 PM, Clark Boylan  wrote:

> On Tue, Mar 29, 2016, at 07:34 PM, Kevin Benton wrote:
> > I'm not aware of any issues. Perhaps you can propose a patch to just
> > change
> > the default in Neutron to that interface and people can -1 if there are
> > any
> > concerns.
>
> Yes, please do. This is one of the nice things about pre merge testing,
> we can all see how it works upfront before committing to it.
>
> As far as concerns go I got curious about this and did some digging
> around documentation and found basically zero docs. It is possible I
> don't know where to look, but I would expect that we should be
> documenting the behavior of the various interface options? However, this
> is a small concern and can be addressed if/when the changes are made to
> Neutron.
>
> In my digging I did find that there is also an of_interface that
> defaults to ovs-ofctl, does this also have a native interface that could
> be used?
>
> Clark
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [neutron] OVSDB native interface as default in gate jobs

[Inessa Vasilevskaya]

Hi all,

I spent some time researching the current state of native ovsdb interface
feature, which has been fully implemented and merged since Liberty [1][2].
I was pretty much impressed by the expected performance improvement (as per
spec [1], some interesting research on ovs-vsctl + rootwrap also done here
[3]). Preliminary test results also showed that native interface does quite
well.

So my question is - why don’t we make native interface the default option
for voting gate jobs? Are there any caveats or security issues that I am
unaware of?

Regards,

Inessa

[1]
https://specs.openstack.org/openstack/neutron-specs/specs/kilo/vsctl-to-ovsdb.html

[2] https://blueprints.launchpad.net/neutron/+spec/vsctl-to-ovsd

[3]
http://blog.otherwiseguy.com/replacing-ovs-vsctl-calls-with-native-ovsdb-in-neutron/
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [TEMPEST] doubts regarding tempest

[Inessa Vasilevskaya]

Hi,
I can't boast digging a lot into tempest, but at least I can give you some
info on question 1.
You can run a single test or a series of tests stopping at import pdb;
pdb.set_trace() if use use testr:

testr list-tests test_name_regex  my-list
python -m testtools.run discover --load-list my-list

Mind that you need to activate your venv first. More info can be found
here: https://wiki.openstack.org/wiki/Testr

By the way, I personally recommend ipdb - has the same power, but is a lot
more user friendly :)

Hope it helps,

Inessa Vasilevskaya

On Sun, Jan 18, 2015 at 11:50 AM, Abhishek Talwar/HYD/TCS 
abhishek.tal...@tcs.com wrote:

 Hi,

 I have some doubts regarding tempest.

 Q1. How can we debug test cases in OpenStack ? (We can debug the code
 through import pdb but the same doesn't work for test cases and we have a
 bdb quit error)

 Q2. Suppose I need to add a test case in the tempest suite how can I do
 that ?

 Q3. Whenever we run run_tests.sh script where does it first hit and how
 does the tests cases start running ?

 Q4. As it is said that tempest interacts only with the OpenStack Rest
 Api's , then how are the test cases for the various clients run, by clients
 here I mean the python-novaclient,keystoneclient etc.


 --
 Thanks and Regards
 Abhishek Talwar
 Employee ID : 770072
 Assistant System Engineer
 Tata Consultancy Services,Gurgaon
 India
 Contact Details : +918377882003

 =-=-=
 Notice: The information contained in this e-mail
 message and/or attachments to it may contain
 confidential or privileged information. If you are
 not the intended recipient, any dissemination, use,
 review, distribution, printing or copying of the
 information contained in this e-mail message
 and/or attachments to it are strictly prohibited. If
 you have received this communication in error,
 please notify us by reply e-mail or telephone and
 immediately and permanently delete the message
 and any attachments. Thank you


 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev