[openstack-dev] [release][all] What is upper-constraints.txt?

2016-03-30 Thread Davanum Srinivas 
Folks,

Quick primer/refresh because of some gate/CI issues we saw last few
days with Routes===2.3

upper-constraints.txt is the current set of all the global libraries
that should be used by all the CI jobs.

This file is in the openstack/requirements repo:
http://git.openstack.org/cgit/openstack/requirements/tree/upper-constraints.txt
http://git.openstack.org/cgit/openstack/requirements/tree/upper-constraints.txt?h=stable/mitaka

Anyone working on a project, please ensure that all CI jobs respect
constraints, example from trove below. If jobs don't respect
constraints then they are more likely to break:
https://review.openstack.org/#/c/298850/

Anyone deploying openstack, please consult this file as it's the one
*sane* set of libraries that we test with.

Yes, global-requirements.txt has the ranges that end up in project
requirements files. However, upper-constraints.txt is what we test for
sure in OpenStack CI.

Thanks,
Dims

-- 
Davanum Srinivas :: https://twitter.com/dims

__
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] unit test failures due to new release of Routes package (v2.3)

2016-03-29 Thread Davanum Srinivas 
https://github.com/bbangert/routes/pull/65

On Tue, Mar 29, 2016 at 9:04 PM, Henry Gessau <hen...@gessau.net> wrote:
> https://launchpad.net/bugs/1563028
> https://review.openstack.org/298855
>
> Aditya Vaja <wolverine...@gmail.com> wrote:
>> Hi,
>>
>> I'm seeing unit test failures when I test locally after a fresh git clone of
>> neutron master.
>>
>> $ ./run_tests.sh -V -f
>>
>> log excerpt: http://paste.openstack.org/show/492384/
>>
>> I update the requirements.txt to use 'Routes<2.0,>=1.12.3' and all the tests
>> work fine.
>> I see there was a new release (v2.3 ) of Routes on 28th March 2016 [1], which
>> seems to have caused the issue, specifically:
>>  - Concatenation fix when using submappers with path prefixes. Multiple
>> submappers combined the path prefix inside the controller argument in
>> non-obvious ways. The controller argument will now be properly carried 
>> through
>> when using submappers. PR #28[2].
>>
>> Is anyone else noticing the test failures?
>> Should I submit this requirements.txt change as a patch or should we pass the
>> required two args as the patch? I can do the requirement.txt change. For the
>> latter, somebody who knows what goes on in the extensions.py __init__() 
>> should
>> take a look.
>>
>> I assume this will also affect the stable branches, since the Routes package
>> versin in requirements.txt in previous versions was same as in master.
>>
>> --
>> Aditya
>> [1] 
>> https://routes.readthedocs.org/en/latest/changes.html#release-2-3-march-28-2016
>> [2] 
>> https://github.com/bbangert/routes/pull/28/files?diff=unified#diff-b54de741c3f86d76eb4bce4a223054aaL154
>
>
>
> ______
> 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



-- 
Davanum Srinivas :: https://twitter.com/dims

__
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] [release][all][ptl] release process changes for official projects

2016-03-29 Thread Davanum Srinivas 
Kirill,

This is prep for Newton. So definitely not rocking the boat when we
have a week left.

-- Dims

On Tue, Mar 29, 2016 at 4:08 PM, Kirill Zaitsev <kzait...@mirantis.com> wrote:
> My immediate question is — when would this be merged? Is it a good idea to
> alter this during the final RC week and before mitaka release, rather than
> implement this change early in the Newton cycle and let people release their
> final release the old way?
>
> --
> Kirill Zaitsev
> Murano Team
> Software Engineer
> Mirantis, Inc
>
> On 29 March 2016 at 19:46:08, Doug Hellmann (d...@doughellmann.com) wrote:
>
> During the Mitaka cycle, the release team worked on automation for
> tagging and documenting releases [1]. For the first phase, we focused
> on official teams with the release:managed tag for their deliverables,
> to keep the number of projects manageable as we built out the tools
> and processes we needed. That created a bit of confusion as official
> projects still had to submit openstack/releases changes in order
> to appear on the releases.openstack.org website.
>
> For the second phase during the Newton cycle, we are prepared to
> expand the use of automation to all deliverables for all official
> projects. As part of this shift, we will be updating the Gerrit
> ACLs for projects to ensure that the release team can handle the
> releases and branching. These updates will remove tagging and
> branching rights for anyone not on the central release management
> team. Instead of tagging releases and then recording them in the
> releases repository after the tag is applied, all official teams
> can now use the releases repo to request new releases. We will be
> reviewing version numbers in all tag requests to ensure SemVer is
> followed, and we won't release libraries late in the week, but we
> will process releases regularly so there is no reason this change
> should have a significant impact on your ability to release frequently.
>
> If you're not familiar with the current release process, please
> review the README.rst file in the openstack/releases repository.
> Follow up here on the mailing list or in #openstack-release if you
> have questions.
>
> The project-config change to update ACLs and correct issues with
> the build job definitions for official projects is
> https://review.openstack.org/298866
>
> Doug
>
> [1]
> http://specs.openstack.org/openstack-infra/infra-specs/specs/centralize-release-tagging.html
>
> __
> 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
>



-- 
Davanum Srinivas :: https://twitter.com/dims

__
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] [election][TC] TC Candidacy

2016-03-28 Thread Davanum Srinivas 
Fellow Stackers,

I would like to announce my candidacy for the OpenStack Technical Committee
election.

Currently i am employed by Mirantis and take manage a couple teams, one working
primarily on Oslo/RabbitMQ/ZMQ and the other on Keystone. My other job is
contributing upstream where i can including several Oslo projects, Nova,
Requirements and Release team. I have served as PTL for Oslo for the last
two terms and am proud of our accomplishments including getting rid of the
oslo-incubator, building up our test matrix for better backwards compatibility
testing and increasing the number of people invested in different Oslo projects.

We have a lot of challenges including figuring out how to balance
stability/innovation, fostering new talent, target our limited resources
to make OpenStack even better than it is today. I would like to offer some
ideas as part of the technical committee based on my previous experiences
at ASF, a startup, working at Big Blue etc.

While working on Oslo as PTL, gave me a lot of insight into how different
projects go about their work. Being part of the Requirements and Release
team has helped me understand the day-to-day challenges of how we pull in
different directions but still end up moving forward. Spending time looking
at gate issues and setting up CI jobs has given me a lot of appreciation
around how many things there are we could work on and fix. As part of
the technical committee, i am hoping to help with:

- Cross Project issues, increasing collaboration between projects
- Backwards compatibility issues and testing
- Evangelizing great ideas from different projects

Starting with @markmc, @sdague, @dhellmann and a whole of of others i have
received a lot of support and guidance over the years. I would like to
pay it forward for the new set of folks who are coming, learning
our ways and becoming part of our community.

Thanks,
Dims

Review history: https://review.openstack.org/#/q/reviewer:dims-v,n,z
Commit history: https://review.openstack.org/#/q/owner:dims-v,n,z
Stackalytics: http://stackalytics.com/?user_id=dims-v
OpenHUB: https://www.openhub.net/accounts/davanum
Freenode: dims




-- 
Davanum Srinivas :: https://twitter.com/dims

__
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] [Infra][ec2-api] What happened with EC2-API project in gerrit?

2016-03-28 Thread Davanum Srinivas 
y, whoa! Andrey, i just pinged folks on #openstack-infra.

On Mon, Mar 28, 2016 at 10:39 AM, Ian Cordasco <sigmaviru...@gmail.com> wrote:
>
>
> -Original Message-
> From: Andrey Pavlov <andrey...@gmail.com>
> Reply: OpenStack Development Mailing List (not for usage questions) 
> <openstack-dev@lists.openstack.org>
> Date: March 28, 2016 at 09:34:54
> To: OpenStack Development Mailing List (not for usage questions) 
> <openstack-dev@lists.openstack.org>
> Subject:  Re: [openstack-dev] [Infra][ec2-api] What happened with EC2-API 
> project in gerrit?
>
>> But why I can't see the project in the gerrit.openstack.org?
>
> I'm not seeing any reviews on Gerrit either: 
> https://review.openstack.org/#/q/project:openstack/ec2-api+AND+(status:merged+OR+status:open)
>
> I think this is what you're asking about, right Andrey?
> --
> Ian Cordasco
>
>
> __
> 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



-- 
Davanum Srinivas :: https://twitter.com/dims

__
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] [Infra][ec2-api] What happened with EC2-API project in gerrit?

2016-03-28 Thread Davanum Srinivas 
it's there : http://git.openstack.org/cgit/openstack/ec2-api/

-- Dims

On Mon, Mar 28, 2016 at 10:12 AM, Andrey Pavlov <andrey...@gmail.com> wrote:
> Hello,
>
> Today I found that our EC2-API project has disappeared from gerrit...
> Yesterday it was accessible...
>
> It is still present on github.com/openstack/ec2-api
> Configuration is still present in project-config repository.
> I can't find any changes in governance project related to ec2-api project.
>
> Can anyone say me what happened with our EC2-API project?
>
> --
> Kind regards,
> Andrey Pavlov.
>
> __
> 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



-- 
Davanum Srinivas :: https://twitter.com/dims

__
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

[Yahoo-eng-team] [Bug 1561151] [NEW] Neutron unit tests fail against oslo.* master

2016-03-23 Thread Davanum Srinivas (DIMS) 
Public bug reported:

from http://logs.openstack.org/periodic/periodic-neutron-py27-with-oslo-
master/b093812/console.html#_2016-03-23_06_21_11_099 :

2016-03-23 06:21:11.099 | Captured traceback:
2016-03-23 06:21:11.099 | ~~~
2016-03-23 06:21:11.099 | Traceback (most recent call last):
2016-03-23 06:21:11.099 |   File 
"neutron/tests/unit/extensions/test_dns.py", line 455, in 
test_api_extension_validation_with_bad_dns_names
2016-03-23 06:21:11.100 | 'cannot be converted to lowercase string' in 
res.text or
2016-03-23 06:21:11.191 |   File 
"/home/jenkins/workspace/periodic-neutron-py27-with-oslo-master/.tox/py27-oslo-master/local/lib/python2.7/site-packages/webob/response.py",
 line 420, in _text__get
2016-03-23 06:21:11.191 | "You cannot access Response.text unless 
charset is set")
2016-03-23 06:21:11.191 | AttributeError: You cannot access Response.text 
unless charset is set
2016-03-23 06:21:11.191 |

** Affects: neutron
 Importance: Undecided
 Assignee: Davanum Srinivas (DIMS) (dims-v)
 Status: In Progress

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1561151

Title:
  Neutron unit tests fail against oslo.* master

Status in neutron:
  In Progress

Bug description:
  from http://logs.openstack.org/periodic/periodic-neutron-py27-with-
  oslo-master/b093812/console.html#_2016-03-23_06_21_11_099 :

  2016-03-23 06:21:11.099 | Captured traceback:
  2016-03-23 06:21:11.099 | ~~~
  2016-03-23 06:21:11.099 | Traceback (most recent call last):
  2016-03-23 06:21:11.099 |   File 
"neutron/tests/unit/extensions/test_dns.py", line 455, in 
test_api_extension_validation_with_bad_dns_names
  2016-03-23 06:21:11.100 | 'cannot be converted to lowercase string' 
in res.text or
  2016-03-23 06:21:11.191 |   File 
"/home/jenkins/workspace/periodic-neutron-py27-with-oslo-master/.tox/py27-oslo-master/local/lib/python2.7/site-packages/webob/response.py",
 line 420, in _text__get
  2016-03-23 06:21:11.191 | "You cannot access Response.text unless 
charset is set")
  2016-03-23 06:21:11.191 | AttributeError: You cannot access Response.text 
unless charset is set
  2016-03-23 06:21:11.191 |

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1561151/+subscriptions

-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 1561121] [NEW] Keystone unit test failure with oslo.* from master

2016-03-23 Thread Davanum Srinivas (DIMS) 
Public bug reported:

from http://logs.openstack.org/periodic/periodic-keystone-py27-with-
oslo-master/0665198/console.html#_2016-03-23_06_21_06_074

2016-03-23 06:21:06.073 | ==
2016-03-23 06:21:06.073 | Failed 1 tests - output below:
2016-03-23 06:21:06.073 | ==
2016-03-23 06:21:06.073 | 
2016-03-23 06:21:06.073 | 
keystone.tests.unit.common.test_manager.TestCreateLegacyDriver.test_class_is_properly_deprecated
2016-03-23 06:21:06.073 | 

2016-03-23 06:21:06.074 | 
2016-03-23 06:21:06.074 | Captured traceback:
2016-03-23 06:21:06.074 | ~~~
2016-03-23 06:21:06.074 | Traceback (most recent call last):
2016-03-23 06:21:06.074 |   File 
"/home/jenkins/workspace/periodic-keystone-py27-with-oslo-master/.tox/py27-oslo-master/local/lib/python2.7/site-packages/mock/mock.py",
 line 1305, in patched
2016-03-23 06:21:06.074 | return func(*args, **keywargs)
2016-03-23 06:21:06.074 |   File 
"keystone/tests/unit/common/test_manager.py", line 37, in 
test_class_is_properly_deprecated
2016-03-23 06:21:06.075 | mock_reporter.assert_called_with(mock.ANY, 
mock.ANY, details)
2016-03-23 06:21:06.075 |   File 
"/home/jenkins/workspace/periodic-keystone-py27-with-oslo-master/.tox/py27-oslo-master/local/lib/python2.7/site-packages/mock/mock.py",
 line 937, in assert_called_with
2016-03-23 06:21:06.075 | 
six.raise_from(AssertionError(_error_message(cause)), cause)
2016-03-23 06:21:06.075 |   File 
"/home/jenkins/workspace/periodic-keystone-py27-with-oslo-master/.tox/py27-oslo-master/local/lib/python2.7/site-packages/six.py",
 line 718, in raise_from
2016-03-23 06:21:06.075 | raise value
2016-03-23 06:21:06.075 | AssertionError: Expected call: 
report_deprecated_feature(, , {'in_favor_of': 
'keystone.catalog.core.CatalogDriverV8', 'as_of': 'Liberty', 'what': 
'keystone.catalog.core.Driver', 'remove_in': 'N'})
2016-03-23 06:21:06.076 | Actual call: 
report_deprecated_feature(, u'%(what)s 
is deprecated as of %(as_of)s in favor of %(in_favor_of)s and may be removed in 
%(remove_in)s.', {'in_favor_of': 'keystone.catalog.core.CatalogDriverV8', 
'as_of': 'Liberty', 'what': 'keystone.catalog.core.Driver', 'remove_in': 
'Newton'})

** Affects: keystone
 Importance: Undecided
 Status: New

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Identity (keystone).
https://bugs.launchpad.net/bugs/1561121

Title:
  Keystone unit test failure with oslo.* from master

Status in OpenStack Identity (keystone):
  New

Bug description:
  from http://logs.openstack.org/periodic/periodic-keystone-py27-with-
  oslo-master/0665198/console.html#_2016-03-23_06_21_06_074

  2016-03-23 06:21:06.073 | ==
  2016-03-23 06:21:06.073 | Failed 1 tests - output below:
  2016-03-23 06:21:06.073 | ==
  2016-03-23 06:21:06.073 | 
  2016-03-23 06:21:06.073 | 
keystone.tests.unit.common.test_manager.TestCreateLegacyDriver.test_class_is_properly_deprecated
  2016-03-23 06:21:06.073 | 

  2016-03-23 06:21:06.074 | 
  2016-03-23 06:21:06.074 | Captured traceback:
  2016-03-23 06:21:06.074 | ~~~
  2016-03-23 06:21:06.074 | Traceback (most recent call last):
  2016-03-23 06:21:06.074 |   File 
"/home/jenkins/workspace/periodic-keystone-py27-with-oslo-master/.tox/py27-oslo-master/local/lib/python2.7/site-packages/mock/mock.py",
 line 1305, in patched
  2016-03-23 06:21:06.074 | return func(*args, **keywargs)
  2016-03-23 06:21:06.074 |   File 
"keystone/tests/unit/common/test_manager.py", line 37, in 
test_class_is_properly_deprecated
  2016-03-23 06:21:06.075 | mock_reporter.assert_called_with(mock.ANY, 
mock.ANY, details)
  2016-03-23 06:21:06.075 |   File 
"/home/jenkins/workspace/periodic-keystone-py27-with-oslo-master/.tox/py27-oslo-master/local/lib/python2.7/site-packages/mock/mock.py",
 line 937, in assert_called_with
  2016-03-23 06:21:06.075 | 
six.raise_from(AssertionError(_error_message(cause)), cause)
  2016-03-23 06:21:06.075 |   File 
"/home/jenkins/workspace/periodic-keystone-py27-with-oslo-master/.tox/py27-oslo-master/local/lib/python2.7/site-packages/six.py",
 line 718, in raise_from
  2016-03-23 06:21:06.075 | raise value
  2016-03-23 06:21:06.075 | AssertionError: Expected call: 
report_deprecated_feature(, , {'in_favor_of': 
'keystone.catalog.core.CatalogDriverV8', 'as_of': 'Liberty', 'what': 
'keystone.catalog.core.Driver', 'remove_in': 'N'})
  2016-03-23 06:21:06.076 | Actual call: 
report_deprecated_feature(, u'%(what)s 
is deprecated as of %(as_of)s in favor of %(in_favor_of)s and may be removed in 
%(remove_in)s.',

Re: [openstack-dev] [all] Maintaining httplib2 python library

2016-03-21 Thread Davanum Srinivas 
Ian, Chris,

You should see invites to join the httplib2 org on github.

Thanks,
Dims

On Fri, Mar 18, 2016 at 3:04 PM, Ian Cordasco <sigmaviru...@gmail.com> wrote:
>
>
> -Original Message-
> From: Cory Benfield <c...@lukasa.co.uk>
> Reply: OpenStack Development Mailing List (not for usage questions) 
> <openstack-dev@lists.openstack.org>
> Date: March 18, 2016 at 13:06:02
> To: OpenStack Development Mailing List (not for usage questions) 
> <openstack-dev@lists.openstack.org>
> Subject:  Re: [openstack-dev] [all] Maintaining httplib2 python library
>
>>
>> > On 18 Mar 2016, at 17:05, Doug Wiegley wrote:
>> >> On Mar 18, 2016, at 8:31 AM, Cory Benfield wrote:
>> >>
>> >> Getting requests to talk over a Unix domain socket is not particularly 
>> >> tricky, and
>> there are third-party libraries that hook into requests appropriately to 
>> make that
>> happen. For example, the requests-unixsocket module exists that can do the 
>> appropriate
>> things.
>> >
>> > That’s the module that I was eyeing, but we’re just trading one dependency 
>> > for another.
>> Is there something about httplib2 maintenance in particular that makes us 
>> want that
>> gone?
>> >
>> > doug
>>
>> The original message in this thread was about the fact that httplib2 is 
>> currently unmaintained
>> and looking for new maintainers. I believe that was the impetus for the 
>> discussion.
>
> Unrelatedly, the author hasn't responded to either email or twitter. I've 
> offered to help keep it on life support but they've not responded. So perhaps 
> they're not interested in adding maintainers after all.
>
> Either way, it's likely a dying project and not one we should hold onto.
>
> But I mean, ignoring that it's dying, it's a great piece of software.
>
> --
> Ian Cordasco
>
>
> ______
> 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



-- 
Davanum Srinivas :: https://twitter.com/dims

__
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

[Yahoo-eng-team] [Bug 1461459] Re: Allow disabling the evacuate cleanup mechanism in compute manager

2016-03-21 Thread Davanum Srinivas (DIMS) 
** Also affects: nova
   Importance: Undecided
   Status: New

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Compute (nova).
https://bugs.launchpad.net/bugs/1461459

Title:
  Allow disabling the evacuate cleanup mechanism in compute manager

Status in OpenStack Compute (nova):
  New
Status in openstack-manuals:
  Triaged

Bug description:
  https://review.openstack.org/174779
  commit 6f1f9dbc211356a3d0e2d46d3a984d7ceee79ca6
  Author: Tony Breeds 
  Date:   Tue Jan 27 11:17:54 2015 -0800

  Allow disabling the evacuate cleanup mechanism in compute manager
  
  This mechanism attempts to destroy any locally-running instances on
  startup if instance.host != self.host. The assumption is that the
  instance has been evacuated and is safely running elsewhere. This is
  a dangerous assumption to make, so this patch adds a configuration
  variable to disable this behavior if it's not desired.
  
  Note that disabling it may have implications for the case where
  instances *were* evacuated, given potential shared resources.
  To counter that problem, this patch also makes _init_instance()
  skip initialization of the instance if it appears to be owned
  by another host, logging a prominent warning in that case.
  
  As a result, if you have destroy_after_evacuate=False and you start
  a nova compute with an incorrect hostname, or run it twice from
  another host, then the worst that will happen is you get log
  warnings about the instances on the host being ignored. This should
  be an indication that something is wrong, but still allow for
  fixing it without any loss. If the configuration option is disabled
  and a legitimate evacuation does occur, simply enabling it and then
  restarting the compute service will cause the cleanup to occur.
  
  This is added to the workarounds config group because it is really
  only relevant while evacuate is fundamentally broken in this way.
  It needs to be refactored to be more robust, and once that is done,
  this should be able to go away.
  
  Conflicts:
  nova/compute/manager.py
  nova/tests/unit/compute/test_compute.py
  nova/tests/unit/compute/test_compute_mgr.py
  nova/utils.py
  
  NOTE: In nova/utils.py a new section has been introduced but
  only the option addessed by this backport has been included.
  
  DocImpact: New configuration option, and peril warning
  Partial-Bug: #1419785
  (cherry picked from commit 922148ac45c5a70da8969815b4f47e3c758d6974)
  
  -- squashed with commit --
  
  Create a 'workarounds' config group.
  
  This group is for very specific reasons.
  
  If you're:
  - Working around an issue in a system tool (e.g. libvirt or qemu) where 
the fix
is in flight/discussed in that community.
  - The tool can be/is fixed in some distributions and rather than patch 
the code
those distributions can trivially set a config option to get the 
"correct"
behavior.
  This is a good place for your workaround.
  
  (cherry picked from commit b1689b58409ab97ef64b8cec2ba3773aacca7ac5)
  
  --
  
  Change-Id: Ib9a3c72c096822dd5c65c905117ae14994c73e99

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1461459/+subscriptions

-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

Re: [openstack-dev] [oslo] oslo.messaging dispatching into private/protected methods?

2016-03-19 Thread Davanum Srinivas 
Josh,

Haha, see note from russellb :)
http://git.openstack.org/cgit/openstack/nova/tree/nova/network/rpcapi.py#n308

On Thu, Mar 17, 2016 at 6:44 PM, Joshua Harlow <harlo...@fastmail.com> wrote:
> In a follow-up to this.
>
> Seems like the patch to disable/disallow this itself found some 'violations'
> @
> http://logs.openstack.org/24/289624/3/check/gate-oslo.messaging-src-dsvm-full-amqp1-centos7/e3b485c/console.html.gz#_2016-03-11_00_06_56_177
>
> Details: {u'message': u'Unable to associate floating IP 172.24.5.1 to fixed
> IP 10.1.14.255 for instance 3660f872-a8c2-4469-99c3-062ed1a90131. Error:
> Remote error: NoSuchMethod Endpoint does not support RPC method
> _associate_floating_ip\n[u\'Traceback (most recent call last):\\n\', u\'
> File "/opt/stack/new/oslo.messaging/oslo_messaging/rpc/dispatcher.py", line
> 138, in _dispatch_and_reply\\nincoming.message))\\n\', u\' File
> "/opt/stack/new/oslo.messaging/oslo_messaging/rpc/dispatcher.py", line 170,
> in _dispatch\\nraise NoSuchMethod(method)\\n\', u\'NoSuchMethod:
> Endpoint does not support RPC method _associate_floating_ip\\n\'].',
> u'code': 400}
>
> I believe this is a nova error as the test name is
> 'tempest.api.compute.floating_ips.test_floating_ips_actions'
>
> So I guess the question becomes, should we start warning using warnings.warn
> (instead of raising a NoSuchMethod error) and at a later point in the future
> stop using warnings.warn and switch to NoSuchMethod, giving people ample
> enough time to stop dispatching into protected/private methods.
>
> Thoughts?
>
> -Josh
>
> On 03/08/2016 09:43 AM, Joshua Harlow wrote:
>>
>> Hi all,
>>
>> As I was working through https://review.openstack.org/#/c/288719/ for
>> kevin benton to do some things with in neutron it came to my
>> understanding that this code (the dispatcher code that is) can dispatch
>> into nearly arbitrary callables of any object (or that is what it looks
>> like it can do):
>>
>>
>> https://github.com/openstack/oslo.messaging/blob/4.5.0/oslo_messaging/rpc/dispatcher.py#L169
>>
>>
>> So during this exploration of this code for the above review it made me
>> wonder if this is a feature or bug, or if we should at least close the
>> hole of allowing calling into nearly any endpoint method/attribute (even
>> non-callable ones to?).
>>
>> So before doing much more of this (which I started in review
>> https://review.openstack.org/#/c/289624/) I wanted to see if people are
>> actually using this 'ability' (for lack of better words) to call into
>> private/protected methods before pursuing 289624 much more...
>>
>> Thoughts?
>>
>> -Josh
>
>
> ______
> 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



-- 
Davanum Srinivas :: https://twitter.com/dims

__
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] [stable] Proposing Tony Breeds for stable-maint-core

2016-03-19 Thread Davanum Srinivas 
+1 for Tony! (my vote does not count, but still wanted to cheer!)

-- Dims

On Fri, Mar 18, 2016 at 4:38 PM, Anita Kuno <ante...@anteaya.info> wrote:
> On 03/18/2016 04:11 PM, Matt Riedemann wrote:
>> I'd like to propose tonyb for stable-maint-core. Tony is pretty much my
>> day to day guy on stable, he's generally in every stable team meeting
>> (which is not attended well so I appreciate it), and he's as proactive
>> as ever on staying on top of gate issues when they come up, so he's well
>> deserving of it in my mind.
>>
>> Here are review stats for stable for the last 90 days (as defined in the
>> reviewstats repo):
>>
>> http://paste.openstack.org/show/491155/
>>
>> Tony is also the latest nova-stable-maint core and he's done a great job
>> there (as expected) and is very active, which is again much appreciated.
>>
>> Please respond with ack/nack.
>>
> My vote probably doesn't count, but I can't pass up the opportunity to
> say it is nice to see Tony's hard work being acknowledged and appreciated.
>
> I appreciate it.
>
> Thanks Matt,
> Anita.
>
> __
> 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



-- 
Davanum Srinivas :: https://twitter.com/dims

__
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] [cross-project] [all] Quotas -- service vs. library

2016-03-19 Thread Davanum Srinivas 
To complete the context:
https://review.openstack.org/#/c/132127/
https://etherpad.openstack.org/p/kilo-oslo-common-quota-library (from
https://wiki.openstack.org/wiki/Design_Summit/Kilo/Etherpads)

-- Dims

On Wed, Mar 16, 2016 at 9:53 AM, Doug Hellmann <d...@doughellmann.com> wrote:
> Excerpts from Sean Dague's message of 2016-03-16 06:09:47 -0400:
>> On 03/16/2016 05:46 AM, Duncan Thomas wrote:
>> > On 16 March 2016 at 09:15, Tim Bell <tim.b...@cern.ch
>> > <mailto:tim.b...@cern.ch>> wrote:
>> >
>> > Then, there were major reservations from the PTLs at the impacts in
>> > terms of
>> > latency, ability to reconcile and loss of control (transactions are
>> > difficult, transactions
>> > across services more so).
>> >
>> >
>> > Not just PTLs :-)
>> >
>> >
>> > 
>> > I would favor a library, at least initially. If we cannot agree on a
>> > library, it
>> > is unlikely that we can get a service adopted (even if it is 
>> > desirable).
>> >
>> > A library (along the lines of 1 or 2 above) would allow consistent
>> > implementation
>> > of nested quotas and user quotas. Nested quotas is currently only
>> > implemented
>> > in Cinder and user quota implementations vary between projects which is
>> > confusing.
>> >
>> >
>> > It is worth noting that the cinder implementation has been found rather
>> > lacking in correctness, atomicity requirements and testing - I wouldn't
>> > suggest taking it as anything other than a PoC to be honest. Certainly
>> > it should not be cargo-culted into another project in its present state.
>>
>> I think a library approach should probably start from scratch, with
>> lessons learned from Cinder, but not really copied code, for just that
>> reason.
>>
>> This is hard code to get right, which is why it's various degrees of
>> wrong in every project in OpenStack.
>>
>> A common library with it's own db tables and migration train is the only
>> way I can imagine this every getting accomplished given the atomicity
>> and two phase commit constraints of getting quota on long lived, async
>> created resources, with sub resources that also have quota. Definitely
>> think that's the nearest term path to victory.
>
> When we talked about this in Paris (I think, all these hotel basements
> are starting to look the same), the main issue with the library was how
> to tie in db table management with the existing tables owned by the app.
> It's not impossible to solve, but we need some thought to happen
> around the tools for that. Maybe some of the lessons of incremental
> on-demand table updates in nova will help there.
>
> Doug
>
> __
> 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



-- 
Davanum Srinivas :: https://twitter.com/dims

__
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] Maintaining httplib2 python library

2016-03-14 Thread Davanum Srinivas 
Thanks Chris.

On Mon, Mar 14, 2016 at 10:21 AM, Chris Dent <cdent...@anticdent.org> wrote:
> On Mon, 14 Mar 2016, Davanum Srinivas wrote:
>
>> fyi, http://bitworking.org/news/2016/03/an_update_on_httplib2
>>
>> We have httplib2 in our global requirements and lots of projects are
>> using it[1]. Is there anyone willing to step up?
>
>
> I've been thinking about asking Joe about it for a while, so will
> contact him.
>
> --
> Chris Dent   (╯°□°)╯︵┻━┻http://anticdent.org/
> freenode: cdent tw: @anticdent
> __
> 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
>



-- 
Davanum Srinivas :: https://twitter.com/dims

__
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] Maintaining httplib2 python library

2016-03-14 Thread Davanum Srinivas 
Ian,

+1 to get rid of that dependency if possible.

Thanks,
Dims

On Mon, Mar 14, 2016 at 10:24 AM, Ian Cordasco <sigmaviru...@gmail.com> wrote:
>
>
> -Original Message-
> From: Davanum Srinivas <dava...@gmail.com>
> Reply: OpenStack Development Mailing List (not for usage questions) 
> <openstack-dev@lists.openstack.org>
> Date: March 14, 2016 at 09:18:50
> To: OpenStack Development Mailing List (not for usage questions) 
> <openstack-dev@lists.openstack.org>
> Subject:  [openstack-dev] [all] Maintaining httplib2 python library
>
>> Team,
>>
>> fyi, http://bitworking.org/news/2016/03/an_update_on_httplib2
>>
>> We have httplib2 in our global requirements and lots of projects are
>> using it[1]. Is there anyone willing to step up?
>
> Is it really worth our time to dedicate extra resources to that? Glance has 
> been discussing (but it's been a low priority) to switing all our dependence 
> on httplib2 to requests (and maybe urllib3 directly) as necessary.
>
> We have other tools and libraries we can use without taking over maintenance 
> of yet another library.
>
> I think the better question than "Can people please maintain this for the 
> community?" is "What benefits does httplib2 have over something that is 
> actively maintained (and has been actively maintaiend) like urllib3, 
> requests, etc.?"
>
> And then we can (and should) also ask "Why have we been using this? How much 
> work do cores think it would be to remove this from our global requirements?"
>
> --
> Ian Cordasco
>



-- 
Davanum Srinivas :: https://twitter.com/dims

__
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] [all] Maintaining httplib2 python library

2016-03-14 Thread Davanum Srinivas 
Team,

fyi, http://bitworking.org/news/2016/03/an_update_on_httplib2

We have httplib2 in our global requirements and lots of projects are
using it[1]. Is there anyone willing to step up?

Thanks,
Dims


[1] 
http://codesearch.openstack.org/?q=(from%7Cimport).*httplib2=nope==

-- 
Davanum Srinivas :: https://twitter.com/dims

__
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

[Yahoo-eng-team] [Bug 1556549] Re: too many qbr or qvo entries on compute node even though I have 7-8 instances on that compute node

2016-03-13 Thread Davanum Srinivas (DIMS) 
** Also affects: neutron
   Importance: Undecided
   Status: New

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1556549

Title:
  too many qbr or qvo entries on compute node even though I have 7-8
  instances on that compute node

Status in neutron:
  New
Status in OpenStack Compute (nova):
  New

Bug description:
  I am seeing this weird behavior in our production environment. Right now, we 
are seeing an issue where launching of an instance is failing since the compute 
node and neutron is not cleaning up the qbr or qvo it had created even after we 
try to terminate the failed instance. Here are the logs from nova-conductor:-
  2016-03-08 01:35:49.478 14041 ERROR nova.scheduler.utils 
[req-6ec7ee4b-9663-4f1b-910a-a87d99ac941c c665814ae07a4f71b666d04fcb99c2e9 
a0288bedbb884e07bc0c602e7a343de8 - - -] [instance: 
fa9c27b4-06dd-4c04-9647-44e1fb8c1a81] Error from last host: compute-42 (node 
compute-42): [u'Traceback (most recent call last):\n', u'  File 
"/usr/lib/python2.7/site-packages/nova/compute/manager.py", line 2254, in 
_do_build_and_run_instance\nfilter_properties)\n', u'  File 
"/usr/lib/python2.7/site-packages/nova/compute/manager.py", line 2400, in 
_build_and_run_instance\ninstance_uuid=instance.uuid, 
reason=six.text_type(e))\n', u"RescheduledException: Build of instance 
fa9c27b4-06dd-4c04-9647-44e1fb8c1a81 was re-scheduled: Error during following 
call to agent: ['ovs-vsctl', '--timeout=120', '--', '--if-exists', 'del-port', 
u'qvo3e44fa11-05', '--', 'add-port', 'br-int', u'qvo3e44fa11-05', '--', 'set', 
'Interface', u'qvo3e44fa11-05', 
u'external-ids:iface-id=3e44fa11-05b5-44dc-8c0c-6b937fe7abe0', 
 'external-ids:iface-status=active', 
u'external-ids:attached-mac=fa:16:3e:60:aa:5e', 
'external-ids:vm-uuid=fa9c27b4-06dd-4c04-9647-44e1fb8c1a81']\n"]

  This qvo still exists on the compute node:-
  [root@compute-42 rahul]# ifconfig | grep qvo3e44fa11-05
  qvo3e44fa11-05: flags=4419  mtu 9000  
 <- this still exists
  [root@compute-42 rahul]# ifconfig | grep qvo | wc -l
  392   < there are about 350+ such 
entries
  [root@compute-42 rahul]# ifconfig | grep tap | wc -l
  8<--- the compute is running only 
8 instances, still more than 350+ entries for qvo-XX alone
  [root@compute-42 rahul]#

  I am running Kilo release and RHEL 7 Openstack rpms.

  Expected:-
  Shouldn't the qvo and qvb be deleted if creation of instance has failed?

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1556549/+subscriptions

-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 1545002] Re: Grenade Failure - MessagingTimeout on floating IP remove

2016-03-09 Thread Davanum Srinivas (DIMS) 
In each of the 5 hits i see - "Function
'nova.servicegroup.drivers.db.DbDriver._report_state' run outlasted
interval by 104.46 sec"

http://logs.openstack.org/30/285530/7/check/gate-grenade-dsvm/4575575/logs/new/screen-n-net.txt.gz?#_2016-03-08_18_36_23_074
http://logs.openstack.org/54/268054/6/check/gate-grenade-dsvm-ceilometer/a253d5f/logs/new/screen-n-net.txt.gz?#_2016-03-08_08_01_31_912
http://logs.openstack.org/14/288814/2/check/gate-grenade-dsvm/c80d3b0/logs/new/screen-n-net.txt.gz?#_2016-03-08_00_57_02_802
http://logs.openstack.org/76/286976/4/gate/gate-grenade-dsvm/101e2a3/logs/new/screen-n-net.txt.gz?#_2016-03-07_22_42_49_151
http://logs.openstack.org/19/225119/5/check/gate-grenade-dsvm/31baa7b/logs/new/screen-n-net.txt.gz?#_2016-03-07_11_08_44_475

It almost seems like something is locking things up?

** Also affects: nova
   Importance: Undecided
   Status: New

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Compute (nova).
https://bugs.launchpad.net/bugs/1545002

Title:
  Grenade Failure - MessagingTimeout on floating IP remove

Status in OpenStack Compute (nova):
  New
Status in oslo.messaging:
  New

Bug description:
  Logstash query:
  message:" (HTTP 500)"

  Grenade failure:
  2016-02-12 10:31:02.846 | + openstack ip floating remove 172.24.5.2 
cinder_server1
  2016-02-12 10:32:05.422 | Unexpected API Error. Please report this at 
http://bugs.launchpad.net/nova/ and attach the Nova API log if possible.
  2016-02-12 10:32:05.422 |  (HTTP 500) (Request-ID: 
req-b1f17c4c-b814-4a21-9209-13db7915370f)
  2016-02-12 10:32:05.443 | + exit_trap

  Example from: http://logs.openstack.org/12/278012/3/check/gate-
  grenade-dsvm/ac87c30/logs/grenade.sh.txt.gz

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1545002/+subscriptions

-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

Re: [openstack-dev] [all] [api] Reminder: WSME is not being actively maintained

2016-03-08 Thread Davanum Srinivas 
24 instances as shown by codesearch:
http://codesearch.openstack.org/?q=%5E(wsme%7CWSME)=nope=%5E.*requirements.txt=

-- Dims

On Tue, Mar 8, 2016 at 7:41 AM, Jay Pipes <jaypi...@gmail.com> wrote:
> Which projects in OpenStack actually use WSME at this time?
>
> Best,
> -jay
>
> On 03/08/2016 07:10 AM, Chris Dent wrote:
>>
>> On Tue, 8 Mar 2016, Stéphane Bisinger wrote:
>>>
>>> Is there an estimate of how much work/time it would take to refactor the
>>> library to slowly satisfy those three points?
>>
>>
>> No, that is the biggest reason I'm calling it unmaintained. Neither
>> Lucas nor I have the time nor interest in being the people who fix WSME
>> so no estimating has been done.
>>
>>> Also, do we already have clear ideas on where we want to get? While the
>>> three points are clear from a general point of view, what does each of
>>> those points really mean? Which parts have you identified as "not easy to
>>> understand", what architecture you have in mind when speaking about
>>> "modern
>>> Python-based web applications"? IIRC you suggested Pecan as a reference.
>>
>>
>> I may have mentioned Pecan as a useful way to transition away from
>> WSME because many people who are using WSME are actually using
>> WSME+Pecan and its not that hard to extract the WSME parts and
>> replace the input and output handling with voluptuous or something
>> like that.
>>
>> However I don't like Pecan myself because it models URL routing using
>> object-dispatch which I think is very bad for URL design. When we've
>> talked about this before Flask and Falcon were mooted. Flask
>> generally gets the nod because of its community but it requires a
>> commitment to doing things the "Flask way".
>>
>>> IMHO, if we are trying to fix it, the first step should be to have a
>>> clear
>>> plan as to encourage volunteer contributions, even thou there are not
>>> many
>>> of those.
>>
>>
>> That is pretty much the main question: Does OpenStack want to fix
>> it?
>>
>>> That's my 2 cents!
>>
>>
>> Thank you!
>>
>>> (*) I remember that a change I did to correct an HTTP status code
>>> returned
>>> from WSME had an impact in the OpenStack projects using it. So before
>>> releasing a version with the correct status codes we have to remember to
>>> tell others to check their code to ensure it works with the correct
>>> status
>>> codes.
>>
>>
>> Exactly. Projects that use OpenStack have habituated themselves to
>> some of the bad behaviors in WSME (I think at one point it was
>> returning 404 when it should have been 405) and written tests to
>> validate the bad behavior. Upgrading to a new WSME breaks their
>> tests.
>>
>>
>>
>> __
>> 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



-- 
Davanum Srinivas :: https://twitter.com/dims

__
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

[Yahoo-eng-team] [Bug 1552897] Re: Unit test failure when buildnig debian package for Mitaka b3 if dogpile.cache is not 0.5.7

2016-03-07 Thread Davanum Srinivas (DIMS) 
** Changed in: nova
   Status: In Progress => Fix Released

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Compute (nova).
https://bugs.launchpad.net/bugs/1552897

Title:
  Unit test failure when buildnig debian package for Mitaka b3 if
  dogpile.cache is not 0.5.7

Status in OpenStack Compute (nova):
  Fix Released
Status in oslo.cache:
  Fix Released

Bug description:
  When building the Debian package of Nova for Mitaka b3 (ie: Nova
  13.0.0~b3), I get the below unit test failures. Please help me to fix
  this. I'm available on IRC if you need more details and a way to
  reproduce (but basically, try to build the package in Sid +
  Experimental using the sources from git clone
  git://git.debian.org/git/openstack/nova.git).

  ==
  FAIL: nova.tests.unit.test_cache.TestOsloCache.test_get_client
  nova.tests.unit.test_cache.TestOsloCache.test_get_client
  --
  _StringException: Empty attachments:
pythonlogging:''
stderr
stdout

  Traceback (most recent call last):
File "/usr/lib/python2.7/dist-packages/mock/mock.py", line 1305, in patched
  return func(*args, **keywargs)
File "nova/tests/unit/test_cache.py", line 64, in test_get_client
  expiration_time=60)],
File "/usr/lib/python2.7/dist-packages/mock/mock.py", line 969, in 
assert_has_calls
  ), cause)
File "/usr/lib/python2.7/dist-packages/six.py", line 718, in raise_from
  raise value
  AssertionError: Calls not found.
  Expected: [call('oslo_cache.dict', arguments={'expiration_time': 60}, 
expiration_time=60), call('dogpile.cache.memcached', arguments={'url': 
['localhost:11211']}, expiration_time=60), call('dogpile.cache.null', 
_config_argument_dict=, _config_prefix='cache.oslo.arguments.', 
expiration_time=60, wrap=None), call('oslo_cache.dict', 
arguments={'expiration_time': 60}, expiration_time=60)]
  Actual: [call('oslo_cache.dict', arguments={'expiration_time': 60}, 
expiration_time=60),
   call('dogpile.cache.memcached', arguments={'url': ['localhost:11211']}, 
expiration_time=60),
   call('dogpile.cache.null', 
_config_argument_dict={'cache.oslo.arguments.pool_maxsize': 10, 
'cache.oslo.arguments.pool_unused_timeout': 60, 'cache.oslo.arguments.url': 
['localhost:11211'], 'cache.oslo.arguments.socket_timeout': 3, 
'cache.oslo.expiration_time': 60, 'cache.oslo.arguments.dead_retry': 300, 
'cache.oslo.arguments.pool_connection_get_timeout': 10, 'cache.oslo.backend': 
'dogpile.cache.null'}, _config_prefix='cache.oslo.arguments.', 
expiration_time=60),
   call('oslo_cache.dict', arguments={'expiration_time': 60}, 
expiration_time=60)]

  ==
  FAIL: nova.tests.unit.test_cache.TestOsloCache.test_get_memcached_client
  nova.tests.unit.test_cache.TestOsloCache.test_get_memcached_client
  --
  _StringException: Empty attachments:
pythonlogging:''
stderr
stdout

  Traceback (most recent call last):
File "/usr/lib/python2.7/dist-packages/mock/mock.py", line 1305, in patched
  return func(*args, **keywargs)
File "nova/tests/unit/test_cache.py", line 120, in test_get_memcached_client
  expiration_time=60, wrap=None)]
File "/usr/lib/python2.7/dist-packages/mock/mock.py", line 969, in 
assert_has_calls
  ), cause)
File "/usr/lib/python2.7/dist-packages/six.py", line 718, in raise_from
  raise value
  AssertionError: Calls not found.
  Expected: [call('dogpile.cache.memcached', arguments={'url': 
['localhost:11211']}, expiration_time=60), call('dogpile.cache.memcached', 
arguments={'url': ['localhost:11211']}, expiration_time=60), 
call('dogpile.cache.null', _config_argument_dict=, 
_config_prefix='cache.oslo.arguments.', expiration_time=60, wrap=None)]
  Actual: [call('dogpile.cache.memcached', arguments={'url': 
['localhost:11211']}, expiration_time=60),
   call('dogpile.cache.memcached', arguments={'url': ['localhost:11211']}, 
expiration_time=60),
   call('dogpile.cache.null', 
_config_argument_dict={'cache.oslo.arguments.pool_maxsize': 10, 
'cache.oslo.arguments.pool_unused_timeout': 60, 'cache.oslo.arguments.url': 
['localhost:11211'], 'cache.oslo.arguments.socket_timeout': 3, 
'cache.oslo.expiration_time': 60, 'cache.oslo.arguments.dead_retry': 300, 
'cache.oslo.arguments.pool_connection_get_timeout': 10, 'cache.oslo.backend': 
'dogpile.cache.null'}, _config_prefix='cache.oslo.arguments.', 
expiration_time=60)]

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1552897/+subscriptions

-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   :

[Yahoo-eng-team] [Bug 1290234] Re: do not use __builtin__ in Python3

2016-03-07 Thread Davanum Srinivas (DIMS) 
** Changed in: nova
   Status: In Progress => Fix Released

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1290234

Title:
  do not use __builtin__ in Python3

Status in Bandit:
  Fix Released
Status in Glance:
  Fix Released
Status in heat:
  Triaged
Status in OpenStack Identity (keystone):
  Fix Released
Status in Magnum:
  Fix Released
Status in neutron:
  In Progress
Status in OpenStack Compute (nova):
  Fix Released
Status in octavia:
  Fix Released
Status in Swift Authentication:
  Fix Released
Status in Trove:
  In Progress
Status in tuskar:
  Fix Released

Bug description:
  __builtin__ does not exist in Python 3, use six.moves.builtins
  instead.

To manage notifications about this bug go to:
https://bugs.launchpad.net/bandit/+bug/1290234/+subscriptions

-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 1428424] Re: Remove use of contextlib.nested

2016-03-06 Thread Davanum Srinivas (DIMS) 
** Changed in: nova
 Assignee: ChangBo Guo(gcb) (glongwave) => Davanum Srinivas (DIMS) (dims-v)

** Changed in: nova
   Status: In Progress => Fix Released

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1428424

Title:
  Remove use of contextlib.nested

Status in Cinder:
  Fix Released
Status in Glance:
  Fix Released
Status in neutron:
  Fix Released
Status in OpenStack Compute (nova):
  Fix Released

Bug description:
  The contextlib.nested call has been deprecated
  in Python 2.7. This causes DeprecationWarning
  messages in the unit tests.
  
  There are also known issues with contextlib.nested
  that were addressed by the native support for
  multiple "with" variables. For instance, if the
  first object is created but the second one throws
  an exception, the first object's __exit__ is never
  called. For more information see
  https://docs.python.org/2/library/contextlib.html#contextlib.nested
  contextlib.nested is also not compatible in Python 3.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cinder/+bug/1428424/+subscriptions

-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 1407915] Re: libvirt: Leverage xpath instead of searching manully

2016-03-06 Thread Davanum Srinivas (DIMS) 
** Changed in: nova
   Status: In Progress => Won't Fix

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Compute (nova).
https://bugs.launchpad.net/bugs/1407915

Title:
  libvirt: Leverage xpath  instead of  searching manully

Status in OpenStack Compute (nova):
  Won't Fix

Bug description:
  libvirt use xml format to create/describe  domain, add/delete devices.  There 
are some codes  hadle xml search by manul
  like:

  ret = doc.findall('./devices/disk')
  for node in ret:
  for child in node.getchildren():
  if child.tag == 'target':
  if child.get('dev') == device:
  return etree.tostring(node)
  that  can be handled by xpath like:

  node = doc.find("./devices/disk/target[@dev='%s'].." % device)
  if node is not None:
  return etree.tostring(node)

  More complicated code convert  xml to  config instance. then search manully, 
like: 
  from 
https://github.com/openstack/nova/blob/master/nova/virt/libvirt/driver.py#L2924
  to 
https://github.com/openstack/nova/blob/master/nova/virt/libvirt/driver.py#L2932

  This bug will track related issue.

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1407915/+subscriptions

-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 1428645] Re: VMware: Deleting an instance might delete Cinder volume's vmdk

2016-03-06 Thread Davanum Srinivas (DIMS) 
** Changed in: nova
   Status: In Progress => Fix Released

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Compute (nova).
https://bugs.launchpad.net/bugs/1428645

Title:
  VMware: Deleting an instance might delete Cinder volume's vmdk

Status in OpenStack Compute (nova):
  Fix Released

Bug description:
  If the instance is migrated (manual or SDRS) with an attached volume,
  the volume's vmdk will end up in instance's datastore folder.  In such
  a case,  instance destroy deletes the volume vmdk.

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1428645/+subscriptions

-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 1445021] Re: nova-compute does not start after upgrade from juno->kilo if there are boot from volume servers running

2016-03-06 Thread Davanum Srinivas (DIMS) 
*** This bug is a duplicate of bug 1416132 ***
https://bugs.launchpad.net/bugs/1416132

** This bug has been marked a duplicate of bug 1416132
   _get_instance_disk_info fails to read files from NFS due to permissions

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Compute (nova).
https://bugs.launchpad.net/bugs/1445021

Title:
  nova-compute does not start after upgrade from juno->kilo if there are
  boot from volume servers running

Status in OpenStack Compute (nova):
  In Progress

Bug description:
  Running: nova master in grenade tests

  Relevant job that triggers this:

  http://logs.openstack.org/91/173791/11/check/check-grenade-
  dsvm/fc725f5/

  This patch attempted to test the survivability of a "boot from volume"
  system over the course of the upgrade, however when we tried to do
  this a lot of tests failed.

  It turns out that libvirt's device scan actually fails in this
  situation after boot:

  http://logs.openstack.org/91/173791/11/check/check-grenade-
  dsvm/fc725f5/logs/new/screen-n-cpu.txt.gz#_2015-04-16_11_39_05_009

  2015-04-16 11:39:05.009 ERROR nova.openstack.common.threadgroup 
[req-b09699d4-5d28-4eeb-a09c-412f48da3d68 None None] Unexpected error while 
running command.
  Command: sudo nova-rootwrap /etc/nova/rootwrap.conf blockdev --getsize64 
/dev/disk/by-path/ip-127.0.0.1:3260-iscsi-iqn.2010-10.org.openstack:volume-f1015aa4-1998-47c1-8ce6-625ca0fa2b8c-lun-1
  Exit code: 1
  Stdout: u''
  Stderr: u'blockdev: cannot open 
/dev/disk/by-path/ip-127.0.0.1:3260-iscsi-iqn.2010-10.org.openstack:volume-f1015aa4-1998-47c1-8ce6-625ca0fa2b8c-lun-1:
 No such device or address\n'
  2015-04-16 11:39:05.009 13951 TRACE nova.openstack.common.threadgroup 
Traceback (most recent call last):
  2015-04-16 11:39:05.009 13951 TRACE nova.openstack.common.threadgroup   File 
"/opt/stack/new/nova/nova/openstack/common/threadgroup.py", line 145, in wait
  2015-04-16 11:39:05.009 13951 TRACE nova.openstack.common.threadgroup 
x.wait()
  2015-04-16 11:39:05.009 13951 TRACE nova.openstack.common.threadgroup   File 
"/opt/stack/new/nova/nova/openstack/common/threadgroup.py", line 47, in wait
  2015-04-16 11:39:05.009 13951 TRACE nova.openstack.common.threadgroup 
return self.thread.wait()
  2015-04-16 11:39:05.009 13951 TRACE nova.openstack.common.threadgroup   File 
"/usr/local/lib/python2.7/dist-packages/eventlet/greenthread.py", line 175, in 
wait
  2015-04-16 11:39:05.009 13951 TRACE nova.openstack.common.threadgroup 
return self._exit_event.wait()
  2015-04-16 11:39:05.009 13951 TRACE nova.openstack.common.threadgroup   File 
"/usr/local/lib/python2.7/dist-packages/eventlet/event.py", line 121, in wait
  2015-04-16 11:39:05.009 13951 TRACE nova.openstack.common.threadgroup 
return hubs.get_hub().switch()
  2015-04-16 11:39:05.009 13951 TRACE nova.openstack.common.threadgroup   File 
"/usr/local/lib/python2.7/dist-packages/eventlet/hubs/hub.py", line 294, in 
switch
  2015-04-16 11:39:05.009 13951 TRACE nova.openstack.common.threadgroup 
return self.greenlet.switch()
  2015-04-16 11:39:05.009 13951 TRACE nova.openstack.common.threadgroup   File 
"/usr/local/lib/python2.7/dist-packages/eventlet/greenthread.py", line 214, in 
main
  2015-04-16 11:39:05.009 13951 TRACE nova.openstack.common.threadgroup 
result = function(*args, **kwargs)
  2015-04-16 11:39:05.009 13951 TRACE nova.openstack.common.threadgroup   File 
"/opt/stack/new/nova/nova/openstack/common/service.py", line 497, in run_service
  2015-04-16 11:39:05.009 13951 TRACE nova.openstack.common.threadgroup 
service.start()
  2015-04-16 11:39:05.009 13951 TRACE nova.openstack.common.threadgroup   File 
"/opt/stack/new/nova/nova/service.py", line 183, in start
  2015-04-16 11:39:05.009 13951 TRACE nova.openstack.common.threadgroup 
self.manager.pre_start_hook()
  2015-04-16 11:39:05.009 13951 TRACE nova.openstack.common.threadgroup   File 
"/opt/stack/new/nova/nova/compute/manager.py", line 1288, in pre_start_hook
  2015-04-16 11:39:05.009 13951 TRACE nova.openstack.common.threadgroup 
self.update_available_resource(nova.context.get_admin_context())
  2015-04-16 11:39:05.009 13951 TRACE nova.openstack.common.threadgroup   File 
"/opt/stack/new/nova/nova/compute/manager.py", line 6237, in 
update_available_resource
  2015-04-16 11:39:05.009 13951 TRACE nova.openstack.common.threadgroup 
rt.update_available_resource(context)
  2015-04-16 11:39:05.009 13951 TRACE nova.openstack.common.threadgroup   File 
"/opt/stack/new/nova/nova/compute/resource_tracker.py", line 376, in 
update_available_resource
  2015-04-16 11:39:05.009 13951 TRACE nova.openstack.common.threadgroup 
resources = self.driver.get_available_resource(self.nodename)
  2015-04-16 11:39:05.009 13951 TRACE nova.openstack.common.threadgroup   File 
"/opt/stack/new/nova/nova/virt/libvirt/driver.py", line 4908, in 
get_available_resource
  2015-04-16 11:39:05.009

[Yahoo-eng-team] [Bug 1505476] Re: when live-migrate failed, remove_volume_connection function accept incorrect arguments order in kilo

2016-03-04 Thread Davanum Srinivas (DIMS) 
** Changed in: nova
   Status: In Progress => Fix Committed

** Changed in: nova
   Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Compute (nova).
https://bugs.launchpad.net/bugs/1505476

Title:
  when live-migrate failed,remove_volume_connection function  accept
  incorrect arguments order  in kilo

Status in OpenStack Compute (nova):
  Fix Released

Bug description:
  Openstack Version : kilo 2015.1.0

  Reproduce steps:

  please see the paths of codes:openstack/nova/nova/compute/manager.py

  def _rollback_live_migration(self, context, instance,dest,
  block_migration, migrate_data=None):

  ..
  for bdm in bdms:
  if bdm.is_volume:
  self.compute_rpcapi.remove_volume_connection(
  context, instance, bdm.volume_id, dest)
  ..
   
  Actual result:

  def remove_volume_connection(self, context, volume_id, instance):
  ..
  ..

  Expected result:

  def remove_volume_connection(self, context, instance, volume_id):

  
  pelease check this bug , thanks.

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1505476/+subscriptions

-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 1552897] Re: Unit test failure when buildnig debian package for Mitaka b3 if dogpile.cache is not 0.5.7

2016-03-04 Thread Davanum Srinivas (DIMS) 
Fixed now https://review.openstack.org/#/c/288474/

** Changed in: oslo.cache
   Status: New => Fix Released

** Changed in: oslo.cache
   Importance: Undecided => High

** Changed in: oslo.cache
 Assignee: (unassigned) => Davanum Srinivas (DIMS) (dims-v)

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Compute (nova).
https://bugs.launchpad.net/bugs/1552897

Title:
  Unit test failure when buildnig debian package for Mitaka b3 if
  dogpile.cache is not 0.5.7

Status in OpenStack Compute (nova):
  New
Status in oslo.cache:
  Fix Released

Bug description:
  When building the Debian package of Nova for Mitaka b3 (ie: Nova
  13.0.0~b3), I get the below unit test failures. Please help me to fix
  this. I'm available on IRC if you need more details and a way to
  reproduce (but basically, try to build the package in Sid +
  Experimental using the sources from git clone
  git://git.debian.org/git/openstack/nova.git).

  ==
  FAIL: nova.tests.unit.test_cache.TestOsloCache.test_get_client
  nova.tests.unit.test_cache.TestOsloCache.test_get_client
  --
  _StringException: Empty attachments:
pythonlogging:''
stderr
stdout

  Traceback (most recent call last):
File "/usr/lib/python2.7/dist-packages/mock/mock.py", line 1305, in patched
  return func(*args, **keywargs)
File "nova/tests/unit/test_cache.py", line 64, in test_get_client
  expiration_time=60)],
File "/usr/lib/python2.7/dist-packages/mock/mock.py", line 969, in 
assert_has_calls
  ), cause)
File "/usr/lib/python2.7/dist-packages/six.py", line 718, in raise_from
  raise value
  AssertionError: Calls not found.
  Expected: [call('oslo_cache.dict', arguments={'expiration_time': 60}, 
expiration_time=60), call('dogpile.cache.memcached', arguments={'url': 
['localhost:11211']}, expiration_time=60), call('dogpile.cache.null', 
_config_argument_dict=, _config_prefix='cache.oslo.arguments.', 
expiration_time=60, wrap=None), call('oslo_cache.dict', 
arguments={'expiration_time': 60}, expiration_time=60)]
  Actual: [call('oslo_cache.dict', arguments={'expiration_time': 60}, 
expiration_time=60),
   call('dogpile.cache.memcached', arguments={'url': ['localhost:11211']}, 
expiration_time=60),
   call('dogpile.cache.null', 
_config_argument_dict={'cache.oslo.arguments.pool_maxsize': 10, 
'cache.oslo.arguments.pool_unused_timeout': 60, 'cache.oslo.arguments.url': 
['localhost:11211'], 'cache.oslo.arguments.socket_timeout': 3, 
'cache.oslo.expiration_time': 60, 'cache.oslo.arguments.dead_retry': 300, 
'cache.oslo.arguments.pool_connection_get_timeout': 10, 'cache.oslo.backend': 
'dogpile.cache.null'}, _config_prefix='cache.oslo.arguments.', 
expiration_time=60),
   call('oslo_cache.dict', arguments={'expiration_time': 60}, 
expiration_time=60)]

  ==
  FAIL: nova.tests.unit.test_cache.TestOsloCache.test_get_memcached_client
  nova.tests.unit.test_cache.TestOsloCache.test_get_memcached_client
  --
  _StringException: Empty attachments:
pythonlogging:''
stderr
stdout

  Traceback (most recent call last):
File "/usr/lib/python2.7/dist-packages/mock/mock.py", line 1305, in patched
  return func(*args, **keywargs)
File "nova/tests/unit/test_cache.py", line 120, in test_get_memcached_client
  expiration_time=60, wrap=None)]
File "/usr/lib/python2.7/dist-packages/mock/mock.py", line 969, in 
assert_has_calls
  ), cause)
File "/usr/lib/python2.7/dist-packages/six.py", line 718, in raise_from
  raise value
  AssertionError: Calls not found.
  Expected: [call('dogpile.cache.memcached', arguments={'url': 
['localhost:11211']}, expiration_time=60), call('dogpile.cache.memcached', 
arguments={'url': ['localhost:11211']}, expiration_time=60), 
call('dogpile.cache.null', _config_argument_dict=, 
_config_prefix='cache.oslo.arguments.', expiration_time=60, wrap=None)]
  Actual: [call('dogpile.cache.memcached', arguments={'url': 
['localhost:11211']}, expiration_time=60),
   call('dogpile.cache.memcached', arguments={'url': ['localhost:11211']}, 
expiration_time=60),
   call('dogpile.cache.null', 
_config_argument_dict={'cache.oslo.arguments.pool_maxsize': 10, 
'cache.oslo.arguments.pool_unused_timeout': 60, 'cache.oslo.arguments.url': 
['localhost:11211'], 'cache.oslo.arguments.socket_timeout': 3, 
'cache.oslo.expiration_time': 60, 'cache.oslo.arguments.dead_retry': 300, 
'cache.oslo.arguments.pool_connection_get_timeout': 10, 'cache.oslo.backend': 
'dogpile.cache.null'}, _config_prefix='cache.oslo.arguments.', 
expiration_time=60)]

To manage notifications about

[Bug 1368030] Re: nova-manage command when executed by non-root user, should give "authorization error" instead of low level database error

2016-03-03 Thread Davanum Srinivas (DIMS) 
** Changed in: nova
 Assignee: vishal yadav (vishalcdac07) => (unassigned)

-- 
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to nova in Ubuntu.
https://bugs.launchpad.net/bugs/1368030

Title:
  nova-manage command when executed by non-root user, should give
  "authorization error" instead of low level database error

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1368030/+subscriptions

-- 
Ubuntu-server-bugs mailing list
Ubuntu-server-bugs@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs

[Bug 1368030] Re: nova-manage command when executed by non-root user, should give "authorization error" instead of low level database error

2016-03-03 Thread Davanum Srinivas (DIMS) 
** Changed in: nova
 Assignee: vishal yadav (vishalcdac07) => (unassigned)

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1368030

Title:
  nova-manage command when executed by non-root user, should give
  "authorization error" instead of low level database error

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1368030/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1418187] Re: _get_host_numa_topology assumes numa cell has memory

2016-03-03 Thread Davanum Srinivas (DIMS) 
** Changed in: nova
   Status: Confirmed => Incomplete

** Changed in: nova (Ubuntu)
   Status: Confirmed => Incomplete

-- 
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to nova in Ubuntu.
https://bugs.launchpad.net/bugs/1418187

Title:
  _get_host_numa_topology assumes numa cell has memory

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1418187/+subscriptions

-- 
Ubuntu-server-bugs mailing list
Ubuntu-server-bugs@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs

[Bug 1418187] Re: _get_host_numa_topology assumes numa cell has memory

2016-03-03 Thread Davanum Srinivas (DIMS) 
** Changed in: nova
   Status: Confirmed => Incomplete

** Changed in: nova (Ubuntu)
   Status: Confirmed => Incomplete

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1418187

Title:
  _get_host_numa_topology assumes numa cell has memory

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1418187/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1388077] Re: Parallel periodic instance power state reporting from compute nodes has high impact on conductors and message broker

2016-03-03 Thread Davanum Srinivas (DIMS) 
** Changed in: nova
   Status: In Progress => Confirmed

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1388077

Title:
  Parallel periodic instance power state reporting from compute nodes
  has high impact on conductors and message broker

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1388077/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1388077] Re: Parallel periodic instance power state reporting from compute nodes has high impact on conductors and message broker

2016-03-03 Thread Davanum Srinivas (DIMS) 
** Changed in: nova
   Status: In Progress => Confirmed

-- 
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to nova in Ubuntu.
https://bugs.launchpad.net/bugs/1388077

Title:
  Parallel periodic instance power state reporting from compute nodes
  has high impact on conductors and message broker

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1388077/+subscriptions

-- 
Ubuntu-server-bugs mailing list
Ubuntu-server-bugs@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs

[openstack-dev] [oslo] PTL for Newton and beyond

2016-03-03 Thread Davanum Srinivas 
Team,

It has been great working with you all as PTL for Oslo. Looks like the
nominations open up next week for elections and am hoping more than
one of you will step up for the next cycle(s). I can show you the
ropes and help smoothen the transition process if you let me know
about your interest in being the next PTL. With the move to more
automated testing in our CI (periodic jobs running against oslo.*
master) and the adoption of the release process (logging reviews in
/releases repo) the load should be considerably less on you.
especially proud of all the new people joining as both oslo cores and
project cores and hitting the ground running. Big shout out to Doug
Hellmann for his help and guidance when i transitioned into the PTL
role.

Main challenges will be to get back confidence of all the projects
that use the oslo libraries, NOT be the first thing they look for when
things break (Better backward compat, better test matrix) and
evangelizing that Oslo is still the common play ground for *all*
projects and not just the headache of some nut jobs who are willing to
take up the impossible task of defining and nurturing these libraries.
There's a lot of great work ahead of us and i am looking forward to
continue to work with you all.

Thanks,
Dims

-- 
Davanum Srinivas :: https://twitter.com/dims

__
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

[Yahoo-eng-team] [Bug 1479842] Re: os-brick needs to provide it's own rootwrap filters file

2016-03-01 Thread Davanum Srinivas (DIMS) 
The plan is to use oslo.privsep instead of oslo.rootwrap in os-brick.

** Changed in: oslo.rootwrap
   Status: Confirmed => Won't Fix

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Compute (nova).
https://bugs.launchpad.net/bugs/1479842

Title:
  os-brick needs to provide it's own rootwrap filters file

Status in Cinder:
  Confirmed
Status in OpenStack Compute (nova):
  Confirmed
Status in os-brick:
  Fix Released
Status in oslo.rootwrap:
  Won't Fix

Bug description:
  This came up in the review for the scaleio libvirt volume driver in
  nova:

  https://review.openstack.org/#/c/194454/16/etc/nova/rootwrap.d/compute.filters

  Basically, having to define rootwrap filters in nova and cinder for
  things that are run in os-brick is kind of terrible since every time
  os-brick needs to add a new command to run as root, it has to be added
  to nova/cinder, and we have to deal with version compat issues (will
  the version of nova/cinder have the filters required for the version
  of os-brick that's running?).

  This was already introduced with multipathd to compute.filters in the
  os-brick integration change:

  https://review.openstack.org/#/c/175569/32/etc/nova/rootwrap.d/compute.filters

  Rather than revert the os-brick integration change to nova, we should
  work this as a bug so that os-brick can carry it's own os-
  brick.filters file and then that can be dropped into
  /etc/nova/rootwrap.d and /etc/cinder/rootwrap.d.

  So we'll need os-brick changes, nova, cinder and devstack changes to
  land this.

  Also considered a release blocker for liberty for the nova team.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cinder/+bug/1479842/+subscriptions

-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 1510234] Re: Heartbeats stop when time is changed

2016-02-29 Thread Davanum Srinivas (DIMS) 
** Also affects: nova
   Importance: Undecided
   Status: New

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Compute (nova).
https://bugs.launchpad.net/bugs/1510234

Title:
  Heartbeats stop when time is changed

Status in OpenStack Compute (nova):
  New
Status in oslo.service:
  Confirmed

Bug description:
  Heartbeats stop working when you mess with the system time. If a
  monotonic clock were used, they would continue to work when the system
  time was changed.

  Steps to reproduce:

  1. List the nova services ('nova-manage service list'). Note that the
  'State' for each services is a happy face ':-)'.

  2. Move the time ahead (for example 2 hours in the future), and then
  list the nova services again. Note that heartbeats continue to work
  and use the future time (see 'Updated_At').

  3. Revert back to the actual time, and list the nova services again.
  Note that all heartbeats stop, and have a 'State' of 'XXX'.

  4. The heartbeats will start again in 2 hours when the actual time
  catches up to the future time, or if you restart the services.

  5. You'll see a log message like the following when the heartbeats
  stop:

  2015-10-26 17:14:10.538 DEBUG nova.servicegroup.drivers.db [req-
  c41a2ad7-e5a5-4914-bdc8-6c1ca8b224c6 None None] Seems service is down.
  Last heartbeat was 2015-10-26 17:20:20. Elapsed time is -369.461679
  from (pid=13994) is_up
  /opt/stack/nova/nova/servicegroup/drivers/db.py:80

  Here's example output demonstrating the issue:

  http://paste.openstack.org/show/477404/

  See bug #1450438 for more context:

  https://bugs.launchpad.net/oslo.service/+bug/1450438

  Long story short: looping call is using the built-in time rather than
  a  monotonic clock for sleeps.

  
https://github.com/openstack/oslo.service/blob/3d79348dae4d36bcaf4e525153abf74ad4bd182a/oslo_service/loopingcall.py#L122

  Oslo Service: version 0.11
  Nova: master (commit 2c3f9c339cae24576fefb66a91995d6612bb4ab2)

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1510234/+subscriptions

-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 1504725] Re: rabbitmq-server restart twice, log is crazy increasing until service restart

2016-02-28 Thread Davanum Srinivas (DIMS) 
Looks like upgrading kombu fixes the issue, please reopen if there's
anything we need to do in oslo.messaging.

** Changed in: oslo.messaging
   Status: Confirmed => Won't Fix

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1504725

Title:
  rabbitmq-server restart twice, log is crazy increasing until service
  restart

Status in neutron:
  New
Status in OpenStack Compute (nova):
  Confirmed
Status in oslo.messaging:
  Won't Fix

Bug description:
  After I restart the rabbitmq-server for the second time, the service log(such 
as nova,neutron and so on) is increasing crazy, log is such as " TypeError: 
'NoneType' object has no attribute '__getitem__'".
  It seems that the channel is setted to None. 

  trace log:

  2015-10-10 15:20:59.413 29515 TRACE root Traceback (most recent call last):
  2015-10-10 15:20:59.413 29515 TRACE root   File 
"/usr/lib/python2.7/site-packages/oslo_utils/excutils.py", line 95, in 
inner_func
  2015-10-10 15:20:59.413 29515 TRACE root return infunc(*args, **kwargs)
  2015-10-10 15:20:59.413 29515 TRACE root   File 
"/usr/lib/python2.7/site-packages/oslo_messaging/_executors/impl_eventlet.py", 
line 96, in _executor_thread
  2015-10-10 15:20:59.413 29515 TRACE root incoming = self.listener.poll()
  2015-10-10 15:20:59.413 29515 TRACE root   File 
"/usr/lib/python2.7/site-packages/oslo_messaging/_drivers/amqpdriver.py", line 
122, in poll
  2015-10-10 15:20:59.413 29515 TRACE root self.conn.consume(limit=1, 
timeout=timeout)
  2015-10-10 15:20:59.413 29515 TRACE root   File 
"/usr/lib/python2.7/site-packages/oslo_messaging/_drivers/impl_rabbit.py", line 
1202, in consume
  2015-10-10 15:20:59.413 29515 TRACE root six.next(it)
  2015-10-10 15:20:59.413 29515 TRACE root   File 
"/usr/lib/python2.7/site-packages/oslo_messaging/_drivers/impl_rabbit.py", line 
1100, in iterconsume
  2015-10-10 15:20:59.413 29515 TRACE root error_callback=_error_callback)
  2015-10-10 15:20:59.413 29515 TRACE root   File 
"/usr/lib/python2.7/site-packages/oslo_messaging/_drivers/impl_rabbit.py", line 
868, in ensure
  2015-10-10 15:20:59.413 29515 TRACE root ret, channel = autoretry_method()
  2015-10-10 15:20:59.413 29515 TRACE root   File 
"/usr/lib/python2.7/site-packages/kombu/connection.py", line 458, in _ensured
  2015-10-10 15:20:59.413 29515 TRACE root return fun(*args, **kwargs)
  2015-10-10 15:20:59.413 29515 TRACE root   File 
"/usr/lib/python2.7/site-packages/kombu/connection.py", line 545, in __call__
  2015-10-10 15:20:59.413 29515 TRACE root self.revive(create_channel())
  2015-10-10 15:20:59.413 29515 TRACE root   File 
"/usr/lib/python2.7/site-packages/kombu/connection.py", line 251, in channel
  2015-10-10 15:20:59.413 29515 TRACE root chan = 
self.transport.create_channel(self.connection)
  2015-10-10 15:20:59.413 29515 TRACE root   File 
"/usr/lib/python2.7/site-packages/kombu/transport/pyamqp.py", line 91, in 
create_channel
  2015-10-10 15:20:59.413 29515 TRACE root return connection.channel()
  2015-10-10 15:20:59.413 29515 TRACE root   File 
"/usr/lib/python2.7/site-packages/amqp/connection.py", line 289, in channel
  2015-10-10 15:20:59.413 29515 TRACE root return self.channels[channel_id]
  2015-10-10 15:20:59.413 29515 TRACE root TypeError: 'NoneType' object has no 
attribute '__getitem__'
  2015-10-10 15:20:59.413 29515 TRACE root

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1504725/+subscriptions

-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 1547544] Re: heat: MessagingTimeout: Timed out waiting for a reply to message ID

2016-02-28 Thread Davanum Srinivas (DIMS) 
** Changed in: oslo.messaging
   Status: New => Invalid

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Compute (nova).
https://bugs.launchpad.net/bugs/1547544

Title:
  heat: MessagingTimeout: Timed out waiting for a reply to message ID

Status in OpenStack Compute (nova):
  Won't Fix
Status in oslo.messaging:
  Invalid

Bug description:
  Setup:

  Single controller[48 GB RAM, 16vCPU, 120GB Disk]
  3 Network Nodes
  100 ESX hypervisors distributed in 10 nova-compute nodes

  Test:

  1. Create /16 network
  2. Heat template which which will launch 100 instances on network created 
step 1
  3. Create 10 stack back2back so that we reach 1000 instances without waiting 
for previous stack to complete

  Observation:

  stack creations are failing while nova run_periodic_tasks at different
  places like _heal_instance_info_cache,  _sync_scheduler_instance_info,
  _update_available_resource etc

  Have attached sample heat template, heat logs, nova compute log from
  one of the host.

  
  Logs:

  2016-02-19 04:21:54.691 TRACE nova.compute.manager   File 
"/usr/local/lib/python2.7/dist-packages/oslo_concurrency/lockutils.py", line 
271, in inner
  2016-02-19 04:21:54.691 TRACE nova.compute.manager return f(*args, 
**kwargs)
  2016-02-19 04:21:54.691 TRACE nova.compute.manager   File 
"/opt/stack/nova/nova/compute/resource_tracker.py", line 553, in 
_update_available_resource
  2016-02-19 04:21:54.691 TRACE nova.compute.manager context, self.host, 
self.nodename)
  2016-02-19 04:21:54.691 TRACE nova.compute.manager   File 
"/usr/local/lib/python2.7/dist-packages/oslo_versionedobjects/base.py", line 
174, in wrapper
  2016-02-19 04:21:54.691 TRACE nova.compute.manager args, kwargs)
  2016-02-19 04:21:54.691 TRACE nova.compute.manager   File 
"/opt/stack/nova/nova/conductor/rpcapi.py", line 240, in 
object_class_action_versions
  2016-02-19 04:21:54.691 TRACE nova.compute.manager args=args, 
kwargs=kwargs)
  2016-02-19 04:21:54.691 TRACE nova.compute.manager   File 
"/usr/local/lib/python2.7/dist-packages/oslo_messaging/rpc/client.py", line 
158, in call
  2016-02-19 04:21:54.691 TRACE nova.compute.manager retry=self.retry)
  2016-02-19 04:21:54.691 TRACE nova.compute.manager   File 
"/usr/local/lib/python2.7/dist-packages/oslo_messaging/transport.py", line 90, 
in _send
  2016-02-19 04:21:54.691 TRACE nova.compute.manager timeout=timeout, 
retry=retry)
  2016-02-19 04:21:54.691 TRACE nova.compute.manager   File 
"/usr/local/lib/python2.7/dist-packages/oslo_messaging/_drivers/amqpdriver.py", 
line 465, in send
  2016-02-19 04:21:54.691 TRACE nova.compute.manager retry=retry)
  2016-02-19 04:21:54.691 TRACE nova.compute.manager   File 
"/usr/local/lib/python2.7/dist-packages/oslo_messaging/_drivers/amqpdriver.py", 
line 454, in _send
  2016-02-19 04:21:54.691 TRACE nova.compute.manager result = 
self._waiter.wait(msg_id, timeout)
  2016-02-19 04:21:54.691 TRACE nova.compute.manager   File 
"/usr/local/lib/python2.7/dist-packages/oslo_messaging/_drivers/amqpdriver.py", 
line 337, in wait
  2016-02-19 04:21:54.691 TRACE nova.compute.manager message = 
self.waiters.get(msg_id, timeout=timeout)
  2016-02-19 04:21:54.691 TRACE nova.compute.manager   File 
"/usr/local/lib/python2.7/dist-packages/oslo_messaging/_drivers/amqpdriver.py", 
line 239, in get
  2016-02-19 04:21:54.691 TRACE nova.compute.manager 'to message ID %s' % 
msg_id)
  2016-02-19 04:21:54.691 TRACE nova.compute.manager MessagingTimeout: Timed 
out waiting for a reply to message ID a87a7f358a0948efa3ab5beb0c8f45e7
  --

  
  stack@esx-compute-9:/opt/stack/nova$ git log -1
  commit d51c5670d8d26e989d92eb29658eed8113034c0f
  Merge: 4fade90 30d5d80
  Author: Jenkins 
  Date:   Thu Feb 18 17:56:32 2016 +

  Merge "reset task_state after select_destinations failed."
  stack@esx-compute-9:/opt/stack/nova$

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1547544/+subscriptions

-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 1544801] Re: Constant tracebacks with eventlet 0.18.2

2016-02-28 Thread Davanum Srinivas (DIMS) 
Looks like this dropped off

** Changed in: nova
   Status: Confirmed => Invalid

** Changed in: nova
 Assignee: (unassigned) => Davanum Srinivas (DIMS) (dims-v)

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1544801

Title:
  Constant tracebacks with eventlet 0.18.2

Status in Cinder:
  New
Status in Glance:
  New
Status in neutron:
  New
Status in OpenStack Compute (nova):
  Invalid

Bug description:
  Kilo builds, with eventlet 0.18.2 have a constant traceback:

  2016-02-12 00:47:01.126 3936 DEBUG nova.api.openstack.wsgi [-] Calling method 
'>' _process_stack 
/opt/bbc/openstack-11.0-bbc153/nova/local/lib/python2.7/site-packages/nova/api/openstack/wsgi.py:783
  2016-02-12 00:47:01.129 3936 INFO nova.osapi_compute.wsgi.server [-] 
Traceback (most recent call last):
File 
"/opt/bbc/openstack-11.0-bbc153/nova/local/lib/python2.7/site-packages/eventlet/wsgi.py",
 line 501, in handle_one_response
  write(b''.join(towrite))
File 
"/opt/bbc/openstack-11.0-bbc153/nova/local/lib/python2.7/site-packages/eventlet/wsgi.py",
 line 442, in write
  _writelines(towrite)
File 
"/opt/bbc/openstack-11.0-bbc153/nova/local/lib/python2.7/site-packages/eventlet/support/__init__.py",
 line 62, in safe_writelines
  writeall(fd, item)
File 
"/opt/bbc/openstack-11.0-bbc153/nova/local/lib/python2.7/site-packages/eventlet/support/__init__.py",
 line 67, in writeall
  fd.write(buf)
File "/usr/lib/python2.7/socket.py", line 324, in write
  self.flush()
File "/usr/lib/python2.7/socket.py", line 303, in flush
  self._sock.sendall(view[write_offset:write_offset+buffer_size])
File 
"/opt/bbc/openstack-11.0-bbc153/nova/local/lib/python2.7/site-packages/eventlet/greenio/base.py",
 line 383, in sendall
  tail = self.send(data, flags)
File 
"/opt/bbc/openstack-11.0-bbc153/nova/local/lib/python2.7/site-packages/eventlet/greenio/base.py",
 line 377, in send
  return self._send_loop(self.fd.send, data, flags)
File 
"/opt/bbc/openstack-11.0-bbc153/nova/local/lib/python2.7/site-packages/eventlet/greenio/base.py",
 line 364, in _send_loop
  return send_method(data, *args)
  error: [Errno 104] Connection reset by peer

  This is happening across nova, neutron, glance, etc..

  Dropping back to eventlet < 0.18.0 works.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cinder/+bug/1544801/+subscriptions

-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

Re: [openstack-dev] [all] audience for release notes

2016-02-27 Thread Davanum Srinivas 
Thomas,

Please try and let use know what kind of problems you see in Debian as
projects have already switched to reno.

Thanks,
Dims

On Sat, Feb 27, 2016 at 9:09 AM, Thomas Goirand <z...@debian.org> wrote:
> On 02/26/2016 08:34 PM, Doug Hellmann wrote:
>> We implemented reno for this cycle to replace the old wiki-based
>> system for writing release notes for deployers, operators, and
>> end-users.
>
> Is the fact that Reno does "git log" when building the docs a solved
> problem? Because from my past experience with Mitaka b1 / b2, any doc
> using reno will refuse to "sphinx-build" in Debian. If it wasn't fixed,
> then I would suggest to *not* use Reno just yet.
>
> Cheers,
>
> Thomas Goirand (zigo)
>
>
> __
> 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



-- 
Davanum Srinivas :: https://twitter.com/dims

__
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

[Yahoo-eng-team] [Bug 1549516] Re: Too many reconnections to the SQLalchemy engine

2016-02-24 Thread Davanum Srinivas (DIMS) 
for keystone :)

** Changed in: keystone
   Status: New => Invalid

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Identity (keystone).
https://bugs.launchpad.net/bugs/1549516

Title:
  Too many reconnections to the SQLalchemy engine

Status in OpenStack Identity (keystone):
  Invalid
Status in oslo.db:
  New

Bug description:
  === Issue Description ===

  It looks like for every DB request oslo.db is reconnecting to the
  SQLalchemy engine, that leads to  "SELECT 1" request to the database
  per every meaningful request.

  === Prelude() ===

  I was testing osprofiler library (OpenStack profiler) changes, that
  are currently on review for Nova, Neutron and Keystone + OSprofiler
  integration, trying to perform nova-boot requests. After generating
  the trace for this request, I got the following html report:
  https://dinabelova.github.io/nova-boot-keystone-cache-turn-on.html .
  Total number of DB operations done for this request is 417, that seems
  too much for the instance creation. Half of these requests is "SELECT
  1" requests, that are used by oslo.db per engine connection via
  _connect_ping_listener function -
  
https://github.com/openstack/oslo.db/blob/master/oslo_db/sqlalchemy/engines.py#L53

  I ensured that all of these requests are coming from this method via
  adding _connect_ping_listener tracing https://dinabelova.github.io
  /nova-boot-oslodb-ping-listener-profiled.html - so we can see that all
  "SELECT 1" requests are placed under db_ping_listener section in the
  trace.

  These "SELECT 1"s are in fact spending 1/3 of all time SQLalchemy
  engine in oslo.db is spending on all requests. This seems to be a bug.

  === Env description & spets to reproduce ===

  I have devstack environment with latest 1.1.0 osprofiler installed. To
  install profiler on the devstack env I used the following additions to
  the local.conf:

  enable_plugin ceilometer https://git.openstack.org/openstack/ceilometer master
  enable_plugin osprofiler https://git.openstack.org/openstack/osprofiler master

  Additionally I've used the following changes:
  - Nova: https://review.openstack.org/254703
  - Nova client: https://review.openstack.org/#/c/254699/
  - Neutron: https://review.openstack.org/273951
  - Neutron client: https://review.openstack.org/281508
  - Keystone: https://review.openstack.org/103368

  Also I've modified standard keystone.conf to turn memcache caching:

  [cache]

  memcache_servers = 127.0.0.1:11211
  backend = oslo_cache.memcache_pool
  enabled = True

  Then you can simply run nova --profile SECRET_KEY boot --image
   --flavor 42 vm1 to generate all notifications and then
  osprofiler trace show --html  --out nova-boot.html using the
  trace id printed in the bottom of nova boot output.

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1549516/+subscriptions

-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 1549516] Re: Too many reconnections to the SQLalchemy engine

2016-02-24 Thread Davanum Srinivas (DIMS) 
Fixed in https://review.openstack.org/#/c/257458/

** Also affects: keystone
   Importance: Undecided
   Status: New

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Identity (keystone).
https://bugs.launchpad.net/bugs/1549516

Title:
  Too many reconnections to the SQLalchemy engine

Status in OpenStack Identity (keystone):
  Invalid
Status in oslo.db:
  New

Bug description:
  === Issue Description ===

  It looks like for every DB request oslo.db is reconnecting to the
  SQLalchemy engine, that leads to  "SELECT 1" request to the database
  per every meaningful request.

  === Prelude() ===

  I was testing osprofiler library (OpenStack profiler) changes, that
  are currently on review for Nova, Neutron and Keystone + OSprofiler
  integration, trying to perform nova-boot requests. After generating
  the trace for this request, I got the following html report:
  https://dinabelova.github.io/nova-boot-keystone-cache-turn-on.html .
  Total number of DB operations done for this request is 417, that seems
  too much for the instance creation. Half of these requests is "SELECT
  1" requests, that are used by oslo.db per engine connection via
  _connect_ping_listener function -
  
https://github.com/openstack/oslo.db/blob/master/oslo_db/sqlalchemy/engines.py#L53

  I ensured that all of these requests are coming from this method via
  adding _connect_ping_listener tracing https://dinabelova.github.io
  /nova-boot-oslodb-ping-listener-profiled.html - so we can see that all
  "SELECT 1" requests are placed under db_ping_listener section in the
  trace.

  These "SELECT 1"s are in fact spending 1/3 of all time SQLalchemy
  engine in oslo.db is spending on all requests. This seems to be a bug.

  === Env description & spets to reproduce ===

  I have devstack environment with latest 1.1.0 osprofiler installed. To
  install profiler on the devstack env I used the following additions to
  the local.conf:

  enable_plugin ceilometer https://git.openstack.org/openstack/ceilometer master
  enable_plugin osprofiler https://git.openstack.org/openstack/osprofiler master

  Additionally I've used the following changes:
  - Nova: https://review.openstack.org/254703
  - Nova client: https://review.openstack.org/#/c/254699/
  - Neutron: https://review.openstack.org/273951
  - Neutron client: https://review.openstack.org/281508
  - Keystone: https://review.openstack.org/103368

  Also I've modified standard keystone.conf to turn memcache caching:

  [cache]

  memcache_servers = 127.0.0.1:11211
  backend = oslo_cache.memcache_pool
  enabled = True

  Then you can simply run nova --profile SECRET_KEY boot --image
   --flavor 42 vm1 to generate all notifications and then
  osprofiler trace show --html  --out nova-boot.html using the
  trace id printed in the bottom of nova boot output.

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1549516/+subscriptions

-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[openstack-dev] [oslo] code changes for Mitaka

2016-02-23 Thread Davanum Srinivas 
Folks,

Let's wrap up any code changes needed for Mitaka as quickly as
possible. We need to cut final releases by tomorrow.
"Final release for non-client libraries: Feb 24" from Doug's email [1]
We may need some final tweaking just for catching up to g-r later, but
any code changes, we need to wrap up.

Cores,

Please go through what's left in the review queue:
bit.ly/oslo-reviews

Thanks,
Dims

[1] http://markmail.org/message/5mzuzyol5pnuxs5p

-- 
Davanum Srinivas :: https://twitter.com/dims

__
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] [oslo] documentation on using the oslo.db opportunistic test feature

2016-02-22 Thread Davanum Srinivas 
Sean,

yes, please let us know which tests fail and we'll try to fix it.

Thanks,
Dims

On Mon, Feb 22, 2016 at 8:18 PM, Sean Dague <s...@dague.net> wrote:
> On 02/22/2016 08:08 PM, Davanum Srinivas wrote:
>> Sean,
>>
>> You need to set the env variable like so. See testenv:mysql-python for 
>> example
>> OS_TEST_DBAPI_ADMIN_CONNECTION=mysql://openstack_citest:openstack_citest@localhost
>>
>> Thanks,
>> Dims
>>
>> [1] 
>> http://codesearch.openstack.org/?q=OS_TEST_DBAPI_ADMIN_CONNECTION=nope==
>
> If I am reading this correctly, this needs full access to the whole
> mysql administratively?
>
> Is that something that could be addressed? In many of my environments
> the mysql db does other things as well, so giving full admin to
> arbitrary test code is a bit concerning. Tempest ran into a similar
> issue and addressed this by allowing for preallocation of accounts. That
> kind of approach seems like it would work here given that you could do
> grants on well known names.
>
> -Sean
>
> --
> Sean Dague
> http://dague.net
>
>
> __
> 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
>



-- 
Davanum Srinivas :: https://twitter.com/dims

__
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] [oslo] documentation on using the oslo.db opportunistic test feature

2016-02-22 Thread Davanum Srinivas 
Sean,

You need to set the env variable like so. See testenv:mysql-python for example
OS_TEST_DBAPI_ADMIN_CONNECTION=mysql://openstack_citest:openstack_citest@localhost

Thanks,
Dims

[1] 
http://codesearch.openstack.org/?q=OS_TEST_DBAPI_ADMIN_CONNECTION=nope==


On Mon, Feb 22, 2016 at 8:02 PM, Sean Dague <s...@dague.net> wrote:
> Before migrating into oslo.db the opportunistic testing for database
> backends was pretty simple. Create an openstack_citest@openstack_citest
> pw:openstack_citest and you could get tests running on mysql. This no
> longer seems to be the case.
>
> I went digging through the source code a bit and it's not entirely
> evident what the new required setup is. Can someone point me to the docs
> to use this? Or explain what the setup for local testing is now? We've
> got some bugs which expose on mysql and not sqlite in nova that we'd
> like to get some test cases written for.
>
> -Sean
>
> --
> Sean Dague
> http://dague.net
>
>
> __
> 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
>



-- 
Davanum Srinivas :: https://twitter.com/dims

__
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

[Yahoo-eng-team] [Bug 1433687] Re: devstack logs do not contain pid information for log messages with context

2016-02-22 Thread Davanum Srinivas (DIMS) 
** No longer affects: oslo.log

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1433687

Title:
  devstack logs do not contain pid information for log messages with
  context

Status in devstack:
  In Progress
Status in neutron:
  Fix Released

Bug description:
  Compare:

  2015-03-18 15:00:15.990 INFO neutron.wsgi 
[req-412094f3-6b4e-41e8-9f2b-833ff6b3ee7a SecurityGroupsTestJSON-724004567 
SecurityGroupsTestJSON-664869352] 127.0.0.1 - - [18/Mar/2015 15:00:15] "DELETE 
/v2.0/security-groups/9cc93b9a-2d06-46e6-9160-1521683f13f9.json HTTP/1.1" 204 
149 0.060949
  2015-03-18 15:00:16.001 15709 INFO neutron.wsgi [-] (15709) accepted 
('127.0.0.1', 60381)

  This is because in devstack, we override the default log format string
  with the one that misses the info. Note that to make it work, it is
  not enough to fall back to default string, since it uses user_identity
  context field that is missing in neutron context object. That is
  because neutron.context.Context does not rely on oslo_context.Context
  when transforming it to_dict().

  The proper fix would be:

  - make neutron context reuse oslo_context.Context.to_dict()
  - make devstack not overwrite the default log format string

  Also note that log colorizer from devstack also rewrites the default
  format string value. In that case, we just need to update the string
  to include pid information.

  Also note that the issue may be more far reaching, since devstack
  rewrites the string for other services too (nova, ironic, among
  others).

To manage notifications about this bug go to:
https://bugs.launchpad.net/devstack/+bug/1433687/+subscriptions

-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 1508442] Re: LOG.warn is deprecated

2016-02-22 Thread Davanum Srinivas (DIMS) 
** No longer affects: oslo.privsep

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1508442

Title:
  LOG.warn is deprecated

Status in anvil:
  In Progress
Status in Aodh:
  In Progress
Status in Astara:
  Fix Released
Status in Barbican:
  Fix Released
Status in bilean:
  Fix Released
Status in Blazar:
  In Progress
Status in Ceilometer:
  Fix Released
Status in cloud-init:
  In Progress
Status in cloudkitty:
  Fix Released
Status in congress:
  Fix Released
Status in Designate:
  Fix Released
Status in django-openstack-auth:
  Fix Released
Status in django-openstack-auth-kerberos:
  In Progress
Status in DragonFlow:
  Fix Released
Status in ec2-api:
  Fix Released
Status in Evoque:
  In Progress
Status in gce-api:
  In Progress
Status in Glance:
  In Progress
Status in glance_store:
  In Progress
Status in Gnocchi:
  In Progress
Status in heat:
  Fix Released
Status in heat-cfntools:
  In Progress
Status in OpenStack Identity (keystone):
  Fix Released
Status in KloudBuster:
  Fix Released
Status in kolla:
  Fix Released
Status in Magnum:
  Fix Released
Status in Manila:
  Fix Released
Status in Mistral:
  In Progress
Status in networking-arista:
  In Progress
Status in networking-calico:
  In Progress
Status in networking-cisco:
  In Progress
Status in networking-fujitsu:
  Fix Released
Status in networking-odl:
  In Progress
Status in networking-ofagent:
  In Progress
Status in networking-plumgrid:
  In Progress
Status in networking-powervm:
  Fix Released
Status in networking-vsphere:
  In Progress
Status in neutron:
  In Progress
Status in OpenStack Compute (nova):
  In Progress
Status in nova-powervm:
  Fix Released
Status in nova-solver-scheduler:
  In Progress
Status in octavia:
  In Progress
Status in openstack-ansible:
  In Progress
Status in oslo.cache:
  Fix Released
Status in Packstack:
  Fix Released
Status in python-dracclient:
  In Progress
Status in python-magnumclient:
  Fix Released
Status in RACK:
  In Progress
Status in python-watcherclient:
  In Progress
Status in shaker:
  In Progress
Status in Solum:
  Fix Released
Status in tempest:
  In Progress
Status in tripleo:
  In Progress
Status in trove-dashboard:
  Fix Released
Status in watcher:
  Fix Released
Status in zaqar:
  In Progress

Bug description:
  LOG.warn is deprecated in Python 3 [1] . But it still used in a few
  places, non-deprecated LOG.warning should be used instead.

  Note: If we are using logger from oslo.log, warn is still valid [2],
  but I agree we can switch to LOG.warning.

  [1]https://docs.python.org/3/library/logging.html#logging.warning
  [2]https://github.com/openstack/oslo.log/blob/master/oslo_log/log.py#L85

To manage notifications about this bug go to:
https://bugs.launchpad.net/anvil/+bug/1508442/+subscriptions

-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 1512207] Re: Fix usage of assertions

2016-02-22 Thread Davanum Srinivas (DIMS) 
** No longer affects: oslo.utils

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Compute (nova).
https://bugs.launchpad.net/bugs/1512207

Title:
  Fix usage of assertions

Status in Aodh:
  Fix Released
Status in Barbican:
  Fix Released
Status in Blazar:
  In Progress
Status in Cinder:
  Invalid
Status in congress:
  Fix Released
Status in Cue:
  Fix Released
Status in Glance:
  Won't Fix
Status in Group Based Policy:
  In Progress
Status in OpenStack Dashboard (Horizon):
  Fix Released
Status in Ironic:
  Fix Released
Status in Ironic Inspector:
  Fix Released
Status in OpenStack Identity (keystone):
  Fix Released
Status in kuryr:
  Fix Released
Status in Magnum:
  In Progress
Status in Manila:
  Fix Released
Status in Murano:
  Fix Released
Status in neutron:
  Fix Released
Status in OpenStack Compute (nova):
  Invalid
Status in OpenStack Health:
  In Progress
Status in os-brick:
  Fix Released
Status in os-net-config:
  In Progress
Status in os-testr:
  In Progress
Status in oslo.cache:
  Fix Released
Status in oslo.messaging:
  Fix Released
Status in Packstack:
  Fix Released
Status in python-barbicanclient:
  In Progress
Status in python-ceilometerclient:
  Fix Released
Status in python-novaclient:
  Fix Released
Status in python-openstackclient:
  Fix Released
Status in OpenStack SDK:
  Fix Released
Status in Rally:
  Fix Released
Status in refstack:
  In Progress
Status in requests-mock:
  In Progress
Status in Sahara:
  Fix Released
Status in shaker:
  Fix Released
Status in Solum:
  Fix Released
Status in Stackalytics:
  Fix Released
Status in OpenStack Object Storage (swift):
  In Progress
Status in tempest:
  In Progress
Status in Trove:
  Fix Released
Status in Vitrage:
  Fix Released
Status in watcher:
  Fix Released
Status in zaqar:
  Fix Released

Bug description:
  Manila  should use the specific assertion:

self.assertIsTrue/False(observed)

  instead of the generic assertion:

self.assertEqual(True/False, observed)

To manage notifications about this bug go to:
https://bugs.launchpad.net/aodh/+bug/1512207/+subscriptions

-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 1368661] Re: Unit tests sometimes fail because of stale pyc files

2016-02-22 Thread Davanum Srinivas (DIMS) 
** No longer affects: oslo.log

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Compute (nova).
https://bugs.launchpad.net/bugs/1368661

Title:
  Unit tests sometimes fail because of stale pyc files

Status in congress:
  Fix Released
Status in Gnocchi:
  Invalid
Status in Ironic:
  Fix Released
Status in Magnum:
  Fix Released
Status in Mistral:
  Fix Released
Status in Monasca:
  Fix Committed
Status in OpenStack Compute (nova):
  Fix Released
Status in OpenStack Compute (nova) icehouse series:
  Fix Released
Status in oslo.cache:
  Invalid
Status in oslo.concurrency:
  Invalid
Status in oslo.service:
  Fix Committed
Status in python-cinderclient:
  Fix Released
Status in python-congressclient:
  Fix Released
Status in python-cueclient:
  Fix Released
Status in python-glanceclient:
  In Progress
Status in python-heatclient:
  Fix Committed
Status in python-keystoneclient:
  Fix Released
Status in python-magnumclient:
  Fix Released
Status in python-mistralclient:
  Fix Committed
Status in python-neutronclient:
  Fix Released
Status in Python client library for Sahara:
  Fix Committed
Status in python-solumclient:
  Fix Released
Status in python-swiftclient:
  Fix Released
Status in python-troveclient:
  Fix Committed
Status in Python client library for Zaqar:
  Fix Committed
Status in Solum:
  Fix Released
Status in OpenStack Object Storage (swift):
  In Progress
Status in Trove:
  Fix Released
Status in zaqar:
  Fix Released

Bug description:
  Because python creates pyc files during tox runs, certain changes in
  the tree, like deletes of files, or switching branches, can create
  spurious errors. This can be suppressed by PYTHONDONTWRITEBYTECODE=1
  in the tox.ini.

To manage notifications about this bug go to:
https://bugs.launchpad.net/congress/+bug/1368661/+subscriptions

-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 1529836] Re: Fix deprecated library function (os.popen()).

2016-02-22 Thread Davanum Srinivas (DIMS) 
** No longer affects: oslo-incubator

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1529836

Title:
  Fix deprecated library function (os.popen()).

Status in bilean:
  In Progress
Status in Blazar:
  In Progress
Status in Ceilometer:
  In Progress
Status in ceilometer-powervm:
  Fix Released
Status in Cinder:
  In Progress
Status in congress:
  In Progress
Status in devstack:
  In Progress
Status in Glance:
  In Progress
Status in glance_store:
  Fix Released
Status in group-based-policy-specs:
  In Progress
Status in heat:
  Fix Released
Status in OpenStack Dashboard (Horizon):
  In Progress
Status in horizon-cisco-ui:
  In Progress
Status in OpenStack Identity (keystone):
  Fix Released
Status in keystoneauth:
  Fix Released
Status in keystonemiddleware:
  Fix Released
Status in Kwapi:
  In Progress
Status in Manila:
  Fix Released
Status in Murano:
  Fix Released
Status in networking-powervm:
  Fix Released
Status in neutron:
  Fix Released
Status in OpenStack Compute (nova):
  Fix Released
Status in nova-powervm:
  Fix Released
Status in python-heatclient:
  Fix Released
Status in python-keystoneclient:
  Fix Released
Status in Python client library for Zaqar:
  In Progress
Status in Sahara:
  Fix Released
Status in senlin:
  Fix Released
Status in OpenStack Object Storage (swift):
  In Progress
Status in tempest:
  Fix Released

Bug description:
  Deprecated library function os.popen is still in use at some places.
  Need to replace it using subprocess module.

To manage notifications about this bug go to:
https://bugs.launchpad.net/bilean/+bug/1529836/+subscriptions

-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 1479066] Re: DeprecationWarning: BaseException.message has been deprecated as of Python 2.6

2016-02-22 Thread Davanum Srinivas (DIMS) 
** Changed in: oslo.vmware
   Status: In Progress => Fix Released

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Compute (nova).
https://bugs.launchpad.net/bugs/1479066

Title:
  DeprecationWarning: BaseException.message has been deprecated as of
  Python 2.6

Status in OpenStack Compute (nova):
  Fix Released
Status in oslo.vmware:
  Fix Released

Bug description:
  I see these when running tests:

  Captured stderr:
  
  nova/virt/libvirt/volume/volume.py:392: DeprecationWarning: 
BaseException.message has been deprecated as of Python 2.6
if ('device is busy' in exc.message or

  Seems that bug 1447946 was meant to fix some of this but it only
  handles NovaException, not other usage.

  We should be able to use six.text_type(e) for 'if str in e' type
  checks.

  
http://logstash.openstack.org/#eyJzZWFyY2giOiJtZXNzYWdlOlwiRGVwcmVjYXRpb25XYXJuaW5nOiBCYXNlRXhjZXB0aW9uLm1lc3NhZ2UgaGFzIGJlZW4gZGVwcmVjYXRlZCBhcyBvZiBQeXRob24gMi42XCIgQU5EIHByb2plY3Q6XCJvcGVuc3RhY2svbm92YVwiIiwiZmllbGRzIjpbXSwib2Zmc2V0IjowLCJ0aW1lZnJhbWUiOiI2MDQ4MDAiLCJncmFwaG1vZGUiOiJjb3VudCIsInRpbWUiOnsidXNlcl9pbnRlcnZhbCI6MH0sInN0YW1wIjoxNDM4MTA2MTkwOTI3fQ==

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1479066/+subscriptions

-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 1276694] Re: Openstack services should support SIGHUP signal

2016-02-22 Thread Davanum Srinivas (DIMS) 
** Changed in: oslo.config
   Status: New => Fix Released

** Changed in: oslo.log
   Status: New => Fix Released

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1276694

Title:
  Openstack services should support SIGHUP signal

Status in Cinder:
  New
Status in Glance:
  Fix Released
Status in heat:
  Fix Released
Status in OpenStack Identity (keystone):
  Invalid
Status in Murano:
  Confirmed
Status in neutron:
  In Progress
Status in OpenStack Compute (nova):
  Fix Released
Status in oslo-incubator:
  Invalid
Status in oslo.config:
  Fix Released
Status in oslo.log:
  Fix Released
Status in oslo.service:
  Fix Released
Status in Sahara:
  In Progress

Bug description:
  1)In order to more effectively manage the unlinked and open (lsof +L1)
  log files descriptors w/o restarting the services, SIGHUP signal
  should be accepted by every Openstack service.

  That would allow, e.g. logrotate jobs to gracefully HUP services after
  their log files were rotated. The only option we have for now is to
  force the services restart, quite a poor option from the services
  continuous accessibility PoV.

  Note: according to  http://en.wikipedia.org/wiki/Unix_signal
  SIGHUP
     ... Many daemons will reload their configuration files and reopen their 
logfiles instead of exiting when receiving this signal.

  Currently Murano and Glance are out of sync with Oslo SIGHUP support.

  There is also the following issue exists for some of the services of OS 
projects with synced SIGHUP support:
  2)
  heat-api-cfn, heat-api, heat-api-cloudwatch, keystone:  looks like the synced 
code is never being executed, thus SIGHUP is not supported for them. Here is a 
simple test scenario:
  2.1) modify 
/site-packages//openstack/common/service.py
  def _sighup_supported():
  +LOG.warning("SIGHUP is supported: {0}".format(hasattr(signal, 'SIGHUP')))
  return hasattr(signal, 'SIGHUP')
  2.2) restart service foo-service-name and check logs for "SIGHUP is 
supported", if service  really supports it, the appropriate messages would be 
present in the logs.
  2.3) issue kill -HUP  and check logs for "SIGHUP is 
supported" and "Caught SIGHUP", if service  really supports it, the appropriate 
messages would be present in the logs. Besides that, the service should remain 
started and its main thread PID should not be changed.

  e.g.
  2.a) heat-engine supports HUPing:
  #service openstack-heat-engine restart
  <132>Apr 11 14:03:48 node-3 heat-heat.openstack.common.service WARNING: 
SIGHUP is supported: True

  2.b)But heat-api don't know how to HUP:
  #service openstack-heat-api restart
  <134>Apr 11 14:06:22 node-3 heat-heat.api INFO: Starting Heat ReST API on 
0.0.0.0:8004
  <134>Apr 11 14:06:22 node-3 heat-eventlet.wsgi.server INFO: Starting single 
process server

  2.c) HUPing heat-engine is OK
  #pid=$(cat /var/run/heat/openstack-heat-engine.pid); kill -HUP $pid && echo 
$pid
  16512
  <134>Apr 11 14:12:15 node-3 heat-heat.openstack.common.service INFO: Caught 
SIGHUP, exiting
  <132>Apr 11 14:12:15 node-3 heat-heat.openstack.common.service WARNING: 
SIGHUP is supported: True
  <134>Apr 11 14:12:15 node-3 heat-heat.openstack.common.rpc.common INFO: 
Connected to AMQP server on ...
  service openstack-heat-engine status
  openstack-heat-engine (pid  16512) is running...

  2.d) HUPed heat-api is dead now ;(
  #kill -HUP $(cat /var/run/heat/openstack-heat-api.pid)
  (no new logs)
  # service openstack-heat-api status
  openstack-heat-api dead but pid file exists

  3)
  nova-cert, nova-novncproxy, nova-objectstore, nova-consoleauth, 
nova-scheduler - unlike to case 2, after kill -HUP  command 
was issued, there would be a "Caught SIGHUP" message in the logs, BUT the 
associated service would have got dead anyway. Instead, the service should 
remain started and its main thread PID should not be changed (similar to the 
2.c case).

  So, looks like there are a lot of things still should be done to
  ensure POSIX standards abidance in Openstack :-)

To manage notifications about this bug go to:
https://bugs.launchpad.net/cinder/+bug/1276694/+subscriptions

-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 1538204] Re: Failed to stop nova-api in grenade tests

2016-02-18 Thread Davanum Srinivas (DIMS) 
16 hits in last week for message:"dictionary changed size during
iteration" logstash query. Only one of them is a FAILURE though
unrelated to this bug.

-- Dims

** Changed in: oslo.service
   Status: Confirmed => Invalid

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Compute (nova).
https://bugs.launchpad.net/bugs/1538204

Title:
  Failed to stop nova-api in grenade tests

Status in OpenStack Compute (nova):
  Invalid
Status in oslo.service:
  Invalid

Bug description:
  Saw this during a grenade run:

  2016-01-26 16:12:58.553 22016 ERROR oslo_service.threadgroup   File 
"/usr/local/lib/python2.7/dist-packages/oslo_service/service.py", line 143, in 
clear
  2016-01-26 16:12:58.553 22016 ERROR oslo_service.threadgroup for sig in 
self._signal_handlers:
  2016-01-26 16:12:58.553 22016 ERROR oslo_service.threadgroup RuntimeError: 
dictionary changed size during iteration

  (From http://logs.openstack.org/25/272425/1/gate/gate-grenade-dsvm-
  heat/b32eda2/).

  May be due to a change in oslo, but it's in the old process so I'm not
  sure it ought to use it.

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1538204/+subscriptions

-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

Re: [openstack-dev] [all][infra] eventlet 0.18.1 not on PyPi anymore

2016-02-17 Thread Davanum Srinivas 
I'd support this,

Last known version is https://pypi.python.org/pypi/eventlet/0.17.4

-- Dims

On Wed, Feb 17, 2016 at 8:42 AM, Doug Hellmann <d...@doughellmann.com> wrote:
> Excerpts from Victor Stinner's message of 2016-02-17 14:14:18 +0100:
>> Le 17/02/2016 13:43, Henry Gessau a écrit :
>> > And it looks like eventlet 0.18.3 breaks neutron:
>> > https://bugs.launchpad.net/neutron/+bug/1546506
>>
>> 2 releases, 2 regressions in OpenStack. Should we cap eventlet version?
>> The requirement bot can produce patches to update eventlet, patches
>> which would run integration tests using Nova, Keystone, Neutron on the
>> new eventlet version.
>>
>> eventlet 0.18.2 broke OpenStack Keystone and OpenStack Nova
>> https://github.com/eventlet/eventlet/issues/296
>> https://github.com/eventlet/eventlet/issues/299
>> https://review.openstack.org/#/c/278147/
>> https://bugs.launchpad.net/nova/+bug/1544801
>>
>> eventlet 0.18.3 broke OpenStack Neutron
>> https://github.com/eventlet/eventlet/issues/301
>> https://bugs.launchpad.net/neutron/+bug/1546506
>>
>> FYI eventlet 0.18.0 broke WSGI servers:
>> https://github.com/eventlet/eventlet/issues/295
>>
>> It was followed quickly by eventlet 0.18.2 to fix this issue.
>>
>> Sadly, it looks like bugfix releases of eventlet don't include a single
>> bugfix, but include also other changes. For example, 0.18.3 fixed the
>> bug #296 but introduced "wsgi: TCP_NODELAY enabled by default" optimization.
>>
>> IMHO the problem is not the release manager of eventlet, but more the
>> lack of tests on eventlet, especially on OpenStack services.
>>
>> Current "Continious Delivery"-like with gates do detect bugs, yeah, but
>> also block a lot of developers when the gates are broken. It doesn't
>> seem trivial to investigate and fix eventlet issues.
>>
>> Victor
>>
>
> Whether we cap or not, we should exclude the known broken versions.
> It looks like getting back to a good version will also require
> lowering the minimum version we support, since we have >=0.18.2
> now.
>
> What was the last version of eventlet known to work?
>
> Doug
>
> __
> 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



-- 
Davanum Srinivas :: https://twitter.com/dims

__
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

[Yahoo-eng-team] [Bug 1532809] Re: Gate failures when DHCP lease cannot be acquired

2016-02-16 Thread Davanum Srinivas (DIMS) 
** Changed in: nova
   Status: In Progress => Fix Released

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Compute (nova).
https://bugs.launchpad.net/bugs/1532809

Title:
  Gate failures when DHCP lease cannot be acquired

Status in OpenStack Compute (nova):
  Fix Released
Status in OpenStack Compute (nova) kilo series:
  In Progress
Status in OpenStack Compute (nova) liberty series:
  In Progress

Bug description:
  Example from:
  
http://logs.openstack.org/97/265697/1/check/gate-grenade-dsvm/6eeced7/console.html#_2016-01-11_07_42_30_838

  Logstash query:
  message:"No lease, failing" AND voting:1

  dhcp_release for an ip/mac does not seem to reach dnsmasq (or it fails
  to act on it - "unknown lease") as i don't see entries in syslog for
  it.

  Logs from nova network:
  dims@dims-mac:~/junk/6eeced7$ grep dhcp_release old/screen-n-net.txt.gz | 
grep 10.1.0.3 | grep CMD
  2016-01-11 07:25:35.548 DEBUG oslo_concurrency.processutils 
[req-62aaa0b9-093e-4f28-805d-d4bf3008bfe6 tempest-ServersTestJSON-1206086292 
tempest-ServersTestJSON-1551541405] CMD "sudo nova-rootwrap 
/etc/nova/rootwrap.conf dhcp_release br100 10.1.0.3 fa:16:3e:32:51:c3" 
returned: 0 in 0.117s execute 
/usr/local/lib/python2.7/dist-packages/oslo_concurrency/processutils.py:297
  2016-01-11 07:25:51.259 DEBUG oslo_concurrency.processutils 
[req-31115ffa-8d43-4621-bb2e-351d6cd4bcef 
tempest-ServerActionsTestJSON-357128318 
tempest-ServerActionsTestJSON-854742699] CMD "sudo nova-rootwrap 
/etc/nova/rootwrap.conf dhcp_release br100 10.1.0.3 fa:16:3e:a4:f0:11" 
returned: 0 in 0.108s execute 
/usr/local/lib/python2.7/dist-packages/oslo_concurrency/processutils.py:297
  2016-01-11 07:26:35.357 DEBUG oslo_concurrency.processutils 
[req-c32a216e-d909-41a0-a0bc-d5eb7a21c048 
tempest-TestVolumeBootPattern-46217374 
tempest-TestVolumeBootPattern-1056816637] CMD "sudo nova-rootwrap 
/etc/nova/rootwrap.conf dhcp_release br100 10.1.0.3 fa:16:3e:ed:de:f6" 
returned: 0 in 0.110s execute 
/usr/local/lib/python2.7/dist-packages/oslo_concurrency/processutils.py:297

  Logs from syslog:
  dims@dims-mac:~/junk$ grep 10.1.0.3 syslog.txt.gz
  Jan 11 07:25:35 devstack-trusty-rax-iad-7090830 dnsmasq-dhcp[7798]: 
DHCPRELEASE(br100) 10.1.0.3 fa:16:3e:32:51:c3 unknown lease
  Jan 11 07:25:51 devstack-trusty-rax-iad-7090830 dnsmasq-dhcp[7798]: 
DHCPRELEASE(br100) 10.1.0.3 fa:16:3e:a4:f0:11 unknown lease
  Jan 11 07:26:24 devstack-trusty-rax-iad-7090830 dnsmasq-dhcp[7798]: 
DHCPOFFER(br100) 10.1.0.3 fa:16:3e:ed:de:f6
  Jan 11 07:26:24 devstack-trusty-rax-iad-7090830 dnsmasq-dhcp[7798]: 
DHCPREQUEST(br100) 10.1.0.3 fa:16:3e:ed:de:f6
  Jan 11 07:26:24 devstack-trusty-rax-iad-7090830 dnsmasq-dhcp[7798]: 
DHCPACK(br100) 10.1.0.3 fa:16:3e:ed:de:f6 tempest
  Jan 11 07:27:34 devstack-trusty-rax-iad-7090830 object-auditor: Object audit 
(ALL). Since Mon Jan 11 07:27:34 2016: Locally: 1 passed, 0 quarantined, 0 
errors files/sec: 2.03 , bytes/sec: 10119063.16, Total time: 0.49, Auditing 
time: 0.00, Rate: 0.00
  Jan 11 07:39:12 devstack-trusty-rax-iad-7090830 dnsmasq-dhcp[7798]: not using 
configured address 10.1.0.3 because it is leased to fa:16:3e:ed:de:f6
  Jan 11 07:40:12 devstack-trusty-rax-iad-7090830 dnsmasq-dhcp[7798]: not using 
configured address 10.1.0.3 because it is leased to fa:16:3e:ed:de:f6
  Jan 11 07:41:12 devstack-trusty-rax-iad-7090830 dnsmasq-dhcp[7798]: not using 
configured address 10.1.0.3 because it is leased to fa:16:3e:ed:de:f6
  Jan 11 07:42:26 devstack-trusty-rax-iad-7090830 dnsmasq-dhcp[7798]: 
DHCPRELEASE(br100) 10.1.0.3 fa:16:3e:fe:1f:36 unknown lease

  Net, The test that runs the ssh against the vm fails with the "No
  lease, failing" in its serial console

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1532809/+subscriptions

-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

Re: [openstack-dev] [nova][glance][barbican][kite][requirements] pycrypto vs pycryptodome

2016-02-15 Thread Davanum Srinivas 
Douglas,

Which means we should make sure pysaml2 and paramiko do switch to the
" pyca/cryptography" ASAP. However, what do we do in the mean time?

-- Dims

On Mon, Feb 15, 2016 at 1:30 PM, Douglas Mendizábal
<douglas.mendiza...@rackspace.com> wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
> One more thing: I forgot to point out that pyca/cryptography is
> already part of global-requirements. [1]
>
> - - Douglas Mendizábal
>
> [1]
> http://git.openstack.org/cgit/openstack/requirements/tree/global-require
> ments.txt#n25
>
> On 2/15/16 12:24 PM, Douglas Mendizábal wrote:
>> I had not previously heard of pycryptodome. Is this supposed to be
>> a drop-in replacement for pycrypto?  If so then it sounds like
>> they're doing a terrible job of it.
>>
>> The plan for Barbican has been to wait for pyca/cryptography [1] to
>> add support for the apis we needed to be able to drop our pycrypto
>> dependency.  I'll have to double check the latest pyca/cryptography
>> notes, but I do believe it's at a point now where it can be used in
>> Barbican to replace pycrypto. This would be the preferred fix for
>> us.
>>
>> AFAIK the paramiko folks were going to adopt pyca/cryptography as
>> well, so it appears that pycryptodome support will not be merged
>> there either. [2]
>>
>> Additionaly, bespoke pure-python cryptography gives me the heebie
>> jeebies, so I would strongly recommend to move all cryptographic
>> work to use pyca/cryptography instead of pycryptodome.
>>
>> - Douglas Mendizábal
>>
>> [1] https://cryptography.io/en/latest/ [2]
>> https://github.com/paramiko/paramiko/pull/646
>>
>> On 2/15/16 6:44 AM, Haïkel wrote:
>>> 2016-02-14 23:16 GMT+01:00 Davanum Srinivas <dava...@gmail.com>:
>>>> Hi,
>>>>
>>>> Short Story: pycryptodome if installed inadvertently will
>>>> break several projects: Example :
>>>> https://review.openstack.org/#/c/279926/
>>>>
>>>> Long Story: There's a new kid in town pycryptodome:
>>>> https://github.com/Legrandin/pycryptodome
>>>>
>>>> Because pycrypto itself has not been maintained for a while:
>>>> https://github.com/dlitz/pycrypto
>>>>
>>>> So folks like pysaml2 and paramiko are trying to switch over:
>>>> https://github.com/rohe/pysaml2/commit/0e4f5fa48b1965b269f69bd383bbf
> b
>>
>>>>
>>>>
> de6b41ac63
>>>>
>>>>
>>>>
>>>>
>> https://github.com/paramiko/paramiko/issues/637
>>>>
>>>> In fact pysaml2===4.0.3 has already switched over. So the
>>>> requirements bot/script has been trying to alert us to this
>>>> new dependency, you can see Nova fail.
>>>> https://review.openstack.org/#/c/279926/
>>>>
>>>> Why does it fail? For example, the new library is strict about
>>>> getting bytes for keys and has dropped some parameters in
>>>> methods. for example:
>>>> https://github.com/Legrandin/pycryptodome/blob/master/lib/Crypto/Pub
> l
>>
>>>>
>>>>
> icKey/RSA.py#L405
>>>>
>>>>
>>>>
>>>>
>> https://github.com/dlitz/pycrypto/blob/master/lib/Crypto/PublicKey/RSA
> .p
>>
>>
>>
> y#L499
>>>>
>>>> Another problem, if pycrypto gets installed last then things
>>>> will work, if it pycryptodome gets installed last, things will
>>>>  fail. So we definitely cannot allow both in our
>>>> global-requirements and upper-constraints. We can always try to
>>>> pin stuff, but things will fail as there are a lot of jobs that
>>>> do not honor upper-constraints. And things will fail in the
>>>> field for Mitaka.
>>>>
>>>> Action: So what can we do? One possibility is to pin
>>>> requirements and hope for the best. Another is to tolerate the
>>>> install of either pycrypto or pycryptodome and test both
>>>> combinations so we don't have to fight this battle.
>>>>
>>>> Example for Nova : https://review.openstack.org/#/c/279909/
>>>> Example for Glance : https://review.openstack.org/#/c/280008/
>>>> Example for Barbican :
>>>> https://review.openstack.org/#/c/280014/
>>>>
>>>> What do you think?
>>>>
>>>> Thanks, Dims
>>>>
>>
>>> This is annoying from a packaging PoV.
>>
>>> We have dependencies relyi

[openstack-dev] [nova][glance][barbican][kite][requirements] pycrypto vs pycryptodome

2016-02-14 Thread Davanum Srinivas 
Hi,

Short Story:
pycryptodome if installed inadvertently will break several projects:
Example : https://review.openstack.org/#/c/279926/

Long Story:
There's a new kid in town pycryptodome:
https://github.com/Legrandin/pycryptodome

Because pycrypto itself has not been maintained for a while:
https://github.com/dlitz/pycrypto

So folks like pysaml2 and paramiko are trying to switch over:
https://github.com/rohe/pysaml2/commit/0e4f5fa48b1965b269f69bd383bbfbde6b41ac63
https://github.com/paramiko/paramiko/issues/637

In fact pysaml2===4.0.3 has already switched over. So the requirements
bot/script has been trying to alert us to this new dependency, you can
see Nova fail.
https://review.openstack.org/#/c/279926/

Why does it fail? For example, the new library is strict about getting
bytes for keys and has dropped some parameters in methods. for
example:
https://github.com/Legrandin/pycryptodome/blob/master/lib/Crypto/PublicKey/RSA.py#L405
https://github.com/dlitz/pycrypto/blob/master/lib/Crypto/PublicKey/RSA.py#L499

Another problem, if pycrypto gets installed last then things will
work, if it pycryptodome gets installed last, things will fail. So we
definitely cannot allow both in our global-requirements and
upper-constraints. We can always try to pin stuff, but things will
fail as there are a lot of jobs that do not honor upper-constraints.
And things will fail in the field for Mitaka.

Action:
So what can we do? One possibility is to pin requirements and hope for
the best. Another is to tolerate the install of either pycrypto or
pycryptodome and test both combinations so we don't have to fight this
battle.

Example for Nova : https://review.openstack.org/#/c/279909/
Example for Glance : https://review.openstack.org/#/c/280008/
Example for Barbican : https://review.openstack.org/#/c/280014/

What do you think?

Thanks,
Dims


-- 
Davanum Srinivas :: https://twitter.com/dims

__
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

[Yahoo-eng-team] [Bug 1545370] Re: pycryptodome breaks nova/barbican/glance/kite

2016-02-14 Thread Davanum Srinivas (DIMS) 
Here's the evidence:
Barbican - https://review.openstack.org/#/c/279977/
Glance - https://review.openstack.org/#/c/279979/
Kite - https://review.openstack.org/#/c/279984/
Kite client - https://review.openstack.org/#/c/279985/


** Summary changed:

- pycryptodome breaks nova 
+ pycryptodome breaks nova/barbican/glance/kite

** Also affects: barbican
   Importance: Undecided
   Status: New

** Also affects: glance
   Importance: Undecided
   Status: New

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Compute (nova).
https://bugs.launchpad.net/bugs/1545370

Title:
  pycryptodome breaks nova/barbican/glance/kite

Status in Barbican:
  New
Status in Glance:
  New
Status in OpenStack Compute (nova):
  In Progress

Bug description:
  pysaml2===4.0.3 drags in pycryptodome===3.4 which breaks Nova in the
  both unit tests and grenade.

  nova.tests.unit.test_crypto.KeyPairTest.test_generate_key_pair_1024_bits
  

  Captured traceback:
  ~~~
  Traceback (most recent call last):
File "nova/tests/unit/test_crypto.py", line 352, in 
test_generate_key_pair_1024_bits
  (private_key, public_key, fingerprint) = 
crypto.generate_key_pair(bits)
File "nova/crypto.py", line 165, in generate_key_pair
  key = paramiko.RSAKey.generate(bits)
File 
"/Users/dims/openstack/openstack/nova/.tox/py27/lib/python2.7/site-packages/paramiko/rsakey.py",
 line 146, in generate
  rsa = RSA.generate(bits, os.urandom, progress_func)
File 
"/Users/dims/openstack/openstack/nova/.tox/py27/lib/python2.7/site-packages/Crypto/PublicKey/RSA.py",
 line 436, in generate
  if e % 2 == 0 or e < 3:
  TypeError: unsupported operand type(s) for %: 'NoneType' and 'int'

To manage notifications about this bug go to:
https://bugs.launchpad.net/barbican/+bug/1545370/+subscriptions

-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 1545370] [NEW] pycryptodome breaks nova

2016-02-13 Thread Davanum Srinivas (DIMS) 
Public bug reported:

pysaml2===4.0.3 drags in pycryptodome===3.4 which breaks Nova in the
both unit tests and grenade.

nova.tests.unit.test_crypto.KeyPairTest.test_generate_key_pair_1024_bits


Captured traceback:
~~~
Traceback (most recent call last):
  File "nova/tests/unit/test_crypto.py", line 352, in 
test_generate_key_pair_1024_bits
(private_key, public_key, fingerprint) = crypto.generate_key_pair(bits)
  File "nova/crypto.py", line 165, in generate_key_pair
key = paramiko.RSAKey.generate(bits)
  File 
"/Users/dims/openstack/openstack/nova/.tox/py27/lib/python2.7/site-packages/paramiko/rsakey.py",
 line 146, in generate
rsa = RSA.generate(bits, os.urandom, progress_func)
  File 
"/Users/dims/openstack/openstack/nova/.tox/py27/lib/python2.7/site-packages/Crypto/PublicKey/RSA.py",
 line 436, in generate
if e % 2 == 0 or e < 3:
TypeError: unsupported operand type(s) for %: 'NoneType' and 'int'

** Affects: nova
 Importance: Undecided
 Status: New

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Compute (nova).
https://bugs.launchpad.net/bugs/1545370

Title:
  pycryptodome breaks nova

Status in OpenStack Compute (nova):
  New

Bug description:
  pysaml2===4.0.3 drags in pycryptodome===3.4 which breaks Nova in the
  both unit tests and grenade.

  nova.tests.unit.test_crypto.KeyPairTest.test_generate_key_pair_1024_bits
  

  Captured traceback:
  ~~~
  Traceback (most recent call last):
File "nova/tests/unit/test_crypto.py", line 352, in 
test_generate_key_pair_1024_bits
  (private_key, public_key, fingerprint) = 
crypto.generate_key_pair(bits)
File "nova/crypto.py", line 165, in generate_key_pair
  key = paramiko.RSAKey.generate(bits)
File 
"/Users/dims/openstack/openstack/nova/.tox/py27/lib/python2.7/site-packages/paramiko/rsakey.py",
 line 146, in generate
  rsa = RSA.generate(bits, os.urandom, progress_func)
File 
"/Users/dims/openstack/openstack/nova/.tox/py27/lib/python2.7/site-packages/Crypto/PublicKey/RSA.py",
 line 436, in generate
  if e % 2 == 0 or e < 3:
  TypeError: unsupported operand type(s) for %: 'NoneType' and 'int'

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1545370/+subscriptions

-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

Re: [openstack-dev] [gate] RFC dropping largeops tests

2016-02-10 Thread Davanum Srinivas 
+1 from me

On Wed, Feb 10, 2016 at 7:56 AM, Jay Pipes <jaypi...@gmail.com> wrote:
> On 02/10/2016 07:33 AM, Sean Dague wrote:
>>
>> The largeops tests at this point are mostly finding out that some of our
>> new cloud providers are slow - http://tinyurl.com/j5u4nf5
>>
>> This is fundamentally a performance test, with timings having been tuned
>> to pass 98% of the time on two clouds that were very predictable in
>> performance. We're now running on 4 clouds, and the variance between
>> them all, and between every run on each can be as much as a factor of 2.
>>
>> We could just bump all the timeouts again, but that's basically the same
>> thing as dropping them.
>>
>> These tests are not instrumented in a way that any real solution can be
>> addressed in most cases. Tests without a path forward, that are failing
>> good patches a lot, are very much the kind of thing we should remove
>> from the system.
>
>
> +1 from me.
>
> -jay
>
> __
> 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



-- 
Davanum Srinivas :: https://twitter.com/dims

__
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] Mock and the stdlib

2016-02-10 Thread Davanum Srinivas 
I've fast tracked the revert - https://review.openstack.org/#/c/278814/

On Wed, Feb 10, 2016 at 9:38 PM, Robert Collins
<robe...@robertcollins.net> wrote:
> We've just had a mass gate breakage due to
> https://review.openstack.org/#/c/268945/ go through, so I thought I'd
> try to get ahead of anyone trying this again.
>
> unittest.mock in the stdlib is not static, it evolves over time. We're
> currently writing to - and depending on - the unittest.mock version
> approximately == that in python 3.5. Until we have that as our minimum
> python version - no 2.7 - we can't just use 'unittest.mock'.
>
> 'mock', the original code that became unittest.mock, is still
> maintained. Its a rolling backport of the features that land in
> Python's stdlib, which lets us use newer features on older pythons. So
> - until the hypothetical date where our minimum Python version is
> newer than the oldest capability we need from unittest.mock, we're
> going to be using 'mock', not 'unittest.mock'.
>
> -> noone should be importing 'unittest.mock', and 'mock' is the
> dependency, not conditional on any given version of Python.
>
> I'm sorry I didn't spot 268945 going through, or I would have -2'd it :(.
>
> -Rob
>
> --
> Robert Collins <rbtcoll...@hpe.com>
> Distinguished Technologist
> HP Converged Cloud
>
> __
> 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



-- 
Davanum Srinivas :: https://twitter.com/dims

__
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 hail the new per-region pypi, wheel and apt mirrors

2016-02-10 Thread Davanum Srinivas 
w00t! thanks infra team

On Wed, Feb 10, 2016 at 7:45 PM, Monty Taylor <mord...@inaugust.com> wrote:
> Hey everybody,
>
> tl;dr - We have new AFS-based consistent per-region mirrors of PyPI and APT
> repos with additional wheel repos containing pre-built wheels for all the
> modules in global-requirements
>
> We've just rolled out a new change that you should mostly never notice -
> except that jobs should be a bit faster and more reliable.
>
> The underpinning of the new mirrors is AFS, which is a global distributed
> filesystem developed by Carnegie Mellon back in the 1980's. In a lovely fit
> of old-is-new-again, the challenges that software had to deal with in the
> 80s (flaky networks, frequent computer failures) mirror life in the cloud
> pretty nicely, and the engineering work to solve them winds up being quite
> relevant.
>
> One of the nice things we get from AFS is the ability to do atomic
> consistent releases of new filesystem snapshots to read-only replicas. That
> means we can build a new version of our mirror content, check it for
> consistency, and then release it for consumption to all of the consumers at
> the same time. That's important for the gate, because our "package not
> found" errors are usually about the mirror state shifting during a test job
> run.
>
> We've had per-region PyPI mirrors for quite some time (and indeed the gate
> would largely be dead in the water without them). The improvement from this
> work for them is that they're now AFS based, so we should never have a
> visible mirror state that's wonky or inconsistent between regions, and we
> can more easily expand into new cloud regions.
>
> We've added per-region apt mirrors (with yum to come soon) to the mix based
> on the same concept - we build the new mirror state then release it. There
> is one additional way that apt can fail even with consistent mirror states,
> which is that apt repos purge old versions of packages that are no longer
> referenced. If a new mirror state rolls out between the time devstack runs
> apt-get update and the time it tries to do apt-get install of something, you
> can get a situation where apt is trying to install a version of a package
> that is no longer present in the archive. To mitigate this, we're purging
> our mirror on a delay ... in our mirror runs every 2 hours we add new
> packages and update the index, and then in the next mirror run we'll delete
> the packages the previous run made unreferenced. This should make apt errors
> about package not found go away.
>
> Last but certainly not least, there are now also wheel repositories of
> wheels built for all of our python packages from global-requirements. This
> is a speed increase and shaves 1.8 tens of minutes off of  a normal devstack
> run.
>
> With these changes, it means we're writing not only pip.conf but now
> sources.list files into the test nodes. If you happen to be doing extra
> special things with either of those in your jobs, you'll want to make sure
> you consume the config files we're laying down
>
> Finally, although all Infra projects are a team effort - a big shout out to
> Michael Krotschek and Jim Blair for diving in and getting this finished over
> the past couple of weeks.
>
> Monty
>
> __
> 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



-- 
Davanum Srinivas :: https://twitter.com/dims

__
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][infra] eventlet 0.18.1 not on PyPi anymore

2016-02-09 Thread Davanum Srinivas 
Monty,

I asked for details and got a response here:
https://github.com/eventlet/eventlet/commit/5bf0a6f32b3e4459b38ad1895c9eb4b0b483dae1#commitcomment-15987613

-- Dims

On Tue, Feb 9, 2016 at 2:05 PM, Monty Taylor <mord...@inaugust.com> wrote:
> On 02/09/2016 12:24 PM, McLellan, Steven wrote:
>>
>>  From the list of versions that are there
>> (https://pypi.python.org/simple/eventlet/), it appears that for a given
>> major version only the most recent release is kept, so this will likely
>> reoccur when/if 0.18.3 is released.
>
>
> Anybody know anybody in eventlet land who we could talk to about their
> release process? PyPI will automatically hide old releases for them, so
> there is really no need to delete previous point releases (and as we all
> know this causes OpenStack considerable pain)
>
>
>> On 2/9/16, 10:44 AM, "Markus Zoeller" <mzoel...@de.ibm.com> wrote:
>>
>>> For the sake of completeness: The eventlet package version 0.18.1
>>> seems to be disappeared from the PyPi servers, which is a bad thing,
>>> as we use that version in the "upper-constraints.txt" of the
>>> requirements project. There is patch [1] in the queue which solves that.
>>> Until this is merged, there is a change that our CI (and your third-party
>>> CI) will break after the locally cached version in the CI vanishes.
>>>
>>> References:
>>> [1] https://review.openstack.org/#/c/277912/
>>>
>>> Regards, Markus Zoeller (markus_z)
>>>
>>>
>>>
>>> __
>>> 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



-- 
Davanum Srinivas :: https://twitter.com/dims

__
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

[Python-jenkins-developers] [Bug 1526170] Fix included in openstack/osprofiler 1.0.0

2016-02-02 Thread Davanum Srinivas (DIMS) 
This issue was fixed in the openstack/osprofiler 1.0.0 release.

-- 
You received this bug notification because you are a member of Python
Jenkins Developers, which is subscribed to Python Jenkins.
https://bugs.launchpad.net/bugs/1526170

Title:
  Python 3.3 support is being dropped since OpenStack Liberty.

Status in cloudkitty:
  In Progress
Status in Mistral:
  Fix Released
Status in Monasca:
  In Progress
Status in os-testr:
  In Progress
Status in python-cinderclient:
  Fix Released
Status in python-congressclient:
  Fix Released
Status in python-ironicclient:
  Fix Released
Status in Python Jenkins:
  Fix Released
Status in python-keystoneclient-kerberos:
  Fix Released
Status in python-magnumclient:
  Fix Released
Status in python-manilaclient:
  Fix Released
Status in python-mistralclient:
  In Progress
Status in python-neutronclient:
  Fix Released
Status in python-novaclient:
  Fix Released
Status in Python client for HP OneView:
  Fix Released
Status in Python client library for Sahara:
  Fix Released
Status in python-scciclient:
  Fix Released
Status in python-solumclient:
  Fix Released
Status in python-swiftclient:
  In Progress
Status in python-tackerclient:
  In Progress
Status in python-troveclient:
  Fix Released
Status in python-watcherclient:
  Fix Released
Status in Python client library for Zaqar:
  Fix Released
Status in Solum:
  Fix Released
Status in tripleo:
  Fix Released

Bug description:
  It is written in the following URL.

  
https://wiki.openstack.org/wiki/Python3#Python_2:_Python_2.6_support_dropped.2C_Python_2.7_only

  And already the infra team and the oslo team are dropping py33 support
  from their projects.

  Since we rely on oslo for a lot of our work, and depend on infra for
  our CI, we should drop py33 support too.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloudkitty/+bug/1526170/+subscriptions

-- 
Mailing list: https://launchpad.net/~python-jenkins-developers
Post to : python-jenkins-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~python-jenkins-developers
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 1540983] [NEW] Gate failures for neutron in test_dualnet_multi_prefix_slaac

2016-02-02 Thread Davanum Srinivas (DIMS) 
Public bug reported:

24 hits in 7 days for logstash query : message:"in
test_dualnet_multi_prefix_slaac" AND voting:1

2016-02-02 14:35:49.054 | Captured traceback:
2016-02-02 14:35:49.054 | ~~~
2016-02-02 14:35:49.054 | Traceback (most recent call last):
2016-02-02 14:35:49.054 |   File "tempest/test.py", line 113, in wrapper
2016-02-02 14:35:49.055 | return f(self, *func_args, **func_kwargs)
2016-02-02 14:35:49.055 |   File "tempest/scenario/test_network_v6.py", 
line 246, in test_dualnet_multi_prefix_slaac
2016-02-02 14:35:49.055 | dualnet=True)
2016-02-02 14:35:49.055 |   File "tempest/scenario/test_network_v6.py", 
line 155, in _prepare_and_test
2016-02-02 14:35:49.055 | sshv4_1, ips_from_api_1, sid1 = 
self.prepare_server(networks=net_list)
2016-02-02 14:35:49.055 |   File "tempest/scenario/test_network_v6.py", 
line 128, in prepare_server
2016-02-02 14:35:49.055 | username=username)
2016-02-02 14:35:49.056 |   File "tempest/scenario/manager.py", line 390, 
in get_remote_client
2016-02-02 14:35:49.056 | linux_client.validate_authentication()
2016-02-02 14:35:49.056 |   File 
"tempest/common/utils/linux/remote_client.py", line 63, in 
validate_authentication
2016-02-02 14:35:49.056 | self.ssh_client.test_connection_auth()
2016-02-02 14:35:49.056 |   File 
"/opt/stack/new/tempest/.tox/full/local/lib/python2.7/site-packages/tempest_lib/common/ssh.py",
 line 172, in test_connection_auth
2016-02-02 14:35:49.056 | connection = self._get_ssh_connection()
2016-02-02 14:35:49.056 |   File 
"/opt/stack/new/tempest/.tox/full/local/lib/python2.7/site-packages/tempest_lib/common/ssh.py",
 line 87, in _get_ssh_connection
2016-02-02 14:35:49.057 | password=self.password)
2016-02-02 14:35:49.057 | tempest_lib.exceptions.SSHTimeout: Connection to 
the 172.24.5.141 via SSH timed out.
2016-02-02 14:35:49.057 | User: cirros, Password: None

** Affects: neutron
 Importance: Undecided
 Status: New

** Affects: openstack-gate
 Importance: Undecided
 Status: New

** Also affects: neutron
   Importance: Undecided
   Status: New

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1540983

Title:
  Gate failures for neutron in test_dualnet_multi_prefix_slaac

Status in neutron:
  New
Status in OpenStack-Gate:
  New

Bug description:
  24 hits in 7 days for logstash query : message:"in
  test_dualnet_multi_prefix_slaac" AND voting:1

  2016-02-02 14:35:49.054 | Captured traceback:
  2016-02-02 14:35:49.054 | ~~~
  2016-02-02 14:35:49.054 | Traceback (most recent call last):
  2016-02-02 14:35:49.054 |   File "tempest/test.py", line 113, in wrapper
  2016-02-02 14:35:49.055 | return f(self, *func_args, **func_kwargs)
  2016-02-02 14:35:49.055 |   File "tempest/scenario/test_network_v6.py", 
line 246, in test_dualnet_multi_prefix_slaac
  2016-02-02 14:35:49.055 | dualnet=True)
  2016-02-02 14:35:49.055 |   File "tempest/scenario/test_network_v6.py", 
line 155, in _prepare_and_test
  2016-02-02 14:35:49.055 | sshv4_1, ips_from_api_1, sid1 = 
self.prepare_server(networks=net_list)
  2016-02-02 14:35:49.055 |   File "tempest/scenario/test_network_v6.py", 
line 128, in prepare_server
  2016-02-02 14:35:49.055 | username=username)
  2016-02-02 14:35:49.056 |   File "tempest/scenario/manager.py", line 390, 
in get_remote_client
  2016-02-02 14:35:49.056 | linux_client.validate_authentication()
  2016-02-02 14:35:49.056 |   File 
"tempest/common/utils/linux/remote_client.py", line 63, in 
validate_authentication
  2016-02-02 14:35:49.056 | self.ssh_client.test_connection_auth()
  2016-02-02 14:35:49.056 |   File 
"/opt/stack/new/tempest/.tox/full/local/lib/python2.7/site-packages/tempest_lib/common/ssh.py",
 line 172, in test_connection_auth
  2016-02-02 14:35:49.056 | connection = self._get_ssh_connection()
  2016-02-02 14:35:49.056 |   File 
"/opt/stack/new/tempest/.tox/full/local/lib/python2.7/site-packages/tempest_lib/common/ssh.py",
 line 87, in _get_ssh_connection
  2016-02-02 14:35:49.057 | password=self.password)
  2016-02-02 14:35:49.057 | tempest_lib.exceptions.SSHTimeout: Connection 
to the 172.24.5.141 via SSH timed out.
  2016-02-02 14:35:49.057 | User: cirros, Password: None

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1540983/+subscriptions

-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

Re: [openstack-dev] Google Sumer of Code 2016 - Call for ideas and mentors (deadline 19/02/2016)

2016-02-02 Thread Davanum Srinivas 
Victoria,

Thanks for doing this. I've signed up as a Mentor at
https://wiki.openstack.org/wiki/GSoC2016#Mentors

Folks,

This is a great opportunity for students to get to know your
project(s), so please sign up!

Thanks,
Dims


On Mon, Feb 1, 2016 at 1:12 PM, Victoria Martínez de la Cruz
<victo...@vmartinezdelacruz.com> wrote:
> Hi all,
>
> Google Summer of Code (GSoC) is a program that matches mentoring
> organizations with college and university student developers who are paid to
> write open source code. It has been around 2005 and we had been accepted as
> a mentor organization in only one opportunity (2014) having a great outcome
> for both interns and for our community. We expect to be able to join this
> year again, but for that, we will need your help.
>
> Mentors
>
> We need to submit our application as a mentoring organization, but for that,
> we need to have a clear outline of what different projects we have for
> interns to work on.
>
> *** The deadline for mentoring organizations applications is 19/02/2016. ***
>
> If you are interested in mentoring but you have doubts about it, please feel
> free to reach us here or on #openstack-gsoc. We will be happy to reply any
> doubt you may have about mentoring for this internship. Also, you can check
> out this guide [0].
>
> If you are already convinced that you want to join us as a mentor for this
> round, add your name in the OpenStack Google Summer of Code 2016 wiki page
> [1] and add your project ideas in [2]. Make sure you leave your contact
> information in the OpenStack GSoC 2016 wiki and that you add all the
> important details about the project idea. Also reach us if there is
> something you are not certain about.
>
> Interns
>
> Whereas we don't know yet if we are going to make it as a mentoring
> organization for this round, if you want to join us as an intern and you
> want to help OpenStack to get selected as a mentoring organization, you can
> help us proposing different tasks for the various projects we have in our
> ecosystem.
>
> For your inspiration, you can check out past projects in [3] and [4].
>
> Looking forward to see GSoC happening again in our community!
>
> Thanks,
>
> Victoria
>
> [0] http://en.flossmanuals.net/gsocmentoring/
> [1] https://wiki.openstack.org/wiki/GSoC2016
> [2] https://wiki.openstack.org/wiki/Internship_ideas
> [3] https://wiki.openstack.org/wiki/GSoC2014
> [4] https://wiki.openstack.org/wiki/GSoC2015



-- 
Davanum Srinivas :: https://twitter.com/dims

__
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

[Yahoo-eng-team] [Bug 1540873] Re: Error: Service n-xvnc is not running

2016-02-02 Thread Davanum Srinivas (DIMS) 
https://review.openstack.org/#/c/274889/ was merged.

** Changed in: nova
   Status: New => Fix Released

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Compute (nova).
https://bugs.launchpad.net/bugs/1540873

Title:
  Error: Service n-xvnc is not running

Status in devstack:
  New
Status in OpenStack Compute (nova):
  Fix Released

Bug description:
  When stacking I am getting below error many times since a pair of
  days:

  2016-02-02 11:07:08,277 | + echo 'Error: Service n-xvnc is not running'
  2016-02-02 11:07:08,278 | Error: Service n-xvnc is not running
  2016-02-02 11:07:08,278 | + '[' -n /opt/stack/status/stack/n-xvnc.failure ']'
  2016-02-02 11:07:08,278 | + die 1642 'More details about the above errors can 
be found with screen, with ./rejoin-stack.sh'
  2016-02-02 11:07:08,278 | + local exitcode=0
  2016-02-02 11:07:08,278 | [Call Trace]
  2016-02-02 11:07:08,278 | ./stack.sh:1353:service_check
  2016-02-02 11:07:08,279 | /opt/stack/devstack/functions-common:1642:die
  2016-02-02 11:07:08,279 | [ERROR] /opt/stack/devstack/functions-common:1642 
More details about the above errors can be found with screen, with 
./rejoin-stack.sh
  2016-02-02 11:07:08,279 | Error on exit

  This is new. I am not sure witch repository between devstack, nova and
  neutron introduced it.

To manage notifications about this bug go to:
https://bugs.launchpad.net/devstack/+bug/1540873/+subscriptions

-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

Re: [openstack-dev] [Magnum] New Core Reviewers

2016-02-01 Thread Davanum Srinivas 
+1 from me!

On Mon, Feb 1, 2016 at 9:58 AM, Adrian Otto <adrian.o...@rackspace.com> wrote:
> Magnum Core Team,
>
> I propose Ton Ngo (Tango) and Egor Guz (eghobo) as new Magnum Core Reviewers. 
> Please respond with your votes.
>
> Thanks,
>
> Adrian Otto
> __
> 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



-- 
Davanum Srinivas :: https://twitter.com/dims

__
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] [oslo][all] Announcing our new Olso Project

2016-02-01 Thread Davanum Srinivas 
yay Ronald :)

On Mon, Feb 1, 2016 at 11:50 AM, Ronald Bradford <m...@ronaldbradford.com> 
wrote:
> The Olso team is proud to announce the release of Oslo Bingo.  In Oslo
> we like to spice up our release notes using meaningful random
> adjectives [1].
>
> Each month the Oslo team will select an adjective to be the Oslo Bingo
> word of the month.
>
> For February 2016 we have selected "jazzed" (from rlrossit).
>
> To play, simply pick the first Oslo project that will have release
> notes using our Bingo word of the month (i.e. jazzed). Check out
> recent release notes that selected "overjoyed" [2] and "jubilant" [3]
> to see what we mean.
>
> Entry is free for all at http://j.mp/Oslo-bingo [4]
>
> The winner each month will get a limited edition Oslo t-shirt,
> sponsored by HPE (quantity and sizes limited):
> http://j.mp/Oslo-bingo-prize
>
> More details at [5]
>
>
> [1] 
> http://git.openstack.org/cgit/openstack-infra/release-tools/tree/releasetools/release_notes.py#n33
> [2] 
> http://lists.openstack.org/pipermail/openstack-dev/2016-January/085000.html
> [3] 
> http://lists.openstack.org/pipermail/openstack-dev/2016-January/083797.html
> [4] http://j.mp/Oslo-bingo
> [5] https://etherpad.openstack.org/p/Oslo_Bingo
>
> __
> 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



-- 
Davanum Srinivas :: https://twitter.com/dims

__
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] [oslo] nominating Alexis Lee for oslo-core

2016-01-30 Thread Davanum Srinivas 
Sylvain,

Let's agree to disagree. This works for Oslo, so lets leave it at that.

Also, *please* switch Subject as this is not fair to Alexis's
nomination if you wish to continue.

-- Dims

On Sat, Jan 30, 2016 at 6:55 AM, Sylvain Bauza <sylvain.ba...@gmail.com> wrote:
>
> Le 30 janv. 2016 09:32, "Julien Danjou" <jul...@danjou.info> a écrit :
>>
>> On Fri, Jan 29 2016, Sylvain Bauza wrote:
>>
>> > While my heart is about that, my brain thinks about some regressions
>> > could
>> > be happening because of a +W even for a small change.
>>
>> I suggest you read the git-revert manpage then, you might discover
>> something interesting there. :)
>>
>
> I suggest you look how to revert an RPC API change by thinking of our
> continuous deployers, you might discover something interesting there. :)
>
>> The "shit happened" (e.g. bad thing merged) rate difference between a
>> "permission" policy and a "forgiveness" policy is based on my very
>> precise guessed estimation probably close to +1% in disfavor of
>> "forgiveness". Right.
>>
>
> I would like to understand your 1% estimate. Do you think that only one
> merged change is bad vs. 100 others good ?
> If so, how can you be sure that having an expert could not avoid the problem
> ?
>
>> But at the same time, the velocity rate difference is close to +50% for
>> that same policy. So I've picked my side. :)
>>
>
> I disagree with you. Say that one change will raise an important gate issue
> if merged.
> Of course the change looks good. It's perfectly acceptable from a python
> perspective and Jenkins is happy.
> Unfortunately, merging that change would create lots of problems because it
> would wedge all the service projects CIs because that would be a behavioral
> change that wouldn't have a backwards compatibility.
>
> If we have your forgiveness policy, it could have this change merged
> earlier, sure. But wouldn't you think that all the respective service
> projects velocities would be impacted by far more than this single change ?
>
> -Sylvain
>
>> --
>> Julien Danjou
>> ;; Free Software hacker
>> ;; https://julien.danjou.info
>
>
> ______
> 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
>



-- 
Davanum Srinivas :: https://twitter.com/dims

__
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] [oslo] nominating Alexis Lee for oslo-core

2016-01-29 Thread Davanum Srinivas 
Matt,

yes, that's a concern for sure. We work closely with all the new Oslo
cores to defer to experts first and learn. This goes into the debate
about the right mixture of Generalists and Specialists in the project
as well.

Thanks,
Dims

On Fri, Jan 29, 2016 at 5:42 AM, Matt Riedemann
<mrie...@linux.vnet.ibm.com> wrote:
>
>
> On 1/29/2016 11:33 AM, Davanum Srinivas wrote:
>>
>> Matt,
>>
>> yes, Nomination is for oslo-core. We would like to expand the core
>> group as well in addition to subject matter experts (example Dmitry
>> Uklhov for Oslo.Messaging core yesterday). The hope and expectation is
>> that Alexis would expand his reviews and expertise across all Oslo
>> projects over a period of time.
>>
>> Thanks,
>> Dims
>>
>> On Fri, Jan 29, 2016 at 5:24 AM, Matt Riedemann
>> <mrie...@linux.vnet.ibm.com> wrote:
>>>
>>>
>>>
>>> On 1/28/2016 10:05 PM, Doug Hellmann wrote:
>>>>
>>>>
>>>> I am nominating Alexis Lee (lxsli) for oslo-core.
>>>>
>>>> Alexis has been working on adding configuration file reloading to
>>>> oslo.config this cycle. The work isn't complete, but at this point
>>>> he probably knows as much or more about the internals of that library
>>>> as any of us. :-) He has also shown, with some of his other recent
>>>> proposals, that he has a ideas for the future of configuration
>>>> management and an interest in contributing to Oslo.
>>>>
>>>> Please indicate yea or nay with the usual +1/-1 vote here.
>>>>
>>>> Doug
>>>>
>>>>
>>>>
>>>> http://stackalytics.com/?release=all_type=all=commits_id=alexisl
>>>>
>>>>
>>>> __
>>>> 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
>>>>
>>>
>>> As an outsider, this is just a question, but I don't see an
>>> oslo-config-core
>>> group. I'm assuming that because of lxsli's work on oslo.config this
>>> nomination is coming up, but is the nomination for oslo-core, as in all
>>> of
>>> the oslo projects? Including things like oslo.versionedobjects and
>>> oslo.messaging?
>>>
>>> I'm just wondering how things get broken down because there are obviously
>>> subject matter experts in certain projects in oslo, but I wouldn't
>>> consider
>>> them as being cores across all projects just because they are core on
>>> one.
>>> Or am I misunderstanding?
>>>
>>> --
>>>
>>> Thanks,
>>>
>>> Matt Riedemann
>>>
>>>
>>>
>>> __
>>> 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
>>
>>
>>
>>
>
> So people are made core and then expected to become experts on the other
> projects? I get that is a carrot, but it seems like that could put the stick
> on the consuming projects if non-expert cores are approving changes they
> shouldn't be.
>
> Anyway, my two cents...
>
>
> --
>
> Thanks,
>
> Matt Riedemann
>
>
> __
> 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



-- 
Davanum Srinivas :: https://twitter.com/dims

__
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] [oslo] Adding Dmitry Ukhlov to Oslo-Messaging-Core

2016-01-28 Thread Davanum Srinivas 
Team,

Dmitry has been focused solely on the Pika Driver this cycle:
http://stackalytics.com/?user_id=dukhlov=commits

Now that we have Pika driver in master, i'd like to invite Dmitry to
continue his work on all of Oslo.Messaging in addition to Pika.
Clearly over time he will expand to other Oslo stuff (hopefully!).
Let's please make add him to the Oslo-Messaging-Core in the meantime.

Thanks,
Dims

-- 
Davanum Srinivas :: https://twitter.com/dims

__
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] [oslo][oslo.versionedobjects] Is it possible to make changes to oslo repos?

2016-01-28 Thread Davanum Srinivas 
Graham,

Quite unfair characterization of Oslo being -2 heavy. Please compare
stats before making such an assertion:

http://russellbryant.net/openstack-stats/oslo-reviewers-365.txt
http://russellbryant.net/openstack-stats/nova-reviewers-365.txt
http://russellbryant.net/openstack-stats/neutron-reviewers-365.txt

On the one single specific review you had a -2, you should be talking
to the reviewer on IRC or bring it to the next Oslo meeting.

Thanks,
Dims


On Thu, Jan 28, 2016 at 12:29 PM, Joshua Harlow <harlo...@fastmail.com> wrote:
> Hayes, Graham wrote:
>>
>> Also, olso seem to be very-2  heavy. This means that alternative views
>> on the review are very unlikely. My question is what is the difference
>> between a-1  and a-2  for oslo?
>
>
> If this is the case I am sorry about it, and I'd also like to think that we
> (as the oslo team) need not do this (or think about it more before we do
> it), because it usually isn't really needed (a -1 suffices IMHO for most
> things, especially things that are being actively discussed).
>
> But I'm also in the camp that thinks the whole -1 or -2 is sorta dumb and
> IMHO just leaving comments and talking to people on IRC to work through
> issues/discussion/code is better...
>
> But then that requires people<->people interaction and I guess not everyone
> likes to do that(?)
>
> In general I hope it's not all of oslo u are grouping here because, if its
> just a few cases, hopefully we can work with the person that is -2ing stuff
> to not do it willy nilly...
>
> My 2 cents,
>
> -Josh
>
>
>
>
> __
> 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



-- 
Davanum Srinivas :: https://twitter.com/dims

__
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] [oslo] nominating Ronald Bradford for oslo-core

2016-01-28 Thread Davanum Srinivas 
+1 from me!

-- Dims

On Thu, Jan 28, 2016 at 4:00 PM, Doug Hellmann <d...@doughellmann.com> wrote:
> I am nominating Ronald Bradford (rbradfor) for oslo-core.
>
> Ronald has been working this cycle to learn about oslo.context,
> oslo.log, and oslo.config. He anticipates picking up the much-needed
> work on the app-agnostic-logging blueprint, and has already started
> making incremental changes related to that work.  He has also
> contributed to the documentation generation and sample generator
> in oslo.config. His understanding of the code, our backwards-compatibility
> requirements, and the operational needs related to configuration
> and logging will make him a valuable addition to the team.
>
> Please indicate yea or nay with the usual +1/-1 vote here.
>
> Doug
>
> http://stackalytics.com/?release=all_type=all_id=ronaldbradford
>
>
> __
> 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



-- 
Davanum Srinivas :: https://twitter.com/dims

__
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] [oslo] nominating Alexis Lee for oslo-core

2016-01-28 Thread Davanum Srinivas 
+1 from me!

-- Dims

On Thu, Jan 28, 2016 at 4:05 PM, Doug Hellmann <d...@doughellmann.com> wrote:
> I am nominating Alexis Lee (lxsli) for oslo-core.
>
> Alexis has been working on adding configuration file reloading to
> oslo.config this cycle. The work isn't complete, but at this point
> he probably knows as much or more about the internals of that library
> as any of us. :-) He has also shown, with some of his other recent
> proposals, that he has a ideas for the future of configuration
> management and an interest in contributing to Oslo.
>
> Please indicate yea or nay with the usual +1/-1 vote here.
>
> Doug
>
> http://stackalytics.com/?release=all_type=all=commits_id=alexisl
>
> __
> 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



-- 
Davanum Srinivas :: https://twitter.com/dims

__
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] [oslo] Sachi King for oslo core

2016-01-24 Thread Davanum Srinivas 
+1 Robert. Here's hoping Sachi can expand her horizon to all of Oslo.

Thanks,
Dims

On Sun, Jan 24, 2016 at 9:51 PM, Robert Collins
<robe...@robertcollins.net> wrote:
> Hey, so I'd like to propose Sachi - one of my HPE colleages who has
> been helping out with pbr for a while now, for oslo core. pbr is
> pretty quiet as you know, so its a bit hard to assess her work based
> on reviews done - but I think her error rate will be
> approximately the same as mine - pbr is such a minefield that everyone
> will make mistakes, but she is thoughtful and has been burnt enough by
> the minefield that she's developing quite the paranoia about
> interactions in the wild. \o/
>
> I'd actually like to propose her for oslo core, not just pbr: though she
> doesn't have a big track record there outside of pbr, I don't see much
> point in restricting her to just pbr - she's very
> diligent and I'm sure if we offered it she'd do more for oslo code
> review than I've managed to. I have asked her if she's interested, and
> if she could commit to doing some reviews in oslo outside of pbr
> itself - which she has said she is and can.
>
> -Rob
>
> --
> Robert Collins <rbtcoll...@hpe.com>
> Distinguished Technologist
> HP Converged Cloud
>
> __
> 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



-- 
Davanum Srinivas :: https://twitter.com/dims

__
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] [nova] gate blockage due to eventlet 0.18

2016-01-24 Thread Davanum Srinivas 
yep. we should be all better now :)

-- dims

On Sun, Jan 24, 2016 at 2:48 PM, Andreas Jaeger <a...@suse.com> wrote:
> On 01/24/2016 08:01 PM, Jeremy Stanley wrote:
>>
>> On 2016-01-24 13:39:38 -0500 (-0500), Sean Dague wrote:
>>>
>>> Something about the eventlet 0.18 release is failing the cloudpipe
>>> functional tests, as well as our docs job (which is really really odd).
>>>
>>> An eventlet pin has been posted - https://review.openstack.org/271809 -
>>> once landed it should let the spice flow again. If someone could look
>>> into it deeper it would be appreciated. I know a lot of us are traveling
>>> over the next 24 hours, so not sure who is going to have time to dig in.
>>> But it will be massively appreciated.
>>
>>
>> Dims reported a related bug upstream:
>>
>>  https://github.com/eventlet/eventlet/issues/290
>>
>
> 0.18.1 was just released and should fix this.
>
> I could reproduce the failure building the docs with 0.18 but with 0.18.1 it
> works again for me,
>
> Andreas
> --
>  Andreas Jaeger aj@{suse.com,opensuse.org} Twitter/Identica: jaegerandi
>   SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
>GF: Felix Imendörffer, Jane Smithard, Graham Norton,
>HRB 21284 (AG Nürnberg)
> GPG fingerprint = 93A3 365E CE47 B889 DF7F  FED1 389A 563C C272 A126
>
>
>
> __
> 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



-- 
Davanum Srinivas :: https://twitter.com/dims

__
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

[Yahoo-eng-team] [Bug 1537402] [NEW] [gate] docs job fails with AttributeError: 'module' object has no attribute 'poll'

2016-01-23 Thread Davanum Srinivas (DIMS) 
Public bug reported:

Example from:
http://logs.openstack.org/63/270763/3/check/gate-nova-docs/ef898a9/console.html#_2016-01-23_19_08_05_195

2016-01-23 19:08:05.195 | 2016-01-23 19:08:05.149 6095 ERROR nova   File 
"/usr/lib/python2.7/subprocess.py", line 799, in communicate
2016-01-23 19:08:05.195 | 2016-01-23 19:08:05.149 6095 ERROR nova return 
self._communicate(input)
2016-01-23 19:08:05.195 | 2016-01-23 19:08:05.149 6095 ERROR nova   File 
"/usr/lib/python2.7/subprocess.py", line 1401, in _communicate
2016-01-23 19:08:05.195 | 2016-01-23 19:08:05.149 6095 ERROR nova stdout, 
stderr = self._communicate_with_poll(input)
2016-01-23 19:08:05.195 | 2016-01-23 19:08:05.149 6095 ERROR nova   File 
"/usr/lib/python2.7/subprocess.py", line 1431, in _communicate_with_poll
2016-01-23 19:08:05.195 | 2016-01-23 19:08:05.149 6095 ERROR nova poller = 
select.poll()
2016-01-23 19:08:05.195 | 2016-01-23 19:08:05.149 6095 ERROR nova 
AttributeError: 'module' object has no attribute 'poll'

** Affects: nova
 Importance: Critical
 Status: New

** Changed in: nova
   Importance: Undecided => Critical

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Compute (nova).
https://bugs.launchpad.net/bugs/1537402

Title:
  [gate] docs job fails with AttributeError: 'module' object has no
  attribute 'poll'

Status in OpenStack Compute (nova):
  New

Bug description:
  Example from:
  
http://logs.openstack.org/63/270763/3/check/gate-nova-docs/ef898a9/console.html#_2016-01-23_19_08_05_195

  2016-01-23 19:08:05.195 | 2016-01-23 19:08:05.149 6095 ERROR nova   File 
"/usr/lib/python2.7/subprocess.py", line 799, in communicate
  2016-01-23 19:08:05.195 | 2016-01-23 19:08:05.149 6095 ERROR nova return 
self._communicate(input)
  2016-01-23 19:08:05.195 | 2016-01-23 19:08:05.149 6095 ERROR nova   File 
"/usr/lib/python2.7/subprocess.py", line 1401, in _communicate
  2016-01-23 19:08:05.195 | 2016-01-23 19:08:05.149 6095 ERROR nova stdout, 
stderr = self._communicate_with_poll(input)
  2016-01-23 19:08:05.195 | 2016-01-23 19:08:05.149 6095 ERROR nova   File 
"/usr/lib/python2.7/subprocess.py", line 1431, in _communicate_with_poll
  2016-01-23 19:08:05.195 | 2016-01-23 19:08:05.149 6095 ERROR nova poller 
= select.poll()
  2016-01-23 19:08:05.195 | 2016-01-23 19:08:05.149 6095 ERROR nova 
AttributeError: 'module' object has no attribute 'poll'

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1537402/+subscriptions

-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

Re: [openstack-dev] [nova][testing] How to run a subset of py34 unit tests

2016-01-22 Thread Davanum Srinivas 
Melanie,

The following should work as well

source .tox/py34/bin/activate
ostestr --regex *.network.*

Thanks,
Dims

On Fri, Jan 22, 2016 at 9:46 PM, melanie witt <melwi...@gmail.com> wrote:
> Hi everyone,
>
> I noticed because of the way we run the py34 tests in tox.ini, I'm not able 
> to specify a filter regex the way I normally do as a positional arg, for 
> example: 'tox -epy34 nova.tests.unit.network' doesn't filter and it runs 
> everything. ('tox -epy27 nova.tests.unit.network' will only run tests that 
> match nova.tests.unit.network).
>
> I couldn't figure out how we could add something to tox.ini to make it work 
> -- we're calling ostestr with the --blacklist_file option. I'm not completely 
> clear on what 'ostestr --blacklist_file  --regex ' does but I 
> couldn't get it to do what I want. From the documentation [1], it adds 
> --regex to the regex created from the --blacklist_file. The regex from the 
> blacklist file looks something like this '^((?!blacklistedstuff).)*$' and if 
> I can only append to it, the best I could do was a positive lookbehind but 
> that can't match at the beginning of a line. (For example, I tried "ostestr 
> --blacklist_file tests-py3.txt --regex '(?<=network)'" and it matched all the 
> non-blacklisted tests that ended with the word "network"). It seems like what 
> I would need is for --regex to do another re.search() and match the line only 
> if the previous regex from the blacklist also matched.
>
> As a workaround to run only network tests, I did:
>
> source .tox/py34/bin/activate
> OS_TEST_PATH=./nova/tests/unit/network ostestr --blacklist_file tests-py3.txt
>
> Does anyone know a better way?
>
> Thanks,
> -melanie
>
>
> [1] http://docs.openstack.org/developer/os-testr/ostestr.html#test-selection
>
>
> __
> 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
>



-- 
Davanum Srinivas :: https://twitter.com/dims

__
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] [gate] gate-grenade-dsvm-multinode intermittent failures

2016-01-21 Thread Davanum Srinivas 
Hi,

Failures for this job has been trending up and is causing the large
gate queue as well. I've logged a bug:
https://bugs.launchpad.net/openstack-gate/+bug/1536622

and am requesting switching the voting to off for this job:
https://review.openstack.org/#/c/270788/

We need to find and fix the underlying issue which can help us
determine when to switch this back on to voting or we cleanup this job
from all the gate queues and move them to check queues (i have a TODO
for this in this review)

Thanks,
Dims

-- 
Davanum Srinivas :: https://twitter.com/dims

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

2016-01-19 Thread Davanum Srinivas 
https://review.openstack.org/#/c/269954/ is the plan of action.
@mtreinish is driving it. Plan is to request infra to promote it once
it passes check. This is not a neutron only break. it breaks all dsvm
jobs.

-- Dims

On Tue, Jan 19, 2016 at 8:28 PM, Armando M. <arma...@gmail.com> wrote:
> Hi neutrinos,
>
> New week, new gate failure. This time this might be infra related [1]. This
> one fails with [2]. If you know what's going on, spread the word!
>
> Cheers,
> Armando
>
> [1] https://review.openstack.org/#/c/269937/
> [2]
> http://logs.openstack.org/37/269937/1/check/gate-tempest-dsvm-neutron-full/a91b641/logs/devstacklog.txt.gz#_2016-01-20_01_12_41_571
>
> __
> 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
>



-- 
Davanum Srinivas :: https://twitter.com/dims

__
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] Long description of oslo.privsep

2016-01-15 Thread Davanum Srinivas 
Haha, needs work :)

-- Dims

On Fri, Jan 15, 2016 at 10:53 PM, Thomas Goirand <z...@debian.org> wrote:
> On 01/16/2016 08:35 AM, Davanum Srinivas wrote:
>> Zigo,
>>
>> Seriously, chill please.
>
> I was trying to write it funnily. Sorry if it wasn't obvious! :)
>
> Cheers,
>
> Thomas Goirand (zigo)
>
>
> __
> 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



-- 
Davanum Srinivas :: https://twitter.com/dims

__
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] Long description of oslo.privsep

2016-01-15 Thread Davanum Srinivas 
Zigo,

Seriously, chill please. the library is no where ready. It's not in
global requirements either at the moment. the code quite a bit of time
to go before we can switch over projects from oslo.rootwrap to
oslo.privsep.

We have check lists we that we go over before we let folks use it.
Right now we it's in pypi because we needed to kick the tires.

Thanks,
Dims

On Fri, Jan 15, 2016 at 7:00 PM, Joshua Harlow <harlo...@fastmail.com> wrote:
> Hopefully the following helps out here.
>
> https://review.openstack.org/#/c/268377/
>
> Gus or others hopefully can review that (and correct me if it's not the a
> good long description).
>
> -Josh
>
> Thomas Goirand wrote:
>>
>> Hi,
>>
>> Lucky I have written, in the cookie-butter repo:
>>
>> Please feel here a long description which must be at least 3 lines
>> wrapped on 80 cols, so that distribution package maintainers can use it
>> in their packages. Note that this is a hard requirement.
>>
>> Because without it, we could see stuff like this:
>> https://pypi.python.org/pypi/oslo.privsep
>>
>> Seriously, what shall I put as a long description for the package? Shall
>> I read the code to guess?
>>
>> Cheers,
>>
>> Thomas Goirand (zigo)
>>
>> __
>> 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



-- 
Davanum Srinivas :: https://twitter.com/dims

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

2016-01-14 Thread Davanum Srinivas 
LOL Tom :)

-- Dims

On Thu, Jan 14, 2016 at 2:32 AM, Tom Fifield <t...@openstack.org> wrote:
> On 14/01/16 15:22, Andreas Jaeger wrote:
>>
>> On 2016-01-14 08:13, Tom Fifield wrote:
>>>
>>> So, I'm prompted by another 20 oslo release emails to dredge up this
>>> thread :)
>>>
>>> There appears to be broad consensus that those shouldn't be going to the
>>> announce list ... what do we need to do to get that to change to posted
>>> to "-dev + batched inside the weekly -dev digest from thingee" as
>>> Thierry suggested?
>>
>>
>> So, those 20 odd olso release emails all went to -dev, the release team
>> changed the logic, see also
>>
>> http://lists.openstack.org/pipermail/openstack-dev/2016-January/083749.html
>
>
> Apologies to all. Maybe its time to visit the optometrist for me ... I
> haven't been once in my life yet, could be scary :)
>
>
>
>> Not sure about the "Batching inside the weekly digest from thingee",
>>
>> Andreas
>>
>>>
>>>
>>> Regards,
>>>
>>>
>>> Tom
>>>
>>> On 14/12/15 17:12, Tom Fifield wrote:
>>>>
>>>> ... and back to this thread after a few weeks :)
>>>>
>>>> The conclusions I saw were:
>>>> * Audience for openstack-announce should be "users/non-dev"
>>>> * Service project releases announcements are good
>>>> * Client library release announcements good
>>>> * Security announcements are good
>>>> * Internal library (particularly oslo) release announcements don't fit
>>>>
>>>> Open Questions:
>>>> * Where do Internal library release announcements go? [-dev or new
>>>> -release list or batched inside the weekly newsletter]
>>>> * Do SDK releases fit on -announce?
>>>>
>>>>
>>>> Regards,
>>>>
>>>>
>>>> Tom
>>>>
>>>>
>>>> On 20/11/15 12:00, Tom Fifield wrote:
>>>>>
>>>>> Hi all,
>>>>>
>>>>> I'd like to get your thoughts about the OpenStack-Announce list.
>>>>>
>>>>> We describe the list as:
>>>>>
>>>>> """
>>>>> Subscribe to this list to receive important announcements from the
>>>>> OpenStack Release Team and OpenStack Security Team.
>>>>>
>>>>> This is a low-traffic, read-only list.
>>>>> """
>>>>>
>>>>> Up until July 2015, it was used for the following:
>>>>> * Community Weekly Newsletter
>>>>> * Stable branch release notifications
>>>>> * Major (i.e. Six-monthly) release notifications
>>>>> * Important security advisories
>>>>>
>>>>> and had on average 5-10 messages per month.
>>>>>
>>>>> After July 2015, the following was added:
>>>>> * Release notifications for clients and libraries (one email per
>>>>> library, includes contributor-focused projects)
>>>>>
>>>>> resulting in an average of 70-80 messages per month.
>>>>>
>>>>>
>>>>> Personally, I no longer consider this volume "low traffic" :)
>>>>>
>>>>> In addition, I have been recently receiving feedback that users have
>>>>> been unsubscribing from or deleting without reading the list's posts.
>>>>>
>>>>> That isn't good news, given this is supposed to be the place where we
>>>>> can make very important announcements and have them read.
>>>>>
>>>>> One simple suggestion might be to batch the week's client/library
>>>>> release notifications into a single email. Another might be to look at
>>>>> the audience for the list, what kind of notifications they want, and
>>>>> chose the announcements differently.
>>>>>
>>>>> What do you think we should do to ensure the announce list remains
>>>>> useful?
>>>>>
>>>>>
>>>>>
>>>>> Regards,
>>>>>
>>>>>
>>>>> Tom
>>>>>
>>>>>
>>>>> __
>>>>>
>>>>>
>>>>>
>>>>> OpenStack Development Mailing L

Re: [openstack-dev] Further closing the holes that let gate breakage happen

2016-01-14 Thread Davanum Srinivas 
Neil,

Apologies. you are right, test_bash_completion is a unit test. and
neutron failure is in "gate-neutron-python27-constraints". so yes,
that was broken by the change to upper-constraints.txt.

https://review.openstack.org/#/c/266042/ is a valid request as it has
a g-r change and a u-c change even though it was not logged by the
Bot.

Thanks,
dims

On Thu, Jan 14, 2016 at 7:09 AM, Neil Jerram <neil.jer...@metaswitch.com> wrote:
> On 14/01/16 12:01, Davanum Srinivas wrote:
>> Neil,
>>
>> The global requirements upper-constraints.txt do not cover neutron
>> unit test targets. So the unit tests pick up latest from pypi.
>
> I'm afraid I don't understand how that's related to my question below.
> Could you explain further?
>
> It seems you might be saying that upper-constraints.txt should have no
> effect on Neutron UTs.  But my understanding from Carl's message is that
> an upper-constraints.txt change caused a Neutron UT (running as part of
> a gate job) to fail.  So I'm not sure how to understand your statement.
>
> Thanks,
> Neil
>
>
>>
>> -- Dims
>>
>>
>>
>> On Thu, Jan 14, 2016 at 6:51 AM, Neil Jerram <neil.jer...@metaswitch.com> 
>> wrote:
>>> On 13/01/16 19:27, Carl Baldwin wrote:
>>>> Hi,
>>>>
>>>> I was looking at the most recent gate breakage in Neutron [1], fixed
>>>> by [2].  This gate breakage was held off for some time by the
>>>> upper-constraints.txt file.   This is great progress and I applaud it.
>>>> I'll continue to cheer on this effort.
>>>>
>>>> Now to the next problem.   If my assessment of this gate failure is
>>>> correct, the update to the upper-constraints file [3] was merged
>>>> without running all of the tests across all of the projects that would
>>>> be broken by bringing in this new constraint.  So, we still get
>>>> breakage and it is still (IMO) too often.
>>>>
>>>> As I see it, there are a couple of options.
>>>>
>>>> 1) We run all tests under the upper-constraints control on all updates
>>>> to the upper constraints file like [2].  This would probably mean each
>>>> update has a very long list of tests and we would require that they
>>>> all be fixed before the upper constraint update can be merged.  This
>>>> seems like a difficult thing to coordinate all at once.
>>>> 2) We handle upper-constraints much like we do the global requirements
>>>> updates.  We have the master and a bot that proposes updates to it out
>>>> to the individual projects.  This would create a situation where
>>>> projects are out of sync with the master but I think if we froze the
>>>> master early enough, we could have time to reconcile before release.
>>>> 3) We continue to allow changes in the upper constraints to break
>>>> individual projects.
>>>>
>>>> Are there options that I missed?  What is your opinion?  In my
>>>> opinion, gate breakage happens a bit too often and the effect on the
>>>> community is widespread.  I'd like to contain it even a little bit
>>>> more.
>>>>
>>>> Carl
>>>>
>>>> [1] https://bugs.launchpad.net/neutron/+bug/1533638
>>>> [2] https://review.openstack.org/#/c/266885/
>>>> [3] https://review.openstack.org/#/c/266042/
>>> I've only just started to learn about requirements and constraints, so I
>>> may be misunderstanding.  However,
>>> https://github.com/openstack/requirements/blob/master/README.rst says:
>>>
>>>> For upper-constraints.txt changes
>>>>
>>>> If the change was proposed by the OpenStack CI bot, then if the
>>>> change has passed CI, only one reviewer is needed and they should +2
>>>> +A without thinking about things.
>>>>
>>>> If the change was not proposed by the OpenStack CI bot, and does not
>>>> include a global-requirements.txt change, then it should be rejected:
>>>> the CI bot will generate an appropriate change itself. Ask in
>>>> #openstack-infra if the bot needs to be run more quickly.
>>> Doesn't that mean that [3] should have been rejected, and hence already
>>> cover the recent situation?
>>>
>>> Neil
>>>
>>>
>>> __
>>> 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



-- 
Davanum Srinivas :: https://twitter.com/dims

__
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] Further closing the holes that let gate breakage happen

2016-01-14 Thread Davanum Srinivas 
Neil,

The global requirements upper-constraints.txt do not cover neutron
unit test targets. So the unit tests pick up latest from pypi.

-- Dims



On Thu, Jan 14, 2016 at 6:51 AM, Neil Jerram <neil.jer...@metaswitch.com> wrote:
> On 13/01/16 19:27, Carl Baldwin wrote:
>> Hi,
>>
>> I was looking at the most recent gate breakage in Neutron [1], fixed
>> by [2].  This gate breakage was held off for some time by the
>> upper-constraints.txt file.   This is great progress and I applaud it.
>> I'll continue to cheer on this effort.
>>
>> Now to the next problem.   If my assessment of this gate failure is
>> correct, the update to the upper-constraints file [3] was merged
>> without running all of the tests across all of the projects that would
>> be broken by bringing in this new constraint.  So, we still get
>> breakage and it is still (IMO) too often.
>>
>> As I see it, there are a couple of options.
>>
>> 1) We run all tests under the upper-constraints control on all updates
>> to the upper constraints file like [2].  This would probably mean each
>> update has a very long list of tests and we would require that they
>> all be fixed before the upper constraint update can be merged.  This
>> seems like a difficult thing to coordinate all at once.
>> 2) We handle upper-constraints much like we do the global requirements
>> updates.  We have the master and a bot that proposes updates to it out
>> to the individual projects.  This would create a situation where
>> projects are out of sync with the master but I think if we froze the
>> master early enough, we could have time to reconcile before release.
>> 3) We continue to allow changes in the upper constraints to break
>> individual projects.
>>
>> Are there options that I missed?  What is your opinion?  In my
>> opinion, gate breakage happens a bit too often and the effect on the
>> community is widespread.  I'd like to contain it even a little bit
>> more.
>>
>> Carl
>>
>> [1] https://bugs.launchpad.net/neutron/+bug/1533638
>> [2] https://review.openstack.org/#/c/266885/
>> [3] https://review.openstack.org/#/c/266042/
>
> I've only just started to learn about requirements and constraints, so I
> may be misunderstanding.  However,
> https://github.com/openstack/requirements/blob/master/README.rst says:
>
>> For upper-constraints.txt changes
>>
>> If the change was proposed by the OpenStack CI bot, then if the
>> change has passed CI, only one reviewer is needed and they should +2
>> +A without thinking about things.
>>
>> If the change was not proposed by the OpenStack CI bot, and does not
>> include a global-requirements.txt change, then it should be rejected:
>> the CI bot will generate an appropriate change itself. Ask in
>> #openstack-infra if the bot needs to be run more quickly.
>
> Doesn't that mean that [3] should have been rejected, and hence already
> cover the recent situation?
>
> Neil
>
>
> __
> 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



-- 
Davanum Srinivas :: https://twitter.com/dims

__
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] [Oslo][all] os-profiler under Oslo umbrella

2016-01-13 Thread Davanum Srinivas 
Team,

Oslo folks have voted[1] to be the home for the osprofiler project[2].
Several projects are already using osprofiler. One example of work in
flight is for Nova[3].

Please take a look at the README to see the features/description, in a
nutshell it will allow operators / end users to drill down into
HTTP/DB/RPC calls:
https://git.openstack.org/cgit/openstack/osprofiler/tree/README.rst

Thanks,
Dims

[1] https://review.openstack.org/#/c/103825/
[2] https://git.openstack.org/cgit/openstack/osprofiler/
[3] https://review.openstack.org/#/c/254703/

-- 
Davanum Srinivas :: https://twitter.com/dims

__
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

[Yahoo-eng-team] [Bug 1533194] [NEW] Gate failures for neutron in TestGettingAddress

2016-01-12 Thread Davanum Srinivas (DIMS) 
Public bug reported:

Logstash query:
message:"AssertionError: False is not true : Timed out waiting for 2003::1 to 
become reachable" AND voting:1

Example:
http://logs.openstack.org/95/262395/7/check/gate-tempest-dsvm-neutron-full/4293c5f/console.html#_2016-01-12_07_44_55_971

Jobs that fail:
gate-tempest-dsvm-neutron-full
gate-tempest-dsvm-neutron-dvr
gate-tempest-dsvm-neutron-src-taskflow
ate-tempest-dsvm-neutron-src-futurist

Tests that Fail include:
tempest.scenario.test_network_v6.TestGettingAddress.test_dhcp6_stateless_from_os
tempest.scenario.test_network_v6.TestGettingAddress.test_dualnet_multi_prefix_slaa

Traceback:
2016-01-12 07:44:55.972 | Captured traceback:
2016-01-12 07:44:55.972 | ~~~
2016-01-12 07:44:55.972 | Traceback (most recent call last):
2016-01-12 07:44:55.972 |   File "tempest/test.py", line 113, in wrapper
2016-01-12 07:44:55.972 | return f(self, *func_args, **func_kwargs)
2016-01-12 07:44:55.972 |   File "tempest/scenario/test_network_v6.py", 
line 216, in test_dhcp6_stateless_from_os
2016-01-12 07:44:55.973 | 
self._prepare_and_test(address6_mode='dhcpv6-stateless')
2016-01-12 07:44:55.973 |   File "tempest/scenario/test_network_v6.py", 
line 195, in _prepare_and_test
2016-01-12 07:44:55.973 | self.subnets_v6[i].gateway_ip)
2016-01-12 07:44:55.973 |   File "tempest/scenario/test_network_v6.py", 
line 205, in _check_connectivity
2016-01-12 07:44:55.973 | (dest, source.ssh_client.host)
2016-01-12 07:44:55.973 |   File 
"/opt/stack/new/tempest/.tox/full/local/lib/python2.7/site-packages/unittest2/case.py",
 line 702, in assertTrue
2016-01-12 07:44:55.973 | raise self.failureException(msg)
2016-01-12 07:44:55.974 | AssertionError: False is not true : Timed out 
waiting for 2003::1 to become reachable from 172.24.5.111

** Affects: neutron
 Importance: Undecided
 Status: New

** Affects: tempest
 Importance: Undecided
 Status: New

** Also affects: tempest
   Importance: Undecided
   Status: New

** Description changed:

  Logstash query:
  message:"AssertionError: False is not true : Timed out waiting for 2003::1 to 
become reachable" AND voting:1
  
  Example:
  
http://logs.openstack.org/95/262395/7/check/gate-tempest-dsvm-neutron-full/4293c5f/console.html#_2016-01-12_07_44_55_971
+ 
+ Jobs that fail:
+ gate-tempest-dsvm-neutron-full
+ gate-tempest-dsvm-neutron-dvr
+ gate-tempest-dsvm-neutron-src-taskflow
+ ate-tempest-dsvm-neutron-src-futurist
  
  Tests that Fail include:
  
tempest.scenario.test_network_v6.TestGettingAddress.test_dhcp6_stateless_from_os
  
tempest.scenario.test_network_v6.TestGettingAddress.test_dualnet_multi_prefix_slaa
  
  Traceback:
  2016-01-12 07:44:55.972 | Captured traceback:
  2016-01-12 07:44:55.972 | ~~~
  2016-01-12 07:44:55.972 | Traceback (most recent call last):
  2016-01-12 07:44:55.972 |   File "tempest/test.py", line 113, in wrapper
  2016-01-12 07:44:55.972 | return f(self, *func_args, **func_kwargs)
  2016-01-12 07:44:55.972 |   File "tempest/scenario/test_network_v6.py", 
line 216, in test_dhcp6_stateless_from_os
  2016-01-12 07:44:55.973 | 
self._prepare_and_test(address6_mode='dhcpv6-stateless')
  2016-01-12 07:44:55.973 |   File "tempest/scenario/test_network_v6.py", 
line 195, in _prepare_and_test
  2016-01-12 07:44:55.973 | self.subnets_v6[i].gateway_ip)
  2016-01-12 07:44:55.973 |   File "tempest/scenario/test_network_v6.py", 
line 205, in _check_connectivity
  2016-01-12 07:44:55.973 | (dest, source.ssh_client.host)
  2016-01-12 07:44:55.973 |   File 
"/opt/stack/new/tempest/.tox/full/local/lib/python2.7/site-packages/unittest2/case.py",
 line 702, in assertTrue
  2016-01-12 07:44:55.973 | raise self.failureException(msg)
  2016-01-12 07:44:55.974 | AssertionError: False is not true : Timed out 
waiting for 2003::1 to become reachable from 172.24.5.111

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1533194

Title:
  Gate failures for neutron in TestGettingAddress

Status in neutron:
  New
Status in tempest:
  New

Bug description:
  Logstash query:
  message:"AssertionError: False is not true : Timed out waiting for 2003::1 to 
become reachable" AND voting:1

  Example:
  
http://logs.openstack.org/95/262395/7/check/gate-tempest-dsvm-neutron-full/4293c5f/console.html#_2016-01-12_07_44_55_971

  Jobs that fail:
  gate-tempest-dsvm-neutron-full
  gate-tempest-dsvm-neutron-dvr
  gate-tempest-dsvm-neutron-src-taskflow
  ate-tempest-dsvm-neutron-src-futurist

  Tests that Fail include:
  
tempest.scenario.test_network_v6.TestGettingAddress.test_dhcp6_stateless_from_os
  
tempest.scenario.test_network_v6.TestGettingAddress.test_dualnet_multi_prefix_slaa

  Traceback:
  2016-01-12 07:44:55.972 | Captured traceback:
  2016-01-12

[Yahoo-eng-team] [Bug 1532809] [NEW] Gate failures when DHCP lease cannot be acquired

2016-01-11 Thread Davanum Srinivas (DIMS) 
Public bug reported:

Example from:
http://logs.openstack.org/97/265697/1/check/gate-grenade-dsvm/6eeced7/console.html#_2016-01-11_07_42_30_838

Logstash query:
message:"No lease, failing" AND voting:1

dhcp_release for an ip/mac does not seem to reach dnsmasq (or it fails
to act on it - "unknown lease") as i don't see entries in syslog for it.

Logs from nova network:
dims@dims-mac:~/junk/6eeced7$ grep dhcp_release old/screen-n-net.txt.gz | grep 
10.1.0.3 | grep CMD
2016-01-11 07:25:35.548 DEBUG oslo_concurrency.processutils 
[req-62aaa0b9-093e-4f28-805d-d4bf3008bfe6 tempest-ServersTestJSON-1206086292 
tempest-ServersTestJSON-1551541405] CMD "sudo nova-rootwrap 
/etc/nova/rootwrap.conf dhcp_release br100 10.1.0.3 fa:16:3e:32:51:c3" 
returned: 0 in 0.117s execute 
/usr/local/lib/python2.7/dist-packages/oslo_concurrency/processutils.py:297
2016-01-11 07:25:51.259 DEBUG oslo_concurrency.processutils 
[req-31115ffa-8d43-4621-bb2e-351d6cd4bcef 
tempest-ServerActionsTestJSON-357128318 
tempest-ServerActionsTestJSON-854742699] CMD "sudo nova-rootwrap 
/etc/nova/rootwrap.conf dhcp_release br100 10.1.0.3 fa:16:3e:a4:f0:11" 
returned: 0 in 0.108s execute 
/usr/local/lib/python2.7/dist-packages/oslo_concurrency/processutils.py:297
2016-01-11 07:26:35.357 DEBUG oslo_concurrency.processutils 
[req-c32a216e-d909-41a0-a0bc-d5eb7a21c048 
tempest-TestVolumeBootPattern-46217374 
tempest-TestVolumeBootPattern-1056816637] CMD "sudo nova-rootwrap 
/etc/nova/rootwrap.conf dhcp_release br100 10.1.0.3 fa:16:3e:ed:de:f6" 
returned: 0 in 0.110s execute 
/usr/local/lib/python2.7/dist-packages/oslo_concurrency/processutils.py:297

Logs from syslog:
dims@dims-mac:~/junk$ grep 10.1.0.3 syslog.txt.gz
Jan 11 07:25:35 devstack-trusty-rax-iad-7090830 dnsmasq-dhcp[7798]: 
DHCPRELEASE(br100) 10.1.0.3 fa:16:3e:32:51:c3 unknown lease
Jan 11 07:25:51 devstack-trusty-rax-iad-7090830 dnsmasq-dhcp[7798]: 
DHCPRELEASE(br100) 10.1.0.3 fa:16:3e:a4:f0:11 unknown lease
Jan 11 07:26:24 devstack-trusty-rax-iad-7090830 dnsmasq-dhcp[7798]: 
DHCPOFFER(br100) 10.1.0.3 fa:16:3e:ed:de:f6
Jan 11 07:26:24 devstack-trusty-rax-iad-7090830 dnsmasq-dhcp[7798]: 
DHCPREQUEST(br100) 10.1.0.3 fa:16:3e:ed:de:f6
Jan 11 07:26:24 devstack-trusty-rax-iad-7090830 dnsmasq-dhcp[7798]: 
DHCPACK(br100) 10.1.0.3 fa:16:3e:ed:de:f6 tempest
Jan 11 07:27:34 devstack-trusty-rax-iad-7090830 object-auditor: Object audit 
(ALL). Since Mon Jan 11 07:27:34 2016: Locally: 1 passed, 0 quarantined, 0 
errors files/sec: 2.03 , bytes/sec: 10119063.16, Total time: 0.49, Auditing 
time: 0.00, Rate: 0.00
Jan 11 07:39:12 devstack-trusty-rax-iad-7090830 dnsmasq-dhcp[7798]: not using 
configured address 10.1.0.3 because it is leased to fa:16:3e:ed:de:f6
Jan 11 07:40:12 devstack-trusty-rax-iad-7090830 dnsmasq-dhcp[7798]: not using 
configured address 10.1.0.3 because it is leased to fa:16:3e:ed:de:f6
Jan 11 07:41:12 devstack-trusty-rax-iad-7090830 dnsmasq-dhcp[7798]: not using 
configured address 10.1.0.3 because it is leased to fa:16:3e:ed:de:f6
Jan 11 07:42:26 devstack-trusty-rax-iad-7090830 dnsmasq-dhcp[7798]: 
DHCPRELEASE(br100) 10.1.0.3 fa:16:3e:fe:1f:36 unknown lease

Net, The test that runs the ssh against the vm fails with the "No lease,
failing" in its serial console

** Affects: nova
 Importance: Undecided
 Status: New

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Compute (nova).
https://bugs.launchpad.net/bugs/1532809

Title:
  Gate failures when DHCP lease cannot be acquired

Status in OpenStack Compute (nova):
  New

Bug description:
  Example from:
  
http://logs.openstack.org/97/265697/1/check/gate-grenade-dsvm/6eeced7/console.html#_2016-01-11_07_42_30_838

  Logstash query:
  message:"No lease, failing" AND voting:1

  dhcp_release for an ip/mac does not seem to reach dnsmasq (or it fails
  to act on it - "unknown lease") as i don't see entries in syslog for
  it.

  Logs from nova network:
  dims@dims-mac:~/junk/6eeced7$ grep dhcp_release old/screen-n-net.txt.gz | 
grep 10.1.0.3 | grep CMD
  2016-01-11 07:25:35.548 DEBUG oslo_concurrency.processutils 
[req-62aaa0b9-093e-4f28-805d-d4bf3008bfe6 tempest-ServersTestJSON-1206086292 
tempest-ServersTestJSON-1551541405] CMD "sudo nova-rootwrap 
/etc/nova/rootwrap.conf dhcp_release br100 10.1.0.3 fa:16:3e:32:51:c3" 
returned: 0 in 0.117s execute 
/usr/local/lib/python2.7/dist-packages/oslo_concurrency/processutils.py:297
  2016-01-11 07:25:51.259 DEBUG oslo_concurrency.processutils 
[req-31115ffa-8d43-4621-bb2e-351d6cd4bcef 
tempest-ServerActionsTestJSON-357128318 
tempest-ServerActionsTestJSON-854742699] CMD "sudo nova-rootwrap 
/etc/nova/rootwrap.conf dhcp_release br100 10.1.0.3 fa:16:3e:a4:f0:11" 
returned: 0 in 0.108s execute 
/usr/local/lib/python2.7/dist-packages/oslo_concurrency/processutils.py:297
  2016-01-11 07:26:35.357 DEBUG oslo_concurrency.processutils 
[req-c32a216e-d909-41a0-a0bc-d5eb7a21c048 
tempest-TestVolumeBootPattern-46217374

Re: [openstack-dev] [oslo][cfg] Benefit of MultiStrOpt over ListOpt

2016-01-10 Thread Davanum Srinivas 
Hi John,

yep it's come up before:
http://markmail.org/message/5ut4rdjivpw6a6a6

Thanks,
Dims

On Sun, Jan 10, 2016 at 1:04 PM, John Stanford <j...@solinea.com> wrote:
> Hi,
>
> I’m having trouble understanding the need for MultiStrOpt.  I see it used in 
> a few places like ‘notification_driver’, and wonder why a MultiStrOpt is a 
> better choice than ListOpt.  Could someone enlighten me.  I suspect it’s used 
> for a reason, but if you’ve tried to programmatically manipulate the INI 
> files, you have probably struggled with MultiStrOpt...
>
> Thanks,
>
> John
> __
> 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



-- 
Davanum Srinivas :: https://twitter.com/dims

__
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] re-introducing twisted to global-requirements

2016-01-08 Thread Davanum Srinivas 
o keep
>>>>> something
>>>>> like this -- if it is TRULY needed -- in-tree with the API service
>>>>> itself,
>>>>> so that the chances of divergence are reduced. This is similar to the
>>>>> fakevirt driver in Nova. It's in tree for good reason: when someone
>>>>> changes
>>>>> the virt driver interface, the fakevirt driver goes boom and needs to
>>>>> be
>>>>> changed in a corresponding fashion in the same patch.
>>>>
>>>>
>>>> I tend to think our REST APIs are much more stable than internal python
>>>> APIs, and so we can manage the divergence much easier.
>>>>
>>>> Also, mimic can simulate:
>>>>
>>>> * old versions (less needed with all the microversion stuff)
>>>> * old bugs that were shipped
>>>> * misconfigurations
>>>> * networking errors
>>>> * the passage of time (including timeouts)
>>>>
>>>> We probably don't want to keep a catalog of old bugs and
>>>> misconfigurations in
>>>> tree forever.
>>>>
>>>>> What value does a functional test against an HTTP API service that does
>>>>> nothing (other than introduce greater surface area for bugs) actually
>>>>> offer
>>>>> over unit tests anyway?
>>>>
>>>>
>>>> Testing the full stack of the client instead of mocking the bottom
>>>> half of requests is a big one.
>>>>
>>>> Lekha and Glyph gave a talk on Mimic in Paris; it may be enlightening.
>>>> https://www.youtube.com/watch?v=HKUUQme3dwA
>>>
>>>
>>> OK, I just watched that. Sorry, still don't see the value that Mimic
>>> provides over unit testing the client interfaces and mocking out the HTTP
>>> payloads so you have strict control over the expectations.
>>>
>>> The problem that Glyph noted in the video about the unit test that mocked
>>> out os.chdir to improperly return a value isn't solved whatsoever by
>>> Mimic,
>>> so I find it odd that that example was used in discussing the value of
>>> Mimic. Bad mocks are just that: bad mocks. The same false positive
>>> failure
>>> could easily be introduced with a typo in the "metadata injection" that
>>> Mimic does to inject failures into the system.
>>>
>>> Mimic isn't testing anything on the server side at all so I'm not sure
>>> why
>>> folks call it "integration testing". It isn't testing the integration of
>>> anything at all. All it enables is multi-language client library testing,
>>> and see my response to Ben, the surface area it introduces for bugs in
>>> the
>>> test platform itself in my opinion outweigh the multi-language value it
>>> might have.
>>
>>
>> FWIW, I've only been calling it functional testing. I also don't care
>> about the multi-language parts here. The sole purpose we have for mimic
>> (so far) is to functionally test python-ironicclient without mocking the
>> world in ironicclient.
>>
>>> Final question on this... if Mimic is *only* for testing clients, why not
>>> make it just a dependency for python-ironicclient and not ironic itself?
>>
>>
>> We haven't made it a dep for anything yet, only added to g-r.
>
>
> According to Dims, not to g-r, but to u-c, right Dims? Not sure if that
> makes functionally any difference, though (pun intended).
>
>> However, now that you mention that, a really ambitious goal would be to
>> add a rabbit interface to mimic, and functionally test the API server
>> (that it sends the right messages, etc). Another would be to mimic
>> (Neutron, Glance) and test Ironic by itself.
>
>
> So you would reimplement AMQP communication protocols using an in-memory
> data store for queues. Sounds like an even greater surface area for bugs to
> be introduced.
>
>> Last, I frankly don't understand why there's
>> such heavy opposition to the ironic team using an additional tool for
>> testing.
>
>
> Since you asked, I'll be blunt. This isn't a personal attack on you, Jim,
> though.
>
> a) Because it fractures the testing and QA processes used by upstream
> contributors that work on OpenStack projects by requiring them to learn
> another system -- and one that potentially would require them to understand
> a whole new surface area for potential bugs
>
> b) Because it represents yet another RAX-driven divergence in the QA space.
> CloudCafe took essentially all of the RAX folks that were at one point
> working on Tempest and upstream QA and siloed them into a totally different
> organization, in true RAX fashion. Instead of pulling the OpenStack QA
> community along together, RAX QA continues to just do its own thing and
> there's still bitterness on the tips of tongues.
>
> 
>
>> There was *more* than sufficient time for "I don't think this is useful"
>> to be posted on the review.
>
>
> Sorry, this was the first I'd heard of it all.
>
>> If anyone has a hard technical reason why
>>
>> mimic should not be used to test an OpenStack project, I'm happy to
>> listen. Otherwise I'd like to work on actually getting things done.
>
>
> I've listed my hard technical reason: it introduces, IMHO, too large of a
> surface area for bugs to creep in to the testing process versus the benefit
> it provides.
>
> Best,
> -jay
>
> __
> 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



-- 
Davanum Srinivas :: https://twitter.com/dims

__
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] [oslo][osdk] PrettyTable needs a home in OpenStack

2016-01-08 Thread Davanum Srinivas 
#2 please :)

Thanks,
Dims

On Fri, Jan 8, 2016 at 8:06 AM, Flavio Percoco <fla...@redhat.com> wrote:
> Greetings,
>
> As some of you know already, google code is going to be shutdown. Some
> projects we're using are hosted and, unfortunately, some of them are
> unmaintained and perhaps going away.
>
> One of these projects is PrettyTable. This point was raised by Erno in
> this patch[0] from jd__. PrettyTable is not just being used in several
> openstack specific projects but it's also a transitive dependency for
> all client libraries using cliff.
>
> With all that in mind, I've contacted the author of the library and
> asked him if it'd be ok for us (OpenStack) to adopt this library. The
> author accepted and granted me access to the project on pypi.
>
> I'm saying all the above because we now need to find a home for it in
> OpenStack.
>
> I've identified 2 possible places:
>
> 1) Oslo, as we maintaing cross-project libraries and some of them are
> not in the oslo namespace
>
> 2) OpenStack Client team as they maintain cliff already and it'd
> perhaps make more sense to have this library there.
>
> One thing to note is that this library has been quite stable, which
> means it won't, hopefully, add too much work to the team.
>
> Thoughts?
>
> [0] https://review.openstack.org/#/c/234340/
>
> --
> @flaper87
> Flavio Percoco
>
> __
> 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
>



-- 
Davanum Srinivas :: https://twitter.com/dims

__
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] Austin Summit Panel on Generation of Sample Configuration Option Files

2016-01-07 Thread Davanum Srinivas 
gt; > >> of sample configuration option files. Upon initial research it looks
>> > > >> like none of the main projects are doing it the same way.
>> > > > I'm not sure what you mean.  Nova, Neutron, Keystone, Glance, and
>> Heat
>> > > > (at least) are all using the oslo-config-generator tool for this.
>> > There
>> > > > might be some slight variation in how they call it, but they are
>> using
>> > it.
>> > > Yes, we know that they are all using oslo-config-generator but there is
>> > > not consistency
>> > > in how the information that oslo-config-generator needs to do its job
>> is
>> > > being created.
>> > > Kendall is looking to better understand what we should be doing and try
>> > > to bring
>> > > greater consistency between the projects.
>> > >
>> > > > I only vaguely recall having discussions about this with Cinder, so
>> I'd
>> > > > be interested in a refresher around why Cinder didn't want to do it
>> the
>> > > > same way.  I kind of considered it a solved problem.
>> > > So, the challenge Cinder has is the fact that there are many
>> > > configuration options with all the
>> > > different drivers.  We had proposed a static cinder/opts.py file with
>> > > hacking checks to ensure
>> > > that all new options were pulled into the file.  This was considered
>> > > undesirable.  This lead to
>> > > the current solution where we are working to find all the possible
>> > > option lists to dynamically
>> > > create the cinder/opts.py file.  Similar to what we used to do with the
>> > > old config generator.
>> >
>> > I proposed, I think, that each driver should have its own entry point,
>> > cinder.foo, cinder.bar, etc. Each entry point refers to a single
>> > function, which can be maintained inside the driver code by the driver
>> > author. Each would then be registered in setup.cfg and listed in the
>> > input file for the config generator. If you also ensure that all of the
>> > options for a given driver are in their own section of the config file,
>> > you'll have a nice neat sample with all of the options. If a deployer or
>> > distributor wants to generate a file that only includes the driver in
>> > use, that's possible by passing different inputs to the config
>> > generator.
>> >
>> > >
>> > > For Nova, having a dynamic solution is less important as they don't
>> have
>> > > options changing
>> > > as frequently.  It appears that Neutron was less concerned about the
>> > > potentially dynamic nature
>> > > of options in their drivers.
>> > >
>> > > > For reference:
>> > > > Nova: https://github.com/openstack/nova/blob/master/tox.ini#L90
>> > > > Neutron:
>> https://github.com/openstack/neutron/blob/master/tox.ini#L198
>> > > > which calls
>> > > >
>> >
>> https://github.com/openstack/neutron/blob/master/tools/generate_config_file_samples.sh#L17
>>
>> >
>> > > > Keystone:
>> > https://github.com/openstack/keystone/blob/master/tox.ini#L148
>> > > > Etc...
>> > > >
>> > > >> I thought it
>> > > >> might be interesting to get a panel together to talk about how it is
>> > > >> done for each project, why it is done that way for each project, and
>> > > >> maybe discuss a more universal approach that could be implemented in
>> > > >> oslo and used by all the projects. Please let me know if you have
>> > > >> knowledge on your project’s method and are interested in being part
>> of
>> > a
>> > > >> panel.
>> > > >>
>> > > >>
>> > > >> If you are interested in looking at Cinder’s approach, here is the
>> > patch
>> > > >> I implemented to make the generation of the sample config file
>> > dynamic:
>> > > >> https://review.openstack.org/#/c/219700/
>> > > >>
>> > > >>
>> > > >> All the Best,
>> > > >>
>> > > >> *Kendall J. Nelson*
>> > > >> Software Engineer &
>> > > >>
>> > > >> Openstack Cinder Contributor
>> > > >>
>> > 
>> > > >> *E-mail:*_kjnel...@us.ibm.com_ <mailto:zah...@us.ibm.com>
>> > > >> *Cell Phone:*(952) 215- 4025*
>> > > >> IRC Nickname:*diablo_rojo
>> > > >> IBM
>> > > >>
>> > > >> 3605 Hwy 52 N
>> > > >> Rochester, MN 55901-1407
>> > > >> United States
>> > > >>
>> > > >>
>> > > >>
>> > > >>
>> > > >>
>> > > >>
>> >
>
> __
> 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



-- 
Davanum Srinivas :: https://twitter.com/dims

__
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] re-introducing twisted to global-requirements

2016-01-07 Thread Davanum Srinivas 
A bit more information. the dependency for twisted is not in
global-requirements.txt, it will be only added to
upper-constraints.txt when the CI job/bot proposes it next.

Thanks,
Dims

On Thu, Jan 7, 2016 at 2:09 PM, Jim Rollenhagen <j...@jimrollenhagen.com> wrote:
> Hi all,
>
> A change to global-requirements[1] introduces mimic, which is an http
> server that can mock various APIs, including nova and ironic, including
> control of error codes and timeouts. The ironic team plans to use this
> for testing python-ironicclient without standing up a full ironic
> environment.
>
> Here's the catch - mimic is built on twisted. I know twisted was
> previously removed from OpenStack (or at least people said "pls no", I
> don't know the full history). We didn't intend to stealth-introduce
> twisted back into g-r, but it was pointed out to me that it may appear
> this way, so here I am letting everyone know. lifeless pointed out that
> when tests are failing, people may end up digging into mimic or twisted
> code, which most people in this community aren't familiar with AFAIK,
> which is a valid point though I hope it isn't required often.
>
> So, the primary question here is: do folks have a problem with adding
> twisted here? We're holding off on Ironic changes that depend on this
> until this discussion has happened, but aren't reverting the g-r change
> until we decide one way or another.
>
> // jim
>
> [1] https://review.openstack.org/#/c/220268/
>
> __
> 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



-- 
Davanum Srinivas :: https://twitter.com/dims

__
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] [nova][ec2-api] Removing Nova's In tree ec2 API code in favor of ec2-api project

2016-01-07 Thread Davanum Srinivas 
Dear Nova cores,

Sorry this did not make into the Nova weekly meeting agenda yesterday.

Is it time for dropping the EC2/ObjectStore REST API Since we've told
folks since Kilo that we will be removing this code and we dropped the
entries api-paste.ini in Liberty?
https://review.openstack.org/#/c/263368/

Thanks,
Dims


-- 
Davanum Srinivas :: https://twitter.com/dims

__
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

[Yahoo-eng-team] [Bug 1482633] Re: requests to SSL wrapped sockets hang while reading using py3

2016-01-03 Thread Davanum Srinivas (DIMS) 
** Also affects: nova
   Importance: Undecided
   Status: New

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1482633

Title:
  requests to SSL wrapped sockets hang while reading using py3

Status in Manila:
  New
Status in neutron:
  Invalid
Status in OpenStack Compute (nova):
  New
Status in oslo.service:
  New

Bug description:
  If we run unit tests using py3 then we get following errors:

  ==
  FAIL: manila.tests.test_wsgi.TestWSGIServer.test_app_using_ssl
  tags: worker-0
  --
  Empty attachments:
pythonlogging:''
stdout

  stderr: {{{
  Traceback (most recent call last):
File 
"/home/vponomaryov/Documents/python/projects/manila/.tox/py34/lib/python3.4/site-packages/eventlet/hubs/hub.py",
 line 457, in fire_timers
  timer()
File 
"/home/vponomaryov/Documents/python/projects/manila/.tox/py34/lib/python3.4/site-packages/eventlet/hubs/timer.py",
 line 58, in __call__
  cb(*args, **kw)
File 
"/home/vponomaryov/Documents/python/projects/manila/.tox/py34/lib/python3.4/site-packages/eventlet/greenthread.py",
 line 214, in main
  result = function(*args, **kwargs)
File 
"/home/vponomaryov/Documents/python/projects/manila/.tox/py34/lib/python3.4/site-packages/eventlet/wsgi.py",
 line 823, in server
  client_socket = sock.accept()
File 
"/home/vponomaryov/Documents/python/projects/manila/.tox/py34/lib/python3.4/site-packages/eventlet/green/ssl.py",
 line 333, in accept
  suppress_ragged_eofs=self.suppress_ragged_eofs)
File 
"/home/vponomaryov/Documents/python/projects/manila/.tox/py34/lib/python3.4/site-packages/eventlet/green/ssl.py",
 line 88, in __init__
  self.do_handshake()
File 
"/home/vponomaryov/Documents/python/projects/manila/.tox/py34/lib/python3.4/site-packages/eventlet/green/ssl.py",
 line 241, in do_handshake
  super(GreenSSLSocket, self).do_handshake)
File 
"/home/vponomaryov/Documents/python/projects/manila/.tox/py34/lib/python3.4/site-packages/eventlet/green/ssl.py",
 line 106, in _call_trampolining
  return func(*a, **kw)
File "/usr/lib/python3.4/ssl.py", line 805, in do_handshake
  self._sslobj.do_handshake()
  ssl.SSLWantReadError: The operation did not complete (read) (_ssl.c:598)
  }}}

  Traceback (most recent call last):
File 
"/home/vponomaryov/Documents/python/projects/manila/manila/tests/test_wsgi.py", 
line 181, in test_app_using_ssl
  'https://127.0.0.1:%d/' % server.port)
File "/usr/lib/python3.4/urllib/request.py", line 153, in urlopen
  return opener.open(url, data, timeout)
File "/usr/lib/python3.4/urllib/request.py", line 455, in open
  response = self._open(req, data)
File "/usr/lib/python3.4/urllib/request.py", line 473, in _open
  '_open', req)
File "/usr/lib/python3.4/urllib/request.py", line 433, in _call_chain
  result = func(*args)
File "/usr/lib/python3.4/urllib/request.py", line 1273, in https_open
  context=self._context, check_hostname=self._check_hostname)
File "/usr/lib/python3.4/urllib/request.py", line 1232, in do_open
  h.request(req.get_method(), req.selector, req.data, headers)
File "/usr/lib/python3.4/http/client.py", line 1065, in request
  self._send_request(method, url, body, headers)
File "/usr/lib/python3.4/http/client.py", line 1103, in _send_request
  self.endheaders(body)
File "/usr/lib/python3.4/http/client.py", line 1061, in endheaders
  self._send_output(message_body)
File "/usr/lib/python3.4/http/client.py", line 906, in _send_output
  self.send(msg)
File "/usr/lib/python3.4/http/client.py", line 841, in send
  self.connect()
File "/usr/lib/python3.4/http/client.py", line 1205, in connect
  server_hostname=server_hostname)
File 
"/home/vponomaryov/Documents/python/projects/manila/.tox/py34/lib/python3.4/site-packages/eventlet/green/ssl.py",
 line 362, in _green_sslcontext_wrap_socket
  return GreenSSLSocket(sock, *a, _context=self, **kw)
File 
"/home/vponomaryov/Documents/python/projects/manila/.tox/py34/lib/python3.4/site-packages/eventlet/green/ssl.py",
 line 88, in __init__
  self.do_handshake()
File 
"/home/vponomaryov/Documents/python/projects/manila/.tox/py34/lib/python3.4/site-packages/eventlet/green/ssl.py",
 line 241, in do_handshake
  super(GreenSSLSocket, self).do_handshake)
File 
"/home/vponomaryov/Documents/python/projects/manila/.tox/py34/lib/python3.4/site-packages/eventlet/green/ssl.py",
 line 116, in _call_trampolining
  timeout_exc=timeout_exc('timed out'))
File 
"/home/vponomaryov/Documents/python/projects/manila/.tox/py34/lib/python3.4/site-packages/eventlet/hubs/__init__.py",
 line 162, in trampoline
  return hub.switch()
File

Re: [openstack-dev] [oslo][nova][all] timeutils deprecation removals will break Nova

2015-12-21 Thread Davanum Srinivas 
Rob,

Can we set some goals for the server projects too?

Say anything deprecated in liberty timeframe in oslo libs or any other
libs we consume should be fixed by milestone2 in mitaka? At the moment
the burden is entirely on oslo and hence unfair.

Thanks,
Dims

On Mon, Dec 21, 2015 at 2:15 PM, Robert Collins
<robe...@robertcollins.net> wrote:
> On 21 December 2015 at 04:57, Davanum Srinivas <dava...@gmail.com> wrote:
>> Nova folks,
>>
>> We have this review in oslo.utils:
>> https://review.openstack.org/#/c/252898/
>>
>> There were failed effort in the past to cleanup in Nova:
>> https://review.openstack.org/#/c/164753/
>> https://review.openstack.org/#/c/197601/
>>
>> What do we do? Suggestions please.
>
> We don't remove it yet. Not till liberty-eol at the earliest, or if we
> don't get users migrated early enough, mitaka-eol.
>
> We would benefit from an automated thing in place to tell projects
> like Nova that they are using deprecated things during CI (without
> bloating deployer logs) -  whether a keystone API, an oslo config
> option or function, or $whatever. We would also benefit from a thing
> to rollup such information from consuming projects back to the
> deprecating project, so we can tell whether we're ready to cleanup old
> things.
>
> I think in general that there needs to be a balance around effort on
> migrations: if oslo deprecates something - anything - we're creating
> work for consumers of oslo. Its unfair for us to do that unilaterally.
> Conversely, if projects don't migrate away from poor APIs onto newer
> better ones, they create long term maintenance work for oslo: so we
> all need to work together to coordinate such things.
>
> https://review.openstack.org/#/c/226157/12 is part of this - it is an
> effort to bring consistency in expectations and process/patterns here.
>
> -Rob
>
> --
> Robert Collins <rbtcoll...@hpe.com>
> Distinguished Technologist
> HP Converged Cloud
>
> __
> 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



-- 
Davanum Srinivas :: https://twitter.com/dims

__
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] [oslo][nova][all] timeutils deprecation removals will break Nova

2015-12-20 Thread Davanum Srinivas 
Nova folks,

We have this review in oslo.utils:
https://review.openstack.org/#/c/252898/

There were failed effort in the past to cleanup in Nova:
https://review.openstack.org/#/c/164753/
https://review.openstack.org/#/c/197601/

What do we do? Suggestions please.

Thanks,
Dims

-- 
Davanum Srinivas :: https://twitter.com/dims

__
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] [oslo] stable/liberty branch needed for oslo-incubator

2015-12-17 Thread Davanum Srinivas 
Thierry,

Right, i believe it was on IRC and not a ML thread. Since there is no
urgency on this one, we can wait till Doug gets back to revisit the
decision.

Thanks,
Dims

On Thu, Dec 17, 2015 at 7:50 AM, Thierry Carrez <thie...@openstack.org> wrote:
> Matt Riedemann wrote:
>> On 12/13/2015 10:33 PM, Robert Collins wrote:
>>> On 14 December 2015 at 15:28, Matt Riedemann
>>> <mrie...@linux.vnet.ibm.com> wrote:
>>>> I don't have a pressing need to backport something right now, but as
>>>> long as
>>>> there was code in oslo-incubator that *could* be synced to other
>>>> projects
>>>> which wasn't in libraries, then that code could have bugs and code
>>>> require
>>>> backports to stable/liberty oslo-incubator for syncing to projects
>>>> that use
>>>> it.
>>>
>>> I thought the thing to do was backport the application of the change
>>> from the projects master?
>>
>> Unless the rules changed, things from oslo-incubator were always
>> backported to stable oslo-incubator and then sync'ed to the stable
>> branches of the affected projects. This is so we wouldn't lose the fix
>> in stable oslo-incubator which is shared across other projects, not just
>> the target project consuming the fix from oslo-incubator.
>
> I think I remember that the Oslo crew made a change there for the last
> branch before incubator removal (something like, "backport it directly
> to the local copy"). I couldn't quickly find a thread reference though.
> Maybe wait for Doug or dims to be around and chime in.
>
> --
> Thierry Carrez (ttx)
>
> ______
> 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



-- 
Davanum Srinivas :: https://twitter.com/dims

__
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] [oslo][keystone] Move oslo.policy from oslo to keystone

2015-12-17 Thread Davanum Srinivas 
Thinking more about it. The only change we'll have is that if someone
files a oslo-specs for oslo.policy we need to tell them to switch over
to keystone-specs. We could add notes in README etc to make this
apparent. So i am +1 to making this move.

Brant, other keystone cores,
Can you please file the governance review request and we can make sure
oslo cores chime in there? and make it official?

Thanks,
Dims


On Thu, Dec 17, 2015 at 2:40 PM, Flavio Percoco <fla...@redhat.com> wrote:
> On 16/12/15 18:51 -0800, Morgan Fainberg wrote:
>>
>> For what is is worth, we originally proposed oslo.policy to graduate to
>> Keystone when we were converting to the library. I still think it belongs
>> in
>> keystone (as long as the oslo team doesn't mind that long-term keystone
>> team
>> owns something in the oslo. namespace).
>>
>> The short term adding keystone-core should get some more eyes on the
>> reviews,
>> so +1 to that.
>
>
>
> Just want to +1 all the above.
>
> It'd be great if we can finally hand the library over to the keystone
> team, where I think it belongs.
>
> Cheers,
> Flavio
>
>>
>> --Morgan
>>
>> On Wed, Dec 16, 2015 at 4:08 PM, Davanum Srinivas <dava...@gmail.com>
>> wrote:
>>
>>As an interim measure, added keystone-core to oslo-policy-core[1]
>>
>>Thanks,
>>Dims
>>
>>[1] https://review.openstack.org/#/admin/groups/556,members
>>
>>On Wed, Dec 16, 2015 at 10:40 PM, Dolph Mathews
>> <dolph.math...@gmail.com>
>>wrote:
>>>
>>> On Wed, Dec 16, 2015 at 1:33 PM, Davanum Srinivas <dava...@gmail.com>
>>wrote:
>>>>
>>>> Brant,
>>>>
>>>> I am ok either way, guess the alternative was to add keystone-core
>>>> directly to the oslo.policy core group (can't check right now).
>>>
>>>
>>> That's certainly reasonable, and kind of what we did with pycadf.
>>>
>>>>
>>>>
>>>> The name is very possibly going to create confusion
>>>
>>>
>>> I assume you're not referring to unnecessarily changing the name of
>> the
>>> project itself (oslo.policy) just because there might be a shift in
>> the
>>> group of maintainers! Either way, let's definitely not do that.
>>>
>>>>
>>>> -- Dims
>>>>
>>>> On Wed, Dec 16, 2015 at 7:22 PM, Jordan Pittier
>>>> <jordan.pitt...@scality.com> wrote:
>>>> > Hi,
>>>> > I am sure oslo.policy would be good under Keystone's governance.
>> But I
>>>> > am
>>>> > not sure I understood what's wrong in having oslo.policy under the
>>oslo
>>>> > program ?
>>>> >
>>>> > Jordan
>>>> >
>>>> > On Wed, Dec 16, 2015 at 6:13 PM, Brant Knudson <b...@acm.org>
>> wrote:
>>>> >>
>>>> >>
>>>> >> I'd like to propose moving oslo.policy from the oslo program to
>> the
>>>> >> keystone program. Keystone developers know what's going on with
>>>> >> oslo.policy
>>>> >> and I think are more interested in what's going on with it so
>> that
>>>> >> reviews
>>>> >> will get proper vetting, and it's not like oslo doesn't have
>> enough
>>>> >> going on
>>>> >> with all the other repos. Keystone core has equivalent stringent
>>>> >> development
>>>> >> policy that we already enforce with keystoneclient and
>> keystoneauth,
>>so
>>>> >> oslo.policy isn't going to be losing any stability.
>>>> >>
>>>> >> If there aren't any objections, let's go ahead with this. I heard
>>this
>>>> >> requires a change to a governance repo, and gerrit permission
>> changes
>>>> >> to
>>>> >> make keystone-core core, and updates in oslo.policy to change
>> some
>>docs
>>>> >> or
>>>> >> links. Any oslo.policy specs that are currently proposed
>>>> >>
>>>> >> - Brant
>>>> >>
>>>> >>
>>>>

<    1   2   3   4   5   6   7   8   9   10   >