| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-sdks - 2017-03-30 | |||
| 20:57:57 | ankur-gupta-f4 | nakul_d: its on my todo list | |
| 20:58:35 | nakul_d | ankur-gupta-f4: cool..thanks:) | |
| 23:30:24 | openstackgerrit | Merged openstack/osc-lib master: Change noauth strategy for plugin loading https://review.openstack.org/450452 | |
| #openstack-sdks - 2017-03-31 | |||
| 00:33:04 | reedip | anything new happeneing? | |
| 00:36:00 | reedip | armax : never mind, got the info from the new stadium docs :) | |
| 00:50:59 | reedip | wrong place :P | |
| 03:21:37 | RuiChen | hi rabel: I saw your discussion in IRC meeting about "router show interface", seems that the key is identify which port is interface and which is gateway, if i'm not wrong, so "port list --router <router> --long" might be helpful, that show "device owner", looks like: network:router_interface/network:router_gateway | |
| 04:22:31 | openstackgerrit | Merged openstack/python-openstackclient master: Remove log translations https://review.openstack.org/447888 | |
| 09:36:59 | reedip | RuiChen : need your help | |
| 09:37:35 | reedip | RuiChen : https://review.openstack.org/#/c/356263/18 was lost somewhere , couldnt track it. I am pushing it now.... can you review it ? | |
| 09:38:25 | reedip | just doing the final test cases | |
| 09:38:43 | reedip | ankur-gupta-f4 : for you as well, when you are awake :D ^^ | |
| 09:59:41 | openstackgerrit | Reedip proposed openstack/python-openstackclient master: Add extra dhcp option to 'port create/set/unset' https://review.openstack.org/356263 | |
| 10:07:10 | openstackgerrit | Reedip proposed openstack/python-openstackclient master: Add extra dhcp option to 'port create/set/unset' https://review.openstack.org/356263 | |
| 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 | |