| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-sdks - 2018-12-12 | |||
| 20:10:56 | Shrews | i may not be quick, but i sure am slow | |
| 20:11:07 | morgan | Shrews: better? | |
| 20:11:09 | morgan | Shrews: :P | |
| 20:11:26 | Shrews | morgan: i think you are having an identity crisis | |
| 20:12:23 | morgan | nah, just /nick was not letting me go to morgan from kmalloc... oddly | |
| 20:24:02 | morgan | anyway... | |
| 20:26:50 | mriedem | does ksa impose any kind of http response timeout? | |
| 20:27:47 | mriedem | hmm https://github.com/openstack/keystoneauth/blob/ccf6cb79033b2083d9177823094f7836eb68ae0d/keystoneauth1/session.py#L248 | |
| 21:20:51 | morgan | mriedem: hmm | |
| 21:21:04 | morgan | mriedem: not by default | |
| 21:26:48 | mriedem | i saw the --timeout option in the CLI defaults to 600 | |
| 21:26:52 | mriedem | but that's still more than plenty | |
| 21:34:39 | morgan | ah yeah | |
| 21:34:51 | morgan | keystoneauth is very liberal in the "we don't force timeouts" | |
| 21:35:00 | morgan | but consumers of KSA aren't so easy going :P | |
| 21:35:04 | morgan | but 600s is a long timeout | |
| #openstack-sdks - 2018-12-13 | |||
| 05:50:51 | openstackgerrit | Rajat Dhasmana proposed openstack/python-openstackclient master: Fix: Restore operation returns 'VolumeBackupsRestore' object is not iterable https://review.openstack.org/624860 | |
| 07:44:08 | openstackgerrit | machunnan proposed openstack/js-openstack-lib master: change http:// to https:// https://review.openstack.org/624873 | |
| 07:47:57 | openstackgerrit | machunnan proposed openstack/js-openstack-lib master: change http:// to https:// https://review.openstack.org/624874 | |
| 07:53:00 | openstackgerrit | machunnan proposed openstack/js-openstack-lib master: change http:// to https:// https://review.openstack.org/624875 | |
| 07:59:33 | openstackgerrit | machunnan proposed openstack/js-openstack-lib master: change http:// to https:// https://review.openstack.org/624879 | |
| 08:03:11 | openstackgerrit | machunnan proposed openstack/js-openstack-lib master: change http:// to https:// https://review.openstack.org/624880 | |
| 08:04:05 | openstackgerrit | machunnan proposed openstack/js-openstack-lib master: change http:// to https:// https://review.openstack.org/624881 | |
| 08:04:13 | openstackgerrit | Rajat Dhasmana proposed openstack/python-openstackclient master: Fix: Restore operation returns 'VolumeBackupsRestore' object is not iterable https://review.openstack.org/624860 | |
| 08:08:20 | openstackgerrit | machunnan proposed openstack/js-openstack-lib master: change http:// to https:// https://review.openstack.org/624883 | |
| 08:09:57 | openstackgerrit | machunnan proposed openstack/js-openstack-lib master: change http:// to https:// https://review.openstack.org/624884 | |
| 08:11:51 | openstackgerrit | machunnan proposed openstack/js-openstack-lib master: change http:// to https:// https://review.openstack.org/624886 | |
| 08:12:50 | openstackgerrit | machunnan proposed openstack/js-openstack-lib master: change http:// to https:// https://review.openstack.org/624887 | |
| 08:38:38 | openstackgerrit | machunnan proposed openstack/js-openstack-lib master: Capitalizes the first letter -- should to Should https://review.openstack.org/624891 | |
| 08:43:07 | openstackgerrit | machunnan proposed openstack/js-openstack-lib master: Capitalizes the first letter -- should to Should https://review.openstack.org/624892 | |
| 11:53:09 | frickler | mordred: Shrews: is there any news regarding the dogpile.cache issue to fix broken nodepool jobs? | |
| 12:59:08 | Shrews | frickler: mordred has a review up to requirements to limit the version. and morgan is going to look into the actual dogpile.cache change for us | |
| 13:00:02 | Shrews | that's all i know before coffee | |
| 13:09:48 | frickler | Shrews: thx, found the reqs patch, seems that it needs a bug report/story attached. do we have a simple reproducer yet? | |
| 13:12:08 | Shrews | frickler: i have one. 1 sec | |
| 13:17:30 | Shrews | frickler: http://paste.openstack.org/show/737212/ | |
| 13:30:55 | frickler | Shrews: thx, created https://storyboard.openstack.org/#!/story/2004605 from that and will add to the reqs patch | |
| 13:31:06 | frickler | mordred: morgan: ^^ fyi | |
| 14:33:00 | elmiko | edleafe: ack, thanks | |
| 14:33:36 | edleafe | elmiko: it's brief | |
| 14:34:17 | elmiko | yeah, but also contains good info imo | |
| 14:34:38 | cdent | I thought it was elegantly sufficient | |
| 14:34:42 | elmiko | me too | |
| 14:34:49 | elmiko | i like it, no objections here edleafe | |
| 14:38:09 | edleafe | okie dokie | |
| 14:42:23 | elmiko | edleafe: reading it over again, i think the only thing that might make me a tad nervous is that it sounds like we could answer all api related issues that come up. i wonder if that gives the impression that any project-specific api issues are fair game to ask the sig? (maybe i'm reading too much, maybe this isn't a concern) | |
| 14:44:05 | cdent | elmiko: to some extent that's supposed to be what SIG means | |
| 14:44:14 | cdent | we are a house for people who care about APIs | |
| 14:44:42 | elmiko | i guess i meant more like, "hey this call to service X isn't working for me, why not? (insert arcane curl command here)" | |
| 14:45:05 | elmiko | and i imagine we would definitely point that person in the right direction | |
| 14:45:15 | cdent | "hey caller, it looks like you're using nova, you might want to talk to ..." | |
| 14:45:25 | elmiko | anyways, it was just a thought. i don't think it's a concern, but if i pushed to make a critique. | |
| 14:45:32 | elmiko | yeah | |
| 14:45:52 | elmiko | i still don't have an objection, i was just trying to go deeper with due diligence =) | |
| 14:51:15 | edleafe | elmiko: Sorry, was afk | |
| 14:51:47 | edleafe | I can see what you mean, but I kinda think that's a good thing. The more interest in the SIG, the better | |
| 14:52:16 | elmiko | i like that attitude =) | |
| 14:52:17 | edleafe | Like cdent said, we may not have the answers, but we might help point people to better resources | |
| 14:52:25 | elmiko | agreed | |
| 14:56:41 | elmiko | thanks for indulging me ;) | |
| 15:11:57 | cdent | elmiko: speaking of indulgences, how did your aqua vit settle in at home. did it even make it home? | |
| 15:12:31 | elmiko | haha, yes! it made it home | |
| 15:12:35 | elmiko | it's been a big hit =) | |
| 15:13:02 | elmiko | people are becoming scared at the volume of clear liquors i am pushing on them when they visit XD | |
| 15:13:35 | cdent | here, try this mysterious thing! | |
| 15:23:49 | elmiko | basically | |
| 15:24:31 | elmiko | at least with the eau de vie they kinda get it, but when i start digging out stuff slike slivovice and awamori things get /interesting/ =D | |
| 15:25:24 | elmiko | the liquor cabinet is starting to look a little nuts though, like "does this guy have a problem?" haha | |
| 16:00:17 | edleafe | API-SIG Office Hour has begun | |
| 16:00:43 | edleafe | Get your feet off the table!! Were you raised in a barn? | |
| 16:01:38 | elmiko | sadly no, just a normal house | |
| 16:03:10 | edleafe | dtantsur: around? Wanted to get your feedback on http://paste.openstack.org/show/737157/ | |
| 16:03:32 | edleafe | It's the little blurb for the OpenStack Foundation Annual Report about our SIG | |
| 16:03:58 | dtantsur | edleafe: sounds perfect to me | |
| 16:04:16 | edleafe | kewl | |
| 16:04:51 | dtantsur | also JFYI I'm off starting tomorrow, back in Jan | |
| 16:04:51 | edleafe | The only other issue I had was whether to freeze https://review.openstack.org/#/c/616610/ | |
| 16:05:01 | edleafe | lucky you! | |
| 16:05:19 | edleafe | I'm around all next week, then back 2nd week of Jan | |
| 16:05:58 | elmiko | i'll be around next week as well | |
| 16:07:25 | edleafe | dtantsur: so you would prefer to interpret DELETE as "find this resource, and then delete it" | |
| 16:07:48 | edleafe | instead of "make sure this resource doesn't exist" | |
| 16:07:56 | dtantsur | edleafe: "delete this resource", yes | |
| 16:09:01 | dtantsur | I think if somebody is actually going to follow this guideline, it's going to be confusing for users | |
| 16:09:15 | dtantsur | e.g. `rm /foo` actually errors out | |
| 16:10:48 | edleafe | So consider this scenario: resource `foo` exists. Two users call DELETE /rsrc/foo. One should get 204, and the other 404? | |
| 16:13:04 | dtantsur | right | |
| 16:14:36 | elmiko | i think the only weird part to me is how long should that behavior persist after the delete? | |
| 16:14:54 | kmalloc | Shrews: now that my massive headache of doom has passed, i should be able to look at dogpile and the other issues outstanding | |
| 16:15:02 | elmiko | like, if i delete a resources ages ago, when should the server respond with a 404? | |
| 16:15:04 | kmalloc | Shrews, mordred: ^ thanks for bearing with me yesterday. | |
| 16:15:34 | elmiko | or should it ever? which implies keeping track of delete resources for the purposes of delete responses | |
| 16:15:54 | edleafe | RFC 7231 says that DELETE is idempotent: https://tools.ietf.org/html/rfc7231#section-8.1.3 | |
| 16:15:56 | dtantsur | tracking deleting resources is quite a change to many database models | |
| 16:16:41 | dtantsur | edleafe: that's one of the reasons HTTP is not a great match for API.. | |
| 16:17:03 | kmalloc | edleafe: oh good to know. | |
| 16:17:15 | kmalloc | edleafe: also... damn that means keystone has messed up a bunch. | |
| 16:18:07 | elmiko | edleafe: such a weird knot this is, it should be idempotent, but does that mean it should always return some 2XX for a previously deleted resource? | |
| 16:18:33 | elmiko | i mean, i know that's what we are proposing i'm just exploring the idea a little more | |
| 16:18:40 | dtantsur | yeah, this is a weird point | |