Earlier  
Posted Nick Remark
#openstack-sdks - 2017-03-31
20:49:47 rosmaita (well, my reading, anyway)
20:50:25 figleaf rosmaita: I tend to agree.
20:52:17 rosmaita figleaf: that worries me, because we are both sensible fellows, so if we agree, we are probably misreading the standard
20:52:20 rosmaita :)
20:52:36 figleaf what makes you think I'm sensible???
20:53:15 rosmaita we tend to agree a lot, it's the only conclusion to draw
20:54:24 rosmaita in any case, you seem to not like the 501 idea
20:56:07 figleaf No, since the server *does* support the functionality. The user can re-formulate the request so that it will succeed
20:56:44 stevelle to advocate for the other side, the server doesn't support the correctly-formatted request
20:56:48 stevelle so "not supported"
20:57:18 stevelle "I can't do that, Dave." is different from "Syntax Error"
20:58:58 figleaf Well, if I were a user, and I got that, I would assume you don't support any downloads
20:59:31 figleaf the problem with that is that the server *can't* do it
21:00:04 stevelle I thought 501 was that. Note that we WILL return an Accepts-Range header
21:00:19 stevelle regardless of the status code
21:01:13 figleaf Remember that in the RFC, "method" means GET, PUT, etc.
21:01:43 stevelle iirc the RFC says "may" mean the method is unsupported... checking
21:02:24 figleaf 4xx is client error. If multi-range is documented as not supported, and a client requests multi-range, that's client error
21:04:08 stevelle I have no horse here. Just trying to thoroughly consider all alternatives. The note on https://tools.ietf.org/html/rfc7233#section-4.4 is the argument for just returning the full image and 200 status
21:04:35 stevelle I see multiple "right" answers, just trying to find more consensus on what is best
21:05:27 rosmaita figleaf: i am worried about the openstack API implications of returing a 400 and then if we later add support ... what do we do? if it's a 501, we are allowed to make the change
21:05:44 stevelle ahh, the meta discussion :)
21:05:56 figleaf My tiebreaker is always what would be more helpful for the consumer of the API?
21:06:35 figleaf rosmaita: that's a very cynical way of approaching API goodness
21:06:53 rosmaita my ocata experiences have made me very cynical!
21:07:08 figleaf Being "allowed" to fix a 5xx is in the spirit of 5xx responses are bugs
21:07:27 rosmaita ok, so 501 might be confused as "no support at all", that makes it un-good
21:07:29 figleaf and a client should never expect a bug
21:07:58 rosmaita 400 would mean reformulate your request, and possibly RTFM before making another request
21:08:13 rosmaita 200 plus the entire thing appears to be allowed by the standard
21:08:31 figleaf rosmaita: well, the error message in the response should be so helpful that they won't have to RTFM!
21:09:09 rosmaita i think we should add "and RTFM" to all 400s just on general principles
21:09:16 stevelle figleaf: in that case, and error message is more important than the status code chosen :)
21:09:23 stevelle I don't disagree, but still what code
21:09:27 figleaf stevelle: +1
21:09:52 figleaf You guys could always come to next week's API WG meeting
21:10:00 figleaf stevelle said he'd bring bagels
21:10:05 stevelle lies!
21:10:19 rosmaita i think they only have to be virtual bagels
21:10:30 rosmaita and, you only have to bring them to your keyboard
21:10:34 figleaf Just the holes
21:10:59 stevelle I don't know where to find bagels in PDX at 6am that don't suck
21:11:15 rosmaita so the argument for 400 and against 416 is that it's a properly formatted request, we just won't accept it
21:11:28 figleaf stevemar: get up at 3am and make 'em yourself!
21:11:38 stevelle poor steve
21:11:46 stevelle he has to make me bagels now :)
21:12:14 rosmaita he is going to be very surprised when he sees that irc highlight
21:12:18 figleaf stevemar: sorry. Freakin' tab completion!
21:12:21 rosmaita "wtf? bagels?"
21:12:37 figleaf Hey, Toronto has some good bagels
21:13:37 figleaf rosmaita: 416 seems to me like it fits the case where they request a range that is larger than the actual resource
21:13:56 figleaf This matter is not that at all
21:14:16 rosmaita right
21:14:30 figleaf if they request multiple ranges that are all within the resource length, 416 isn't applicable
21:14:45 openstackgerrit Cedric Brandily proposed openstack/python-openstackclient master: Enable to add/remove port to/from a server https://review.openstack.org/452328
21:14:54 figleaf But since you don't support multiple ranges, 400 is returned
21:15:03 rosmaita ok, 400 plus informative error message sounds good ... what about just dumping the entire content with a 200 ?
21:15:23 stevelle reviewed where we talked about 400 vs 416, and I don't see any reason to dwell on that here. 400 or 200 is where I think we are at
21:15:38 figleaf rosmaita: wait - are they requesting the whole thing, just in parts?
21:15:54 rosmaita figleaf: not necessarily
21:16:09 rosmaita i think we don't even want to try to find out
21:16:29 rosmaita we are just saying "no multiple range requests are accepted"
21:16:34 figleaf So no, I wouldn't return anything other than what they requested
21:16:46 figleaf 'zactly
21:17:03 figleaf brb
21:17:27 rosmaita i'm leaving, too ... have a good weekend, and thanks for the help
21:24:18 figleaf no worries - enjoy your weekend!
22:39:47 openstackgerrit Dean Troyer proposed openstack/python-openstackclient master: start using api.versions https://review.openstack.org/451618
#openstack-sdks - 2017-04-01
02:44:15 openstackgerrit Rui Chen proposed openstack/python-openstackclient master: Make block-device-mapping more stable and clear https://review.openstack.org/438141
02:44:19 openstackgerrit Rui Chen proposed openstack/python-openstackclient master: Replace "Display Name" by "Name" in volume list https://review.openstack.org/423081
05:02:38 openstackgerrit Reedip proposed openstack/python-openstackclient master: Introduce quota unset command https://review.openstack.org/376311
05:07:15 openstackgerrit Reedip proposed openstack/python-openstackclient master: Introduce quota unset command https://review.openstack.org/376311
05:30:16 reedip RuiChen: yiur patch https://review.openstack.org/#/c/449879 wont help OSC till the new lib is released, right?
05:34:19 reedip RuiChen : I have reopened https://review.openstack.org/#/c/447938/9 to allow merge of https://review.openstack.org/#/c/383025/73
06:22:49 RuiChen sorry, reedip , I'm in a meeting, I will take a look later
06:34:48 RuiChen reedip: I'm back, yes, need a new openstacksdk version to ship the change
06:35:36 RuiChen reedip: I prefer to remove the floating ip cache, then use a internal method to support getting floating ip by both uuid and address
06:36:02 RuiChen reedip: then switch to new openstacksdk version when it's ready
08:05:18 openstackgerrit Rui Chen proposed openstack/python-openstackclient master: Add help commands withouth auth in functional https://review.openstack.org/452407
08:25:16 reedip RuiChen : Didnt get u
08:44:44 RuiChen reedip: I means don't use ip_cache in _find_floating_ip() at all, I can push a patch as reference, if you don't mind
08:45:30 reedip u mean in the function definition?
08:46:17 RuiChen all related part in floating_ip.py
09:03:30 reedip RuiChen: u mean in the function definition?
09:10:14 RuiChen reedip: I remove all the cache related code now
09:10:27 reedip oh , I also did the same :D
09:12:13 RuiChen reedip: you're updating the patch?
09:12:16 reedip RuiChen : Can you check this oatch ?
09:12:23 openstackgerrit Reedip proposed openstack/python-openstackclient master: Structure FindFloatingIP() to work without ip_cache https://review.openstack.org/447938
09:12:35 reedip If you see anything different then please update it
09:12:41 RuiChen ah, of course
09:12:58 reedip sorry for the rework...but your idea struck me :)
09:14:19 reedip Thanks :)
09:16:41 RuiChen reedip: thank you work hard for this patch, my English is bad, it might make you confused :(
09:16:45 reedip RuiChen : I think the Functional Test case needs to be changed
09:17:12 reedip RuiChen : Python is not dependent on English ! :D
09:17:35 RuiChen reedip: good point :-)
09:19:27 reedip Let me know if anything needs to be changed
09:20:51 RuiChen reedip: the current implement is same with I wish, thank you
09:21:15 reedip RuiChen : Okay great, awaiting your +1 once Jenkins finishes troubling me :D

Earlier   Later