| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-08-14 | |||
| 13:04:59 | cdent | efried: also, did you see my response to you on the -dev list ? make sense or did I miss the boat? | |
| 13:05:11 | efried | cdent I did, and it does... somewhat. | |
| 13:05:49 | cdent | only somewhat? | |
| 13:05:56 | efried | cdent I gather a lot of folks set up their endpoints at http://example.com:1234/ instead of http://example.com/service | |
| 13:06:12 | efried | Though I understand the former is now discouraged. | |
| 13:06:14 | cdent | yes | |
| 13:06:27 | efried | So in the former case, the `self` links will come back *without* the prefix? | |
| 13:06:52 | cdent | yes, the presence of the prefix is unrelated to the service catalog entry, it is based entirely on the web server config | |
| 13:07:26 | efried | cdent Well, I hadn't assumed it had to do with the service catalog; but was hoping it wasn't hardcoded somewhere :) | |
| 13:07:31 | gibi | cdent: for the first, I noticed that this morning | |
| 13:07:39 | gibi | cdent: test_evacuate is unstable | |
| 13:08:04 | cdent | efried: it’s not hardcoded in placement itself. The prefix comes from the environ[‘SCRIPT_NAME’] | |
| 13:08:15 | gibi | cdent: I will pushed a fix for that in the evacuate bugfix but then I will remove that and leave comment on https://review.openstack.org/#/c/493448/ instead | |
| 13:08:26 | cdent | gibi: I tested it out myself quite a bit and from what I could tell it was a matter of the loop timing out too soon | |
| 13:08:49 | cdent | with a longer loop it worked | |
| 13:10:01 | gibi | cdent: it happens because instance already in ACTIVE state when the the loop starts | |
| 13:10:10 | gibi | cdent: at least in my trial | |
| 13:10:13 | efried | cdent Okay, so (and perhaps this is in the devref (is that up yet?), but) how is a consumer supposed to use the links? Seems like nontrivial url dicing would be required. | |
| 13:10:15 | gibi | cdent: but anyhow | |
| 13:10:26 | gibi | cdent: my suggestion is to wait for both the status and the host | |
| 13:10:35 | gibi | cdent: and we already have a function for that | |
| 13:11:11 | cdent | huh, I’ll take your word for it gibi, I could consistently get it to fail with short timeout, and not with long, but maybe that was just (bad-) luck | |
| 13:11:18 | gibi | cdent: https://github.com/openstack/nova/blob/master/nova/tests/functional/integrated_helpers.py#L221 | |
| 13:11:32 | gibi | cdent: I suggest to use this ^^ | |
| 13:11:47 | gibi | cdent: this way we wait for both the ACTIVE status and the new host name to appeare on th REST API | |
| 13:13:38 | cdent | efried: a) if the consumer is using ksa then it is ksa which is making the decision to not treat an absolute link as an absolute link, b) I don’t reckon anybody uses the links anyway, certainly not in any code that I’ve seen. The code I’ve seen behaves as if it is all “well known urls”, which is probably best practice when using a url-manipulating client like ksa | |
| 13:14:11 | efried | cdent Hmph. Then what's the point in having 'em in there in the first place? | |
| 13:14:12 | efried | But okay. | |
| 13:14:23 | gibi | cdent: I left a comment in https://review.openstack.org/#/c/493448 | |
| 13:15:23 | cdent | efried: it (things like ksa) does bugger the concept of HATEOAS. The reason for having the links is if you are using a client that doesn’t do a requests style mount | |
| 13:15:41 | cdent | of which there could easily be | |
| 13:15:50 | cdent | the server needs to be client agnostic | |
| 13:16:08 | efried | Okay, fair enough. Thanks for the explanation. | |
| 13:16:43 | cdent | efried: I’m totally with you that it is weird | |
| 13:17:34 | cdent | gibi, makes sense | |
| 13:18:04 | cdent | these non-atomic updates are bewildering | |
| 13:18:13 | cdent | but not surprising, just hard to track | |
| 13:20:10 | gibi | cdent: an extra complication that the propose change in the _wait_for_state_change function is no the one that is called by the actual failing test | |
| 13:20:31 | cdent | oops | |
| 13:20:34 | cdent | :) | |
| 13:20:59 | gibi | now I start reading the your report client patch :) | |
| 13:21:14 | cdent | it should be a little more straightforward...maybe | |
| 13:39:12 | gibi | cdent: your report client patch looks good to me but I have limited knowledge about ksa | |
| 13:39:54 | jangutter | Hi, we're testing a third-party CI to test OpenStack on Netronome hardware (specifically with regard to https://review.openstack.org/#/c/491502/ ). Would anyone be willing to give feedback? | |
| 13:40:44 | cdent | jangutter: just a heads up this week a significan number of nova cores are away on holiday, so the amount of feedback may be limited | |
| 13:41:24 | jangutter | cdent: I saw, this isn't on our critical path, I'll re-post next week or so. | |
| 13:42:23 | jangutter | cdent: more or less looking for "run, you fools!" kind of feedback now. | |
| 13:42:36 | cdent | that’s my default state | |
| 13:42:40 | cdent | so I’ll look!\ | |
| 13:50:24 | edleafe- | Scheduler subteam meeting in 10 minutes in #openstack-meeting-alt | |
| 13:51:07 | openstackgerrit | Merged openstack/nova master: Handle addition of new nodes/instances in ironic flavor migration https://review.openstack.org/487954 | |
| 13:53:24 | dtantsur | morning edleafe, should we backport ^^^ to pike? | |
| 13:55:41 | edleafe | dtantsur: I'm not sure what backporting to RC1 would get us. It will be in RC2, so it will be in "official" Pike | |
| 13:56:22 | smcginnis | It will need to be "backported" to stable/pike to be part of RC2, right? | |
| 13:57:17 | edleafe | smcginnis: OIC what you mean. I misunderstood. Yes, it will need to be part of RC2 | |
| 13:57:26 | smcginnis | ;) | |
| 13:58:47 | dtantsur | edleafe: could you please propose such backport then? | |
| 13:58:59 | edleafe | dtantsur: sure, after the scheduler meeting | |
| 13:59:05 | dtantsur | yeah, thanks | |
| 14:01:20 | edleafe | Scheduler meeting going on now in #openstack-meeting-alt | |
| 14:11:45 | dansmith | dtantsur: edleafe: https://review.openstack.org/#/c/493227/1 | |
| 14:12:06 | dtantsur | sweet, thanks! | |
| 14:12:12 | edleafe | dansmith: cool | |
| 14:12:34 | dtantsur | should we recheck the ironic CI? it failed due to the overall timeout (hello, slow nodes!) | |
| 14:15:33 | smcginnis | Anyone have time to figure out what's going on with this grenade failure? | |
| 14:15:36 | smcginnis | http://logs.openstack.org/57/493057/10/check/gate-grenade-dsvm-neutron-ubuntu-xenial/5edfb4e/logs/ | |
| 14:15:39 | smcginnis | uwsgi: attempt to connect to Unix domain socket /var/run/uwsgi/nova-api-wsgi.socket (uwsgi-uds-nova-api-wsgi) failed | |
| 14:16:02 | dansmith | smcginnis: maybe cdent is the person to do that? | |
| 14:16:25 | cdent | smcginnis: yeah, I can look shortly, in the middle of a meeting, and then got to write a quick test, but then happy to look | |
| 14:16:36 | smcginnis | cdent: Perfect, thanks! | |
| 14:16:37 | dtantsur | dansmith: see my comments on 492964, you may be underestimating how "interesting" our driver is :) | |
| 14:20:37 | cdent | dansmith, dtantsur : as I recall the mismatch between inventory used and real inventory is hard to reconcile at the time of allocations because the allocations want to be based on the flavor and injecting and “oh by the way this is ironic, just consume everything” is complex so easier to change the inventory. (all of which is what led to customer resource class CUSTOM_IRON_SUPERMAN etc) | |
| 14:21:05 | dansmith | cdent: it's not a thing placement needs to handle, | |
| 14:21:14 | dansmith | it's a thing we should arrange for in our reporting | |
| 14:21:32 | cdent | ? then I must have missed a detail | |
| 14:22:17 | dtantsur | dansmith: I also don't get it a bit.. where exactly do you suggest to make the change? | |
| 14:22:40 | dtantsur | dansmith: we can either change the inventory in the ironic driver OR change how nova talks to placement somewhere on an upper level, no? | |
| 14:23:51 | dansmith | dtantsur: I'm replying hang on a sec | |
| 14:23:55 | dtantsur | sure, thanks | |
| 14:26:12 | dansmith | dtantsur: I'm saying nova should be either reporting node size instead of flavor to ironic for the _allocation_ instead of reporting a smaller node while an instance is booted there, | |
| 14:26:29 | dansmith | but you're correct that we don't have a way for the ironic driver to override that at the moment | |
| 14:26:49 | dtantsur | right, this is the problem. I agree that your suggested approach is much cleaner | |
| 14:26:59 | dansmith | I want to talk to jay about this before we proceed and I think we've got some time here | |
| 14:27:43 | dansmith | dtantsur: if people are using the exact filters today, then just continuing to report the size of the node even when an instance is booted there is fine, right? | |
| 14:27:53 | dansmith | because we'll report full inventory and they will consume it all | |
| 14:28:02 | dansmith | only if you have tiny flavors and big nodes would we have a problem | |
| 14:28:09 | dtantsur | dansmith: yes, this is ok | |
| 14:28:19 | dansmith | I feel like we could maybe just reno that and say that moving to RC is the solution which you have to do anyway | |
| 14:28:53 | dtantsur | dansmith: moving to RC also does not work without this patch, because we used to not report RC for deployed nodes | |
| 14:29:05 | dansmith | we need a patch for sure, I get that | |
| 14:29:18 | dtantsur | I can split it into two patches, if you would like: to fix RC and to fix reporting of everything else | |
| 14:29:26 | dansmith | I just want that patch to report consistent inventory regardless | |
| 14:30:06 | dansmith | if you want to split, then the split should be: 1. Keep reporting inventory even if instances are booted there, and 2. report _flavor_ as the inventory if an instance is booted | |
| 14:30:11 | dansmith | #2 is the thing I have a problem with | |
| 14:30:18 | dansmith | #1 I'm fine with | |
| 14:30:20 | dansmith | make sense? | |
| 14:30:58 | dtantsur | dansmith: reporting VCPU from node instead of flavors will break everyone who does not use exact filters (e.g. tripleo) | |
| 14:31:25 | dtantsur | in this case, I'd report only custom resource classes as #1, and leave vcpu/... for #2 | |
| 14:31:41 | dansmith | how does it break non-exact flavor users? | |
| 14:32:01 | dansmith | only if you have flavors so small that you could fit more than one per node right? | |