Tuesday, 2015-07-14

*** Apoorva_ has quit IRC01:07
*** terrylhowe has quit IRC05:24
*** cdent has joined #openstack-api07:14
*** fzdarsky has joined #openstack-api07:25
*** alex_klimov has joined #openstack-api07:50
*** woodster_ has quit IRC07:51
*** alex_xu has quit IRC07:52
*** alex_xu has joined #openstack-api07:55
*** lucasagomes has joined #openstack-api08:06
*** e0ne has joined #openstack-api09:02
*** e0ne is now known as e0ne_09:12
*** e0ne_ is now known as e0ne09:16
*** e0ne is now known as e0ne_09:58
*** e0ne_ is now known as e0ne10:01
*** salv-orlando has quit IRC10:16
*** e0ne is now known as e0ne_10:45
*** e0ne_ is now known as e0ne10:49
*** openstackgerrit has quit IRC11:09
*** openstackgerrit has joined #openstack-api11:10
*** terrylhowe has joined #openstack-api11:15
*** alex_klimov has quit IRC11:21
*** alex_klimov has joined #openstack-api11:29
*** e0ne is now known as e0ne_11:39
*** e0ne_ is now known as e0ne11:41
*** lucasagomes is now known as lucas-hungry11:44
*** e0ne is now known as e0ne_11:56
*** e0ne_ is now known as e0ne11:59
*** salv-orlando has joined #openstack-api12:08
*** openstack has joined #openstack-api12:12
*** ig0r_ has joined #openstack-api12:24
*** annegent_ has quit IRC12:24
*** annegentle has joined #openstack-api12:25
*** lucas-hungry is now known as lucasagomes12:40
*** e0ne is now known as e0ne_12:42
*** e0ne_ is now known as e0ne12:47
*** e0ne is now known as e0ne_13:40
*** e0ne_ is now known as e0ne13:48
*** annegentle has quit IRC14:00
*** sigmavirus24_awa is now known as sigmavirus2414:01
*** woodster_ has joined #openstack-api14:20
openstackgerritMichael McCune proposed openstack/api-wg: Adding 5xx guidance  https://review.openstack.org/18369814:23
elmikonotmyname, salv-orlando, would be curious on your thoughts about the changes ^^14:27
*** agentle_ has joined #openstack-api14:28
salv-orlandoelmiko: sure!14:38
elmikosalv-orlando: thanks =)14:38
*** terrylhowe has left #openstack-api14:56
*** e0ne is now known as e0ne_14:56
*** e0ne_ is now known as e0ne14:59
*** alex_xu has quit IRC15:09
*** alex_xu has joined #openstack-api15:10
*** ig0r_ has quit IRC15:10
*** ig0r__ has joined #openstack-api15:11
*** ig0r_ has joined #openstack-api15:18
*** ig0r__ has quit IRC15:19
*** notmars has joined #openstack-api15:23
*** wuhao has joined #openstack-api15:35
*** haha has joined #openstack-api15:38
*** haha is now known as Guest7402515:39
*** Guest74025 has quit IRC15:39
*** ig0r__ has joined #openstack-api15:43
*** ig0r_ has quit IRC15:43
*** notmars has quit IRC15:46
*** e0ne is now known as e0ne_15:53
elmikosigmavirus24: got a response code/rfc question. is 422 part of http/1 but not 1.1?15:53
*** e0ne_ is now known as e0ne15:54
*** wuhao has quit IRC15:54
*** wuhao has joined #openstack-api15:54
sigmavirus24elmiko: I think it's part of neither to be honest15:55
sigmavirus24It's from the WebDAV RFC iirc but GitHub and other services use it anyway15:55
elmikook, maybe that's why i'm having trouble finding it15:56
sigmavirus24They like it15:56
sigmavirus24or maybe CalDAV15:56
sigmavirus24I forget which DAV15:56
sigmavirus24One of the DAVs15:56
elmikoi'm looking at https://review.openstack.org/#/c/19787115:56
elmikoand was curious about the mention of 42215:56
*** notmars has joined #openstack-api16:03
sigmavirus24That's not the reason string I've seen used for 42216:10
sigmavirus24I've seen Validation Failed16:10
sigmavirus24Anyway, for state conflicts, I agree 409 is the way the truth and the light16:11
sigmavirus24Nevermind16:11
sigmavirus24GitHub does use it as "Unprocessable Entity" ignore me16:12
elmikolol16:14
elmikonevar!16:14
*** e0ne is now known as e0ne_16:16
*** alex_klimov has quit IRC16:16
*** e0ne_ is now known as e0ne16:18
*** Apoorva has joined #openstack-api16:18
*** e0ne has quit IRC16:42
*** notmars has quit IRC16:51
*** lucasagomes is now known as lucas-dinner17:01
*** notmars has joined #openstack-api17:37
elmikonotmyname: 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 rfcs17:50
notmynameelmiko: http://www.iana.org/assignments/http-status-codes/http-status-codes.xhtml17:51
notmynameit's from WebDAV17:51
*** e0ne has joined #openstack-api17:51
notmyname507 InsufficientStorage turns out to be a really useful code in Swift ;-)17:51
elmikolol, i'll bet!17:52
elmikowould 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
elmikorather than just saying "must not..."17:53
notmyname"transport-related"17:53
notmynamehmm17:53
elmikois that too imprecise?17:54
notmynametoday 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 IRC17:56
notmynameie it's definitely an issue on the server side. but it's not a "transport" error, at least how I'd think of transport17:56
elmikotrue, and the language for 503 in the rfc doesn't necessarily indicate transport specifically17:56
*** openstackgerrit has joined #openstack-api17:57
elmikoseems 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
elmikoi'll try to get a little more specific and push a new change. thanks again for the advise17:59
elmikoadvice.. ;)18:00
*** agentle_ has quit IRC18:02
elmikomaybe that part isn't even needed. this seems like another "restating the rfc" type situations18:02
*** agentle_ has joined #openstack-api18:02
elmikosigmavirus24, miguelgrinberg, any thoughts about providing guidance on 502-505(and greater) status codes?18:04
elmikostevelle, salv-orlando too ^^18:05
salv-orlandoI believe we're providing already the best guidance: don't use them18:06
salv-orlandobut 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 pushing18:07
elmikowell, 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
elmikoi like the idea of leaving them to the doc that sdague has been working through18:08
elmikobut i just wonder if we should say anything about them in the general 5xx section?18:08
salv-orlandoelmiko: we might then add caveats for notmyname's remarks18:11
salv-orlandolike "you should never have a real necessity of using them, unless..."18:12
miguelgrinbergelmiko: are there any usages of 502-505 in openstack code?18:12
elmikomiguelgrinberg: 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
elmikomiguelgrinberg: oh, yea he just mentioned a 503 in swift18:13
miguelgrinbergbecause I think the risk of someone thinking using those codes is a good idea is pretty low18:14
notmynamein 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.bulk18:14
notmynameand 503 is a general case in swift for errors18:14
salv-orlandothe 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
elmikogood 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
elmikothat sounds like it could come from an application error detecting the bad write18:21
*** notmars has quit IRC18:23
miguelgrinbergI 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 problem18:23
miguelgrinbergand let it be noted that here is a first time notmyname and I agree on something :)18:24
elmikoyea, that makes sense to me18:24
elmikolol18:24
elmikoi 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
elmikoit might be worthwhile to drop the 502-505 stuff18:25
miguelgrinbergProbably something generic for all 5xx is enough.18:25
elmikoi feel that amounts to us saying "read the rfcs and use the appropriate error" though18:26
*** e0ne_ is now known as e0ne18:26
notmynamemiguelgrinberg: yay18:26
miguelgrinbergelmiko: in my opinion the important bit is that 4xx errors are caused by the client, 5xx errors are not18:28
elmikomiguelgrinberg: ok, good distinction18:29
miguelgrinbergto the client this separation is important, as it knows when it is useless to keep trying18:29
*** stevelle_ has joined #openstack-api18:29
*** dtroyer_zz has joined #openstack-api18:29
*** sigmavirus24 has quit IRC18:30
*** stevelle has quit IRC18:30
*** dtroyer has quit IRC18:30
*** sigmavirus24 has joined #openstack-api18:31
salv-orlandomiguelgrinberg. 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 use18:32
salv-orlandowhere as that does not apply to 502, 504 and 50518:33
notmynameI'm with miguelgrinberg. the important part is 5xx = server error and 4xx = client error18:33
salv-orlandoand for 507... what's our position on webdav error codes? personally I don't see why we should not use them18:33
*** notmars has joined #openstack-api18:34
miguelgrinbergsalv-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 API18:34
elmikoi'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
elmikomiguelgrinberg: 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
miguelgrinbergelmiko: if your application functions as a gateway then sure18:36
elmikoand 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
miguelgrinbergthere 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 request18:37
elmikodefinitely18:38
miguelgrinbergin the latter I would have to think carefully if a 5xx makes sense18:38
elmikobut someone may be dreaming up the next aaS application that happens to act as a gateway and full integrates with the rest of openstack18:38
miguelgrinbergabsolutely18:38
miguelgrinbergthat's why the hard rule of never do this does not work for me18:38
elmikoyea, i'm having trouble with it too18:39
elmikooh well, i'll take another run at this and maybe go with a more minimal approach18:39
openstackgerritMichael McCune proposed openstack/api-wg: Adding 5xx guidance  https://review.openstack.org/18369818:54
elmikook, i've radically trimmed back the guidance18:55
*** openstackgerrit has quit IRC18:56
*** openstackgerrit has joined #openstack-api18:56
elmikomiguelgrinberg, salv-orlando, notmyname, would love feedback on ^^18:56
notmynameelmiko: after lunch :-)18:57
notmynameah, it's short. looks great :-)18:58
elmikohehe, enjoy lunch =)18:58
miguelgrinbergelmiko: works for me, I think it is a nice improvement over the previous patch18:59
elmikocool, thanks for taking a look19:00
* cdent has a sad19:07
elmikocdent: you ok?19:07
cdentyour 5xx changes :)19:08
cdentthey give me weeps19:08
elmikolol19:08
cdentnot that they are incorrect or anything19:08
cdentbut that now they just satisfy the context, rather than providing a TeachingMomentâ„¢19:08
cdentwhich, yeah, it is up for debate whether that's what the group should be doing19:08
cdentI 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 serious19:09
cdentmostly19:09
elmikowell, 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
elmikolike, i kept coming up with exceptions for every 5xx code. i think it was getting too muddied19:10
cdentfair19:10
cdentit's good that the other versions are in the permanent record so we can go back and have a look19:11
cdentsometimes the discussion surrounding these things feels more relevant than the eventual guideline19:11
elmikoi'm really happy that folks were liking the other versions. i just didn't want to write a book on 5xx codes ;)19:12
elmikoagreed19:12
cdentI've written a comment that I hope adequately captures things19:15
*** notmars has quit IRC19:15
elmikoi 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 clear19:17
cdents/REST//19:17
cdent;)19:17
cdentwe don't do that here19:17
elmikofair19:17
* cdent is a big jerk19:17
elmikohaha19:17
elmikoi 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
elmikoi find the distinction to be noteworthy19:19
cdentA 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
elmikothat should be interesting19:20
*** agentle__ has joined #openstack-api19:20
cdentI'm not personally a huge fan of HATEOAS. I like the conversational/grammar aspect of knowing the URIs19:21
elmikoi think it's a cool idea, but i'd be really curious to get a closer look at an application using it19:23
elmikodoesn't github use something like this on their api?19:23
*** agentle_ has quit IRC19:24
cdentI think they have some hypertextuality but I'm not aware of whether you can fully traverse it blindly19:24
elmikook, i really should look at their docs in my oh-so-copious spare time ;)19:25
sigmavirus24sorry I just saw github mentioned19:25
* cdent remembers spare time, vaguely19:25
sigmavirus24what're you looking for in their API?19:25
sigmavirus24https://api.github.com/ kind of gives you a listing of other URLs to traverse19:26
elmikooh, just curious if their api uses hateoas19:26
sigmavirus24And each endpoint's objects give you some notion of URLs you can use to explore19:26
sigmavirus24I think they consider it far more RESTful than an implementation of HATEOAS19:26
elmikoneat19:26
*** agentle__ is now known as annegentle20:02
ryansbcan confirm: it's quite nice to use20:11
elmikoryansb: did you write an app to do something github?20:14
ryansbyeah, I had a script to handle github issues -> taskwarrior20:20
elmikocool20:20
ryansband a script to backup all of an organization's repos20:20
ryansbnothing big, but enough to notice that their API is really fun to use20:21
sigmavirus24elmiko: https://github.com/sigmavirus24/github3.py20:22
sigmavirus24I second ryansb's notion that it's fun to use20:22
sigmavirus24It's terrible in terms of being "stable" though20:22
sigmavirus24They break it every 3 to 6 months20:22
elmikolol, nice20:22
sigmavirus24Not really20:23
elmikoawww, but if i use your package then i miss out on all the fun ;)20:23
sigmavirus24github3.py tries to be fun to use20:27
*** cdent has quit IRC20:28
*** lucas-dinner has quit IRC20:28
*** e0ne has quit IRC20:28
elmikook, then i can accept that20:28
*** fzdarsky has quit IRC21:14
*** notmars has joined #openstack-api21:32
*** notmars has quit IRC21:58
*** annegentle has quit IRC22:18
*** sigmavirus24 is now known as sigmavirus24_awa23:01
*** bitblt has joined #openstack-api23:31

Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!