*** Apoorva has quit IRC | 00:17 | |
*** woodster_ has quit IRC | 02:01 | |
*** woodster_ has joined #openstack-api | 03:18 | |
*** subscope has joined #openstack-api | 06:50 | |
*** woodster_ has quit IRC | 06:51 | |
*** alex_klimov has joined #openstack-api | 07:00 | |
*** e0ne has joined #openstack-api | 07:04 | |
*** subscope has quit IRC | 07:05 | |
*** e0ne has quit IRC | 07:23 | |
*** subscope has joined #openstack-api | 07:30 | |
*** fzdarsky has joined #openstack-api | 07:39 | |
*** salv-orl_ has quit IRC | 07:40 | |
*** cdent has joined #openstack-api | 08:11 | |
*** lucas-dinner has joined #openstack-api | 08:28 | |
*** subscope has quit IRC | 08:32 | |
*** lucas-dinner is now known as lucasagomes | 08:33 | |
*** e0ne has joined #openstack-api | 08:48 | |
*** subscope has joined #openstack-api | 08:49 | |
*** e0ne is now known as e0ne_ | 08:58 | |
*** e0ne_ is now known as e0ne | 09:00 | |
*** e0ne is now known as e0ne_ | 09:57 | |
*** e0ne_ is now known as e0ne | 09:59 | |
*** salv-orlando has joined #openstack-api | 10:26 | |
*** salv-orl_ has joined #openstack-api | 10:29 | |
*** salv-orlando has quit IRC | 10:31 | |
*** e0ne is now known as e0ne_ | 10:50 | |
*** e0ne_ has quit IRC | 11:00 | |
*** fzdarsky has quit IRC | 11:05 | |
*** fzdarsky has joined #openstack-api | 11:08 | |
*** e0ne has joined #openstack-api | 11:36 | |
*** salv-orl_ has quit IRC | 12:11 | |
*** e0ne is now known as e0ne_ | 12:32 | |
*** e0ne_ is now known as e0ne | 12:39 | |
*** woodster_ has joined #openstack-api | 12:45 | |
*** fzdarsky has quit IRC | 12:46 | |
*** fzdarsky has joined #openstack-api | 12:49 | |
*** salv-orlando has joined #openstack-api | 13:07 | |
*** salv-orl_ has joined #openstack-api | 13:12 | |
*** salv-orlando has quit IRC | 13:15 | |
*** fifieldt_ is now known as fifieldt | 13:36 | |
*** elmiko has joined #openstack-api | 13:37 | |
*** sigmavirus24_awa is now known as sigmavirus24 | 13:57 | |
*** e0ne is now known as e0ne_ | 14:37 | |
*** e0ne_ is now known as e0ne | 14:37 | |
ryansb | elmiko: I'm going to miss today's meeting, but can you bring https://review.openstack.org/177468 up as a freeze candidate for me? | 14:56 |
---|---|---|
elmiko | ryansb: yes, adding it to agenda | 14:57 |
ryansb | awesome, thanks. I'm putting up a final set of tweaks (all small) and I think it'll be good to go | 14:58 |
elmiko | cool | 14:59 |
openstackgerrit | Ryan Brown proposed openstack/api-wg: Add section on filtering https://review.openstack.org/177468 | 15:04 |
*** e0ne has quit IRC | 15:04 | |
*** subscope has quit IRC | 15:11 | |
*** subscope has joined #openstack-api | 15:26 | |
cdent | ryansb: yeah, wasn't trying to suggest that changes-since be part of filtering, just trying to get some sense on where (or if) if should exist at all | 15:46 |
sdague | what's the process to get this stack into some final voting state - https://review.openstack.org/#/c/181931/ | 15:51 |
sdague | so it's not hanging out in my outgoing queue for ever | 15:51 |
ekarlso | any ideas guys on when the error guidelines will land ? | 15:51 |
etoews | elmiko: will you be kicking off the meeting in 5 minutes? i'll be there but i'm still in catchup mode. | 15:55 |
elmiko | etoews: sure, i can do it | 15:55 |
elmiko | sdague: i'll add it to the agenda to talk about moving to freeze | 15:55 |
elmiko | ekarlso: i thought there was still discussion about the error guideline? (i don't have the link ready) | 15:56 |
etoews | elmiko: oops i just did that | 15:56 |
elmiko | etoews: no worries =) | 15:57 |
etoews | ekarlso: that one is mine. it's been dependent on some work in the logging work group and elsewhere so the going has been slow. | 15:57 |
etoews | ekarlso: i'd be very interested to hear your use case. | 15:57 |
etoews | it's probably time to unjam it and just forge ahead. | 15:58 |
ekarlso | etoews: new project and just wanting to land errors corerctly from start vs 1-2 cycles :P | 15:58 |
etoews | excellent that sounds like a good use case :) | 15:59 |
elmiko | +1 | 15:59 |
etoews | ekarlso: do you have any feedback on the current proposed structure of the errors? does it work for your new project? | 16:00 |
ekarlso | etoews: I haven't added it yet ;) | 16:00 |
ekarlso | hence why I wonder if it's landed :D | 16:00 |
*** jamie_h has joined #openstack-api | 16:05 | |
*** alex_klimov has quit IRC | 16:07 | |
*** openstackgerrit has quit IRC | 16:22 | |
*** openstackgerrit has joined #openstack-api | 16:23 | |
openstackgerrit | Steve Lewis proposed openstack/api-wg: Add section on filtering https://review.openstack.org/177468 | 16:46 |
openstackgerrit | Jay Pipes proposed openstack/api-wg: Add guidance on 500 Internal Server Error https://review.openstack.org/179365 | 16:47 |
*** lucasagomes has quit IRC | 16:55 | |
*** Apoorva has joined #openstack-api | 16:58 | |
etoews | sdague: are you using any of the python libs to hit the gerrit api? | 17:01 |
sdague | honestly, I often just use the ssh api either ad-hoc or in shell | 17:02 |
sdague | there is gerritlib in openstack-infra, it's thin enough wrapper it's often just as easy to do it yourself | 17:02 |
sdague | I haven't bother to convert to the rest api yet | 17:03 |
etoews | i wasn't aware of the "ssh api" | 17:03 |
sdague | yeh, that's how you submit code today | 17:03 |
sdague | git-review just hides a bunch of that from you | 17:04 |
etoews | ah. are we talking about this https://review.openstack.org/Documentation/cmd-index.html ? | 17:04 |
sdague | etoews: yep | 17:04 |
openstackgerrit | Merged openstack/api-wg: Update the merge process for Liberty https://review.openstack.org/186836 | 17:07 |
sdague | https://review.openstack.org/Documentation/cmd-query.html is what you are more or less looking for I expect | 17:07 |
sdague | at least if you are driving automation off things | 17:08 |
sdague | there is also the gerrit-dash-creator if it's just about finding things easily via browser | 17:08 |
sdague | https://github.com/stackforge/gerrit-dash-creator | 17:08 |
elmiko | is there some guidance around partial creation of a collection? (i'm not seeing it immediately) | 17:11 |
etoews | got it. i was able to do an ls-projects so auth is okay. i'll dig into query and dash creator and see if they can do what we need. | 17:12 |
etoews | sdague: thx! | 17:12 |
*** cdent has quit IRC | 17:17 | |
elmiko | so, we've got a question about creating a series of resources in sahara that might fail part way through due to quota. is there something in nova like this that we might use as guidance? | 17:18 |
stevelle | elmiko: this sounds vaguely familiar https://bugs.launchpad.net/nova/+bug/1458122 | 17:21 |
openstack | Launchpad bug 1458122 in OpenStack Compute (nova) "nova shouldn't error if we can't schedule all of max_count instances at boot time" [Wishlist,Confirmed] - Assigned to Chris Friesen (cbf123) | 17:21 |
*** cdent has joined #openstack-api | 17:21 | |
sdague | stevelle: sort of | 17:21 |
sdague | but not really | 17:21 |
sdague | elmiko: is this a blocking call/ | 17:22 |
sdague | ? | 17:22 |
elmiko | no | 17:22 |
elmiko | it's during a cluster creation operation | 17:22 |
elmiko | we are proposing a method for batch creating clusters, and i think it will be ok if some get created | 17:22 |
sdague | so, the idea that nova never got to yet here was a tasks api | 17:22 |
elmiko | but the user might request something that goes beyond their quota | 17:22 |
sdague | do the create, get back a tasks id, and you can get status on the task as a set of ops that need to happen | 17:23 |
sdague | and if it fails some time later the task goes to error, explains why, and things are rolled back | 17:23 |
elmiko | i really like that solution, unfortunately i am proposing tasks for our v2 api, which won't get in until M at the soonest | 17:24 |
*** cdent has quit IRC | 17:24 | |
*** openstackgerrit has quit IRC | 17:50 | |
*** openstackgerrit has joined #openstack-api | 17:51 | |
*** first123 has joined #openstack-api | 17:56 | |
*** first123 has quit IRC | 18:03 | |
*** first123 has joined #openstack-api | 18:03 | |
*** fzdarsky has quit IRC | 18:03 | |
*** first123 has quit IRC | 18:04 | |
*** cdent has joined #openstack-api | 18:14 | |
*** jamie_h has quit IRC | 18:19 | |
*** elmiko has quit IRC | 18:27 | |
*** elmiko has joined #openstack-api | 18:29 | |
*** cdent has quit IRC | 18:55 | |
*** first123 has joined #openstack-api | 18:58 | |
*** first123 has quit IRC | 18:58 | |
*** alex_klimov has joined #openstack-api | 19:37 | |
*** alex_klimov has quit IRC | 20:33 | |
*** alex_klimov has joined #openstack-api | 20:35 | |
*** elmiko is now known as _elmiko | 20:46 | |
*** etoews has quit IRC | 20:53 | |
*** e0ne has joined #openstack-api | 20:59 | |
*** etoews has joined #openstack-api | 21:13 | |
*** _elmiko is now known as elmiko | 21:23 | |
etoews | sigmavirus24: i'm looking at the guidance on https://review.openstack.org/#/c/183694/ | 21:33 |
etoews | and i'm reading up a bit on 1xx in http/2 https://http2.github.io/http2-spec/#HTTPLayer | 21:33 |
etoews | everything i'm reading says that 1xx will still be http/2 | 21:34 |
etoews | they even have examples at the end of https://http2.github.io/http2-spec/#rfc.section.8.1.3 | 21:34 |
sigmavirus24 | Looks as if they added it back then | 21:34 |
sigmavirus24 | It had been ripped outo | 21:35 |
elmiko | notmyname, has a good point. maybe we should make the guidance less stern, but still conservative? | 21:36 |
sigmavirus24 | etoews: https://github.com/http2/http2-spec/issues/535 | 21:38 |
notmyname | hello | 21:38 |
etoews | i'm a bit surprised glance doesn't use 100 for uploading images | 21:38 |
sigmavirus24 | etoews: I'll be surprised if webob even supports 100 continue | 21:38 |
sigmavirus24 | (we also don't support Range requests) | 21:38 |
sigmavirus24 | (because we're awful people who haven't finished refactoring glance_store) | 21:39 |
elmiko | notmyname: hey, just saw the convo and was trying to assess how to adjust the 1xx advice | 21:40 |
notmyname | 100 continue is nice. despite client support, it's part of the rfc and should be available when it's appropriate | 21:42 |
notmyname | similar to multi-range requests (requests with more than one range in them) | 21:42 |
elmiko | i don't have an issue with that, it seemed like we should advise conservatively though. like you said, only use when appropriate. | 21:42 |
notmyname | interesting http://bugs.python.org/issue1346874 | 21:43 |
sigmavirus24 | notmyname: yeah I'm surprised you didn't already know that | 21:43 |
sigmavirus24 | That's why, until requests reimplements httplib, we can't meaningfully support it | 21:44 |
sigmavirus24 | And yes | 21:44 |
sigmavirus24 | We're working on 86'ing httplib | 21:44 |
notmyname | well, i'm aware that requests doesn't support it (swiftclient lost that feature when we ported to requests for other reasons) | 21:44 |
lifeless | huh | 21:47 |
lifeless | 100 is cone | 21:47 |
lifeless | *gone* | 21:47 |
lifeless | support for 1xx remains | 21:47 |
notmyname | in swift, we support 100 continue with some code in an HTTPConnection wrapper we have | 21:47 |
lifeless | but 100 and 101 are not in HTTP/2 last I heard | 21:47 |
lifeless | hmm, 101 is definitely gone | 21:48 |
lifeless | http://http2.github.io/http2-spec/index.html#informational-responses | 21:48 |
lifeless | tracking down what the outcome of 100 was | 21:48 |
notmyname | ok, but despite what's in http/2, we don't actually support http/2. we support http/1 or 1.1 | 21:50 |
lifeless | sure | 21:50 |
lifeless | 1.0 doesn't have 100 | 21:50 |
lifeless | but you know that :) | 21:51 |
etoews | lifeless: from https://http2.github.io/http2-spec/#HTTPLayer and https://http2.github.io/http2-spec/#rfc.section.8.1.3 (at the end) it seems to me 100 is still there. | 21:54 |
lifeless | etoews: yes, I concur | 21:55 |
lifeless | etoews: there's just no value to it except for h1to2 gateways | 21:55 |
lifeless | anyhow, I have a much more pressing problem with the API advice - Its not RFC conformant | 21:55 |
lifeless | there, chapter and verse quoted. | 21:58 |
elmiko | sigmavirus24, etoews, so... was there ever any consensus? should i respin with some language about use 100 if you must but be aware of these issues (with references)? | 22:13 |
elmiko | notmyname, lifeless ^^ | 22:13 |
sigmavirus24 | elmiko: sounds good to me | 22:14 |
etoews | ++ | 22:14 |
lifeless | elmiko: references would be a good start | 22:14 |
lifeless | elmiko: I presume the driver was some client somewhere that got confused by a 100? | 22:14 |
lifeless | or someone did the common misdeploy I've seen | 22:15 |
elmiko | notmyname made a comment on the review, and it is a good point | 22:15 |
elmiko | etoews and sigmavirus24 pulled out a bunch of good details too | 22:15 |
lifeless | where you have client -> 1.0 -> accelerator -> 1.1 -> origin, which sends a 100, and the accelerator is buggy and doesn't strip it out ? | 22:15 |
sigmavirus24 | so | 22:15 |
notmyname | lifeless raises a good point. what is the motivation for writing this guidance down? | 22:15 |
sigmavirus24 | I don't see where webob supports sending a 100 partial response | 22:16 |
lifeless | sigmavirus24: WSGI is rather terrible in this space | 22:16 |
sigmavirus24 | lifeless: are we ever going to revive the work to redo wsgi for http/2 support? | 22:16 |
elmiko | notmyname, lifeless, i'd have to dig up the conversations. but essentially we wanted to provide guidance on all the reponse status codes. | 22:16 |
lifeless | sigmavirus24: but thats a separate discussion: - the gateway in this case - e.g. apache2 - has to send it | 22:16 |
sigmavirus24 | Or did PJ and Graham sufficiently kill this? | 22:17 |
elmiko | i took a stab at the 1xx series based on the rfc language, and the conversation | 22:17 |
elmiko | (if i understand your question) | 22:17 |
* notmyname looks forward to guidance on 418 | 22:17 | |
lifeless | elmiko: so, I think thats a great goal, but lets make sure the guidance is RFC conformant | 22:17 |
lifeless | sigmavirus24: yes, we are totally. | 22:17 |
lifeless | sigmavirus24: it got interrupted when I had a death in the family | 22:17 |
* sigmavirus24 wonders if you realize that you added me as an admin on that list | 22:17 | |
elmiko | lifeless: ack, i'll take another pass and pay more mind to the documentation. | 22:17 |
sigmavirus24 | lifeless: right, I forgot about that. I'm sorry. =( | 22:18 |
lifeless | sigmavirus24: and coming back to it I realised we had to fix the openstack velocity issues vis-a-vis gate reliability before I could wander off into upstream land again | 22:18 |
lifeless | sigmavirus24: I do :). lukasa too IIRC | 22:18 |
lifeless | I'm very open with admin there | 22:18 |
lifeless | sigmavirus24: graham was pretty positive actually | 22:19 |
sigmavirus24 | Yeah he was mostly | 22:20 |
lifeless | sigmavirus24: I'm hoping to have a chat f2f @ pyconau | 22:20 |
sigmavirus24 | :D | 22:20 |
lifeless | we had a few skypes | 22:20 |
sigmavirus24 | Have you met lukasa yet? | 22:20 |
lifeless | yes | 22:20 |
lifeless | in paris | 22:20 |
sigmavirus24 | Ah cool | 22:20 |
lifeless | I was in a hangout with him this morning even :) | 22:20 |
*** e0ne has quit IRC | 22:31 | |
*** elmiko is now known as _elmiko | 22:35 | |
*** sigmavirus24 is now known as sigmavirus24_awa | 22:44 | |
*** openstackgerrit has quit IRC | 22:55 | |
*** alex_klimov has quit IRC | 22:58 | |
*** openstackgerrit has joined #openstack-api | 23:06 | |
openstackgerrit | Everett Toews proposed openstack/api-wg: Minor fixes to the process https://review.openstack.org/193366 | 23:38 |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!