| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-sdks - 2017-03-31 | |||
| 20:49:15 | rosmaita | figleaf: our reading of the rfc7233 is that 416 is for inconsistent range requests, but in this case, you could be making an otherwise OK request syntax-wise, we just don't suport multi-range requests | |
| 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 | |