Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2017-01-20
09:31:18 tdurakov gibi, thank you!
09:31:40 gibi tdurakov: thank you for fixing the bug! :)
09:53:09 gibi tdurakov: just checked the #2) comment and I can confirm that instance.<action> notifications are not affected
09:54:18 tdurakov ok, cool, thank you
10:01:37 openstackgerrit OpenStack Proposal Bot proposed openstack/nova: Updated from global requirements https://review.openstack.org/422323
10:06:35 openstackgerrit Sergey Nikitin proposed openstack/nova: do not merge https://review.openstack.org/422841
10:06:40 openstackgerrit Takashi NATSUME proposed openstack/nova: Avoid forcing translation on logging calls https://review.openstack.org/413876
10:10:10 openstackgerrit Duong Ha-Quang proposed openstack/nova: Stop using mox stubs in nova/tests/unit/cells/fakes.py https://review.openstack.org/342043
10:11:14 openstackgerrit Duong Ha-Quang proposed openstack/nova: Stop using mox stubs in nova/tests/unit/cells/fakes.py https://review.openstack.org/342043
10:20:14 openstackgerrit Andrey Volkov proposed openstack/nova: PoC: add hierarchy quota driver https://review.openstack.org/391072
10:26:56 openstackgerrit Pawel Koniszewski proposed openstack/nova: live-mig: Add claims and proper resource tracking https://review.openstack.org/244489
10:26:58 openstackgerrit Pawel Koniszewski proposed openstack/nova: libvirt: pass libvirt reference methods to migration https://review.openstack.org/328997
10:26:58 openstackgerrit Pawel Koniszewski proposed openstack/nova: libvirt: live-migrate updates NUMA and cpus in the XML https://review.openstack.org/286744
10:49:40 bauzas alex_xu: around ?
10:50:11 bauzas alex_xu: I was working on the scheduler change when I saw that we haven't yet a fixture for calling the placement api
10:50:38 bauzas so some of the functional tests are failing because we return NoValidHosts
10:51:32 bauzas alex_xu: I was thinking of very quickly writing a fixture, but given we don't run the WSGI app for placement the same than OSAPI, then I'm a bit sad
10:52:09 bauzas alex_xu: do you know if there is some way to hack that by having a WSGI server fixture able to deploy a WSGI app ?
10:52:52 bauzas and sean is off, I can't ask advice from him
10:53:08 sahid jaypipes: hello, i lost your +2 on https://review.openstack.org/#/c/400874/ because of a conflict if I can get it again that would be nice since next week (if i remember correclty) you will be out
10:54:54 openstackgerrit Wang Qing wu proposed openstack/nova: WIP(4): Introduce base PowerVM driver (cfg drv) https://review.openstack.org/409404
11:02:15 lyarwood Morning all, if anyone has time I'd appreciate some additional reviews on the following findmnt bugfix - https://review.openstack.org/#/c/420146/
11:42:49 bauzas sdague: I think I come up with a potential problem for us wanting to get the placement upcall from the scheduler
11:43:14 bauzas sdague: we haven't yet a fixture for running the placement API in our functional tests
11:43:26 bauzas sdague: thoughts on the best approach ?
11:43:40 bauzas sdague: I began to look at to embed the WSGI app into a fixture
11:43:53 bauzas to look at how*
11:44:14 bauzas since we can't reuse the OSAPIFixture, as it's a totally different structure AFAICS
11:46:50 bauzas sdague: maybe using paste.fixture ?
11:57:50 sdague bauzas: are, right, no oslo.service
11:58:06 sdague so... my suggestion, spawn a thread and run the app inside https://docs.python.org/2/library/wsgiref.html#module-wsgiref.simple_server
11:58:35 bauzas not sure I understood your first point ?
11:58:47 bauzas "no oslo service "
11:59:00 bauzas you mean that indeed the placement service is not oslo's
11:59:02 sdague placement doesn't launch through oslo.service
11:59:06 bauzas yeah
11:59:23 sdague oslo.service gave us the ability to just run in a greenlet
11:59:28 bauzas okay, so you'd recommend wsgiref instead of paste.fixture ?
11:59:44 sdague well, paste doesn't actually listen
12:00:08 bauzas okay, disclaimer, I'm not a super expert on that
12:00:16 bauzas so okay, using wsgiref
12:00:25 bauzas given the short time we have, I'm rushing
12:00:45 bauzas sdague: I'll just use a thread in the fixture and do like the above you mentioned ^
12:00:52 bauzas sdague: thanks for the very quick answer
12:01:15 sdague bauzas: it's not the only thing you are going to need to do though, you potentially need to simulate the keystone catalog as well
12:01:26 sdague because the placement api is only looked up by catalog
12:01:27 bauzas sdague: I was thinking to noauth
12:01:45 bauzas and mock the keystone calls
12:01:54 sdague bauzas: yeh, that's possible
12:02:14 sdague it would be better long term to avoid mock there, but given the timing that should get you there fast
12:02:16 bauzas dunno, the quickiest one given the short time
12:02:21 bauzas yeah
12:02:25 sdague I think this biggest trick of wsgiref is going to be picking ports
12:02:40 sdague eventlet can bind an unused port and give it back to you
12:02:52 sdague which is what we use
12:02:58 bauzas but I have to be explicit for wsgiref? gotcha
12:03:01 sdague yeh
12:03:17 bauzas let's try to do something at least
12:04:17 bauzas sdague: from a upper standpoint, our functional tests were working because we still update the DB
12:04:40 bauzas sdague: which is unfortunate, I thought we were already mocking that placement upcall from the compute
12:04:52 bauzas that's why we're at risk now
12:05:00 bauzas I haven't identified it would require a new fixture
12:05:37 sdague bauzas: actually, have you tried just launching the placement app in nova.wsgi.Server?
12:05:48 bauzas sdague: I was tempted to
12:06:09 sdague because, yes, that uses eventlet to do it
12:06:22 sdague but ... it's not really that eventlet specific
12:06:27 sdague as I'm looking through the code
12:07:20 sdague I think the only tricky part is the paste load is a little different
12:07:31 sdague but, you might just be able to do that
12:07:40 bauzas lemme write that
12:07:44 bauzas my fixture is there
12:07:48 bauzas I just need to update it
12:08:07 bauzas and my change is a canary patch so I can see
12:19:32 bauzas sdague: that looks working
12:19:36 bauzas using wsgi.Server()
12:19:53 bauzas I now need to fake the keystone calls
12:19:59 bauzas and verify a few tings
12:25:34 openstackgerrit sahid proposed openstack/nova: libvirt: make coherent logs when reboot success https://review.openstack.org/416994
12:25:35 openstackgerrit sahid proposed openstack/nova: libvirt: rework _destroy method https://review.openstack.org/416995
12:25:35 openstackgerrit sahid proposed openstack/nova: libvirt: rework hard reboot https://review.openstack.org/376350
12:30:56 snikitin BobBall: Hi, Bob! JFYI: I found the reason of diagnostics tempest tests fail. Sometimes (I don't know why) xen returns "NaN" instead of numbers. For example I saw such response in Xen CI job: {"last_update": "1484900660", "cpu0": "NaN", "memory": "NaN"}.
12:30:56 snikitin My code can't convert float('NaN') into int and this is the reason of the fails. On my local Xen env everything is ok. I saw 'NaN' values only one time and I don't know how to reproduce it. But on CI I saw normal values only one time. All other times I see 'NaN'.
12:30:56 snikitin I guess I need to add 'is NaN' checks into my code. Did you face with such strange behavior?
12:32:01 BobBall I suspect this will be because we're getting the stats from the RRDs which are updated every 5 seconds. Perhaps a pause in the tempest test for 10 seconds(?) to ensure some stats are populated would fix it?
12:35:52 snikitin BobBall: Thank you for advice! I will check it. P.S. Even if some stats aren't populated I expect to see something like 'None' or 'null' rather than 'NaN'. strange behavior.
12:38:37 BobBall snikitin: The RRDs are typically based on min, max or averages over a period (as an instant reading doesn't make much sense for things like CPU usage). My guess is that they are providing a number based on the average over X-X seconds - which will be a number divided by 0 as we don't have sufficient time periods. I get what you're saying, but if a 10 second delay fixes the issue I would understand why it is returning "Not a Number"
12:41:54 bauzas sdague: quick question, we deduce the endpoint from the token unless we use the endpoint_override here https://github.com/openstack/keystoneauth/blob/master/keystoneauth1/session.py#L509-L513
12:42:18 bauzas sdague: am I correct if I say that if I'm providing endpoint_override, I'd not lookup the SC ?
12:42:28 bauzas and directly call the placement service
12:42:58 sdague bauzas: looks like... however
12:43:05 sdague if you are really using noauth
12:44:16 sdague then probably you are actually going to want to build a fake client entirely, I think mocking out keystoneauth at all the right points is going to be harder
12:44:57 sean-k-mooney dims: jaypipes looking at https://review.openstack.org/#/c/422838 do we still need to merge this and make a release to fix the python 3.5 support today?
12:45:04 bauzas I don't want to mock out all the keystoneclient
12:45:18 bauzas sdague: just recreating a new Session with an endpoint_override
12:45:33 snikitin BobBall: Ok. I will check it, but I think you right. Anyway I think we should check 'NaN' values in nova, because user can get a 500 error because of it.
12:45:47 sdague bauzas: ok
12:45:57 bauzas anyway, let's try
12:46:21 bauzas just taking a few mins for refueling myself at $lunch, and then back quickly
12:46:26 BobBall snikitin: Sure - the xenapi drive could easily translate NaN to None if it makes more sense up the stack

Earlier   Later