20:05:15 #startmeeting barbican 20:05:16 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 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 20:05:19 The meeting name has been set to 'barbican' 20:06:20 As usual the meeting agenda can be found here: 20:06:22 #link https://wiki.openstack.org/wiki/Meetings/Barbican 20:06:25 #topic Roll Call 20:06:32 heyo/ 20:06:32 o/ 20:06:33 o/ 20:06:34 o/ 20:06:35 o/ 20:06:37 o/ 20:06:44 o/ kinda here 20:06:50 o/ 20:07:24 awesome! lots of barbicaneers here 20:07:31 #topic Action Items 20:07:41 #link http://eavesdrop.openstack.org/meetings/barbican/2015/barbican.2015-05-04-20.01.html 20:08:35 First action item from last week was the Oslo Versioned Objects Spec 20:08:45 which it looks like x3k did submit 20:08:47 #link https://review.openstack.org/#/c/174318/ 20:09:04 redrobot, yes 20:09:29 Next action items were on me, and I have yet to get to them, so 20:09:41 #action redrobot to talk to Greg Swift about DB being used in Fedora 20:09:48 #action redrobot to clean up the barbican-specs repo 20:09:58 Next action items are for woodster_ 20:10:12 woodster_ did you get a chance to look into the mutability of Generic Containers? 20:10:20 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 secrets, PUT is better. 20:10:44 o/ 20:11:09 redrobot: so do we need a blueprint to make the PUT to genetic containers official? 20:11:56 woodster_ I think that, if Containers don't currently support PUT, then yes, a blueprint would be a good first step. 20:13:14 ok, moving on to our agenda items 20:13:35 #topic ACL API changes 20:13:53 arunkant did you want to talk about this? 20:14:35 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 #link https://review.openstack.org/#/c/178479/5/doc/source/api/quickstart/acls.rst,cm 20:15:19 So the proposal is to remove /secrets_or_containers/{uuid}/acls/{uuid} calls . 20:16:06 And only have PUT/PATCH/DELETE operation on /secrets_or_containers/{uuid}/acl (single acl resource) 20:16:32 There is also a sample code change available here: 20:16:35 #link https://review.openstack.org/#/c/180888/ 20:16:53 It simplifies the ACL operation and client does not have worry about internal structure of ACL (i.e. ACL uuid etc.).. 20:17:56 So was hoping to get community inputs..if it looks okay to them? 20:18:15 Is anyone opposed to this approach? 20:18:20 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 I have not kept up as much with this stuff, so I will abstain. 20:18:57 I'm still reviewing it, but I think the approach is nice 20:18:57 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 I believe that was in the original spec as well 20:19:29 not having a UUID for each ACL makes them easier to use. I like it. 20:19:32 at least as it was described in the discussion in the documentation CR 20:19:48 yup, pretty good improvement in usability 20:19:57 That code CR above implements it as well. 20:20:10 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 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 I think redrobot is reffering to the initial blueprint 20:20:53 that, it should have been caught there, which it should have 20:21:17 redrobot, most likely these changes will need to be ported to kilo as well as they are significant API changes . 20:21:23 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 ouch 20:21:41 ouh 20:21:47 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 oh that's tricky 20:23:15 we'll definitely catch some grief for this :( 20:23:34 but I do want to backport the new API that agrees with the original SPEC back into Kilo 20:23:54 another option would be to make a new API micro-version 20:24:14 What is a micro-version? 20:24:21 rellerreller glad you asked! :) 20:24:23 +1 for microversions 20:24:29 something like Barbican API v1.1 20:24:41 we had to start thinking about versions at some point anyway 20:24:42 Micro-versions are the recommended way to do minor API changes. 20:25:00 basically adding a new Header X-Barbican-Version or something like that 20:25:33 so does that mean we need to support the v1 acls resource then (including gate/functional testing)? 20:25:49 there are significant changes../{secrets}/{uuid}/acls <--- resource does not exist in new changes. 20:26:17 making the functional tests honor versioning will be required 20:26:20 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 yep, so I think that would be on a new path then?: /v1.1/secrets/{UUID}/acl ? 20:26:55 woodster_ if we choose to do a micro-api, yes, we would still support the APIs that shipped in Kilo. 20:27:01 new path plus updates to actually use the path to make version-based decisions 20:27:05 woodster_ no, micro-versions do not change the URI 20:27:16 woodster_ micro-versions are specified by a header 20:27:20 oh, cool 20:27:58 elmiko thanks for the linkx 20:28:13 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 dave-mccowan I agree with you, and I'm willing to take the heat if anyone gripes about it. 20:30:01 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 redrobot +1 20:31:16 yea, +1 to backport 20:31:46 redrobot, I can publish update docs CR to reflect new changes so that request/response content can be viewed to verify 20:31:56 backporting will probably lead to less hassle, as then we won't need to support the way it's in kilo. 20:32:26 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 arunkant I think that having an updated doc CR would definitely help reviewers for the implementation CR 20:33:18 so should we land the code CR first (which would unblock functional testing I suppose), or the doc CR? 20:33:32 redrobot: that sounds good 20:34:10 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 okay, I can keep docs CR in sync with API changes 20:34:39 I guess there is also the change that someone will see the docs and thing the feature is ready to use 20:34:50 woodster_: right 20:35:35 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 +1 20:36:42 makes sense 20:36:55 ok, I think we're all in agreement then. please be on the lookout for arunkant's changes for review. 20:37:22 #topic Muti-user Functional Testing 20:37:30 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 dave-mccowan do you want to talk about this topic? 20:37:42 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 Without these users then tests in test_rbac.py (and later test_acs.py) will fail. 20:38:41 dave-mccowan thanks for adding all those tests btw! 20:38:58 dave-mccowan although they may need to change after arunkant's changes 20:38:58 +oo 20:39:44 alrighty, that's all that's on the agenda for today 20:39:53 no meeting next week, since most of us will be in Vancouver. 20:40:19 #topic Vancouver Design Summit 20:40:50 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 I'll also be adding topics to the working sessions today/tomorrow. 20:41:43 please ping me with any conflicts. I want to make sure that interested parties get to attend relevant sessions 20:41:43 redrobot: I'll be arriving there on Saturday too 20:41:53 jaosorior Saturday night beers? 20:42:14 http://weknowmemes.com/wp-content/uploads/2012/11/mexcellent.jpg 20:42:25 sounds like a late Sunday morning/afternoon 'breakfast' to me :) 20:42:36 lol 20:43:13 any other questions/coments? 20:43:16 redrobot: will ping you when I'm in Vancouver then 20:43:22 Anybody else gonna be around on Saturday? 20:43:25 jaosorior sounds like a plan! 20:44:56 I get in Sunday 2:30pm so I'm up for some investigating 20:45:02 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 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 that doesn't sound good lol 20:46:47 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 lol, poor guy 20:47:03 aaaanyway, see you guys in Vancouver then. hockeynut, ping us when you're there 20:47:15 yessir! 20:47:22 yup, thanks for coming everyone! Looking forward to seeing many of you in Vancouver! 20:47:32 #endmeeting