| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-07-21 | |||
| 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 | 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) | |
| 15:54:28 | mriedem | blarg | |
| 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/ | |
| 17:48:57 | mriedem | so when we get that auth error we aren't providing the original response text | |
| 17:49:10 | mriedem | i had that working in the functional tests but leakypipes removed it | |
| 17:49:24 | mriedem | and then i raged | |