| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-01-06 | |||
| 10:44:38 | cdent | yes | |
| 10:44:52 | bauzas | cdent: okay, putting a new PS | |
| 11:04:20 | bauzas | cdent: mmm, trying to find a good pattern for the decorator using something related to the PlacementClient now that we agreed that it's just a member of SchedulerClient and not an inherited | |
| 11:04:49 | bauzas | cdent: the disabled field that the decorator looks at means that we should review it like self.placement_client._disabled but I don't like it | |
| 11:12:43 | cdent | bauzas: that suggests either some functionlity needs to move from scheduler client to placement client or vice versa? | |
| 11:13:04 | bauzas | cdent: I think I have an idea | |
| 11:13:06 | cdent | It seems like only doing the http methods in the placement client is perhaps a bit limited | |
| 11:18:00 | openstackgerrit | sahid proposed openstack/nova: numa: add numa constraints for emulator threads policy https://review.openstack.org/385023 | |
| 11:18:02 | openstackgerrit | sahid proposed openstack/nova: libvirt: return a CPU overhead if isolate emulator threads requested https://review.openstack.org/385364 | |
| 11:18:03 | openstackgerrit | sahid proposed openstack/nova: objects: add new field cpus_reserved in NUMACell https://review.openstack.org/400874 | |
| 11:18:03 | openstackgerrit | sahid proposed openstack/nova: numa: fit instance toplogy with cpus reserved onto cores https://review.openstack.org/400875 | |
| 11:18:04 | openstackgerrit | sahid proposed openstack/nova: virt: update overhead to take into account vCPUs https://review.openstack.org/385024 | |
| 11:18:06 | openstackgerrit | sahid proposed openstack/nova: libvirt: make emulator threads to run on the reserved pCPU https://review.openstack.org/400878 | |
| 11:18:07 | openstackgerrit | sahid proposed openstack/nova: numa: take into account cpus reserved https://review.openstack.org/400876 | |
| 11:18:07 | openstackgerrit | sahid proposed openstack/nova: numa: update numa usage incording the cpu reserved https://review.openstack.org/400877 | |
| 11:33:24 | mdbooth | I have a python3 problem: I have some code which maps over a list of tuples. In python2 I do: | |
| 11:33:41 | mdbooth | map(lambda (x, y): x, mylist) | |
| 11:33:58 | mdbooth | i.e. the output is a new list containing only the first element of each tuple | |
| 11:34:04 | mdbooth | In python3 this is a syntax error | |
| 11:35:10 | mdbooth | I've mashed the keyboard a bit, but I can't find a solution, and I haven't yet worked out what to google | |
| 11:42:13 | cdent | mdbooth: will a list comp work for you: [a for a, b in x] | |
| 11:42:26 | mdbooth | Yeah, list comp is the way to go, thanks cdent | |
| 11:43:20 | mdbooth | The original original code actually constructed an iterator, not a list | |
| 11:43:20 | cdent | you can do a generator comprehension instead if you want | |
| 11:46:08 | bauzas | yeah that's the problem I'd see with a list comprehension | |
| 11:51:22 | bauzas | mdbooth: so, map in py2 returns a list | |
| 11:51:24 | bauzas | https://docs.python.org/2/library/functions.html#map | |
| 11:51:37 | mdbooth | bauzas: original original code was itertools.imap | |
| 11:51:40 | bauzas | mdbooth: while in py3, it's an iterable https://docs.python.org/3/library/functions.html#map | |
| 11:51:51 | bauzas | like most of the changes for the list stuff | |
| 11:51:56 | openstackgerrit | sahid proposed openstack/nova: libvirt: update the active migrations DS to support migration result https://review.openstack.org/409260 | |
| 11:51:56 | openstackgerrit | sahid proposed openstack/nova: libvirt: ensure live-migration success https://review.openstack.org/409261 | |
| 11:52:06 | mdbooth | which I'd already simplified to share | |
| 11:52:13 | bauzas | mdbooth: oh okaty | |
| 11:52:15 | mdbooth | As it's also not in py3 | |
| 11:52:36 | bauzas | because it's in stdlib :) | |
| 11:52:55 | mdbooth | Also, because we hate users | |
| 11:54:12 | bauzas | mdbooth: six has a 'map' rename | |
| 11:55:07 | mdbooth | bauzas: Yeah, had already found that. Concentrating on the renaming and syntax is probably why I didn't think of using a comprehension instead :) | |
| 11:58:46 | bauzas | mdbooth: an alternative could be using zip | |
| 11:58:50 | bauzas | lemme test | |
| 11:59:39 | mdbooth | bauzas: comprehension is the right solution. It's actually much neater that what I'd originally written. | |
| 12:00:41 | bauzas | mdbooth: but you're no longer creating an iterator, right?N | |
| 12:00:55 | mdbooth | There's also a generator comprehension | |
| 12:01:26 | mdbooth | (x for (x, y) in foo) | |
| 12:01:57 | bauzas | agreed | |
| 12:03:33 | bauzas | cdent: given the effort it requires to properly seam all the client stuff within a proper module (given how we intrisected the use in the report client), do you agree with me leaving some kind of ugly but necessary inheritance aspect for a PlacementClient? | |
| 12:03:58 | bauzas | cdent: ideally, we would have different objects per resource | |
| 12:04:09 | bauzas | like we do for most of our clientcode | |
| 12:04:57 | cdent | bauzas: I think if the base class is just put(), post(), etc, then I'm not sure I would bother? | |
| 12:05:19 | cdent | But if it makes sense, then sure, if it makes things more clear or clean. | |
| 12:05:40 | bauzas | cdent: the problem is I'm beginning to include all the resource-related methods for inventories and allocations | |
| 12:05:48 | cdent | I think we intentionally chose _not_ to use different objects per resource in the client as that was felt to be overkill given the types of interactions being done | |
| 12:05:54 | bauzas | cdent: and that's an hard work to do so | |
| 12:15:05 | mdbooth | Is anybody working on the gate snafu, btw? | |
| 12:16:09 | mdbooth | nova.tests.unit.test_cinder.CinderV1TestCase.test_cinderclient_unsupported_v1 | |
| 12:17:07 | mdbooth | cdent: You currently have a zuul job failing in ^^^ btw | |
| 12:17:52 | cdent | mdbooth: that was talked about last night | |
| 12:18:11 | cdent | https://bugs.launchpad.net/nova/+bug/1654393 | |
| 12:18:11 | openstack | Launchpad bug 1654393 in OpenStack Compute (nova) ""keystoneauth1.exceptions.catalog.EmptyCatalog: The service catalog is empty." in test_cinderclient_unsupported_v1" [High,In progress] - Assigned to Matt Riedemann (mriedem) | |
| 12:18:22 | cdent | matt's got a fix pending | |
| 12:18:37 | mdbooth | cdent: Impact is nothing can land, right? | |
| 12:18:54 | cdent | I was under the impression it was racy | |
| 12:19:27 | johnthetubaguy | sfinucan: I wasn't sure about this one: https://review.openstack.org/#/c/413658/2 does my comment make sense? | |
| 12:21:30 | sfinucan | johnthetubaguy: Yup, `null` would be the JSON variant | |
| 12:23:58 | sfinucan | johnthetubaguy: In turn, any idea if the comments on this patch correct? I've no idea, I'm afraid :/ https://review.openstack.org/#/c/416959/1/nova/conf/quota.py | |
| 12:25:04 | johnthetubaguy | sfinucan: oh, that is correct I think | |
| 12:25:16 | johnthetubaguy | sfinucan: all the network ones, there is a bit in the code that would confirm that, one sec | |
| 12:26:04 | sdague_ | I'm back now, what's up? | |
| 12:26:17 | sfinucan | johnthetubaguy: Yeah, I've found in rather touch to delineate between nova-net and neutron in 'nova/network' where most of these variables are used | |
| 12:27:25 | sfinucan | sdague: Any idea about the the validity of comments on https://review.openstack.org/#/c/416959/1/nova/conf/quota.py ? | |
| 12:29:34 | sdague | sfinucan: I'm pretty sure Takashi is right, those also only have an effect when nova-network is in play | |
| 12:31:56 | sfinucan | sdague: johnthetubaguy: Cool cool. I'll respin that to drop those so | |
| 13:14:25 | jaypipes | good morning Novas. | |
| 13:36:15 | openstackgerrit | Stephen Finucane proposed openstack/nova: libvirt: Make 'get_domain' private https://review.openstack.org/417378 | |
| 13:54:43 | openstackgerrit | Ed Leafe proposed openstack/nova: Remove the Allocation.create() method. https://review.openstack.org/416751 | |
| 13:54:44 | openstackgerrit | Ed Leafe proposed openstack/nova: Add check for invalid allocation amounts https://review.openstack.org/416752 | |
| 13:55:43 | openstackgerrit | Stephen Finucane proposed openstack/nova: rbd: Remove unnecessary 'encode' calls https://review.openstack.org/412356 | |
| 13:59:40 | openstackgerrit | Stephen Finucane proposed openstack/nova: conf: Deprecate yet more nova-net options https://review.openstack.org/416959 | |
| 14:10:33 | openstackgerrit | melissaml proposed openstack/nova: Fix a typo in documents https://review.openstack.org/417389 | |
| 14:14:25 | cdent | mdbooth: maybe you have some thoughts on this: Do you know to what extent eventlet gets involved when running the unit tests? | |
| 14:15:12 | mdbooth | cdent: I think sdague would be a better authority on this stuff, but to the best of my knowledge: not really. | |
| 14:15:33 | mdbooth | I understand that tox fires up several workers in independent processes, which then run tests serially. | |
| 14:15:49 | cdent | (I was asking in relation to your comment on matt's fix for the gate failure) | |
| 14:15:55 | mdbooth | So 'races' shouldn't really occur. | |
| 14:16:16 | mdbooth | However, you can get ordering artifacts if tests don't clean up after themselves properly. | |
| 14:16:19 | cdent | yeah, that was my thinking too, but if eventlet does getinvolved, then game over | |
| 14:16:31 | cdent | s/over/confused/ | |
| 14:16:42 | mdbooth | However, I'd defer entirely to sdague :) | |
| 14:16:56 | sdague | cdent: what is the eventlet concern when tests are run? | |
| 14:17:10 | cdent | So I've been assuming it doesn't (as that would be bad as it introduces ambiguity). | |
| 14:17:43 | mdbooth | Incidentally, I'm just starting to look at this myself. | |
| 14:17:44 | cdent | sdague: If eventlet is present and monkey patching file io in some sense, you might get an unexpected yield to an unexpected greenthread? | |
| 14:18:11 | cdent | I don't really know, I'm experiening curiosity. Expressing it to see if anyone else knows what's up. | |
| 14:18:20 | sdague | cdent: eventlet is definitely present | |
| 14:20:06 | sdague | but, there are going to need to be spawns to have greenlets running, right? We use that to our advantage on the functional tests with the single process cloud | |
| 14:21:29 | cdent | That's effectively my question: If your first statement/question is true, not an issue. | |
| 14:22:20 | sdague | the parallel running of tests is via testr spawning dedicated processes with subsets of the tests, and running subunit serially in each | |
| 14:23:03 | cdent | yeah, that part I understand (and know too well, dealing with trying to get gabbi to behave properly in that scenario (it does)) | |
| 14:23:07 | sdague | so... as long as tests clean up after themselves, there shouldn't be interference between tests. But cleaning up after themselves is sometimes not super clear, especially if globals are set | |