Earlier  
Posted Nick Remark
#openstack-nova - 2017-07-21
15:50:53 ildikov mriedem: do we want less code lines or complete separation?
15:50:55 mriedem or shouldn't need to
15:51:02 mriedem i want separation
15:51:12 ildikov I have 15 tests failing...
15:51:22 mriedem mucking with the old tests (1) loses coverage on the old flow and (2) makes it much harder to review IMO
15:51:28 ildikov ok, I prefer that too, so at least we are on the same page
15:51:41 mriedem fwiw that's what i did in the swap volume new style attachments change
15:52:17 ildikov honestly I wanted to see tests working and deal with finalizing them when we are kinda fine with the code
15:52:22 ildikov maybe wasn't the best idea
15:52:37 ildikov still helped understanding a few things though, so oh well
15:52:47 ildikov next time I will do it differently... :)
15:53:36 ildikov mriedem: I think we're good with the direction, I will ping you if I get this up at a reasonable time today so at least you know it's there
15:54:26 mriedem https://bugs.launchpad.net/nova/+bug/1704293
15:54:28 mriedem blarg
15:54:28 openstack Launchpad bug 1704293 in OpenStack Compute (nova) "We can not set volume's type when creating a vm from image by creating a volume" [Undecided,Won't fix] - Assigned to liuxiuli (liu-lixiu)
16:00:50 jangutter mriedem: would something like this (create non-standard volume/port/etc and attach it to the created server) ever be covered by the osc CLI?
16:01:47 openstackgerrit Jay Pipes proposed openstack/nova master: claim resources in placement API during schedule() https://review.openstack.org/483566
16:01:48 openstackgerrit Jay Pipes proposed openstack/nova master: placement: add retry tight loop claim_resources() https://review.openstack.org/486170
16:01:49 mriedem jangutter: that's the way you do it today
16:01:51 leakypipes mriedem: ^
16:01:55 mriedem which was my response in the bug report
16:02:17 leakypipes mriedem: I ended up hiding the tight retry loop in the scheduler report client's claim_resources() method.
16:02:27 leakypipes mriedem: so no changes needed to the scheduler patch.
16:02:31 mriedem leakypipes: sneaky sis
16:02:40 leakypipes mriedem_afk: :)
16:02:49 jangutter mriedem: argh, sorry, my verbage unclear... I meant, doing that in "one go"
16:03:08 jangutter mriedem: I think that's not just a can of worms, but a can of worm factory.
16:03:33 melwitt leakypipes: question for you, if this sort is to get non-shared resources first, does that mean "sharing_providers" has non-shared resources in it? https://review.openstack.org/#/c/485088/6/nova/objects/resource_provider.py@1060
16:04:47 melwitt just confused about what's going on there. and how does sorting them make non-shared be first?
16:06:45 melwitt cdent ^
16:07:36 cdent melwitt: the name of the variable might be misleading
16:09:30 cdent melwitt: just a sec I’ll refresh my memory
16:10:38 cdent melwitt: the value in the dictionary is the id of a provider of that resource class that makes it available via sharing
16:10:43 melwitt it looks like sharing_providers is a dict where the key is resource class ID and each value is a list of resource provider IDs?
16:11:00 cdent of it items() is sorted by the value, then anything provider which is not one that shares comes first
16:12:03 melwitt non sharing providers always have lower IDs?
16:14:08 cdent no, the value will be None if it a non sharing provider
16:14:31 melwitt okay, so the Nones get sorted ahead of the lists of IDs
16:15:37 cdent yeah
16:15:45 cdent and it’s not none, sorry it’s an empty list
16:15:54 cdent it’s hard to track :(
16:16:19 melwitt okay, thanks. now this makes a lot more sense
16:29:43 cdent leakypipes: can you clarify your comment on https://review.openstack.org/#/c/485209/2/nova/tests/functional/api/openstack/placement/gabbits/shared-resources.yaml . Are you saying it should be 1 provider or something else? It currently returns 0, which doesn’t align with what you seem to be saying
16:31:31 leakypipes cdent: it's currently returning 1, which is correct.
16:31:40 leakypipes cdent: $.resource_providers.`len`: 1
16:32:29 cdent it is not returning 1, that’s why the xfail: true is there
16:33:03 cdent eXpected fail
16:35:13 leakypipes cdent: oh, sorry
16:36:11 leakypipes cdent: didn't catch the xfail thing
16:36:21 leakypipes cdent: I can investigate that then.
16:36:51 cdent i’ve got a better version of the test, will push it up without the xfail
16:37:39 cdent leakypipes: I can do it if you like, now that I know what the correct thing is I should be able to some reasonable poking
16:37:53 leakypipes cdent: sure, please do if you'd like
16:38:00 cdent ✔
16:38:35 cdent am I slow or is gerrit slow?
16:39:01 figleaf cdent: both are possible
16:39:56 figleaf leakypipes: making progress on the alternates, and then lost connectivity to my dev env. Will continue after lunch
16:40:07 leakypipes figleaf: sounds good, thanks Ed
16:47:59 melwitt I wonder what the func test job fail rate is, it seems like it's got to be near 50%
16:51:50 leakypipes melwitt: yes, likely. I'm hoping the bug fix for that join order will help some.
16:53:14 melwitt yeah, true. most of the fails I see are "authentication error" and versioned notifications stuff
16:56:09 cdent melwitt: I think that auth error is part of the compute and placement fixtures not working well together all the time
16:57:04 melwitt cdent: yeah, I've heard that. recently mriedem_afk tried adding the keepalive=False globally but it didn't seem to have helped
16:57:05 cdent leakypipes: as far as I can tell the functionality for shared providers on /resource_providers was never implemented, only talked about: it’s talked about in the commit message of this: https://review.openstack.org/#/c/460798/ but I can’t find where it happened
16:57:14 openstackgerrit Stephen Finucane proposed openstack/nova master: console: provide an RFB security proxy implementation https://review.openstack.org/345399
16:57:29 leakypipes cdent: heh, yes, that's correct. :)
16:57:51 leakypipes cdent: I'd forgotten about that
16:58:57 cdent so I reckon we’ve got at least two options: a) implement it b) decide that actually we never wanted that on resource providers anyway, that shared thing is sort of magical any way for “listing” resource providers, so doesn’t belong there
16:59:48 cdent leakypipes: I think I actually prefer option b for that url. you?
17:01:40 leakypipes cdent: not sure I follow you... GET /resource_providers is intended to return a list of the resource providers that can accomodate the requested resources, and in this case, if one of the requested resources is a shared resource, we naturally need to account for sharing providers (we just don't need to return information that indicates a sharing provider would be used)
17:04:21 cdent What I’m saying is that maybe (now that we have /allocation_candidates) listing /resource_providers should just do that: list resource providers that match queries, where resources is just another type of query. the concept of a shared resource isn’t necessarily a concept that is “natural” when request a listing of resource provider for no specific purpose
17:04:42 cdent (i’m not sold on this, just throwing it out there for thinking)
17:06:42 leakypipes cdent: I'm not actually sure what you're advocating :)
17:07:04 cdent i’m advocating leaving /resource_providers as it is right now
17:08:12 cdent leakypipes: or rather not advocating, wondering if it makes sense to do so
17:08:33 leakypipes cdent: I see. I don't suppose it would hurt to leave it as-is for a little while as we decide on that question.
17:11:04 cdent figleaf: you have any thoughts on the last few lines?
17:27:13 cdent have fun stephenfin
17:35:11 mriedem maybe we should put a dumb retry in the functional osapi client fixture if we get a 401 or 403 response for now?
17:35:20 mriedem as a hack until we're to RC1?
17:38:18 melwitt yeah, I forgot about that idea
17:41:27 melwitt I don't understand what the right way to fix this would be
17:42:14 mriedem rm -rf nova/tests/functional
17:42:25 melwitt hah
17:42:38 cdent is the auth error the main offender at this point?
17:42:54 mriedem it's what i've been noticing after the global keepalive=False change
17:43:14 cdent common url, or multiple urls?
17:43:15 mriedem which is odd since we use the noauth middleware i thought in all of the osapi fixture tests
17:43:27 melwitt yeah. I don't get it
17:43:35 mriedem i'll find the last one i just rechecked
17:44:03 mriedem http://logs.openstack.org/11/485011/4/gate/gate-nova-tox-functional-py35-ubuntu-xenial/42d69de/console.html#_2017-07-21_14_55_31_532907
17:45:25 mriedem i've been seeing these in the functional jobs too
17:45:26 mriedem sys:1: ResourceWarning: unclosed file <_io.FileIO name=1 mode='wb' closefd=True>
17:46:41 cdent mriedem: is that on both py27 and py35 or or just py35?
17:47:15 mriedem only seeing it on py3
17:47:29 mriedem py3 jobs are also way chattier about warnings
17:48:16 melwitt gdi looks like logstash.o.o is busted again
17:48:26 melwitt I wanted to check which jobs have "OpenStackApiAuthenticationException: Authentication error"
17:48:30 cdent I get unclosed file errors all over the place in lots of other things besides nova in py35
17:48:35 cdent s/errors/warnings/

Earlier   Later