[openstack-dev] [puppet] running tempest on beaker jobs
Hi, I would like to propose to run Tempest at the end of the beaker jobs, for testing purpose now. As a start, we would accept 0 1 as return code, because this is really experimental. Though I think it will be interesting to see how it behaves, specially when we implement new configurations or plugins in our modules. I already did a PoC for puppet-keystone: https://review.openstack.org/198561 (failing because it needs more work to pass keystone v3 tests but v2 tests are successful). As you can see the code is really light, since we use puppet-tempest. Any suggestion is welcome ! -- Emilien Macchi __ 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] Hello,everyone ( keystone )
Hello everyone, Who can help me decide the importance of the bug? https://bugs.launchpad.net/keystone/+bug/1473639 By the way, help me review the bug: https://review.openstack.org/#/c/200512/__ 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] Time to remove Python2.6 jobs from master
This includes for client libraries too? --John On Jul 12, 2015, at 6:29 PM, Robert Collins robe...@robertcollins.net wrote: So, we've got constraints support for tox coming together nicely. The rollout for that will be per project (because tox.ini needs to change). However, we're not compiling, nor are we easily able to do so, a constraints set for Python 2.6. (We compile one unified file with all our constraints, which requires a VM with all the Python's we need to use installed on it). Enabling constraints on py2.6 tox jobs will fail to constrain anything which varies by Python version. So - folk that haven't disabled their 2.6 jobs (you know who you are) - you probably want to do so now in master. Its' my understanding that they were meant to be disabled during kilo but they've fallen through the cracks. -Rob -- Robert Collins rbtcoll...@hp.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 signature.asc Description: Message signed with OpenPGP using GPGMail __ 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] [puppet] running tempest on beaker jobs
We used Tempest for a time against our production environment. It was a pain to clean up but ephemeral test jobs solves that for you. A few questions: What version of tempest will be using? Will we maintain a blacklist if there are known failures? (although this is a pain to keep updated) On Sun, Jul 12, 2015 at 8:44 PM, Emilien Macchi emilien.mac...@gmail.com wrote: Hi, I would like to propose to run Tempest at the end of the beaker jobs, for testing purpose now. As a start, we would accept 0 1 as return code, because this is really experimental. Though I think it will be interesting to see how it behaves, specially when we implement new configurations or plugins in our modules. I already did a PoC for puppet-keystone: https://review.openstack.org/198561 (failing because it needs more work to pass keystone v3 tests but v2 tests are successful). As you can see the code is really light, since we use puppet-tempest. Any suggestion is welcome ! -- Emilien Macchi __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [murano] idea of introducing a spec-freeze, during M cycle
We had discussed this (see subj) interesting idea, during our latest meeting in IRC (http://eavesdrop.openstack.org/meetings/murano/2015/murano.2015-07-07-17.01.html) The idea was borrowed from nova, who froze their specs shortly after L1 release. The reasoning behind this is rather simple, as adding something, that requires a spec during a 2d half of the cycle, seems like a not so good idea. Knowing that there would be a spec freeze of some sort, would probably 1) make contributors want to write their specs beforehan 2) make reviewers review specs more often (although I’m not really sure if there is a good way to encourage spec reviews) What do you think about such an idea? Obviously introducing a spec-freeze for liberty (without proper prior notice) is a bad thing to do. But sounds like a reasonable idea for M cycle. Somewhere between M-1 and M-2, maybe? What do you think? -- Kirill Zaitsev Murano team Software Engineer Mirantis, Inc__ 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]: provider network use case supported?
You can mark the network as shared and have it exposed to all of your tenants. - Original Message - Hi, I'm running openstack ( IceHouse ) configured for provider networks. For a tenant i've created the network/ subnet using the below commands and everything works as expected. neutron net-create --tenant-id f557a3f5303d4e7c9218c5539456eb37 --provider:physical_network=physnet2 --provider:network_type= vlan --provider:segmentation_id=315 ih - lwr - ci -provider-vlan315 neutron subnet -create Openstack -External-vlan55 10.82.42.0/24 --name Openstack -External-vlan55- subnet --no-gateway --host-route destination= 0.0.0.0/0 , nexthop =10.82.42.1 --allocation-pool start=10.82.42.223,end=10.82.42.254 Now my questions/ use cases are: 1. For a 2nd tenant, can i map it to the same subnet created for tenant 1? If the answer is to create same net/ subnet (same segmentation_id - i.e vlans ) for tenant 2, how will dhcp agent avoid IP duplication. 2. Is having multiple tenants pointing to same provider network (net/ subnet / vlan ) is not possible what options do i have? Only to create a new net/ subnet based on new vlan and allocated to tenant 2? Cheers, Dani __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova][qa] turbo-hipster seems to be out to lunch
Hey, Yes, sorry, I only discovered this yesterday. I should have updated the wiki page sooner but I've placed some details there now: https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:stable/kilo+topic:fix-th,n,z Basically the removal of migrate-flavor-data from master broke turbo-hipster and a few of the patches to make it work just missed the cut-off for kilo. As such they are backported here: https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:stable/kilo+topic:fix-th,n,z Turbo-hipster is now disabled, blocked on getting those in so any help reviewing would be appreciated. Thanks, Josh On Sat, Jul 11, 2015 at 9:09 AM, Matt Riedemann mrie...@linux.vnet.ibm.com wrote: There are a lot of failures on nova changes since yesterday and rechecks today don't seem to be coming back (after rechecking several hours ago). Known issues? -- 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 __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [neutron]: provider network use case supported?
Hi, I'm running openstack (IceHouse) configured for provider networks. For a tenant i've created the network/ subnet using the below commands and everything works as expected. neutron net-create --tenant-id f557a3f5303d4e7c9218c5539456eb37 --provider:physical_network=physnet2 --provider:network_type=vlan --provider:segmentation_id=315 ih-lwr-ci-provider-vlan315 neutron subnet-create Openstack-External-vlan55 10.82.42.0/24 --name Openstack-External-vlan55-subnet --no-gateway --host-route destination= 0.0.0.0/0,nexthop=10.82.42.1 --allocation-pool start=10.82.42.223,end=10.82.42.254 Now my questions/ use cases are: 1. For a 2nd tenant, can i map it to the same subnet created for tenant 1? If the answer is to create same net/ subnet (same segmentation_id - i.e vlans) for tenant 2, how will dhcp agent avoid IP duplication. 2. Is having multiple tenants pointing to same provider network (net/ subnet/ vlan) is not possible what options do i have? Only to create a new net/ subnet based on new vlan and allocated to tenant 2? Cheers, Dani __ 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] [murano] idea of introducing a spec-freeze, during M cycle
Kirill, Here's the latest on the Nova freeze concept: http://lists.openstack.org/pipermail/openstack-dev/2015-June/068079.html -- dims On Sun, Jul 12, 2015 at 5:29 PM, Kirill Zaitsev kzait...@mirantis.com wrote: We had discussed this (see subj) interesting idea, during our latest meeting in IRC (http://eavesdrop.openstack.org/meetings/murano/2015/murano.2015-07-07-17.01.html) The idea was borrowed from nova, who froze their specs shortly after L1 release. The reasoning behind this is rather simple, as adding something, that requires a spec during a 2d half of the cycle, seems like a not so good idea. Knowing that there would be a spec freeze of some sort, would probably 1) make contributors want to write their specs beforehan 2) make reviewers review specs more often (although I’m not really sure if there is a good way to encourage spec reviews) What do you think about such an idea? Obviously introducing a spec-freeze for liberty (without proper prior notice) is a bad thing to do. But sounds like a reasonable idea for M cycle. Somewhere between M-1 and M-2, maybe? What do you think? -- Kirill Zaitsev Murano team Software Engineer Mirantis, Inc __ 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][tests] Fix it friday! [mock failure in CI]
Has anyone else seen this error with the new mock? 'self' parameter lacking default value My function under test runs correctly, but then Mock throws this TypeError when comparing the parameters in assert_calls_with(). I'm seeing this in Barbican. More info below [1][2]. --Dave [1] Complete backtrace == FAIL: barbican.tests.plugin.test_kmip.WhenTestingKMIPSecretStore.test_store_passp hrase_secret_assert_called -- _StringException: Traceback (most recent call last): File /Users/dmccowan/barbican/barbican/tests/plugin/test_kmip.py, line 432, in test_store_passphrase_secret_assert_called credential=self.credential) File /Users/dmccowan/.pyenv/versions/barb278/lib/python2.7/site-packages/mock/m ock.py, line 941, in assert_called_once_with return self.assert_called_with(*args, **kwargs) File /Users/dmccowan/.pyenv/versions/barb278/lib/python2.7/site-packages/mock/m ock.py, line 930, in assert_called_with six.raise_from(AssertionError(_error_message(cause)), cause) File /Users/dmccowan/.pyenv/versions/barb278/lib/python2.7/site-packages/six.py , line 692, in raise_from raise value AssertionError: Expected call: mock(credential=Struct(), object_type=ObjectType.SECRET_DATA: 7, secret=ANY, template_attribute=ANY) Actual call: mock(credential=Struct(), object_type=ObjectType.SECRET_DATA: 7, secret=Struct(), template_attribute=Struct()) 'self' parameter lacking default value [2] A CR (containing other unit test fixes) that is failing with this https://review.openstack.org/200824 On 7/10/15, 3:45 AM, Robert Collins robe...@robertcollins.net wrote: Good news everybody, mock 1.1.0 is now out. This backports all the improvements over the last couple of years, making it fully synchronised with cPython master. Yay. Bad news. Lots of unit tests jobs have suffered falled from this. But - none of the things I've looked into so far are bugs in mock 1.1.0. One of the improvements in mock is to fail when a bad method is called. Consider this: https://review.openstack.org/#/c/200384/1/taskflow/tests/unit/test_engine_ helpers.py Note the old method: mock_import.assert_called_onec_with(name) That method never existed. onec is a typo :). mock 1.0.1 silently accepts that - thats part of its job. But, its a very fragile API. 1.1.0 makes that an error, for methods with assert prefixes - unless unsafe is specifically requested. So a big chunk of the failing tests are tests that were not testing anything *at all*. One common exampled of that is 'assert_called' - another method that never ever existed. All our tests using that were testing nothing at all. Neutron is failing on a bunch of tests that accessed a private function inside mock. I'm surprised reviewers didn't spot this, but _patch isn't part of the public API, and never was. Tempest seems to be failing due to a different object being returned - I haven't dug deep enough to describe the cause in more detail. We can probably pin mock back to 1.0.1 locally within projects to gain breathing room, but given the API improvements in 1.1.0 (see below[1] as readthedocs is failing to build it due to having an old pip in their virtualenvs :/) - I think we'll be much better off adopting it as quickly as we can. NB: with this release we don't need to use 'unittest.mock' for Python3.4 - we can just standardise on using 'mock' across the board, which is much simpler and easier to reason about (same codebase everywhere[2]) [2]: Python 2.6 support was dropped in 1.1.0, so we need to use markers to select 1.0.1 for the remaining 2.6 gate jobs. (We should kill those of asap). [1]: - Issue #23310: Fix MagicMock's initializer to work with __methods__, just like configure_mock(). Patch by Kasia Jachim. - Issue #23568: Add rdivmod support to MagicMock() objects. Patch by Håkan Lövdahl. - Issue #23581: Add matmul support to MagicMock. Patch by Håkan Lövdahl. - Issue #23326: Removed __ne__ implementations. Since fixing default __ne__ implementation in issue #21408 they are redundant. *** NOT BACKPORTED *** - Issue #21270: We now override tuple methods in mock.call objects so that they can be used as normal call attributes. - Issue #21256: Printout of keyword args should be in deterministic order in a mock function call. This will help to write better doctests. - Issue #21262: New method assert_not_called for Mock. It raises AssertionError if the mock has been called. - Issue #21238: New keyword argument `unsafe` to Mock. It raises `AttributeError` incase of an attribute startswith assert or assret. - Issue #21239: patch.stopall() didn't work deterministically when the same name was patched more than once. - Issue #21222: Passing name keyword argument to mock.create_autospec now works. - Issue #17826: setting an iterable side_effect on a mock function created by create_autospec
[openstack-dev] [all] Time to remove Python2.6 jobs from master
So, we've got constraints support for tox coming together nicely. The rollout for that will be per project (because tox.ini needs to change). However, we're not compiling, nor are we easily able to do so, a constraints set for Python 2.6. (We compile one unified file with all our constraints, which requires a VM with all the Python's we need to use installed on it). Enabling constraints on py2.6 tox jobs will fail to constrain anything which varies by Python version. So - folk that haven't disabled their 2.6 jobs (you know who you are) - you probably want to do so now in master. Its' my understanding that they were meant to be disabled during kilo but they've fallen through the cracks. -Rob -- Robert Collins rbtcoll...@hp.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
Re: [openstack-dev] [Sahara] Questions about how Sahara use trust ?
Hi Andrew, Thanks for the reply. Are you mean : 1. admin user is used by transient cluster is mainly to make it work. 2. The proxy user is the more secure way to do the same thing. Should we use proxy user at all situation then ? Should this be a bp or just a bug ? Thanks. -chen From: Andrew Lazarev [mailto:alaza...@mirantis.com] Sent: Friday, July 10, 2015 11:39 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Sahara] Questions about how Sahara use trust ? Hi Chen, As I remember, proxy users were added for security reasons. When one user creates cluster in Sahara he should not get access to data of other users. Thanks, Andrew. On Thu, Jul 9, 2015 at 11:12 PM, Li, Chen chen...@intel.commailto:chen...@intel.com wrote: Hi Sahara guys, When sahara create a transient cluster, it create a trust with sahara admin user. https://github.com/openstack/sahara/blob/master/sahara/service/ops.py#L239-L240 https://github.com/openstack/sahara/blob/master/sahara/service/trusts.py#L79 When sahara deal with swift, it create a trust too, but : sahara admin user = create a proxy domain = set in sahara.conf = sahara create proxy user in the domain. = create a trust with the proxy user. https://github.com/openstack/sahara/blob/master/sahara/utils/proxy.py#L110 https://github.com/openstack/sahara/blob/master/sahara/utils/proxy.py#L265 My questions are : Why not user proxy user for transient cluster ? Or, why a proxy user is needed for swift but not use sahara admin user directly ? Looking forward to your reply. Thanks. -chen __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribehttp://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] devstack installation problem
I just ran into this issue because I was installing a package that was bringing in keystonemiddleware 1.5.x which was downgrading pbr to 1.0. I fixed this problem by upgrading keystonemiddleware to 2.x.x with: pip install -U keystonemiddleware After that, devstack worked fine again. This break happened after the RDO packages used in devstack were changed from Juno to Kilo. Skyler Berg The 07/11/2015 18:18, Jeremy Stanley wrote: On 2015-07-11 18:09:26 + (+), Jeremy Stanley wrote: On 2015-07-11 22:49:27 +0530 (+0530), Venkateswarlu P wrote: After running ./stack.sh I am getting the following error. 015-07-11 17:01:02.188 | error in setup command: 'tests_require' must be a string or list of strings containing valid project/version requirement specifiers; Expected ',' or end-of-list in python-ldap=2.4;python_version=='2.7' at ;python_version=='2.7' [...] That's an indication something's dragging in an older PBR release that didn't know not to copy environment markers into tests_require. Without more of the logs indicating what installed which versions of PBR and why, it's hard to tell you any more than that. Are you running from the DevStack master branch or a stable/something branch? Oh, I also meant to add that if you're re-running stack.sh on a machine where you've already run it before, this is a known issue. See https://launchpad.net/bugs/1468808 for a detailed explanation and current workaround. -- Jeremy Stanley __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Cinder]Restrict volume creation based on type
Hi, Forgot to mention, indeed we configured extra_specs: volume_backend_name. The problem is that a volume of this type can get scheduled on a node where c-vol is not configured with this backend. F.e.: I have 3 storage nodes (c-vol) and two have the driver configured, the third one doesn't have it; when i try to create a volume of this type, sometimes the c-vol on third node gets the call, and it fails because the driver is not configured. Maybe we didn't configure something properly, i tried looking at c-sch but i can't figure out why the third node got chosen. Thanks, Eduard __ 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] [Requirements][Routes][Senlin] Which version of Routes to use now?
Hi, Tried these in requirements.txt: Routes!=2.0,!=2.1,=1.12.3;python_version=='2.7' Routes!=2.0,=1.12.3;python_version!='2.7' The gate still complains: Requirement set([Requirement(package=u'Routes', location='', specifiers='!=2.0,!=2.1,=1.12.3', markers=upython_version=='2.7', comment=''), Requirement(package=u'Routes', location='', specifiers='!=2.0,=1.12.3', markers=upython_version!='2.7', comment='')]) does not match openstack/requirements value set([Requirement(package='Routes', location='', specifiers='!=2.0,!=2.1,=1.12.3', markers='', comment='')]) Am I supposed to propose a change to the global-requirements to make this work? Thanks. Qiming On Sat, Jul 04, 2015 at 02:33:51PM +1200, Robert Collins wrote: Yes. Use environment markers to specify= 2 for portion 2.7 and uncapped for 3.4. On 4 Jul 2015 2:19 pm, Qiming Teng teng...@linux.vnet.ibm.com wrote: The recent change to global-requirements is excluding both 2.0 and 2.1 version of Routes. That is forcing us to use Routes 1.13. However, Routes 1.13 cannot pass py34 tests due to errors like this: /home/jenkins/workspace/gate-senlin-python34/.tox/py34/lib/python3.4/site-packages/routes/route.py, line 101, in _setup_route for key, val in self.reqs.iteritems(): AttributeError: 'dict' object has no attribute 'iteritems' Any suggestions on a workaround? Thanks. Regards, Qiming __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [magnum] Tom Cammann for core
+1 Welcome!! -- OTSUKA, Motohiro Sent with Sparrow (http://www.sparrowmailapp.com/?sig) On Friday, July 10, 2015 at 21:50, Hongbin Lu wrote: +1 Welcome Tom! -Original Message- From: Adrian Otto [mailto:adrian.o...@rackspace.com] Sent: July-09-15 10:21 PM To: OpenStack Development Mailing List Subject: [openstack-dev] [magnum] Tom Cammann for core Team, Tom Cammann (tcammann) has become a valued Magnum contributor, and consistent reviewer helping us to shape the direction and quality of our new contributions. I nominate Tom to join the magnum-core team as our newest core reviewer. Please respond with a +1 vote if you agree. Alternatively, vote -1 to disagree, and include your rationale for consideration. Thanks, Adrian __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe (mailto:openstack-dev-requ...@lists.openstack.org?subject:unsubscribe) http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe (mailto:openstack-dev-requ...@lists.openstack.org?subject:unsubscribe) http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [nova-scheduler] Scheduler sub-group meeting - Agenda 7/13
Meeting on #openstack-meeting at 1400 UTC (8:00AM MDT) 1) Liberty specs - https://etherpad.openstack.org/p/liberty-nova-priorities-tracking 2) Mid-cycle meetup 3) Opens -- Don Dugger Censeo Toto nos in Kansa esse decisse. - D. Gale Ph: 303/443-3786 __ 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] [Cinder]Restrict volume creation based on type
It sounds like the extra specs you configured are not selective enough. Can you post up your 3 cinder.conf files from the c-vol nodes, and the commands used to create the volume type, please? On 13 Jul 2015 08:00, Eduard Matei eduard.ma...@cloudfounders.com wrote: Hi, Forgot to mention, indeed we configured extra_specs: volume_backend_name. The problem is that a volume of this type can get scheduled on a node where c-vol is not configured with this backend. F.e.: I have 3 storage nodes (c-vol) and two have the driver configured, the third one doesn't have it; when i try to create a volume of this type, sometimes the c-vol on third node gets the call, and it fails because the driver is not configured. Maybe we didn't configure something properly, i tried looking at c-sch but i can't figure out why the third node got chosen. Thanks, Eduard __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Requirements][Routes][Senlin] Which version of Routes to use now?
Right - all changes to requirements.txt in a project must be already in global-requirements. So propose it there, get that merged, then propose into your local project. -Rob On 13 July 2015 at 17:08, Qiming Teng teng...@linux.vnet.ibm.com wrote: Hi, Tried these in requirements.txt: Routes!=2.0,!=2.1,=1.12.3;python_version=='2.7' Routes!=2.0,=1.12.3;python_version!='2.7' The gate still complains: Requirement set([Requirement(package=u'Routes', location='', specifiers='!=2.0,!=2.1,=1.12.3', markers=upython_version=='2.7', comment=''), Requirement(package=u'Routes', location='', specifiers='!=2.0,=1.12.3', markers=upython_version!='2.7', comment='')]) does not match openstack/requirements value set([Requirement(package='Routes', location='', specifiers='!=2.0,!=2.1,=1.12.3', markers='', comment='')]) Am I supposed to propose a change to the global-requirements to make this work? Thanks. Qiming On Sat, Jul 04, 2015 at 02:33:51PM +1200, Robert Collins wrote: Yes. Use environment markers to specify= 2 for portion 2.7 and uncapped for 3.4. On 4 Jul 2015 2:19 pm, Qiming Teng teng...@linux.vnet.ibm.com wrote: The recent change to global-requirements is excluding both 2.0 and 2.1 version of Routes. That is forcing us to use Routes 1.13. However, Routes 1.13 cannot pass py34 tests due to errors like this: /home/jenkins/workspace/gate-senlin-python34/.tox/py34/lib/python3.4/site-packages/routes/route.py, line 101, in _setup_route for key, val in self.reqs.iteritems(): AttributeError: 'dict' object has no attribute 'iteritems' Any suggestions on a workaround? Thanks. Regards, Qiming __ 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 -- Robert Collins rbtcoll...@hp.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
Re: [openstack-dev] [Openstack] [Openstack-operators] Rescinding the M name decision
+1 for this 2015-07-10 18:19 GMT+09:00 Thierry Carrez thie...@openstack.org: Adam Lawson wrote: The alternative of course is to just number the releases since names ultimately don't mean anything but it seems there are problems with that level of simplicity. I personally prefer Tristan's suggestion to keep it as simple as possible. In a few years we'll run out of letters anyway. Part of the confusion here is that we are not naming releases. We are naming release *cycles*. We are giving a name to a period of time, basically. In that period of time, various version numbers for various components will be released. Saying Glance 12.0.0 was released in OpenStack 13 cycle is not really helping. We won't run out of letters, because the names can cycle back to A (potentially using a new theme, away from geographic features near where the corresponding design summit happened). So while we could technically name a release cycle 14, I feel it's a bit more difficult to rally around a number than a name. Also, numbers wouldn't really solve the perceived issues with names: numbers happen to also be culturally meaningful. You don't have a 13th floor in many US buildings. In China, building miss the 4th floor instead. 9 is feared in Japan. And don't talk about 39 to Afghans. I think growing up is accepting the pain that comes with picking a good name, rather than sidestepping the issue. -- Thierry Carrez (ttx) ___ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openst...@lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack __ 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] [swift] [ceilometer] Ceilometer log dir permissions bust swift proxy
On Fri, Jul 10, 2015 at 1:57 AM, Mark Kirkwood mark.kirkw...@catalyst.net.nz wrote: Hi, I'm deploying a swift 1.13 cluster on Ubuntu 14.04 and enabling ceilometer in the proxy pipeline results in it not working. The cause appears to be the log directory perms (note I am running the proxy under Apache): [Fri Jul 10 05:12:15.126214 2015] [:error] [pid 6844:tid 140048779998976] [remote 192.168.5.1:21419] IOError: [Errno 13] Permission denied: '/var/log/ceilometer/proxy-server.wsgi.log' Sure enough: $ ls -la /var/log/ceilometer/ total 16 drwxr-x--- 2 ceilometer adm4096 Jul 10 02:55 . Looking at the swift user: $ id swift uid=50144(swift) gid=50145(swift) groups=50145(swift),4(adm),106(puppet),115(ceilometer) This looks like https://bugs.launchpad.net/swift/+bug/1269473 but the code I have includes the fix for that. In fact it looks like the directory permissions are just being set wrong (indeed chmod'ing them to be 770 fixes this). Am I missing something? I don't see how this can possibly work unless the directory allows group write. I think this is something that could be fixed in packaging scripts. I can see you're using Puppet to deploy OpenStack, and fwiw, we are stopping to manage permissions in Puppet because of packaging overlap. From now, we totally rely on packaging permissions. We are in the process to drop all the code that hardcode POSIX User/groups/permissions in our manifests. Regards Mark __ 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 -- Emilien Macchi __ 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
