Re: [openstack-dev] [Cinder] Nominating Scott D'Angelo to Cinder core
One more vote from "not a core member" . I am not a core and I am mainly involved in the Nova project where Scott presence is always useful and valuable when we need to sort out some cinder <-> nova issue. -- Andrea Rosa On 27/06, Sean McGinnis wrote: > I would like to nominate Scott D'Angelo to core. Scott has been very > involved in the project for a long time now and is always ready to help > folks out on IRC. His contributions [1] have been very valuable and he > is a thorough reviewer [2]. > > Please let me know if there are any objects to this within the next > week. If there are none I will switch Scott over by next week, unless > all cores approve prior to then. > > Thanks! > > Sean McGinnis (smcginnis) > > [1] > https://review.openstack.org/#/q/owner:%22Scott+DAngelo+%253Cscott.dangelo%2540hpe.com%253E%22+status:merged > [2] http://cinderstats-dellstorage.rhcloud.com/cinder-reviewers-90.txt > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova][cinder] what are the key errors with volume detach
Hi thanks Sean for bringing this point, I have been working on the change and on the (abandoned) spec. I'll try here to summarize all the discussions we had and what we decided. > From: Sean Dague [mailto:s...@dague.net] > Sent: 02 December 2015 13:31 > To: OpenStack Development Mailing List (not for usage questions) > Subject: [openstack-dev] [nova] what are the key errors with volume detach > > This patch to add a bunch of logic to nova-manage for forcing volume detach > raised a bunch of questions > https://review.openstack.org/#/c/184537/24/nova/cmd/manage.py,cm On this specific review there are some valid concerns that I am happy to address, but first we need to understand if we want this change. FWIW I think it is still a valid change, please see below. > In thinking about this for the last day, I think the real concern is that we > have > so many safety checks on volume delete, that if we failed with a partially > setup volume, we have too many safety latches to tear it down again. > > Do we have some detailed bugs about how that happens? Is it possible to > just fix DELETE to work correctly even when we're in these odd states? In a simplified view of a detach volume we can say that the nova code does: 1 detach the volume from the instance 2 Inform cinder about the detach and call the terminate_connection on the cinder API. 3 delete the dbm recod in the nova DB If 2 fails the volumes get stuck in a detaching status and any further attempt to delete or detach the volume will fail: "Delete for volume failed: Volume is still attached, detach volume first. (HTTP 400)" And if you try to detach: "EROR (BadRequest): Invalid input received: Invalid volume: Unable to detach volume. Volume status must be 'in-use' and attach_status must be 'attached' to detach. Currently: status: 'detaching', attach_status: 'attached.' (HTTP 400)" at the moment the only way to clean up the situation is to hack the nova DB for deleting the bdm record and do some hack on the cinder side as well. We wanted a way to clean up the situation avoiding the manual hack to the nova DB. Solution proposed #1 Move the deletion of the bdm record so as it happens before calling cinder, I thought that was ok as from nova side we have done, no leaking bdm and the problem was just in the cinder side, but I was wrong. We have to call the terminate_connection otherwise the device may show back on the nova host, for example that is true for iSCSI volumes: "if an iSCSI session from the compute host to the storage backend still exists (because other volumes are connected), then the volume you just removed will show back up on the next scsi bus rescan." The key point here is that Nova must call the terminate_connection because just Nova has the "connector info" to call the terminate connection method, so Cinder can't fix it. Solution proposed #2 Then I thought, ok, so let's expose a new nova API called force delete volume which skips all the check and allow to detach a volume in "detaching" status, I thought it was ok but I was wrong (again). The main concern here is that we do not want to have the concept of "force delete", the user already asked for detaching the volume and the call should be idempotent and just work. So adding a new API was just adding a technical debt in the RESP API for a buggy/weak interaction between the Cinder API and Nova, or in other words we are adding a Nova API for fixing a bug in Cinder, which is very odd. Solution proposed #3 Ok, so the solution is to fix the Cinder API and makes the interaction between Nova volume manager and that API robust. This time I was right (YAY) but as you can imagine this fix is not going to be an easy one and after talking with Cinder guys they clearly told me that thatt is going to be a massive change in the Cinder API and it is unlikely to land in the N(utella) or O(melette) release. Solution proposed #4: The trade-off This solution is the solution I am proposing in the patch you mentioned, the idea is to have a temporary solution which allows us to give a handy tool for the operators to easily fix a problem which can occur quite often. The solution should be something with a low impact on the nova code and easy to remove when we will have the proper solution for the root cause. "quick", "useful", "dirty", "tool", "trade-off", "db"we call it nova-manage! The idea is to put a new method in the compute/api.py which skips all the checks on the volume status and go ahead with calling the detach_volume on the compute manager to detach the volume, call the terminate_connection and clean the bdm entry. Nova-manage will have a command to call directly that new method. That is a recap that I hope can help to understand how we decided to use nova-manage instead of other solutions, it was a bit long but I tried to condensate the comments from 53 spec patches + 24 code change patches (and counting). PS: I added the cinder tag as they are
Re: [openstack-dev] [nova] hackathon day
Hi, > -Original Message- > From: Wang, Shane [mailto:shane.w...@intel.com] > Sent: 12 November 2015 16:34 > To: OpenStack Development Mailing List (not for usage questions); Daniel P. > Berrange; Bhargava, Ruchi > Subject: Re: [openstack-dev] [nova] hackathon day > > Hey, how about driving a Hackathon on the same dates in 3 geos right before > release? Who are interested in? We can say that for the next mid-cycle is not feasible, I think the best option at the moment is discuss this proposal at the next summit. I like the idea to have it in different location not sure if having it before the release is a good thing, the core-reviewer efforts are all focused on getting the release ready which means on high priority bugs, not necessarily the bugs which are tackled during the hackathon. Regards -- Andrea Rosa __ OpenStack Development Mailing 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] hackathon day
Hi I knew that people in China had a 3 days hackathon few months ago I was thinking to have a similar thing in Europe. My original idea was to propose to add an extra day after the mid-cycle but I am not sure if that is a good idea anymore: CONS: - the next mid-cycle is going to be the first one outside USA and as for any new things it has some level of uncertainty, we know that we could have a less participant than the other meetups, so it is a risk to add the hackathon at this time - probably it is better to have more than one day for getting the most out of an hackathon event - ppl attending the hackathon are not necessarily the same person attending a mid-cycle event, I think at the hackathon as a very good opportunity for new contributors - it is already late for this proposal, I know I had to propose it at the last summit, my fault PROS: - having the hackathon following the mid-cycle gives us the opportunity to have more core reviewers available, which is a key point for getting right directions and stuff done - cost effective: ppl interested in attending both events can save a travel It'd be good to have a feedback about the Chinese hackathon experience to understand if it's worth to put effort in making a similar event in other part of the world. If it's not the mid-cycle I think there are other events where it could be good to have a couple of extra days for the hackathon, I am thinking for example at Fosdem [1]... well not for 2016 as it is on the week-end after the mid-cycle :) Thanks -- Andrea Rosa [1] https://fosdem.org/ __ OpenStack Development Mailing 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] live migration in Mitaka
Hi all > Not all of these are covered by specs yet and all the existing specs need > reviews. Please look at the etherpad and see if there is anything you think is > missing. What about adding a way to migrate files which are not migrated at the moment, like console.log? I think that could be used to migrate the unrescue.xml file as well and then we could enable the migration for instances in rescue state. If we can't configure libvirt/QEMU to migrate those files, the only idea I have is using RPC mechanism, any other ideas? I'd like to have some opinions before proposing a new spec. Thanks -- Andrea Rosa __ OpenStack Development Mailing 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] live migration in Mitaka
Hi all, > Please respond to this post if you have an interest in this and what you > would like to see done. Include anything you are already getting on with so > we get a clear picture. I have put a new spec about "allow more instance actions during the live migration" [0]. Please note that this is a follow up of a specs proposed for Liberty [1] I put a new patch as I know that the author of the original spec is not going to work on it anymore. Regards -- Andrea Rosa [0] https://review.openstack.org/226199 [1] https://review.openstack.org/179346 __ OpenStack Development Mailing 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][api] Allow passing body for more API methods
Hi all Thank you very much for your feedback, I found the discussion quick and useful. I'll abandon my change and for the bug fixing I'll pass a parameter in the DELETE. Regards -- ar -Original Message- From: Jay Pipes [mailto:jaypi...@gmail.com] Sent: 11 May 2015 19:29 To: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [nova][api] Allow passing body for more API methods On 05/11/2015 11:53 AM, Sean Dague wrote: Why is DELETE /volumes/ID?force=true not an option? Yes, this is what I would recommend as well. Best, -jay __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing 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] Allow passing body for more API methods
Hi all, I noticed that in the nova API we allow to specify body just for the PUT and POST requests [0], for all the other methods, if a body is specified, it gets ignored. I had a look at the RFC 7231 [1] and I noticed that just the TRACE must not have a body, for all the other request a body can be passed and managing or ignoring it depends on the semantic of the request. For that reason my proposal is to allow at WSGI layer to define a body for all the requests but for the TRACE then it is up to the specific controller to ignore or deal with the body in the request. I put a WIP to implement that change [3]. The rationale behind it is double: - Be more in compliance with the RFC - Having more flexibility in our framework. I have a valid (at least for me) use case here [4]: at the moment a volume detach is implemented using a HTTP DELETE, I'd like to add the option for calling from nova, the cinder -force-delete My idea to implement it is to add a parameter in the body of the DELETE call, but at the moment the only valid option is to create a new API using a POST method. What do you think? Regards -- Andrea Rosa [0] https://github.com/openstack/nova/blob/master/nova/api/openstack/wsgi.py#L788 [1] https://tools.ietf.org/html/rfc7231 [3] https://review.openstack.org/181918 [4] https://bugs.launchpad.net/nova/+bug/1449221 __ OpenStack Development Mailing 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][api] Allow passing body for more API methods
Why is DELETE /volumes/ID?force=true not an option? I believe it's valid for DELETE method to take parameters. Just not a body. I am not 100% sure that it would be considered RESTful as it could violates some REST principlebut I think we do not want to open this discussion. So yes it could be a good compromise for the specific issue, my proposal was for a more general case. Agreed. Violating the HTTP spec is something that should be avoided. Actually it is not violating the HTTP spec, from RFC: A payload within a DELETE request message has no defined semantics; sending a payload body on a DELETE request might cause some existing implementations to reject the request. The RFC prohibit the use of a body just for the TRACE: A client MUST NOT send a message body in a TRACE request. Thanks -- Andrea Rosa __ OpenStack Development Mailing 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] OpenStack Havana with ZMQ
Hi Well, we don't know yet. We are planning a mid-size installation (around 600 nodes) and I'm looking for options. From my experience I can tell you that for 600 nodes Rabbitmq is absolutely fine. Regards -- Andrea Rosa ___ 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] Nova XML serialization bug 1223358 moving discussion here to get more people involved
Hi Vish, Thank you very much indeed for your reply! From: Vishvananda Ishaya [mailto:vishvana...@gmail.com] Sent: 12 November 2013 21:56 To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] Nova XML serialization bug 1223358 moving discussion here to get more people involved I personally don't see any problem with converting the Selector to handle empty objects. If we are concerned with hiding other exceptions, then we could explicitly check for == '' instead of catching TypeError. That was another option to fix the problem. I'll let this thread open over the weekend and if no one will object I'll submit a new patch implementing the check for the empty object. Thanks again Regards -- Andrea Rosa ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] Do we have some guidelines for mock, stub, mox when writing unit test?
Hi Generally mock is supposed to be used over mox now for python 3 support. That is my understanding too As for when to use mock vs stubs, I think you'll get different opinions from different people. Stubs are quick and easy and that's what I used early when I started contributing to the project, but since then have preferred mox/mock since they validate that methods are actually called with specific parameters, which can get lost when simply stubbing a method call out. In other words, if I'm stubbing a method and doing assertions within it (which you'll usually see), if that method is never called (maybe the code changed since the test was written), the assertions are lost and the test is essentially broken. So I think in general it's best to use mock now unless you have a good reason not to. AFAIK We all agree that for mocking we move to mock but there is no indication about using mock or stub, and that's good to me. Mocking and stubbing are two different philosophies, I don't think one is better than the other. I found this article [1] really useful. HTH Regards [1] http://martinfowler.com/articles/mocksArentStubs.html -- Andrea Rosa ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Nova XML serialization bug 1223358 moving discussion here to get more people involved
Hi all I realised that I sent this request just the Friday before the HK summit, a really bad timing :( Resending, anyone is available to have a look at this thread? Please note that the code change has a -1 and I am not submitting a new patch as we (the reviewer and myself) are stuck in finding a common solution for the original bug. As soon as we have a consensus I'll be really happy to submit a new patch. Regards -- Andrea Rosa -Original Message- From: Rosa, Andrea (HP Cloud Services) Sent: 01 November 2013 14:35 To: OpenStack Development Mailing List (openstack-dev@lists.openstack.org) Subject: [openstack-dev] Nova XML serialization bug 1223358 moving discussion here to get more people involved Hi all Long story short: a long time ago I raised a bug [1] and I started to work on the fix: GuoHui LIu (the reviewer) and myself had long and useful discussion about the right solution for that but now we are stuck and we need some more opinions to find a proper one. And now the long story: When we have an instance booted from a volume and we don't specify the image details in the boot command the XML serialization of instance details fails and the API call (like nova show) returns a 500 error. The problem is that the image properties is mandatory to serialize but the xml serializer can't manage properly an empty value. In particular in the xmlutil we a have the class Selector which selects datum within a specific object, that class is designed to deal with missing data in the object but not to deal with an empty object. At this moment to deal with missing data the logic used in the method is to catch KeyError or IndexError exceptions: try: obj = obj[elem] except (KeyError, IndexError): if do_raise: raise KeyError(elem) My simple fix was to following the same logic and add a new exception to get caught TypeError which is raised when the passed object is empty (it is an empty string). One of the main complain was that this approach tends to add some business logic in the xmlutil and also adding a new exception could hide some potential errors. I can't disagree but at the same time I say that I am following the same logic that we already have there. We are now stuck, because the long-term solution probably is to rethink the XML serialization process to allow more flexibility but that doesn't seem an easy task and I really want to get this bug fixed. What do you think? Anyone is available to have a look and give us an opinion? Please @Llu feel free to add your comments or any missing points. PS: I am not an expert of the nova xmlutil, could be that I am missing some easy points if so, please let me know. Thanks -- Andrea Rosa [1] https://bugs.launchpad.net/nova/+bug/1223358 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] When is it okay for submitters to say 'I don't want to add tests' ?
-Original Message- From: Chris Friesen [mailto:chris.frie...@windriver.com] Sent: 31 October 2013 17:07 To: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] When is it okay for submitters to say 'I don't want to add tests' ? On 10/31/2013 06:04 AM, Rosa, Andrea (HP Cloud Services) wrote: A - there is no test suite at all, adding one in unreasonable B - this thing cannot be tested in this context (e.g. functional tests are defined in a different tree) C - this particular thing is very hard to test D - testing this won't offer benefit In my opinion C instead of being an acceptable reason for not having tests is a symptom of one of the two things: 1) F = Submitter doesn't know how to write tests, in this case someone else can help with suggestions 2) The code we are trying to test is too complicated so it's time to refactor it And about D, In my opinion tests always offer benefits, like code coverage or helping in understanding the code. I think there are actually cases where C is valid. It's difficult to test certain kinds of race conditions, for example, unless you have very low-level hooks into the guts of the system in order to force the desired conditions to reliably occur at exactly the right time. Well depends which kind of tests we are talking about. I was talking about unit tests and I totally agree with Sandy when he said that everything can be tested and should be. Test certain kinds of race conditions those kind of tests not always are unit tests, I'd consider them functional tests. Regards -- Andrea Rosa ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] Nova XML serialization bug 1223358 moving discussion here to get more people involved
Hi all Long story short: a long time ago I raised a bug [1] and I started to work on the fix: GuoHui LIu (the reviewer) and myself had long and useful discussion about the right solution for that but now we are stuck and we need some more opinions to find a proper one. And now the long story: When we have an instance booted from a volume and we don't specify the image details in the boot command the XML serialization of instance details fails and the API call (like nova show) returns a 500 error. The problem is that the image properties is mandatory to serialize but the xml serializer can't manage properly an empty value. In particular in the xmlutil we a have the class Selector which selects datum within a specific object, that class is designed to deal with missing data in the object but not to deal with an empty object. At this moment to deal with missing data the logic used in the method is to catch KeyError or IndexError exceptions: try: obj = obj[elem] except (KeyError, IndexError): if do_raise: raise KeyError(elem) My simple fix was to following the same logic and add a new exception to get caught TypeError which is raised when the passed object is empty (it is an empty string). One of the main complain was that this approach tends to add some business logic in the xmlutil and also adding a new exception could hide some potential errors. I can't disagree but at the same time I say that I am following the same logic that we already have there. We are now stuck, because the long-term solution probably is to rethink the XML serialization process to allow more flexibility but that doesn't seem an easy task and I really want to get this bug fixed. What do you think? Anyone is available to have a look and give us an opinion? Please @Llu feel free to add your comments or any missing points. PS: I am not an expert of the nova xmlutil, could be that I am missing some easy points if so, please let me know. Thanks -- Andrea Rosa [1] https://bugs.launchpad.net/nova/+bug/1223358 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] When is it okay for submitters to say 'I don't want to add tests' ?
Hi all, This is a bit of a social norms thread I've been consistently asking for tests in reviews for a while now, and I get the occasional push-back. I think this falls into a few broad camps: A - there is no test suite at all, adding one in unreasonable B - this thing cannot be tested in this context (e.g. functional tests are defined in a different tree) C - this particular thing is very hard to test D - testing this won't offer benefit E - other things like this in the project don't have tests F - submitter doesn't know how to write tests G - submitter doesn't have time to write tests Now, of these, I think it's fine not add tests in cases A, B, C in combination with D, and D. In my opinion C instead of being an acceptable reason for not having tests is a symptom of one of the two things: 1) F = Submitter doesn't know how to write tests, in this case someone else can help with suggestions 2) The code we are trying to test is too complicated so it's time to refactor it And about D, In my opinion tests always offer benefits, like code coverage or helping in understanding the code. What do you think? Regards -- Andrea Rosa ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Testing before sending for review
Hi 2. Before submitting the new patch for review it's better to run unit tests (tox -epy27) and pep8 check (tox -epep8) Instead of pep8 I think you should run flake8 we moved to that some months ago[1]. Usually I find always useful to test my changes in devstack. Regards -- Andrea Rosa [1] http://lists.openstack.org/pipermail/openstack-dev/2013-May/009178.html ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Testing before sending for review
Hi On 23.10.2013 11:29, Rosa, Andrea (HP Cloud Services) wrote: Usually I find always useful to test my changes in devstack. How do you do that? I think the devstack does not always contain up to date codebase does it, so what would be the point in testing changes on the old code? With devstack you can decide which code you want to install and run playing with the configuration files: 1 you can define to reclone your devstack installation using the latest trunk code every time you run stack.sh, to do that add RECLONE=yes option [1] 2 you can specify which branch you want to use [2] Hope this helps -- Andrea Rosa [1] http://devstack.org/localrc.html [2] http://devstack.org/stackrc.html ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] run_tests in debug mode fails
Hi Clark, From: Clark Boylan [mailto:clark.boy...@gmail.com] Sent: 11 September 2013 04:44 To: OpenStack Development Mailing List Subject: Re: [openstack-dev] run_tests in debug mode fails I did manage to confirm that the attached patch mostly fixes the problem. with your patch I am able to run `python -m testtools.run nova.tests.integrated.test_servers.ServersTestV3.test_create_and_rebuild_server` Thanks for that and for your time! -- Andrea Rosa ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] run_tests in debug mode fails
Hi all
I need to debug a specific test but when I try to run it in debug mode using
the run_tests -d (I need to attach pdb) that command fails but if I run the
script without the -d option that works.
I created a brand-new env so I don't think it's related to my local env.
Anyone is experiencing the same issue?
Should I file a nova bug for that?
Error details:
./run_tests.sh -d
nova.tests.integrated.test_servers.ServersTestV3.test_create_and_rebuild_server
Traceback (most recent call last):
File nova/tests/integrated/test_servers.py, line 43, in setUp
super(ServersTest, self).setUp()
File nova/tests/integrated/integrated_helpers.py, line 87, in setUp
self.consoleauth = self.start_service('consoleauth')
File nova/test.py, line 279, in start_service
svc = self.useFixture(ServiceFixture(name, host, **kwargs))
File
/home/ubuntu/nova/.venv/local/lib/python2.7/site-packages/testtools/testcase.py,
line 591, in useFixture
fixture.setUp()
File nova/test.py, line 174, in setUp
self.service = service.Service.create(**self.kwargs)
File nova/service.py, line 245, in create
manager = CONF.get(manager_cls, None)
File /home/ubuntu/nova/.venv/lib/python2.7/_abcoll.py, line 342, in get
return self[key]
File
/home/ubuntu/nova/.venv/local/lib/python2.7/site-packages/oslo/config/cfg.py,
line 1610, in __getitem__
return self.__getattr__(key)
File
/home/ubuntu/nova/.venv/local/lib/python2.7/site-packages/oslo/config/cfg.py,
line 1606, in __getattr__
return self._get(name)
File
/home/ubuntu/nova/.venv/local/lib/python2.7/site-packages/oslo/config/cfg.py,
line 1930, in _get
value = self._substitute(self._do_get(name, group, namespace))
File
/home/ubuntu/nova/.venv/local/lib/python2.7/site-packages/oslo/config/cfg.py,
line 1948, in _do_get
info = self._get_opt_info(name, group)
File
/home/ubuntu/nova/.venv/local/lib/python2.7/site-packages/oslo/config/cfg.py,
line 2029, in _get_opt_info
raise NoSuchOptError(opt_name, group)
NoSuchOptError: no such option: consoleauth_manager
Ran 1 test in 11.296s
FAILED (failures=1)
Thanks
--
Andrea
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Openstack] Ceilometer and notifications
HI AFAIK, amqp only uses the exchange as a dispatcher and all storage is done in the queue ... but I could be wrong. I vaguely recall there being a durable exchange setting as well as durable queue. AFAIK if a message can't be routed there are three options: - the message is discarded (I think this is the default option) - the message is sent back to the publisher (some params need to be specified when a message is published) - some broker can have specific queues for those messages, for example Rabbitmq has a dead letter queue where not routable messages are stored. Durable exchanges are exchanges that survive to a server restart, they don't need to be re-declared. HTH -- Andrea Rosa ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Openstack-dev][nova] Disable per-user rate limiting by default
I'd like to turn it off by default, as already pointed in [1] I think the rate limiting should be managed by something else (for example load balancers) in front of the API. Regards -- Andrea Rosa [1] http://www.gossamer-threads.com/lists/openstack/operators/28599 From: Joe Gordon [mailto:joe.gord...@gmail.com] Sent: 24 July 2013 23:39 To: OpenStack Development Mailing List Subject: [openstack-dev] [Openstack-dev][nova] Disable per-user rate limiting by default Hi all I have proposed a patch to disable per-user rate limiting by default: https://review.openstack.org/#/c/34821/. And on Russell's request does anyone care or prefer this to be enabled by default? Here is some more context: Earlier rate limiting discussion: http://www.gossamer-threads.com/lists/openstack/operators/28599 Related bug: https://bugs.launchpad.net/tripleo/+bug/1178529 rate limiting is per process, and doesn't act as expected in a multi-process environment: https://review.openstack.org/#/c/36516/ best, Joe Gordon ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] Question about locking
Hi all, What happens if a greenthread, after acquiring a lock (not external), it dies? For example: A thread is performing the do_terminate_instance, it has the lock and before terminating the process it dies, what happens at the lock? Is that released in some way? If not I think that all other actions for that instance are blocked waiting for the lock, is that correct? Regards -- Andrea ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
