20:05:15 <redrobot> #startmeeting barbican 20:05:16 <openstack> Meeting started Mon May 11 20:05:15 2015 UTC and is due to finish in 60 minutes. The chair is redrobot. Information about MeetBot at http://wiki.debian.org/MeetBot. 20:05:17 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 20:05:19 <openstack> The meeting name has been set to 'barbican' 20:06:20 <redrobot> As usual the meeting agenda can be found here: 20:06:22 <redrobot> #link https://wiki.openstack.org/wiki/Meetings/Barbican 20:06:25 <redrobot> #topic Roll Call 20:06:32 <elmiko> heyo/ 20:06:32 <dave-mccowan> o/ 20:06:33 <rellerreller> o/ 20:06:34 <hockeynut> o/ 20:06:35 <arunkant> o/ 20:06:37 <woodster_> o/ 20:06:44 <rm_work> o/ kinda here 20:06:50 <kfarr> o/ 20:07:24 <redrobot> awesome! lots of barbicaneers here 20:07:31 <redrobot> #topic Action Items 20:07:41 <redrobot> #link http://eavesdrop.openstack.org/meetings/barbican/2015/barbican.2015-05-04-20.01.html 20:08:35 <redrobot> First action item from last week was the Oslo Versioned Objects Spec 20:08:45 <redrobot> which it looks like x3k did submit 20:08:47 <redrobot> #link https://review.openstack.org/#/c/174318/ 20:09:04 <x3k> redrobot, yes 20:09:29 <redrobot> Next action items were on me, and I have yet to get to them, so 20:09:41 <redrobot> #action redrobot to talk to Greg Swift about DB being used in Fedora 20:09:48 <redrobot> #action redrobot to clean up the barbican-specs repo 20:09:58 <redrobot> Next action items are for woodster_ 20:10:12 <redrobot> woodster_ did you get a chance to look into the mutability of Generic Containers? 20:10:20 <woodster_> elmiko asked the API WG on our behalf about POST vs PUT. They said as long as the resultant URI didn't change in a request, PUT was perferred. IF the URI changes (say due to a new unique UUID being generated) then POST is appropriate. So for ACL updates on a secret with no UUIDs involved, then PUT is better. For Container updates to change the list of 20:10:20 <woodster_> secrets, PUT is better. 20:10:44 <jaosorior> o/ 20:11:09 <woodster_> redrobot: so do we need a blueprint to make the PUT to genetic containers official? 20:11:56 <redrobot> woodster_ I think that, if Containers don't currently support PUT, then yes, a blueprint would be a good first step. 20:13:14 <redrobot> ok, moving on to our agenda items 20:13:35 <redrobot> #topic ACL API changes 20:13:53 <redrobot> arunkant did you want to talk about this? 20:14:35 <arunkant> During ACL docs review, John has proposed some changes which are related to ACL API ..https://review.openstack.org/#/c/178479/5/doc/source/api/quickstart/acls.rst,cm Line 237 20:15:14 <redrobot> #link https://review.openstack.org/#/c/178479/5/doc/source/api/quickstart/acls.rst,cm 20:15:19 <arunkant> So the proposal is to remove /secrets_or_containers/{uuid}/acls/{uuid} calls . 20:16:06 <arunkant> And only have PUT/PATCH/DELETE operation on /secrets_or_containers/{uuid}/acl (single acl resource) 20:16:32 <woodster_> There is also a sample code change available here: 20:16:35 <woodster_> #link https://review.openstack.org/#/c/180888/ 20:16:53 <arunkant> It simplifies the ACL operation and client does not have worry about internal structure of ACL (i.e. ACL uuid etc.).. 20:17:56 <arunkant> So was hoping to get community inputs..if it looks okay to them? 20:18:15 <woodster_> Is anyone opposed to this approach? 20:18:20 <redrobot> So I think that the proposed changes are more in-line with the original SPEC, so I am in favor of it 20:18:49 <rellerreller> I have not kept up as much with this stuff, so I will abstain. 20:18:57 <jaosorior> I'm still reviewing it, but I think the approach is nice 20:18:57 <woodster_> This also includes moving from 'acls' to 'acl' as the resource name, as the resource appears to the client as a single resource 20:19:14 <woodster_> I believe that was in the original spec as well 20:19:29 <dave-mccowan> not having a UUID for each ACL makes them easier to use. I like it. 20:19:32 <jaosorior> at least as it was described in the discussion in the documentation CR 20:19:48 <jaosorior> yup, pretty good improvement in usability 20:19:57 <woodster_> That code CR above implements it as well. 20:20:10 <redrobot> One comment that arunkant made that I agree with is that these changes should have been caught in the original review. The doc CR was only documenting the API that we had previously approved. 20:20:25 <woodster_> So should the doc or code CRs land first? Is the code CR one that needs to make it into Kilo final release? 20:20:46 <jaosorior> I think redrobot is reffering to the initial blueprint 20:20:53 <jaosorior> that, it should have been caught there, which it should have 20:21:17 <arunkant> redrobot, most likely these changes will need to be ported to kilo as well as they are significant API changes . 20:21:23 <redrobot> Yeah, we're in a bit of a pickle, because the API we shipped in Kilo is not what the SPEC or the revised docs describe 20:21:38 <elmiko> ouch 20:21:41 <jaosorior> ouh 20:21:47 <woodster_> yeah, it might be helpful for API-impacting blueprints to have detailed API docs in them...makes it easy to cut/paste into the docs too 20:22:02 <woodster_> oh that's tricky 20:23:15 <redrobot> we'll definitely catch some grief for this :( 20:23:34 <redrobot> but I do want to backport the new API that agrees with the original SPEC back into Kilo 20:23:54 <redrobot> another option would be to make a new API micro-version 20:24:14 <rellerreller> What is a micro-version? 20:24:21 <redrobot> rellerreller glad you asked! :) 20:24:23 <elmiko> +1 for microversions 20:24:29 <jaosorior> something like Barbican API v1.1 20:24:41 <jaosorior> we had to start thinking about versions at some point anyway 20:24:42 <redrobot> Micro-versions are the recommended way to do minor API changes. 20:25:00 <redrobot> basically adding a new Header X-Barbican-Version or something like that 20:25:33 <woodster_> so does that mean we need to support the v1 acls resource then (including gate/functional testing)? 20:25:49 <arunkant> there are significant changes../{secrets}/{uuid}/acls <--- resource does not exist in new changes. 20:26:17 <hockeynut> making the functional tests honor versioning will be required 20:26:20 <elmiko> if anyone wants additional reading on microversions, here is nova's spec #link http://specs.openstack.org/openstack/nova-specs/specs/kilo/implemented/api-microversions.html 20:26:41 <woodster_> yep, so I think that would be on a new path then?: /v1.1/secrets/{UUID}/acl ? 20:26:55 <redrobot> woodster_ if we choose to do a micro-api, yes, we would still support the APIs that shipped in Kilo. 20:27:01 <hockeynut> new path plus updates to actually use the path to make version-based decisions 20:27:05 <redrobot> woodster_ no, micro-versions do not change the URI 20:27:16 <redrobot> woodster_ micro-versions are specified by a header 20:27:20 <woodster_> oh, cool 20:27:58 <redrobot> elmiko thanks for the linkx 20:28:13 <dave-mccowan> i don't think the current shipping kilo API has any complete documentation. i would vote to fix and document the new API, and retire the old undocumented API. (I understand that is bad form.) 20:29:08 <redrobot> dave-mccowan I agree with you, and I'm willing to take the heat if anyone gripes about it. 20:30:01 <redrobot> micro-version was a suggestion, to get you guys thinking about them. But I still think backporting the API updates that arunkant is working on is my preferred fix for this. 20:30:51 <dave-mccowan> redrobot +1 20:31:16 <elmiko> yea, +1 to backport 20:31:46 <arunkant> redrobot, I can publish update docs CR to reflect new changes so that request/response content can be viewed to verify 20:31:56 <jaosorior> backporting will probably lead to less hassle, as then we won't need to support the way it's in kilo. 20:32:26 <redrobot> awesome, as soon as arunkant's changes land, I'll backport them into stable/kilo, and then get the ball rolling on releasing 2015.1.1 20:33:04 <redrobot> arunkant I think that having an updated doc CR would definitely help reviewers for the implementation CR 20:33:18 <woodster_> so should we land the code CR first (which would unblock functional testing I suppose), or the doc CR? 20:33:32 <woodster_> redrobot: that sounds good 20:34:10 <elmiko> tough question, i like redrobot's thought about the doc CR helping reviewers but it does seem out of order that way 20:34:38 <arunkant> okay, I can keep docs CR in sync with API changes 20:34:39 <woodster_> I guess there is also the change that someone will see the docs and thing the feature is ready to use 20:34:50 <elmiko> woodster_: right 20:35:35 <redrobot> yeah, I don't necessarily think that the Doc CR should land first. Just that it would be nice to have it in review to use for reference. 20:36:21 <woodster_> +1 20:36:42 <elmiko> makes sense 20:36:55 <redrobot> ok, I think we're all in agreement then. please be on the lookout for arunkant's changes for review. 20:37:22 <redrobot> #topic Muti-user Functional Testing 20:37:30 <dave-mccowan> I just want to give people a heads up on an upcoming change to functional tests. Now, all functional tests run as an admin user. In order to test RBAC or ACLs, we needed run-as-user support. 20:37:30 <redrobot> dave-mccowan do you want to talk about this topic? 20:37:42 <dave-mccowan> This is implemented in https://review.openstack.org/#/c/176615/. When this merges, then in order to run functional tests locally, your local keystone deployment will need 6 new users and 3 new roles added. bin/keystone_data.sh can do it, or has the info you need to add them. 20:37:52 <dave-mccowan> Without these users then tests in test_rbac.py (and later test_acs.py) will fail. 20:38:41 <redrobot> dave-mccowan thanks for adding all those tests btw! 20:38:58 <redrobot> dave-mccowan although they may need to change after arunkant's changes 20:38:58 <hockeynut> +oo 20:39:44 <redrobot> alrighty, that's all that's on the agenda for today 20:39:53 <redrobot> no meeting next week, since most of us will be in Vancouver. 20:40:19 <redrobot> #topic Vancouver Design Summit 20:40:50 <redrobot> I'll be flying into Vancouver Saturday Night, so if anyone wants to go check out the town on Sunday let me know 20:41:24 <redrobot> I'll also be adding topics to the working sessions today/tomorrow. 20:41:43 <redrobot> please ping me with any conflicts. I want to make sure that interested parties get to attend relevant sessions 20:41:43 <jaosorior> redrobot: I'll be arriving there on Saturday too 20:41:53 <redrobot> jaosorior Saturday night beers? 20:42:14 <jaosorior> http://weknowmemes.com/wp-content/uploads/2012/11/mexcellent.jpg 20:42:25 <woodster_> sounds like a late Sunday morning/afternoon 'breakfast' to me :) 20:42:36 <elmiko> lol 20:43:13 <redrobot> any other questions/coments? 20:43:16 <jaosorior> redrobot: will ping you when I'm in Vancouver then 20:43:22 <jaosorior> Anybody else gonna be around on Saturday? 20:43:25 <redrobot> jaosorior sounds like a plan! 20:44:56 <hockeynut> I get in Sunday 2:30pm so I'm up for some investigating 20:45:02 <redrobot> jaosorior I think people may have heard about what happened last time you and I went out drinking together in Paris... I would be scared too. 20:45:49 <jaosorior> redrobot: I am getting an interesting international reputation. I also scared some people from the office in Hungary in another trip haha 20:46:08 <elmiko> that doesn't sound good lol 20:46:47 <jaosorior> they had a lot of fun. But one of them ended up pretty lost in the city and had a hard time getting back to his hotel 20:47:02 <redrobot> lol, poor guy 20:47:03 <jaosorior> aaaanyway, see you guys in Vancouver then. hockeynut, ping us when you're there 20:47:15 <hockeynut> yessir! 20:47:22 <redrobot> yup, thanks for coming everyone! Looking forward to seeing many of you in Vancouver! 20:47:32 <redrobot> #endmeeting