| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-sdks - 2017-03-31 | |||
| 10:25:00 | reedip | sindhu : ^^ | |
| 10:25:04 | reedip | thanks | |
| 13:01:19 | openstackgerrit | Cedric Brandily proposed openstack/python-openstackclient master: Enable to create legacy router https://review.openstack.org/449176 | |
| 14:16:08 | openstackgerrit | Dean Troyer proposed openstack/python-openstackclient master: start using api.versions https://review.openstack.org/451618 | |
| 14:49:45 | sindhu | reedip: will take a look :) | |
| 14:50:05 | reedip | great sindhu : cheers :D | |
| 14:56:44 | openstackgerrit | Cedric Brandily proposed openstack/python-openstackclient master: Enable to specify which vm fixed-ip to add https://review.openstack.org/452235 | |
| 16:37:58 | ZZelle | reedip, hi | |
| 16:38:15 | reedip | hi Cedrick / ZZelle :) | |
| 16:38:32 | ZZelle | reedip, about https://review.openstack.org/#/c/452235/1/doc/source/command-objects/server.rst | |
| 16:38:38 | reedip | yeah | |
| 16:39:05 | ZZelle | reedip, i don't see the added value of your proposed change | |
| 16:39:15 | reedip | ZZelle : okay | |
| 16:39:31 | ZZelle | reedip, 'Requested fixed ip address' comes from novaclient help | |
| 16:39:49 | reedip | it may not add too much value , thats why I said nit. But it is in line with the message format followed in OSC. | |
| 16:40:17 | reedip | ZZelle : its not necessary to translate the help messages exactly as that from the original client. But similarity is expected. | |
| 16:40:43 | reedip | ZZelle : I find the message , IMO, short. But this is my opinion. | |
| 16:41:11 | reedip | again, its a nit. If others find it Ok, then I dont have a problem. | |
| 16:42:52 | ZZelle | reedip, short doesn't mean meaningless | |
| 16:43:31 | reedip | ZZelle : does my message change the meaning of the one proposed in the patch? | |
| 16:44:10 | ZZelle | reedip, no, longer without added value IMO | |
| 16:45:08 | reedip | ZZelle ; I am not in agreement with you , but yes, thats a nit. I will revert my analysis, but retain my comment | |
| 16:45:34 | ZZelle | reedip, longer also means line-wrapped and less readable | |
| 16:45:57 | reedip | ZZelle : if we are going beyond 80 characters, yes | |
| 17:15:27 | openstackgerrit | Cedric Brandily proposed openstack/python-openstackclient master: Enable to specify which vm fixed-ip to add https://review.openstack.org/452235 | |
| 20:12:31 | stevelle | elmiko_ or any other API-WG types paying attention? | |
| 20:38:46 | figleaf | stevelle: I'm around | |
| 20:40:29 | rosmaita | figleaf: got a question about supporting partial downloads. we are thinking of supporting only single-range requests. so in response to a multi-range request, would it be better to (A) return 501, or (B) return 200 and the entire content | |
| 20:40:52 | rosmaita | the standard isn't very clear on this point | |
| 20:41:01 | stevelle | figleaf: reference we have been looking at https://tools.ietf.org/html/rfc7233#section-4.4 | |
| 20:41:16 | figleaf | rosmaita: 5xx are only for server-side errors | |
| 20:41:37 | rosmaita | well, it's kind of on us because we aren't implementing something | |
| 20:41:55 | figleaf | If you only support single-range, and they request something unsupported, it should be a 400 Bad Request | |
| 20:41:57 | stevelle | our library doesn't support multi-range | |
| 20:42:12 | figleaf | Is that documented? | |
| 20:42:32 | stevelle | we are choosing not to try to work around that limitation at this time | |
| 20:45:21 | figleaf | I still think a 400 with an error message that explains how to correct the request would be best | |
| 20:45:59 | rosmaita | figleaf: i think this is what we have doc'd now: https://developer.openstack.org/api-ref/image/v2/?expanded=download-binary-image-data-detail | |
| 20:47:04 | figleaf | ah, forgot about 416 | |
| 20:47:15 | figleaf | Not one of the more popular return codes :) | |
| 20:47:20 | rosmaita | nope | |
| 20:47:28 | stevelle | pointing at what we have now (which is for the wrong header) is kind of terrible though :) | |
| 20:47:54 | stevelle | makes me sad | |
| 20:49:14 | stevelle | the current text saying "For an unsatisfiable partial download request" seems to suggest it is used where it probably shouldn't | |
| 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 | |