20:00:05 #startmeeting barbican 20:00:06 Meeting started Mon Nov 30 20:00:05 2015 UTC and is due to finish in 60 minutes. The chair is kfarr. Information about MeetBot at http://wiki.debian.org/MeetBot. 20:00:08 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 20:00:10 The meeting name has been set to 'barbican' 20:00:19 hello/ 20:00:22 Welcome back from Thanksgiving! 20:00:24 #topic Roll Call 20:00:35 o/ 20:00:37 0/ 20:00:37 o/ 20:01:07 wb to you as well kfarr =) 20:01:24 o/ 20:01:25 o/ 20:01:37 o/ 20:01:44 o/ 20:01:54 As usual, the agenda can be found here: 20:02:00 #link https://wiki.openstack.org/wiki/Meetings/Barbican 20:02:26 Lots of Barbicaneers today! 20:02:44 #topic Action Items from last meeting 20:03:10 #link http://eavesdrop.openstack.org/meetings/barbican/2015/barbican.2015-11-23-20.00.log.html 20:04:01 o/ 20:04:03 Oh, rellerreller just made it 20:04:32 Did everyone review the federation use cases? 20:04:42 #link https://etherpad.openstack.org/p/barbican-federation-use-cases 20:05:10 a little bit, not extensively 20:05:28 Alright, we'll just keep that action item open 20:05:49 #action everyone review the federation use cases 20:06:12 The next action item was to meet to discuss the Castellan context objects 20:06:52 There was a good chat with alee, elmiko, and diazjf 20:07:06 +1 20:07:14 o/ 20:07:23 Was there any follow-up notes or etherpads? 20:07:26 dave-mccowan buys the donuts next week :-) 20:07:42 kfarr, alee, elmiko, Still going over SAML to determine how we should create the Barbican Auth Middleware. I'm planning on updating it soon. 20:07:55 kfarr: none that i've seen 20:07:56 diazjf: ack 20:08:22 Great, thanks diazjf! Do you have the link to the blueprint handy? 20:08:53 kfarr, https://review.openstack.org/#/c/241068/ but I have yet to update it 20:09:13 Ok, great. I'll just put that as an action item for next week then 20:09:35 #action diazjf to update the Barbican context blueprint 20:09:38 #link https://review.openstack.org/#/c/241068/ 20:10:06 alee, there was another action item from last week about the cinder volume encryption blog post 20:10:35 kfarr, yeah -- I'm still working on it .. 20:11:03 alee, ok thanks! I'll just keep that action item on there because I'm interesting in seeing the finished product! 20:11:25 #action alee to post blog post on testing Cinder volume encryption 20:12:06 lisaclark1, there was a note last week about hotel recommendations, did you have a chance to pull together a list? 20:12:54 Also, lisaclark1 do you have the link to the eventbrite page? 20:14:07 Maybe lisaclark1 is busy, we'll just keep that on there for next week 20:14:34 #action lisaclark1 to post links to hotel recommendations and mid-cycle eventbrite link 20:15:16 There was an action for me to work on the next release of Castellan, which is out there, version 0.3.0, so action item completed 20:15:35 I think that was it for action items 20:15:51 On to the meeting items.. 20:16:06 #topic mitaka-1 milestone 20:16:51 One thing I realized is that all projects need to integrate reno into their codebase before the release can occur 20:16:57 there was information on the mailing list about this 20:17:31 It's a tool for managing release notes during development. It's meant to take the burden of managing the release notes off of the release managers 20:17:58 I gave it a shot at adding it, but reviews would be appreciated. 20:18:14 We need to integrate reno before we can cut a release 20:18:14 #link http://lists.openstack.org/pipermail/openstack-dev/2015-November/080694.html 20:18:20 just fyi 20:18:21 thanks elmiko! 20:18:37 np 20:18:41 #link https://review.openstack.org/#/c/248918/ 20:19:00 ^^ that's the link for adding it to barbican, reviews would be appreciated 20:19:32 ack, added to the queue 20:19:43 Thanks elmiko! 20:20:02 Does anyone have any questions about it? I'm still trying to read up on it myself.. 20:20:11 If not, we'll move on to the next topic 20:20:18 seems like a convenient system for release notes 20:21:01 Alright, next topic 20:21:10 #topic Castellan logging options 20:21:16 elmiko I think this was yours? 20:21:21 yea, thanks 20:21:41 so, the configuring of logging options in castellan is currently causing some downstream issues 20:22:04 namely, if an application that is using castellan has already configured logging, then calls to key_manager.API() will fail 20:22:08 #link https://bugs.launchpad.net/castellan/+bug/1521265 20:22:08 Launchpad bug 1521265 in castellan "Log configuration causes error in applications that have already processed configuration arguments" [Undecided,New] - Assigned to Fernando Diaz (diazjf) 20:22:27 i opened that for it, but it got me thinking about logging in castellan in general 20:22:34 i don't think we should auto config castellan for logging 20:22:50 since it is a library, we should not be making assumptions about how a user has configured their application 20:23:17 i think it would be ok to provide a function for convenience, to setup logging where none is already configured, but in general we shouldn't do anything 20:23:33 diazjf and i talked about this a little, but i wanted to talk with the group about it 20:23:44 elmiko, that makes sense to me, how do the logging configuration get passed into it then? 20:24:05 well, in general, there is no need to pass in logging configuration. 20:24:25 the python logging package will be used under the covers, and oslo_log will mediate those configurations 20:24:44 so, if my application has already configured oslo_log then it should "just work" 20:25:04 elmiko, that sounds fine to me 20:25:27 kfarr, I'll keep working with elmiko to get a patch up 20:25:33 we should definitely add to the configuration documentation for castellan to inform users how to setup the castellan log level though 20:25:56 sounds good to me! 20:26:00 cool 20:26:02 Also a +1 from rellerreller 20:26:14 * elmiko waves to rellerreller ;) 20:26:47 He says hi back! 20:26:54 nice 20:27:03 elmiko, is there anything else about this topic, or we can move to the next one 20:27:25 i don't think so, if no one has objections i'll just keep working with diazjf to get a good solution 20:27:37 but, we do need to be mindful of getting a patch out 20:27:56 this has effectively stopped any progress downstream in sahara because of the error 20:28:05 i imagine other projects would have similar issues 20:28:36 elmiko, I'll be keeping an eye out for when that fix merges so I can cut a new release 20:28:39 elmiko, I'll try to resolve the bug quickly today and add the documentation after 20:28:49 ack, thanks kfarr and diazjf 20:28:55 is there something we can do in the meantime so sahara isn't blocked? 20:29:45 not really, it's gonna be slow going. we need to get a patch out, then bump the vers in global reqs. we might want to hold off on https://review.openstack.org/#/c/248911/ and wait to bump until 0.3.1 is available? 20:30:17 elmiko, that's fair. It's not passing jenkins anyway, which is another issue 20:30:18 but, this does dovetail nicely into the next topic ;) 20:30:33 got it! 20:30:41 #topic Castellan integration testing 20:30:45 hey! 20:30:59 so, while debugging this logging issue it got me thinking about testing castellan 20:31:31 could we setup some sort of integration testing using the not implemented key manager, or something, to test a full end-to-end usage of castellan? 20:32:03 elmiko, what do you mean by full end-to-end usage? 20:32:26 if we had a couple small sample applications we could emulate the behavior that castellan consumers might expect, and hopefully catch something like this earlier in the future 20:32:47 so, i can expect that other openstack service controllers might use castellan 20:33:02 they would be using the common openstack design patterns, which means they would have oslo.log already in place 20:33:19 we woud have been able to detect the exception during an integration test then 20:33:36 additionally, we could test out some of the more complex configuration details 20:34:15 if this sounds interesting, i could try putting together a spec for it. i'm just not sure what we could use to gate it (machine-wise) 20:35:03 elmiko, that makes sense, it could be useful. Do you think it could live with the already existing functional tests? 20:35:33 kfarr: possibly, the current tests just use the unittest harness, right? 20:36:31 Yeah, there are unit tests, and then there are functional tests which kind of sound like what you want to do 20:36:52 but yeah, they are using the unittest library to run the functional tests 20:36:53 ok, i missed the functional tests. i'll take another look at those, maybe it would just fit right in 20:37:18 elmiko, the functional tests are not running in the gate, but I have a patch up so hopefully they could be 20:37:25 o\ 20:37:28 o/ 20:37:28 i was envisioning something like the integration tests where it would deploy castellan and then attempt to run some small applications against the deployment. 20:37:51 kfarr: very cool, sounds like i need to do a little more reading and then figure out what to propose 20:38:11 should i use the [barbican] subject or [castellan] to bring this up on the ml? 20:38:17 elmiko what do you mean deploy castellan? 20:38:26 elmiko you could use both! 20:38:57 kfarr: well, i say "deploy" but it mainly just means installing to a venv and creating a config file for the testing applications. 20:39:19 it wouldn't actually use the barbican key manager, it would just use the testing key manager 20:39:37 although, it might be possible in the future to build out a full barbican test (if needed) 20:39:53 elmiko I'd be interesting in seeing what that looked like! 20:40:01 but i envision something more "real world" than the isolation of the unit tests 20:40:05 kfarr: cool! 20:41:08 elmiko: it kind of sounds like a devstack instance with barbican and castellan deployed and also some OS service to test against. would that work? 20:41:35 silos: that would be ultimate, but we could start with something smaller 20:42:05 in other projects they use devstack, i don't see why we couldn't test castellan in a similar fashion 20:42:10 elmiko: that's what I was thinking. Icarus was flying to close to the sun right there. 20:42:20 silos: hehe, yea ;) 20:42:42 elmiko, silos, that is what the functional tests do 20:42:49 well, once they're integrated 20:42:59 kfarr: ah, cool. that would be perfect then 20:43:14 kfarr: is there a review up for them now? 20:43:30 but they launch devstack with barbican, though it doesn't create the separate os application. 20:43:57 the functional tests mimic what an application would do 20:43:57 ok, so maybe we just need to build more tests =D 20:44:05 #link https://review.openstack.org/#/c/229115/ 20:44:19 elmiko +1 (and +1 from rellerreller) 20:44:30 kfarr: awesome, thanks! 20:45:10 kfarr: i'll read through that review and maybe we can just generate some more tests on top of it 20:45:48 elmiko, ok great! That review just adds the gate hooks, but they call the functional tests, let me know if you have any questions about it! 20:45:54 at the very least we can cover the usages and configurations that are suggested by the castellan documentation. it's becoming complicated enough that i think it would be beneficial to potential end-users 20:46:06 hi. i wanted to add a topic for the midcycle info/registration 20:46:29 ok lisaclark1! elmiko, was there anything else? 20:46:45 kfarr: no, i think we've covered everything i was concerned about. thanks! 20:46:52 ok great! 20:47:01 #topic midcycle info 20:47:18 It's all you lisaclark1! 20:48:18 I added an eventbrite event for barbican midcycle registration 20:48:33 and have also updated the openstack wiki sprints page with some details 20:48:36 #link https://wiki.openstack.org/wiki/Sprints 20:48:46 #link https://wiki.openstack.org/wiki/Sprints/BarbicanMitakaSprint 20:48:55 #link http://www.eventbrite.com/e/openstack-barbican-mitaka-midcycle-tickets-19784674494 20:49:22 I still have the action item (that I saw was also captured earlier) to review preferred hotel options 20:49:34 fin. 20:49:47 Thank you lisaclark! That's some really great info 20:50:48 Does anyone else have anything? 20:50:52 #topic open discussino 20:51:50 hi kfarr, i had a question for folks on how are they running functinal tests 20:52:04 trying to delete some duplicate code and here is the patch https://review.openstack.org/#/c/247810/ 20:52:33 ok pdesai taking a look now 20:53:08 the doc has instructions on setting up devstack followed by running functional test, it doesnt have details on setting up keystone accounts 20:53:22 which is done as part of devstack barbican plugin 20:54:23 if anyone is using keystone_data.sh to create necessary accounts, then it make sense to add how to create necessary accounts after we have deleted this script 20:54:54 pdesai, sometimes I run functional tests by setting up keystone and postgres in a docker instances 20:55:12 then I use that script to set up the relevant barbican accounts 20:55:27 that's the hockeynut taught me... run keystone inside a VM, run keystone_data.sh against it, and then run barbican in a pyenv. 20:55:34 pdesai: sounds like good content for developer docs on running the func. tests 20:56:26 yup, looks like that script is used for folks without having to run devstack 20:57:23 pdesai maybe keystone_data.sh can source devstack/lib/barbican to remove the duplicate code. but, both files would remain. 20:57:57 yeah i will check if its possible (should be) 20:58:38 i agree to not have duplicate code but source it from devstack/lib/barbican 20:58:54 thanks dave-mccowan 20:59:02 thanks everyone 20:59:09 pdesai... not to pile-on... but, for folks just running devstack, it's probably weird to add all of those accounts that are used by barbican functional tests. it might be best to separate what's needed for devstack and what's needed for functional tests. 20:59:37 Alright folks, that's about all the time we have for today. Some good discussions, let's continue back in the barbican channel! 20:59:38 #endmeeting