*** Apoorva_ has quit IRC | 01:07 | |
*** terrylhowe has quit IRC | 05:24 | |
*** cdent has joined #openstack-api | 07:14 | |
*** fzdarsky has joined #openstack-api | 07:25 | |
*** alex_klimov has joined #openstack-api | 07:50 | |
*** woodster_ has quit IRC | 07:51 | |
*** alex_xu has quit IRC | 07:52 | |
*** alex_xu has joined #openstack-api | 07:55 | |
*** lucasagomes has joined #openstack-api | 08:06 | |
*** e0ne has joined #openstack-api | 09:02 | |
*** e0ne is now known as e0ne_ | 09:12 | |
*** e0ne_ is now known as e0ne | 09:16 | |
*** e0ne is now known as e0ne_ | 09:58 | |
*** e0ne_ is now known as e0ne | 10:01 | |
*** salv-orlando has quit IRC | 10:16 | |
*** e0ne is now known as e0ne_ | 10:45 | |
*** e0ne_ is now known as e0ne | 10:49 | |
*** openstackgerrit has quit IRC | 11:09 | |
*** openstackgerrit has joined #openstack-api | 11:10 | |
*** terrylhowe has joined #openstack-api | 11:15 | |
*** alex_klimov has quit IRC | 11:21 | |
*** alex_klimov has joined #openstack-api | 11:29 | |
*** e0ne is now known as e0ne_ | 11:39 | |
*** e0ne_ is now known as e0ne | 11:41 | |
*** lucasagomes is now known as lucas-hungry | 11:44 | |
*** e0ne is now known as e0ne_ | 11:56 | |
*** e0ne_ is now known as e0ne | 11:59 | |
*** salv-orlando has joined #openstack-api | 12:08 | |
*** openstack has joined #openstack-api | 12:12 | |
*** ig0r_ has joined #openstack-api | 12:24 | |
*** annegent_ has quit IRC | 12:24 | |
*** annegentle has joined #openstack-api | 12:25 | |
*** lucas-hungry is now known as lucasagomes | 12:40 | |
*** e0ne is now known as e0ne_ | 12:42 | |
*** e0ne_ is now known as e0ne | 12:47 | |
*** e0ne is now known as e0ne_ | 13:40 | |
*** e0ne_ is now known as e0ne | 13:48 | |
*** annegentle has quit IRC | 14:00 | |
*** sigmavirus24_awa is now known as sigmavirus24 | 14:01 | |
*** woodster_ has joined #openstack-api | 14:20 | |
openstackgerrit | Michael McCune proposed openstack/api-wg: Adding 5xx guidance https://review.openstack.org/183698 | 14:23 |
---|---|---|
elmiko | notmyname, salv-orlando, would be curious on your thoughts about the changes ^^ | 14:27 |
*** agentle_ has joined #openstack-api | 14:28 | |
salv-orlando | elmiko: sure! | 14:38 |
elmiko | salv-orlando: thanks =) | 14:38 |
*** terrylhowe has left #openstack-api | 14:56 | |
*** e0ne is now known as e0ne_ | 14:56 | |
*** e0ne_ is now known as e0ne | 14:59 | |
*** alex_xu has quit IRC | 15:09 | |
*** alex_xu has joined #openstack-api | 15:10 | |
*** ig0r_ has quit IRC | 15:10 | |
*** ig0r__ has joined #openstack-api | 15:11 | |
*** ig0r_ has joined #openstack-api | 15:18 | |
*** ig0r__ has quit IRC | 15:19 | |
*** notmars has joined #openstack-api | 15:23 | |
*** wuhao has joined #openstack-api | 15:35 | |
*** haha has joined #openstack-api | 15:38 | |
*** haha is now known as Guest74025 | 15:39 | |
*** Guest74025 has quit IRC | 15:39 | |
*** ig0r__ has joined #openstack-api | 15:43 | |
*** ig0r_ has quit IRC | 15:43 | |
*** notmars has quit IRC | 15:46 | |
*** e0ne is now known as e0ne_ | 15:53 | |
elmiko | sigmavirus24: got a response code/rfc question. is 422 part of http/1 but not 1.1? | 15:53 |
*** e0ne_ is now known as e0ne | 15:54 | |
*** wuhao has quit IRC | 15:54 | |
*** wuhao has joined #openstack-api | 15:54 | |
sigmavirus24 | elmiko: I think it's part of neither to be honest | 15:55 |
sigmavirus24 | It's from the WebDAV RFC iirc but GitHub and other services use it anyway | 15:55 |
elmiko | ok, maybe that's why i'm having trouble finding it | 15:56 |
sigmavirus24 | They like it | 15:56 |
sigmavirus24 | or maybe CalDAV | 15:56 |
sigmavirus24 | I forget which DAV | 15:56 |
sigmavirus24 | One of the DAVs | 15:56 |
elmiko | i'm looking at https://review.openstack.org/#/c/197871 | 15:56 |
elmiko | and was curious about the mention of 422 | 15:56 |
*** notmars has joined #openstack-api | 16:03 | |
sigmavirus24 | That's not the reason string I've seen used for 422 | 16:10 |
sigmavirus24 | I've seen Validation Failed | 16:10 |
sigmavirus24 | Anyway, for state conflicts, I agree 409 is the way the truth and the light | 16:11 |
sigmavirus24 | Nevermind | 16:11 |
sigmavirus24 | GitHub does use it as "Unprocessable Entity" ignore me | 16:12 |
elmiko | lol | 16:14 |
elmiko | nevar! | 16:14 |
*** e0ne is now known as e0ne_ | 16:16 | |
*** alex_klimov has quit IRC | 16:16 | |
*** e0ne_ is now known as e0ne | 16:18 | |
*** Apoorva has joined #openstack-api | 16:18 | |
*** e0ne has quit IRC | 16:42 | |
*** notmars has quit IRC | 16:51 | |
*** lucasagomes is now known as lucas-dinner | 17:01 | |
*** notmars has joined #openstack-api | 17:37 | |
elmiko | notmyname: thanks for the comments, i'll rework that section. do you have any references to the 507 code? i'm not seeing it in the 2616 or 7231 rfcs | 17:50 |
notmyname | elmiko: http://www.iana.org/assignments/http-status-codes/http-status-codes.xhtml | 17:51 |
notmyname | it's from WebDAV | 17:51 |
*** e0ne has joined #openstack-api | 17:51 | |
notmyname | 507 InsufficientStorage turns out to be a really useful code in Swift ;-) | 17:51 |
elmiko | lol, i'll bet! | 17:52 |
elmiko | would you be amenable to me rewriting the 502-05 section to more generally advise that these are transport related codes and should only be used in those circumstances? | 17:52 |
elmiko | rather than just saying "must not..." | 17:53 |
notmyname | "transport-related" | 17:53 |
notmyname | hmm | 17:53 |
elmiko | is that too imprecise? | 17:54 |
notmyname | today in swift, a 503 should be interpreted by the client as "something broke, we can't guarantee any sort of state, client shoudl retry". it would normally be seen on a write when a quorum of responses wasn't made (eg 2 of the 3 drives failed halfway through the write) | 17:55 |
*** openstackgerrit has quit IRC | 17:56 | |
notmyname | ie it's definitely an issue on the server side. but it's not a "transport" error, at least how I'd think of transport | 17:56 |
elmiko | true, and the language for 503 in the rfc doesn't necessarily indicate transport specifically | 17:56 |
*** openstackgerrit has joined #openstack-api | 17:57 | |
elmiko | seems like 502 and 504 are transport specific, 503 is more general in terms of server side issue, and 505 is more well defined. | 17:58 |
elmiko | i'll try to get a little more specific and push a new change. thanks again for the advise | 17:59 |
elmiko | advice.. ;) | 18:00 |
*** agentle_ has quit IRC | 18:02 | |
elmiko | maybe that part isn't even needed. this seems like another "restating the rfc" type situations | 18:02 |
*** agentle_ has joined #openstack-api | 18:02 | |
elmiko | sigmavirus24, miguelgrinberg, any thoughts about providing guidance on 502-505(and greater) status codes? | 18:04 |
elmiko | stevelle, salv-orlando too ^^ | 18:05 |
salv-orlando | I believe we're providing already the best guidance: don't use them | 18:06 |
salv-orlando | but yes, we can find some actual examples explaining why they're not a good idea, and add them to the "rest mistakes" section sdague is pushing | 18:07 |
elmiko | well, except that's not entirely accurate. notmyname made some pretty clear examples of when they might be used, so we can say "in general they aren't needed" but there are cases where they are needed. | 18:07 |
elmiko | i like the idea of leaving them to the doc that sdague has been working through | 18:08 |
elmiko | but i just wonder if we should say anything about them in the general 5xx section? | 18:08 |
salv-orlando | elmiko: we might then add caveats for notmyname's remarks | 18:11 |
salv-orlando | like "you should never have a real necessity of using them, unless..." | 18:12 |
miguelgrinberg | elmiko: are there any usages of 502-505 in openstack code? | 18:12 |
elmiko | miguelgrinberg: good question, notmyname provided an example of 507 (but that's a little out of range if we are basing on rfc only) | 18:13 |
elmiko | miguelgrinberg: oh, yea he just mentioned a 503 in swift | 18:13 |
miguelgrinberg | because I think the risk of someone thinking using those codes is a good idea is pretty low | 18:14 |
notmyname | in one swift feature (bulk operations), you may get a 502 with certain errors. see http://docs.openstack.org/developer/swift/middleware.html#module-swift.common.middleware.bulk | 18:14 |
notmyname | and 503 is a general case in swift for errors | 18:14 |
salv-orlando | the thing is 503 explicitly used as an application error, or is it returned by the web container when things are wrong? | 18:14 |
*** e0ne is now known as e0ne_ | 18:17 | |
elmiko | good question, i could see it being either way though. it sounded like a situation could occur where swift doesn't know about sending the 503 until it sees that the write has failed across the drives. | 18:21 |
elmiko | that sounds like it could come from an application error detecting the bad write | 18:21 |
*** notmars has quit IRC | 18:23 | |
miguelgrinberg | I don't really find that distinction between server and application that useful. The status codes are meant to be consumed by the client, and to the client there is no server and app separation, the whole thing is a web server. So in my opinion, if that app has a good reason to send a 503 (like a hardware failure in this case) I don't see a problem | 18:23 |
miguelgrinberg | and let it be noted that here is a first time notmyname and I agree on something :) | 18:24 |
elmiko | yea, that makes sense to me | 18:24 |
elmiko | lol | 18:24 |
elmiko | i think the heart of the guidance here is not to use 500 for general errors, and to be careful when using 501 due to the caching nature. | 18:24 |
elmiko | it might be worthwhile to drop the 502-505 stuff | 18:25 |
miguelgrinberg | Probably something generic for all 5xx is enough. | 18:25 |
elmiko | i feel that amounts to us saying "read the rfcs and use the appropriate error" though | 18:26 |
*** e0ne_ is now known as e0ne | 18:26 | |
notmyname | miguelgrinberg: yay | 18:26 |
miguelgrinberg | elmiko: in my opinion the important bit is that 4xx errors are caused by the client, 5xx errors are not | 18:28 |
elmiko | miguelgrinberg: ok, good distinction | 18:29 |
miguelgrinberg | to the client this separation is important, as it knows when it is useless to keep trying | 18:29 |
*** stevelle_ has joined #openstack-api | 18:29 | |
*** dtroyer_zz has joined #openstack-api | 18:29 | |
*** sigmavirus24 has quit IRC | 18:30 | |
*** stevelle has quit IRC | 18:30 | |
*** dtroyer has quit IRC | 18:30 | |
*** sigmavirus24 has joined #openstack-api | 18:31 | |
salv-orlando | miguelgrinberg. notmyname: I see your point and it makes sense. I also think that usage a 503 from application code is compatible with RFC 7231 so it should be ok to use | 18:32 |
salv-orlando | where as that does not apply to 502, 504 and 505 | 18:33 |
notmyname | I'm with miguelgrinberg. the important part is 5xx = server error and 4xx = client error | 18:33 |
salv-orlando | and for 507... what's our position on webdav error codes? personally I don't see why we should not use them | 18:33 |
*** notmars has joined #openstack-api | 18:34 | |
miguelgrinberg | salv-orlando: right, the 502 504 and 505 errors would not make any sense for an application to issue unless it is a gateway or proxy server. Something like nginx would issue these errors, but not an openstack API | 18:34 |
elmiko | i'm so confused/frustrated by this at the moment. i'm thinking i should just trim the entire thing back to the bare minimum that miguelgrinberg is talking about. | 18:35 |
elmiko | miguelgrinberg: but what if you were writing some sort of gateway as a service and could detect that you were receiving bad responses from another server, wouldn't it be appropriate to explicitly send back a 502? | 18:36 |
miguelgrinberg | elmiko: if your application functions as a gateway then sure | 18:36 |
elmiko | and i think that's the point here, we don't know what folks will do so it's poor guidance to say "never do this..." | 18:37 |
miguelgrinberg | there is a difference between being a gateway and being a regular service that needs to send a request to another server as part of fulfilling a request | 18:37 |
elmiko | definitely | 18:38 |
miguelgrinberg | in the latter I would have to think carefully if a 5xx makes sense | 18:38 |
elmiko | but someone may be dreaming up the next aaS application that happens to act as a gateway and full integrates with the rest of openstack | 18:38 |
miguelgrinberg | absolutely | 18:38 |
miguelgrinberg | that's why the hard rule of never do this does not work for me | 18:38 |
elmiko | yea, i'm having trouble with it too | 18:39 |
elmiko | oh well, i'll take another run at this and maybe go with a more minimal approach | 18:39 |
openstackgerrit | Michael McCune proposed openstack/api-wg: Adding 5xx guidance https://review.openstack.org/183698 | 18:54 |
elmiko | ok, i've radically trimmed back the guidance | 18:55 |
*** openstackgerrit has quit IRC | 18:56 | |
*** openstackgerrit has joined #openstack-api | 18:56 | |
elmiko | miguelgrinberg, salv-orlando, notmyname, would love feedback on ^^ | 18:56 |
notmyname | elmiko: after lunch :-) | 18:57 |
notmyname | ah, it's short. looks great :-) | 18:58 |
elmiko | hehe, enjoy lunch =) | 18:58 |
miguelgrinberg | elmiko: works for me, I think it is a nice improvement over the previous patch | 18:59 |
elmiko | cool, thanks for taking a look | 19:00 |
* cdent has a sad | 19:07 | |
elmiko | cdent: you ok? | 19:07 |
cdent | your 5xx changes :) | 19:08 |
cdent | they give me weeps | 19:08 |
elmiko | lol | 19:08 |
cdent | not that they are incorrect or anything | 19:08 |
cdent | but that now they just satisfy the context, rather than providing a TeachingMomentâ„¢ | 19:08 |
cdent | which, yeah, it is up for debate whether that's what the group should be doing | 19:08 |
cdent | I just kind of think we should preface every guideline with "if you're writing a "normal" api thingie, this applies, if your swift, it does not" | 19:09 |
* cdent is not really serious | 19:09 | |
cdent | mostly | 19:09 |
elmiko | well, maybe we can add the teaching moment in later patches. i just felt like this topic seems too deep a well for this patch. | 19:10 |
elmiko | like, i kept coming up with exceptions for every 5xx code. i think it was getting too muddied | 19:10 |
cdent | fair | 19:10 |
cdent | it's good that the other versions are in the permanent record so we can go back and have a look | 19:11 |
cdent | sometimes the discussion surrounding these things feels more relevant than the eventual guideline | 19:11 |
elmiko | i'm really happy that folks were liking the other versions. i just didn't want to write a book on 5xx codes ;) | 19:12 |
elmiko | agreed | 19:12 |
cdent | I've written a comment that I hope adequately captures things | 19:15 |
*** notmars has quit IRC | 19:15 | |
elmiko | i do like the distinction in various type of REST applications, but i think we are going to need to build up the language and reference to make that distinction clear | 19:17 |
cdent | s/REST// | 19:17 |
cdent | ;) | 19:17 |
cdent | we don't do that here | 19:17 |
elmiko | fair | 19:17 |
* cdent is a big jerk | 19:17 | |
elmiko | haha | 19:17 |
elmiko | i think it's interesting to note the difference between looking at client/server interaction, and then breaking down the server side into various layers of application. | 19:18 |
elmiko | i find the distinction to be noteworthy | 19:19 |
cdent | A friend of mine is starting some new work on an API (private banking thing) that is being planned to be fully HATEOAS. I'm curious to find out how it turns out. | 19:19 |
elmiko | that should be interesting | 19:20 |
*** agentle__ has joined #openstack-api | 19:20 | |
cdent | I'm not personally a huge fan of HATEOAS. I like the conversational/grammar aspect of knowing the URIs | 19:21 |
elmiko | i think it's a cool idea, but i'd be really curious to get a closer look at an application using it | 19:23 |
elmiko | doesn't github use something like this on their api? | 19:23 |
*** agentle_ has quit IRC | 19:24 | |
cdent | I think they have some hypertextuality but I'm not aware of whether you can fully traverse it blindly | 19:24 |
elmiko | ok, i really should look at their docs in my oh-so-copious spare time ;) | 19:25 |
sigmavirus24 | sorry I just saw github mentioned | 19:25 |
* cdent remembers spare time, vaguely | 19:25 | |
sigmavirus24 | what're you looking for in their API? | 19:25 |
sigmavirus24 | https://api.github.com/ kind of gives you a listing of other URLs to traverse | 19:26 |
elmiko | oh, just curious if their api uses hateoas | 19:26 |
sigmavirus24 | And each endpoint's objects give you some notion of URLs you can use to explore | 19:26 |
sigmavirus24 | I think they consider it far more RESTful than an implementation of HATEOAS | 19:26 |
elmiko | neat | 19:26 |
*** agentle__ is now known as annegentle | 20:02 | |
ryansb | can confirm: it's quite nice to use | 20:11 |
elmiko | ryansb: did you write an app to do something github? | 20:14 |
ryansb | yeah, I had a script to handle github issues -> taskwarrior | 20:20 |
elmiko | cool | 20:20 |
ryansb | and a script to backup all of an organization's repos | 20:20 |
ryansb | nothing big, but enough to notice that their API is really fun to use | 20:21 |
sigmavirus24 | elmiko: https://github.com/sigmavirus24/github3.py | 20:22 |
sigmavirus24 | I second ryansb's notion that it's fun to use | 20:22 |
sigmavirus24 | It's terrible in terms of being "stable" though | 20:22 |
sigmavirus24 | They break it every 3 to 6 months | 20:22 |
elmiko | lol, nice | 20:22 |
sigmavirus24 | Not really | 20:23 |
elmiko | awww, but if i use your package then i miss out on all the fun ;) | 20:23 |
sigmavirus24 | github3.py tries to be fun to use | 20:27 |
*** cdent has quit IRC | 20:28 | |
*** lucas-dinner has quit IRC | 20:28 | |
*** e0ne has quit IRC | 20:28 | |
elmiko | ok, then i can accept that | 20:28 |
*** fzdarsky has quit IRC | 21:14 | |
*** notmars has joined #openstack-api | 21:32 | |
*** notmars has quit IRC | 21:58 | |
*** annegentle has quit IRC | 22:18 | |
*** sigmavirus24 is now known as sigmavirus24_awa | 23:01 | |
*** bitblt has joined #openstack-api | 23:31 |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!