| *** alex_klimov has quit IRC | 00:01 | |
| *** salv-orlando has joined #openstack-api | 00:15 | |
| *** salv-orlando has quit IRC | 00:19 | |
| *** Apoorva has quit IRC | 00:26 | |
| HenryG | If a new api is being developed or an api is being reworked in a project (neutron, in my case), I would like to tell them to "check the design with the API WG". What docs/wikis should I point them to? | 01:36 |
|---|---|---|
| *** sigmavirus24 is now known as sigmavirus24_awa | 01:50 | |
| *** salv-orlando has joined #openstack-api | 02:37 | |
| *** salv-orlando has quit IRC | 02:42 | |
| *** woodster_ has quit IRC | 03:40 | |
| *** terrylhowe has quit IRC | 04:00 | |
| *** salv-orlando has joined #openstack-api | 04:42 | |
| *** openstackgerrit has quit IRC | 04:50 | |
| *** openstackgerrit has joined #openstack-api | 04:50 | |
| *** salv-orlando has quit IRC | 04:53 | |
| *** salv-orlando has joined #openstack-api | 05:23 | |
| *** fifieldt has joined #openstack-api | 05:25 | |
| *** elmiko has quit IRC | 06:47 | |
| *** salv-orlando has quit IRC | 07:00 | |
| *** salv-orlando has joined #openstack-api | 07:00 | |
| *** elmiko has joined #openstack-api | 07:16 | |
| *** gmann is now known as help | 07:16 | |
| *** help is now known as gmann | 07:17 | |
| *** alex_klimov has joined #openstack-api | 07:24 | |
| *** fzdarsky has joined #openstack-api | 07:26 | |
| *** salv-orlando has quit IRC | 07:38 | |
| *** alex_klimov has quit IRC | 08:04 | |
| *** alex_klimov has joined #openstack-api | 08:10 | |
| *** salv-orlando has joined #openstack-api | 08:39 | |
| *** salv-orlando has quit IRC | 08:45 | |
| *** xylan_kong has joined #openstack-api | 08:49 | |
| *** e0ne has joined #openstack-api | 09:22 | |
| *** e0ne is now known as e0ne_ | 09:30 | |
| *** e0ne_ has quit IRC | 09:35 | |
| *** miyagishi_t has joined #openstack-api | 09:50 | |
| *** e0ne has joined #openstack-api | 09:57 | |
| *** miyagishi_t has quit IRC | 10:01 | |
| *** salv-orlando has joined #openstack-api | 10:10 | |
| *** e0ne is now known as e0ne_ | 10:39 | |
| *** e0ne_ has quit IRC | 10:45 | |
| *** e0ne has joined #openstack-api | 10:53 | |
| *** e0ne is now known as e0ne_ | 11:11 | |
| *** e0ne_ is now known as e0ne | 11:12 | |
| *** salv-orlando has quit IRC | 11:12 | |
| *** e0ne is now known as e0ne_ | 11:20 | |
| *** kaufer has joined #openstack-api | 11:24 | |
| *** e0ne_ has quit IRC | 11:25 | |
| *** e0ne has joined #openstack-api | 11:34 | |
| *** openstackgerrit has quit IRC | 11:39 | |
| *** openstackgerrit has joined #openstack-api | 11:39 | |
| *** woodster_ has joined #openstack-api | 11:42 | |
| *** salv-orlando has joined #openstack-api | 12:12 | |
| *** e0ne is now known as e0ne_ | 12:32 | |
| *** e0ne_ has quit IRC | 12:43 | |
| *** terrylhowe has joined #openstack-api | 12:43 | |
| *** e0ne has joined #openstack-api | 12:47 | |
| *** fzdarsky has quit IRC | 12:56 | |
| *** fzdarsky has joined #openstack-api | 12:56 | |
| *** salv-orlando has quit IRC | 13:11 | |
| *** fifieldt has quit IRC | 13:11 | |
| *** salv-orlando has joined #openstack-api | 13:11 | |
| *** sigmavirus24_awa is now known as sigmavirus24 | 14:02 | |
| miguelgrinberg | HenryG: the current list of guidelines is available in our git repo: https://github.com/openstack/api-wg/tree/master/guidelines. For anything not covered in the guidelines, you can reach to us here, or come to our weekly meetings. | 14:32 |
| ryansb | HenryG: you can also add "APIImpact" to the commit message of the spec/patch to notify us | 14:33 |
| HenryG | miguelgrinberg: thanks. Those docs are looking good! Still a lot of work to do though :) | 14:34 |
| HenryG | ryansb: Yes, thanks, I know about that flag. Do you see it before a patch is merged? | 14:35 |
| miguelgrinberg | HenryG: yes, definitely there's a lot more guidelines to write. A few are going through the review process also. | 14:35 |
| HenryG | BTW, I am ramping to be one of the liasons for neutron | 14:37 |
| ryansb | HenryG: yup, I try to go through APIImpact reviews on a pretty regular basis | 14:38 |
| ryansb | great, I'm the Heat CPL | 14:38 |
| ryansb | nice to (irc)meet you | 14:38 |
| HenryG | ryansb: likewise | 14:38 |
| HenryG | ryansb: How do you search for APIimpact reviews? | 14:41 |
| ryansb | bookmarked gerrit query | 14:44 |
| ryansb | https://review.openstack.org/#/q/status:open+AND+%28message:ApiImpact+OR+message:APIImpact%29,n,z | 14:44 |
| ryansb | or this line in gertty | 14:46 |
| ryansb | query: "is:open AND message:APIImpact OR message:ApiImpact" | 14:46 |
| elmiko | welcome aboard HenryG =) | 14:48 |
| * HenryG learned about the message: search field in gerrit today. Thanks ryansb! | 14:51 | |
| ryansb | :) | 14:51 |
| *** e0ne is now known as e0ne_ | 15:00 | |
| *** e0ne_ is now known as e0ne | 15:00 | |
| *** fzdarsky has quit IRC | 15:46 | |
| stevelle | ryansb: for the filtering review that is out there, is there a way I can help get it out of WIP? | 15:51 |
| ryansb | stevelle: today is actually a spec-day for me, and that's on the list :) | 15:52 |
| ryansb | so gimme a bit and I should be able to rev it | 15:52 |
| stevelle | good to hear. It came up as a topic at this week's meeting. | 15:53 |
| ryansb | yeah, I saw in the logs | 15:54 |
| * ryansb is buried under a pile of specs | 15:55 | |
| openstackgerrit | Ryan Brown proposed openstack/api-wg: Add section on filtering https://review.openstack.org/177468 | 16:00 |
| openstackgerrit | Ryan Brown proposed openstack/api-wg: Add section on filtering https://review.openstack.org/177468 | 16:01 |
| *** Apoorva has joined #openstack-api | 16:03 | |
| *** alex_klimov has quit IRC | 16:04 | |
| openstackgerrit | Ryan Brown proposed openstack/api-wg: Add section on filtering https://review.openstack.org/177468 | 16:25 |
| miguelgrinberg | ryansb: one problem with your proposed approach is that there is no namespacing for the filters, so their names may collide with other query string args (such as marker, limit, etc). | 16:29 |
| ryansb | that's true, would you want them namespaced as "filter_" or similar? | 16:31 |
| stevelle | I considered that also miguelgrinberg but wasn't sure the fix was worth it | 16:31 |
| stevelle | ryansb: easier would be q. or q_ | 16:31 |
| ryansb | How does f_ (mnemonic for "field" or "filter") strike you? | 16:32 |
| stevelle | I'm amenable to that as well. Probably obvious that I was going with the mnemonic for query | 16:34 |
| miguelgrinberg | ryansb: thinking on building more complex searches, I was wondering what your thoughts are on having a single filters arg that has the query in it, similar to sort | 16:34 |
| stevelle | any namespacing really makes the query string ugly and clunky however | 16:35 |
| ryansb | miguelgrinberg: I thought about that, but I don't want to end up with queries like | 16:35 |
| ryansb | ?filters=name=foo,type=bar because I don't want to overload the equals sign | 16:36 |
| ryansb | and doing delimiter hacks where there may be a comma (for example) in the filter value seems unfortunate | 16:36 |
| ryansb | so while namespacing is a bit unpleasant, I'd prefer to write queries as ?f_foo=bar&f_baz=honk | 16:37 |
| miguelgrinberg | have you thought about issuing ranges based on this syntax? | 16:42 |
| miguelgrinberg | or the OR operator? | 16:42 |
| ryansb | I hadn't thought about OR | 16:47 |
| ryansb | for ranges I was going to do things like | 16:47 |
| ryansb | ?lt_dollars=8 | 16:48 |
| ryansb | so use lt/le/gt/ge/ | 16:48 |
| stevelle | I was going to be proposing something like ?size=gte8 which is in range of that | 16:49 |
| ryansb | I'm not big on mixing the range modifier and value without a delimiter | 16:50 |
| stevelle | the necessity for supporting OR queries is limited and might require an alternate complex query syntax, but most of the time supporting that complexity seems like it would inhibit usability of filters | 16:50 |
| ryansb | so ?size=gte,8 would get +1 from me | 16:50 |
| ryansb | if we introduce or, that opens the whole operator precedence/parens/complex filtering | 16:51 |
| stevelle | I could add the , delimiter without a big issue | 16:51 |
| stevelle | agreed on OR | 16:51 |
| miguelgrinberg | I would be okay making the OR syntax complicated, if that means we can keep everything else simple. I agree it is not going to be something that is used all the time. | 16:53 |
| stevelle | the big issue is that introducing OR introduces a need for precedence also. | 16:54 |
| miguelgrinberg | only if it is mixed with other operators | 16:55 |
| miguelgrinberg | you can support a simple query where the field can be one of several values | 16:55 |
| miguelgrinberg | that's actually pretty much all you can do with enumerated fields | 16:55 |
| stevelle | right now there is only one operator, so OR implies two can be mixed | 16:56 |
| stevelle | but yes ofc | 16:56 |
| ryansb | so the or for fields could look like "?foo=a,b,c" if we could assume , wasn't in the values | 16:58 |
| ryansb | which I'm not certain we can do | 16:58 |
| * ryansb wanders to lunch | 16:59 | |
| ryansb | I'll update my patch in a bit to incorporate this stuff | 16:59 |
| miguelgrinberg | ryansb: for the tagging I got away with saying the comma isn't allowed. I don't think we can get away with that here, so we probably need a way to escape it | 17:01 |
| stevelle | miguelgrinberg ryansb recommend an alternate separator? | 17:02 |
| stevelle | e.g. ; | 17:02 |
| miguelgrinberg | the problem is how you tell the query parser which separator you are using for a given query | 17:04 |
| miguelgrinberg | another option is to allow two syntaxes: ?foo=a,b,c for the easy case, or ?foo="a,b","c","d" for the case where a string has commas in it | 17:05 |
| miguelgrinberg | and quotes inside strings are escaped as usual | 17:05 |
| stevelle | miguelgrinberg: that isn't bad, also it conforms to csv escaping | 17:06 |
| miguelgrinberg | so CSV escapes quotes by putting two in a row correct? | 17:07 |
| miguelgrinberg | or do they use \" like most languages? | 17:07 |
| stevelle | CSV uses , separator but if a value includes the comma the value must be double quoted | 17:08 |
| stevelle | double quoted values are optional otherwise | 17:08 |
| miguelgrinberg | ah, that's what you mean, right, I understand now | 17:08 |
| miguelgrinberg | yes, same idea | 17:08 |
| *** e0ne has quit IRC | 17:08 | |
| stevelle | iirc a " at beginning or end of a value can be escaped | 17:09 |
| stevelle | with \ | 17:09 |
| stevelle | another technique would be to offer a param e.g. separator=, so it could be exchanged for another value when appropriate | 17:10 |
| miguelgrinberg | sure, that would work too, though the burden is on the client to find an appropriate separator | 17:11 |
| stevelle | one way or another you seem to always end up having to support escaping something. in the CSV style example " gets treated differently | 17:11 |
| ryansb | stevelle: it's only be at the beginning/end of a value | 17:12 |
| miguelgrinberg | yeah, there's no way to avoid it, so we should pick a familiar escaping pattern | 17:12 |
| ryansb | so ="a,b",c"d,e would be ok | 17:12 |
| ryansb | though looks a touch odd... | 17:12 |
| miguelgrinberg | it's a corner case, we just need to make sure it can be done, it does not need to be pretty | 17:13 |
| miguelgrinberg | here is one ugly one foo="a,b",c",d,"e\"" | 17:14 |
| miguelgrinberg | seems decent to me | 17:14 |
| stevelle | ="a%20%22%0Ab%22%0A",b,c ? | 17:15 |
| stevelle | sorry drop the %0A in those | 17:15 |
| miguelgrinberg | still okay IMHO | 17:18 |
| *** kaufer has quit IRC | 17:18 | |
| ryansb | wouldn't it be | 17:19 |
| ryansb | %22a%2Cb%22%2Cc%2Cd%2C%22a%5C%22%22 | 17:20 |
| stevelle | that should be the value from transforming { key : 'a "b"', 'b', 'c' } to filter format | 17:20 |
| ryansb | oh, I was encoding a different example | 17:20 |
| ryansb | :) | 17:20 |
| stevelle | figured it would help to make it explicit | 17:20 |
| ryansb | anyways, I think we've reached a conclusion | 17:21 |
| ryansb | use f_ as a filter prefix for the field name to avoid collision | 17:21 |
| ryansb | and CSV escaping for multifields | 17:21 |
| ryansb | thanks for all the input :) I'll get that into my spec | 17:21 |
| stevelle | 'gt,' 'gte,' 'lt,' 'lte,' 'eq,' as optional operators? | 17:22 |
| ryansb | yeah | 17:22 |
| stevelle | eq being default applied | 17:22 |
| ryansb | same csv separation for those such as | 17:22 |
| * sigmavirus24 missed using bash comparators | 17:22 | |
| ryansb | ?f_foo=lt,8 | 17:22 |
| stevelle | sigmavirus24: also simplified html entities | 17:23 |
| miguelgrinberg | ryansb: do we want to also have the "like" operator? This is a SQL operator that works as a crappy regex replacement. | 17:35 |
| ryansb | miguelgrinberg: I usually shy away from "like" | 17:36 |
| ryansb | can that be a follow-up to this patch? I think "like" will be fairly controversial and I don't want to hold up this change just for "like" | 17:36 |
| miguelgrinberg | sure, I have no problem with that, just trying to thing about all the options | 17:38 |
| miguelgrinberg | s/thing/think/ | 17:38 |
| ryansb | yeah, I'll toss in a TODO for now | 17:38 |
| miguelgrinberg | regardless of liking it or not, I think it fits the style of queries you are proposing, so no problem, we can visit that later | 17:38 |
| *** kaufer has joined #openstack-api | 17:39 | |
| ryansb | yeah, the reason I usually don't expose "like" is because it's a fairly slow query, especially over large DB's | 17:39 |
| ryansb | (well, don't unless it's needed) | 17:39 |
| miguelgrinberg | yeah, I don't use it much either | 17:42 |
| *** salv-orlando has quit IRC | 17:43 | |
| *** salv-orlando has joined #openstack-api | 17:47 | |
| stevelle | we might do best to bust these changes into small elements so we can identify the controversial parts more easily and focus on passing the rest through, feels like it's got a few parts at this point | 17:48 |
| openstackgerrit | Ryan Brown proposed openstack/api-wg: Add section on filtering https://review.openstack.org/177468 | 17:53 |
| openstackgerrit | Ryan Brown proposed openstack/api-wg: Switch to new Sphinx RFC entites from links https://review.openstack.org/186517 | 18:00 |
| *** e0ne has joined #openstack-api | 18:06 | |
| *** e0ne has quit IRC | 18:21 | |
| openstackgerrit | Ryan Brown proposed openstack/api-wg: Add new guideline for HTTP Headers https://review.openstack.org/186526 | 18:35 |
| elmiko | ryansb: minor nit on the header guideline, could you fit it to the template =) | 18:46 |
| ryansb | elmiko: sure thing | 18:47 |
| elmiko | thanks | 18:48 |
| elmiko | i'm fine with the older guidelines not using it yet, but i figure we should try it out for new stuff | 18:48 |
| ryansb | it's still in review, right? | 18:49 |
| elmiko | the template has been merged | 18:49 |
| elmiko | it's at doc/source/template.rst | 18:49 |
| ryansb | ah, got it | 18:51 |
| elmiko | otherwise the guideline looks reasonable to me | 18:51 |
| ryansb | so do you envision this single doc (headers.rst) having sections (e.g. deprecation of x-) and each section having a intro/guidance/refs subsection? | 18:52 |
| ryansb | or are you thinking this file would only contain the x- deprecation guideline? | 18:53 |
| elmiko | hmm | 18:53 |
| elmiko | if we are creating a single guideline for headers in general, then yes i'd say this would be one section. if not, then it could just be a single guideline for x- deprecation. | 18:53 |
| elmiko | i don't have a strong opinion on this, given the http guideline it might make more sense to make a bigger guideline. i'm not sure though. | 18:54 |
| elmiko | if we go with one big guideline, i would not expect each section to have intro/guideline/examples/etc... | 18:55 |
| ryansb | my concern is that if we do one-file-per-guideline we'll have pretty poor categorization/heirarchy | 18:55 |
| elmiko | i would expect one intro (this is about headers blah blah), then in the guidelines there would be a "x- deprecation" section | 18:55 |
| elmiko | yea, agreed | 18:55 |
| ryansb | having files for concepts (headers, general, encoding, etc) and guidelines inside seem like the way to go | 18:56 |
| elmiko | +1 | 18:56 |
| ryansb | hm, maybe each guideline could be an H2 (subhead) and have within it the applicable H3 (subsub) intro/guidance/examples/refs | 18:58 |
| ryansb | I'll rev that header guideline as an example | 18:59 |
| ryansb | then maybe we can swap up the template a little | 18:59 |
| elmiko | i'm amenable to that, i guess we'll have to see how large they get. | 18:59 |
| elmiko | and then yea, we'd need to update the template to specify the usage | 19:00 |
| ryansb | I can only speak for myself, but I prefer having multiple guidelines in a single page, and having anchor links to specific guidelines | 19:02 |
| ryansb | I'll put up a template review in tandem with the header spec | 19:03 |
| openstackgerrit | Ryan Brown proposed openstack/api-wg: Add new guideline for HTTP Headers https://review.openstack.org/186526 | 19:06 |
| elmiko | ryansb: awesome, thanks! | 19:08 |
| openstackgerrit | Ryan Brown proposed openstack/api-wg: Add section on filtering https://review.openstack.org/177468 | 19:24 |
| elmiko | sigmavirus24: why do you think the swift cpl will object? it doesn't advise changing all the old ones | 19:28 |
| sigmavirus24 | elmiko: all of swift's metadata is transferred via headers | 19:28 |
| sigmavirus24 | And they're all x- headers | 19:29 |
| sigmavirus24 | It's the same reason they complained about Miguel's metadata spec | 19:29 |
| elmiko | sure, but the guideline specifically says "This **does not** mean it is recommended to replace existing uses of X-" | 19:29 |
| ryansb | yeah, but the guideline doesn't say "change all the existing headers" | 19:29 |
| * elmiko wants to increase the peace with swift | 19:29 | |
| ryansb | and even says "existing projects may continue to add X- headers for consistency with existing API) | 19:29 |
| ryansb | also peace++ | 19:29 |
| elmiko | hehe | 19:29 |
| sigmavirus24 | elmiko: the swift people's who gave feedback on the metadata guideline ignored that | 19:30 |
| sigmavirus24 | It's been frequently said by members of the swift team "You say that, but I don't believe you" | 19:30 |
| elmiko | that makes me a sad panda | 19:30 |
| sigmavirus24 | So I'm anticipating push bag regardless of what the text says | 19:30 |
| elmiko | fair | 19:30 |
| sigmavirus24 | s/bag/back/ | 19:30 |
| elmiko | a push bag would be cool too | 19:30 |
| *** Apoorva has quit IRC | 19:33 | |
| *** Apoorva has joined #openstack-api | 19:39 | |
| openstackgerrit | Ryan Brown proposed openstack/api-wg: Change template to match our historic usage https://review.openstack.org/186546 | 19:44 |
| openstackgerrit | Ryan Brown proposed openstack/api-wg: Add new guideline for HTTP Headers https://review.openstack.org/186526 | 19:59 |
| elmiko | thanks ryansb, i just wanted to avoid the possibility of folks feeling singled-out or something | 20:02 |
| ryansb | makes sense, I didn't consider that aspect when I wrote it in | 20:14 |
| elmiko | i only thought about it because of sigmavirus24 ;) | 20:14 |
| sigmavirus24 | you're welcome | 20:17 |
| sigmavirus24 | and I'm sorry | 20:17 |
| elmiko | haha, no worries =) | 20:19 |
| openstackgerrit | Ryan Brown proposed openstack/api-wg: Change template to match our historic usage https://review.openstack.org/186546 | 20:31 |
| *** salv-orlando has quit IRC | 20:49 | |
| *** openstackgerrit has quit IRC | 21:36 | |
| *** openstackgerrit has joined #openstack-api | 21:37 | |
| *** kaufer has quit IRC | 21:45 | |
| *** salv-orlando has joined #openstack-api | 21:50 | |
| *** alex_klimov has joined #openstack-api | 21:52 | |
| *** salv-orlando has quit IRC | 21:55 | |
| *** kaufer has joined #openstack-api | 22:03 | |
| *** salv-orlando has joined #openstack-api | 22:15 | |
| *** kaufer has quit IRC | 22:36 | |
| *** salv-orlando has quit IRC | 23:30 | |
| *** alex_klimov has quit IRC | 23:41 | |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!