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