16:00:07 <etoews> #startmeeting api wg
16:00:07 <openstack> Meeting started Thu Dec 17 16:00:07 2015 UTC and is due to finish in 60 minutes.  The chair is etoews. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:00:09 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:00:11 <openstack> The meeting name has been set to 'api_wg'
16:00:16 <elmiko> hi
16:00:20 <etoews> good day
16:00:27 <gouthamr_> hello!
16:00:27 <cdent> hellos
16:00:40 <annegentle> hi
16:01:32 <etoews> #topic agenda
16:01:40 <etoews> #link https://wiki.openstack.org/wiki/Meetings/API-WG#Agenda
16:01:47 <etoews> #topic previous meeting action items
16:01:48 <ryansb> hey folks
16:01:56 <etoews> #link http://eavesdrop.openstack.org/meetings/api_wg/2015/api_wg.2015-12-03-16.00.html
16:02:15 <elmiko> i think i covered 2/3 of mine
16:02:29 <elmiko> i'm working on a patch to propose for the developer site
16:02:43 <salv-orlando> aloha
16:03:01 <etoews> and i saw rosmaita created the patch for the version discovery guideline
16:03:24 <elmiko> yea, we've got i think 4 services in the current design for versions
16:03:37 <elmiko> i'd like to get a few more in there for reference, but it's a start
16:03:48 <etoews> link?
16:03:49 <elmiko> and i think we need to have something about microversions in that guideline
16:04:06 <elmiko> #link https://wiki.openstack.org/wiki/API_Working_Group/Current_Design/Version_Responses
16:05:46 <etoews> nice
16:06:02 <elmiko> it's a start
16:06:42 * gouthamr_ makes a note to Add Manila's versions api response to that wiki
16:06:53 <elmiko> ooh, thanks gouthamr_ !
16:06:53 <etoews> thanks gouthamr_
16:07:06 <gouthamr_> :)
16:07:25 <etoews> anyone else want to volunteer adding the version api response to that page?
16:07:39 <etoews> (for the project they usually work on)
16:09:18 <cdent> I'll add for ceilo, gnocchi, aodh
16:09:32 <cdent> (even though I'm not quite usually working on them anymore)
16:10:08 <etoews> #action cdent to add version api response for ceilo, gnocchi, aodh to https://wiki.openstack.org/wiki/API_Working_Group/Current_Design/Version_Responses
16:10:13 <cdent> thanks
16:10:14 <etoews> thanks cdent !
16:10:27 <elmiko> thanks cdent =)
16:10:34 <etoews> ryansb: are you still working on heat mostly? (nudge nudge)
16:10:49 <ryansb> etoews: zaqar as well
16:11:04 <etoews> care to add to that page?
16:11:09 <ryansb> most of my upstream is zaqar atm, but I expect heat to broaden its share in the future
16:11:58 <ryansb> yeah sure
16:12:16 <ryansb> I'm not sure what heat does, I know zaqar presents a pretty good version schema
16:12:35 <etoews> #action ryansb to add version api response for heat, zaqar to https://wiki.openstack.org/wiki/API_Working_Group/Current_Design/Version_Responses
16:12:42 <etoews> thanks
16:12:50 <elmiko> yay, thanks ryansb !
16:13:00 * ryansb adds to todo list
16:13:23 <ryansb> I'm going to be out Dec 21-Jan 1, btw, but I'll try and get it done before holiday
16:13:55 <etoews> any topics anyone would like to discuss in particular?
16:14:10 <elmiko> i have a quick one
16:14:29 <etoews> shoot
16:14:53 <elmiko> cool, so the OpenStack Security Project (OSSP) is doing outreach to all the project teams
16:15:10 <elmiko> and i wanted to bring it up with this group
16:15:10 <etoews> #topic ossp
16:15:27 <elmiko> the main security stuff is at https://security.openstack.org/
16:15:50 <elmiko> there are some cool api fuzzing efforts that have been going on recently
16:15:57 <elmiko> which may be a some interest to this gourp
16:16:04 <annegentle> what's api fuzzing?
16:16:13 * annegentle honestly hasn't heard of it
16:16:40 <elmiko> api fuzzing is an operation whereby an application will send bad, bogus, or random string to a server's endpoints
16:16:55 <elmiko> this is in an attempt to find vulnerabilities or errors in the server
16:17:02 <annegentle> ah, okay
16:17:14 <elmiko> there have been a few examples already of fuzzing finding bugs in neutron, for example
16:17:37 <etoews> annegentle: akin to system call fuzzing like http://codemonkey.org.uk/projects/trinity/
16:17:39 <elmiko> so, the OSSP has a project called Syntribos which is a fuzzer
16:18:19 <cdent> how is that pronounced? I have to kind of read through it without hearing it...
16:18:37 <elmiko> i think, sin tri bos
16:18:54 <elmiko> long o on bos
16:19:01 <annegentle> try or tree?
16:19:09 <elmiko> tree
16:19:28 <elmiko> sin-tree-bose
16:19:38 <ryansb> don't worry - 99% of the time you'll only need to say it on the ML ;)
16:19:49 <elmiko> true
16:20:11 <cdent> :)
16:20:27 <elmiko> anyway, i just wanted to help raise awareness about the project and if we might have cross-over into security stuff, they are a resource we can go to.
16:21:14 <elmiko> #link https://security.openstack.org/
16:21:15 <etoews> elmiko: do you have a link to the project?
16:21:23 <elmiko> #link https://wiki.openstack.org/wiki/Security
16:21:26 <elmiko> sure, 1 sec
16:21:29 <etoews> the api fuzzer in particular
16:21:38 <elmiko> #link https://github.com/openstack/syntribos
16:21:59 <elmiko> #link https://github.com/redhat-cip/restfuzz
16:22:09 <elmiko> that is another fuzzer which has been discussed as well
16:22:49 * etoews plans to read through https://security.openstack.org/#secure-development-guidelines
16:23:18 <annegentle> nice
16:23:23 <cdent> tristan noodled briefly about trying to use gabbi for restfuzz but I think he eventually decided it wasn't really going to work
16:23:53 <cdent> but we talked about revisiting that at some point, as there are plenty of ways to make gabbi do things other than static yaml
16:23:59 <elmiko> yea, i had brought up gabbi in the early days of the OSSP talking about fuzzing
16:24:26 <cdent> Did I ever link the hypothesis + gabbi blog posting here?
16:24:40 <elmiko> in the end, the fuzz tests need more dynamism than gabbi had at the time
16:24:45 <elmiko> cdent: i don't think so
16:24:53 <cdent> http://wildfish.com/blog/2015/10/01/using-gabbi-and-hypothesis-test-django-apis/
16:25:03 <elmiko> neat, thanks!
16:25:19 <cdent> hypothesis is something we should be using all over openstack
16:25:48 <elmiko> i'm not familiar with it
16:27:04 <elmiko> sounds cool from the blog post
16:27:33 <etoews> thanks for highlighting that elmiko
16:27:53 <elmiko> np, thanks =)
16:28:01 <etoews> #topic guidelines dashboard
16:28:10 <etoews> #link http://ghostcloud.net/openstack_gerrit_dashboards/dashboard_api-wg.html
16:28:49 <elmiko> would be cool if those dashboards had a direct link to just run them
16:29:24 <etoews> yes it would
16:29:30 <elmiko> #link https://review.openstack.org/#/c/208264/
16:29:42 <elmiko> will that one ever get merged?
16:30:53 <elmiko> i guess it all flows up to this one #link https://review.openstack.org/#/c/181393/
16:31:29 * cdent nods
16:31:47 <etoews> how's the Service Catalog standardization effort going annegentle ?
16:33:41 <annegentle> etoews: getting there
16:33:54 <annegentle> #link https://wiki.openstack.org/wiki/API_Working_Group/Current_Design/Service_Catalog#Project_IDs
16:33:57 <annegentle> latest effort ^^
16:34:22 <annegentle> figuring out which projects have project_id or tenant_id in the catalog endpoint entry
16:34:41 <annegentle> and, updated the spec itself this week
16:34:42 <annegentle> #link https://review.openstack.org/#/c/181393/
16:35:07 <annegentle> that's all I have this week
16:35:18 <etoews> wow. that's a lot of work.
16:35:26 <annegentle> etoews: heh no joke
16:35:59 <elmiko> annegentle: quick question, how did you get all the private cloud catalog data?
16:36:16 <annegentle> elmiko: emailed people and they sent them to me
16:36:31 <annegentle> elmiko: I have a bunch of contacts hahaha
16:36:31 <elmiko> neat, very nice on the current design page too
16:36:40 <etoews> annegentle: bonne chance
16:36:40 <annegentle> thanks, getting there
16:36:54 <etoews> is there anything we can do to help the microversion guidelines along?
16:37:20 <elmiko> i *think* it's still waiting for an update
16:38:06 <elmiko> hmm, looks like it just needs more reviews now
16:40:10 <cdent> it's in my queue (with lots of other stuff :( )
16:40:26 <etoews> i hear ya
16:40:33 <elmiko> +1
16:41:45 <etoews> should i add all of the CPLs to the microversion guidelines?
16:42:02 <etoews> get more eyes on them...
16:42:30 <annegentle> might work
16:42:32 <elmiko> i dunno, might be best to at least get a pass by the wg for consistency then send it up
16:43:25 <elmiko> although, it is on set 4...
16:44:06 <annegentle> this time of year, who knows
16:44:23 <elmiko> good point
16:44:43 <cdent> Next two weeks not a lot gonna happen...
16:46:37 <elmiko> etoews: looking at it again, i have no objection to adding the CPLs
16:47:07 <etoews> it would nice to unstick this one https://review.openstack.org/#/c/196918/
16:47:24 <elmiko> +1
16:47:44 <elmiko> i think it's all bundled up with the service catalog stuff though
16:47:50 <cdent> yes
16:48:47 <etoews> we need to find a way forward without depending so much on service catalog standardization
16:48:57 <etoews> that's just going to take a really long time
16:49:10 <cdent> the conceptual stuff should resolve relatively soon
16:49:56 <etoews> sigh
16:50:04 <elmiko> etoews: agreed, but we got bogged down in the whole service name vs project name stuff
16:50:20 <etoews> project names are silly. period.
16:50:31 <etoews> :)
16:50:38 <elmiko> qotd, imo ;)
16:51:22 <etoews> is there any point in adding CPLs to anything right now? seems extremely unlikely anything is really going to happen over the next 2 week.
16:51:48 <elmiko> probably not
16:52:16 <etoews> how about https://review.openstack.org/#/c/190743/ ?
16:52:52 <elmiko> probably good for freeze material
16:53:03 <etoews> it went through some substantial discussion since the last freeze so should be frozen again.
16:53:18 <elmiko> agreed
16:53:20 <etoews> but again we hit the timing of it
16:53:38 <elmiko> should we just push on all freezes until after break?
16:53:45 <etoews> freeze tomorrow and merge on christmas day! :D
16:53:51 <elmiko> (also, should we cancel the next 2 meetings?)
16:54:01 <elmiko> haha, nice
16:54:02 <etoews> yes to cancelling meetings
16:54:06 <cdent> yes cancel
16:54:09 <cdent> Before we end the meeting I've got an open topic to raise, please let me know when we've reached that point.
16:54:40 <etoews> okay. let's push off freezes and review pestering until the new year.
16:54:43 <etoews> shoot cdent
16:54:44 <elmiko> +1
16:55:38 <cdent> I think we've covered this ground before but it's just come back up again in telemetry: what do with url elements that contain '/'?
16:55:52 <cdent> Web servers will often not preserve %2F
16:56:22 <etoews> ummmm...not have '/' as url elements?
16:56:36 <elmiko> i'm not sure on the proper handling for that
16:56:38 <etoews> that just seems like you're asking for trouble
16:56:43 <elmiko> yea
16:56:50 <etoews> all up and down the stack
16:56:51 <cdent> in this case it is ids being used elsewhere in openstack
16:57:10 <cdent> and yeah, everyone knows it is borked
16:57:13 <cdent> but they're still out there
16:57:20 <etoews> that's epically bad
16:57:47 <cdent> what I'm wondering is: are there existing solutions for the web server problem with dealing with %2F?
16:57:51 <elmiko> is it feasable to migrate away from those urls?
16:58:04 <cdent> In the past I've done this: https://github.com/tiddlyweb/tiddlyweb/blob/master/tiddlyweb/web/serve.py#L95
16:58:24 <cdent> It is probably possible to migrate, but it will be slow, deprecation, laziness etc
16:58:36 * elmiko nods
16:59:16 <elmiko> i'm kinda at a loss on this one, i don't know any solutions off the top of my head
16:59:24 <etoews> no ideas come to my mind. that's uncharted territory for me. i think i'm in shock a bit.
16:59:37 <etoews> elmiko++
17:00:06 <etoews> thanks to everyone for a great year!!!
17:00:06 <cdent> To me it a fundamental flaw in web servers, with the precent set by apache a very long time ago.
17:00:07 <elmiko> maybe something to research for next time
17:00:17 <etoews> #endmeeting