[openstack-dev] [oslo][oslo.service] Bootstrapping oslo.service core
Elena Ezhova and Marian Horban helped get oslo.service off the ground [1] with a lot of testing and are actively coordinating adoption by several projects like Nova, Neutron and Cinder etc. Since we don't have anyone in oslo-service-core at the moment, Let's add them as the initial core members of oslo.service. Thanks, dims [1] http://stackalytics.com/?module=oslo.servicemetric=commitsrelease=liberty -- 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][messaging] Expanding the oslo.messaging core team
Hi Team, We have had active and continuing contributions [1] from the following in Blueprints, Reviews, Commits and Summit/Email discussions: * Ken Giusti * Oleksii Zamiatin * Victor Sergeyev Ken and Oleksii are spearheading important drivers that will help expand choices of messaging infrastructure in OpenStack to boot and Victor is helping harden the existing code. So can we please invite them to join the oslo.messaging core team Thanks, Dims [1] http://stackalytics.com/?module=oslo.messaging -- 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] FYI - dropping non RabbitMQ support in devstack
yay! thanks Sean. -- dims On Thu, Jun 18, 2015 at 9:36 AM, Sean Dague s...@dague.net wrote: On 06/18/2015 06:49 AM, Sean Dague wrote: On 06/18/2015 03:28 AM, ozamiatin wrote: Hi, please don't remove zmq support from devstack. We are now in progress of writing a new version of the driver. I use devstack each time to check the driver functionality. When the implementation become public it will be even more important to have a possibility to check it on devstack. Which will be extremely easy to continue doing with an external plugin, and also make it much simpler for you to add new enhancements to it. Your development workflow would be add the following line to your localrc: enable_plugin zmq git://.. And will continue exactly the same in usage pattern of devstack after that. So, instead of further explaining that this was going to be easy to do out of tree, I did it for the 0mq case. https://github.com/sdague/zmq-devstack is up and ready to go. It creates the same functional environment as the in code. You can demonstrate that by doing the following: git clone https://github.com/openstack-dev/devstack cd devstack git review -d 192154 (this is the code which deletes all the non rabbit code from the devstack tree) echo enable_plugin zmq-devstack https://github.com/sdague/zmq-devstack; localrc ./stack.sh Which I just did and tested in a local 14.04 vagrant (easily built with devstack-vagrant project). Looked through all the logs, things look like they are working to some degree. Saw a couple of stack traces that looked non fatal in nova-conductor, which would be the current state of the zmq driver from my understanding. I did not functionally test this beyond that, because from a devstack interface point of view, all the things devstack used to do (install redis, zmq code, start the oslo messaging zmq receiver, and setup all the config files for all the projects) match the output of the old code. The effort could use a README like the other devstack plugins have, to document to prospective users what variables they have access when using this. I'll leave that as an exercise for whenever someone imports this into gerrit to take ownership of it. Other drivers should be able to pretty closely model this in about 30 minutes of work. The install and post-config phases are probably the only ones you need. (install for installing code, post-config for starting servers). User friendly plugins will want to also want to implement clean and maybe unstack. (clean is implemented here, because it was in the old code). -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] [all] setup.py executable bit
+1 both to using -x and to removing the shebang. On Wed, Jun 17, 2015 at 2:47 PM, Doug Hellmann d...@doughellmann.com wrote: Excerpts from Robert Collins's message of 2015-06-18 06:40:33 +1200: An unintended side effect of the requirements refactoring was that we changed from preserving the 'x' bit on setup.py, to discarding it. This happened when we started writing the file atomically rather than in-place - a good robustness improvement. Previously the requirements sync, which enforces setup.py contents had made no statement about the file mode. Now it unintentionally is. We could do several things: - preserve the file mode (stat the old, use its mode in open on the temp file) - force the mode to be +x - force the mode to be -x [the current behaviour] After a brief IRC discussion in #openstack-olso we're proposing that forcing the mode to be -x is appropriate. Our reasoning is as follows: - './setup.py XYZ' is often a bug - unless the shebang in the setup.py is tolerant of virtualenvs (not all are), it will do the wrong thing in a virtual env. Similarly with PATH. - we don't require or suggest users of our requirements syncronised packages run setup.py at all: - sdists and releases are made in the CI infrastructure - installation is exclusively via pip So it seems like a slight safety improvement to remove the x bit - and possibly (we haven't thought it all the way through yet) also remove the shebang entirely, so that the contract becomes explicitly 'setup.py is not executable'. Please raise concerns or objections here; if there are none I'll likely put up a patch to remove the shebang early next week, or whenever I get reminded of this. +1 both to using -x and to removing the shebang. 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] FYI - dropping non RabbitMQ support in devstack
+1 Sean. -- dims On Tue, Jun 16, 2015 at 9:22 AM, Sean Dague s...@dague.net wrote: FYI, One of the things that came out of the summit for Devstack plans going forward is to trim it back to something more opinionated and remove a bunch of low use optionality in the process. One of those branches to be trimmed is all the support for things beyond RabbitMQ in the rpc layer. RabbitMQ is what's used by 95%+ of our community, that's what the development environment should focus on. The patch to remove all of this is here - https://review.openstack.org/#/c/192154/. Expect this to merge by the end of the month. If people are interested in non RabbitMQ external plugins, now is the time to start writing them. The oslo.messaging team already moved their functional test installation for alternative platforms off of devstack, so this should impact a very small number of people. -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
[openstack-dev] [oslo][all] Request from Oslo team for Liberty Cycle
Hello fellow stackers, The Oslo team came up with a handful of requests to the projects that use Oslo-*. Here they are: 0. Check if your project has a Oslo Liaison Please see https://wiki.openstack.org/wiki/CrossProjectLiaisons#Oslo and volunteer for your project. We meet once a week to go over specs, issues with releases, etc. If you can't attend the meetings, review the logs and send questions/feedback to the -dev mailing list or hop onto #openstack-oslo channel. If you filter the -dev mailing list, include the [oslo] topic in your whitelist to ensure you see team announcements. 1. Update files from oslo-incubator Check what files you have listed in [my_project]/openstack-common.conf and under [my_project]/openstack/common/* tree. You can run the update.py script in oslo-incubator (https://github.com/openstack/oslo-incubator/blob/master/update.py) to refresh the files in your project. You may see that some of the files you may have already graduated into a library, in which case you will need to switch to the library. 2. Use oslo.context with oslo.log Several projects still have a custom RequestContext. For oslo.log to log the details stored in the RequestContext, you will need to extend your custom RequestContext from the one in oslo.context. See example in Nova - https://github.com/openstack/nova/blob/master/nova/context.py 3. Switch to oslo-config-generator The discovery mechanism in the old style generator.py is fragile and hence we have replaced it with a better (at least in our eyes!) solution. Please see http://specs.openstack.org/openstack/oslo-specs/specs/juno/oslo-config-generator.html. This will help generate configuration files for different services with different content/options as well. 4. Review new libraries to be added in Liberty and older ones from Kilo Please see the specs we have for Liberty - http://specs.openstack.org/openstack/oslo-specs/ We have a handful of new libraries from existing oslo-incubator code as well as some brand new ones like futurist and automaton that are not oslo specific and very useful (Don't forget Debtcollector, tooz, taskflow from Kilo). Projects like oslo.versionedobjects is getting a lot of traction as well. So please review what's useful to your project and let us know if you need more information. Thanks, The Oslo Team -- 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.vmware] Bump oslo.vmware to 1.0.0
+1 to the plan garyk, vipin et.al -- dims On Mon, Jun 15, 2015 at 7:00 AM, Gary Kotton gkot...@vmware.com wrote: Hi, The email mail below was a little cryptic so here is the general plan to move forwards: 1. Oslo.vmware:- rebase and update the patch https://review.openstack.org/#/c/114503. This will sort out the issues that we have with the exception hierarchy 2. Nova: hopefully manage to get reviews for https://review.openstack.org/191569. This will ensure that Nova works with the exceptions in the existing and future formats (and ensure that we do not go through the debacle that we hit with 0.13.0). Please note that I have tested this with the current version and the aforementioned evrsion and it works 3. We will make a few extra cleanups in Nova as there are some exceptions in the driver that are imported from oslo.vmware and they are specific for nova. So hopefully we can get concensus on the plan and move forwards. A luta continua Thanks Gary On 6/14/15, 5:34 PM, Gary Kotton gkot...@vmware.com wrote: Hi, I agree with Vipin. Can we please address the exception handling. We already have the patches. Thanks Gary On 6/14/15, 12:41 PM, Vipin Balachandran vbalachand...@vmware.com wrote: Dims, There are some problems with exception hierarchy which need to be fixed. -Original Message- From: Davanum Srinivas [mailto:dava...@gmail.com] Sent: Tuesday, June 09, 2015 7:32 PM To: OpenStack Development Mailing List (not for usage questions) Subject: [openstack-dev] [oslo.vmware] Bump oslo.vmware to 1.0.0 Gary, Tracy, Vipin and other contributors, Is oslo.vmware API solid enough for us to bump to 1.0.0? if not, what's left to be done? thanks, dims -- Davanum Srinivas :: https://urldefense.proofpoint.com/v2/url?u=https-3A__twitter.com_dimsd=B Q ICAgc=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEsr=CTAUyaHvyUUJ-0QHvizt Q xBhCDLLSg1DksoSE4TOfZ8m=kJNU_fkxhspoxLdOSLde2j2GO0QDJLhUi8W9uh6x5V4s=_U 0 Uo0Fogc_CkxUAPs9E2ql0AbSNYzFJ4YRjsq7qdv8e= _ _ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev _ _ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- 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] Getting rid of suds, which is unmaintained, and which we want out of Debian
Thomas,
Is anyone willing to the work needed to get the existing Nova vmware
driver scenarios with any alternate python library acceptable to
Debian? If not, this discussion is moot.
-- dims
On Mon, Jun 15, 2015 at 9:16 AM, Thomas Goirand z...@debian.org wrote:
On 06/15/2015 11:31 AM, Joe Gordon wrote:
Nova itself doesn't depend on suds anymore.
A quick grep still shows references to suds (that's in Kilo, but the
master branch shows similar results):
etc/nova/logging_sample.conf:qualname = suds
nova/tests/unit/test_hacking.py: def
fake_suds_context(calls={}):
nova/tests/unit/virt/vmwareapi/test_vim_util.py:with
stubs.fake_suds_context(calls):
nova/tests/unit/virt/vmwareapi/stubs.py:def fake_suds_context(calls=None):
nova/tests/unit/virt/vmwareapi/stubs.py:Generate a suds client
which automatically mocks all SOAP method calls.
nova/tests/unit/virt/vmwareapi/stubs.py:
mock.patch('suds.client.Client', fake_client),
nova/tests/unit/virt/vmwareapi/test_driver_api.py:import suds
nova/tests/unit/virt/vmwareapi/test_driver_api.py:
mock.patch.object(suds.client.Client,
nova/tests/unit/virt/vmwareapi/fake.py:Fake factory class for the
suds client.
nova/tests/unit/virt/vmwareapi/fake.py:Initializes the suds
client object, sets the service content
nova/virt/vmwareapi/vim_util.py:import suds
nova/virt/vmwareapi/vim_util.py:for k, v in
suds.sudsobject.asdict(obj).iteritems():
nova/config.py: 'qpid=WARN', 'sqlalchemy=WARN',
'suds=INFO',
test-requirements.txt:suds=0.4
Oslo.vmware has a suds
dependency, but that is only needed if you are using the vmware virt
driver in nova.
It's used in unit tests, no?
So nova's vmware driver depends on suds (it may be suds-jurko these
days)
As I wrote, suds-jurko isn't acceptable either, as it's also not
maintained upstream.
but not nova in general.
If we don't want suds, we don't want suds. Not just it's only in some
parts kind of answer. Especially, it should appear in
tests-requirements.txt and in vmwareapi unit tests. Don't you think?
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] [Magnum] Make functional tests voting
+1 from me Tom. On Mon, Jun 15, 2015 at 1:15 PM, Tom Cammann tom.camm...@hp.com wrote: Hello, I haven't seen any false positives in a few weeks from the functional tests, but I have seen a couple reviewers missing the -1 from the non-voting job when there has been a legitimate failures. I think now would be a good time to turn 'check-functional-dsvm-magnum' to voting. Thanks, Tom __ 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] [api][nova][ironic] Microversion API HTTP header
+1 from me to remove 'X-' -- dims On Mon, Jun 15, 2015 at 6:18 PM, Jay Pipes jaypi...@gmail.com wrote: On 06/15/2015 05:58 PM, Ed Leafe wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 06/15/2015 04:30 PM, Michael Davies wrote: On Tue, Jun 16, 2015 at 5:15 AM, Kevin L. Mitchell kevin.mitch...@rackspace.com mailto:kevin.mitch...@rackspace.com wrote: Given the disagreement evinced by the responses to this thread, let me ask a question: Would there be any particular problem with using X-OpenStack-API-Version? Well, perhaps we should consider OpenStack-API-Version instead and drop the X-. Ref https://tools.ietf.org/html/rfc6648. That makes the most sense to me. Sure, agreed that a removal of the X- makes sense. -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
[Yahoo-eng-team] [Bug 1442174] Re: can not print request_id in some logs when booting an instance
Already fixed in: https://review.openstack.org/#/c/171299/ ** Changed in: nova Status: Confirmed = 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/1442174 Title: can not print request_id in some logs when booting an instance Status in OpenStack Compute (Nova): Fix Released Bug description: nova keeps the RequestConext in threading.local, so it can print the request_id in the logs. But when booting an instance, it spawns a new greenthread to build the instance. The RequestContext is not kept in the threading.local of the new greenthread, so we can not print the request_id in the logs. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1442174/+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 1413142] Re: bad configuration for libguestfs
** 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/1413142 Title: bad configuration for libguestfs Status in devstack - openstack dev environments: New Status in OpenStack Compute (Nova): New Bug description: An error is reported by guestfs when exercising but hidden by an except reported in a log level DEBUG: http://git.openstack.org/cgit/openstack/nova/tree/nova/virt/disk/api.py#n214 In Nova a clean is in progress on this part of code; We normally would like to break the process if something goes wrong at this step. However the CI failed since the except has been removed: https://review.openstack.org/#/c/119104/18/nova/virt/disk/api.py,cm 2015-01-15 15:19:35.840 28636 ERROR nova.compute.manager [-] [instance: 162caeb6-5a8e-413f-8df2-300cf4e66202] Instance failed to spawn 2015-01-15 15:19:35.840 28636 TRACE nova.compute.manager [instance: 162caeb6-5a8e-413f-8df2-300cf4e66202] Traceback (most recent call last): 2015-01-15 15:19:35.840 28636 TRACE nova.compute.manager [instance: 162caeb6-5a8e-413f-8df2-300cf4e66202] File /opt/stack/new/nova/nova/compute/manager.py, line 2290, in _build_resources 2015-01-15 15:19:35.840 28636 TRACE nova.compute.manager [instance: 162caeb6-5a8e-413f-8df2-300cf4e66202] yield resources 2015-01-15 15:19:35.840 28636 TRACE nova.compute.manager [instance: 162caeb6-5a8e-413f-8df2-300cf4e66202] File /opt/stack/new/nova/nova/compute/manager.py, line 2160, in _build_and_run_instance 2015-01-15 15:19:35.840 28636 TRACE nova.compute.manager [instance: 162caeb6-5a8e-413f-8df2-300cf4e66202] flavor=flavor) 2015-01-15 15:19:35.840 28636 TRACE nova.compute.manager [instance: 162caeb6-5a8e-413f-8df2-300cf4e66202] File /opt/stack/new/nova/nova/virt/libvirt/driver.py, line 2391, in spawn 2015-01-15 15:19:35.840 28636 TRACE nova.compute.manager [instance: 162caeb6-5a8e-413f-8df2-300cf4e66202] admin_pass=admin_password) 2015-01-15 15:19:35.840 28636 TRACE nova.compute.manager [instance: 162caeb6-5a8e-413f-8df2-300cf4e66202] File /opt/stack/new/nova/nova/virt/libvirt/driver.py, line 2790, in _create_image 2015-01-15 15:19:35.840 28636 TRACE nova.compute.manager [instance: 162caeb6-5a8e-413f-8df2-300cf4e66202] project_id=instance['project_id']) 2015-01-15 15:19:35.840 28636 TRACE nova.compute.manager [instance: 162caeb6-5a8e-413f-8df2-300cf4e66202] File /opt/stack/new/nova/nova/virt/libvirt/imagebackend.py, line 201, in cache 2015-01-15 15:19:35.840 28636 TRACE nova.compute.manager [instance: 162caeb6-5a8e-413f-8df2-300cf4e66202] *args, **kwargs) 2015-01-15 15:19:35.840 28636 TRACE nova.compute.manager [instance: 162caeb6-5a8e-413f-8df2-300cf4e66202] File /opt/stack/new/nova/nova/virt/libvirt/imagebackend.py, line 478, in create_image 2015-01-15 15:19:35.840 28636 TRACE nova.compute.manager [instance: 162caeb6-5a8e-413f-8df2-300cf4e66202] copy_qcow2_image(base, self.path, size) 2015-01-15 15:19:35.840 28636 TRACE nova.compute.manager [instance: 162caeb6-5a8e-413f-8df2-300cf4e66202] File /usr/local/lib/python2.7/dist-packages/oslo_concurrency/lockutils.py, line 431, in inner 2015-01-15 15:19:35.840 28636 TRACE nova.compute.manager [instance: 162caeb6-5a8e-413f-8df2-300cf4e66202] return f(*args, **kwargs) 2015-01-15 15:19:35.840 28636 TRACE nova.compute.manager [instance: 162caeb6-5a8e-413f-8df2-300cf4e66202] File /opt/stack/new/nova/nova/virt/libvirt/imagebackend.py, line 444, in copy_qcow2_image 2015-01-15 15:19:35.840 28636 TRACE nova.compute.manager [instance: 162caeb6-5a8e-413f-8df2-300cf4e66202] disk.extend(target, size, use_cow=True) 2015-01-15 15:19:35.840 28636 TRACE nova.compute.manager [instance: 162caeb6-5a8e-413f-8df2-300cf4e66202] File /opt/stack/new/nova/nova/virt/disk/api.py, line 167, in extend 2015-01-15 15:19:35.840 28636 TRACE nova.compute.manager [instance: 162caeb6-5a8e-413f-8df2-300cf4e66202] if not is_image_extendable(image, use_cow): 2015-01-15 15:19:35.840 28636 TRACE nova.compute.manager [instance: 162caeb6-5a8e-413f-8df2-300cf4e66202] File /opt/stack/new/nova/nova/virt/disk/api.py, line 217, in is_image_extendable 2015-01-15 15:19:35.840 28636 TRACE nova.compute.manager [instance: 162caeb6-5a8e-413f-8df2-300cf4e66202] fs = vfs.VFS.instance_for_image(image, 'qcow2', None) 2015-01-15 15:19:35.840 28636 TRACE nova.compute.manager [instance: 162caeb6-5a8e-413f-8df2-300cf4e66202] File /opt/stack/new/nova/nova/virt/disk/vfs/api.py, line 57, in instance_for_image 2015-01-15 15:19:35.840 28636 TRACE nova.compute.manager [instance: 162caeb6-5a8e-413f-8df2-300cf4e66202] vfs.inspect_capabilities() 2015-01-15 15:19:35.840 28636 TRACE nova.compute.manager [instance: 162caeb6-5a8e-413f-8df2-300cf4e66202] File
[Yahoo-eng-team] [Bug 1414530] Re: cwd might be set incorrectly when exceptions are thrown
Fixed in:
https://review.openstack.org/#/c/155847/
** Changed in: oslo.concurrency
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/1414530
Title:
cwd might be set incorrectly when exceptions are thrown
Status in OpenStack Compute (Nova):
Fix Released
Status in Oslo Concurrency Library:
Fix Released
Bug description:
CWD might be set incorrectly when exceptions are thrown
The call to utils.execute ends up in /opt/stack/nova/nova/utils.py which
ultimately calls processutils.execute() in the oslo_concurrency module.
If there's an error when executing the command which calls an bash script
then an exception ProcessExecutionError will be raised at #1. This means that
the code at #2 will never be reached resulting in the Exception being
propagated
up to the call-stack but now one is still stuck with the wrong working
directory which can lead to problems. One should catch the Exception and make
sure
that in all cases the working directory is reset to the original one.
/opt/stack/nova/nova/crypto.py
def ensure_ca_filesystem():
Ensure the CA filesystem exists.
ca_dir = ca_folder()
if not os.path.exists(ca_path()):
genrootca_sh_path = os.path.abspath(
os.path.join(os.path.dirname(__file__), 'CA',
'genrootca.sh'))
start = os.getcwd()
fileutils.ensure_tree(ca_dir)
os.chdir(ca_dir)
utils.execute(sh, genrootca_sh_path) --- #1
os.chdir(start)--- #2
One can see in
https://github.com/openstack/oslo.concurrency/blob/master/oslo_concurrency/processutils.py
that this Exception can indeed be thrown.
Analogously there's a similar issue also in the aforementioned file in
_ensure_project_folder.
def _ensure_project_folder(project_id):
if not os.path.exists(ca_path(project_id)):
geninter_sh_path = os.path.abspath(
os.path.join(os.path.dirname(__file__), 'CA',
'geninter.sh'))
start = os.getcwd()
os.chdir(ca_folder())
utils.execute('sh', geninter_sh_path, project_id,
_project_cert_subject(project_id))
os.chdir(start)
I'm not sure whether this has a potential security vulnerability impact or
not. The potential risk is definitely there but it remains to be seen whether
an attacker can actually reliably trigger this and then possibly gain something
else by having a different working directory. That's why I didn't tag it as a
security bug.
To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1414530/+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 1453268] Re: dynamic nova.conf generation does not work without python-barbicanclient installed
** Changed in: nova/kilo 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/1453268 Title: dynamic nova.conf generation does not work without python- barbicanclient installed Status in OpenStack Compute (Nova): Invalid Status in OpenStack Compute (nova) kilo series: Invalid Status in Oslo configuration management library: Invalid Bug description: In gentoo we dynamically generate the docs (we also package stable branch releases that install from git). This doesn't work unless python-barbicanclient is installed. What I would like to see is either a silent failure with that section of nova.conf removed or just add python-barbicanclient to requirements from test-requirements. I understand that it is expected that example conf generation is expected to need test-requirements, but I don't agree :P Let me know if you need more info. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1453268/+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 1441922] Re: Keystone V3 authentication return BadRequest: Malformed request url
** Changed in: nova
Status: Triaged = 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/1441922
Title:
Keystone V3 authentication return BadRequest: Malformed request url
Status in Cinder:
Invalid
Status in OpenStack Compute (Nova):
Invalid
Bug description:
When using keystone V3 authentication for cinder and nova (see comment #3), I
got error BadRequest: Malformed request url (HTTP 400).
I am testing on Juno release, my keystone v3 env is like this,
export OS_USERNAME=admin
export OS_PASSWORD=password
export OS_DOMAIN_NAME=default
export OS_AUTH_URL=http://$MY_HOST:35357/v3;
export OS_IDENTITY_API_VERSION=3
My endpoint of cinder public URL is like
http://**.**.**.**:8776/v1/cbe4b1d87fbb4318be379a79a570b7ec (I hided the real
IP)
When run command openstack --debug volume list or openstack --debug volume
create --size 1 jin, I got this BadRequest error. From debug info, this error
comes from cinder server. I added log in cinder/api/openstack/wsgi.py function
_process_stack(), found the context.project_id is None while project_id has a
value, here return the error.
if (context and project_id and (project_id != context.project_id)):
msg = _(Malformed request url)
return Fault(webob.exc.HTTPBadRequest(explanation=msg))
I compared with another keystone V2 authentication server, the
context.project_id is same as project_id. Maybe this is difference, in v2
server the REQ has one more Project-id like curl -i -H X-Auth-Project-Id:
admin.
I found the cinder.context maybe come from cinder/api/middleware/auth.py, the
project_id in cinder.context may not be assigned a value in keystone v3
authentication scenario.
ERROR log is as below:
REQ: curl -i
http://**.**.**.**:8776/v1/cbe4b1d87fbb4318be379a79a570b7ec/volumes/detail
-X GET -H User-Agent: python-cinderclient -H Accept:
application/json -H X-Auth-Token: e883e05a887144d4ae70151c976ce666
INFO: requests.packages.urllib3.connectionpool Starting new HTTP connection
(1): **.**.**.**
DEBUG: requests.packages.urllib3.connectionpool GET
/v1/cbe4b1d87fbb4318be379a79a570b7ec/volumes/detail HTTP/1.1 400 65
DEBUG: cinderclient.client RESP: [400] {'date': 'Thu, 09 Apr 2015 00:35:30
GMT', 'content-length': '65', 'content-type': 'application/json;
charset=UTF-8', 'x-compute-request-id':
'req-39a96150-b9ab-4753-8b02-d5730492b288', 'x-openstack-request-id':
'req-39a96150-b9ab-4753-8b02-d5730492b288'}
RESP BODY: {badRequest: {message: Malformed request url, code: 400}}
ERROR: openstack Malformed request url (HTTP 400) (Request-ID:
req-39a96150-b9ab-4753-8b02-d5730492b288)
Traceback (most recent call last):
File /usr/lib/python2.7/site-packages/cliff/app.py, line 280, in
run_subcommand
result = cmd.run(parsed_args)
File /usr/lib/python2.7/site-packages/cliff/display.py, line 91, in run
column_names, data = self.take_action(parsed_args)
File
/usr/lib/python2.7/site-packages/openstackclient/volume/v1/volume.py, line
255, in take_action
data = volume_client.volumes.list(search_opts=search_opts)
File /usr/lib/python2.7/site-packages/cinderclient/v1/volumes.py, line
220, in list
volumes)
File /usr/lib/python2.7/site-packages/cinderclient/base.py, line 70, in
_list
resp, body = self.api.client.get(url)
File /usr/lib/python2.7/site-packages/cinderclient/client.py, line 302,
in get
return self._cs_request(url, 'GET', **kwargs)
File /usr/lib/python2.7/site-packages/cinderclient/client.py, line 269,
in _cs_request
**kwargs)
File /usr/lib/python2.7/site-packages/cinderclient/client.py, line 252,
in request
raise exceptions.from_response(resp, body)
BadRequest: Malformed request url (HTTP 400) (Request-ID:
req-39a96150-b9ab-4753-8b02-d5730492b288)
To manage notifications about this bug go to:
https://bugs.launchpad.net/cinder/+bug/1441922/+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 1371424] Re: EC2 API does not support filters
** Also affects: ec2-api 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/1371424 Title: EC2 API does not support filters Status in EC2 API: New Status in OpenStack Compute (Nova): Confirmed Bug description: Each AWS describe operation has common and some custom filter parameters to filter result set by various object attributes. But Nova EC2 supports filters by object ids only. I found similar ancient bug https://bugs.launchpad.net/nova/+bug/734912, but it's closed with 'invalid' resolution. As i understand it refers to a blueprint which proposes to implement this feature by enhancement of native Nova filter capability. But there was no activity in this blueprint for the last 3 years. I believe we could implement EC2 filters in EC2 layer mostly, using the existing filtering capabilities of OS services (Nova, Glance, Cinder). If insufficient performance of filtering operation by some attribute will be found later, we will optimize it by moving filtering by this attribute to an appropriate OS service. To manage notifications about this bug go to: https://bugs.launchpad.net/ec2-api/+bug/1371424/+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 885090] Re: EC2 and OS Image APIs use inconsistent IDs
** Also affects: ec2-api 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/885090 Title: EC2 and OS Image APIs use inconsistent IDs Status in EC2 API: New Status in OpenStack Compute (Nova): Confirmed Bug description: When retrieving images through the EC2 API, the image id looks like ami-0001; when using the OS API it looks like 1. Sadly the EC2 API only accepts the ami-0001 format, which means that if you query the OS API to get the image (which you have to do to get the metadata) you then can't use that image API to create an instance (which you have to do to specify an SSH key). While I can perform the same mapping that the EC2 API no doubt does under the covers, I really shouldn't have to - I suggest that the EC2 API should be returned in the metadata, or the EC2 API create call should accept an OS Image Id. To manage notifications about this bug go to: https://bugs.launchpad.net/ec2-api/+bug/885090/+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 954335] Re: registering new image from existing s3 location does not respect kernel/ramdisk/name
** Also affects: ec2-api 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/954335 Title: registering new image from existing s3 location does not respect kernel/ramdisk/name Status in EC2 API: New Status in OpenStack Compute (Nova): Confirmed Bug description: $ cloud-publish-image --type kernel --rename my-kernel.img amd64 my.img my-bucket aki-000fmy-bucket/my-kernel.img.manifest.xml $ cloud-publish-image --type ramdisk --rename my-ramdisk.img amd64 my.img my-bucket ari-0010my-bucket/my-ramdisk.img.manifest.xml $ cloud-publish-image --type image --rename my-image-01.img amd64 my.img my-bucket ami-0011my-bucket/my-image-01.img.manifest.xml $ euca-register my-bucket/my-image-01.img.manifest.xml --kernel aki-000f --ramdisk ari-0010 --name my-bucket/my-image-01-with-kenrel-ramdisk.img IMAGE ami-0012 $ euca-describe-images ami-0012 IMAGE ami-0012my-bucket/my-image-01.img.manifest.xml available private x86_64 machine instance-store However, if you pass --kernel/--ramdisk the first time you register that s3 location, then it works. $ cloud-publish-image --type image --rename my-image-02.img amd64 my.img my-bucket --kernel aki-000f --ramdisk ari-0010 ami-0013my-bucket/my-image-02.img.manifest.xml $ euca-describe-images ami-0013 IMAGE ami-0013my-bucket/my-image-02.img.manifest.xml available private x86_64 machine aki-000fari-0010 instance-store The desired behavior is basically to re-register that s3 location but with different kernel/ramdisk (or --name) parameters. Euca-describe-images shows the following: $ euca-describe-images | grep my-bucket/ IMAGE aki-000fmy-bucket/my-kernel.img.manifest.xml available private x86_64 kernel instance-store IMAGE ari-0010my-bucket/my-ramdisk.img.manifest.xml available private x86_64 ramdisk instance-store IMAGE ami-0011my-bucket/my-image-01.img.manifest.xml available private x86_64 machine instance-store IMAGE ami-0012my-bucket/my-image-01.img.manifest.xml available private x86_64 machine instance-store IMAGE ami-0013my-bucket/my-image-02.img.manifest.xml available private x86_64 machine aki-000fari-0010 instance-store $ glance index /dev/null | grep my-bucket 09e381db-4281-4678-9c4b-854158148643 my-bucket/my-image-02.img ami ami10485760 f90dd1a9-301c-4ee9-9636-af1fd2454872 my-bucket/my-image-01-with-ken ami ami10485760 4799f149-0d04-4b5a-bd2a-f0bf96e97a1d my-bucket/my-image-01.img ami ami10485760 909651a3-e3c1-4858-946e-17433ef73aed my-bucket/my-ramdisk.img ari ari10485760 228a64fd-dadc-4cec-9954-92fef2251413 my-bucket/my-kernel.imgaki aki10485760 To manage notifications about this bug go to: https://bugs.launchpad.net/ec2-api/+bug/954335/+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 1284741] Re: EC2 metadata service doesn't account for request forwarding when using neutron metadata-proxy
** Also affects: ec2-api
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/1284741
Title:
EC2 metadata service doesn't account for request forwarding when using
neutron metadata-proxy
Status in EC2 API:
New
Status in OpenStack Compute (Nova):
In Progress
Bug description:
When an EC2 metadata request is received via the neutron metadata
proxy Nova assumes that the X-Forwarded-For item in teh header is the
address of the instance:
https://github.com/openstack/nova/blob/master/nova/api/metadata/handler.py#L149
In fact depending on the network path this could be a comma separated
list of of addresses, only the first element of which is the address
of the instance.
The correct handling should be something like:
remote_address = req.headers.get('X-Forwarded-For').split(',')[0]
To manage notifications about this bug go to:
https://bugs.launchpad.net/ec2-api/+bug/1284741/+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 1371046] Re: No type check for resource-id value in EC2 describe_tags filter
** Also affects: ec2-api 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/1371046 Title: No type check for resource-id value in EC2 describe_tags filter Status in EC2 API: New Status in OpenStack Compute (Nova): Confirmed Bug description: $ euca-describe-tags --filter resource-id=vol-nnn returns tags for i-nnn instance. For example: $ euca-describe-tags TAG i-000e instancexxx yyy $ euca-describe-tags --filter resource-id=vol-000e TAG i-000e instancexxx yyy To manage notifications about this bug go to: https://bugs.launchpad.net/ec2-api/+bug/1371046/+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 1215527] Re: DescribeInstanceAttribute userData missing value xml element
** Also affects: ec2-api 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/1215527 Title: DescribeInstanceAttribute userData missing value xml element Status in EC2 API: New Status in OpenStack Compute (Nova): Confirmed Bug description: The nova ec2 compatibility api sends a response differing from ec2 for simple string value types such as userData and disableApiTermination. They are missing the wrapper value xml element. This does not effect complex responses such as groupSet and blockDeviceMapping To manage notifications about this bug go to: https://bugs.launchpad.net/ec2-api/+bug/1215527/+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 1280948] Re: The DB API is inconsistent about returning sub-second resolution timestamps
** Also affects: ec2-api 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/1280948 Title: The DB API is inconsistent about returning sub-second resolution timestamps Status in EC2 API: New Status in OpenStack Compute (Nova): Confirmed Bug description: While creating volume, the return value says that volume creation time is dd-mm-yyThh:mm:ss.s, but while listing volumes at a later point of time, it changes to dd-mm-yyThh:mm:ss.0 Doesn't look like a big issue though, but nevertheless shouldn't happen. I'd say the simplest solution should be to return dd-mm- yyThh:mm:ss.0 at the create-time itself. To manage notifications about this bug go to: https://bugs.launchpad.net/ec2-api/+bug/1280948/+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 1273983] Re: Pagination not implemented for DescribeTags
** Also affects: ec2-api 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/1273983 Title: Pagination not implemented for DescribeTags Status in EC2 API: New Status in OpenStack Compute (Nova): Confirmed Bug description: Amazon's API tells that it has MaxResults and NextToken tags for pagination. There is no such thing in our API http://docs.aws.amazon.com/AWSEC2/latest/APIReference/ApiReference-query-DescribeTags.html To manage notifications about this bug go to: https://bugs.launchpad.net/ec2-api/+bug/1273983/+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 1075051] Re: AWS credentials delegation to S3/Swift3
** Also affects: ec2-api 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/1075051 Title: AWS credentials delegation to S3/Swift3 Status in EC2 API: New Status in OpenStack Compute (Nova): Confirmed Bug description: Now (openstack-nova-api-2012.2-1.fc18) , when the nova tries to connect to the S3 storage it tries to use the credentials hard coded to the config file. It means every RegisterImage call will use the same tenant credentials instead of their own tenant credentials. I think nova should delegate authentication to the swift backed, even by using other access method with the original requester permissions/roles. Note1: Probably this behaviour originated the days where the nova-objectstore used and it does not validated credentials. Note2: Part of AWS credential is a signature of the request by the secret key, simple forwarding probably will not work. To manage notifications about this bug go to: https://bugs.launchpad.net/ec2-api/+bug/1075051/+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 1259438] Re: EC2 API doesn't return Cinder volume 'type'
** Also affects: ec2-api 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/1259438 Title: EC2 API doesn't return Cinder volume 'type' Status in EC2 API: New Status in OpenStack Compute (Nova): Confirmed Bug description: When one create a volume with volume type 'standard', the EC2 API doesn't reflect this. The API response still shows volume.type as None. To manage notifications about this bug go to: https://bugs.launchpad.net/ec2-api/+bug/1259438/+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 1200734] Re: Boto fails to boot instances with a security group
** Also affects: ec2-api 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/1200734 Title: Boto fails to boot instances with a security group Status in EC2 API: New Status in OpenStack Compute (Nova): Confirmed Bug description: Some of our users are having an issue when booting instances on OpenStack with using Boto. It seems Boto is having an issue with Nova when it assigns a security group at booting instances. Here's a simple example to make the issue happens. image = conn.get_image(ami-XX) for a in range (20): image.run(instance_type=m1.small, key_name=mykey1, security_groups=[secgroup1]) Several instances fail to boot with error status. But the follows is fine. image = conn.get_image(ami-XX) for a in range (20): image.run(instance_type=m1.small, key_name=mykey1) Here's the version info. Nova: 2012.1.3+stable-20130423-e52e6912-0ubuntu1.1 Boto: 2.9.7 Thanks and best regards, Koji To manage notifications about this bug go to: https://bugs.launchpad.net/ec2-api/+bug/1200734/+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 1212581] Re: ec2 api doesn't respect reclaim_instance_interval from nova.conf
** Also affects: ec2-api 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/1212581 Title: ec2 api doesn't respect reclaim_instance_interval from nova.conf Status in EC2 API: New Status in OpenStack Compute (Nova): Confirmed Bug description: When a user, uses the ec2 api to delete an instance the check whether the instance should be soft-deleted isn't done. This logic is current in api/nova/ and not in api/ec2. I expected the ec2 api to have the same behavior. We currently lost user data because of this. Would be nice to have compute/api.y only a contain a single delete function which does the checking whether to soft-delete or not instead of doing it in the api level. Impact: High To manage notifications about this bug go to: https://bugs.launchpad.net/ec2-api/+bug/1212581/+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 681416] Re: Different default security groups depending on API used to launch instnaces
** Also affects: ec2-api 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/681416 Title: Different default security groups depending on API used to launch instnaces Status in EC2 API: New Status in OpenStack Compute (Nova): Incomplete Bug description: Cloud servers from Rackspace have no firewall by default, while access to instances on EC2 are completely blocked from the outside. In order to mimick this behaviour, we should have two default security groups per user (or project, really): One for instances launched through the EC2 API and one for instances launched through the OpenStack API. The former should be closed by default, the latter should be open by default. To manage notifications about this bug go to: https://bugs.launchpad.net/ec2-api/+bug/681416/+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 1272844] Re: Fails to 'modify_image_attribute()' for ec2
** Also affects: ec2-api
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/1272844
Title:
Fails to 'modify_image_attribute()' for ec2
Status in EC2 API:
New
Status in OpenStack Compute (Nova):
Confirmed
Bug description:
The params of modify_image_attribute() in cloud.py, are not matched
with ec2 api.
-
I checked the ec2 api, the url is like:
https://ec2.amazonaws.com/?Action=ModifyImageAttribute
ImageId=ami-61a54008
LaunchPermission.Remove.1.UserId=
And I tested again with euca2ools, the modify_image_attribute() failed
again:
TypeError: 'modify_image_attribute() takes exactly 5 non-keyword
arguments (3 given)'
--
Here is the definition of modify_image_attribute():
def modify_image_attribute(self, context, image_id, attribute,
operation_type, **kwargs)
And I printed out the params send to here, the value of args is:
args={'launch_permission': {'add': {'1': {'group': u'all'}}}, 'image_id':
u'ami-0004'}
--
So I got a question, are the params used in modify_image_attribute()
correct?
To manage notifications about this bug go to:
https://bugs.launchpad.net/ec2-api/+bug/1272844/+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 1438286] Re: os-fixed-ips does not have json schema validation
Looks like this was fixed here? https://review.openstack.org/#/c/169139/ ** Changed in: nova Status: Triaged = 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/1438286 Title: os-fixed-ips does not have json schema validation Status in OpenStack Compute (Nova): Invalid Bug description: The v2.1 os-fixed-ips extension: http://git.openstack.org/cgit/openstack/nova/tree/nova/api/openstack/compute/plugins/v3/fixed_ips.py?id=2015.1.0b3 Does not have any json schema validation today: http://git.openstack.org/cgit/openstack/nova/tree/nova/api/openstack/compute/schemas/v3?id=2015.1.0b3 To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1438286/+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] Adopt mox3
Victor, Monty had a github repo, that's where we are starting from. The idea is to rely on our day to day tools here in the openstack ecosystem to maintain the project. If one of the original authors shows up, we'll see what we can do. Given that the code is Apache License 2.0, we are ok to pick this up. -- dims On Thu, Jun 11, 2015 at 4:15 AM, Victor Stinner vstin...@redhat.com wrote: Hi, Le 10/06/2015 22:17, Davanum Srinivas a écrit : Oslo folks, everyone, mox3 needs to be maintained since some of our projects use it and we have it in our global requirements. Here's the proposal from Doug - https://review.openstack.org/#/c/190330/ Why not only creating a project on Github? Do we need all OpenStack tools for mox3? I don't expect much enhancements in the library. For me, OpenStack looks more restrictive than a classic Github project, it's more heavy to contribute (sign a CLA, use review.openstack.org, etc.). I prefer mock over mox, the API is very different. mock is now part of Python stdlib (unittest.mock since Python 3.3). In the past, I ported some mox tests to mock, but it takes a lot of time :-( https://docs.python.org/dev/library/unittest.mock.html Did anyone try to contact original mox authors? smiddlek is the last active contributor. I see changes in 2012 in the Subversion repository of mox, whereas the latest mox release was in 2010 (mox 0.5.3). It would be nice to merge back enhancements of mox3 (Python 3 support) into mox. It's annoying to have a specific project to get Python 3 support. mox is hosted on code.google.com which is closing! Victor __ 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] Adopt mox3
Yes, that's the official position - Avoid mox, use mock, worst case use mox3 for existing -- dims On Thu, Jun 11, 2015 at 3:37 AM, Jordan Pittier jordan.pitt...@scality.com wrote: Hi, Shouldn't we move to use mock instead ? If mox3 is supported and active, why would we recommend to use mock ? Jordan On Wed, Jun 10, 2015 at 10:17 PM, Davanum Srinivas dava...@gmail.com wrote: Oslo folks, everyone, mox3 needs to be maintained since some of our projects use it and we have it in our global requirements. Here's the proposal from Doug - https://review.openstack.org/#/c/190330/ Any objections? Please chime in here or on the 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 __ 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] Getting rid of suds, which is unmaintained, and which we want out of Debian
Thomas, oslo.vmware (master) moved to suds-jurko for both python2 and python3. we deleted references in nova and other places directly to suds and rely on transitively loading the suds-jurko specified from oslo.vmware. cinder (master) has a reference to suds-jurko as well. -- dims On Thu, Jun 11, 2015 at 3:26 AM, Thomas Goirand z...@debian.org wrote: Hi, The current maintainer of suds in Debian sent bug reports against all packages depending on it. We would like to get rid of suds completely. See: https://bugs.debian.org/788080 https://bugs.debian.org/788081 https://bugs.debian.org/788083 https://bugs.debian.org/788085 https://bugs.debian.org/788088 Affected projects are: cinder, nova, trove, ironic, and finally oslo.vmware. So, are we moving to suds-jurko? Or anything else? 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
[openstack-dev] [oslo] Adopt mox3
Oslo folks, everyone, mox3 needs to be maintained since some of our projects use it and we have it in our global requirements. Here's the proposal from Doug - https://review.openstack.org/#/c/190330/ Any objections? Please chime in here or on the 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
[openstack-dev] [oslo.vmware] Bump oslo.vmware to 1.0.0
Gary, Tracy, Vipin and other contributors, Is oslo.vmware API solid enough for us to bump to 1.0.0? if not, what's left to be done? 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][Automaton] Proposal for new core reviewer (min pae)
+1 from me Josh. welcome Min Pae. -- dims On Mon, Jun 8, 2015 at 2:31 PM, Joshua Harlow harlo...@outlook.com wrote: Greetings all stackers, I propose that we add Min Pae (sputnik13) to the automaton-core team. Min has been actively contributing to taskflow for a while now and as automaton (the library came out of taskflow) is a new library it would be great to have his participation there as well. He is willing (and able!) to help with the review load when he can. He has provided quality reviews in other projects and would be a welcome addition in helping make automaton the best library it can be! Overall I think he would make a great addition to the core review team. Please respond with +1/-1. Thanks much! -- Joshua Harlow It's openstack, relax... | harlo...@yahoo-inc.com __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- 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-operators] [Fuel][Oslo][RabbitMQ][Shovel] Deprecate mirrored queues from HA AMQP cluster scenario
Bogdan, I'd also like to ask: c) Does anyone have any experience with shovel in a realistic openstack environment? (or even a devstack one) Thanks, dims On Mon, Jun 8, 2015 at 6:24 AM, Bogdan Dobrelya bdobre...@mirantis.com wrote: Hello, stackers. I'd like to bring out a poll about deprecating the RabbitMQ mirrored queues for HA layout and replacing the AMQP clustering by shovel [0], [1]. I guess the federation would not be a good option, but let's consider it as well. Why this must be done? The answer is that the rabbit cluster cannot detect and survive micro outages well and just ending up with some queues stuck and as a result, the rabbitmqctl control plane hanged completely unresponsive (until the rabbit node erased and recovered its cluster membership). These outages could be caused either by the network *or* by CPU load spikes. For example, like this bug in Fuel project [2] and this mail thread [3]. So, let's please vote and discuss. But the questions also are: a) Would be there changes in Oslo.messaging required as well in order to support the underlying AMQP layer architecture changes? b) Are there any volunteers for this research to be done for the Oslo.messaging AMQP rabbit driver? PS. Note, I'm not bringing RabbitMQ versions here as the issue seems unresolved for any of existing ones. This seems rather the Erlang's Mnesia generic clustering issue, than something what could be just fixed in RabbitMQ, unless the mnesia based clustering would be dropped completely ;) [0] https://www.rabbitmq.com/shovel-dynamic.html [1] https://www.rabbitmq.com/shovel.html [2] https://bugs.launchpad.net/fuel/+bug/1460762 [3] https://groups.google.com/forum/#!topic/rabbitmq-users/iZWokxvhlaU -- Best regards, Bogdan Dobrelya, Skype #bogdando_at_yahoo.com Irc #bogdando ___ OpenStack-operators mailing list openstack-operat...@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators -- 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] [magnum][horizon] Making a dashboard for Magnum - need a vote from the core team
+1 to single team -- dims On Thu, Jun 4, 2015 at 2:02 PM, Steven Dake (stdake) std...@cisco.com wrote: My vote is +1 for a unified core team for all Magnum development which in the future will include the magnum-ui repo, the python-magnumclient repo, the magnum repo, and the python-k8sclient repo. Regards -steve From: Steven Dake std...@cisco.com Reply-To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org Date: Thursday, June 4, 2015 at 10:58 AM To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org Subject: [openstack-dev] [magnum][horizon] Making a dashboard for Magnum - need a vote from the core team Hey folks, I think it is critical for self-service needs that we have a Horizon dashboard to represent Magnum. I know the entire Magnum team has no experience in UI development, but I have found atleast one volunteer Bradley Jones to tackle the work. I am looking for more volunteers to tackle this high impact effort to bring Containers to OpenStack either in the existing Magnum core team or as new contributors. If your interested, please chime in on this thread. As far as “how to get patches approved”, there are two models we can go with. Option #1: We add these UI folks to the magnum-core team and trust them not to +2/+A Magnum infrastructure code. This also preserves us as one team with one mission. Option #2: We make a new core team magnum-ui-core. This presents special problems if the UI contributor team isn’t large enough to get reviews in. I suspect Option #2 will be difficult to execute. Cores, please vote on Option #1, or Option #2, and Adrian can make a decision based upon the results. Regards -steve __ 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 1461217] Re: Kilo Docker: Hypervisor Type Not Defined
Fixing it in https://review.openstack.org/#/c/188339/ ** Changed in: nova-docker Status: New = Invalid ** Changed in: nova Status: New = In Progress ** Changed in: nova Importance: Undecided = Low ** 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 OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1461217 Title: Kilo Docker: Hypervisor Type Not Defined Status in OpenStack Compute (Nova): In Progress Status in Nova Docker Driver: Invalid Bug description: On a multinode setup, based on Ubuntu14.04, with nova version, below # dpkg -l | grep nova ii nova-common 1:2015.1.0-0ubuntu1~cloud0 all OpenStack Compute - common files ii nova-compute1:2015.1.0-0ubuntu1~cloud0 all OpenStack Compute - compute node base ii nova-compute-kvm1:2015.1.0-0ubuntu1~cloud0 all OpenStack Compute - compute node (KVM) ii nova-compute-libvirt1:2015.1.0-0ubuntu1~cloud0 all OpenStack Compute - compute node libvirt support ii python-nova 1:2015.1.0-0ubuntu1~cloud0 all OpenStack Compute Python libraries ii python-novaclient 1:2.22.0-0ubuntu1~cloud0 all client library for OpenStack Compute API , did the following: 1- Followed https://wiki.openstack.org/wiki/Docker procedure 2- Added nova to libvirtd group, to avoid /var/run/libvirt/libvirt-sock access problem 3- Updated nova-compute.conf to include compute_driver=novadocker.virt.docker.DockerDriver and virt_type=docker Upon starting a new docker instance, got the following error: 2015-06-01 17:02:59.784 42703 ERROR nova.openstack.common.threadgroup [req-9f37298d-828c-4ac5-9834-320cc082f92b - - - - -] 'module' object has no attribute 'DOCKER' 2015-06-01 17:02:59.784 42703 TRACE nova.openstack.common.threadgroup Traceback (most recent call last): 2015-06-01 17:02:59.784 42703 TRACE nova.openstack.common.threadgroup File /usr/lib/python2.7/dist-packages/nova/openstack/common/threadgroup.py, line 145, in wait 2015-06-01 17:02:59.784 42703 TRACE nova.openstack.common.threadgroup x.wait() 2015-06-01 17:02:59.784 42703 TRACE nova.openstack.common.threadgroup File /usr/lib/python2.7/dist-packages/nova/openstack/common/threadgroup.py, line 47, in wait 2015-06-01 17:02:59.784 42703 TRACE nova.openstack.common.threadgroup return self.thread.wait() 2015-06-01 17:02:59.784 42703 TRACE nova.openstack.common.threadgroup File /usr/lib/python2.7/dist-packages/eventlet/greenthread.py, line 175, in wait 2015-06-01 17:02:59.784 42703 TRACE nova.openstack.common.threadgroup return self._exit_event.wait() 2015-06-01 17:02:59.784 42703 TRACE nova.openstack.common.threadgroup File /usr/lib/python2.7/dist-packages/eventlet/event.py, line 121, in wait 2015-06-01 17:02:59.784 42703 TRACE nova.openstack.common.threadgroup return hubs.get_hub().switch() 2015-06-01 17:02:59.784 42703 TRACE nova.openstack.common.threadgroup File /usr/lib/python2.7/dist-packages/eventlet/hubs/hub.py, line 294, in switch 2015-06-01 17:02:59.784 42703 TRACE nova.openstack.common.threadgroup return self.greenlet.switch() 2015-06-01 17:02:59.784 42703 TRACE nova.openstack.common.threadgroup File /usr/lib/python2.7/dist-packages/eventlet/greenthread.py, line 214, in main 2015-06-01 17:02:59.784 42703 TRACE nova.openstack.common.threadgroup result = function(*args, **kwargs) 2015-06-01 17:02:59.784 42703 TRACE nova.openstack.common.threadgroup File /usr/lib/python2.7/dist-packages/nova/openstack/common/service.py, line 497, in run_service 2015-06-01 17:02:59.784 42703 TRACE nova.openstack.common.threadgroup service.start() 2015-06-01 17:02:59.784 42703 TRACE nova.openstack.common.threadgroup File /usr/lib/python2.7/dist-packages/nova/service.py, line 183, in start 2015-06-01 17:02:59.784 42703 TRACE nova.openstack.common.threadgroup self.manager.pre_start_hook() 2015-06-01 17:02:59.784 42703 TRACE nova.openstack.common.threadgroup File /usr/lib/python2.7/dist-packages/nova/compute/manager.py, line 1291, in pre_start_hook 2015-06-01 17:02:59.784 42703 TRACE nova.openstack.common.threadgroup self.update_available_resource(nova.context.get_admin_context()) 2015-06-01 17:02:59.784 42703 TRACE nova.openstack.common.threadgroup File /usr/lib/python2.7/dist-packages/nova/compute/manager.py, line 6240, in update_available_resource 2015-06-01 17:02:59.784 42703 TRACE nova.openstack.common.threadgroup rt.update_available_resource(context) 2015-06-01 17:02:59.784 42703 TRACE nova.openstack.common.threadgroup File /usr/lib/python2.7/dist-packages/nova
[Yahoo-eng-team] [Bug 1461665] [NEW] nova.tests.unit.db.test_db_api sets up quotas incorrectly
Public bug reported:
Faced this problem when porting tests to python3. user_quotas[res] field
is bring populated with the class object instead of hard_limit. python2
is magically allowing user_quotas[res] = 0 to succed when that
variable has nova.db.sqlalchemy.models.Quota or
nova.db.sqlalchemy.models.ProjectQuota
You can also reproduce this with the following patch:
diff --git a/nova/db/sqlalchemy/api.py b/nova/db/sqlalchemy/api.py
index 16342e1..7e7e43a 100644
--- a/nova/db/sqlalchemy/api.py
+++ b/nova/db/sqlalchemy/api.py
@@ -3428,6 +3428,10 @@ def _calculate_overquota(project_quotas, user_quotas,
deltas,
for res, delta in deltas.items():
# We can't go over-quota if we're not reserving anything or if
# we have unlimited quotas.
+if not isinstance(user_quotas[res], six.integer_types):
+raise Exception('user_quotas[res] is not an integer - %r'
+% user_quotas[res])
+
if user_quotas[res] = 0 and delta = 0:
# over if the project usage + delta is more than project quota
if project_quotas[res] delta + project_usages[res]['total']:
Here's a sample output:
http://paste.openstack.org/show/260349/
** Affects: nova
Importance: Medium
Assignee: Matt Riedemann (mriedem)
Status: In Progress
** Tags: db testing
--
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/1461665
Title:
nova.tests.unit.db.test_db_api sets up quotas incorrectly
Status in OpenStack Compute (Nova):
In Progress
Bug description:
Faced this problem when porting tests to python3. user_quotas[res]
field is bring populated with the class object instead of hard_limit.
python2 is magically allowing user_quotas[res] = 0 to succed when
that variable has nova.db.sqlalchemy.models.Quota or
nova.db.sqlalchemy.models.ProjectQuota
You can also reproduce this with the following patch:
diff --git a/nova/db/sqlalchemy/api.py b/nova/db/sqlalchemy/api.py
index 16342e1..7e7e43a 100644
--- a/nova/db/sqlalchemy/api.py
+++ b/nova/db/sqlalchemy/api.py
@@ -3428,6 +3428,10 @@ def _calculate_overquota(project_quotas, user_quotas,
deltas,
for res, delta in deltas.items():
# We can't go over-quota if we're not reserving anything or if
# we have unlimited quotas.
+if not isinstance(user_quotas[res], six.integer_types):
+raise Exception('user_quotas[res] is not an integer - %r'
+% user_quotas[res])
+
if user_quotas[res] = 0 and delta = 0:
# over if the project usage + delta is more than project quota
if project_quotas[res] delta + project_usages[res]['total']:
Here's a sample output:
http://paste.openstack.org/show/260349/
To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1461665/+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] upcoming oslo releases
Matt, we are reverting that change - https://review.openstack.org/#/c/187306/ - so no need for any caps. that change will go to a feature branch for later. We can decide version numbers etc later and add caps if needed at that time. -- dims On Mon, Jun 1, 2015 at 5:38 PM, Matt Riedemann mrie...@linux.vnet.ibm.com wrote: On 6/1/2015 12:04 PM, Doug Hellmann wrote: We have a bunch of Oslo libraries ready for releases tomorrow, Tuesday 2 June. I will be releasing: 0.5.0 8685171 debtcollector 1.10.0 9a963a9 oslo.concurrency 1.12.0 02a86d2 oslo.config 0.4.0 4c9b37d oslo.context 1.10.0 42dc936 oslo.db 1.7.0 a02d901 oslo.i18n 1.3.0 6754d13 oslo.log 1.12.0 27efb36 oslo.messaging 0.5.0 757857b oslo.policy 1.8.0 2335e63 oslo.rootwrap 1.6.0 74b3f97 oslo.utils 0.3.0 a03c635 oslo.versionedobjects If you are interested in more detail, the full set of changes to be included is available in http://paste.openstack.org/show/253257/ 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 Was there agreement on capping oslo.serialization 2.0 in global-requirements on master so that nova doesn't pick up the latest and breaks with the new iso time format stuff? -- 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
Re: [openstack-dev] [oslo.messaging][zeromq] Next step
of connecting the end points to the proxy server while they all can potentially reside in different Vms - you cannot just use 127.0.0.1 to find the local proxy server). I'll cite the zmq-guide about broker/brokerless (4.14. Brokerless Reliability p.221): It might seem ironic to focus so much on broker-based reliability, when we often explain ØMQ as brokerless messaging. However, in messaging, as in real life, the middleman is both a burden and a benefit. In practice, most messaging architectures benefit from a mix of distributed and brokered messaging. Brokers and middlemen are beneficial in many situations no question about it. In this particular situation there is actually already a broker of sort which is the redis server ;-) The redis server acts like a name server and allows dynamic discovery of services (topics and the associated addresses). Brokers are interesting for 2 reasons: decouple participants of a communication infra (e.g. you do not want to hardcode anything about peers, their count and their addresses), this can be done by a broker a la 0MQ example or by a name server do something special about messages that are being brokered (e.g. persistence, replication, multicast, load balancing etc...), things that you can't do with simple peer to peer connections and things where RabbitMQ (presumably) excels Given that the proxy server does not seem to do anything special with the messages (other than forwarding/unicasting) and given that Redis could provide a full end to end addressing, it seems that the need for a proxy is greatly diminished. A list of drawbacks in having a proxy server in every node: potential deployment complications as noted above, total connection count is higher compared to proxy-less design - this could be a problem if we ever get to the point of encrypting every connection (btw 0MQ supports encryption since version 3 although I have not personally tried it) 1 more hop for every message in both directions not clear if the proxy would propagate disconnection events from one side to the other? need to tend to the buffering and flow control in the proxy (one policy may not fit all needs and will it still be state-less) Lastly, note that the Redis server itself could be clustered for HA (a feature added recently) and this might be something we may have to look at as well because it is another point of failure (it would be awkward to put the redis server on 1 controller node where HA calls for 3 controller nodes for example). I'm still relatively new to oslo messaging and still have a lot of questions regarding a deployment based on 0MQ. I think it is important that we assess properly the forces in favor of this protocol and make sure it does provide a better option than rabbitMQ at production scale using measurable evidence. Thanks Alec Thanks, Oleksii 1 - http://zeromq.org/area:faq#toc7 5/26/15 18:57, Davanum Srinivas пишет: Alec, Here are the slides: http://www.slideshare.net/davanum/oslomessaging-new-0mq-driver-proposal All the 0mq patches to date should be either already merged in trunk or waiting for review on trunk. Oleksii, Li Ma, Can you please address the other questions? thanks, Dims On Tue, May 26, 2015 at 11:43 AM, Alec Hothan (ahothan) ahot...@cisco.com wrote: Looking at what is the next step following the design summit meeting on 0MQ as the etherpad does not provide too much information. Few questions: - would it be possible to have the slides presented (showing the proposed changes in the 0MQ driver design) to be available somewhere? - is there a particular branch in the oslo messaging repo that contains 0MQ related patches - I'm more particularly interested by James Page's patch to pool the 0MQ connections but there might be other - question for Li Ma, are you deploying with the straight upstream 0MQ driver or with some additional patches? The per node proxy process (which is itself some form of broker) needs to be removed completely if the new solution is to be made really broker-less. This will also eliminate the only single point of failure in the path and reduce the number of 0MQ sockets (and hops per message) by half. I think it was proposed that we go on with the first draft of the new driver (which still keeps the proxy server but reduces the number of sockets) before eventually tackling the removal of the proxy server? Thanks Alec __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribehttp://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
[Yahoo-eng-team] [Bug 1460652] Re: nova-conductor infinitely reconnets to rabbit
** Also affects: oslo.messaging 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/1460652 Title: nova-conductor infinitely reconnets to rabbit Status in OpenStack Compute (Nova): New Status in Messaging API for OpenStack: New Bug description: 1. Exact version of Nova ii nova-api 1:2014.1.100+git201410062002~trusty-0ubuntu1 all OpenStack Compute - API frontend ii nova-cert 1:2014.1.100+git201410062002~trusty-0ubuntu1 all OpenStack Compute - certificate management ii nova-common 1:2014.1.100+git201410062002~trusty-0ubuntu1 all OpenStack Compute - common files ii nova-conductor 1:2014.1.100+git201410062002~trusty-0ubuntu1 all OpenStack Compute - conductor service ii nova-console 1:2014.1.100+git201410062002~trusty-0ubuntu1 all OpenStack Compute - Console ii nova-consoleauth 1:2014.1.100+git201410062002~trusty-0ubuntu1 all OpenStack Compute - Console Authenticatorii nova-novncproxy 1:2014.1.100+git201410062002~trusty-0ubuntu1 all OpenStack Compute - NoVNC proxy ii nova-scheduler 1:2014.1.100+git201410062002~trusty-0ubuntu1 all OpenStack Compute - virtual machine scheduler ii python-nova 1:2014.1.100+git201410062002~trusty-0ubuntu1 all OpenStack Compute Python libraries ii python-novaclient 1:2.17.0.74.g2598714+git201404220131~trusty-0ubuntu1 all client library for OpenStack Compute API rabbit configuration in nova.conf: rabbit_hosts = m610-2:5672, m610-1:5672 rabbit_ha_queues = true 2. Relevant log files: /var/log/nova/nova-conductor.log exchange 'reply_bea18a6133c548f099b85b168fddf83c' in vhost '/' 2015-06-01 08:23:56.484 16427 TRACE oslo.messaging._drivers.impl_rabbit Traceback (most recent call last): 2015-06-01 08:23:56.484 16427 TRACE oslo.messaging._drivers.impl_rabbit File /usr/lib/python2.7/dist-packages/oslo/messaging/_drivers/impl_rabbit.py, line 624, in ensure 2015-06-01 08:23:56.484 16427 TRACE oslo.messaging._drivers.impl_rabbit return method(*args, **kwargs) 2015-06-01 08:23:56.484 16427 TRACE oslo.messaging._drivers.impl_rabbit File /usr/lib/python2.7/dist-packages/oslo/messaging/_drivers/impl_rabbit.py, line 729, in _publish 2015-06-01 08:23:56.484 16427 TRACE oslo.messaging._drivers.impl_rabbit publisher = cls(self.conf, self.channel, topic, **kwargs) 2015-06-01 08:23:56.484 16427 TRACE oslo.messaging._drivers.impl_rabbit File /usr/lib/python2.7/dist-packages/oslo/messaging/_drivers/impl_rabbit.py, line 361, in __init__ 2015-06-01 08:23:56.484 16427 TRACE oslo.messaging._drivers.impl_rabbit type='direct', **options) 2015-06-01 08:23:56.484 16427 TRACE oslo.messaging._drivers.impl_rabbit File /usr/lib/python2.7/dist-packages/oslo/messaging/_drivers/impl_rabbit.py, line 326, in __init__ 2015-06-01 08:23:56.484 16427 TRACE oslo.messaging._drivers.impl_rabbit self.reconnect(channel) 2015-06-01 08:23:56.484 16427 TRACE oslo.messaging._drivers.impl_rabbit File /usr/lib/python2.7/dist-packages/oslo/messaging/_drivers/impl_rabbit.py, line 334, in reconnect 2015-06-01 08:23:56.484 16427 TRACE oslo.messaging._drivers.impl_rabbit routing_key=self.routing_key) 2015-06-01 08:23:56.484 16427 TRACE oslo.messaging._drivers.impl_rabbit File /usr/lib/python2.7/dist-packages/kombu/messaging.py, line 82, in __init__ 2015-06-01 08:23:56.484 16427 TRACE oslo.messaging._drivers.impl_rabbit self.revive(self._channel) 2015-06-01 08:23:56.484 16427 TRACE oslo.messaging._drivers.impl_rabbit File /usr/lib/python2.7/dist-packages/kombu/messaging.py, line 216, in revive 2015-06-01 08:23:56.484 16427 TRACE oslo.messaging._drivers.impl_rabbit self.declare() 2015-06-01 08:23:56.484 16427 TRACE oslo.messaging._drivers.impl_rabbit File /usr/lib/python2.7/dist-packages/kombu/messaging.py, line 102, in declare 2015-06-01 08:23:56.484 16427 TRACE oslo.messaging._drivers.impl_rabbit self.exchange.declare() 2015-06-01 08:23:56.484 16427 TRACE oslo.messaging._drivers.impl_rabbit File /usr/lib/python2.7/dist-packages/kombu/entity.py, line 166, in declare 2015-06-01 08:23:56.484 16427 TRACE oslo.messaging._drivers.impl_rabbit nowait=nowait, passive=passive, 2015-06-01 08:23:56.484 16427 TRACE oslo.messaging._drivers.impl_rabbit File /usr/lib/python2.7/dist-packages/amqp/channel.py, line 612, in exchange_declare 2015-06-01 08:23:56.484 16427 TRACE oslo.messaging._drivers.impl_rabbit
Re: [openstack-dev] [all] upcoming oslo releases
Doug, Here's the updated tip of the trees that i have tested by hand against at least Nova. 0.5.0 8f4100a debtcollector 1.10.0 9a963a9 oslo.concurrency 1.12.0 cc9940f oslo.config 0.4.0 23f81ea oslo.context 1.10.0 42dc936 oslo.db 1.7.0 7935c3f oslo.i18n 1.3.0 1d64c91 oslo.log 1.12.0 5181361 oslo.messaging 0.5.0 08215c5 oslo.policy 1.8.0 563291f oslo.rootwrap 1.6.0 15c82cc oslo.serialization 1.6.0 e5349b9 oslo.utils 0.3.0 a03c635 oslo.versionedobjects Let's please release these tomorrow. Here's the paste of the unreleased changes: http://paste.openstack.org/show/254643/ thanks, dims On Mon, Jun 1, 2015 at 6:00 PM, Davanum Srinivas dava...@gmail.com wrote: Matt, we are reverting that change - https://review.openstack.org/#/c/187306/ - so no need for any caps. that change will go to a feature branch for later. We can decide version numbers etc later and add caps if needed at that time. -- dims On Mon, Jun 1, 2015 at 5:38 PM, Matt Riedemann mrie...@linux.vnet.ibm.com wrote: On 6/1/2015 12:04 PM, Doug Hellmann wrote: We have a bunch of Oslo libraries ready for releases tomorrow, Tuesday 2 June. I will be releasing: 0.5.0 8685171 debtcollector 1.10.0 9a963a9 oslo.concurrency 1.12.0 02a86d2 oslo.config 0.4.0 4c9b37d oslo.context 1.10.0 42dc936 oslo.db 1.7.0 a02d901 oslo.i18n 1.3.0 6754d13 oslo.log 1.12.0 27efb36 oslo.messaging 0.5.0 757857b oslo.policy 1.8.0 2335e63 oslo.rootwrap 1.6.0 74b3f97 oslo.utils 0.3.0 a03c635 oslo.versionedobjects If you are interested in more detail, the full set of changes to be included is available in http://paste.openstack.org/show/253257/ 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 Was there agreement on capping oslo.serialization 2.0 in global-requirements on master so that nova doesn't pick up the latest and breaks with the new iso time format stuff? -- 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 -- 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] [Magnum] Does Bay/Baymodel name should be a required option when creating a Bay/Baymodel
+1 from me as well On Sun, May 31, 2015 at 6:08 PM, Steven Dake (stdake) std...@cisco.com wrote: Jay 513 +1 on mandatory name requirement. From: Jay Lau jay.lau@gmail.com Reply-To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org Date: Sunday, May 31, 2015 at 2:38 PM To: OpenStack Development Mailing List openstack-dev@lists.openstack.org Subject: [openstack-dev] [Magnum] Does Bay/Baymodel name should be a required option when creating a Bay/Baymodel Just want to use ML to trigger more discussion here. There are now bugs/patches tracing this, but seems more discussions are needed before we come to a conclusion. https://bugs.launchpad.net/magnum/+bug/1453732 https://review.openstack.org/#/c/181839/ https://review.openstack.org/#/c/181837/ https://review.openstack.org/#/c/181847/ https://review.openstack.org/#/c/181843/ IMHO, making the Bay/Baymodel name as a MUST will bring more flexibility to end user as Magnum also support operating Bay/Baymodel via names and the name might be more meaningful to end users. Perhaps we can borrow some iead from nova, the concept in magnum can be mapped to nova as following: 1) instance = bay 2) flavor = baymodel So I think that a solution might be as following: 1) Make name as a MUST for both bay/baymodel 2) Update magnum client to use following style for bay-create and baymodel-create: DO NOT add --name option root@devstack007:/tmp# nova boot usage: nova boot [--flavor flavor] [--image image] [--image-with key=value] [--boot-volume volume_id] [--snapshot snapshot_id] [--min-count number] [--max-count number] [--meta key=value] [--file dst-path=src-path] [--key-name key-name] [--user-data user-data] [--availability-zone availability-zone] [--security-groups security-groups] [--block-device-mapping dev-name=mapping] [--block-device key1=value1[,key2=value2...]] [--swap swap_size] [--ephemeral size=size[,format=format]] [--hint key=value] [--nic net-id=net-uuid,v4-fixed-ip=ip-addr,v6-fixed-ip=ip-addr,port-id=port-uuid] [--config-drive value] [--poll] name error: too few arguments Try 'nova help boot' for more information. root@devstack007:/tmp# nova flavor-create usage: nova flavor-create [--ephemeral ephemeral] [--swap swap] [--rxtx-factor factor] [--is-public is-public] name id ram disk vcpus Please show your comments if any. -- Thanks, Jay Lau (Guangya Liu) __ 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] [magnum] Proposing Kai Qiang Wu (Kennan) for Core for Magnum
+1 from me! On Sun, May 31, 2015 at 1:56 AM, Steven Dake (stdake) std...@cisco.com wrote: Hi core team, Kennan (Kai Qiang Wu’s nickname) has really done a nice job in Magnum contributions. I would like to propose Kennan for the core reviewer team. I don’t think we necessarily need more core reviewers on Magnum, but Kennan has demonstrated a big commitment to Magnum and is a welcome addition in my opinion. For the lifetime of the project, Kennan has contributed 8% of the reviews, and 8% of the commits. Kennan is also active in IRC. He meets my definition of what a core developer for Magnum should be. Consider my proposal to be a +1 vote. Please vote +1 to approve or vote –1 to veto. A single –1 vote acts as a veto, meaning Kennan would not be approved for the core team. I believe we require 3 +1 core votes presently, but since our core team is larger now then when we started, I’d like to propose at our next team meeting we formally define the process by which we accept new cores post this proposal for Magnum into the magnum-core group and document it in our wiki. I’ll leave voting open for 1 week until June 6th to permit appropriate time for the core team to vote. If there is a unanimous decision or veto prior to that date, I’ll close voting and make the appropriate changes in gerrit as appropriate. Thanks -steve __ 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 1459726] Re: api servers hang with 100% CPU if syslog restarted
** Also affects: oslo.log
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/1459726
Title:
api servers hang with 100% CPU if syslog restarted
Status in OpenStack Image Registry and Delivery Service (Glance):
New
Status in OpenStack Neutron (virtual network service):
New
Status in OpenStack Compute (Nova):
New
Status in Logging configuration library for OpenStack:
New
Bug description:
Affected:
glance-api
glance-registry
neutron-server
nova-api
If service was configured to use rsyslog and rsyslog was restarted
after API server started, it hangs on next log line with 100% CPU. If
server have few workers, each worker will eat own 100% CPU share.
Steps to reproduce:
1. Configure syslog:
use_syslog=true
syslog_log_facility=LOG_LOCAL4
2. restart api service
3. restart rsyslog
Execute some command to force logging. F.e.: neutron net-create foo,
nova boot, etc.
Expected result: normal operation
Actual result:
with some chance (about 30-50%) api server will hung with 100% CPU usage and
will not reply to request.
Strace on hung service:
gettimeofday({1432827199, 745141}, NULL) = 0
poll([{fd=3, events=POLLOUT|POLLERR|POLLHUP}, {fd=5,
events=POLLIN|POLLPRI|POLLERR|POLLHUP}], 2, 6) = 1 ([{fd=3,
revents=POLLOUT}])
sendto(3, 151keystonemiddleware.auth_token[12502]: DEBUG Authenticating
user token __call__
/usr/lib/python2.7/dist-packages/keystonemiddleware/auth_token.py:650\0, 154,
0, NULL, 0) = -1 ENOTCONN (Transport endpoint is not connected)
gettimeofday({1432827199, 745226}, NULL) = 0
poll([{fd=3, events=POLLOUT|POLLERR|POLLHUP}, {fd=5,
events=POLLIN|POLLPRI|POLLERR|POLLHUP}], 2, 6) = 1 ([{fd=3,
revents=POLLOUT}])
sendto(3, 151keystonemiddleware.auth_token[12502]: DEBUG Authenticating
user token __call__
/usr/lib/python2.7/dist-packages/keystonemiddleware/auth_token.py:650\0, 154,
0, NULL, 0) = -1 ENOTCONN (Transport endpoint is not connected)
gettimeofday({1432827199, 745325}, NULL) = 0
Tested on:
nova, glance, neutron: 1:2014.2.3, Ubuntu version.
To manage notifications about this bug go to:
https://bugs.launchpad.net/glance/+bug/1459726/+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 1456437] Re: Devstack can not install openstack due to bad md5 hash code
** Project changed: nova = devstack -- 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/1456437 Title: Devstack can not install openstack due to bad md5 hash code Status in devstack - openstack dev environments: New Bug description: when using devstack to install stable branch openstack project, there may fail due to bad md5 hash .. 2015-05-18 19:51:25.980 | Obtaining file:///opt/stack/kilo/nova 2015-05-18 19:51:27.563 | Requirement already satisfied (use --upgrade to upgrade): pbr!=0.7,1.0,=0.6 in /usr/local/lib/python2.7/dist-packages (from nova==2015.1.1.dev13) 2015-05-18 19:51:27.566 | Requirement already satisfied (use --upgrade to upgrade): SQLAlchemy=0.9.99,=0.9.7 in /usr/local/lib/python2.7/dist-packages (from nova==2015.1.1.dev13) 2015-05-18 19:51:27.586 | Collecting boto=2.32.1 (from nova==2015.1.1.dev13) 2015-05-18 19:51:27.692 | Using cached boto-2.38.0-py2.py3-none-any.whl 2015-05-18 19:51:27.694 | Hash of the package https://pypi.python.org/packages/2.7/b/boto/boto-2.38.0-py2.py3-none-any.whl#md5=dd00fcddc668880494987bcb6102ecf2 (from https://pypi.python.org/simple/boto/) (39c6ea46c7f78b4ac829a0cf4ed6bbd3) doesn't match the expected hash dd00fcddc668880494987bcb6102ecf2! 2015-05-18 19:51:27.696 | Bad md5 hash for package https://pypi.python.org/packages/2.7/b/boto/boto-2.38.0-py2.py3-none-any.whl#md5=dd00fcddc668880494987bcb6102ecf2 (from https://pypi.python.org/simple/boto/) To manage notifications about this bug go to: https://bugs.launchpad.net/devstack/+bug/1456437/+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 1460061] [NEW] Security issues reported by bandit
Public bug reported:
Using the tox target added in this review -
https://review.openstack.org/#/c/186752/
Use of exec detected.
- nova/cmd/manage.py::215
214
215 exec(compile(open(path).read(), path, 'exec'), locals(),
globals())
216
Use of insecure MD5 hash function.
- nova/utils.py::1131
1130returns string that represents hash of base_str (in hex
format).
1131return hashlib.md5(base_str).hexdigest()
1132
Pickle library appears to be in use, possible security issue.
- nova/virt/xenapi/client/session.py::213
212 rv = self.call_plugin(plugin, fn, params)
213 return pickle.loads(rv)
214
Use of possibly insecure function - consider using safer ast.literal_eval.
- nova/virt/xenapi/client/session.py::291
290 # FIXME(comstud): eval is evil.
291 params = eval(exc.details[3])
292 except Exception:
Pickle library appears to be in use, possible security issue.
- nova/virt/xenapi/fake.py::661
660 def _plugin_migration_transfer_vhd(self, method, args):
661 kwargs = pickle.loads(args['params'])['kwargs']
662 vdi_ref = self.xenapi_request('VDI.get_by_uuid',
Audit url open for permitted schemes. Allowing use of file:/ or custom
schemes is often unexpected.
- nova/virt/xenapi/vm_utils.py::1961
1960try:
1961xml = urllib.urlopen(%s://%s:%s@%s/vm_rrd?uuid=%s % (
1962server[0],
1963CONF.xenserver.connection_username,
1964CONF.xenserver.connection_password,
** 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/1460061
Title:
Security issues reported by bandit
Status in OpenStack Compute (Nova):
New
Bug description:
Using the tox target added in this review -
https://review.openstack.org/#/c/186752/
Use of exec detected.
- nova/cmd/manage.py::215
214
215 exec(compile(open(path).read(), path, 'exec'), locals(),
globals())
216
Use of insecure MD5 hash function.
- nova/utils.py::1131
1130 returns string that represents hash of base_str (in hex
format).
1131 return hashlib.md5(base_str).hexdigest()
1132
Pickle library appears to be in use, possible security issue.
- nova/virt/xenapi/client/session.py::213
212 rv = self.call_plugin(plugin, fn, params)
213 return pickle.loads(rv)
214
Use of possibly insecure function - consider using safer ast.literal_eval.
- nova/virt/xenapi/client/session.py::291
290 # FIXME(comstud): eval is evil.
291 params = eval(exc.details[3])
292 except Exception:
Pickle library appears to be in use, possible security issue.
- nova/virt/xenapi/fake.py::661
660 def _plugin_migration_transfer_vhd(self, method, args):
661 kwargs = pickle.loads(args['params'])['kwargs']
662 vdi_ref = self.xenapi_request('VDI.get_by_uuid',
Audit url open for permitted schemes. Allowing use of file:/ or custom
schemes is often unexpected.
- nova/virt/xenapi/vm_utils.py::1961
1960 try:
1961 xml = urllib.urlopen(%s://%s:%s@%s/vm_rrd?uuid=%s % (
1962 server[0],
1963 CONF.xenserver.connection_username,
1964 CONF.xenserver.connection_password,
To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1460061/+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.vmware release 0.13.0 (liberty)
Team, i've published 0.13.1 of oslo.vmware with the revert from Gary and so far the Nova jobs are good. -- dims On Thu, May 28, 2015 at 4:41 AM, Gary Kotton gkot...@vmware.com wrote: Hi, We have reverted the problematic patch (I suggest that you all add the word balagan to your lexicons). Anyways, the plan forwards is as follows: To update the nova code to use the correct exceptions and to ensure that it will not break moving forwards To clean up the exceptions in oslo.vmware and to make use of the Vim exceptions Thanks and sorry for the troubles Gary From: Joe Gordon joe.gord...@gmail.com Reply-To: OpenStack List openstack-dev@lists.openstack.org Date: Wednesday, May 27, 2015 at 9:38 PM To: OpenStack List openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] oslo.vmware release 0.13.0 (liberty) On Wed, May 27, 2015 at 11:23 AM, Davanum Srinivas dava...@gmail.com wrote: Joe, Given that the code once lived in nova and the team across has spent quite a bit of time to turn it into a library which at last count was adopted by 6 projects at least. i'd like to give the team some credit. Agreed, they have done a great job. I was just pointing out a lot of OpenStack libs don't use semver's 0.x.x clause much. openstack/ceilometer/test-requirements.txt:oslo.vmware=0.11.1 # Apache-2.0 openstack/cinder/requirements.txt:oslo.vmware=0.11.1 # Apache-2.0 openstack/congress/requirements.txt:oslo.vmware=0.11.1 # Apache-2.0 openstack/glance/requirements.txt:oslo.vmware=0.11.1 # Apache-2.0 openstack/glance_store/test-requirements.txt:oslo.vmware=0.11.1 # Apache-2.0 openstack/nova/test-requirements.txt:oslo.vmware=0.11.1,!=0.13.0 # Apache-2.0 Shit happens! the team that works on oslo.vmware overlaps nova too and others. There were several solutions that came up quickly as well. we can't just say nothing should ever break or we should not use 0.x.x then we can never make progress. This is not going to get any better either with the big tent coming up. All that matters is how quickly we can recover and move on with our collective sanity intact. Let's work on that in addition as well. I'd also want to give some more say in the actual folks who are contributing and working on the code as well in the specific discussion. Anyway, with the global-requirements block of 0.13.0, nova should unclog and we'll try to get something out soon in 0.13.1 to keep @haypo's python34 effort going as well. Thanks! I think it would be good to move to 1.x.x soon to show that the API is stable. But then again we do have a lot of other libraries that are below 0.x.x so maybe we should look at that more holistically. +1000 to release fewer unexpectedly incompatible libraries and continue working on improving how we handle dependencies in general. i'd like to hear specific things we can do that we are not doing both for libraries under our collective care as well as things we use from the general python community. For openstack libraries that have a fairly limited number of consumers we can test source of the lib against target unit test suites, in addition to a devstack run. So oslo.vmware would have a job running source oslo.vmware against nova py27 unit tests. As for in general, is cooking up a plan. thanks, dims On Wed, May 27, 2015 at 1:52 PM, Joe Gordon joe.gord...@gmail.com wrote: On Wed, May 27, 2015 at 12:54 AM, Gary Kotton gkot...@vmware.com wrote: Hi, I prefer the patched posted by Sabari. The patch has two changes: It fixes unit tests In the even that an instance spawn fails then it catches an exception to warn the admin that the guestId may be invalid. The only degradation may be that the warning will no longer be there. I think that the admin can get this information from the logged exception too. So this breakage takes us into some strange waters. oslo.vmware is at version 0.x.x which according to semver [0] means Major version zero (0.y.z) is for initial development. Anything may change at any time. The public API should not be considered stable. If that is accurate, then nova should not be using oslo.vmware, since we shouldn't use an unstable library in production. If we are treating the API as stable then semver says we need to rev the major version (MAJOR version when you make incompatible API changes). What I am trying to say is, I don't know how you can say the nova unit tests are 'wrong.' either nova using oslo.vmware is 'wrong' or oslo.vmware breaking the API is 'wrong'. With OpenStack being so large and having so many dependencies (many of them openstack owned), we should focus on making sure we release fewer unexpectedly incompatible libraries and continue working on improving how we handle dependencies in general (lifeless has a big arch he is working on here AFAIK). So I am not in favor
Re: [openstack-dev] [oslo] Updates from the Summit
Please add it Gorka. thanks, dims On Thu, May 28, 2015 at 6:23 AM, Gorka Eguileor gegui...@redhat.com wrote: On Wed, May 27, 2015 at 08:47:42AM -0400, Davanum Srinivas wrote: Hi Team, Here are the etherpads from the summit[1]. I remember that in Taskflow's Fishbowl session we discussed not only pause/yield option but abort/cancel for long running tasks as well, but reviewing the Etherpad now I don't see it there. Should I just add it to Ideas for Liberty section or there's a specific reason why it wasn't included? Cheers, Gorka. Some highlights are as follows: Oslo.messaging : Took status of the existing zmq driver, proposed a new driver in parallel to the existing zmq driver. Also looked at possibility of using Pika with RabbitMQ. Folks from pivotal promised to help with our scenarios as well. Oslo.rootwrap : Debated daemon vs a new privileged service. The Nova change to add rootwrap as daemon is on hold pending progress on the privsep proposal/activity. Oslo.versionedobjects : We had a nice presentation from Dan about what o.vo can do and a deepdive into what we could do in next release. Taskflow : Josh and team came up with several new features and how to improve usability We will also have several new libraries in Liberty (oslo.cache, oslo.service, oslo.reports, futurist, automaton etc). We talked about our release processes, functional testing, deprecation strategies and debated a but about how best to move to async models as well. Please see etherpads for detailed information. thanks, dims [1] https://wiki.openstack.org/wiki/Design_Summit/Liberty/Etherpads#Oslo -- 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 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] Updates from the Summit
Flavio, PIka is an unknown quantity at the moment as none of us have touched it. It was brought up by rabbitmq folks. So someone should look at it. We don't have have enough info either to say we should use Pika by itself or as a kombu driver. We may have to make that determination at some point in the future if indeed pika is so much better. We don't have anyone in the Kombu community either...and Pika will need to pass the python34, licensing etc as well to be considered in addition to the performance. thanks, dims On Thu, May 28, 2015 at 7:08 AM, Flavio Percoco fla...@redhat.com wrote: On 27/05/15 10:24 -0700, Joshua Harlow wrote: Thanks dims! indeed, thanks. [snip] Also for the pika one, I'd really like to understand why not kombu. I don't know enough of the background, but from that session it looks like we need to do some comparative analysis (and imho get feedback from asksol[1] and others) before we go to deep down that rabbit hole (no jump to another 'greener pasture' imho should be done without all of this, to avoid pissing off the two [kombu, pika] communities). I couldn't attend this session but I'd also like to understand what's the idea behind using pika instead of kombu. FWIW, older versions of kombu used pika and it was moved away from it. One of the reasons was that pika was not stable enough at that time. This could've changed. If pika is just better than the amqp lib used by Kombu, wouldn't it be better to just contribute back to kombu? Cheers, Flavio My 2 cents :-P [1] https://github.com/ask -Josh Davanum Srinivas wrote: Hi Team, Here are the etherpads from the summit[1]. Some highlights are as follows: Oslo.messaging : Took status of the existing zmq driver, proposed a new driver in parallel to the existing zmq driver. Also looked at possibility of using Pika with RabbitMQ. Folks from pivotal promised to help with our scenarios as well. Oslo.rootwrap : Debated daemon vs a new privileged service. The Nova change to add rootwrap as daemon is on hold pending progress on the privsep proposal/activity. Oslo.versionedobjects : We had a nice presentation from Dan about what o.vo can do and a deepdive into what we could do in next release. Taskflow : Josh and team came up with several new features and how to improve usability We will also have several new libraries in Liberty (oslo.cache, oslo.service, oslo.reports, futurist, automaton etc). We talked about our release processes, functional testing, deprecation strategies and debated a but about how best to move to async models as well. Please see etherpads for detailed information. thanks, dims [1] https://wiki.openstack.org/wiki/Design_Summit/Liberty/Etherpads#Oslo __ 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 -- @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] [Ironic][oslo] Stepping down from oslo-ironic liaison
That's right. The oslo team is OK with the liaison to other teams not being a core reviewer. -- dims On Thu, May 28, 2015 at 3:35 AM, Flavio Percoco fla...@redhat.com wrote: On 28/05/15 09:20 +0200, Victor Stinner wrote: Oh, on the wiki page I read that The liaison should be a core reviewer for the project, but does not need to be the PTL.. I'm not a core reviewer for nova. Is it an issue? This was more like a general recommendation, I guess. I don't think the liaison has to be a core reviewer at all. Cheers, Flavio On the wiki page, I see that John Villalovos (happycamp) is the Nova liaison for Oslo, not Joe Goron. I don't understand. Victor Le 27/05/2015 20:44, Joe Gordon a écrit : On Wed, May 27, 2015 at 3:20 AM, Davanum Srinivas dava...@gmail.com mailto:dava...@gmail.com wrote: Victor, Nice, yes, Joe was the liaison with Nova so far. Yes, please go ahead and add your name in the wiki for Nova as i believe Joe is winding down the oslo liaison as well. https://wiki.openstack.org/wiki/CrossProjectLiaisons#Oslo Yup, thank you Victor! thanks, dims On Wed, May 27, 2015 at 5:12 AM, Victor Stinner vstin...@redhat.com mailto:vstin...@redhat.com wrote: Hi, By the way, who is the oslo liaison for nova? If there is nobody, I would like to take this position. Victor Le 25/05/2015 18:45, Ghe Rivero a écrit : My focus on the Ironic project has been decreasing in the last cycles, so it's about time to relinquish my position as a oslo-ironic liaison so new contributors can take over it and help ironic to be the vibrant project it is. So long, and thanks for all the fish, Ghe Rivero -- Pinky: Gee, Brain, what do you want to do tonight? The Brain: The same thing we do every night, Pinky—try to take over the world! .''`. Pienso, Luego Incordio : :' : `. `' `- www.debian.org http://www.debian.org http://www.debian.org www.openstack.com http://www.openstack.com http://www.openstack.com GPG Key: 26F020F7 GPG fingerprint: 4986 39DA D152 050B 4699 9A71 66DB 5A36 26F0 20F7 __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Davanum Srinivas :: https://twitter.com/dims __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- @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] [oslo] Updates from the Summit
Flavio, yay! :) -- dims On Thu, May 28, 2015 at 9:24 AM, Flavio Percoco fla...@redhat.com wrote: On 28/05/15 07:34 -0400, Davanum Srinivas wrote: Flavio, PIka is an unknown quantity at the moment as none of us have touched it. It was brought up by rabbitmq folks. So someone should look at it. We don't have have enough info either to say we should use Pika by itself or as a kombu driver. We may have to make that determination at some point in the future if indeed pika is so much better. We don't have anyone in the Kombu community either...and Pika will need to pass the python34, licensing etc as well to be considered in addition to the performance. I'm here from the Kombu community[0] (although I haven't done much lately). I think we should consider contributing back before dropping kombu if we ever get to the point where we think pika is better than whatever kombu is using. Flavio [0] https://github.com/orgs/celery/people thanks, dims On Thu, May 28, 2015 at 7:08 AM, Flavio Percoco fla...@redhat.com wrote: On 27/05/15 10:24 -0700, Joshua Harlow wrote: Thanks dims! indeed, thanks. [snip] Also for the pika one, I'd really like to understand why not kombu. I don't know enough of the background, but from that session it looks like we need to do some comparative analysis (and imho get feedback from asksol[1] and others) before we go to deep down that rabbit hole (no jump to another 'greener pasture' imho should be done without all of this, to avoid pissing off the two [kombu, pika] communities). I couldn't attend this session but I'd also like to understand what's the idea behind using pika instead of kombu. FWIW, older versions of kombu used pika and it was moved away from it. One of the reasons was that pika was not stable enough at that time. This could've changed. If pika is just better than the amqp lib used by Kombu, wouldn't it be better to just contribute back to kombu? Cheers, Flavio My 2 cents :-P [1] https://github.com/ask -Josh Davanum Srinivas wrote: Hi Team, Here are the etherpads from the summit[1]. Some highlights are as follows: Oslo.messaging : Took status of the existing zmq driver, proposed a new driver in parallel to the existing zmq driver. Also looked at possibility of using Pika with RabbitMQ. Folks from pivotal promised to help with our scenarios as well. Oslo.rootwrap : Debated daemon vs a new privileged service. The Nova change to add rootwrap as daemon is on hold pending progress on the privsep proposal/activity. Oslo.versionedobjects : We had a nice presentation from Dan about what o.vo can do and a deepdive into what we could do in next release. Taskflow : Josh and team came up with several new features and how to improve usability We will also have several new libraries in Liberty (oslo.cache, oslo.service, oslo.reports, futurist, automaton etc). We talked about our release processes, functional testing, deprecation strategies and debated a but about how best to move to async models as well. Please see etherpads for detailed information. thanks, dims [1] https://wiki.openstack.org/wiki/Design_Summit/Liberty/Etherpads#Oslo __ 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 -- @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 -- @flaper87 Flavio Percoco -- 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] [Ironic][oslo] Stepping down from oslo-ironic liaison
Thanks Doug! On Thu, May 28, 2015 at 10:10 AM, Doug Hellmann d...@doughellmann.com wrote: Excerpts from Davanum Srinivas (dims)'s message of 2015-05-28 06:02:24 -0400: That's right. The oslo team is OK with the liaison to other teams not being a core reviewer. I've updated the wiki to reflect that. 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
[openstack-dev] [nova-docker] Looking for volunteers to take care of nova-docker
Hi all, So the feedback during the Vancouver summit from some of the nova cores was that, we needed volunteers to take care of the nova-docker driver before it can be considered to merge in the Nova tree. As an exercise is resposibility, we need people who can reinstate the nova-docker non-voting job (essentially revert [1]) and keep an eye on the output of the job every day to make sure when the CI jobs run against the nova reviews, they stay green. I've cc'ed some folks who expressed interest in the past, please reply back to this thread if you wish to join this effort and specifically if you can volunteer for watching and fixing the CI as issues arise (keeping up with Nova trunk and requirements etc). If there are no volunteers here, nova-docker will stay in sourceforge. So folks who are using it, please step up. Thanks, dims [1] https://review.openstack.org/#/c/150887/ -- 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] [nova-docker][nova]Different meta data information in nova and docker view
Ashish, when we create the docker container, we can pass it the name we want it to have, so yes, it's possible. you will have to try modifying the code to see the fallout. thanks, dims On Wed, May 27, 2015 at 5:12 AM, ashish.jai...@wipro.com wrote: Hello, I am using nova-docker. I deploy a docker container and run the following 2 commands 1) nova list +--+---+++-+---+ | ID | Name | Status | Task State | Power State | Networks | +--+---+++-+---+ | 35cdcbc6-516d-4e99-a8a1-28fedd5b088f | test123,and three | ACTIVE | - | Running | demo-net=192.168.1.71 | +--+---+++-+---+ 2) sudo docker ps CONTAINER IDIMAGE COMMAND CREATED STATUS PORTS NAMES ad381f97816dhttpd:2 httpd-foreground 34 minutes ago Up 34 minutes nova-35cdcbc6-516d-4e99-a8a1-28fedd5b088f Why is their a difference in the name of the container? It is possible to somehow customize what is being seen in the docker view. for example map the Name field in Nova to NAMES field in docker? Regards Ashish The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments. WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. www.wipro.com ___ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack@lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack -- Davanum Srinivas :: https://twitter.com/dims ___ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack@lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Re: [openstack-dev] [Ironic][oslo] Stepping down from oslo-ironic liaison
Tan, Awesome, please update the page here: https://wiki.openstack.org/wiki/CrossProjectLiaisons thanks, dims On Tue, May 26, 2015 at 9:04 PM, Tan, Lin lin@intel.com wrote: Hi Doug and guys, I would like to work as oslo-ironic liasison to sync Ironic with Oslo. I will attend the regular Oslo meeting for sure. My IRC name is lintan, and Launchpad id is tan-lin-good Thanks Tan -Original Message- From: Doug Hellmann [mailto:d...@doughellmann.com] Sent: Tuesday, May 26, 2015 9:17 PM To: openstack-dev Subject: Re: [openstack-dev] [Ironic][oslo] Stepping down from oslo-ironic liaison Excerpts from Ghe Rivero's message of 2015-05-25 09:45:47 -0700: My focus on the Ironic project has been decreasing in the last cycles, so it's about time to relinquish my position as a oslo-ironic liaison so new contributors can take over it and help ironic to be the vibrant project it is. So long, and thanks for all the fish, Ghe Rivero Thanks for your help as liaison, Ghe, the Oslo team appreciates your effort! 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 __ 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] [Ironic][oslo] Stepping down from oslo-ironic liaison
Victor, Nice, yes, Joe was the liaison with Nova so far. Yes, please go ahead and add your name in the wiki for Nova as i believe Joe is winding down the oslo liaison as well. https://wiki.openstack.org/wiki/CrossProjectLiaisons#Oslo thanks, dims On Wed, May 27, 2015 at 5:12 AM, Victor Stinner vstin...@redhat.com wrote: Hi, By the way, who is the oslo liaison for nova? If there is nobody, I would like to take this position. Victor Le 25/05/2015 18:45, Ghe Rivero a écrit : My focus on the Ironic project has been decreasing in the last cycles, so it's about time to relinquish my position as a oslo-ironic liaison so new contributors can take over it and help ironic to be the vibrant project it is. So long, and thanks for all the fish, Ghe Rivero -- Pinky: Gee, Brain, what do you want to do tonight? The Brain: The same thing we do every night, Pinky—try to take over the world! .''`. Pienso, Luego Incordio : :' : `. `' `- www.debian.org http://www.debian.org www.openstack.com http://www.openstack.com GPG Key: 26F020F7 GPG fingerprint: 4986 39DA D152 050B 4699 9A71 66DB 5A36 26F0 20F7 __ 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] [oslo] Updates from the Summit
Hi Team, Here are the etherpads from the summit[1]. Some highlights are as follows: Oslo.messaging : Took status of the existing zmq driver, proposed a new driver in parallel to the existing zmq driver. Also looked at possibility of using Pika with RabbitMQ. Folks from pivotal promised to help with our scenarios as well. Oslo.rootwrap : Debated daemon vs a new privileged service. The Nova change to add rootwrap as daemon is on hold pending progress on the privsep proposal/activity. Oslo.versionedobjects : We had a nice presentation from Dan about what o.vo can do and a deepdive into what we could do in next release. Taskflow : Josh and team came up with several new features and how to improve usability We will also have several new libraries in Liberty (oslo.cache, oslo.service, oslo.reports, futurist, automaton etc). We talked about our release processes, functional testing, deprecation strategies and debated a but about how best to move to async models as well. Please see etherpads for detailed information. thanks, dims [1] https://wiki.openstack.org/wiki/Design_Summit/Liberty/Etherpads#Oslo -- 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.vmware release 0.13.0 (liberty)
Joe, Given that the code once lived in nova and the team across has spent quite a bit of time to turn it into a library which at last count was adopted by 6 projects at least. i'd like to give the team some credit. openstack/ceilometer/test-requirements.txt:oslo.vmware=0.11.1 # Apache-2.0 openstack/cinder/requirements.txt:oslo.vmware=0.11.1 # Apache-2.0 openstack/congress/requirements.txt:oslo.vmware=0.11.1 # Apache-2.0 openstack/glance/requirements.txt:oslo.vmware=0.11.1 # Apache-2.0 openstack/glance_store/test-requirements.txt:oslo.vmware=0.11.1 # Apache-2.0 openstack/nova/test-requirements.txt:oslo.vmware=0.11.1,!=0.13.0 # Apache-2.0 Shit happens! the team that works on oslo.vmware overlaps nova too and others. There were several solutions that came up quickly as well. we can't just say nothing should ever break or we should not use 0.x.x then we can never make progress. This is not going to get any better either with the big tent coming up. All that matters is how quickly we can recover and move on with our collective sanity intact. Let's work on that in addition as well. I'd also want to give some more say in the actual folks who are contributing and working on the code as well in the specific discussion. Anyway, with the global-requirements block of 0.13.0, nova should unclog and we'll try to get something out soon in 0.13.1 to keep @haypo's python34 effort going as well. +1000 to release fewer unexpectedly incompatible libraries and continue working on improving how we handle dependencies in general. i'd like to hear specific things we can do that we are not doing both for libraries under our collective care as well as things we use from the general python community. thanks, dims On Wed, May 27, 2015 at 1:52 PM, Joe Gordon joe.gord...@gmail.com wrote: On Wed, May 27, 2015 at 12:54 AM, Gary Kotton gkot...@vmware.com wrote: Hi, I prefer the patched posted by Sabari. The patch has two changes: It fixes unit tests In the even that an instance spawn fails then it catches an exception to warn the admin that the guestId may be invalid. The only degradation may be that the warning will no longer be there. I think that the admin can get this information from the logged exception too. So this breakage takes us into some strange waters. oslo.vmware is at version 0.x.x which according to semver [0] means Major version zero (0.y.z) is for initial development. Anything may change at any time. The public API should not be considered stable. If that is accurate, then nova should not be using oslo.vmware, since we shouldn't use an unstable library in production. If we are treating the API as stable then semver says we need to rev the major version (MAJOR version when you make incompatible API changes). What I am trying to say is, I don't know how you can say the nova unit tests are 'wrong.' either nova using oslo.vmware is 'wrong' or oslo.vmware breaking the API is 'wrong'. With OpenStack being so large and having so many dependencies (many of them openstack owned), we should focus on making sure we release fewer unexpectedly incompatible libraries and continue working on improving how we handle dependencies in general (lifeless has a big arch he is working on here AFAIK). So I am not in favor of the nova unit test change as a fix here. [0] http://semver.org/ Thanks Gary From: Sabari Murugesan sabari.b...@gmail.com Reply-To: OpenStack List openstack-dev@lists.openstack.org Date: Wednesday, May 27, 2015 at 6:20 AM To: OpenStack List openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] oslo.vmware release 0.13.0 (liberty) Matt I posted a patch https://review.openstack.org/#/c/185830/1 to fix the nova tests and make it compatible with the oslo.vmware 0.13.0 release. I am fine with the revert and g-r blacklist as oslo.vmware broke the semver but we can also consider this patch as an option. Thanks Sabari On Tue, May 26, 2015 at 2:53 PM, Davanum Srinivas dava...@gmail.com wrote: Vipin, Gary, Can you please accept the revert or figure out the best way to handle this? thanks, dims On Tue, May 26, 2015 at 5:41 PM, Matt Riedemann mrie...@linux.vnet.ibm.com wrote: On 5/26/2015 4:19 PM, Matt Riedemann wrote: On 5/26/2015 9:53 AM, Davanum Srinivas wrote: We are gleeful to announce the release of: oslo.vmware 0.13.0: Oslo VMware library With source available at: http://git.openstack.org/cgit/openstack/oslo.vmware For more details, please see the git log history below and: http://launchpad.net/oslo.vmware/+milestone/0.13.0 Please report issues through launchpad: http://bugs.launchpad.net/oslo.vmware Changes in oslo.vmware 0.12.0..0.13.0 - 5df9daa Add ToolsUnavailable exception 286cb9e Add support for dynamicProperty 7758123 Remove support for Python 3.3 11e7d71 Updated from global
Re: [openstack-dev] [nova-docker] Looking for volunteers to take care of nova-docker
Bich, Sure thing, just start on #nova-docker irc channel and we can talk there -- dims On Wed, May 27, 2015 at 11:28 AM, Bich Le l...@platform9.com wrote: I'd like to contribute. But I may need some help / pointers in getting started (I have experience with running and hacking openstack, but this would be my first time contributing). Thanks. Bich Le Platform9 On Wed, May 27, 2015 at 3:48 AM, Davanum Srinivas dava...@gmail.com wrote: Hi all, So the feedback during the Vancouver summit from some of the nova cores was that, we needed volunteers to take care of the nova-docker driver before it can be considered to merge in the Nova tree. As an exercise is resposibility, we need people who can reinstate the nova-docker non-voting job (essentially revert [1]) and keep an eye on the output of the job every day to make sure when the CI jobs run against the nova reviews, they stay green. I've cc'ed some folks who expressed interest in the past, please reply back to this thread if you wish to join this effort and specifically if you can volunteer for watching and fixing the CI as issues arise (keeping up with Nova trunk and requirements etc). If there are no volunteers here, nova-docker will stay in sourceforge. So folks who are using it, please step up. Thanks, dims [1] https://review.openstack.org/#/c/150887/ -- Davanum Srinivas :: https://twitter.com/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] Updates from the Summit
Josh, thanks. yes, the kombu vs pika is just a research thing someone should look at. no blueprint, no spec, so not approved in anyway :) -- dims On Wed, May 27, 2015 at 1:24 PM, Joshua Harlow harlo...@outlook.com wrote: Thanks dims! Good write up, Other things I noted (more controversial ones); is that we need to come up with a concurrency strategy (and/or guidelines, and/or best practices). At least I feel this will be a way that works and imho implies that one concurrency strategy will (likely) not fit every project; at the best we can do is try to offer best practices. Also for the pika one, I'd really like to understand why not kombu. I don't know enough of the background, but from that session it looks like we need to do some comparative analysis (and imho get feedback from asksol[1] and others) before we go to deep down that rabbit hole (no jump to another 'greener pasture' imho should be done without all of this, to avoid pissing off the two [kombu, pika] communities). My 2 cents :-P [1] https://github.com/ask -Josh Davanum Srinivas wrote: Hi Team, Here are the etherpads from the summit[1]. Some highlights are as follows: Oslo.messaging : Took status of the existing zmq driver, proposed a new driver in parallel to the existing zmq driver. Also looked at possibility of using Pika with RabbitMQ. Folks from pivotal promised to help with our scenarios as well. Oslo.rootwrap : Debated daemon vs a new privileged service. The Nova change to add rootwrap as daemon is on hold pending progress on the privsep proposal/activity. Oslo.versionedobjects : We had a nice presentation from Dan about what o.vo can do and a deepdive into what we could do in next release. Taskflow : Josh and team came up with several new features and how to improve usability We will also have several new libraries in Liberty (oslo.cache, oslo.service, oslo.reports, futurist, automaton etc). We talked about our release processes, functional testing, deprecation strategies and debated a but about how best to move to async models as well. Please see etherpads for detailed information. thanks, dims [1] https://wiki.openstack.org/wiki/Design_Summit/Liberty/Etherpads#Oslo __ 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.messaging][zeromq] Next step
Alec, Here are the slides: http://www.slideshare.net/davanum/oslomessaging-new-0mq-driver-proposal All the 0mq patches to date should be either already merged in trunk or waiting for review on trunk. Oleksii, Li Ma, Can you please address the other questions? thanks, Dims On Tue, May 26, 2015 at 11:43 AM, Alec Hothan (ahothan) ahot...@cisco.com wrote: Looking at what is the next step following the design summit meeting on 0MQ as the etherpad does not provide too much information. Few questions: - would it be possible to have the slides presented (showing the proposed changes in the 0MQ driver design) to be available somewhere? - is there a particular branch in the oslo messaging repo that contains 0MQ related patches - I'm more particularly interested by James Page's patch to pool the 0MQ connections but there might be other - question for Li Ma, are you deploying with the straight upstream 0MQ driver or with some additional patches? The per node proxy process (which is itself some form of broker) needs to be removed completely if the new solution is to be made really broker-less. This will also eliminate the only single point of failure in the path and reduce the number of 0MQ sockets (and hops per message) by half. I think it was proposed that we go on with the first draft of the new driver (which still keeps the proxy server but reduces the number of sockets) before eventually tackling the removal of the proxy server? Thanks Alec __ 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.log release 1.2.0 (liberty)
We are thrilled to announce the release of: oslo.log 1.2.0: oslo.log library With source available at: http://git.openstack.org/cgit/openstack/oslo.log For more details, please see the git log history below and: http://launchpad.net/oslo.log/+milestone/1.2.0 Please report issues through launchpad: http://bugs.launchpad.net/oslo.log Changes in oslo.log 1.1.0..1.2.0 7730773 Use proper deprecation for use-syslog-rfc-format option 33f5c6f Replace RFCSysLogHandler by a syslog() based one 36c925e Make remove_in=0 (no removal) use a better syntax 37166ac Remove is_compatible from versionutils e9a11f4 Add versionutils options to list_opts 3a4dc52 Add versionutils to API documentation cc713ab Advertise support for Python3.4 / Remove support for Python 3.3 39da8f9 Updated from global requirements 00036e7 Updated from global requirements 187881e Remove run_cross_tests.sh dbae3bf Deprecate WritableLogger - used for eventlet logging b457dae Log deprecation message when catching deprecated exceptions 27f7fe5 Change misleading TRACE to ERROR 6472777 Provide an API to let tempest control the log file 07d2641 fix pep8 errors c750167 Add pypi download + version badges 494074b Update to latest hacking 6a53053 move versionutils into place e10dccf Add liberty release name to versionutils Diffstat (except docs and test files) - README.rst | 15 +- openstack-common.conf| 5 +- openstack/common/versionutils.py | 260 - oslo_log/_options.py | 12 +- oslo_log/handlers.py | 43 - oslo_log/log.py | 71 --- oslo_log/loggers.py | 7 +- oslo_log/versionutils.py | 250 requirements.txt | 5 +- setup.cfg| 2 +- test-requirements.txt| 2 +- tox.ini | 2 +- 20 files changed, 741 insertions(+), 711 deletions(-) Requirements updates diff --git a/requirements.txt b/requirements.txt index f38fc04..3bfd17a 100644 --- a/requirements.txt +++ b/requirements.txt @@ -5 +5 @@ -pbr=0.6,!=0.7,1.0 +pbr=0.11,2.0 @@ -9 +9 @@ iso8601=0.1.9 -oslo.config=1.9.3 # Apache-2.0 +oslo.config=1.11.0 # Apache-2.0 @@ -13,0 +14 @@ oslo.serialization=1.4.0 # Apache-2.0 +debtcollector=0.3.0 # Apache-2.0 diff --git a/test-requirements.txt b/test-requirements.txt index b551d65..7f335ce 100644 --- a/test-requirements.txt +++ b/test-requirements.txt @@ -5 +5 @@ -hacking=0.9.1,0.10 +hacking=0.10.0,0.11 -- 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.vmware release 0.13.0 (liberty)
Vipin, Gary, Can you please accept the revert or figure out the best way to handle this? thanks, dims On Tue, May 26, 2015 at 5:41 PM, Matt Riedemann mrie...@linux.vnet.ibm.com wrote: On 5/26/2015 4:19 PM, Matt Riedemann wrote: On 5/26/2015 9:53 AM, Davanum Srinivas wrote: We are gleeful to announce the release of: oslo.vmware 0.13.0: Oslo VMware library With source available at: http://git.openstack.org/cgit/openstack/oslo.vmware For more details, please see the git log history below and: http://launchpad.net/oslo.vmware/+milestone/0.13.0 Please report issues through launchpad: http://bugs.launchpad.net/oslo.vmware Changes in oslo.vmware 0.12.0..0.13.0 - 5df9daa Add ToolsUnavailable exception 286cb9e Add support for dynamicProperty 7758123 Remove support for Python 3.3 11e7d71 Updated from global requirements 883c441 Remove run_cross_tests.sh 1986196 Use suds-jurko on Python 2 84ab8c4 Updated from global requirements 6cbde19 Imported Translations from Transifex 8d4695e Updated from global requirements 1668fef Raise VimFaultException for unknown faults 15dbfb2 Imported Translations from Transifex c338f19 Add NoDiskSpaceException 25ec49d Add utility function to get profiles by IDs 32c61ee Add bandit to tox for security static analysis f140b7e Add SPBM WSDL for vSphere 6.0 Diffstat (except docs and test files) - bandit.yaml| 130 +++ openstack-common.conf |2 - .../locale/fr/LC_MESSAGES/oslo.vmware-log-error.po |9 - .../locale/fr/LC_MESSAGES/oslo.vmware-log-info.po |3 - .../fr/LC_MESSAGES/oslo.vmware-log-warning.po | 10 - oslo.vmware/locale/fr/LC_MESSAGES/oslo.vmware.po | 86 +- oslo.vmware/locale/oslo.vmware.pot | 48 +- oslo_vmware/api.py | 10 +- oslo_vmware/exceptions.py | 13 +- oslo_vmware/objects/datastore.py |6 +- oslo_vmware/pbm.py | 18 + oslo_vmware/service.py |2 +- oslo_vmware/wsdl/6.0/core-types.xsd| 237 + oslo_vmware/wsdl/6.0/pbm-messagetypes.xsd | 186 oslo_vmware/wsdl/6.0/pbm-types.xsd | 806 ++ oslo_vmware/wsdl/6.0/pbm.wsdl | 1104 oslo_vmware/wsdl/6.0/pbmService.wsdl | 16 + requirements-py3.txt | 27 - requirements.txt |8 +- setup.cfg |2 +- test-requirements-bandit.txt |1 + tox.ini| 14 +- 27 files changed, 2645 insertions(+), 262 deletions(-) Requirements updates diff --git a/requirements.txt b/requirements.txt index 807bcfc..dd5a1aa 100644 --- a/requirements.txt +++ b/requirements.txt @@ -5 +5 @@ -pbr=0.6,!=0.7,1.0 +pbr=0.11,2.0 @@ -23,3 +23,3 @@ PyYAML=3.1.0 -suds=0.4 -eventlet=0.16.1,!=0.17.0 -requests=2.2.0,!=2.4.0 +suds-jurko=0.6 +eventlet=0.17.3 +requests=2.5.2 diff --git a/test-requirements-bandit.txt b/test-requirements-bandit.txt new file mode 100644 index 000..38c39e1 --- /dev/null +++ b/test-requirements-bandit.txt @@ -0,0 +1 @@ +bandit==0.10.1 There is now a blocking vmware unit tests bug in nova due to the oslo.vmware 0.13.0 release: https://bugs.launchpad.net/nova/+bug/1459021 Since the vmware driver unit test code in nova likes to stub out external APIs there is probably a bug in the nova unit tests rather than an issue in oslo.vmware, but I'm not very familiar so I can't really say. I have a revert for oslo.vmware here: https://review.openstack.org/#/c/185744/ And a block on the 0.13.0 version in global-requirements here: https://review.openstack.org/#/c/185748/ -- 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.vmware release 0.13.0 (liberty)
We are gleeful to announce the release of: oslo.vmware 0.13.0: Oslo VMware library With source available at: http://git.openstack.org/cgit/openstack/oslo.vmware For more details, please see the git log history below and: http://launchpad.net/oslo.vmware/+milestone/0.13.0 Please report issues through launchpad: http://bugs.launchpad.net/oslo.vmware Changes in oslo.vmware 0.12.0..0.13.0 - 5df9daa Add ToolsUnavailable exception 286cb9e Add support for dynamicProperty 7758123 Remove support for Python 3.3 11e7d71 Updated from global requirements 883c441 Remove run_cross_tests.sh 1986196 Use suds-jurko on Python 2 84ab8c4 Updated from global requirements 6cbde19 Imported Translations from Transifex 8d4695e Updated from global requirements 1668fef Raise VimFaultException for unknown faults 15dbfb2 Imported Translations from Transifex c338f19 Add NoDiskSpaceException 25ec49d Add utility function to get profiles by IDs 32c61ee Add bandit to tox for security static analysis f140b7e Add SPBM WSDL for vSphere 6.0 Diffstat (except docs and test files) - bandit.yaml| 130 +++ openstack-common.conf |2 - .../locale/fr/LC_MESSAGES/oslo.vmware-log-error.po |9 - .../locale/fr/LC_MESSAGES/oslo.vmware-log-info.po |3 - .../fr/LC_MESSAGES/oslo.vmware-log-warning.po | 10 - oslo.vmware/locale/fr/LC_MESSAGES/oslo.vmware.po | 86 +- oslo.vmware/locale/oslo.vmware.pot | 48 +- oslo_vmware/api.py | 10 +- oslo_vmware/exceptions.py | 13 +- oslo_vmware/objects/datastore.py |6 +- oslo_vmware/pbm.py | 18 + oslo_vmware/service.py |2 +- oslo_vmware/wsdl/6.0/core-types.xsd| 237 + oslo_vmware/wsdl/6.0/pbm-messagetypes.xsd | 186 oslo_vmware/wsdl/6.0/pbm-types.xsd | 806 ++ oslo_vmware/wsdl/6.0/pbm.wsdl | 1104 oslo_vmware/wsdl/6.0/pbmService.wsdl | 16 + requirements-py3.txt | 27 - requirements.txt |8 +- setup.cfg |2 +- test-requirements-bandit.txt |1 + tox.ini| 14 +- 27 files changed, 2645 insertions(+), 262 deletions(-) Requirements updates diff --git a/requirements.txt b/requirements.txt index 807bcfc..dd5a1aa 100644 --- a/requirements.txt +++ b/requirements.txt @@ -5 +5 @@ -pbr=0.6,!=0.7,1.0 +pbr=0.11,2.0 @@ -23,3 +23,3 @@ PyYAML=3.1.0 -suds=0.4 -eventlet=0.16.1,!=0.17.0 -requests=2.2.0,!=2.4.0 +suds-jurko=0.6 +eventlet=0.17.3 +requests=2.5.2 diff --git a/test-requirements-bandit.txt b/test-requirements-bandit.txt new file mode 100644 index 000..38c39e1 --- /dev/null +++ b/test-requirements-bandit.txt @@ -0,0 +1 @@ +bandit==0.10.1 -- 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.messaging release 1.11.0 (liberty)
,!=0.17.0 +eventlet=0.17.3 @@ -26 +26,3 @@ PyYAML=3.1.0 -kombu=2.5.0 +# we set the amqp version to ensure heartbeat works +amqp=1.4.0 +kombu=3.0.7 @@ -29 +31 @@ kombu=2.5.0 -oslo.middleware=1.0.0 # Apache-2.0 +oslo.middleware=1.2.0 # Apache-2.0 @@ -32 +34 @@ oslo.middleware=1.0.0 # Apache-2.0 -futures=2.1.6 +futures=3.0 diff --git a/test-requirements-py3.txt b/test-requirements-py3.txt index 22b4c4e..71fe497 100644 --- a/test-requirements-py3.txt +++ b/test-requirements-py3.txt @@ -19,0 +20,3 @@ redis=2.10.0 +# for test_impl_zmq +pyzmq=14.3.1 # LGPL+BSD + -- 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 1458861] Re: Unable to retrieve instances after changing to multi-domain setup
The error is coming from keystone -
http://git.openstack.org/cgit/openstack/keystone/tree/keystone/common/controller.py#n237
** Project changed: nova = keystone
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to Keystone.
https://bugs.launchpad.net/bugs/1458861
Title:
Unable to retrieve instances after changing to multi-domain setup
Status in OpenStack Identity (Keystone):
New
Bug description:
After I changed keystone to multi-domain driver, I get on the horizon
dashboard following error message when i want to display instances:
Error: Unauthorized:. Unable to retrieve instances
Name : openstack-nova-api
Arch: noarch
Version : 2014.2.2
/var/log/nova/nova.log
2015-05-26 14:09:44.512 2175 WARNING keystonemiddleware.auth_token [-]
Identity response: {error: {message: Non-default domain is not supported
(Disable debug mode to suppress these details.), code: 401, title:
Unauthorized}}
2015-05-26 14:09:44.512 2175 WARNING keystonemiddleware.auth_token [-]
Authorization failed for token
2015-05-26 14:09:44.513 2175 INFO nova.osapi_compute.wsgi.server [-]
10.0.0.10 GET
/v2/1d524a0433474fa48eb376d913a80fc1/servers/detail?limit=21project_id=1d524a0433474fa48eb376d913a80fc1
HTTP/1.1 status: 401 len: 258 time: 0.4322391
2015-05-26 14:09:44.518 2175 WARNING keystonemiddleware.auth_token [-] Unable
to find authentication token in headers
To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1458861/+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 1437902] Re: nova redeclares the `nova` named exchange zillion times without a real need
** Changed in: oslo.messaging 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/1437902 Title: nova redeclares the `nova` named exchange zillion times without a real need Status in OpenStack Compute (Nova): Incomplete Status in Messaging API for OpenStack: Fix Released Bug description: The AMQP broker preserves the exchanges, they are replaced to all broker even in non HA mode. A transient exchange can disappear ONLY when the user explicitly requests it's deletion or when the full rabbit cluster dies. More efficient to declare exchanges only when it is really missing. Application MUST redeclare the exchange when it was reported as Not Found. Note.: The Channel exceptions causes channel termination, but not connection termination. Application MAY try to redeclare the exchange on connection breakage, it can assume the messaging cluster dead. Application SHOULD redeclare the exchange at application start up to verify the attributes (Before the first usage). Application does not needs to redeclare the exchange in any other cases. Now, significant amount of the AMQP request/response-es is Exchange.Declare - Exchange.Declare-Ok. (One per publish?) To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1437902/+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] No meeting today
Hi all, Sorry for the late notice, since it is a US holiday and we all just met last week at the summit. Let's skip today's meeting and talk next week. 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 1457759] Re: Wrong oslo message keystone_authtoken username
Already fixed in oslo.config review https://review.openstack.org/#/c/169392/ ** Project changed: nova = oslo.config -- 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/1457759 Title: Wrong oslo message keystone_authtoken username Status in Oslo configuration management library: New Bug description: The following line appears in my api-log: 2015-05-22 08:46:55.205 2579 WARNING oslo_config.cfg [-] Option username from group keystone_authtoken is deprecated. Use option username from group keystone_authtoken. the corresponding configuration: [keystone_authtoken] [...] username = nova [...] So this warning is not correct and confuses. To manage notifications about this bug go to: https://bugs.launchpad.net/oslo.config/+bug/1457759/+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] [Ironic][oslo] Stepping down from oslo-ironic liaison
Thanks a lot for your work Ghe and best wishes and hope to see you back. -- dims On Mon, May 25, 2015 at 9:45 AM, Ghe Rivero g...@debian.org wrote: My focus on the Ironic project has been decreasing in the last cycles, so it's about time to relinquish my position as a oslo-ironic liaison so new contributors can take over it and help ironic to be the vibrant project it is. So long, and thanks for all the fish, Ghe Rivero -- Pinky: Gee, Brain, what do you want to do tonight? The Brain: The same thing we do every night, Pinky—try to take over the world! .''`. Pienso, Luego Incordio : :' : `. `' `-www.debian.orgwww.openstack.com GPG Key: 26F020F7 GPG fingerprint: 4986 39DA D152 050B 4699 9A71 66DB 5A36 26F0 20F7 __ 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][service] oslo.service puplic repositiry review request
Hi Elena, This looks good to me. thanks, dims On Thu, May 21, 2015 at 7:38 AM, Elena Ezhova eezh...@mirantis.com wrote: Hi, all! As the spec for the graduation of oslo.service [1] is about to merge I have created a public repository on github [2] with oslo.service initial version, which is the next step in graduation of a library according to [3]. I would like to ask everyone interested to review it so we can proceed with the graduation process. Thanks, Elena [1] https://review.openstack.org/#/c/142659/9 [2] https://github.com/eezhova/oslo.service [3] https://wiki.openstack.org/wiki/Oslo/CreatingANewLibrary __ 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] Changes to oslo.log section of Oslo Wiki page for source repo and bug reporting
Andreas, Thanks! 1. https://launchpad.net/oslo is an umbrella and oslo.log is under it. If you try to create a bug from https://bugs.launchpad.net/oslo you will be prompted to enter/choose oslo.log. So either way the bug created from either urls ends up int he same plate. So either url is ok. 2. Can you please switch it to http://git.openstack.org/cgit/openstack/oslo.log/ ? If you see http://git.openstack.org/ you will see all the projects thanks, dims On Thu, May 21, 2015 at 1:35 PM, Andreas Maier mai...@de.ibm.com wrote: Hi, I'd like to notify the Oslo community of these two changes to the oslo.log section on the Oslo Wiki page: 1. There were conflicting statements about where bugs against oslo.log should be created: - The CONTRIBUTING.rst file in oslo.log suggests: https://bugs.launchpad.net/oslo.log - The oslo.log section on the Oslo Wiki page mentions: https://bugs.launchpad.net/oslo Based on where bugs are currently open, I suspected that the information on the Oslo Wiki page would be outdated, and updated it accordingly. 2. There was no link to a source repo yet for oslo.log on the Oslo Wiki page, so I added one to the github.com repo. If any of that was a bad idea, please let me know. Andy __ 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] needed, driver for oslo.db thursday session
Thanks Jeremy, Mike, Roman, Victor, Please see remote connection details in: https://etherpad.openstack.org/p/YVR-oslo-db-plans The schedule time for the session is in: https://libertydesignsummit.sched.org/event/3571aa54b364c62e097da8cd32d97258 Hope you can make it :) yes, please pick one of the 2 choices there (either sip or google hangout) and drop a note in the etherpad which one you want me to connect to thanks, dims On Tue, May 19, 2015 at 10:17 AM, Jeremy Stanley fu...@yuggoth.org wrote: On 2015-05-19 09:06:56 -0700 (-0700), Davanum Srinivas wrote: Ouch. Thanks for the heads up Roman We have https://wiki.openstack.org/wiki/Infrastructure/Conferencing which we used yesterday to successfully bridge Clark B. into an I18n tooling session via Jitsi over the normal conference wireless network with the built-in mic/speaker in Jim's laptop. Feel free to use it in your sessions, just try to pick a random conference number between 6000 and 7999 so nobody steps on the toes of other sessions which might be using it (maybe add your conference room number to 6000 or something?). Let me or other Infra people know if you have any questions about or trouble using it! -- 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 -- 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] Inviting Robert Collins to Oslo core
Hi Team, I'd like to invite Robert Collins (aka lifeless) as an Oslo core. Robert has been a long time contributor to a whole bunch of OpenStack projects and a member of our TC. Robert indicated that he can help across Oslo projects this cycle, so let's please welcome him. Here's my +1. thanks, Dims [1] http://stackalytics.com/?user_id=lifelessrelease=all [2] https://www.openstack.org/foundation/tech-committee/ -- 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] needed, driver for oslo.db thursday session
Mike, Thanks for the heads up. Wow 26 hours. crazy! No worries. we'll make something out of the session and report back -- dims On Tue, May 19, 2015 at 7:24 AM, Mike Bayer mba...@redhat.com wrote: ouch ! maybe next summit will be on the Lost island. another easy place to get to ! :) On 5/19/15 9:08 AM, Roman Podoliaka wrote: Hi all, Just FYI, due to problems with obtaining a Canadian visa, neither Victor Sergeyev, nor I made it to Vancouver. I hope someone else from Oslo team can replace Mike as a session driver. Thanks, Roman On Tue, May 19, 2015 at 3:53 AM, Mike Bayer mba...@redhat.com wrote: Hello - It is my extreme displeasure and frustration to announce that due to an incredibly unfortunate choice of airline, I had to cancel my entire trip to the Openstack summit after spending 26 hours in my home airport waiting for my airline to produce a working airplane (which they did not). I will not be able to attend in person the Thursday oslo.db session I was to drive, so a replacement will be needed. I am also lamenting not being able to meet so many of you who I hoped very much to meet. Hope you all enjoy the summit and I hope our paths can cross at future events. - mike __ 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
Re: [openstack-dev] [oslo] needed, driver for oslo.db thursday session
Ouch. Thanks for the heads up Roman -- dims On Tue, May 19, 2015 at 6:08 AM, Roman Podoliaka rpodoly...@mirantis.com wrote: Hi all, Just FYI, due to problems with obtaining a Canadian visa, neither Victor Sergeyev, nor I made it to Vancouver. I hope someone else from Oslo team can replace Mike as a session driver. Thanks, Roman On Tue, May 19, 2015 at 3:53 AM, Mike Bayer mba...@redhat.com wrote: Hello - It is my extreme displeasure and frustration to announce that due to an incredibly unfortunate choice of airline, I had to cancel my entire trip to the Openstack summit after spending 26 hours in my home airport waiting for my airline to produce a working airplane (which they did not). I will not be able to attend in person the Thursday oslo.db session I was to drive, so a replacement will be needed. I am also lamenting not being able to meet so many of you who I hoped very much to meet. Hope you all enjoy the summit and I hope our paths can cross at future events. - mike __ 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] [nova-docker] Status update
Adam, Please follow the discussion on the nova-spec review: https://review.openstack.org/#/c/128753/ At the moment, we need folks actively watching the project in terms of reviews, gate/check job failures, keeping up with Nova trunk etc. Please let me know if you or anyone else is interested. thanks, dims On Tue, May 19, 2015 at 10:48 AM, ADAMS, STEVEN E sa2...@att.com wrote: Has there been any decision made on if and when the nova-docker driver will move back to the Nova tree and out of Stackforge? -Steve Adams __ 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][cinder][neutron][security] Rootwrap discussions at OSSG mid-cycle
Brant, I started work to use rootwrap as daemon in Nova fyi: https://review.openstack.org/#/c/180695/ Don't know if this will help -- dims On Thu, May 14, 2015 at 11:55 AM, Brant Knudson b...@acm.org wrote: On Thu, May 14, 2015 at 2:48 AM, Angus Lees g...@inodes.org wrote: On Wed, 13 May 2015 at 02:16 Thierry Carrez thie...@openstack.org wrote: Lucas Fisher wrote: We spent some time at the OSSG mid-cycle meet-up this week discussing root wrap, looking at the existing code, and considering some of the mailing list discussions. Summary of our discussions: https://github.com/hyakuhei/OSSG-Security-Practices/blob/master/ossg_rootwrap.md The one line summary is we like the idea of a privileged daemon with higher level interfaces to the commands being run. It has a number of advantages such as easier to audit, enables better input sanitization, cleaner interfaces, and easier to take advantage of Linux capabilities, SELinux, AppArmour, etc. The write-up has some more details. For those interested in that topic and willing to work on the next stage, we'll have a work session on the future of rootwrap in the Oslo track at the Design Summit in Vancouver: http://sched.co/3B2B Fwiw, I've continued work on my privsep proposal(*) and how it interacts with existing rootwrap. I look forward to discussing it and alternatives at the session. (*) https://review.openstack.org/#/c/155631 - Gus As part of the OSSG work, I started prototyping changes in Nova where the goal is to 1) Get all the code that's calling rootwrap into one place so that it's easy to find, and get tests for this code. 2) Next (or even in step 1 if it's easy enough), tighten the interfaces, so that rather than providing a function to do chmod %s %s it would only allow whatever chmod nova actually has to do, maybe passing in a server ID rather than a bare file name. With this, we should be able to tighten up the rootwrap filters in the same way, or switch to privsep or whatever we decide to do in the future. So maybe it looks like rearranging deckchairs on the titanic, but in this case the deckchairs are blocking the emergency exits. I didn't get too far in it to even see how viable the approach is since I was working on other things. I'll put this session on my calendar. - Brant __ 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 1454455] Re: nova doesn't log to syslog
** Also affects: oslo.log 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/1454455 Title: nova doesn't log to syslog Status in OpenStack Compute (Nova): New Status in Logging configuration library for OpenStack: New Bug description: Logs from nova are not recorded when using syslog. Neutron logging works fine using the same rsyslog service. I've tried with debug and verbose enabled and disabled. 1) Nova version: 1:2014.2.2-0ubuntu1~cloud0 on Ubuntu 14.04 2) Relevant log files: No relevant log files, as that is the problem 3) Reproduction steps: a) Set the following in nova.conf logdir=/var/log/nova b) Restart nova services c) Confirm that logs are created in /var/log/nova d) Remove logdir and add the following to nova.conf use_syslog=true syslog_log_facility=LOG_LOCAL0 e) Restart nova services f) Nova's logs are not showing up in /var/log/syslog To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1454455/+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-docker] [magnum] [nova] Returning nova-docker to Nova Tree
Thanks for this response Daniel!. On Tue, May 12, 2015 at 4:59 AM, Daniel P. Berrange berra...@redhat.com wrote: On Mon, May 11, 2015 at 03:58:59PM -0400, Russell Bryant wrote: On 05/11/2015 03:51 PM, Adrian Otto wrote: I invite Nova and nova-docker team members to join us to discuss this topic, and give us your input. If the Magnum team is interested in helping to maintain it, why not just keep it as a separate repo? What's the real value in bringing it into the Nova tree? Well if that's the question you have to really ask why any of the current drivers are in tree. I don't really think it makes sense to single out Docker for special treatment, requiring them to justify why they want to be in tree. IMHO if we want drivers to live out of tree we should push them all out, if we want drivers to live in tree then we should actively welcome in any driver that has a team of people willing to maintain it, not require justification for wanting to be in tree. Regards, Daniel -- |: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| __ 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][oslo] disabling pypy unit test jobs for oslo
requirements jobs are stuck as well :( http://logs.openstack.org/30/170830/6/check/gate-requirements-pypy/732dc33/console.html#_2015-05-11_01_25_22_506 -- dims On Mon, May 11, 2015 at 6:19 AM, Steven Hardy sha...@redhat.com wrote: On Mon, May 11, 2015 at 11:52:13AM +0200, Julien Danjou wrote: On Fri, May 08 2015, Doug Hellmann wrote: The jobs running unit tests under pypy are failing for several Oslo libraries for reasons that have nothing to do with the libraries themselves, as far as I can tell (they pass locally). I have proposed a change to mark the jobs as non-voting [1] until someone can fix them, but we need a volunteer to look at the failure and understand why they fail. Does anyone want to step up to do that? If we don't have a volunteer in the next couple of weeks, I'll go ahead and remove the jobs so we can use those test nodes for other jobs. I'm willing to take a look at those, do you have any link to a review/job that failed? I suspect we're impacted by the same issue for python-heatclient, nearly all of our patches are failing the pypy job, e.g: http://logs.openstack.org/56/178756/4/gate/gate-python-heatclient-pypy/66e4dcc/console.html The error error: option --single-version-externally-managed not recognized looks a lot like bug 1290562 which was closed months ago. I've raised https://bugs.launchpad.net/python-heatclient/+bug/1453095, because I didn't know what component (other than heatclient) this could be assigned to. I'm attempting the bug 1290562 workaround here: https://review.openstack.org/#/c/181851/ If we can't figure out what the problem is, I guess we'll have to temporarily disable our pypy job too, any insights appreciated! :) Steve __ 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][oslo] disabling pypy unit test jobs for oslo
Thanks Sean, filed this review to mark them as non-voting to start with: https://review.openstack.org/181870 -- dims On Mon, May 11, 2015 at 7:51 AM, Sean Dague s...@dague.net wrote: It appears that we've basically run out of interest / time in realistically keeping pypy working in our system. With the focus on really getting python 3.4 working, it seems like it would just be better to drop pypy entirely in the system. In the last couple of years we've not seen any services realistically get to the point of being used for any of the services. And as seen by this last failure, pypy is apparently not keeping up with upstream tooling changes. -Sean On 05/11/2015 06:50 AM, Davanum Srinivas wrote: requirements jobs are stuck as well :( http://logs.openstack.org/30/170830/6/check/gate-requirements-pypy/732dc33/console.html#_2015-05-11_01_25_22_506 -- dims On Mon, May 11, 2015 at 6:19 AM, Steven Hardy sha...@redhat.com wrote: On Mon, May 11, 2015 at 11:52:13AM +0200, Julien Danjou wrote: On Fri, May 08 2015, Doug Hellmann wrote: The jobs running unit tests under pypy are failing for several Oslo libraries for reasons that have nothing to do with the libraries themselves, as far as I can tell (they pass locally). I have proposed a change to mark the jobs as non-voting [1] until someone can fix them, but we need a volunteer to look at the failure and understand why they fail. Does anyone want to step up to do that? If we don't have a volunteer in the next couple of weeks, I'll go ahead and remove the jobs so we can use those test nodes for other jobs. I'm willing to take a look at those, do you have any link to a review/job that failed? I suspect we're impacted by the same issue for python-heatclient, nearly all of our patches are failing the pypy job, e.g: http://logs.openstack.org/56/178756/4/gate/gate-python-heatclient-pypy/66e4dcc/console.html The error error: option --single-version-externally-managed not recognized looks a lot like bug 1290562 which was closed months ago. I've raised https://bugs.launchpad.net/python-heatclient/+bug/1453095, because I didn't know what component (other than heatclient) this could be assigned to. I'm attempting the bug 1290562 workaround here: https://review.openstack.org/#/c/181851/ If we can't figure out what the problem is, I guess we'll have to temporarily disable our pypy job too, any insights appreciated! :) Steve __ 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 -- 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
[openstack-dev] Who is using nova-docker? (Re: [nova-docker] Status update)
Good points, Dan and John. At this point it may be useful to see who is actually using nova-docker. Can folks who are using any version of nova-docker, please speak up with a short description of their use case? Thanks, dims On Mon, May 11, 2015 at 10:06 AM, Dan Smith d...@danplanet.com wrote: +1 Agreed nested containers are a thing. Its a great reason to keep our LXC driver. I don't think that's a reason we should keep our LXC driver, because you can still run containers in containers with other things. If anything, using a nova vm-like container to run application-like containers inside them is going to beg the need to tweak more detailed things on the vm-like container to avoid restricting the application one, I think. IMHO, the reason to keep the seldom-used, not-that-useful LXC driver in nova is because it's nearly free. It is the libvirt driver with a few conditionals to handle different things when necessary for LXC. The docker driver is a whole other nova driver to maintain, with even less applicability to being a system container (IMHO). I am keen we set the right expectations here. If you want to treat docker containers like VMs, thats OK. I guess a remaining concern is the driver dropping into diss-repair if most folks end up using Magnum when they want to use docker. I think this is likely the case and I'd like to avoid getting into this situation again. IMHO, this is not our target audience, it's very much not free to just put it into the tree because meh, some people might like it instead of the libvirt-lxc driver. --Dan __ 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 1453268] Re: dynamic nova.conf generation does not work without python-barbicanclient installed
** Changed in: oslo.config 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/1453268 Title: dynamic nova.conf generation does not work without python- barbicanclient installed Status in OpenStack Compute (Nova): Invalid Status in OpenStack Compute (nova) kilo series: New Status in Oslo configuration management library: Invalid Bug description: In gentoo we dynamically generate the docs (we also package stable branch releases that install from git). This doesn't work unless python-barbicanclient is installed. What I would like to see is either a silent failure with that section of nova.conf removed or just add python-barbicanclient to requirements from test-requirements. I understand that it is expected that example conf generation is expected to need test-requirements, but I don't agree :P Let me know if you need more info. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1453268/+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] Adding Mehdi Abaakouk (sileht) to oslo-core
Dear Oslo folks, I'd like to propose adding Mehdi Abaakouk to oslo-core. He is already leading the oslo.messaging team and helping with Tooz, and futurist efforts. I am hoping to get Mehdi more involved across the board in Oslo. 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.config] MultiStrOpt VS. ListOpt
ZhiQiang, Please log a bug and we can try to do what jd suggested. -- dims On Wed, May 6, 2015 at 9:21 AM, Julien Danjou jul...@danjou.info wrote: On Wed, May 06 2015, ZhiQiang Fan wrote: I come across a problem that crudini cannot handle MultiStrOpt[1], I don't know why such type configuration option is needed. It seems ListOpt is a better choice. Currently I find lots of MultiStrOpt options in both Nova and Ceilometer, and I think other projects have too. Here are my questions: 1) how can I update such type of option without manually rewrite the config file? (like devstack scenario) 2) Is there any way to migrate MultiStrOpt to ListOpt? The ListOpt will take last specified value while MultiStrOpt takes all, so the compatibility is a big problem Any hints? I didn't check extensively, but this is something I hit regularly. It seems to me we have to two types doing more or less the same things and mapping to the same data structure (i.e. list). We should unify them. -- Julien Danjou // Free Software hacker // http://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] Adding Joshua Harlow to oslo-core
+1 from me!! -- dims On Tue, May 5, 2015 at 10:47 AM, Julien Danjou jul...@danjou.info wrote: Hi fellows, I'd like to propose that we add Joshua Harlow to oslo-core. He is already maintaining some of the Oslo libraries (taskflow, tooz…) and he's helping on a lot of other ones for a while now. Let's bring him in for real! -- Julien Danjou -- Free Software hacker -- http://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
[Yahoo-eng-team] [Bug 1440773] Re: Remove WritableLogger as eventlet has a real logger interface in 0.17.2
We need to use self._logger directly in Nova and deprecate WritableLogger in oslo.log ** Summary changed: - Deprecate WritableLogger as eventlet has a real logger interface in 0.17.2 + Remove WritableLogger as eventlet has a real logger interface in 0.17.2 ** 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/1440773 Title: Remove WritableLogger as eventlet has a real logger interface in 0.17.2 Status in OpenStack Compute (Nova): In Progress Status in Logging configuration library for OpenStack: New Bug description: Info from Sean on IRC: the patch to use a real logger interface in eventlet has been released in 0.17.2, which means we should be able to phase out https://github.com/openstack/oslo.log/blob/master/oslo_log/loggers.py Eventlet PR was: https://github.com/eventlet/eventlet/pull/75 thanks, dims To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1440773/+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] [all] Sign up for oslo liaisons for liberty cycle
[ re-sending an almost identical email from Doug sent just before kilo cycle :) ] The Oslo team is responsible for managing code shared between projects. There are a LOT more projects than Oslo team members, so we created the liaison program at the beginning of the Juno cycle, asking each team that uses Oslo libraries to provide one volunteer liaison. Our liaisons facilitate communication and work with us to make the application code changes needed as code moves out of the incubator and into libraries. With this extra help in place, we were able to successfully graduate 7 new libraries and begin having them adopted across OpenStack. With the change-over to the new release cycle, it’s time to ask for volunteers to sign up to be liaisons again. If you are interested in acting as a liaison for your project, please sign up on the wiki page [1]. It would be very helpful to have a full roster before the summit, so we can make sure liaisons are invited to participate in any relevant discussions there. If you are curious about the current state of planning for Liberty, please peek at [2] and [3]. Thanks, Dims [1] https://wiki.openstack.org/wiki/Oslo/ProjectLiaisons [2] https://etherpad.openstack.org/p/liberty-oslo-summit-planning [3] https://libertydesignsummit.sched.org/overview/type/design+summit/Oslo -- 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] [pbr] pbr-release includes oslo-core?
Not sure about the history, but +1 to remove oslo-core from that group. -- dims On Mon, May 4, 2015 at 6:59 PM, Robert Collins robe...@robertcollins.net wrote: Clark and I spotted this when releasing 0.11 - pbr-release, the group of folk that can cut a release, includes oslo-release (expected) and also unexpectedly oslo-core. https://review.openstack.org/#/admin/groups/387,members This means that folk that are olso-core, but can't release regular libraries can release the one special-case library in oslo (pbr, because setup_requires) - this doesn't make sense to me or Clark :). Anyone with insight please shout out now, if we don't hear anything back justifying this, I'll remove oslo-core from pbr-release later this week. -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 -- 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] [pbr] regular releases, and path to 1.0
+1 to call the current master as 1.0 +1 to more frequent releases (not sure if it should be every monday though!) -- dims On Mon, May 4, 2015 at 3:53 PM, Robert Collins robe...@robertcollins.net wrote: Hi, I'd like to talk about how often we can and should release pbr, and what criteria we should use for 1.0. tl;dr: release weekly [outside of organisation-wide-freezes], do a 1.0 immediately. pbr, like all our libraries affects everything when its released, but unlike everything else in oslo, it is an open ended setup_requires dependency. It's like this because of https://github.com/pypa/pip/issues/2666 - when setuptools encounters a setup_requires constraint that conflicts with an already installed version, it just gives up. Until thats fixed, if we express pbr constraints like pbr 1.0 we'll cause everything that has previously released to hard-fail to install as soon as anything in the environment has pulled in a pbr that doesn't match the constraint. This will get better once we have pip handle setup_requires with more scaffolding... we can in principle get to the point where we can version the pbr setup_requires dependencies. However - thats future, and indefinite at this point. So, for pbr we need to have wide open constraints in setup_requires, and it must be in setup_requires (otherwise pip can't build egg info at all and thus can't probe the install_requires dependencies). The consequence of this is that pbr has to be ultra conservative - we're not allowed any deliberate API breaks for the indefinite future, and even once the tooling supports it we'd have to wait for all the current releases of things that couldn't be capped to semantic versioning limits, to be unsupported. So - we're at least 18 months away from any possible future where API breaks - a 2.0 - are possible without widespread headaches. In light of this, I'd like to make two somewhat related proposals. Firstly, I'd like to just call the current master 1.0: its stable, we're supporting it, its not going anywhere rash, it has its core feature set. Those are the characteristics of 1.0 in most projects :). Its not a big splashy 1.0 but who cares..., and there's more we need, but thats what 1.x is for. Secondly, I'd like to release every Monday (assuming no pending reverts): I'd like to acknowledge the reality that we have approximately zero real world testing of master - we're heavily dependent on our functional tests. The only two reasons to wait for releasing are a) to get more testing, and we don't get that, and b) to let -core notice mistakes and back things out. Waiting to release once an improvement is in master just delays giving the benefits to our users. -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 -- 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-operators] FYI: Rabbit Heartbeat Patch Landed
Sam, 1. Weird, did you pick it up from ubuntu cloud archive? we could raise a bug against them 2. yes, not much we can do about that now i guess. 3. yes, Can you please log a bug for this? Thanks! On Sun, May 3, 2015 at 9:45 PM, Sam Morrison sorri...@gmail.com wrote: I’ve found a couple of issues with this: 1. Upgrading the packages in ubuntu doesn’t seem to work, you need to remove them all then install fresh. Some conflicts with file paths etc. 2. With juno heat the requirements.txt has upper limits on the versions for oslo deps. I just removed these and it seems to work fine. 3. When using amqp_durable_queues it will no longer declare the exchanges with this argument set so this will give errors when declaring the exchange. (I think this is a bug, at least an upgrade bug as this will affect people moving juno - kilo) On 4 May 2015, at 9:08 am, Sam Morrison sorri...@gmail.com wrote: We’re running: kombu: 3.0.7 amqp: 1.4.5 rabbitmq, 3.3.5 erlang: R14B04 On 2 May 2015, at 1:51 am, Kris G. Lindgren klindg...@godaddy.com wrote: We are running: kombu 3.0.24 amqp 1.4.6 rabbitmq 3.4.0 erlang R16B-03.10 Kris Lindgren Senior Linux Systems Engineer GoDaddy, LLC. On 5/1/15, 9:41 AM, Davanum Srinivas dava...@gmail.com wrote: may i request folks post the versions of rabbitmq and pip versions of kombu and amqp libraries? thanks, dims On Fri, May 1, 2015 at 11:29 AM, Mike Dorman mdor...@godaddy.com wrote: We¹ve been running the new oslo.messaging under Juno for about the last month, and we¹ve seen success with it, too. From: Sam Morrison Date: Thursday, April 30, 2015 at 11:02 PM To: David Medberry Cc: OpenStack Operators Subject: Re: [Openstack-operators] FYI: Rabbit Heartbeat Patch Landed Great, let me know how you get on. On 1 May 2015, at 12:21 pm, David Medberry openst...@medberry.net wrote: Great news Sam. I'll pull those packages into my Juno devel environment and see if it makes any difference. Much appreciated for the rebuilds/links. Also, good to connect with you at ... Connect AU. On Thu, Apr 30, 2015 at 7:30 PM, Sam Morrison sorri...@gmail.com wrote: I managed to get a juno environment with oslo.messaging 1.8.1 working in ubuntu 14.04 I have a debian repo with all the required dependancies at: deb http://download.rc.nectar.org.au/nectar-ubuntu trusty-juno-testing-oslo main All it includes is ubuntu official packages from vivid. Have installed in our test environment and all looking good so far although haven¹t done much testing yet. Sam On 21 Mar 2015, at 2:35 am, David Medberry openst...@medberry.net wrote: Hi Sam, I started down the same path yesterday. If I have any success today, I'll post to this list. I'm also going to reach out to the Ubuntu Server (aka Cloud) team and so if they can throw up a PPA with this for Juno quickly (which they will likely NOT do but it doesn't hurt to ask.) We need to get the stable/juno team on board with this backport/regression. On Fri, Mar 20, 2015 at 4:14 AM, Sam Morrison sorri...@gmail.com wrote: I¹ve been trying to build a ubuntu deb of this in a juno environment. It¹s a bit of a nightmare as they have changed all the module names from oslo.XXX to oslo_XXX Have fixed those up with a few sed replaces and had to remove support for aioeventlet as the dependencies aren¹t in the ubuntu cloud archive juno. Still have a couple of tests failing but I think it *should* work in on our juno hosts. I have a branch of the 1.8.0 release that I¹m trying to build against Juno here [1] and I¹m hoping that it will be easy to integrate the heartbeat code. I¹m sure there is lots of people that would be keen to get a latest version of oslo.messaging working against a juno environment. What is the best way to make that happen though? Cheers, Sam [1] https://github.com/NeCTAR-RC/oslo.messaging/commits/nectar/1.8.0 On 20 Mar 2015, at 8:59 am, Davanum Srinivas dava...@gmail.com wrote: So, talking about experiments, here's one: https://review.openstack.org/#/c/165981/ Trying to run oslo.messaging trunk against stable/juno of the rest of the components. -- dims On Thu, Mar 19, 2015 at 5:10 PM, Matt Fischer m...@mattfischer.com wrote: I think everyone is highly interested in running this change or a newer OSLO messaging in general + this change in Juno rather than waiting for Kilo. Hopefully everyone could provide updates as they do experiments. On Thu, Mar 19, 2015 at 1:22 PM, Kevin Bringard (kevinbri) kevin...@cisco.com wrote: Can't speak to that concept, but I did try cherry picking the commit into the stable/juno branch of oslo.messaging and there'd definitely be some work to be done there. I fear that could mean havoc for trying to just use master oslo as well, but a good idea to try for sure. -- Kevin On Mar 19, 2015, at 1:13 PM, Jesse Keating j...@bluebox.net
[openstack-dev] [nova-docker] Status update
Anyone still interested in this work? :) * there's a stable/kilo branch now (see http://git.openstack.org/cgit/stackforge/nova-docker/). * CI jobs are running fine against both nova trunk and nova's stable/kilo branch. * there's an updated nova-spec to get code back into nova tree (see https://review.openstack.org/#/c/128753/) 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-operators] FYI: Rabbit Heartbeat Patch Landed
may i request folks post the versions of rabbitmq and pip versions of kombu and amqp libraries? thanks, dims On Fri, May 1, 2015 at 11:29 AM, Mike Dorman mdor...@godaddy.com wrote: We’ve been running the new oslo.messaging under Juno for about the last month, and we’ve seen success with it, too. From: Sam Morrison Date: Thursday, April 30, 2015 at 11:02 PM To: David Medberry Cc: OpenStack Operators Subject: Re: [Openstack-operators] FYI: Rabbit Heartbeat Patch Landed Great, let me know how you get on. On 1 May 2015, at 12:21 pm, David Medberry openst...@medberry.net wrote: Great news Sam. I'll pull those packages into my Juno devel environment and see if it makes any difference. Much appreciated for the rebuilds/links. Also, good to connect with you at ... Connect AU. On Thu, Apr 30, 2015 at 7:30 PM, Sam Morrison sorri...@gmail.com wrote: I managed to get a juno environment with oslo.messaging 1.8.1 working in ubuntu 14.04 I have a debian repo with all the required dependancies at: deb http://download.rc.nectar.org.au/nectar-ubuntu trusty-juno-testing-oslo main All it includes is ubuntu official packages from vivid. Have installed in our test environment and all looking good so far although haven’t done much testing yet. Sam On 21 Mar 2015, at 2:35 am, David Medberry openst...@medberry.net wrote: Hi Sam, I started down the same path yesterday. If I have any success today, I'll post to this list. I'm also going to reach out to the Ubuntu Server (aka Cloud) team and so if they can throw up a PPA with this for Juno quickly (which they will likely NOT do but it doesn't hurt to ask.) We need to get the stable/juno team on board with this backport/regression. On Fri, Mar 20, 2015 at 4:14 AM, Sam Morrison sorri...@gmail.com wrote: I’ve been trying to build a ubuntu deb of this in a juno environment. It’s a bit of a nightmare as they have changed all the module names from oslo.XXX to oslo_XXX Have fixed those up with a few sed replaces and had to remove support for aioeventlet as the dependencies aren’t in the ubuntu cloud archive juno. Still have a couple of tests failing but I think it *should* work in on our juno hosts. I have a branch of the 1.8.0 release that I’m trying to build against Juno here [1] and I’m hoping that it will be easy to integrate the heartbeat code. I’m sure there is lots of people that would be keen to get a latest version of oslo.messaging working against a juno environment. What is the best way to make that happen though? Cheers, Sam [1] https://github.com/NeCTAR-RC/oslo.messaging/commits/nectar/1.8.0 On 20 Mar 2015, at 8:59 am, Davanum Srinivas dava...@gmail.com wrote: So, talking about experiments, here's one: https://review.openstack.org/#/c/165981/ Trying to run oslo.messaging trunk against stable/juno of the rest of the components. -- dims On Thu, Mar 19, 2015 at 5:10 PM, Matt Fischer m...@mattfischer.com wrote: I think everyone is highly interested in running this change or a newer OSLO messaging in general + this change in Juno rather than waiting for Kilo. Hopefully everyone could provide updates as they do experiments. On Thu, Mar 19, 2015 at 1:22 PM, Kevin Bringard (kevinbri) kevin...@cisco.com wrote: Can't speak to that concept, but I did try cherry picking the commit into the stable/juno branch of oslo.messaging and there'd definitely be some work to be done there. I fear that could mean havoc for trying to just use master oslo as well, but a good idea to try for sure. -- Kevin On Mar 19, 2015, at 1:13 PM, Jesse Keating j...@bluebox.net wrote: On 3/19/15 10:15 AM, Davanum Srinivas wrote: Apologies. i was waiting for one more changeset to merge. Please try oslo.messaging master branch https://github.com/openstack/oslo.messaging/commits/master/ (you need at least till Change-Id: I4b729ed1a6ddad2a0e48102852b2ce7d66423eaa - change id is in the commit message) Please note that these changes are NOT in the kilo branch that has been cut already https://github.com/openstack/oslo.messaging/commits/stable/kilo So we need your help with testing to promote it to kilo for you all to use it in Kilo :) Please file reviews or bugs or hop onto #openstack-oslo if you see issues etc. Many thanks to Kris Lindgren to help shake out some issues in his environment. How bad of an idea would it be to run master of oslo.messaging with juno code base? Explosions all over the place? -- -jlk ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
Re: [openstack-dev] [nova] Proposal to add Melanie Witt to nova-core
+1 from me as well! (Ditto as Ed, not a core). -- dims On Thu, Apr 30, 2015 at 9:00 AM, Ed Leafe e...@leafe.com wrote: On Apr 30, 2015, at 6:30 AM, John Garbutt j...@johngarbutt.com wrote: I propose we add Melanie to nova-core. I know I'm not core, so my vote doesn't count, but I think that this would be a great addition. +1 -- Ed Leafe __ 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] [tc] Who is allowed to vote for TC candidates
One concrete suggestion based on my experience working with Kris Lindgren on Heartbeat patch: http://markmail.org/message/gifrt5f3mslco24j I could have added a Co-Tested-By (or Co-Operator - get it? :) in my commit message which would have signaled a concrete contribution/feedback with specific folks in the operator community. This could be done not just for code, could be for reviews or documentation etc as well. WDYT? thanks, dims On Thu, Apr 30, 2015 at 9:06 PM, Adam Lawson alaw...@aqorn.com wrote: I think it's easy to quantify a code contributor since we have systems that monitor activity - who contributed, what they contributed and when. But we don't have a system that monitors operator activity and honestly, that's the question mark for which I really don't have any answers. That might be our first hurdle - how define the difference between a causal user making remarks on the mailing lists and someone who works with the technology and engages. We'd have to quantify them differently somehow. Maybe attending an operators meeting would qualify someone to vote? On Apr 30, 2015 5:35 PM, Stefano Maffulli stef...@openstack.org wrote: On Thu, 2015-04-30 at 12:26 +0200, Flavio Percoco wrote: I've seen the number of threads to discuss Ops topics increase in openstack-dev and the influence of Ops - even just points of views inherited from the feedback we've got - on reviews has gotten better as well. Fantastic, that has always been the intention. If it's a matter of having more Ops voting for the TC, we do have a process in place that we could likely improve. Other than that, I believe Thierry and Doug have explained perfectly the issues related to having these 2 groups merged from a *governance* perspective. I noticed that this round of elections we had TC *candidates* that at least I consider more operators than strictly 'dev'. That, to me, is a huge sign of the progress we've made to integrate the two categories. To me the real big question is: how are candidates from the operators side going to get a better chance of being elected next time? And what's the role of the User Committee in all this? /stef __ 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] [Congress] [Murano] Congress devstack installation is failing in murano gate job
So, summarizing some chatter on #openstack-dev: Action item for unblocking the gate job: 1. Remove the -U in the shell script that installs thirdparty-requirements.txt in congress' repo. If that's not enough: 2. make sure congress' stable/kilo requirements.txt/test-requirements.txt is sync'ed with the global stable/kilo. -- dims On Wed, Apr 29, 2015 at 11:32 AM, Doug Hellmann d...@doughellmann.com wrote: Excerpts from Brant Knudson's message of 2015-04-29 09:17:08 -0500: On Wed, Apr 29, 2015 at 9:11 AM, Sean Dague s...@dague.net wrote: On 04/29/2015 10:05 AM, Sean Dague wrote: On 04/29/2015 09:29 AM, Filip Blaha wrote: Hi Serg I checked devstack log [1] and it seems that stevedore==1.4.0 was installed due to congress 2015-04-29 11:12:16.120 http://logs.openstack.org/61/178461/1/check/gate-murano-congress-devstack-dsvm/fa01b8f/logs/devstacklog.txt.gz#_2015-04-29_11_12_16_120 | Successfully installed PyYAML-3.11 argparse-1.3.0 jsonpatch-1.9 jsonpointer-1.7 oslo.config-1.11.0 pyOpenSSL-0.15.1 python-cloudfoundryclient-1.0.2 requests-2.6.2 stevedore-1.4.0 It is last entry in log mentioning installation stevedore [1] http://logs.openstack.org/61/178461/1/check/gate-murano-congress-devstack-dsvm/fa01b8f/logs/devstacklog.txt.gz Not, it was installed due to keystonemiddleware - http://logs.openstack.org/61/178461/1/check/gate-murano-congress-devstack-dsvm/fa01b8f/logs/devstacklog.txt.gz#_2015-04-29_11_02_13_727 Actually, it's more insideous than this. It's installed at 1.4.0 there, then it's downgraded to 1.3.0 when glance is installed, and then it's pushed back to 1.4.0 because of: http://logs.openstack.org/61/178461/1/check/gate-murano-congress-devstack-dsvm/fa01b8f/logs/devstacklog.txt.gz#_2015-04-29_11_12_08_418 pip install -U should not be used in the general case, only in *very* specific cases. Whatever is hardcoding -U is the source of your problem. -Sean -- Sean Dague http://dague.net There's a review posted to update keystonemiddleware's requirements: https://review.openstack.org/#/c/173972/ . It was broken for a while after the branch was created due to pycadf installing oslo.messaging. For some reason it's working now even without the pycadf changes, but Doug H has a -2 on it. I'd like to know what the reqs are supposed to be for all the stable/kilo libraries -- I assumed we wanted them all to match global-requirements. We're in the process of figuring out how we want to deal with the caps. Adding caps to the requirements of libraries introduces challenges, so we're considering removing those and having applications cap all of their transitive dependencies. We need more time to think about it, and we're going to have a summit session in a couple of weeks, so we're not going to land patches now that we might have to undo later on. We also want to be mindful that changing the requirements of the library may involve breaking semver if we release a new stable version, and we only want to do that once per library if we do it at all. Doug I think all of our tox.ini's have -U: http://git.openstack.org/cgit/openstack/nova/tree/tox.ini#n6 - Brant __ 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
