| *** salv-orlando has joined #openstack-api | 00:31 | |
| *** salv-orlando has quit IRC | 00:33 | |
| *** sigmavirus24 is now known as sigmavirus24_awa | 00:41 | |
| *** annegentle has joined #openstack-api | 00:45 | |
| *** annegentle has quit IRC | 01:03 | |
| *** Apoorva has quit IRC | 02:13 | |
| *** Apoorva has joined #openstack-api | 02:20 | |
| *** Apoorva has quit IRC | 02:24 | |
| *** kaufer has joined #openstack-api | 02:53 | |
| *** kaufer has quit IRC | 03:37 | |
| *** salv-orlando has joined #openstack-api | 03:45 | |
| *** salv-orlando has quit IRC | 03:47 | |
| *** alex_klimov has joined #openstack-api | 06:11 | |
| *** salv-orlando has joined #openstack-api | 06:30 | |
| *** e0ne has joined #openstack-api | 06:42 | |
| *** e0ne has quit IRC | 06:49 | |
| *** woodster_ has quit IRC | 06:50 | |
| *** etoews has quit IRC | 07:50 | |
| *** alex_klimov has quit IRC | 08:14 | |
| *** fzdarsky has joined #openstack-api | 08:19 | |
| *** alex_klimov has joined #openstack-api | 08:37 | |
| *** alex_klimov has quit IRC | 09:30 | |
| *** alex_klimov has joined #openstack-api | 09:35 | |
| *** alex_klimov has quit IRC | 10:25 | |
| *** kaufer has joined #openstack-api | 11:45 | |
| *** alex_klimov has joined #openstack-api | 11:56 | |
| *** woodster_ has joined #openstack-api | 12:50 | |
| openstackgerrit | Ryan Brown proposed openstack/api-wg: Add section on filtering https://review.openstack.org/177468 | 12:54 |
|---|---|---|
| *** alex_klimov has quit IRC | 12:57 | |
| openstackgerrit | Ryan Brown proposed openstack/api-wg: Add new guideline for HTTP Headers https://review.openstack.org/186526 | 13:00 |
| *** sigmavirus24_awa is now known as sigmavirus24 | 13:01 | |
| *** kaufer has quit IRC | 13:15 | |
| *** alex_klimov has joined #openstack-api | 13:18 | |
| *** annegentle has joined #openstack-api | 13:29 | |
| *** kaufer has joined #openstack-api | 13:30 | |
| *** subscope has quit IRC | 13:35 | |
| elmiko | annegentle: hey, i'm looking at https://wiki.openstack.org/wiki/CrossProjectLiaisons#API_Working_Group | 13:44 |
| elmiko | i thought we editted that page? | 13:44 |
| *** annegent_ has joined #openstack-api | 13:44 | |
| *** annegentle has quit IRC | 13:45 | |
| *** subscope has joined #openstack-api | 13:52 | |
| *** annegent_ has quit IRC | 13:57 | |
| *** alex_klimov has quit IRC | 14:05 | |
| *** etoews_ has joined #openstack-api | 14:05 | |
| *** sigmavirus24 is now known as sigmavirus24_awa | 14:06 | |
| *** etoews_ is now known as etoews | 14:07 | |
| *** annegentle has joined #openstack-api | 14:10 | |
| *** salv-orlando has quit IRC | 14:12 | |
| *** subscope has quit IRC | 14:15 | |
| *** sigmavirus24_awa is now known as sigmavirus24 | 14:25 | |
| *** alex_klimov has joined #openstack-api | 14:30 | |
| *** subscope has joined #openstack-api | 14:31 | |
| *** kaufer1 has joined #openstack-api | 14:39 | |
| *** kaufer has quit IRC | 14:41 | |
| *** notmars has joined #openstack-api | 14:51 | |
| *** annegentle has quit IRC | 14:59 | |
| *** salv-orlando has joined #openstack-api | 15:13 | |
| *** salv-orlando has quit IRC | 15:22 | |
| *** annegentle has joined #openstack-api | 15:30 | |
| *** subscope has quit IRC | 15:35 | |
| *** annegentle has quit IRC | 15:42 | |
| *** alex_klimov has quit IRC | 15:42 | |
| *** annegentle has joined #openstack-api | 15:43 | |
| *** fzdarsky has quit IRC | 15:52 | |
| etoews | heyo elmiko | 15:53 |
| elmiko | yo | 15:54 |
| etoews | i've got a very pressing deadline on june 9. i'm effectively heads down until june 15. do you mind taking the reigns on meetings and getting stuff merged over the next couple of weeks? | 15:54 |
| elmiko | not at all, i can jump in =) | 15:55 |
| etoews | thank you. that's a huge help. | 15:55 |
| etoews | first i'll throw the merging process up for review. | 15:55 |
| elmiko | hopefully i'll be able to round up a few more CPLs over the next few weeks as well | 15:55 |
| elmiko | cool | 15:55 |
| etoews | that would be good. can you attend the cross-project meeting on tuesday at 4 pm cst? | 15:56 |
| elmiko | let me check | 15:56 |
| elmiko | yea, that's free for me | 15:57 |
| etoews | cool. let me get the merge process out there and then we can discuss. | 15:57 |
| elmiko | awesome, i think if we start emphasizing the 1-week freeze for larger patches it will help as well | 15:58 |
| elmiko | do you have a link for the cross-project meetings? | 15:59 |
| elmiko | oh wait, think i found it | 15:59 |
| *** kaufer has joined #openstack-api | 16:00 | |
| *** annegentle has quit IRC | 16:01 | |
| *** kaufer2 has joined #openstack-api | 16:02 | |
| *** kaufer1 has quit IRC | 16:02 | |
| *** kaufer has quit IRC | 16:04 | |
| elmiko | etoews: oops, i spoke too soon about one of the meetings. i'll be on a flight for the jun10 meeting, so we need a backup-backup for that one ;) | 16:04 |
| elmiko | presumambly i could join once we take off, but it leaves at 8pm.. which is start time for me | 16:05 |
| etoews | it's the 00:00 utc one so, if we can't find somebody, i think it's okay to cancel. | 16:06 |
| etoews | https://wiki.openstack.org/wiki/Meetings/CrossProjectMeeting | 16:06 |
| elmiko | ok cool, that looks like my only conflict | 16:09 |
| *** notmars has quit IRC | 16:09 | |
| *** sigmavirus24 is now known as sigmavirus24_awa | 16:18 | |
| *** jxstanford has joined #openstack-api | 16:25 | |
| *** sigmavirus24_awa is now known as sigmavirus24 | 16:28 | |
| *** sigmavirus24 is now known as sigmavirus24_awa | 16:43 | |
| openstackgerrit | Everett Toews proposed openstack/api-wg: Update the merge process for Liberty https://review.openstack.org/186836 | 16:50 |
| etoews | elmiko: ^^^ | 16:52 |
| elmiko | ack | 16:53 |
| etoews | i'm sure that will get kicked around a lot but i think we can follow that for the time being even though it's a WIP | 16:53 |
| elmiko | cool, giving it a read through now | 16:53 |
| etoews | elmiko: i've added that review to the cross project meeting agenda https://wiki.openstack.org/wiki/Meetings/CrossProjectMeeting#Proposed_agenda | 16:55 |
| elmiko | etoews: awesome, thanks | 16:56 |
| etoews | elmi | 16:56 |
| etoews | :( | 16:56 |
| etoews | elmiko: no. thank you. | 16:56 |
| elmiko | hehe, this looks pretty reasonable to me | 16:57 |
| etoews | okay. i'm going to go dark for a couple of weeks starting now. | 16:57 |
| elmiko | good luck, we'll see you soon ;) | 16:57 |
| ryansb | etoews: make sure you clear your -2's ;) | 16:57 |
| *** notmars has joined #openstack-api | 16:58 | |
| *** krotscheck has joined #openstack-api | 16:59 | |
| *** Apoorva has joined #openstack-api | 16:59 | |
| etoews | ryansb: good point. i checked and it doesn't look like i have any. i guess i'm just not that negative. :) | 17:00 |
| ryansb | an optimist, indeed | 17:00 |
| etoews | i'll be dark but still around. ping me if necessary. | 17:00 |
| elmiko | etoews: if anything comes up on that merge guidelines review will you mind if i update and repush? | 17:00 |
| etoews | elmiko: not at all | 17:00 |
| elmiko | k, thanks | 17:01 |
| *** salv-orlando has joined #openstack-api | 17:04 | |
| *** salv-orlando has quit IRC | 17:10 | |
| *** sigmavirus24_awa is now known as sigmavirus24 | 17:26 | |
| krotscheck | Hey, where's the conversation on Caching guidelines at right now? Is there a spec somewhere I can look at? | 17:27 |
| elmiko | krotscheck: is https://review.openstack.org/#/c/185288/ that the one you are thinking of? | 17:28 |
| elmiko | https://review.openstack.org/#/c/183523/ that too, i guess =) | 17:29 |
| krotscheck | elmiko: Ah, that second one :) | 17:30 |
| krotscheck | Thanks! | 17:30 |
| elmiko | np, thanks for taking a look | 17:30 |
| krotscheck | Hrm, that entire piece is not that specific. | 17:31 |
| elmiko | are you thinking about something along the lines that miguelgrinberg mentioned, in terms of providing more specific advice? | 17:32 |
| * krotscheck wonders if adding middleware to start offloading some of the cache header bits would make sense. etags, if-modified-since, if-none-match, etc. | 17:32 | |
| krotscheck | Basically, yeah. | 17:32 |
| elmiko | good question | 17:32 |
| miguelgrinberg | Hi krotscheck | 17:33 |
| krotscheck | miguelgrinberg: hey there! | 17:33 |
| miguelgrinberg | I think we should create a middleware to add conservative caching headers | 17:33 |
| krotscheck | I think we should create a middleware that adds accurate caching headers :) | 17:33 |
| krotscheck | (Which might be conservative) | 17:34 |
| elmiko | sounds cool to me | 17:34 |
| miguelgrinberg | krotscheck: well, what I'm thinking is that for APIs that don't care, there's a safety net that does the right thing, for APIs that care, they should do the right thing | 17:34 |
| miguelgrinberg | if you don't care about caching, then the right thing is to disable it, that is more or less what you get when you work with a non-browser client | 17:34 |
| krotscheck | And we can make it easier. | 17:35 |
| miguelgrinberg | I mean, it would be great that we think about the right caching level for each response, but having a baseline would be a good idea | 17:35 |
| miguelgrinberg | I mean to bring up the topic of caching at the next meeting | 17:36 |
| miguelgrinberg | API-WG meeting | 17:36 |
| elmiko | +1 | 17:37 |
| elmiko | sa far as the guideline goes, we might be best to start with the informational stance proposed and then build up specific advice | 17:37 |
| krotscheck | Well, we have an advantage in that oslo's db abstraction has codified the created_at and modified_at field into the resources that are served by our API's, and an awful lot of caching logic can be triggered off of that. | 17:37 |
| elmiko | especially if we are proposing new middleware | 17:38 |
| krotscheck | That will give us things like if-modified-since handling. | 17:38 |
| elmiko | back later, gtg | 17:38 |
| miguelgrinberg | krotscheck: haven't considered the created_at/updated_at, I like that | 17:39 |
| krotscheck | Right. | 17:39 |
| krotscheck | So from my read of the various headers, there's three ways to bust the cache. | 17:39 |
| miguelgrinberg | etags can also be generated in a middleware, MD5 of the JSON body | 17:39 |
| krotscheck | The first is the Cache-Expires header, which is a duration. | 17:39 |
| krotscheck | The second is etags. | 17:39 |
| krotscheck | As you mentioned. | 17:39 |
| krotscheck | And that gives us if-none-matches or if-in-range support | 17:40 |
| miguelgrinberg | right | 17:40 |
| krotscheck | The third is what I just mentioned, the if-modified-since handling. | 17:40 |
| krotscheck | And... well, it seems to me that if you want to do real sane cache invalidation, you'll want to do etags and/or date _anyway_. | 17:40 |
| krotscheck | So the guideline could, rather easily, just say: "Hey, don't use cache-expiry at all" | 17:41 |
| krotscheck | "There's better things" | 17:41 |
| krotscheck | So naive clients always get the freshest. | 17:41 |
| krotscheck | And intelligent clients can talk intelligently. | 17:41 |
| miguelgrinberg | yes, that's reasonable | 17:42 |
| krotscheck | Cooolio. | 17:43 |
| krotscheck | Do you want to write a spec for the middleware, or shall I/ | 17:43 |
| miguelgrinberg | I was planning to write one after seeing how others feel about it. Sounds like we had a discussion, so I'll go ahead and write one. | 17:44 |
| krotscheck | Alrightey! | 17:44 |
| krotscheck | I have an interview to do, back in an hour. | 17:44 |
| miguelgrinberg | thanks! | 17:44 |
| *** annegentle has joined #openstack-api | 17:45 | |
| *** annegentle has quit IRC | 18:08 | |
| *** annegentle has joined #openstack-api | 18:09 | |
| *** jxstanford has quit IRC | 18:22 | |
| *** annegentle has quit IRC | 18:41 | |
| *** salv-orlando has joined #openstack-api | 19:14 | |
| krotscheck | Ok, back! | 19:15 |
| elmiko | wb | 19:16 |
| krotscheck | miguelgrinberg: Any issue with me having a quick technical discussion with the oslo people about a potential cache supporting middleware? | 19:18 |
| *** salv-orlando has quit IRC | 19:21 | |
| *** salv-orlando has joined #openstack-api | 19:38 | |
| *** salv-orlando has quit IRC | 19:41 | |
| *** openstack has joined #openstack-api | 20:05 | |
| miguelgrinberg | krotscheck: not at all, we don't have a solution without a middleware in my opinion | 20:06 |
| krotscheck | Coolio | 20:07 |
| miguelgrinberg | I tried to find an example implementation but it appears there isn't one. I have done this for Flask, but not as a middleware. | 20:07 |
| *** Apoorva has joined #openstack-api | 20:22 | |
| *** sigmavirus24 is now known as sigmavirus24_awa | 20:23 | |
| *** openstack has joined #openstack-api | 20:30 | |
| *** annegentle has joined #openstack-api | 20:42 | |
| *** alex_klimov has joined #openstack-api | 20:49 | |
| *** openstackgerrit has quit IRC | 20:59 | |
| *** openstackgerrit has joined #openstack-api | 21:00 | |
| *** sigmavirus24_awa is now known as sigmavirus24 | 21:14 | |
| *** annegentle has quit IRC | 21:17 | |
| *** salv-orlando has joined #openstack-api | 21:26 | |
| *** openstack has joined #openstack-api | 21:31 | |
| *** notmars has quit IRC | 21:35 | |
| *** salv-orlando has quit IRC | 21:40 | |
| *** annegentle has joined #openstack-api | 21:46 | |
| *** salv-orlando has joined #openstack-api | 21:52 | |
| *** kaufer2 has quit IRC | 22:02 | |
| *** annegentle has quit IRC | 22:18 | |
| *** annegentle has joined #openstack-api | 22:20 | |
| *** annegentle has quit IRC | 22:40 | |
| woodster_ | I was curious if folks here had thoughts on PATCH-ing approaches, such at using JSON pointers: http://williamdurand.fr/2014/02/14/please-do-not-patch-like-an-idiot/ | 22:40 |
| elmiko | i don't think we've created guidelines for PATCH yet, i'd have to double check though | 22:41 |
| woodster_ | elmiko: there are none here anyway: https://github.com/openstack/api-wg/blob/master/guidelines/http.rst | 22:42 |
| elmiko | yea, that's what i was thinking about | 22:42 |
| elmiko | we would happily accept something if you have some thoughts about it =) | 22:42 |
| woodster_ | elmiko: keystone does patching the way I'm used to, with json fragments. But it doesn't allow for removing elements in a resource like JSON pointer does | 22:43 |
| elmiko | hmm | 22:43 |
| elmiko | miguelgrinberg: any thoughts ^^ | 22:43 |
| woodster_ | This RFC has a few examples in it: https://tools.ietf.org/html/rfc6902 (that that blog link above is based on): https://tools.ietf.org/html/rfc6902 | 22:43 |
| elmiko | interesting... i'm adding these to the reading list | 22:44 |
| miguelgrinberg | I was chatting with ryansb at the summit about another patch spec, I think it is called JSON-PATCH | 22:44 |
| miguelgrinberg | yes, this is the RFC: https://tools.ietf.org/html/rfc6902 | 22:45 |
| miguelgrinberg | oh wait, same one :-) | 22:45 |
| elmiko | hehe | 22:45 |
| elmiko | woodster_: is barbican running into a situation where PATCH is needed? | 22:45 |
| woodster_ | elmiko: It is...in a spec to support adding/removing users from an access control list, and also as a means to update the secrets grouped in a container in a spec I'm looking at now | 22:47 |
| woodster_ | miguelgrinberg: would you say 6902 is looking promising to consider for patching? | 22:47 |
| miguelgrinberg | woodster_: not familiar with the API, but adding/removing from a collection does not need patch. Could you expose this userlist as a collection and avoid patch altogether? | 22:48 |
| woodster_ | elmiko: yeah, the atomicity of the updates is very appealing | 22:48 |
| elmiko | woodster_: yea, this article seems pretty reasonable so far | 22:48 |
| miguelgrinberg | woodster_: I personally find the whole idea of PATCH too complicated. For example, how does the server report an error? the client would probably want to know which of the operations in the PATCH body failed, so this gets very complex. | 22:49 |
| woodster_ | miguelgrinberg: well, I'd expect that if anything is in error, nothing get committed...i.e. it should be in a single transaction in the datastore sense | 22:50 |
| miguelgrinberg | I don't oppose the use of PATCH, but I only see it as beneficial when the representations are prohibitively large, else it is easier to use PUT and send the whole thing | 22:50 |
| miguelgrinberg | woodster_: yes, nothing will change, that's for sure. But it is hard to report where the error was. | 22:51 |
| woodster_ | miguelgrinberg: that's true. The ACL add/remove user was raised in the context of multiple Heat engines potentially modifying resource simultaneously leading to potential race conditions. But this is probably a sign that orchestration is not designed so well | 22:52 |
| miguelgrinberg | woodster_: I'd like to understand this thing about heat better. | 22:53 |
| miguelgrinberg | so this is barbican, correct? | 22:53 |
| woodster_ | miguelgrinberg: I can ask the gentleman that brought this up more about their use case...yes, this is regarding barbican | 22:54 |
| woodster_ | miguelgrinberg: I do like the keep it simple approach | 22:54 |
| miguelgrinberg | heat does not have much going on for barbican, we have the barbican integration in a plugin right now. This is unsupported code, we can change it if there are any problems with it. | 22:55 |
| miguelgrinberg | (I work on heat, BTW, in case you didn't know) | 22:56 |
| woodster_ | miguelgrinberg: A contributor named kfox1111 mentioned this use case to us, but he mentioned it in passing, so I might have gotten the ask wrong! | 22:58 |
| woodster_ | miguelgrinberg: I'm cool downplaying patch support though...I agree it adds api complexity for sure | 22:59 |
| miguelgrinberg | yeah, I would really not bother with the complications of implementing patch unless you really have no other choice | 23:00 |
| elmiko | i gotta head out, have a good weekend folks =) | 23:00 |
| miguelgrinberg | elmiko: have a good weekend! | 23:00 |
| *** salv-orlando has quit IRC | 23:07 | |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!