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