Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2017-01-06
10:38:51 bauzas cdent: but we're already accepting it, right?
10:39:59 cdent we're accepting it by accident and when we do it will result in an error, and the intention is to merge the api code that handles it asap: https://review.openstack.org/#/c/407742/
10:42:11 bauzas cdent: okay, so I'll remove it from the schema then
10:42:36 cdent stuff near hear in the logs: http://p.anticdent.org/48rX
10:43:37 cdent sigh: here
10:43:46 bauzas cdent: okay, what I understand is that we contracted on member_of but without having the right API
10:43:55 bauzas cdent: so, stopping to accept it is good to me
10:44:32 bauzas cdent: when you'll add the API version for it, it'll be clear that now we explicitly accept member_of by the schema you'll add
10:44:33 cdent I think what we're doing is simply fixing a bug
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: numa: fit instance toplogy with cpus reserved onto cores https://review.openstack.org/400875
11:18:03 openstackgerrit sahid proposed openstack/nova: objects: add new field cpus_reserved in NUMACell https://review.openstack.org/400874
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: update numa usage incording the cpu reserved https://review.openstack.org/400877
11:18:07 openstackgerrit sahid proposed openstack/nova: numa: take into account cpus reserved https://review.openstack.org/400876
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 cdent you can do a generator comprehension instead if you want
11:43:20 mdbooth The original original code actually constructed an iterator, not a list
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: ensure live-migration success https://review.openstack.org/409261
11:51:56 openstackgerrit sahid proposed openstack/nova: libvirt: update the active migrations DS to support migration result https://review.openstack.org/409260
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 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:11 cdent https://bugs.launchpad.net/nova/+bug/1654393
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).

Earlier   Later