[openstack-dev] [Neutron] Stepping down from Neutron core team

[Jakub Libosvar]

Hi all,

as you have might already heard, I'm no longer involved in Neutron
development due to some changes. Therefore I'm officially stepping down
from the core team because I can't provide same quality reviews as I
tried to do before.

I'd like to thank you all for the opportunity I was given in the Neutron
team, thank you for all I have learned over the years professionally,
technically and personally. Tomorrow it's gonna be exactly 5 years since
I started hacking Neutron and I must say I really enjoyed working with
all Neutrinos here and I had privilege to meet most of you in person and
that has an extreme value for me. Keep on being a great community!

Thank you again!
Kuba

__
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] Appointing Slawek Kaplonski to the Neutron Drivers team

[Jakub Libosvar]

Congrats Slawek! I'm sure you'll rock as a driver too!

Kuba

On 27/08/2018 18:42, Miguel Lavalle wrote:
> Dear Neutron team,
> 
> In order to help the Neutron Drivers team to perform its very important job
> of guiding the community to evolve the OpenStack Networking architecture to
> meet the needs of our current and future users [1], I have asked Slawek
> Kaplonski to join it. Over the past few years, he has gained very valuable
> experience with OpenStack Networking, both as a deployer  and more recently
> working with one of our key packagers. He played a paramount role in
> implementing our QoS (Quality of Service) features, currently leading that
> sub-team. He also leads the CI sub-team, making sure the prompt discovery
> and fixing of bugs in our software. On top of that, he is one of our most
> active reviewers, contributor of code to our reference implementation and
> fixer of bugs. I am very confident in Slawek making great contributions to
> the Neutron Drivers team.
> 
> Best regards
> 
> Miguel
> 
> [1]
> https://docs.openstack.org/neutron/latest/contributor/policies/neutron-teams.html#drivers-team
> 
> 
> 
> __
> 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

Re: [openstack-dev] [FFE][requirements] Bump ansible-runner u-c to 1.0.5

[Jakub Libosvar]

On 31/07/2018 18:46, Matthew Thode wrote:
> On 18-07-31 17:30:02, Jakub Libosvar wrote:
>> Hi all,
>>
>> I want to ask for FFE at this time to bump upper-constraint version of
>> ansible-runner library from 1.0.4 to 1.0.5.
>>
>> Reason: ansible-runner 1.0.4 has an issue when running with currently
>> used eventlet version because of missing select.poll() in eventlet [1].
>> The fix [2] is present in 1.0.5 ansible-runner version.
>>
>> Impact: networking-ansible project uses Neutron project and
>> ansible-runner together and Neutron monkey patches code with eventlet.
>> This fails all operations at networking-ansible.
>>
>> Statement: networking-ansible is the only project using ansible-runner
>> in OpenStack world [3] so if we release Rocky with 1.0.4, the only
>> project using it becomes useless. Bumping the version at this later
>> stage will not affect any other project beside networking-ansible.
>>
>> [1] https://github.com/ansible/ansible-runner/issues/90
>> [2]
>> https://github.com/ansible/ansible-runner/commit/5608e786eb96408658604e75ef3db3c9a6b39308
>> [3] http://codesearch.openstack.org/?q=ansible-runner=nope==
> 
> Looks good, you may want to update the minimum in networking-ansible,
> but lgtm otherwise.
> 
> | networking-ansible | requirements.txt|5 | ansible-runner>=1.0.3 
> # Apache-2.0 |

Yep, thanks for reminder. I've done that here
https://review.openstack.org/#/c/587475/ where the workaround was removed.

Jakub
> 
> 
> 
> __
> 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] [FFE][requirements] Bump ansible-runner u-c to 1.0.5

[Jakub Libosvar]

Hi all,

I want to ask for FFE at this time to bump upper-constraint version of
ansible-runner library from 1.0.4 to 1.0.5.

Reason: ansible-runner 1.0.4 has an issue when running with currently
used eventlet version because of missing select.poll() in eventlet [1].
The fix [2] is present in 1.0.5 ansible-runner version.

Impact: networking-ansible project uses Neutron project and
ansible-runner together and Neutron monkey patches code with eventlet.
This fails all operations at networking-ansible.

Statement: networking-ansible is the only project using ansible-runner
in OpenStack world [3] so if we release Rocky with 1.0.4, the only
project using it becomes useless. Bumping the version at this later
stage will not affect any other project beside networking-ansible.

Thanks for consideration.

Jakub


[1] https://github.com/ansible/ansible-runner/issues/90
[2]
https://github.com/ansible/ansible-runner/commit/5608e786eb96408658604e75ef3db3c9a6b39308
[3] http://codesearch.openstack.org/?q=ansible-runner=nope==

__
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] Gate-failure bugs spring cleaning

[Jakub Libosvar]

On 21/04/2018 14:16, Slawomir Kaplonski wrote:
> Hi Neutrinos,
> 
> There is time for some spring cleaning now so I went through list of Neutron 
> bugs with „gate-failure” tag https://tinyurl.com/y826rccx 
> I mark some of them as incomplete if there was not hits of same errors in 
> last 30 days. Please reopen them with proper comment if You think that it is 
> still valid bug or if You will spot similar error in some recent test runs.
> 
> About some of them I’m not sure if are still valid so please check it and 
> maybe update comment or close it if it’s already fixed somehow :)
> 
> Below detailed summary of bugs which I checked:
> 
> I removed Neutron from affected projects:
> * https://bugs.launchpad.net/tempest/+bug/1660612 
> 
> I marked as incomplete:
> * https://bugs.launchpad.net/neutron/+bug/1687027
> * https://bugs.launchpad.net/neutron/+bug/1693931
> * https://bugs.launchpad.net/neutron/+bug/1676966
> 
> Bugs which needs check of owner:
> * https://bugs.launchpad.net/neutron/+bug/1711463 - @Miguel, is it still 
> valid? Can we close it?
> * https://bugs.launchpad.net/neutron/+bug/1717302 - @Brian, no action since 
> 2017-12-12, is it failing still?
> 
> Bug which IMO should be reported against Cinder instead of Neutron, can 
> someone check and confirm that:
> * https://bugs.launchpad.net/neutron/+bug/1726462 - Is it related to Neutron 
> really, IMO it look like error with Cinder and it happens also in other than 
> neutron jobs, like „devstack-platform-opensuse-tumbleweed” and 
> „nova-multiattach” for example
> 
> Still valid bugs probably:
> * https://bugs.launchpad.net/neutron/+bug/1693950 - not exactly same error 
> but same tests failures I found recently so I think it is still valid to check
> * https://bugs.launchpad.net/neutron/+bug/1756301 - @Miguel: Can You check 
> and confirm that this is still valid
> * https://bugs.launchpad.net/neutron/+bug/1569621 - should be fixed by 
> https://review.openstack.org/#/c/562220/ - @Jakub can You confirm that?

That is correct - it's tracked as a fix for
https://bugs.launchpad.net/neutron/+bug/1708731
> 
> — 
> Best regards
> Slawek Kaplonski
> skapl...@redhat.com
> 
> 
> __
> 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

Re: [openstack-dev] [neutron][stable] New release for Pike is overdue

[Jakub Libosvar]

Thanks for notice. I sent a patch to request a new release:
https://review.openstack.org/#/c/553447/

Jakub

On 15/03/2018 11:28, Jens Harbott wrote:
> The last neutron release for Pike has been made in November, a lot of
> bug fixes have made it into the stable/pike branch, can we please get
> a fresh release for it soon?
> 
> __
> 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] Bug deputy report

[Jakub Libosvar]

Hi all,

I was a bug deputy for the last week and I won't be attending today team
meeting, so here comes my report:

It was very calm, there were no critical bugs reported, some bugs were
already fixed and other got attention and have patches up for review.
Some bugs were also triaged and some closed as they were duplicates.

The only one left is https://bugs.launchpad.net/neutron/+bug/1746707
where I'm not sure whether that's valid for reference implementation. It
says there are inconsistency issues in NSX Neutron plugin and hence
there *might* be issues in other plugins too.

AFAIK ml2 has BEFORE_ and AFTER_ callbacks in combination with retry
mechanisms performed over database. But I'm not brave to judge whether
this is sufficient to be considered safe. Hence I marked the bug as
incomplete but I think it deserves some discussion at the meeting.

Thanks,
Kuba

__
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] Stepping down from core

[Jakub Libosvar]

I'm sad reading this. Thanks for everything you did for the community
and best of luck in your new adventures.

Jakub

On 15/12/2017 20:01, Armando M. wrote:
> Hi neutrinos,
> 
> To some of you this email may not come as a surprise.
> 
> During the past few months my upstream community engagements have been more
> and more sporadic. While I tried hard to stay committed and fulfill my core
> responsibilities I feel like I failed to retain the level of quality and
> consistency that I would have liked ever since I stepped down from being
> the Neutron PTL back at the end of Ocata.
> 
> I stated many times when talking to other core developers that being core
> is a duty rather than a privilege, and I personally feel like it's way
> overdue for me to recognize on the mailing list that it's the time that I
> state officially my intention to step down due to other commitments.
> 
> This does not mean that I will disappear tomorrow. I'll continue to be on
> neutron IRC channels, support the neutron team, being the release liasion
> for Queens, participate at meetings, and be open to providing feedback to
> anyone who thinks my opinion is still valuable, especially when dealing
> with the neutron quirks for which I might be (git) blamed :)
> 
> Cheers,
> Armando
> 
> 
> 
> __
> 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

Re: [openstack-dev] [Neutron][ovn] networking-ovn core team update

[Jakub Libosvar]

Congratulations! Very well deserved! :)

On 01/12/2017 17:45, Lucas Alvares Gomes wrote:
> Hi all,
> 
> I would like to welcome Daniel Alvarez to the networking-ovn core team!
> 
> Daniel has been contributing with the project for a good time already
> and helping *a lot* with reviews and code.
> 
> Welcome onboard man!
> 
> Cheers,
> Lucas
> 
> __
> 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

Re: [openstack-dev] [Neutron] Propose Slawek Kaplonski for Neutron core

[Jakub Libosvar]

Big +1 for Slawek :)

On 30/11/2017 00:49, Armando M. wrote:
> On 29 November 2017 at 12:27, Korzeniewski, Artur <
> artur.korzeniew...@intel.com> wrote:
> 
>> +1 from me , (even though my vote does not count)
>>
>> I know Slawek since Tokyo summit and I’m impressed of his knowledge and
>> hands-on experience to improve Neutron quality and functionality!
>>
>> It is great to see him joining the core reviewers team!
>>
>> Congrats Sławek!
>>
> 
> Rock On
> 
> 
>>
>>
>> *From:* Miguel Angel Ajo Pelayo [mailto:majop...@redhat.com]
>> *Sent:* Wednesday, November 29, 2017 8:47 PM
>> *To:* OpenStack Development Mailing List (not for usage questions) <
>> openstack-dev@lists.openstack.org>
>> *Subject:* Re: [openstack-dev] [Neutron] Propose Slawek Kaplonski for
>> Neutron core
>>
>>
>>
>> "+1" I know, I'm not active, but I care about neutron, and slaweq is a
>> great contributor.
>>
>>
>>
>> On Nov 29, 2017 8:37 PM, "Ihar Hrachyshka"  wrote:
>>
>> YES, FINALLY.
>>
>> On Wed, Nov 29, 2017 at 11:29 AM, Kevin Benton  wrote:
>>> +1! ... even though I haven't been around. :)
>>>
>>> On Wed, Nov 29, 2017 at 1:21 PM, Miguel Lavalle 
>> wrote:

 Hi Neutron Team,

 I want to nominate Slawek Kaplonski (irc: slaweq) to Neutron core.
>> Slawek
 has been an active contributor to the project since the Mitaka cycle.
>> He has
 been instrumental in the development of the QoS capabilities in Neutron,
 becoming the lead of the sub-team focused on that set of features. More
 recently, he has collaborated in the implementation of OVO and is an
>> active
 participant in the CI sub-team. His number of code reviews during the
>> Queens
 cycle is on par with the leading core members of the team:
 http://stackalytics.com/?module=neutron

 In my opinion, his efforts are highly valuable to the team and we will
>> be
 very lucky to have him as a fully voting core.

 I will keep this nomination open for a week as customary,

 Thank you,

 Miguel

 
>> __
 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 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 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] Next team meeting canceled

[Jakub Libosvar]

Hi all,

unless there is a person who wants to chair our next Tuesday meeting,
I'd like to cancel it due to OpenStack Summit.

If there is a person who wants to run it, please speak up :)

Thanks,
Jakub

__
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] Bug deputy report

[Jakub Libosvar]

Hi all,

I was the bug deputy for the last week and I won't be attending today
the upstream meeting so I'm sending out this report:

There was one critical issue but got attention:
https://bugs.launchpad.net/neutron/+bug/1722967

and just a few bugs that need attention from somebody with broader
knowledge of particular topics. Namely:

https://bugs.launchpad.net/neutron/+bug/1722367 - this one can be either
switched to docs bug or probably closes as it was the configuration issue.

https://bugs.launchpad.net/cloud-archive/+bug/1722946 - I asked for more
info there as it's not clear if the issue is in openvswitch or Neutron code.

https://bugs.launchpad.net/neutron/+bug/1723696 - would be good if Moshe
or somebody from SR-IOV team could have a look to prioritize this bug -
there is already a patch on review.

Cheers,
Jakub


__
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] Denver Team Dinner

[Jakub Libosvar]

+1

On 12/09/2017 21:44, Terry Wilson wrote:
> +1
> 
> On Tue, Sep 12, 2017 at 6:23 PM, Miguel Lavalle  wrote:
>> Dear Neutrinos,
>>
>> Our social event will take place on Thursday September 12th at 7:30pm. The
>> venue is going to be https://www.famousdaves.com/Denver-Stapleton. It is
>> located 0.4 miles from the Renaissance Hotel, which translates to an easy 9
>> minutes walk.
>>
>> I have a reservation for a group of 30 people under my name. Please respond
>> to this message with your attendance confirmation by Wednesday night, so I
>> can get a more accurate head count.
>>
>> Looking forward to see y'all Thursday night
>>
>> Best regards
>>
>> Miguel
>>
>> __
>> 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 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][infra] Functional job failure rate at 100%

[Jakub Libosvar]

On 28/08/2017 21:20, Jeremy Stanley wrote:
> On 2017-08-11 15:31:58 +0200 (+0200), Jakub Libosvar wrote:
> [...]
>> My best hope is they are gonna backport the fix to 4.4.0 and tag a
>> new kernel so we can start running the tests again.
> 
> Just to follow up on this thread, it looks like the Ubuntu kernel
> team have had the upstream fix patched into xenial-proposed for a
> couple weeks already, awaiting confirmation from someone with the
> ability to reproduce the issue. Please see
> https://launchpad.net/bugs/1709032 if you can help close it out.

Thanks Jeremy for reminder. I replied on the LP bug that they can close
it. We enabled our functional job back a while ago and it works just fine.

PS. The new kernel also solved other issue we were facing, so we killed
two birds with one stone.

Jakub

__
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] [openstack-neutron] [neutron dvr tempest test problem]

[Jakub Libosvar]

On 24/08/2017 12:47, Ning Yao wrote:
> Hi, all
> 
> I encounter a problem about neutron tempest test. I run the tempest
> neutron plugin test against my self-build OpenStack, and I find that
> tempest will run the dvr test and report NotImplementedERROR. I dig
> into the test code and find that even if I do not enable dvr router
> for my OpenStack, the dvr test runs and does not automatically skip.
> This is because it only skip this logic when
> network-feature-enabled.api_extensions does not support dvr.
> ```
> 
> class DvrRoutersTest(base_routers.BaseRouterTest):
> 
> 
> @classmethod
> 
> @test.requires_ext(extension="dvr", service="network")
> 
> def skip_checks(cls):
> 
> super(DvrRoutersTest, cls).skip_checks()
> 
> ```
> 
> Is any other way to skip the test?
> 
> I can manually delete the 'dvr' in tempest.conf
> network-feature-enabled.api_extensions, but it is not convenient for
> integrating test. while the value
> network-feature-enabled.api_extensions is automatically detected from
> neutron ext-list.
> 
> while neutron ext-list is describing whether the current version
> supports dvr,  dvr can be still disabled in neutron.conf for a certain
> openstack environment. So I think we need a method to find out whether
> this feature is enabled for the current OpenStack cluster and skip
> this test depending on this. Am I right or I still miss something.
> 
> 
> Regards
> Ning Yao

Hi Ning,

during the Pike cycle, there was a patch [1] merged for this specific
problem ops were facing. If your build contains this change, you can set
enable_dvr option to False in /etc/neutron/neutron.conf and then your
ext-list won't be propagating dvr.

I hope that helps.

Jakub

[1] https://review.openstack.org/#/c/454203/
> 
> __
> 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

Re: [openstack-dev] [neutron][infra] Functional job failure rate at 100%

[Jakub Libosvar]

On 10/08/2017 21:16, Jeremy Stanley wrote:
> On 2017-08-10 17:13:58 + (+), Mooney, Sean K wrote:
> [...]
>> so on that it would bre quite trivial to have disk image builder
>> install The linux-image-virtual-hwe-16.04
>> linux-image-virtual-hwe-16.04-edge to pull in a 4.10 or 4.11
>> kernel respctivly if the default 4.4 is broken. We just need a new
>> dib element to install the package And modify the  nodepool config
>> to include it when it rebuildes the image every night.
>> Alternitivly You can pull a vanilla kernel form
>> http://kernel.ubuntu.com/~kernel-ppa/mainline/ Follow the process
>> documented here https://wiki.ubuntu.com/Kernel/MainlineBuilds If
>> you want to maintain testing with 4.4.x
> [...]
> 
> Sure, your definition of "quite trivial" just differs a lot from
> mine. Given that the bug in question seems to have no further impact
> to the pace of development with the discussed test temporarily
> disabled, that strikes me as a lot more maintainable in the long run
> for a problem which started getting urgent attention from the distro
> as soon as it was reported to them and will likely be resolved over
> the course of the next few days at which point we'll automatically
> update to the fixed version and you can try reenabling that test
> again.

Yeah, I totally agree with Jeremy. Ubuntu folks are very active :)
Thanks for that. My best hope is they are gonna backport the fix to
4.4.0 and tag a new kernel so we can start running the tests again.


__
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][infra] Functional job failure rate at 100%

[Jakub Libosvar]

On 09/08/2017 18:23, Jeremy Stanley wrote:
> On 2017-08-09 15:29:04 +0200 (+0200), Jakub Libosvar wrote:
> [...]
>> Is it possible to switch used image for jenkins machines to use
>> back the older version? Any other ideas how to deal with the
>> kernel bug?
> 
> Making our images use non-current kernel packages isn't trivial, but
> as Thierry points out in his reply this is not just a problem for
> our CI system. Basically Ubuntu has broken OpenStack (and probably a
> variety of other uses of conntrack) for a lot of people following
> kernel updates in 16.04 LTS so the fix needs to happen there
> regardless. Right now, basically, Ubuntu Xenial is not a good
> platform to be running OpenStack on until they get the kernel
> regression addressed.

True. Fortunately, the impact is not that catastrophic for Neutron as it
might seem on the first look. Not sure about the other projects, though.
Neutron doesn't create conntrack entries in production code - only in
testing. That said, agents should work just fine even with the kernel bug.

> 
> 
> 
> __
> 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

Re: [openstack-dev] [neutron][infra] Functional job failure rate at 100%

[Jakub Libosvar]

Daniel Alvarez and I spent some time looking at it and the culprit was
finally found.

tl;dr

We updated a kernel on machines to one containing bug when creating
conntrack entries which makes functional tests stuck. More info at [4].

For now, I sent a patch [5] to disable for now jobs that create
conntrack entries manually, it needs update of commit message. Once it
merges, we an enable back functional job to voting to avoid regressions.

Is it possible to switch used image for jenkins machines to use back the
older version? Any other ideas how to deal with the kernel bug?

Thanks
Jakub

[5] https://review.openstack.org/#/c/492068/1

On 07/08/2017 11:52, Jakub Libosvar wrote:
> Hi all,
> 
> as per grafana [1] the functional job is broken. Looking at logstash [2]
> it started happening consistently since 2017-08-03 16:27. I didn't find
> any particular patch in Neutron that could cause it.
> 
> The culprit is that ovsdb starts misbehaving [3] and then we retry calls
> indefinitely. We still use 2.5.2 openvswitch as we had before. I opened
> a bug [4] and started investigation, I'll update my findings there.
> 
> I think at this point there is no reason to run "recheck" on your patches.
> 
> Thanks,
> Jakub
> 
> [1]
> http://grafana.openstack.org/dashboard/db/neutron-failure-rate?panelId=7
> [2] http://bit.ly/2vdKMwy
> [3]
> http://logs.openstack.org/14/488914/8/check/gate-neutron-dsvm-functional-ubuntu-xenial/75d7482/logs/openvswitch/ovsdb-server.txt.gz
> [4] https://bugs.launchpad.net/neutron/+bug/1709032
> 


__
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] Bug deputy report

[Jakub Libosvar]

Hi all,

I was bug deputy for the last week and as I'm not gonna attend meeting
today, I'm sending a report here:

There weren't that many urgent things reported last week. Here are some
bugs that needs more eyes:

 - https://bugs.launchpad.net/neutron/+bug/1708030 - failure in
functional tests, has a patch ready

 - https://bugs.launchpad.net/neutron/+bug/1708133 - has a patch for
review but will probably need somebody involved in quotas and policies

 - https://bugs.launchpad.net/neutron/+bug/1708463 - alembic migration
script failure


A failure from the weekend:

 - https://bugs.launchpad.net/neutron/+bug/1709032 - currently failing
in 100%, I was looking at it today but I still don't understand what
causes it.


Cheers,
Jakub

__
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] Functional job failure rate at 100%

[Jakub Libosvar]

Hi all,

as per grafana [1] the functional job is broken. Looking at logstash [2]
it started happening consistently since 2017-08-03 16:27. I didn't find
any particular patch in Neutron that could cause it.

The culprit is that ovsdb starts misbehaving [3] and then we retry calls
indefinitely. We still use 2.5.2 openvswitch as we had before. I opened
a bug [4] and started investigation, I'll update my findings there.

I think at this point there is no reason to run "recheck" on your patches.

Thanks,
Jakub

[1]
http://grafana.openstack.org/dashboard/db/neutron-failure-rate?panelId=7
[2] http://bit.ly/2vdKMwy
[3]
http://logs.openstack.org/14/488914/8/check/gate-neutron-dsvm-functional-ubuntu-xenial/75d7482/logs/openvswitch/ovsdb-server.txt.gz
[4] https://bugs.launchpad.net/neutron/+bug/1709032

__
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] Call for help with in-tree tempest scenario test failures

[Jakub Libosvar]

Hi all,

as sending out a call for help with our precious jobs was very
successful last time and we swept all Python 3 functional from Neutron
pretty fast (kudos the the team!), here comes a new round of failures.

This time I'm asking for your help  with gate-tempest-dsvm-neutron-dvr-multinode-scenario
non-voting job. This job has been part of check queue for a while and is
very very unstable. Such job covers scenarios like router dvr/ha/legacy
migrations, qos, trunk and dvr. I went through current failures and
created an etherpad [1] with categorized failures and logstash queries
that give you latest failures with given particular tests.

If you feel like doing troubleshooting and sending fixes for gates,
please pick one test and write down your name to the test.

Thanks to all who are willing to participate.

Have a great weekend.
Jakub


[1]
https://etherpad.openstack.org/p/neutron-dvr-multinode-scenario-gate-failures


__
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] Upstream meeting cancelled tomorrow

[Jakub Libosvar]

Hi folks,

I'm on personal leave tomorrow and there is also 4th July in the US, so
we're cancelling the meeting tomorrow.

Cheers,
Jakub


__
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] Journey to running functional job with Python 3

[Jakub Libosvar]

Hi folks,

we've been tracking the OpenStack common goal for Python 3 in our
Neutron CI meetings. As an outcome we created a list of categorized
failures in current non-voting job. There are 250 failures that we split
into 14 categories. The list can be found here:

https://etherpad.openstack.org/p/py3-neutron-pike

Consider this email as a call-for-action in case you'd like to
participate in this goal. If you decide to work on one failure category,
please write down your name to the etherpad above.

Thanks to all who will join this effort! :)

Jakub

__
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] Canceling next upstream meeting

[Jakub Libosvar]

Hi folks,

due to OpenStack Summit I'm canceling the next Tue May 9th upstream meeting.

Cheers,
Jakub

__
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] - Neutron team social in Atlanta on Thursday

[Jakub Libosvar]

+1

> On 17 Feb 2017, at 2:19 PM, Kevin Benton  wrote:
> 
> Hi all,
> 
> I'm organizing a Neutron social event for Thursday evening in Atlanta 
> somewhere near the venue for dinner/drinks. If you're interested, please 
> reply to this email with a "+1" so I can get a general count for a 
> reservation.
> 
> Cheers,
> Kevin Benton
> __
> 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] Towards better stability of gate jobs

[Jakub Libosvar]

Hi all,

we've been struggling with functional and fullstack jobs for a while
now and we'd like to bring a better stability to it as the failure rate
is still quite high. This is getting annoying, specifically for voting
functional job, which makes it sometimes harder to get some of our
beautiful precious patches merged.

The very basic pillar on the way to improve the jobs is to understand
what is wrong with them. Without having an overview of current failures
it's very hard to make any improvement.

Hence I'd like to ask you for help. When you see a failed job, don't
just 'recheck' with the best hope that your patch won't get hit by gate
failure again. Take a minute, please, open the failure and eventually
report a new bug.

Armando already sent similar email in the past [1], where he
encouraged to have a look at the failure and report a bug. I have also
sent a new policy to our docs with recommended steps [2]. Ideas on
improvement are very welcome!

It's really crucial to get a better grasp of our job failures and I
believe if we can make this a habit into our day to day work, it will
really make a difference at the job stability.

Thank you.
Jakub

[1] 
http://lists.openstack.org/pipermail/openstack-dev/2016-August/100801.html

[2] https://review.openstack.org/#/c/426829/

__
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] [infra][Neutron] Running out of memory on gate for linux bridge job

[Jakub Libosvar]

Hi,

recently I noticed we got oom-killer in action in one of our jobs [1]. I 
saw it several times, so far only with linux bridge job. The consequence 
is that usually mysqld gets killed as a processes that consumes most of 
the memory, sometimes even nova-api gets killed.


Does anybody know whether we can bump memory on nodes in the gate 
without losing resources for running other jobs?
Has anybody experience with memory consumption being higher when using 
linux bridge agents?


Any other ideas?

Thanks,
Jakub

[1] 
http://logs.openstack.org/73/373973/13/check/gate-tempest-dsvm-neutron-linuxbridge-ubuntu-xenial/295d92f/logs/syslog.txt.gz#_Jan_11_13_56_32


__
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] Stepping down from core

[Jakub Libosvar]

Sad to see you stepping down. Thanks for making Neutron better and good 
luck in your new adventures!


Jakub

On 17/11/2016 19:42, Carl Baldwin wrote:

Neutron (and Openstack),

It is with regret that I report that my work situation has changed such
that I'm not able to keep up with my duties as a Neutron core reviewer,
L3 lieutenant, and drivers team member. My participation has dropped off
considerably since Newton was released and I think it is fair to step
down and leave an opening for others to fill. There is no shortage of
talent in Neutron and Openstack and I know I'm leaving it in good hands.

I will be more than happy to come back to full participation in
Openstack and Neutron in the future if things change again in that
direction. This is a great community and I've had a great time
participating and learning with you all.

Well, I don't want to drag this out. I will still be around on IRC and
will be happy to help out where I am able. Feel free to ping me.

Carl


__
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

Re: [openstack-dev] [All] Finish test job transition to Ubuntu Xenial

[Jakub Libosvar]

On 18/11/2016 12:17, Jakub Libosvar wrote:

On 07/11/2016 23:04, Clark Boylan wrote:

On Mon, Nov 7, 2016, at 01:48 PM, Clark Boylan wrote:

How can you do this? First double check your job logs to see where your
tests are running. The first few lines of your job console logs should
say "[Zuul] Building remotely on ubuntu-xenial" if running on Xenial.
Any changes to master should not run on Trusty and instead should run on
Xenial.


Point of clarification here, stable/newton and master jobs should both
be transitioned to Xenial.


I noticed gate-grenade-dsvm-ubuntu-xenial job is run on stable Newton
branch for devstack. It basically means Mitaka devstack is used to
deploy on Xenial but Xenial is not among supported distros in Mitaka [1].

What is recommended way of upgrade for Ubuntu users running Mitaka on
Trusy? Is it: upgrade Ubuntu to Xenial first, then upgrade Mitaka to
Newton?

I see three ways how to solve this problem:
1) Implement support to devstack Mitaka.
2) Use FORCE value for grenade Newton (I sent experimental patch [2]).
3) Run Trusty only for upgrades Mitaka->Newton.

Any thoughts or comments?
I see it was resolved by 
https://bugs.launchpad.net/openstack-gate/+bug/1642543

Sorry for the noise.



Thanks,
Jakub

[1]
https://github.com/openstack-dev/devstack/blob/stable/mitaka/stack.sh#L188
[2] https://review.openstack.org/#/c/399526/



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 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] [All] Finish test job transition to Ubuntu Xenial

[Jakub Libosvar]

On 07/11/2016 23:04, Clark Boylan wrote:

On Mon, Nov 7, 2016, at 01:48 PM, Clark Boylan wrote:

How can you do this? First double check your job logs to see where your
tests are running. The first few lines of your job console logs should
say "[Zuul] Building remotely on ubuntu-xenial" if running on Xenial.
Any changes to master should not run on Trusty and instead should run on
Xenial.


Point of clarification here, stable/newton and master jobs should both
be transitioned to Xenial.


I noticed gate-grenade-dsvm-ubuntu-xenial job is run on stable Newton 
branch for devstack. It basically means Mitaka devstack is used to 
deploy on Xenial but Xenial is not among supported distros in Mitaka [1].


What is recommended way of upgrade for Ubuntu users running Mitaka on 
Trusy? Is it: upgrade Ubuntu to Xenial first, then upgrade Mitaka to Newton?


I see three ways how to solve this problem:
1) Implement support to devstack Mitaka.
2) Use FORCE value for grenade Newton (I sent experimental patch [2]).
3) Run Trusty only for upgrades Mitaka->Newton.

Any thoughts or comments?

Thanks,
Jakub

[1] 
https://github.com/openstack-dev/devstack/blob/stable/mitaka/stack.sh#L188

[2] https://review.openstack.org/#/c/399526/



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

Re: [openstack-dev] [Neutron] Neutron team social event in Barcelona

[Jakub Libosvar]

+1

On 14/10/2016 20:30, Miguel Lavalle wrote:

Dear Neutrinos,

I am organizing a social event for the team on Thursday 27th at 19:30.
After doing some Google research, I am proposing Raco de la Vila, which
is located in Poblenou: http://www.racodelavila.com/en/index.htm. The
menu is here: http://www.racodelavila.com/en/carta-racodelavila.htm

It is easy to get there by subway from the Summit venue:
https://goo.gl/maps/HjaTEcBbDUR2. I made a reservation for 25 people
under 'Neutron' or "Miguel Lavalle". Please confirm your attendance so
we can get a final count.

Here's some reviews:
https://www.tripadvisor.com/Restaurant_Review-g187497-d1682057-Reviews-Raco_De_La_Vila-Barcelona_Catalonia.html

Cheers

Miguel


__
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] ARP spoofing in VLAN aware VMs

[Jakub Libosvar]

Hi all,

I promised Armando a braindump of this issue so here it comes:
During my work on fullstack test for VLAN aware VMs I ran into issues 
with ARP spoofing. The issue was with subports having different MAC 
addresses than MAC address of the parent port. Packets leaving virtual 
instance via VLAN interfaces (e.g. eth0.1) have always source MAC 
address of VLAN parent interface (e.g. eth0).


This doesn't play nice when arp spoofing from OVS agent is used.

For example here parent port has MAC fa:16:3e:8d:4d:45 and VLAN 
interface has fa:16:3e:8d:5d:13. Trunk patch port is port 2 and subport 
patch port is 3. Tagged outgoing packet from VM will have source MAC set 
to fa:16:3e:8d:4d:45 but will come to integration bridge from port 3. 
And thus marked rule below won't get matched.


 cookie=0xa849678518c226b1, duration=545.317s, table=24, n_packets=2, 
n_bytes=92, idle_age=530, priority=2,arp,in_port=3,arp_spa=192.168.0.11 
actions=resubmit(,25)
 cookie=0xa849678518c226b1, duration=545.080s, table=24, n_packets=4, 
n_bytes=168, idle_age=531, priority=2,arp,in_port=2,arp_spa=10.0.0.3 
actions=resubmit(,25)
 cookie=0xa849678518c226b1, duration=554.554s, table=24, n_packets=5, 
n_bytes=230, idle_age=525, priority=0 actions=drop


 cookie=0xa849678518c226b1, duration=545.437s, table=25, n_packets=0, 
n_bytes=546, idle_age=530, priority=2,in_port=3,dl_src=fa:16:3e:8d:5d:13 
actions=NORMAL<--- This rule won't be matched.
 cookie=0xa849678518c226b1, duration=545.204s, table=25, n_packets=19, 
n_bytes=1430, idle_age=520, 
priority=2,in_port=2,dl_src=fa:16:3e:8d:4d:45 actions=NORMAL



The current fullstack test creates all ports attached to VM with the 
same MAC addresses and it works fine. But this doesn't work fine when 
OVS firewall is used as it contains a bug [1][2] where there can't be 
two same MAC addresses from different network used on a single hypervisor.



There was a second issue with port binding race but that turned up to be 
PEBKAC as update_port() was called before OVS port has been created.


Kuba

[1] https://bugs.launchpad.net/neutron/+bug/1626010
[2] https://bugs.launchpad.net/neutron/+bug/1593760

__
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][trunk] objects within transactions

[Jakub Libosvar]

On 05/09/16 16:45, Gary Kotton wrote:

Hi,

It is unclear what our policy is with objects. My understanding is that
an object should handle all of the database interaction. Is that not one
of the benefits of the objects? I posted
https://review.openstack.org/#/c/365459 and it has a number of
interesting comments – the main is that drivers are using the PRECOMIT
callbacks. Can someone please point out to where these are use. That
would at least provide some justification for this being blocked.

Thanks

Gary

As per comments on the change, they are used in ODL [1].

Kuba

[1] 
https://review.openstack.org/#/c/342459/3/networking_odl/trunk/driver_v2.py@53




__
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] Missing functional job in check queue

[Jakub Libosvar]

Hi all,

you might have noticed there was a time period where we run our gate 
without functional job. It was my goof that I appended ubuntu-trusty 
suffix to functional job [1] while the suffix by default make the job 
run on stable branches only. It should be fixed by now [2].


Sorry for caused inconveniences.

Jakub

[1] https://review.openstack.org/#/c/359843/
[2] https://review.openstack.org/#/c/363531/

__
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] Proposing Jakub Libosvar for testing core

[Jakub Libosvar]

On 26/07/16 16:56, Assaf Muller wrote:

We've hit critical mass from cores interesting in the testing area.

Welcome Jakub to the core reviewer team. May you enjoy staring at the
Gerrit interface and getting yelled at by people... It's a glamorous
life.


Thanks everyone for support! I'll try to do my best :)





On Mon, Jul 25, 2016 at 10:49 PM, Brian Haley <brian.ha...@hpe.com> wrote:

+1

On 07/22/2016 04:12 AM, Oleg Bondarev wrote:


+1

On Fri, Jul 22, 2016 at 2:36 AM, Doug Wiegley
<doug...@parksidesoftware.com
<mailto:doug...@parksidesoftware.com>> wrote:

+1


On Jul 21, 2016, at 5:13 PM, Kevin Benton <ke...@benton.pub
<mailto:ke...@benton.pub>> wrote:

+1

On Thu, Jul 21, 2016 at 2:41 PM, Carl Baldwin <c...@ecbaldwin.net
<mailto:c...@ecbaldwin.net>> wrote:

+1 from me

On Thu, Jul 21, 2016 at 1:35 PM, Assaf Muller <as...@redhat.com
<mailto:as...@redhat.com>> wrote:

As Neutron's so called testing lieutenant I would like to
propose
Jakub Libosvar to be a core in the testing area.

Jakub has demonstrated his inherent interest in the testing
area over
the last few years, his reviews are consistently insightful
and his
numbers [1] are in line with others and I know will improve
if given
the responsibilities of a core reviewer. Jakub is deeply
involved with
the project's testing infrastructures and CI systems.

As a reminder the expectation from cores is found here [2],
and
specifically for cores interesting in helping out shaping
Neutron's
testing story:

* Guide community members to craft a testing strategy for
features [3]
* Ensure Neutron's testing infrastructures are sufficiently
sophisticated to achieve the above.
* Provide leadership when determining testing Do's & Don'ts
[4]. What
makes for an effective test?
* Ensure the gate stays consistently green

And more tactically we're looking at finishing the
Tempest/Neutron
tests dedup [5] and to provide visual graphing for historical
control
and data plane performance results similar to [6].

[1] http://stackalytics.com/report/contribution/neutron/90
[2]

http://docs.openstack.org/developer/neutron/policies/neutron-teams.html
[3]

http://docs.openstack.org/developer/neutron/devref/development.environment.html#testing-neutron
[4]
https://assafmuller.com/2015/05/17/testing-lightning-talk/
[5] https://etherpad.openstack.org/p/neutron-tempest-defork
[6]

https://www.youtube.com/watch?v=a0qlsH1hoKs=youtu.be=24m22s


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

<http://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://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

<mailto: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://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 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 

Re: [openstack-dev] Mitaka - OVS Firewall Driver, not working = OVSFWPortNotFound

[Jakub Libosvar]

On 04/28/2016 07:29 PM, Martinx - ジェームズ wrote:
> Guys,
> 
>  I'm trying to enable OVS Firewall Driver in my Cloud Env but, it is not
> working...
> 
>  I'm trying to replace the following line (openvswitch_agent.ini config
> across the cloud):
You also need to set it for mechanism driver. We are trying to find and
implement better approach, tracked here:
https://bugs.launchpad.net/neutron/+bug/1560957

> 
> ---
>  firewall_driver =
> neutron.agent.linux.iptables_firewall.OVSHybridIptablesFirewallDriver
> ---
> 
>  By this:
> 
> ---
>  firewall_driver = openvswitch
> ---
> 
>  But it does not work in a multi-node env (all-in-one looks good).
> 
>  I'm seeing the following error on Neutron OpenvSwitch Agents, while
> trying to launch Instances:
> 
>  "OVSFWPortNotFound" Port "is not managed by this agent"
> 
>  Full log putput:
> 
>  http://paste.openstack.org/show/495252/
> 
>  The result is that instances are inaccessible from its Floating IP.
> Rolling back to OVSHybrid, all goo again.
> 
>  What am I missing?
That sounds like port is not plugged into integration bridge. Can you
please open a launchpad bug so we can track it there instead of mailing
list?

You can also attach there output of ovs-vsctl show to make sure we have
the port available.

Thanks,
Kuba

> 
> Thanks!
> Thiago
> 
> 
> __
> 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

Re: [openstack-dev] [Neutron][Infra] Post processing of gate hooks on job timeouts

[Jakub Libosvar]

On 04/11/2016 06:41 PM, Clark Boylan wrote:
> On Mon, Apr 11, 2016, at 03:07 AM, Jakub Libosvar wrote:
>> Hi,
>>
>> recently we hit an issue in Neutron with tests getting stuck [1]. As a
>> side effect we discovered logs are not collected properly which makes it
>> hard to find the root cause. The reason of missing logs is that we send
>> SIGKILL to whatever gate hook is running when we hit the global timeout
>> per gate job [2]. This gives no time to running process to perform any
>> post-processing. In post_gate_hook function in Neutron, we collect logs
>> from /tmp directory, compress them and move them to /opt/stack/logs to
>> make them exposed.
>>
>> I have in mind two solutions to which I'd like to get feedback before
>> sending patches.
>>
>> 1) In Neutron, we execute tests in post_gate_hook (dunno why). But even
>> if we would have moved test execution into gate_hook and tests get stuck
>> then the post_gate_hook won't be triggered [3]. So the solution I
>> propose here is to terminate gate_hook N minutes before global timeout
>> and still execute post_gate_hook (with timeout) as post-processing
>> routine.
>>
>> 2) Second proposal is to let timeout wrapped commands know they are
>> about to be killed. We can send let's say SIGTERM instead of SIGKILL and
>> after certain amount of time, send SIGKILL. Example: We send SIGTERM 3
>> minutes before global timeout, letting these 3 minutes to 'command' to
>> handle the SIGTERM signal.
>>
>>  timeout -s 15 -k 3 $((REMAINING_TIME-3))m bash -c "command"
>>
>> With the 2nd approach we can trap the signal that kills running test
>> suite and collects logs with same functions we currently have.
>>
>>
>> I would personally go with second option but I want to hear if anybody
>> has a better idea about post processing in gate jobs or if there is
>> already a tool we can use to collect logs.
>>
>> Thanks,
>> Kuba
> 
> Devstack gate already does a "soft" timeout [0] then proceeds to cleanup
> (part of which is collecting logs) [1], then Jenkins does the "hard"
> timeout [2]. Why aren't we collecting the required log files as part of
> the existing cleanup?
This existing cleanup doesn't support hooks. Neutron tests produce a lot
of logs by default stored in /tmp/dsvm- so we need to compress
and move them to /opt/stack/logs in order to get them collected by [1].

> 
> [0]
> https://git.openstack.org/cgit/openstack-infra/devstack-gate/tree/devstack-vm-gate-wrap.sh#n569
> [1]
> https://git.openstack.org/cgit/openstack-infra/devstack-gate/tree/devstack-vm-gate-wrap.sh#n594
> [2]
> https://git.openstack.org/cgit/openstack-infra/project-config/tree/jenkins/jobs/devstack-gate.yaml#n325
> 
> 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][Infra] Post processing of gate hooks on job timeouts

[Jakub Libosvar]

Hi,

recently we hit an issue in Neutron with tests getting stuck [1]. As a
side effect we discovered logs are not collected properly which makes it
hard to find the root cause. The reason of missing logs is that we send
SIGKILL to whatever gate hook is running when we hit the global timeout
per gate job [2]. This gives no time to running process to perform any
post-processing. In post_gate_hook function in Neutron, we collect logs
from /tmp directory, compress them and move them to /opt/stack/logs to
make them exposed.

I have in mind two solutions to which I'd like to get feedback before
sending patches.

1) In Neutron, we execute tests in post_gate_hook (dunno why). But even
if we would have moved test execution into gate_hook and tests get stuck
then the post_gate_hook won't be triggered [3]. So the solution I
propose here is to terminate gate_hook N minutes before global timeout
and still execute post_gate_hook (with timeout) as post-processing routine.

2) Second proposal is to let timeout wrapped commands know they are
about to be killed. We can send let's say SIGTERM instead of SIGKILL and
after certain amount of time, send SIGKILL. Example: We send SIGTERM 3
minutes before global timeout, letting these 3 minutes to 'command' to
handle the SIGTERM signal.

 timeout -s 15 -k 3 $((REMAINING_TIME-3))m bash -c "command"

With the 2nd approach we can trap the signal that kills running test
suite and collects logs with same functions we currently have.


I would personally go with second option but I want to hear if anybody
has a better idea about post processing in gate jobs or if there is
already a tool we can use to collect logs.

Thanks,
Kuba


[1] https://bugs.launchpad.net/bugs/1567668
[2]
https://github.com/openstack-infra/devstack-gate/blob/master/functions.sh#L1151
[3]
https://github.com/openstack-infra/devstack-gate/blob/master/devstack-vm-gate-wrap.sh#L581

__
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] Make a separate library from /neutron/agent/ovsdb

[Jakub Libosvar]

On 02/03/2016 12:23 PM, Petr Horacek wrote:
> Hello,
> 
> would it be possible to change /neutron/agent/ovsdb package into a
> separate library, independent on openstack? It's a pity that there is
> no high-level python library for ovs handling available and your
> implementation seems to be great. The module is dependent only or some
> openstack utils, would be packaging a problem?
> 
> Thanks,
> Petr
Hi,

there is an initiative to move some parts of the code from neutron tree
into neutron-lib[1][2] so that other services like neutron-*aas don't
necessarily need to depend on neutron. ovsdb sounds like a reusable
library code.

[1]
http://specs.openstack.org/openstack/neutron-specs/specs/mitaka/neutron-lib.html
[2] https://github.com/openstack/neutron-lib
> 
> __
> 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

Re: [openstack-dev] [neutron] Testing Neutron with latest OVS

[Jakub Libosvar]

On 01/14/2016 12:38 AM, Matthew Treinish wrote:
> On Wed, Jan 13, 2016 at 10:47:21PM +, Sean M. Collins wrote:
>> On Wed, Jan 13, 2016 at 03:57:37PM CST, Mooney, Sean K wrote:
>>> One of the ideas that I have been thinking about over the last month or two 
>>> is do we
>>> Want to create a dedicated library file in devstack to support compilation 
>>> and installation
>>> Of ovs. 
>>
>> So, my suggestion is as follows: create a new devstack plugin that is
>> *specifically* geared towards just compiling OVS and installing it to
>> get the bits that you need.
> 
> +1, you do not want a monolithic plugin that does everything. Creating a
> separate small plugin to install ovs from source and the other pieces 
> necessary
> for doing that is the best path for enabling this.
If I understand correctly, this requires to either create a new git
repository that just provides a function to compile ovs or add it to
some already existing project like ovs.

Given that we will likely not even use it with devstack but only in
gate_hook.sh for functional/ job, I don't see the point in creating new
repository for one bash function or any "small plugin".

I know it was me who originally put the code in the Neutron devstack
plugin. So seems like the thing we need to solve is "Where will it
live". How about creating a separate script in tools?

> 
>> I'm just concerned about the feature creep
>> that is happening in the Neutron DevStack plugin ( which I didn't like in
>> the first place ) where now every little thing is getting proposed
>> against it.
>>
>> I'd prefer to see small, very specific DevStack plugins that have narrow
>> focus, and jobs that need them for specific things adding them to their
>> local.conf settings explicitly via enable_repo lines.
> 
> This is the intended way to use plugins. Dumping everything but the kitchen
> sink into a single plugin is just going to tightly couple too much and lead
> to an undebugable tangled ball of yarn. The idea with plugins is to have
> smaller plugins that can be used in conjunction to configure and enable
> various additional pieces.
> 
>>
>> The concern I have with compiling bleeding edge OVS and then running our
>> Neutron jobs is that yes, we get new features, but yes we also get
>> the newest bugs and the configuration matrix for Neutron now gets a new
>> dimension of 'packaged OVS versus git commit SHA'
>>
> 
> I don't think you ever want to have a gating job with OVS from source.
> There is way too much potential instability when building something like this
> from source to rely on it. An experimental job would probably be as far as I
> would go with something like this. Going any further than that is just asking
> for trouble.
Experimental job sounds like the best candidate but it also brings
disadvantages like having the new code prone to regressions, as tests
for new features will need to be skipped in normal gate jobs.

In functional tests we don't use any complex scenarios on OVS. It mostly
tests interface drivers with simple steps like creating bridge and
plugging interface to it. I believe this is pretty basic thing that
works even in unstable development branch of OVS.

Thanks for ideas.
Kuba

> 
> -Matt Treinish
> 
> 
> 
> __
> 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] Testing Neutron with latest OVS

[Jakub Libosvar]

Hi all,

recently I was working on firewall driver [1] that requires latest
features in OVS, specifically conntrack support. In order to get the
driver tested, we need to have the latest OVS kernel modules on machines
running tests but AFAIK there is no stable "2.5 like" release of OVS yet.

Facing the same problem OVN did in the past, I decided to try to steal
their solution and apply it in our Neutron repo [2]. Sean and Matthew
rightfully expressed worries about this approach on review of [2].

So I'd like to bring this to a broader audience and ask for help or
suggestion on how to test such Neutron features that require some newer
versions.

The first idea was to have an option to compile trunk ovs and use it in
particular jobs like functional one. That would bring faster development
of features going along with ovs features.

Please share your ideas :)

Thanks!
Kuba

[1] https://review.openstack.org/#/c/249337
[2] https://review.openstack.org/#/c/266423

__
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] Security Groups OVS conntrack support

[Jakub Libosvar]

On 11/22/2015 07:28 PM, Gal Sagie wrote:
> Hi Fawad,
> 
> From what i could understand from Miguel Angel Ajo, someone is working
> on this integration and it
> is suppose to be delivered as part of Mitaka.
> I don't remember the person name, Miguel will sure update shortly.
> 
> Gal.

Hi Fawad, Gal,

I'm the person working on ovs firewall. There is reported an rfe bug [1]
to tracking it.

Kuba

[1] https://bugs.launchpad.net/neutron/+bug/1461000
> 
> On Sun, Nov 22, 2015 at 7:05 PM, Fawad Khaliq  > wrote:
> 
> Folks,
> 
> Is there a plan to add conntrack support to the security groups for
> the OVS driver in Mitaka cycle? 
> 
> My understanding is that it is being actively worked on for
> networking-ovn but no concrete plan for support in the OVS Neutron
> driver yet.
> 
> Thanks,
> Fawad Khaliq
> 
> 
> __
> 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 ,
> 
> The G.
> 
> 
> __
> 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

Re: [openstack-dev] [Horizon][Neutron] how to configure horizon to use lbaas api v2?

[Jakub Libosvar]

On 07/28/2015 12:09 PM, Wilence Yao wrote:
 Hi all,
 In devstack, I configured
 enable_plugin neutron-lbaas
 https://git.openstack.org/openstack/neutron-lbaas
 ENABLED_SERVICES+=,q-lbaasv2
 
 so, I can use lbaasv2 api in neutronclient. But I see the agent that's
 name is q-lbaasv2 not q-lbaas in screen, and horizon can  recognize it .
 So I cann't use resource about lbaas in horizon.
 What should to let horizon recognize q-lbaasv2?
 
 Wilence Yao
 
 
 __
 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
 

This question was asked recently:
http://lists.openstack.org/pipermail/openstack-dev/2015-July/070066.html

Related BP: https://blueprints.launchpad.net/horizon/+spec/lbaas-v2-panel

Kuba

__
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] How to configure sriov nic using in neutron ml2 plugin

[Jakub Libosvar]

On 05/11/2015 04:13 PM, Kamsali, RaghavendraChari (Artesyn) wrote:
 Hi,
 
  
 
 I want to use SR-IOV supported nic (intel XL710) NIC for VM
 instantiation , so I would like to configure ml2plugin for the intel
 XL710 nic , How can could any one help me .
 
  
 
 https://wiki.openstack.org/wiki/PCI_passthrough_SRIOV_support
 
  
 
 https://wiki.openstack.org/wiki/SR-IOV-Passthrough-For-Networking
 
  
 
 Here some of them are provided .

Hi Raghavendrachari,

you may also find these blog posts [1][2] by Nir Yechiel interesting and
they may help you with configuration.

If you have any particular issue or question, feel free to ask on the list.

Good luck.
Kuba

[1]
http://redhatstackblog.redhat.com/2015/03/05/red-hat-enterprise-linux-openstack-platform-6-sr-iov-networking-part-i-understanding-the-basics/
[2]
http://redhatstackblog.redhat.com/2015/04/29/red-hat-enterprise-linux-openstack-platform-6-sr-iov-networking-part-ii-walking-through-the-implementation/

 
  
 
  
 
 Thanks and Regards,
 
 *Raghavendrachari kamsali *| Software Engineer II  | Embedded Computing
 
 *Artesyn Embedded Technologies***|**5th Floor, Capella Block, The V,
 Madhapur| Hyderabad, AP 500081 India
 
 T +91-40-66747059 | M +919705762153
 
  
 
 
 
 __
 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

Re: [openstack-dev] [neutron][ml2][sqlalchemy] Database table does not exists error

[Jakub Libosvar]

On 01/22/2015 01:00 PM, Ettore zugliani wrote:
 I am implementing the precommit part of a mechanism driver (ml2) right
 now i'm having problems with sqlalchemy. 
 I made the class that uses the tables, but when the precommit is called
 an error pops up telling that the tables don't exists. 
 To create the tables should i use a create all on initialize? or is
 there a proper way of doing it?
Hi Ettore,

you need to make a migration script for your class. More info can be
found here: https://wiki.openstack.org/wiki/Neutron/DatabaseMigration

After autogenerating you can fine-tune it. It's gonna be placed at
neutron/db/migration/alembic_migrations/versions/

Kuba

 
 
 __
 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

Re: [openstack-dev] [neutron][devstack][keystone] Devstack failures due to empty service catalogue

[Jakub Libosvar]

It is caused by using old python-openstackclient [1]. We should be using
= 1.0.2 - fix is about to be merged [2].

Kuba

[1] https://bugs.launchpad.net/devstack/+bug/1413252
[2] https://review.openstack.org/#/c/148951/

On 01/22/2015 04:20 AM, Zhou, Zhenzan wrote:
 Just noticed that your log has “2015-01-21 16:43:24.674 | The service
 catalog is empty.”
 
  
 
 I just met a similar issue: stack.sh aborted with service catalog empty
 error). I
 
 find errors like below:
 
  
 
 2015-01-22 14:34:10.048 | ++ get_or_create_service cinder volume 'Cinder
 Volume Service'
 
 2015-01-22 14:34:10.049 | +++ openstack service show cinder -f value -c id
 
 2015-01-22 14:34:10.607 | +++ openstack service create volume --name
 cinder '--description=Cinder Volume Service' -f value -c id
 
 2015-01-22 14:34:11.096 | usage: openstack service create [-h] [-f
 {html,json,shell,table,value,yaml}]
 
 2015-01-22 14:34:11.096 | [-c COLUMN]
 [--max-width integer]
 
 2015-01-22 14:34:11.096 | [--prefix
 PREFIX] --type service-type
 
 2015-01-22 14:34:11.096 | [--description
 service-description]
 
 2015-01-22 14:34:11.097 | service-name
 
 2015-01-22 14:34:11.097 | openstack service create: error: argument
 --type is required
 
  
 
 The reason is that my openstack client is old and not compatible with
 new devstack code. I have to git clone python-openstackclient and
 
 install it manually.
 
 I don’t know why devstack doesn’t check this. Any comments from experts?
 Thanks.
 
  
 
 BR
 
 Zhou Zhenzan
 
  
 
  
 
 *From:*Sukhdev Kapur [mailto:sukhdevka...@gmail.com]
 *Sent:* Thursday, January 22, 2015 4:58 AM
 *To:* OpenStack Development Mailing List (not for usage questions);
 openstack-in...@lists.openstack.org
 *Subject:* [openstack-dev] [neutron][devstack][keystone] Devstack
 failures due to empty service catalogue
 
  
 
 Hi All, 
 
  
 
 I noticed that our CI got hit sometime last night. Neutron is unable to
 create private network as there is no Tenant ID. 
 
  
 
 Please see the error log here - http://paste.openstack.org/show/159912/
 
  
 
 It appears that keystone is not creating tenant. Keystone screen log did
 not show anything obvious.
 
  
 
 I wonder if others saw the same issue and if anybody has any idea as to
 what could have caused this? I looked at the obvious places and could
 not find anything interesting. 
 
  
 
 Any guidance/help will be appreciated. 
 
  
 
 Thanks
 
 -Sukhdev
 
  
 
 
 
 __
 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

Re: [openstack-dev] [Neutron] grenade failures

[Jakub Libosvar]

On 01/14/2015 10:58 AM, yatin kumbhare wrote:
 Many of them on gerrit page.
 
 Mine is also one of them.
 https://review.openstack.org/#/c/145290/
 
 Regards,
 Yatin
The cause is that nova-compute cannot start on stable/juno branch:
http://logs.openstack.org/90/145290/2/check/check-grenade-dsvm-neutron/b328def/logs/old/screen-n-cpu.txt.gz

I'm looking into this issue and will update once I have more info.

Kuba

 
 On Wed, Jan 14, 2015 at 2:21 PM, Miguel Ángel Ajo majop...@redhat.com
 mailto:majop...@redhat.com wrote:
 
 Hi Sukhdev, thanks,
 Can you post links to the specific patches?
 
 Miguel Ángel Ajo
 
 On Wednesday, 14 de January de 2015 at 09:01, Sukhdev Kapur wrote:
 
 Hi All, 

 I noticed that several neutron patches are failing
 check-grenade-dsvm-neutron. I pinged it on IRC, did not get any
 response, thought I post it here. 


 -Sukhdev


 
 __
 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe:
 openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 mailto: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://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 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] [Openstack-operators] The state of nova-network to neutron migration

[Jakub Libosvar]

On 12/24/2014 10:07 AM, Oleg Bondarev wrote:
 
 
 On Mon, Dec 22, 2014 at 10:08 PM, Anita Kuno ante...@anteaya.info
 mailto:ante...@anteaya.info wrote:
 
 On 12/22/2014 01:32 PM, Joe Gordon wrote:
  On Fri, Dec 19, 2014 at 9:28 AM, Kyle Mestery mest...@mestery.com
 mailto:mest...@mestery.com wrote:
 
  On Fri, Dec 19, 2014 at 10:59 AM, Anita Kuno
 ante...@anteaya.info mailto:ante...@anteaya.info wrote:
 
  Rather than waste your time making excuses let me state where we
 are and
  where I would like to get to, also sharing my thoughts about how
 you can
  get involved if you want to see this happen as badly as I have
 been told
  you do.
 
  Where we are:
  * a great deal of foundation work has been accomplished to
 achieve
  parity with nova-network and neutron to the extent that those
 involved
  are ready for migration plans to be formulated and be put in place
  * a summit session happened with notes and intentions[0]
  * people took responsibility and promptly got swamped with other
  responsibilities
  * spec deadlines arose and in neutron's case have passed
  * currently a neutron spec [1] is a work in progress (and it
 needs
  significant work still) and a nova spec is required and doesn't
 have a
  first draft or a champion
 
  Where I would like to get to:
  * I need people in addition to Oleg Bondarev to be available
 to help
  come up with ideas and words to describe them to create the
 specs in a
  very short amount of time (Oleg is doing great work and is a
 fabulous
  person, yay Oleg, he just can't do this alone)
  * specifically I need a contact on the nova side of this complex
  problem, similar to Oleg on the neutron side
  * we need to have a way for people involved with this effort
 to find
  each other, talk to each other and track progress
  * we need to have representation at both nova and neutron weekly
  meetings to communicate status and needs
 
  We are at K-2 and our current status is insufficient to expect
 this work
  will be accomplished by the end of K-3. I will be championing
 this work,
  in whatever state, so at least it doesn't fall off the map. If
 you would
  like to help this effort please get in contact. I will be
 thinking of
  ways to further this work and will be communicating to those who
  identify as affected by these decisions in the most effective
 methods of
  which I am capable.
 
  Thank you to all who have gotten us as far as well have gotten
 in this
  effort, it has been a long haul and you have all done great
 work. Let's
  keep going and finish this.
 
  Thank you,
  Anita.
 
  Thank you for volunteering to drive this effort Anita, I am very
 happy
  about this. I support you 100%.
 
  I'd like to point out that we really need a point of contact on
 the nova
  side, similar to Oleg on the Neutron side. IMHO, this is step 1
 here to
  continue moving this forward.
 
 
  At the summit the nova team marked the nova-network to neutron
 migration as
  a priority [0], so we are collectively interested in seeing this
 happen and
  want to help in any way possible.   With regard to a nova point of
 contact,
  anyone in nova-specs-core should work, that way we can cover more time
  zones.
 
  From what I can gather the first step is to finish fleshing out
 the first
  spec [1], and it sounds like it would be good to get a few nova-cores
  reviewing it as well.
 
 
 
 
  [0]
 
 
 http://specs.openstack.org/openstack/nova-specs/priorities/kilo-priorities.html
  [1] https://review.openstack.org/#/c/142456/
 
 
 Wonderful, thank you for the support Joe.
 
 It appears that we need to have a regular weekly meeting to track
 progress in an archived manner.
 
 I know there was one meeting November but I don't know what it was
 called so so far I can't find the logs for that.
 
 
 It wasn't official, we just gathered together on #novamigration.
 Attaching the log here.
 
 
 So if those affected by this issue can identify what time (UTC please,
 don't tell me what time zone you are in it is too hard to guess what UTC
 time you are available) and day of the week you are available for a
 meeting I'll create one and we can start talking to each other.
 
 I need to avoid Monday 1500 and 2100 UTC, Tuesday 0800 UTC, 1400 UTC and
 1900 - 2200 UTC, Wednesdays 1500 - 1700 UTC, Thursdays 1400 and 2100
 UTC.
 
 
 I'm available each weekday 0700-1600 UTC, 1700-1800 UTC is also acceptable.
 
 Thanks,
 Oleg

Hi all,
I'm quite flexible, any business day 0800-2300 UTC with several
exceptions is 

Re: [openstack-dev] [neutron][stable] metadata agent performance

[Jakub Libosvar]

On 10/22/2014 02:26 AM, Maru Newby wrote:
 We merged caching support for the metadata agent in juno, and backported to 
 icehouse.  It was enabled by default in juno, but disabled by default in 
 icehouse to satisfy the stable maint requirement of not changing functional 
 behavior.
 
 While performance of the agent was improved with caching enabled, it 
 regressed a reported 8x when caching was disabled [1].  This means that by 
 default, the caching backport severely impacts icehouse Neutron's performance.
 
 So, what is the way forward?  We definitely need to document the problem for 
 both icehouse and juno.  Is documentation enough?  Or can we enable caching 
 by default in icehouse?  Or remove the backport entirely.
 
 There is also a proposal to replace the metadata agent’s use of the neutron 
 client in favor of rpc [2].  There were comments on an old bug suggesting we 
 didn’t want to do this [3], but assuming that we want this change in Kilo, is 
 backporting even a possibility given that it implies a behavioral change to 
 be useful?
 
 Thanks,
 
 
 Maru
 
 
 
 1: https://bugs.launchpad.net/cloud-archive/+bug/1361357
 2: https://review.openstack.org/#/c/121782
 3: https://bugs.launchpad.net/neutron/+bug/1092043
 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 
I thought the performance regression was caused by wrong keystone token
caching leading to authentication per neutron client instance. Fix was
backported to Icehouse [1].

Does it mean this patch hasn't solved the problem and regression is
somewhere else?

Kuba

[1] https://review.openstack.org/#/c/120418/

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Neutron][DB] Strategy for collecting models for autogenerate

[Jakub Libosvar]

Hi all,

as a part of making db migrations unconditional we need to have all
models easily collectible [1]. Currently we have a head.py file
containing imports to all models. Disadvantage is that all imports need
to be collected manually and maintained in case new module with model is
added to the tree.

Original suggested approach was to consolidate all models into one
directory providing simple import of all models. This approach wasn't
liked so I tried to implement alternatives.

1) os.walk neutron directory, search for model_base.BASEV2 occurrences
and import such modules.

2) Import all models in the tree excluding UT and neutron.db.migration
(since it contains frozen models).

I did simple benchmark of three mentioned approaches, could be found
here [2].

On a DB meeting today we agreed that least painful way will be importing
all modules with pkgutil. Considering this will be used only in testing
and autogenerate, memory consumption and speed are imho acceptable.

We'd like to know your opinion, and especially Mark's opinion, on
mentioned approaches and if we can agree on the approach chosen on
today's meeting.

Thanks,
Kuba

[1] https://bugs.launchpad.net/neutron/+bug/1346658
[2] http://paste.openstack.org/show/89984/
- time tested with 100 iterations on Lenovo X230, 2 cores with
  hyperthreading Intel(R) Core(TM) i7-3520M CPU @ 2.90GHz

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron][CI] DB migration error

[Jakub Libosvar]

On 07/17/2014 12:18 PM, trinath.soman...@freescale.com wrote:
 Hi Kevin-
 
  
 
 The fix given in the bug report is not working for my CI. I think I need
 to wait for the real fix in the main stream.
What version of alembic library did you have at the time of error?
Are you sure you re-run
pip install -r requirements.txt after you changed the version?

Kuba
 
  
 
 --
 
 Trinath Somanchi - B39208
 
 trinath.soman...@freescale.com| extn: 4048
 
  
 
 *From:*Kevin Benton [mailto:blak...@gmail.com]
 *Sent:* Wednesday, July 16, 2014 10:01 PM
 *To:* OpenStack Development Mailing List (not for usage questions)
 *Subject:* Re: [openstack-dev] [Neutron][CI] DB migration error
 
  
 
 This bug is also affecting Ryu and the Big Switch CI.
 There is a patch to bump the version requirement for alembic linked in
 the bug report that should fix it. It we can't get that merged we may
 have to revert the healing patch.
 
 https://bugs.launchpad.net/bugs/1342507
 
 On Jul 16, 2014 9:27 AM, trinath.soman...@freescale.com
 mailto:trinath.soman...@freescale.com trinath.soman...@freescale.com
 mailto:trinath.soman...@freescale.com wrote:
 
 Hi-
 
  
 
 With the neutron Update to my CI, I get the following error while
 configuring Neutron in devstack.
 
  
 
 2014-07-16 16:12:06.349 | INFO  [alembic.autogenerate.compare]
 Detected server default on column 'poolmonitorassociations.status'
 
 2014-07-16 16:12:06.411 | INFO 
 [neutron.db.migration.alembic_migrations.heal_script] Detected added
 foreign key for column 'id' on table u'ml2_brocadeports'
 
 2014-07-16 16:12:14.853 | Traceback (most recent call last):
 
 2014-07-16 16:12:14.853 |   File /usr/local/bin/neutron-db-manage,
 line 10, in module
 
 2014-07-16 16:12:14.853 | sys.exit(main())
 
 2014-07-16 16:12:14.854 |   File
 /opt/stack/new/neutron/neutron/db/migration/cli.py, line 171, in main
 
 2014-07-16 16:12:14.854 | CONF.command.func(config,
 CONF.command.name http://CONF.command.name)
 
 2014-07-16 16:12:14.854 |   File
 /opt/stack/new/neutron/neutron/db/migration/cli.py, line 85, in
 do_upgrade_downgrade
 
 2014-07-16 16:12:14.854 | do_alembic_command(config, cmd,
 revision, sql=CONF.command.sql)
 
 2014-07-16 16:12:14.854 |   File
 /opt/stack/new/neutron/neutron/db/migration/cli.py, line 63, in
 do_alembic_command
 
 2014-07-16 16:12:14.854 | getattr(alembic_command, cmd)(config,
 *args, **kwargs)
 
 2014-07-16 16:12:14.854 |   File
 /usr/local/lib/python2.7/dist-packages/alembic/command.py, line
 124, in upgrade
 
 2014-07-16 16:12:14.854 | script.run_env()
 
 2014-07-16 16:12:14.854 |   File
 /usr/local/lib/python2.7/dist-packages/alembic/script.py, line
 199, in run_env
 
 2014-07-16 16:12:14.854 | util.load_python_file(self.dir, 'env.py')
 
 2014-07-16 16:12:14.854 |   File
 /usr/local/lib/python2.7/dist-packages/alembic/util.py, line 205,
 in load_python_file
 
 2014-07-16 16:12:14.854 | module = load_module_py(module_id, path)
 
 2014-07-16 16:12:14.854 |   File
 /usr/local/lib/python2.7/dist-packages/alembic/compat.py, line 58,
 in load_module_py
 
 2014-07-16 16:12:14.854 | mod = imp.load_source(module_id, path, fp)
 
 2014-07-16 16:12:14.854 |   File
 /opt/stack/new/neutron/neutron/db/migration/alembic_migrations/env.py,
 line 106, in module
 
 2014-07-16 16:12:14.854 | run_migrations_online()
 
 2014-07-16 16:12:14.855 |   File
 /opt/stack/new/neutron/neutron/db/migration/alembic_migrations/env.py,
 line 90, in run_migrations_online
 
 2014-07-16 16:12:14.855 | options=build_options())
 
 2014-07-16 16:12:14.855 |   File string, line 7, in run_migrations
 
 2014-07-16 16:12:14.855 |   File
 /usr/local/lib/python2.7/dist-packages/alembic/environment.py,
 line 681, in run_migrations
 
 2014-07-16 16:12:14.855 | self.get_context().run_migrations(**kw)
 
 2014-07-16 16:12:14.855 |   File
 /usr/local/lib/python2.7/dist-packages/alembic/migration.py, line
 225, in run_migrations
 
 2014-07-16 16:12:14.855 | change(**kw)
 
 2014-07-16 16:12:14.856 |   File
 
 /opt/stack/new/neutron/neutron/db/migration/alembic_migrations/versions/1d6ee1ae5da5_db_healing.py,
 line 32, in upgrade
 
 2014-07-16 16:12:14.856 | heal_script.heal()
 
 2014-07-16 16:12:14.856 |   File
 
 /opt/stack/new/neutron/neutron/db/migration/alembic_migrations/heal_script.py,
 line 78, in heal
 
 2014-07-16 16:12:14.856 | execute_alembic_command(el)
 
 2014-07-16 16:12:14.856 |   File
 
 /opt/stack/new/neutron/neutron/db/migration/alembic_migrations/heal_script.py,
 line 93, in execute_alembic_command
 
 2014-07-16 16:12:14.856 | parse_modify_command(command)
 
 2014-07-16 16:12:14.856 |   File
 
 

Re: [openstack-dev] [Neutron] Gap 0 (database migrations) closed!

[Jakub Libosvar]

On 07/16/2014 04:29 PM, Paddu Krishnan (padkrish) wrote:
 Hello,
 A follow-up development question related to this:
 
 As a part of https://review.openstack.org/#/c/105563/, which was
 introducing a new table in Neutron DB, I was trying to send for review a
 new file in neutron/db/migration/alembic_migrations/versions/
 https://review.openstack.org/#/c/105563/4/neutron/db/migration/alembic_migrations/versions/1be5bdeb1d9a_ml2_network_overlay_type_driver.py
  which
 got generated through script neutron-db-manage. This also
 updated  neutron/db/migration/alembic_migrations/versions/
 https://review.openstack.org/#/c/105563/4/neutron/db/migration/alembic_migrations/versions/1be5bdeb1d9a_ml2_network_overlay_type_driver.pyHEAD.
 I was trying to send this file for review as well.
 
 git review failed and I saw merge errors
 in neutron/db/migration/alembic_migrations/versions/
 https://review.openstack.org/#/c/105563/4/neutron/db/migration/alembic_migrations/versions/1be5bdeb1d9a_ml2_network_overlay_type_driver.pyHEAD.
  
 
 W/O HEAD modified, jenkins was failing. I am working to fix this and saw
 this e-mail. 
 
 I had to go through all the links in detail in this thread. But,
 meanwhile, the two points mentioned below looks related to the
 patch/issues I am facing. 
 So, if I add a new table, I don't need to run the neutron-db-manage
 script to generate the file and modify the HEAD anymore? Is (2) below
 need to be done manually?
Hi Paddu,

the process is the same (create migration script, update HEAD file), but
all migrations should have

migration_for_plugins = ['*']


Because you created a new DB model in new module, you also need to add

from neutron.plugins.ml2.drivers import type_network_overlay

to neutron/db/migration/models/head.py module.

I hope it helps.

Kuba

 
 Thanks,
 Paddu



 
 From: Anna Kamyshnikova akamyshnik...@mirantis.com
 mailto:akamyshnik...@mirantis.com
 Reply-To: OpenStack Development Mailing List (not for usage questions)
 openstack-dev@lists.openstack.org
 mailto:openstack-dev@lists.openstack.org
 Date: Wednesday, July 16, 2014 1:14 AM
 To: OpenStack Development Mailing List (not for usage questions)
 openstack-dev@lists.openstack.org
 mailto:openstack-dev@lists.openstack.org
 Subject: Re: [openstack-dev] [Neutron] Gap 0 (database migrations) closed!
 
 Hello everyone!
 
 I would like to bring the next two points to everybody's attention:
 
 1) As Henry mentioned if you add new migration you should make it
 unconditional. Conditional migrations should not be merged since now.
 
 2) If you add some new models you should ensure that module containing
 it is imported in /neutron/db/migration/models/head.py.
 
 The second point in important for testing which I hope will be merged
 soon: https://review.openstack.org/76520.
 
 Regards,
 Ann
 
 
 
 On Wed, Jul 16, 2014 at 5:54 AM, Kyle Mestery mest...@mestery.com
 mailto:mest...@mestery.com wrote:
 
 On Tue, Jul 15, 2014 at 5:49 PM, Henry Gessau ges...@cisco.com
 mailto:ges...@cisco.com wrote:
  I am happy to announce that the first (zero'th?) item in the Neutron Gap
  Coverage[1] has merged[2]. The Neutron database now contains all tables 
 for
  all plugins, and database migrations are no longer conditional on the
  configuration.
 
  In the short term, Neutron developers who write migration scripts need 
 to set
migration_for_plugins = ['*']
  but we will soon clean up the template for migration scripts so that 
 this will
  be unnecessary.
 
  I would like to say special thanks to Ann Kamyshnikova and Jakub 
 Libosvar for
  their great work on this solution. Also thanks to Salvatore Orlando and 
 Mark
  McClain for mentoring this through to the finish.
 
  [1]
  
 https://wiki.openstack.org/wiki/Governance/TechnicalCommittee/Neutron_Gap_Coverage
  [2] https://review.openstack.org/96438
 
 This is great news! Thanks to everyone who worked on this particular
 gap. We're making progress on the other gaps identified in that plan,
 I'll send an email out once Juno-2 closes with where we're at.
 
 Thanks,
 Kyle
 
  ___
  OpenStack-dev mailing list
  OpenStack-dev@lists.openstack.org
 mailto:OpenStack-dev@lists.openstack.org
  http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 
 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 mailto:OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 
 
 
 
 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman

[openstack-dev] Promoting healing script to scheme migration script?

[Jakub Libosvar]

Hi all,

I'd like to get some opinions on following idea:

Because currently we have (thanks to Ann) WIP of healing script capable
of changing database scheme by comparing tables in the database to
models in current codebase, I started to think whether it could be used
generally to db upgrades instead of generating migration scripts.

If I understand correctly the purpose of migration scripts used to be to:
1) separate changes according plugins
2) upgrade database scheme
3) migrate data according the changed scheme

Since we dropped on conditional migrations, we can cross out no.1).
The healing script is capable of doing no.2) without any manual effort
and without adding migration script.

That means if we will decide to go along with using script for updating
database scheme, migration scripts will be needed only for data
migration (no.3)) which are from my experience rare.

Also other benefit would be that we won't need to store all database
models from Icehouse release which we probably will need in case we want
to heal database in order to achieve idempotent Icehouse database
scheme with Juno codebase.

Please share your ideas and reveal potential glitches in the proposal.

Thank you,
Kuba

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Neutron][db] Promoting healing script to scheme migration script?

[Jakub Libosvar]

Forgot to add tags, sorry

On 06/09/2014 04:18 PM, Jakub Libosvar wrote:
 Hi all,
 
 I'd like to get some opinions on following idea:
 
 Because currently we have (thanks to Ann) WIP of healing script capable
 of changing database scheme by comparing tables in the database to
 models in current codebase, I started to think whether it could be used
 generally to db upgrades instead of generating migration scripts.
 
 If I understand correctly the purpose of migration scripts used to be to:
 1) separate changes according plugins
 2) upgrade database scheme
 3) migrate data according the changed scheme
 
 Since we dropped on conditional migrations, we can cross out no.1).
 The healing script is capable of doing no.2) without any manual effort
 and without adding migration script.
 
 That means if we will decide to go along with using script for updating
 database scheme, migration scripts will be needed only for data
 migration (no.3)) which are from my experience rare.
 
 Also other benefit would be that we won't need to store all database
 models from Icehouse release which we probably will need in case we want
 to heal database in order to achieve idempotent Icehouse database
 scheme with Juno codebase.
 
 Please share your ideas and reveal potential glitches in the proposal.
 
 Thank you,
 Kuba
 
 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] Fix migration that breaks Grenade jobs

[Jakub Libosvar]

On 04/22/2014 10:53 AM, Anna Kamyshnikova wrote:
 Hello everyone!
 
 I'm working on fixing bug 1307344. I found out solution that will fix
 Grenade jobs and will work for online and offline migartions.
 https://review.openstack.org/87935 But I faced the problem that Metering
 usage won't be fixed as we need to create 2 tables (meteringlabels,
 meteringlabelrules). I tried to create both in patch set #7 but it won't
 work for offline migration. In fact to fix Grenade it is enough to
 create meteringlabels table, that is done in my change in the last patch
 set #8. I want to ask reviewers to take a look at this change and
 suggest something or approve it. I'm available on IRC(akamyshnikova) or
 by email.
 
 Regards 
 Ann
Hi Ann,

Good suggestion how to get out of failing job but I don't think it
should go to 33c3db036fe4_set_length_of_description_field_metering.py
because this failure is grenade specific while the real issue is a fact
that we're not able to add new service plugin to already deployed Neutron.

I think the same workaround you proposed in the 87935 review should go
to grenade itself (from-havana/upgrade-neutron script) just to have the
job working on havana-icehouse upgrade. It's a bit of ugly workaround
though but imho so far the best solution to reach stable job in a short
time.

Kuba

 
 
 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] Fix migration that breaks Grenade jobs

[Jakub Libosvar]

On 04/22/2014 02:38 PM, Salvatore Orlando wrote:
 When I initially spoke to the infra team regarding this problem, they
 suggested that just fixing migrations so that the job could run was
 not a real option.
 I tend to agree with this statement.
 However, I'm open to options for getting grenade going until the
 migration problem is solved. Ugly workarounds might be fine, as long as
 we won't be doing anything that a real deployer would never do.
 
 Personally, I still think the best way for getting grenade to work is to
 ensure previos_rev and current_rev have the same configuration. For the
 havana/icehouse upgrade, this will mean that devstack for icehouse
 should not add the metering plugin.

Is it possible to run Icehouse tempest without metering tests?

Kuba

 I and Jakub are overdue a discussion
 on whether this would be feasible or not.
 
 Change 87935 is acceptable as a fix for that specific migration.
 However it does not fix the general issue, where the root cause is that
 currently the state of the neutron database depends on configuration
 settings, and therefore migrations are idempotent as long as the plugin
 configuration is not changed, which is not the case.
 
 Salvatore
 
 
 On 22 April 2014 11:14, Jakub Libosvar libos...@redhat.com
 mailto:libos...@redhat.com wrote:
 
 On 04/22/2014 10:53 AM, Anna Kamyshnikova wrote:
  Hello everyone!
 
  I'm working on fixing bug 1307344. I found out solution that will fix
  Grenade jobs and will work for online and offline migartions.
  https://review.openstack.org/87935 But I faced the problem that
 Metering
  usage won't be fixed as we need to create 2 tables (meteringlabels,
  meteringlabelrules). I tried to create both in patch set #7 but it
 won't
  work for offline migration. In fact to fix Grenade it is enough to
  create meteringlabels table, that is done in my change in the last
 patch
  set #8. I want to ask reviewers to take a look at this change and
  suggest something or approve it. I'm available on
 IRC(akamyshnikova) or
  by email.
 
  Regards
  Ann
 Hi Ann,
 
 Good suggestion how to get out of failing job but I don't think it
 should go to 33c3db036fe4_set_length_of_description_field_metering.py
 because this failure is grenade specific while the real issue is a fact
 that we're not able to add new service plugin to already deployed
 Neutron.
 
 I think the same workaround you proposed in the 87935 review should go
 to grenade itself (from-havana/upgrade-neutron script) just to have the
 job working on havana-icehouse upgrade. It's a bit of ugly workaround
 though but imho so far the best solution to reach stable job in a short
 time.
 
 Kuba
 
 
 
  ___
  OpenStack-dev mailing list
  OpenStack-dev@lists.openstack.org
 mailto:OpenStack-dev@lists.openstack.org
  http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 
 
 
 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 mailto:OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 
 
 
 
 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] Fix migration that breaks Grenade jobs

[Jakub Libosvar]

On 04/22/2014 03:57 PM, Jakub Libosvar wrote:
 On 04/22/2014 02:38 PM, Salvatore Orlando wrote:
 When I initially spoke to the infra team regarding this problem, they
 suggested that just fixing migrations so that the job could run was
 not a real option.
 I tend to agree with this statement.
 However, I'm open to options for getting grenade going until the
 migration problem is solved. Ugly workarounds might be fine, as long as
 we won't be doing anything that a real deployer would never do.

 Personally, I still think the best way for getting grenade to work is to
 ensure previos_rev and current_rev have the same configuration. For the
 havana/icehouse upgrade, this will mean that devstack for icehouse
 should not add the metering plugin.
 
 Is it possible to run Icehouse tempest without metering tests?
Oh, I see, we can pass regexp to tox.

 
 Kuba
 
 I and Jakub are overdue a discussion
 on whether this would be feasible or not.

 Change 87935 is acceptable as a fix for that specific migration.
 However it does not fix the general issue, where the root cause is that
 currently the state of the neutron database depends on configuration
 settings, and therefore migrations are idempotent as long as the plugin
 configuration is not changed, which is not the case.

 Salvatore


 On 22 April 2014 11:14, Jakub Libosvar libos...@redhat.com
 mailto:libos...@redhat.com wrote:

 On 04/22/2014 10:53 AM, Anna Kamyshnikova wrote:
  Hello everyone!
 
  I'm working on fixing bug 1307344. I found out solution that will fix
  Grenade jobs and will work for online and offline migartions.
  https://review.openstack.org/87935 But I faced the problem that
 Metering
  usage won't be fixed as we need to create 2 tables (meteringlabels,
  meteringlabelrules). I tried to create both in patch set #7 but it
 won't
  work for offline migration. In fact to fix Grenade it is enough to
  create meteringlabels table, that is done in my change in the last
 patch
  set #8. I want to ask reviewers to take a look at this change and
  suggest something or approve it. I'm available on
 IRC(akamyshnikova) or
  by email.
 
  Regards
  Ann
 Hi Ann,

 Good suggestion how to get out of failing job but I don't think it
 should go to 33c3db036fe4_set_length_of_description_field_metering.py
 because this failure is grenade specific while the real issue is a fact
 that we're not able to add new service plugin to already deployed
 Neutron.

 I think the same workaround you proposed in the 87935 review should go
 to grenade itself (from-havana/upgrade-neutron script) just to have the
 job working on havana-icehouse upgrade. It's a bit of ugly workaround
 though but imho so far the best solution to reach stable job in a short
 time.

 Kuba

 
 
  ___
  OpenStack-dev mailing list
  OpenStack-dev@lists.openstack.org
 mailto:OpenStack-dev@lists.openstack.org
  http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 


 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 mailto:OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

 
 
 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] Ports' vif_details after upgrading from havana with ML2

[Jakub Libosvar]

Hello,

In Icehouse was introduced new column vif_details and removed
cap_port_filter. During db migration data in cap_port_filter column are
lost and after upgrade the vif_details column is legally empty. This
leads to tempest tests failure when checking port_filter[1].

What would be the impact of running neutron-server without information
about port_filter in vif_details?
Should neutron-server check this on startup and according vif_type and
mechanism_drivers set the port_filter?

Thanks for explanation.

Kuba

[1]
http://logs.openstack.org/95/58695/40/check/check-grenade-dsvm-neutron/4dc0dff/logs/testr_results.html.gz

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Neutron] Ports' vif_details after upgrading from havana with ML2

[Jakub Libosvar]

Forgot to add tag to subject, sorry about that.

Kuba
On 03/24/2014 05:51 PM, Jakub Libosvar wrote:
 Hello,
 
 In Icehouse was introduced new column vif_details and removed
 cap_port_filter. During db migration data in cap_port_filter column are
 lost and after upgrade the vif_details column is legally empty. This
 leads to tempest tests failure when checking port_filter[1].
 
 What would be the impact of running neutron-server without information
 about port_filter in vif_details?
 Should neutron-server check this on startup and according vif_type and
 mechanism_drivers set the port_filter?
 
 Thanks for explanation.
 
 Kuba
 
 [1]
 http://logs.openstack.org/95/58695/40/check/check-grenade-dsvm-neutron/4dc0dff/logs/testr_results.html.gz
 


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev