18:59:27 #startmeeting Poppy Weekly Meeting 18:59:28 Meeting started Thu Jun 18 18:59:27 2015 UTC and is due to finish in 60 minutes. The chair is amitgandhinz. Information about MeetBot at http://wiki.debian.org/MeetBot. 18:59:29 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 18:59:31 The meeting name has been set to 'poppy_weekly_meeting' 18:59:33 #topic RollCall 19:00:40 o/ 19:00:46 o/ 19:01:07 o/ 19:01:25 o/ 19:02:03 o/ 19:02:09 #link Agenda - https://wiki.openstack.org/wiki/Meetings/Poppy 19:02:22 o/ 19:02:26 #topic Last Weeks Action Items 19:02:42 #link http://eavesdrop.openstack.org/meetings/poppy_weekly_meeting/2015/poppy_weekly_meeting.2015-06-11-19.01.html 19:03:03 1. malini did you groom the bugs? 19:03:10 * amitgandhinz i know i didnt get to that =( 19:03:32 me neither 19:03:38 ok carry this forward 19:03:47 #action amitgandhinz and malini to groom the bugs 19:03:49 I'll surely get to it by then 19:04:03 2. malini to sync up with michael xin regarding security tests 19:04:24 that happened :) 19:04:38 malini: you want to give a quick recap of the conversation and the action items out of it 19:04:41 So Mike & co are going to first address the outstanding patches 19:04:55 there are 3 of them tht needs rebase, updates etc. 19:05:26 Once those are merged, we'll have more patches from them - maybe we shud have an actio item rolling over every week to add new tests? 19:05:57 #action: malini to work with Mike Xin & get the outstanding patches merged 19:06:05 ugh you beat me to it 19:06:13 jian5397: ^ 19:06:50 #topic Liberty 1 Updates 19:06:53 #link https://launchpad.net/poppy/+milestone/liberty-1 19:07:09 https://blueprints.launchpad.net/poppy/+spec/host-header-forwarding 19:07:17 anantha has this in code review 19:07:22 can everyone please review it 19:07:40 we should try to get this merged 19:07:42 sure 19:07:52 will do 19:07:55 Yep, I've addressed all previous comments by malini and obulpathi 19:08:06 thx anantha 19:08:10 will review 19:08:13 thanks 19:08:17 https://blueprints.launchpad.net/poppy/+spec/security-testing 19:08:26 malini: jian5397: ^ 19:08:33 i guess malini needs to bug jian5397 for this =P 19:08:45 ok - I can do tht 19:08:52 bugging is my second nature ;) 19:08:55 miqui: https://blueprints.launchpad.net/poppy/+spec/devstack 19:10:20 sriram worked on https://blueprints.launchpad.net/poppy/+spec/log-delivery 19:10:32 we need to get that merged too 19:10:54 obulpathi: https://blueprints.launchpad.net/poppy/+spec/enable-disable-service 19:11:11 its done 19:11:25 wait, 19:11:29 although anantha is working on moving it to an admin endpoint 19:11:34 ananta is changing the implementation 19:11:37 yep 19:11:57 ok i will keep the status as in progress. anantha i guess this is the bp you need to reference ;-) 19:12:09 talking abt admin endpoint - shud we also move create/delete flavors there? 19:12:18 Oh I see. I created a new BP. 19:12:47 malini: thats a good idea 19:12:51 malini: possibly. although i kind of like the restful natire of those endpoints as they are currently 19:13:10 is the admin endpoint unresty? 19:13:33 a little bit only because admin isnt actually an entity 19:14:05 do we really need tht /admin in the url? 19:14:18 also, creating/deleting flavors are actions against the flavor entity itself and we can restrict access to them 19:14:40 hmmm.... 19:14:52 we have create/delete flavors doc'ed in the RS Admin Guide... guess it is in the right place :) 19:14:57 so we could have POST /services/state { ... } 19:15:07 cathR: yup 19:15:16 amitgandhinz: possibly 19:15:20 and then lock that url to operators only 19:15:28 yeap 19:15:32 likewise /domains/domain_name 19:15:40 so we dont segment them into an admin path 19:15:57 but we just lock those urls down in the rbac/repose component 19:16:03 yeap 19:16:35 shall i change the code? One PR is already out 19:17:01 does anyone have concerns with this structure? 19:17:16 #info get rid of /admin/... endpoints 19:17:39 #info use /services/state { ... } for updating a state and restrict access in repose 19:17:47 /services/state 19:17:53 +1 with passing stuff in the body instead of in url 19:17:57 #info use /domains/{domian_name} and resrtict access in repose 19:18:02 hmm .. won't pecan interpret the state as uuid? 19:18:22 obulpathi is right 19:19:04 what about PATCH /services { "field } 19:19:14 or we can have services/service_id/state? 19:19:15 what about PATCH /services { "field" : "state", "value": "enabled", } 19:19:22 but then we'll have problems restricting access -rt? 19:19:32 patch will be difficult to implement 19:19:33 malini: we can still restrict that access 19:19:49 but then we will have serviceid in url and in body = duplication 19:20:05 because at the identity level we don't know what is allowed by user and what is by admin 19:20:31 I think we should put service id for /state endpoint in the body 19:20:38 +1 19:20:41 we need to look into patch body and infer if thats admin only update or user allowed update 19:20:57 +1 to tonytan4ever's idea 19:20:57 can repose do tht? 19:21:06 no 19:21:18 repose can only check url's and roles 19:22:09 how bad is it really to duplicate the service id in the url and the body? 19:22:17 or not include it in the body 19:22:26 or is that just weird and confusing 19:23:31 The service id in url makes me think if we are doing something with the admin user's service 19:23:37 That's the confusing part. 19:23:43 good point 19:24:16 amitgandhinz: u meant PATCH /service/{id}/state ? 19:24:24 ya 19:24:44 {'id': ''ss', 'state': 'disabled'} 19:24:45 or should we implement admin api separately? 19:24:52 like admin.cdn.com? 19:24:57 but then is that {id} a service that belongs to the privileged user making this call, or a customers's service id 19:25:14 obulpathi: i like the idea of it all being part of poppy 19:25:22 makes it easier to deploy and maintain 19:25:33 grr…this is getting messy 19:25:43 how do everybody else do that? 19:25:52 ok .. lets think about this for this week 19:26:11 we can always iterate & make this better 19:26:26 for now lets continue with tthe /admin/... patch that is already out there and then iterate on it 19:26:33 +1 19:27:00 ok moving on... 19:27:05 tonytan4ever: https://blueprints.launchpad.net/poppy/+spec/geo-restrictions 19:27:35 This one is yet to be started. 19:28:06 slackorama: does edgecast have some good docs on how its API implemented geo restrictions and what countrycodes/regions are supported? 19:28:30 Planning to start it tomorrow. We will need to think about supported country codes and region codes though 19:29:11 amitgandhinz: Not really. Frankly, it's kind of a PITA to do it via the API. 19:29:21 we may want to make the list of regions presented by poppy configurable (db table?) and then have a mapping to providers supported country codes 19:30:04 slackorama: why is that? 19:32:11 amitgandhinz: because it's done via xml inside of a json object via an undocumented beta API. 19:32:19 wow!! 19:32:23 ouch 19:32:40 xml inside of json - tht takes creativity :) 19:32:46 i think that pretty much is a textbook definition for PITA. 19:33:41 im just glad that openstack has dropped support for xml 19:34:16 and final bp - anantha https://blueprints.launchpad.net/poppy/+spec/operator-state-api 19:34:26 this is the same as obulpathi one right? 19:34:30 Yep 19:34:43 ok, lets use the original one obulpathi had, and get rid of this oen 19:34:55 #topic OpenDiscussion 19:35:17 anyone have any specific topics to discuss? 19:35:32 slackorama: are is it going getting poppy up and running? 19:35:40 s/are/how 19:36:24 amitgandhinz: I have it up and running (thanks obulpathi). working on the driver as much as I can. 19:36:44 you are welcome :) 19:36:47 I havent been able to update the end to end tests yet :/ 19:36:52 will get to it after next week 19:37:02 most of us are active in poppy channel from 9 - 5 EST 19:37:42 so if you have any questions, that would be the best time 19:37:49 cool let us know how we can help you 19:38:01 and how to make this process better 19:38:09 thanks. 19:38:49 ok any topics to be discussed? 19:38:59 none from me 19:39:08 I am good. 19:39:13 I am good 19:39:24 I'm good. 19:39:35 okay. thanks everyone =) 19:39:45 #endmeeting