20:02:02 #startmeeting barbican 20:02:03 Meeting started Mon Apr 21 20:02:02 2014 UTC and is due to finish in 60 minutes. The chair is redrobot. Information about MeetBot at http://wiki.debian.org/MeetBot. 20:02:04 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 20:02:07 The meeting name has been set to 'barbican' 20:02:23 welcome everyone to the Barbican weekly meeting 20:02:42 As usual the agenda can be found here: 20:02:45 #link https://wiki.openstack.org/wiki/Meetings/Barbican 20:03:22 Looks like we don't have much on the agenda for today 20:03:40 can I get a show of hands for the Barbican meeting? 20:03:54 I have 2 topic to discuss 20:03:57 o/ 20:04:00 o/ 20:04:01 o/ 20:04:04 o/ 20:04:05 o/ 20:04:41 atiwari: not quite on topic but I just finished reviewing 82189. I've put some comments and removed my -2 20:04:54 awesome, lots of peeps here 20:05:08 I'd like to discuss my cr as well. 20:05:10 reaperhulk great 20:05:28 so in case y'all missed it, we released Icehouse last week 20:05:51 #link https://launchpad.net/barbican/icehouse/icehouse/ 20:06:22 so we're working towards Juno on trunk now 20:06:46 atwiari, what are the topics you want to discuss? 20:07:22 I need some agreement on #link https://review.openstack.org/#/c/88463/ 20:07:35 is the API proposal for order add more type 20:07:45 o/ 20:08:12 o/ 20:08:19 o/ 20:08:45 redrobot, can we hash out summit topics ? 20:09:04 those are my two agendas 20:09:07 #topic Order resource changes to support more types 20:09:22 atiwari, k, let's start with the order changes 20:09:30 sure 20:09:55 has anyone had a chance to review the CR? 20:10:00 I have not. :( 20:10:39 fyi, this API change proposal is based on #link https://gist.github.com/jfwood/9080109 20:11:13 I looked at it 20:11:38 I discussed with woodster 20:11:50 I left a comment about the asymmetric keys and how you would identify both private and public key 20:12:29 rellerreller I replied to your comment 20:12:43 we are going to provide ref to container 20:12:59 in container ther will be multiple refs to secrets 20:13:05 pub and priv 20:13:17 Sounds good 20:14:29 yep, that's correct, the order resource will return a container ref, the container will specify which keys are private/public and if there's an associated passphrase 20:14:48 yep 20:15:07 in case of key type ther will be ref to one secret 20:15:24 line 138 20:15:28 example 20:16:16 anyone else have input on this? Or do we need some time to review it? 20:16:44 redrobot, I am ok with more review 20:16:52 I assume we don't want to merge this? Just use Gerrit for the review? 20:17:00 correct 20:17:16 it would be a good candidate for either an API repo, or for starting our blueprint repo... 20:17:24 I did not find other way to go through review 20:17:39 atiwari, no worries, I don't think we have anything in place right now 20:17:46 redrobot we need a sepoarate repo 20:18:12 redrobot I have stared imp in that direction. just for FYI 20:18:27 which is #link https://review.openstack.org/#/c/87405/ 20:18:36 not ready for review 20:18:52 I'm hopeful we can discuss these design concepts in more detail at the openstack conf as well. 20:19:27 yep, can be keep ball rolling till the summit :) 20:20:11 Ok, looks like there's no more comments on this for now, let's move on to talk about alee's changes to crypto plugin 20:20:22 #topic Crypto plugin changes (DogTag) 20:20:37 alee did you want to talk about this? 20:20:51 cool - it looks like my changes to the crypto plugin interfac went in today - yay :) 20:21:08 now there is also a cr out there for the dogtag plugin itself 20:21:09 #link https://review.openstack.org/#/c/84329/ 20:21:12 sure did 20:21:20 has anyone had a chance to review it ? 20:21:37 I noticed that atiwari did and chadlung 20:22:17 https://review.openstack.org/#/c/85137/ 20:22:30 I am reviewing it right now alee, but am not done 20:22:39 me too 20:22:45 alee, it mostly looks good to me just one comment. which is already not a blocker 20:22:58 as per community members 20:23:03 atiwari, the unit tests? 20:23:13 we need those 20:23:18 unit test 20:23:19 atiwari, I plan to add those as a separate cr 20:23:31 why separate 20:23:36 ? 20:23:52 separate does not make sense to me 20:24:24 doesn't have to be, I can work on them concurrently. The thing is that in order to run the unit tests as part of the build say, we need to be able to install a drm 20:24:55 we can mock it. 20:25:16 you don't need drm for unit test 20:26:00 we don't need a integration test with DRM 20:26:09 yes - I suppose we could - I suppose I can create some mock tests 20:26:23 atiwari: similar to the test_p11_crypto.py test you mean? 20:26:37 although its not clear how valuable such tests would be 20:26:50 yes 20:27:08 alee, I think unit tests are really valuable 20:27:33 Mocks are of substantially less value than a typical unit test, but I'd like to see some way to do some testing 20:27:36 we have been trying to get close to 100% code coverage on crypto tests 20:27:50 that is not a gating requirement though 20:28:23 do we have any gating requirement to ensure our code coverage doesn't drop below its current level? 20:28:45 At this time we do not gate on that, no. We implicitly gate on it during code review though :) 20:29:06 atiwari, I can provide some mock tests. I just figured that the unit test wasn't really valuable without a real drm. 20:29:22 but if it helps move things forward then I'll add them. 20:29:51 alee, In that case it will not be a unit test. in my opinion 20:30:11 atiwari, fair enough :/ I'll add them. 20:30:27 it can be helpful to exercise the business logic in there, to alert of regressions 20:30:37 correct 20:31:06 I think we have an agreement here :) 20:31:22 #agreed mock tests for dogtag plugin would be helpful 20:31:34 (and I'll add them) 20:31:53 now -- to discuss integration with a real drm ... 20:32:08 k 20:32:46 so if I recall correctly someone had started some work on a recipe to insatll a drm 20:33:07 yes... we'll it's more of an empty repo at the moment 20:33:10 #link https://github.com/cloudkeep-ops/chef-dogtag 20:33:38 we probably need to revive that effort for the purpose of actually adding a drm tot he integration tests 20:34:10 alee: do you mean devstack tests? 20:34:34 …or true integration with drm testing? 20:34:41 I think integration tests would be CloudCAFE or Tempest? 20:34:55 woodster_, well, thats part of my question actually. what testing should involve a real drm? 20:35:25 devstack testing? cloud cafe or tempest? 20:36:04 can it be installed without an HSM, and as a separate module from dogtag? 20:36:08 I don't think standing up DogTag would be necessary for DevStack gates 20:36:33 woodster_, it can be done without hsm 20:36:58 woodster_, in that case, drm will use a software based nss certdb 20:37:02 for its certs 20:37:39 so for my testing -- this is what I did .. 20:38:00 my preference would be to stand up a dogtag instance and run a full CloudCAFE/Tempest suite against it 20:38:33 is jvrbanac around? I'd like to hear his thoughts on this 20:38:56 created a python virtual env, copied over the relevant dogtag python libs in the virtual envrionment and ran barbican.sh 20:39:18 and then did some testing by passing in requests to the barbican server 20:39:28 through curl 20:39:41 obviously thats all very manual .. 20:40:31 yeah, I think it would be awesome to kick off an automated job that would spin up DogTag and run a full regression suite on jenkins.cloudkeep.io 20:40:58 redrobot, thats the cloudcafe stuff? 20:41:40 alee, currently yes. We need to start getting these things into Tempest 20:42:15 I think we need to have a more extended discussion about this 20:42:43 jvrbanac hash it out at the summit maybe? 20:42:57 redrobot, jvrbanac that sounds good to me. I'm not very familiar with the whole structure of the cloud cafe tests and with recipes. Is there anyone who will be able to work with me on this? 20:43:27 alee: did you want to try get those cookbooks working in your environment to exercise things? 20:43:44 woodster_, I think that would be a great idea 20:44:16 If we are done with this topic, can I raise one? 20:44:32 Chad has been updating documents on the wiki here: https://wiki.openstack.org/wiki/Barbican#Automation_Details 20:44:58 redrobot, we can certainly hash things out more at the summit. but thats awhile from now. we can get a great deal accomplished if I can get someone to work with me on this the next couple of weeks. 20:44:59 we can discuss details outside of the meeting if you'd like 20:45:12 woodster_, sure 20:45:26 alee, jvrbanac is our resident CloudCAFE/Tempest expert. I think he'd be the best person to help you out with this 20:46:03 ok -- jvrbanac I'll be pinging you :) 20:46:05 yep, so phase 1 would be getting the cookbooks working in your env. phase 2 woudl be the automation/deployemnt/testing part 20:46:08 alee, cool 20:47:35 Arunkant has posed as cr #link https://review.openstack.org/#/c/81310/ for BP #link https://blueprints.launchpad.net/barbican/+spec/policy-target-support. Waiting for blessings from you guys. 20:48:05 any one looked at it? 20:48:26 I have started etherpad for discussion..https://etherpad.openstack.org/p/barbican-policy-target-support 20:49:07 My concern was that we plan to remove the project-id from the REST URI 20:49:23 #topic Policy changes 20:49:28 …so the specific purpose of this change (to replace the project-ID check) would not be required 20:50:13 woodster_ that is really good idea I am wokong on API proposal for removing tenant_id 20:50:44 it seems like a lot of code change for that purpose. It might be helpful for other policy purposes as Adam mentions in comments, but I don't think it is needed right now though 20:50:49 woodster_ even though you need this for authz purpose 20:51:46 You couldn't auth-n without the right token/project-id combo, so the auth-z part is just enforcing RBAC 20:52:02 woodster_ we can has out the tenant_id less API uris first. is that what you are thinking ? 20:52:03 It started as the change for that bug..but having target support will be foundation for user isolation work later. This way of policy enforcement is used in number of openstack projects 20:53:01 woodster_, correct but within on project multiple use case get token 20:53:41 is the user isolation feature planned to be available in keystone v3? 20:53:54 it is already there 20:54:01 in v3 20:54:39 ok, that makes sense then 20:54:40 this is more of isolation of barbican entities at user level and enforcing authz 20:55:16 can the rest of the team proceed on review then? 20:55:28 will do. 20:55:42 great 20:55:50 #agreed policy changes should be reviewed and merged 20:55:57 Will be helpful to get inputs from team..thanks 20:56:24 ok, guys, running out of time for this one. 20:56:38 atiwari, we'll have to revisit summit topics next time. 20:56:48 Can we tie this to milestone target in Juno? 20:56:48 ok 20:58:01 arunkant, yeah. all new CRs will be targeting juno-1 20:58:09 woodster_ and all, just FYI.. , soon I will submit API change proposal for tenant_id less rest API. ping you guys 20:58:22 time flies when you're having fun. :) 20:58:44 I think that's all the time we have this week. Be sure to update the wiki if you guys have any topics for next week. 20:58:51 #endmeeting