Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2017-01-20
09:24:05 gibi diga: hi! good question
09:24:33 gibi diga: I think we have to judge how usefull a field for the notification consumer
09:24:46 diga gibi: :) okay
09:25:08 gibi diga: I suggest propose what you think is usefull and then in the spec review the placement guys can suggest improvements there
09:25:28 diga gibi: Yep
09:25:34 diga gibi: I will send one WIP spec today, just have a look at it
09:25:42 gibi tdurakov: shall I look into the sample test problem or you will check that?
09:25:49 diga gibi: that will be good approach
09:25:54 gibi diga: good, I will try to check it
09:26:16 tdurakov gibi, I'll check, but I think it worth to do it separately
09:27:16 diga gibi: Thanks :)
09:27:56 gibi tdurakov: OK let's do that separately
09:29:34 tdurakov gibi, could you please +-1 the change with a fix
09:31:00 gibi tdurakov: just did +1 it :)
09:31:06 gibi with the comments we agreed
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: live-migrate updates NUMA and cpus in the XML https://review.openstack.org/286744
10:26:58 openstackgerrit Pawel Koniszewski proposed openstack/nova: libvirt: pass libvirt reference methods to migration https://review.openstack.org/328997
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 hard reboot https://review.openstack.org/376350
12:25:35 openstackgerrit sahid proposed openstack/nova: libvirt: rework _destroy method https://review.openstack.org/416995
12:30:56 snikitin I guess I need to add 'is NaN' checks into my code. Did you face with such strange behavior?
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 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: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.

Earlier   Later