Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2018-01-30
21:40:30 mriedem like, i don't know how to take that and see how long a simple tempest create server test has taken over the last 12 monhts
21:40:32 mriedem *months
21:40:36 mriedem mtreinish can maybe help
21:40:57 openstackgerrit melanie witt proposed openstack/nova stable/ocata: Stop globally caching host states in scheduler HostManager https://review.openstack.org/539013
21:49:05 mriedem mmedvede: powerkvm ci seems pretty unhappy
21:49:07 mriedem is that a known issue?
21:51:30 openstackgerrit Sylvain Bauza proposed openstack/nova master: Provide support matrix and doc for VGPU https://review.openstack.org/539266
21:56:07 mriedem dansmith: want to hit these backports? I didn't realize those weren't merged by now https://review.openstack.org/#/q/Ie70c77db753711e1449e99534d3b83669871943f+status:open
21:56:48 mmedvede mriedem: I do not see anything too far out of ordinary, which powerkvm ci unhappiness are you referring to?
21:57:00 mmedvede double checking now
21:57:12 mriedem mmedvede: https://review.openstack.org/#/c/538510/
21:57:18 mriedem https://dal05.objectstorage.softlayer.net/v1/AUTH_3d8e6ecb-f597-448c-8ec2-164e9f710dd6/pkvmci/nova/10/538510/3/check/tempest-dsvm-full-xenial/41f1c6d/
22:01:15 edleafe efried: PUT {} is not semantically the same as DELETE, even if in most cases the result is the same
22:04:15 mriedem cfriesen: speaking of perf, this is an easy fix for an RT perf issue if you're building several instances on the same compute host at once https://review.openstack.org/#/q/Ib588c31a4d2075f8730409d50c99dfb04180a9cd+status:open
22:04:32 mriedem our operations people were hitting perf issues with the big RT update lock
22:09:08 dansmith mriedem: got em
22:10:05 efried edleafe: Oh? How not?
22:10:26 efried edleafe: Oh, you mean in the general case, where None and {} aren't the same thing.
22:10:50 prometheanfire win 30
22:11:51 edleafe efried: No. Sometimes you need to indicate if anything was in fact deleted. PUT {} can't do that; DELETE can
22:12:12 efried edleafe: It can? How?
22:12:43 openstackgerrit Matt Riedemann proposed openstack/nova stable/ocata: Pass the correct image to build_request_spec in conductor.rebuild_instance https://review.openstack.org/516404
22:14:12 mmedvede mriedem: that pkvmci failure seems to have been a fluke on that VM, one of a kind. Sorry for the false negative.
22:14:56 edleafe efried: In cases where that distinction is important, you can return a 404 if the thing you're trying to delete is not there
22:15:17 sean-k-mooney the ibm powerkvm ci is still broken currently correct?
22:15:25 edleafe efried: Like I said, it isn't usually necessary. When you want to delete something, you usually just want it gone.
22:15:58 efried edleafe: Okay, then I'm specifically talking about resource provider inventories, traits, allocations, and aggregates.
22:16:42 efried edleafe: I can provide a good argument for why we should favor PUT <empty> over DELETE (at least DELETE as currently implemented). I'm trying to figure out if there's an argument for the other side.
22:16:49 edleafe efried: for those cases, I simply prefer the grammar of DELETE
22:17:07 mmedvede sean-k-mooney: I am confused as to why you think so. It did have a few failures, but failure rate is within normal
22:17:26 efried edleafe: The grammar of the request (as opposed to the (lack of) response), right?
22:17:28 edleafe efried: That's what DELETE is designed to do.
22:17:52 edleafe efried: No, PUT {} is an awkward way of saying DELETE
22:18:49 efried edleafe: Yeah, I get it. Is it "wrong" (in the annals of HTTP, or REST, or APIs, or whatever) for a DELETE API to return a payload?
22:20:30 sean-k-mooney efried: yes i belive it is not ment to have a payload generally
22:20:46 edleafe efried: Unless the response is 204.
22:21:01 mmedvede sean-k-mooney: am I missing something? Both http://ci-watch.tintri.com/project?project=nova and https://dal05.objectstorage.softlayer.net/v1/AUTH_3d8e6ecb-f597-448c-8ec2-164e9f710dd6/pkvmci/index.html do not indicate a systemic failure on nova patches
22:21:09 mmedvede for powerkvm ci
22:21:40 sean-k-mooney mmedvede: there was a message a week or two saying it was i was not sure if it was fixed or not
22:21:56 edleafe efried: Othewise, you can return either a description of the deleted resource (200) or a URL to check for success/failure on a 202.
22:22:28 efried edleafe: So it'd be acceptable for a DELETE to return 200 with a payload?
22:23:01 edleafe efried: it's required
22:23:07 mriedem sean-k-mooney: are you thinking of the zvm ci?
22:23:23 mriedem or zkvm i mean
22:23:58 efried edleafe: Sorry, I mean I get that it's cool for DELETE to respond 204 with no content; I'm asking whether there's any restriction - standard-wise or cultural - against a DELETE responding 200 with a payload.
22:24:07 mriedem mmedvede: i had seen some other pkvm ci failures in stable branches, but those might have been old/transient
22:24:11 efried and I think you've said that's acceptable.
22:24:46 edleafe efried: yes, it's acceptable, although it isn't very common
22:26:14 sean-k-mooney mriedem: yes i was https://www.mail-archive.com/openstack-dev@lists.openstack.org/msg115082.html
22:27:29 mriedem sean-k-mooney: mixing up one of the dozen ibm 3rd party CIs is grounds for pistols at dawn
22:28:02 mmedvede mriedem: yes, stable branches have high rate of failure unfortunately, I'll shift some time to look at those.
22:28:53 sean-k-mooney mriedem: haha well the grenade job is failing because of a ubuntu keyring missing on the powervm ci too but that could be intermitent
22:29:33 mmedvede sean-k-mooney: that is intermittent, there is a bug in ubuntu somewhere that we reported
22:29:59 mmedvede it happens only last 10 minutes of any hour
22:30:21 sean-k-mooney mmedvede: ya the patch i noticed it on is for rocky anyway so im not going to waste ci time rechecking
22:32:47 sean-k-mooney anyway i have fixed my unrelated ovs db socket somehow became a directory and broke everything issue with kolla so im going to head home for the evening
22:32:58 efried edleafe: btw, in case it wasn't obvious, this is pursuant to what we were discussing the other day. Without a response payload, we have to assume things about the effect of DELETE on provider generation. One possible solution is to use PUT <empty> where available, which it happens to be for all of these. Another is to implement DELETE with a response payload from which we can glean the new generation.
22:36:16 edleafe efried: Aren't we sending the generation along with the PUT/DELETE request?
22:37:00 efried edleafe: With PUT, yes. Not with DELETE, which doesn't accept a payload. The latter is a definite (but separate) problem.
22:37:37 efried edleafe: But even the former only guarantees that we're deleting what we thought we were deleting. The lack of generation in the return is a problem for *subsequent* updates.
22:38:11 efried ...unless we continue to make assumptions about how placement does generations. Which IMO is wrong.
22:38:40 edleafe efried: So say I get the generation back from the PUT/DELETE. Right after that, other requests modify the resource. What good does getting back gen+1 from the request do me then?
22:39:54 efried edleafe: In that scenario, it doesn't save you anything, because your next update will 409 and you have to re-GET the provider and its associated stuff before you redrive your update.
22:40:19 efried edleafe: It's in the scenario where the resource provider *doesn't* change that it saves us.
22:40:36 edleafe efried: I still don't see that
22:40:38 efried edleafe: Because without it, we *have* to do that re-GET in order to glean the new generation.
22:40:46 efried (again, unless assumptions)
22:41:00 edleafe efried: Oh, you're still pretending that we don't know how generations work
22:41:04 efried Correct.
22:41:08 edleafe The name itself should be a giveaway
22:41:21 efried say wha?
22:41:33 efried Please tell me you're joking
22:41:40 edleafe no, I'm not
22:42:14 efried We're not going to assume API behavior based on the dictionary definition of an ambiguous English word with lots of synonyms.
22:42:35 efried even if any one of those definitions said "and we start at 0, and the next one is +1" - which they don't.
22:43:19 edleafe We adopted generations over other candidates, such as etags, precisely because we *could* make these assumptions
22:43:36 edleafe I understand that we have not documented that behavior well enough for outsiders
22:43:47 efried Or insiders, apparently. I think I qualify.
22:43:51 edleafe But within the placement dev team, it was clear
22:44:06 edleafe were you in the discussions about what to use?
22:44:32 efried Oh, by "outsiders" did you mean whoever wasn't in the design discussion?
22:44:40 edleafe yes
22:44:51 efried I thought you meant people who aren't developers of the placement API.
22:45:15 edleafe well, you have seemed to pick up on the way it works :_
22:45:50 efried Yes, and I vociferously contend that we have not documented that behavior well enough.
22:46:04 edleafe and I will vociferously agree with that
22:46:14 efried In any case, based on last week's straw poll, I don't think there's consensus even among people who were in the room when it was designed.
22:46:32 efried ...as to whether the behavior should be an explicit, documented part of the API.
22:46:34 edleafe some of us weren't happy with the choice :(
22:46:38 mriedem you guys are talking about a decision made a couple of years ago right?
22:46:50 mriedem in a kind of 'shit or get off the pot' situation?
22:46:54 edleafe mriedem: well, about a year or so I think
22:47:04 mriedem not knowing what we'd be doing with these things several releases later
22:47:19 efried mriedem: We're not even arguing the decision to implement generation a certain way. I don't think anyone has a problem with that.
22:47:26 edleafe there was the opaque marker (etag) proponents, and the deterministic marker (generation) camp
22:47:28 mriedem a year would have been the ATL PTG and it seems older than that, at least BCN
22:48:07 mriedem so next step is....documenting how generations work
22:48:08 mriedem ?
22:48:29 efried mriedem: Yeah - what's at issue is whether that implementation is supposed to be known by consumers of the API, or whether it's supposed to be opaque.
22:49:13 mriedem sorry, i haven't followed this debate the last several times it's come up, but what's the issue? that a client can get a generation that skips increments?

Earlier   Later