| *** salv-orlando has joined #openstack-api | 00:51 | |
| *** salv-orlando has quit IRC | 00:56 | |
| *** salv-orlando has joined #openstack-api | 01:23 | |
| *** salv-orlando has quit IRC | 01:30 | |
| *** woodster_ has quit IRC | 01:40 | |
| *** woodster_ has joined #openstack-api | 02:37 | |
| *** salv-orlando has joined #openstack-api | 02:42 | |
| *** salv-orlando has quit IRC | 02:44 | |
| *** salv-orlando has joined #openstack-api | 03:04 | |
| *** salv-orlando has quit IRC | 03:11 | |
| *** woodster_ has quit IRC | 04:40 | |
| *** salv-orlando has joined #openstack-api | 04:49 | |
| *** salv-orlando has quit IRC | 05:05 | |
| *** salv-orlando has joined #openstack-api | 05:22 | |
| openstackgerrit | Alex Xu proposed openstack/api-wg: Add guideline for api microversion https://review.openstack.org/187112 | 06:24 |
|---|---|---|
| *** fzdarsky has joined #openstack-api | 07:28 | |
| *** etoews has quit IRC | 08:10 | |
| *** etoews has joined #openstack-api | 08:12 | |
| *** cdent has joined #openstack-api | 08:56 | |
| *** e0ne has joined #openstack-api | 09:02 | |
| *** e0ne is now known as e0ne_ | 09:48 | |
| *** e0ne_ is now known as e0ne | 09:50 | |
| *** openstack has quit IRC | 10:20 | |
| *** openstack has joined #openstack-api | 10:26 | |
| *** alex_klimov has joined #openstack-api | 11:02 | |
| *** fzdarsky has joined #openstack-api | 11:12 | |
| *** e0ne has quit IRC | 11:21 | |
| *** woodster_ has joined #openstack-api | 11:24 | |
| *** e0ne has joined #openstack-api | 11:30 | |
| *** salv-orlando has quit IRC | 11:51 | |
| *** salv-orlando has joined #openstack-api | 12:13 | |
| *** terrylhowe has joined #openstack-api | 13:09 | |
| *** annegentle has joined #openstack-api | 13:23 | |
| openstackgerrit | Ryan Brown proposed openstack/api-wg: Add section on filtering https://review.openstack.org/177468 | 13:23 |
| *** e0ne has quit IRC | 13:35 | |
| openstackgerrit | Ryan Brown proposed openstack/api-wg: Add section on filtering https://review.openstack.org/177468 | 13:41 |
| *** annegentle has quit IRC | 14:02 | |
| *** annegentle has joined #openstack-api | 14:03 | |
| *** sigmavirus24_awa is now known as sigmavirus24 | 14:07 | |
| *** annegentle has quit IRC | 14:32 | |
| krotscheck | sdague: So, that API caching recommendation you put up, I'm starting to ponder whether I agree with miguelgrinberg that it should have some more specifics. At the very least, perhaps a link to http://www.w3.org/Protocols/rfc2616/rfc2616-sec13.html | 14:39 |
| krotscheck | Personally, I'm really liking both the etag section and the last-modified header, since they can be implemented against openstack without too much hassle. | 14:40 |
| ryansb | yup, middleware is pretty great for that kind of change | 14:41 |
| sdague | krotscheck: ok, just getting back from a week of family time, so I haven't looked at those reviews | 14:41 |
| krotscheck | ryansb: The only hiccup I see is that use of paste.ini might cause a race condition initializing oslo_config. | 14:42 |
| krotscheck | sdague: NO worries, I'll add a comment. | 14:42 |
| ryansb | krotscheck: implementation detail, methinks | 14:42 |
| krotscheck | ryansb: It's an implementation detail until you try to propose a specification to add a middleware, and you get tons of political pushback :) | 14:44 |
| * krotscheck might have just gone through that. | 14:44 | |
| ryansb | you sound a touch traumatized ;) | 14:45 |
| sdague | heh | 14:45 |
| krotscheck | ryansb: Well, yes. Not that I don't get what they're saying, but now I have two distinctly conflicting feature requests that I don't think are reconcilable ;) | 14:46 |
| elmiko | ouch =( | 14:47 |
| sdague | krotscheck: so we can definitely add more specifics. I think the challenge is striking the line between guidelines and rewriting the upstream specs. I was erring on the side of "this is how I'd explain it in a hallway track at a summit" | 14:47 |
| krotscheck | One group wants CORS support that can run standalone. The other wants CORS support that's automatically configured from keystone. | 14:48 |
| krotscheck | Doing both to me is a little tooo.... magic | 14:48 |
| sdague | krotscheck: which groups? | 14:48 |
| sdague | sometimes that's the important part :) | 14:48 |
| krotscheck | sdague: Ironic, and Keystone, respectively. | 14:48 |
| sdague | does ironic want it stand along because they want to run without keystone? | 14:49 |
| krotscheck | sdague: Yep. They want ironic to be entirely self-sufficient where necessary. | 14:49 |
| sdague | so... that's where I kind of draw a line. I really think keystone should not be considered optional for OpenStack | 14:50 |
| cdent | what does "configured from keystone" mean in this context? | 14:50 |
| sdague | yeh, I don't know what that means either, honestly :) | 14:50 |
| krotscheck | Right | 14:50 |
| krotscheck | So, CORS request comes in with an Origin header. | 14:51 |
| krotscheck | CORS middleware asks keystone: Hey! is this one of your trusted dashboards? | 14:51 |
| krotscheck | Keystone gives thumbs up/down. | 14:51 |
| cdent | ah, okay | 14:51 |
| cdent | so it's not so much "configured from" but "managed by"? | 14:51 |
| krotscheck | sdague: Well, you can argue that with devananda :) | 14:51 |
| krotscheck | cdent: Yeah, I guess so. | 14:52 |
| *** e0ne has joined #openstack-api | 14:52 | |
| * krotscheck is just here to advocate javascript. | 14:52 | |
| cdent | :) | 14:52 |
| *** notmars has joined #openstack-api | 14:52 | |
| *** e0ne is now known as e0ne_ | 14:52 | |
| cdent | I would think a use-keystone-to-validate-dashboards is a reasonable option | 14:53 |
| cdent | especially as turning it off could make some forms of testing easier | 14:53 |
| cdent | (nevermind the ironic use case) | 14:53 |
| cdent | (which may or may not be valid, dunno) | 14:53 |
| sdague | yeh, it honestly seems pretty weird to me to design around the non keystone case | 14:54 |
| cdent | It's pretty easy to imagine a keystone-less undercloud, isn't it? | 14:55 |
| *** e0ne_ is now known as e0ne | 14:56 | |
| sdague | cdent: so then you created a 2nd auth system for your cloud admins? | 14:56 |
| * cdent shrugs | 14:56 | |
| cdent | I don't really know, I'm just flexing my imagination | 14:57 |
| cdent | (my imagination has HUGE biceps) | 14:57 |
| elmiko | hehe | 14:57 |
| sdague | keystone is basically a REST API (and metadata add) for your existing auth system | 14:57 |
| sdague | it seems weird to bypass that | 14:57 |
| cdent | tru | 14:58 |
| elmiko | i take it the ironic folks have a use case for a keystone-less stack? | 14:58 |
| cdent | we're speculating at this point | 14:59 |
| krotscheck | Seems to me like Keystone's an abstraction layer that supports functionality that the auth systems it abstracts should "Just Support". i.e. it's a shim | 14:59 |
| elmiko | ok, just curious if this was academic or pragmatic | 14:59 |
| krotscheck | elmiko: I never did get a nailed down use case for that. | 14:59 |
| krotscheck | elmiko: Might be good to ask in the ironic channel | 14:59 |
| elmiko | k | 14:59 |
| sdague | elmiko: they want to do a thing. We don't entirely know why. That thing is going to cause extra work for other efforts, so probably should figure that out. | 15:00 |
| elmiko | krotscheck: i'm still trying to fully understand the problem space here | 15:00 |
| elmiko | sdague: agreed on more understanding | 15:00 |
| *** Guest83839 has joined #openstack-api | 15:00 | |
| krotscheck | I just want everything to support OpenId Connect and leave it at that. | 15:01 |
| krotscheck | :) | 15:01 |
| cdent | \o/ | 15:01 |
| elmiko | nice | 15:02 |
| *** kfox1111 has quit IRC | 15:04 | |
| ryansb | I kind of doubt users would want a keystoneless UC | 15:05 |
| ryansb | since authz/authn is still important for those services, even though they may not have as many tenants | 15:05 |
| krotscheck | ryansb: I doubt that users would want a UC without authentication, whether that is provided by keystone or something else. | 15:05 |
| cdent | I suspect the driver for this stuff is bifrost | 15:05 |
| ryansb | especially if they use Heat for provisioning ironic nodes, and want heat stack-domain users for cloudinit/cfntools to run well | 15:06 |
| krotscheck | ryansb: They're not touching heat. | 15:06 |
| ryansb | hm | 15:06 |
| * krotscheck knows that much | 15:06 | |
| krotscheck | ryansb: I belive it's the other way around. Ironic can be a driver for nova, and heat uses nova to do things, which may - depending on the driver - be on bare metal. | 15:07 |
| * krotscheck might not have that entirely correct. | 15:08 | |
| sdague | cdent: it is | 15:08 |
| sdague | anyway, this might be a great instance to get an ML thread going, because the implications touch a lot of efforts | 15:09 |
| sdague | and corner conversations inside irc channels probably won't get us anywhere useful | 15:09 |
| krotscheck | sdague: Are you sure? I was under the impression that Ironic's design philosophy is very clearly "We don't depend on anyone". Much to my chagrin, since I'm trying to convince them that glance is more or less necessary to make the service usable. | 15:09 |
| ryansb | truth | 15:09 |
| elmiko | sdague: +1 | 15:10 |
| krotscheck | Righto, so who wants to start that? | 15:10 |
| * cdent listens to the crickets | 15:13 | |
| cdent | Which issue is it that we are trying to address here? We seemed to leap from caching to CORS middleware in a way I didn't quite understand | 15:13 |
| sdague | krotscheck: I don't know. I do know that "uses keystone" is kind of table stakes for big tent. Otherwise it's not really clear it's OpenStack, it's some other software that's drafting on OpenStack brand. | 15:14 |
| krotscheck | Well, there are two issues. | 15:15 |
| sdague | cdent: I think the things is CORS support means the client is Chrome, which has very different caching semantics than python requests | 15:15 |
| krotscheck | Whoooathere. Caching is a different topic altogether. We're just talking API-to-API communication here. | 15:16 |
| krotscheck | Browser's haven't even come into the picture yet. | 15:16 |
| sdague | krotscheck: right, fair | 15:16 |
| sdague | I'm trying to get ahead of that one though | 15:16 |
| sdague | because getting servers to do cache control sanely is going to take a while | 15:16 |
| krotscheck | Problem 1: CORS middleware, should it have an implicit dependency on keystone or not? Upside: Easy (zero) configuration. Downside: Can't run standalone. | 15:16 |
| krotscheck | Problem 2: Can we support both in one middleware? If not, should we provide paste.ini options? If so, there's an Order-of-operations problem with initializing oslo_config. | 15:17 |
| krotscheck | sdague: As far as browser cache control goes, I can quite happily teach our request abstraction to use etags and if-last-modified headers rather than the cache-expiry settings | 15:18 |
| cdent | it's not an either or | 15:20 |
| sdague | krotscheck: yeh, sorry, still getting my brain back up to speed. I'm not sure I understand what that would mean vs. actually getting the servers to do the right things internally and send those headers appropriately. I'm a little concerned that if we go doesn the "solve cache management in middleware" we actually lose a lot of correct info. | 15:20 |
| cdent | (cache control, that is) | 15:20 |
| sdague | but, again, I've been out for a week, and brain is still rewrapping on openstack things :) | 15:20 |
| cdent | sdague++ | 15:20 |
| cdent | I know how that can be. I'm still resetting my bogosity filters. | 15:21 |
| elmiko | lol | 15:21 |
| krotscheck | sdague: I think it's unreasonable to assume that any of the API teams are going to care about sending the correct data. | 15:21 |
| krotscheck | Or implementing it internally | 15:21 |
| cdent | since my bogosity filters are not yet set I'll say: then they shouldn't be writing apis | 15:22 |
| krotscheck | Because it's a complex problem, and it's a lot of work to support, get right, and frankly everyone's going to want to do their own version of this. | 15:22 |
| krotscheck | Assuming that anyone's willing to front the actual development time. | 15:22 |
| cdent | there it is | 15:23 |
| krotscheck | cdent: Yep | 15:23 |
| krotscheck | So here's the thing. | 15:23 |
| krotscheck | I am willing to do some work on this. But I have zero desire to become an expert at the nuances of _every_ single OpenStack API. | 15:24 |
| cdent | very fair | 15:24 |
| krotscheck | So if I was going to build this, I'd do two things. | 15:24 |
| cdent | (which "this"?) | 15:24 |
| krotscheck | (caching) | 15:24 |
| krotscheck | 1- Etag middleware, that md5's the response body and modifies the response if the approriate headers are sent. | 15:25 |
| krotscheck | 2- Last-modified middleware, which assumes that everyone's using oslo_db's 'created_at' and 'modified_at' fields. | 15:25 |
| krotscheck | ....and acts accordingly. | 15:25 |
| krotscheck | (urm, 3 things) | 15:26 |
| krotscheck | 3- Cache-Expiry middleware, which assumes oslo config and just sets the expiry time to something from a config file. | 15:26 |
| krotscheck | If there's an appropriate spec that will back me up that I can use to strongarm api teams into applying these things, great. | 15:27 |
| krotscheck | Or to apply pressure to come up with their own solution. | 15:27 |
| cdent | I don't think 1 can work unless you have a tool to normalize dict-based representations | 15:28 |
| cdent | which is why I think doing it as middleware is fraught with impossibilities | 15:28 |
| krotscheck | cdent: Yeah, there'd have to be attribute sorting. | 15:28 |
| krotscheck | And that might be processor intensive. | 15:28 |
| krotscheck | i.e. nontrivial impact to performance. | 15:28 |
| cdent | I reckon etag calculation is very implementation dependent because you can have representations of the same thing which are structurally different but which should have the same etag | 15:29 |
| cdent | and then there's the vary header | 15:30 |
| krotscheck | cdent: Well, we could just do the same with 1 as we are with 2 and just hash the modified_date. | 15:31 |
| krotscheck | ....and assume that the api's are sane. | 15:32 |
| * krotscheck isn't sure that's a thing we can assume. | 15:32 | |
| *** notmars has quit IRC | 15:32 | |
| cdent | I don't know, but suspect not | 15:32 |
| cdent | I think these are the sorts of questions that a mailing list posting might ask, around the topic of "is it possible to generically manage etags" | 15:32 |
| cdent | and see what people say | 15:32 |
| *** subscope has joined #openstack-api | 15:37 | |
| sdague | anyway, I have a few more near term things I need to try to get moving this week that I committed to at summit. I think on the etags from middleware thing I was thinking slightly differently. The issue I was thinking about was the GET 404 being cachable, but it might have occurred on a resource that did not yet exist (but could later) in which case the server really needs to indicate that fact (middleware can't solve it) | 15:40 |
| sdague | in doing a little more etags refreshing, I do agree there could be a middleware path there, though honestly I'm not convinced it's going to help much in our model because it would mostly just save the wire time as the server would need to figure out if the resource was equiv | 15:42 |
| sdague | enough so, that I'd say punting all of etags to M cycle, because I think there is lots of other things to sort first | 15:42 |
| krotscheck | sdague: Thankfully, I don't care about what you silly server people care about :) | 15:42 |
| sdague | :) | 15:43 |
| sdague | krotscheck: I mostly care so that your life is easier :) | 15:43 |
| krotscheck | Honestly though, I want to get the protocol established. Once we say: Hey, this is how we communicate cached resources, each team can evolve how they see fit. | 15:43 |
| krotscheck | And middleware seems to be the quickest way to "Here's the language we speak". | 15:43 |
| * cdent rewrites openstack to use a dht p2p-managed event pool | 15:43 | |
| krotscheck | Implement everything in node! | 15:44 |
| * krotscheck actually dislikes node on the server. | 15:44 | |
| sdague | ok, well, good chat. Now I need to go find food. Back in a while. | 15:45 |
| elmiko | krotscheck: you're on a heavy javascript vibe today ;) | 15:45 |
| *** e0ne is now known as e0ne_ | 15:50 | |
| cdent | elmiko: someone said to me today: you don't give yourself enough credit, understanding [this thing we were talking about] requires a lot of frontend javascript knowledge | 15:50 |
| cdent | I felt ashamed | 15:50 |
| cdent | and wanted to hide | 15:50 |
| cdent | not really | 15:51 |
| cdent | but it does make me wish I could archive stuff | 15:51 |
| *** e0ne_ is now known as e0ne | 15:51 | |
| elmiko | LOL | 15:54 |
| *** notmars has joined #openstack-api | 15:56 | |
| *** subscope has quit IRC | 16:07 | |
| *** Guest83839 has quit IRC | 16:08 | |
| *** annegentle has joined #openstack-api | 16:09 | |
| *** annegentle has quit IRC | 16:14 | |
| *** alex_klimov has quit IRC | 16:16 | |
| krotscheck | elmiko: That's what I get paid for :) | 16:17 |
| * krotscheck is actually serious. Making OpenStack more javascript friendly is his job. | 16:18 | |
| cdent | That should have a good title | 16:18 |
| krotscheck | cdent: "Glutton for Punishment" | 16:19 |
| krotscheck | At least that's the working title | 16:19 |
| cdent | Senior Glutton for Punishment, sir | 16:20 |
| *** Apoorva has joined #openstack-api | 16:22 | |
| elmiko | krotscheck: nice! i had no idea =) | 16:25 |
| krotscheck | elmiko: Why do you think I'm harping so hard on improving API things :) | 16:28 |
| cdent | diverse client environment makes better apis | 16:29 |
| cdent | this way in which stuff is written to blessed clients is _horrible_ | 16:29 |
| elmiko | krotscheck: i thought you just wanted to help improve the API =) | 16:30 |
| sigmavirus24 | == cdent | 16:30 |
| sigmavirus24 | elmiko: and here krotscheck was being selfish all along ;) | 16:30 |
| *** notmars has quit IRC | 16:30 | |
| krotscheck | elmiko, sigmavirus24: What cdent said :). We'll all be happier if API's behave according to standards. | 16:31 |
| elmiko | lol! | 16:31 |
| elmiko | krotscheck: agreed | 16:31 |
| krotscheck | And if me being selfish makes the world better, then is it really being selfish? #circularreasoning | 16:32 |
| *** salv-orl_ has joined #openstack-api | 16:39 | |
| *** salv-orlando has quit IRC | 16:42 | |
| *** fzdarsky has quit IRC | 16:42 | |
| elmiko | hehe | 16:43 |
| sigmavirus24 | krotscheck: scratching an itch is the foundation of oss =P | 16:47 |
| krotscheck | sigmavirus24: Even if I do it with a flamethrower? | 16:47 |
| sigmavirus24 | yep | 16:48 |
| *** e0ne has quit IRC | 16:55 | |
| *** salv-orl_ has quit IRC | 16:56 | |
| *** salv-orlando has joined #openstack-api | 16:57 | |
| *** notmars has joined #openstack-api | 17:09 | |
| *** annegentle has joined #openstack-api | 17:10 | |
| *** annegentle has quit IRC | 17:17 | |
| *** annegentle has joined #openstack-api | 17:21 | |
| *** notmars has quit IRC | 17:23 | |
| *** Apoorva has quit IRC | 18:56 | |
| *** annegentle has quit IRC | 19:00 | |
| *** e0ne has joined #openstack-api | 19:10 | |
| *** cdent has quit IRC | 19:17 | |
| *** e0ne has quit IRC | 19:24 | |
| *** annegentle has joined #openstack-api | 19:33 | |
| *** annegentle has quit IRC | 19:35 | |
| *** annegentle has joined #openstack-api | 19:35 | |
| *** salv-orlando has quit IRC | 19:49 | |
| *** Apoorva has joined #openstack-api | 19:50 | |
| *** alex_klimov has joined #openstack-api | 19:51 | |
| *** annegentle has quit IRC | 19:51 | |
| *** salv-orlando has joined #openstack-api | 20:07 | |
| *** annegentle has joined #openstack-api | 20:19 | |
| *** fzdarsky has joined #openstack-api | 20:20 | |
| *** notmars has joined #openstack-api | 20:41 | |
| *** salv-orlando has quit IRC | 20:50 | |
| *** notmars has quit IRC | 20:56 | |
| *** notmars has joined #openstack-api | 21:01 | |
| miguelgrinberg | krotscheck: wondering if you had any discussions regarding a caching middleware. I'm thinking about the API-WG guideline, and it really would make it a lot easier to briefly describe the best practices around caching and then point at a middleware that implements the caching baseline. | 21:24 |
| *** notmars has quit IRC | 21:37 | |
| *** salv-orlando has joined #openstack-api | 21:50 | |
| *** e0ne has joined #openstack-api | 21:51 | |
| *** annegentle has quit IRC | 21:51 | |
| *** openstackgerrit has quit IRC | 22:07 | |
| *** openstackgerrit has joined #openstack-api | 22:07 | |
| krotscheck | miguelgrinberg: ALl I got from the oslo team was: Sure! Who's the customer? | 22:07 |
| krotscheck | miguelgrinberg: Everything else was discussed here in channel. | 22:07 |
| miguelgrinberg | krotscheck: okay, I guess that's better than a no | 22:08 |
| *** annegentle has joined #openstack-api | 22:09 | |
| krotscheck | miguelgrinberg: Well, they seemed pretty happy when I said it'd be part of caching guidelines proposed by the API-WG | 22:14 |
| elmiko | krotscheck: +1 | 22:16 |
| *** annegentle has quit IRC | 22:16 | |
| lifeless | krotscheck: miguelgrinberg: cache control middleware, or caching-content middleware? | 22:22 |
| *** e0ne has quit IRC | 22:22 | |
| miguelgrinberg | lifeless: cache control | 22:23 |
| miguelgrinberg | krotscheck: I looked all over for something already built that is close to what we need, but haven't found anything. | 22:24 |
| *** fzdarsky has quit IRC | 22:28 | |
| lifeless | miguelgrinberg: better to have a library for it than everyone rolling-their-own-buggy versions | 22:28 |
| lifeless | so sure, what do you need from oslo for that? | 22:29 |
| miguelgrinberg | lifeless: the concern is that once we enable CORS and start seeing browser clients we'll have to make sure we control caching | 22:30 |
| miguelgrinberg | so the idea is to have a middleware that adds safe caching | 22:30 |
| miguelgrinberg | this would include generating an etag and also responding to conditional requests | 22:31 |
| lifeless | miguelgrinberg: I don't understand why that becomes a concern | 22:31 |
| lifeless | miguelgrinberg: its already a concern | 22:31 |
| miguelgrinberg | of course, but browsers are pretty aggressive about caching, other clients are not | 22:32 |
| miguelgrinberg | so opening access to browsers may expose existing problems, cause by us not doing anything to control caching from the server | 22:33 |
| lifeless | I haven't done an audit of our responses | 22:34 |
| lifeless | but - do they have datestamps? | 22:34 |
| miguelgrinberg | I don't think so | 22:34 |
| lifeless | I don't have a devstack running right now | 22:36 |
| miguelgrinberg | I believe in most cases responses have no caching headers, so what clients can do with that is pretty open | 22:36 |
| lifeless | so no | 22:36 |
| miguelgrinberg | this isn't well defined in the HTTP RFC, but there are some response status codes that are cacheable by default | 22:36 |
| lifeless | I'm going to differ here | 22:37 |
| lifeless | its very well defined | 22:37 |
| lifeless | going back to 1.0 even, the idea of clockless caching was considered | 22:37 |
| lifeless | with no explicit caching metadata, RFC 7234 section 4.2.2 applies | 22:38 |
| miguelgrinberg | okay, let me find that | 22:39 |
| lifeless | implementors are allowed considerable latitude in the heuristic they choose | 22:39 |
| lifeless | but | 22:39 |
| lifeless | chromium doesn't set a freshness without LMT | 22:40 |
| lifeless | so we need to check if there is an LMT; if there is, it uses 10% of now-lmt | 22:40 |
| lifeless | I haven't checked firefox, but from memory its similar | 22:41 |
| lifeless | e.g. really conservative given that if we're generating dynamic LMT's (which we probably are), and clock skew isn't an issue (because it causes huge token expiry problems so we know operators have that sorted in general) | 22:41 |
| miguelgrinberg | I believe our responses (most of them at least) have no LMT or any other piece of information that can be used for caching | 22:42 |
| lifeless | we're looking at cache times in the subsecond region - e.g. uncachable | 22:42 |
| lifeless | mozilla is also 10% of date-lmt, if lmt, and nothing if no lmt (lmt is the fallback of last resort) | 22:43 |
| miguelgrinberg | so I think the question is what these caches do when there's no hints of freshness/age | 22:44 |
| lifeless | they don't cache | 22:44 |
| miguelgrinberg | that's the ideal, but that's the part that isn't well defined in the RFC, at least that's my impression | 22:46 |
| lifeless | so, I don't mean to be difficult, and if you want to spend a bunch of time drilling into this we can | 22:46 |
| lifeless | but I've just cross checked the firefox caching faq too | 22:46 |
| lifeless | https://developer.mozilla.org/en-US/docs/Web/HTTP/Caching_FAQ | 22:47 |
| lifeless | and its also consistent with my assertion | 22:47 |
| lifeless | I can also just about quote from memory the squid internals for this | 22:47 |
| lifeless | I'm also not sure why we're ratholing here - I asked what help you needed from oslo to move your proposal forward | 22:49 |
| elmiko | this is some deep caching/browser talk, thanks =) | 22:50 |
| lifeless | I think we'll clearly need a spec, since the inputs to mark a response as cachable are non-trivial for APIs that weren't designed with that in mind (and ours weren't) | 22:50 |
| miguelgrinberg | At this point we are just discussing caching, so there are no immediate needs. The possibility of having a middleware that adds caching headers is the potential oslo involvement. | 22:50 |
| lifeless | without some cross project analysis I'd also hesitate about the idea of responding to conditional requests: the conservative thing to do is to assume that all requests need to hit the API internals | 22:51 |
| *** openstackgerrit has quit IRC | 22:51 | |
| elmiko | miguelgrinberg: agreed, when talking about middleware best to consult with the oslo team | 22:51 |
| *** openstackgerrit has joined #openstack-api | 22:51 | |
| lifeless | that is, if a client has a fresh response (once we figure out how to determine a sensible cache lifetime for /any/ response) then the client uses it, but if it asks to validate, we always give it a new response | 22:52 |
| lifeless | miguelgrinberg: ok, sure. | 22:53 |
| miguelgrinberg | I feel we are getting into very specific implementation details, but if the server decides the client has a fresh response it can say "yeah, use what you have" and save some bandwidth. | 22:53 |
| miguelgrinberg | this is easy to do with etags | 22:53 |
| miguelgrinberg | the API internals have to be hit anyway, because that's how you determine if the client has a fresh response | 22:53 |
| lifeless | miguelgrinberg: anyhow, I'm very confident, if we're emitting no LMT or any explict caching headers, that browers won't be caching | 22:54 |
| lifeless | miguelgrinberg: so you can in principle save a bunch of the response calculation in some cases, if your validator is well glued into the backend | 22:54 |
| lifeless | as a trivial example of this consider apache's etags on static content, derived from file system metadata | 22:55 |
| lifeless | rather than hashing the entire body | 22:55 |
| lifeless | all that said, I'm happy to help; I just don't think the CORS work needs to block in any way on caching middleware | 22:56 |
| miguelgrinberg | lifeless: if we are all convinced that current responses are not at risk of getting cached, then I'd say we don't need to worry about a caching middleware for time being | 22:57 |
| miguelgrinberg | So what I can do is add some quick & dirty CORS support to some of the APIs and then test them in a bunch of browsers, including closed source ones to see what happens. | 22:58 |
| lifeless | remember too that authenticated content is noncachable by default | 22:58 |
| lifeless | good idea, testing++ :) | 22:58 |
| lifeless | and ssl, which I'd expect all deployments to be using | 22:59 |
| lifeless | so please be sure to test with ssl! | 22:59 |
| miguelgrinberg | re "authenticated content", browsers are not going to consider X-Auth-Token | 22:59 |
| lifeless | indeed | 22:59 |
| miguelgrinberg | so as far as they are concerned we are not doing auth. Or am I wrong? | 22:59 |
| lifeless | We should really fix up keystone to use the bearer token specs that are around these days | 23:00 |
| lifeless | but EONETHINGATATIME | 23:00 |
| miguelgrinberg | lifeless: and of course SSL needs to be tested as well | 23:00 |
| miguelgrinberg | so I think we are not ready to write an API-WG proposal on caching yet :) | 23:01 |
| miguelgrinberg | lifeless: thanks for your help | 23:02 |
| lifeless | np, hope it turns out well :) | 23:04 |
| lifeless | speaking of CORS | 23:09 |
| lifeless | krotscheck: reviewed the cors spec per your request. | 23:09 |
| *** agentle1 has joined #openstack-api | 23:10 | |
| miguelgrinberg | lifeless: unrelated to needing this or not as far as CORS, would you guys be open to a proposal/spec on a middleware that does auto-etag support? I've implemented that in the past (not openstack related), the nice thing is that a default implementation can be done without knowledge of the content, so it can go in a generic middleware. | 23:11 |
| elmiko | miguelgrinberg: i've seen you mention etags several times now, is there an rfc i can read up on that topic? | 23:11 |
| miguelgrinberg | elmiko: sure, it's in the HTTP RFC, let me look up which one has it | 23:12 |
| elmiko | think i found the old one in 2616 | 23:12 |
| *** sigmavirus24 is now known as sigmavirus24_awa | 23:12 | |
| miguelgrinberg | elmiko: https://tools.ietf.org/html/rfc7232 | 23:13 |
| miguelgrinberg | conditional requests | 23:14 |
| elmiko | miguelgrinberg: awesome, thank you =) | 23:14 |
| miguelgrinberg | the tl;dr is that each response comes with a unique ID (the etag). Then the client can send a conditional request to the server passing a previously cached etag from a response. If the etag is still valid the server can reply with a "use your cached copy" response. | 23:15 |
| miguelgrinberg | and you save bandwidth that way | 23:15 |
| elmiko | nice | 23:15 |
| elmiko | take care miguelgrinberg, i'm off for some dinner | 23:17 |
| miguelgrinberg | elmiko: have a good one | 23:17 |
| lifeless | miguelgrinberg: I'd be ok with such a spec, sure. | 23:28 |
| *** agentle1 has quit IRC | 23:30 | |
| *** salv-orlando has quit IRC | 23:33 | |
| *** alex_klimov has quit IRC | 23:40 | |
| *** agentle1 has joined #openstack-api | 23:49 | |
| *** agentle1 has quit IRC | 23:49 | |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!