20:00:36 <redrobot> #startmeeting barbican
20:00:37 <openstack> Meeting started Mon Feb  2 20:00:36 2015 UTC and is due to finish in 60 minutes.  The chair is redrobot. Information about MeetBot at http://wiki.debian.org/MeetBot.
20:00:38 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
20:00:40 <openstack> The meeting name has been set to 'barbican'
20:00:55 <redrobot> #topic Roll Call
20:00:56 <rm_work> ohai o/
20:01:00 <hockeynut> o/
20:01:03 <tkelsey> o/
20:01:08 <chellygel> \(>///<)/
20:01:11 <arunkant> o/
20:01:49 <jvrbanac> o/
20:02:26 <jaosorior> o/
20:02:36 <jvrbanac> <_<
20:02:45 <jaosorior> >_>
20:02:55 <kfarr> o/
20:03:08 <redrobot> Well, we have a few barbicaneers here, but not the folks I was hoping would be here
20:03:23 <redrobot> lots of stuff on the agenda though
20:03:28 <alee> o/
20:03:29 <hockeynut> feeling the love :-)
20:03:29 <redrobot> which, as usual, can be found here:
20:03:43 <rm_work> T_T
20:03:43 <redrobot> #link https://wiki.openstack.org/wiki/Meetings/Barbican
20:03:58 <redrobot> not that I don't want YOU guys here...  :D
20:04:06 <woodster_> o/
20:04:22 <hockeynut> <stepping back off of the ledge>
20:04:28 <redrobot> ok, let's get started, hopefully we'll be able to get through some stuff we left on hold last week
20:04:40 <redrobot> #topic Kilo 2
20:04:45 <redrobot> #link https://launchpad.net/barbican/+milestone/kilo-2
20:04:59 <redrobot> Thanks jaosorior for all the bugfixes!
20:05:16 <jaosorior> a couple more coming :P
20:05:41 <redrobot> jaosorior nice!
20:06:01 <redrobot> I want to give Thierry a good sha to release for Kilo-2 tomorrow, or Thursday at the latest
20:06:23 <redrobot> alee I see that there's two CRs in review for the Common Certificate API BP
20:06:35 <redrobot> alee are those the only two outstanding CRs for the BP to be complete?
20:06:40 <jaosorior> I need to hurry the fuck up to review those
20:06:40 <alee> redrobot, yup
20:06:44 <alee> :)
20:06:48 <jaosorior> sorry for the slowness alee
20:07:16 <redrobot> #link https://review.openstack.org/#/c/146611/
20:07:16 <alee> jaosorior, no prob -- reviews from others too please :)
20:07:22 <redrobot> #link https://review.openstack.org/#/c/150670/
20:07:45 <redrobot> if we can get those reviewed (and hopefully landed) in the next day we can call the BP complete for Kilo2
20:07:51 <redrobot> which would be awesome
20:07:59 <redrobot> so please everyone take some time to review
20:08:00 <alee> redrobot, we're not quite there yet
20:08:07 <jaosorior> the simple cmc one just needs a workflow, basically
20:08:09 <alee> there will be more crs to come
20:08:26 <alee> both just need workflows I think
20:08:31 <redrobot> alee sorry, got confused... I asked if those were the only two?
20:08:55 <jaosorior> yeah, but I don't want to workflow it before I finish understanding it :( and I have to catch up on reading the details
20:08:56 <alee> redrobot, those are only two out there currently
20:09:00 <jaosorior> that's why I've been slow
20:09:11 <alee> but there is more code that needs to be written
20:09:14 <redrobot> alee got it... so no complete BP for Kilo-2 then...
20:09:17 <alee> validation code for instance
20:09:24 <redrobot> alee I'll go ahead and bump that BP to Kilo-3
20:09:25 <alee> when is kilo-2?
20:09:29 <rm_work> Thursday
20:09:38 <alee> yeah - not for kilo-2
20:09:41 <redrobot> rm_work Thierry prefers them early
20:09:44 <rm_work> heh
20:09:56 <redrobot> rm_work so Tomorrow since we don't have any other BPs that would land
20:09:58 <alee> but that doesn't mean ya'll should put off the reviews :)
20:10:02 <rm_work> we're probably working up to the 11th hour for neutron-lbaas >_>
20:10:04 <redrobot> alee +1
20:10:12 <redrobot> rm_work hehe nice
20:10:18 <redrobot> ok... I
20:10:29 <redrobot> I'll look through the bug reports to make sure I haven't missed any
20:10:41 <alee> redrobot, there are some CRs out for the "identifying CAs" BP too
20:10:42 <redrobot> but if all looks good, I'll ask Thierry to cut Kilo-2 tomorrow.
20:11:34 <rm_work> We still have some *spec* BPs that aren't merged <_< is it getting pretty late in the cycle for Kilo for still sitting on specs?
20:11:47 <redrobot> alee indeed... I'm so behind on reviews it's not even funny...
20:12:03 <tkelsey> rm_work: +1
20:12:13 <jaosorior> redrobot: drink coffee like there's no tomorrow
20:12:28 <redrobot> rm_work we still have a while before feature proposal freeze, but yes, I would like us to drive those specs home by the mid-cycle at the latest
20:12:29 <woodster_> it would be good to land those before the mid cycle...hackathon not blueprintathon! :)
20:12:42 <redrobot> woodster_ +1
20:12:58 <redrobot> ok, moving on from Kilo-2... we got a ton of stuff on the agenda still.
20:13:16 <redrobot> #topic Quota BP
20:13:18 <redrobot> #link https://review.openstack.org/#/c/132091
20:13:27 <redrobot> Open question: Admin endpoint (9312) vs service admin thats allowed to set quotas on any project it wishes to?
20:13:35 <redrobot> woodster_ I think you added this to the agenda last week?
20:13:51 <tsv> redrobot, woodster, i added a comment today to the spec on that
20:13:52 <woodster_> yes, trying to get traction on this bp
20:14:02 <jaosorior> tsv: yeah, just reading your comments
20:14:07 <jaosorior> that one I did review with time
20:14:26 <tsv> jaosorior, thanks
20:14:37 <redrobot> woodster_ regarding the open question, did you get a chance to send something to the mailing list?
20:14:37 <woodster_> I think that is the bigger question on that bp....and it seems that the admin role access vs admin endpoint is the way to go, esp. since keystone v3 doesn't support admin endpoint I recall
20:15:07 <woodster_> redrobot, I did not, but I think if v3 is not supporting it, we really need to go the admin rbac route
20:15:19 <morganfainberg> woodster_, please go RBAC route
20:15:24 <morganfainberg> please.
20:15:24 <woodster_> so that would be the 'cloud admin' sort of role, not the barbican admin role
20:15:25 <morganfainberg> :)
20:15:59 <morganfainberg> hard-coded roles backs everyone into corners in the long run (We're working hard to get rid of "admin" and move to RBAC for other services)
20:16:05 <rm_work> yeah, i thought we were removing the admin endpoint ages ago -- i had it in one of my CRs but reverted it so someone else could make a CR
20:16:13 <morganfainberg> and admin endpoints scare me /security
20:16:16 <woodster_> morganfainberg, on great! So we would modify our policy to only let a cloud admin access to those admin only resources, ocrrect?
20:16:17 <rm_work> did that just never happen
20:16:18 <rm_work> ?
20:16:24 <morganfainberg> woodster_, ideally
20:16:45 <morganfainberg> woodster_, or whatever role you're looking to make this admin role
20:16:48 <redrobot> morganfainberg so, the argument FOR admin endpoints is that you can run those on a different network.
20:16:49 <morganfainberg> it *might* be barbican_admin
20:17:08 <woodster_> nice! tsv, then it seems like you could put a final update for your blueprint then
20:17:22 <tsv> woodster, great! will do today
20:17:27 <morganfainberg> redrobot, there is nothing saying you can;'t make the public endpoint(s) [filtered out via enfpoint filtering] have the policy not allow access to those apis
20:17:43 <woodster_> this is for a resource that is able to set quotas on other projects than their own, so I'm thinking it has to be a non-barbican admin role of some sort?
20:18:15 <redrobot> morganfainberg true... I don't have a preference either way, it's just that I've heard some arguments for admin endpoints that supposedly makes them easier to protect.
20:18:18 <morganfainberg> redrobot, and then the right "admin" people could be filtered to the admin endpoint. - but i digress. it still falls into "do it with RBAC" you can configure deployment other ways as well. but RBAC allows for a lot more flexibility in who ends up managing the barbican stuff in real deployments
20:19:05 <redrobot> #agreed we'll add administration to the public endpoint via RBAC
20:19:13 <woodster_> thanks for weighing in morganfainberg
20:19:17 <morganfainberg> of course!
20:19:23 <tsv> morganfainberg, thanks!
20:19:26 <jaosorior> excellent
20:19:30 * morganfainberg likes OpenStack policy enforcement to be consistent (for obvious reasons)
20:19:38 * morganfainberg might be pushing hard for good interop stories.
20:19:52 <redrobot> woodster_ is there anything else about this BP we need to discuss ?
20:19:58 <morganfainberg> and we're working on stuff to make policy better [via keystone] so.. yay thanks for RBAC :)
20:20:20 <woodster_> I don't think so, tsv can you put an update based on cmments? Maybe we could land this one this week?
20:20:29 <tsv> sure. will do
20:20:35 <redrobot> rm_work I agree, we should get rid of the admin endpoint sooner rather than later.
20:20:50 <woodster_> it's a good thing we never actually got it working then ;)
20:21:11 <redrobot> ok, moving on
20:21:11 <woodster_> I think it just has the version resource on it now
20:21:37 <redrobot> #topic Castellan
20:21:49 <redrobot> Which openstack services are driving? What is the timeline for Castellan availability and services started using it?
20:22:04 <redrobot> I'm not sure who added this?
20:22:13 <redrobot> it was left on the agenda from last week
20:22:23 <redrobot> rellerreller maybe?
20:22:24 <arunkant> its me. Just want to find out about this
20:22:47 <redrobot> arunkant so the idea for Castellan came out of the Paris summit
20:22:48 <arunkant> Interested in knowing how services are going to use it.
20:23:13 <redrobot> arunkant currently it's an effort to remove duplication from Cinder and Nova
20:23:43 <redrobot> the JHU team noticed that both Cinder and Nova (?) were both adding an additional abstraction on top of python-barbicanclient
20:23:48 <redrobot> instead of integrating directly
20:23:55 <arunkant> Okay..so are those services going to use that instead of barbican cliemt
20:24:24 <jaosorior> arunkant: Well, that could use barbicanclient as a backend
20:24:35 <woodster_> arunkant, correct. Barbican client is an optional plugin for it
20:24:43 <jaosorior> * plugin...not backend
20:24:54 <redrobot> arunkant yes, Castellan will just be an abstract interface
20:24:55 <rm_work> yes, Nova/Cinder/Neutron will use Castellan as a KeyManager / CertManager
20:25:01 <woodster_> if folks don't want a barbican dependency, there could be other plugins that go directly to an HSM (for example)
20:25:07 <rm_work> and then Castellan can be configured to use a Barbican backend plugin (or other plugin)
20:25:10 <redrobot> arunkant the actual implementation will use python-barbicanclient
20:25:57 <arunkant> So what functionality is targeted for Castellan ..looks like keymgr. Is it going to be made available in Kilo?
20:26:13 <woodster_> I think the timeline is kilo, with patches in other projects using Castellan in Kilo too?
20:26:39 <rm_work> hopefully
20:26:43 <woodster_> rellerreller is not online to ask him
20:26:48 <rm_work> arunkant: CertMgr also
20:27:04 <woodster_> rm_work will your team have Kilo patches to use it then?
20:27:06 <rm_work> my goal is to have Castellan "working" by the end of the Barbican meetup
20:27:12 <rm_work> woodster_: I will write them, yes
20:27:15 <arunkant> Okay..so cinder has keymgr which is using barbicanclient right now..so they are going to revert to Castellan in kilo?
20:27:38 <redrobot> arunkant no, keymgr will be castellan instead... they'll still use barbicanclient to talk to barbican
20:27:41 <rm_work> arunkant: I believe that is the plan -- though technically that could be put off until L without real issues
20:28:10 <redrobot> arunkant now the interaction is Cinder -> keymgr -> barbicanclient
20:28:23 <redrobot> arunkant after castellan it will be Cinder -> Castellan -> barbicanclient
20:28:31 <rm_work> right
20:28:51 <rm_work> though keymgr is inside their project currently, so... <_<
20:29:54 <tsv> anybody knows if swift is planning on using Castellan too ?
20:29:59 <redrobot> there was some concern on #openstack-infra last time we were talking about castellan
20:30:13 <jaosorior> concern about what?
20:30:23 <redrobot> tsv we would prefer that everyone integrate with python-barbicanclient directly, so hopefully not.
20:30:33 <rm_work> redrobot: >_>
20:30:37 <redrobot> jaosorior about people not wanting to integrate with barbicanclient directly
20:30:48 <rm_work> there are good reasons to not
20:30:49 <redrobot> jaosorior about adding yet another abstraction, etc.
20:30:57 <rm_work> redrobot: are you anti-Castellan? :P
20:30:59 <arunkant> Okay..So is the castellan initiatve driven by service teams ?
20:31:00 <jaosorior> yeah... I understand the concern
20:32:12 <arunkant> I mean..as it appears to be another abstraction around barbicanclient.
20:32:15 <redrobot> rm_work not really... but some of the arguments made me reconsider some assumptions.
20:32:18 <woodster_> I recall concern about barbican not being integrated yet driving some of this effort.
20:32:46 <tsv> redrobot, sorry got confused. thought the keymanager will be abstracted by castellan ?
20:33:00 <rm_work> tsv: keymanager literally *moves into* castellan
20:33:05 <rm_work> the code is essentially being copy/pasted
20:33:15 <rm_work> Castellan now provides KeyManager
20:33:24 <rm_work> instead of the KeyManager code being local to each project
20:33:27 <tsv> rm_work, in that case swift has to use castellan right ?
20:33:37 <rm_work> does Swift currently have KeyManager code merged?
20:33:56 <kfarr> rm_work, not that I'm aware of
20:34:04 <tsv> i don't know - if somebody knows about it, please share
20:34:41 <redrobot> tsv I think you have a valid concern... we do need to figure out what the recommendation should be moving forward
20:35:03 <arunkant> rm_work, Okay so this new keymgr has a standard and common interface for all services (cinder, nova, lbass) ?
20:35:06 <tsv> redrobot, sure
20:35:12 <woodster_> I think reaperhulk has been speaking the most with swift...can get an update from him next week when he's back
20:35:14 <rm_work> arunkant: yes
20:35:34 <tsv> woodster_, that would be great. thanks!
20:35:36 <rm_work> so Neutron-LBaaS -> Castellan.CertManager -> Barbican
20:35:49 <rm_work> Cinder -> Castellan.KeyManager -> Barbican
20:36:14 <rm_work> or Neutron-LBaaS -> Castellan.CertManager -> LocalConf
20:36:28 <rm_work> (for a dev/testing environment where security isn't an issue)
20:37:22 <arunkant> So all these castellan functionality targeted for Kilo ?
20:37:28 <rm_work> I hope so
20:37:40 <redrobot> rm_work I think the open question is, Will the Barbican Team recommendation be that EVERYONE use Castellan?
20:37:59 <rm_work> redrobot: I don't think it needs to be? but I certainly would, just for ease of development
20:38:21 <arunkant> rerobot: + 1, that was my next question..how services decide whether to use barbican client or castellan (benefits ??)
20:38:53 <rm_work> Castellan takes care of some stuff / simplifies the interaction a little bit
20:39:01 <rm_work> and allows for simpler dev
20:39:25 <tsv> rm_work, for the Neutron-LBaaS case, there are two parts right ? 1. lbaas user gets cert from barbican using barbican client 2. lbaas admin talks to barbican using castellan to get the user's cert ?
20:39:26 <redrobot> rm_work I've been starting to think that maybe Castellan could have just been an abstraction layer in python-barbicanclient
20:39:40 <jaosorior> so...what's stopping us from using these levels of abstraction in barbicanclient?
20:39:42 <redrobot> rm_work sort of how pyca/cryptography has a high-level and low-level api
20:40:04 <woodster_> redrobot, I recall some projects were holding back on integrating with barbican until we integrated, so castellan gave a way to make that dependency optional
20:40:08 <rm_work> jaosorior: do you want to implement LocalConf / LocalFile implementations of cert/key storage in python-barbicanclient?
20:40:10 <redrobot> jaosorior +1 that's the question I'm struggling with right now.
20:40:23 <redrobot> woodster_ not after we decided to put the python-barbicanclient impl in castellan
20:40:30 <jaosorior> rm_work: is that a challenge? :P
20:40:40 <rm_work> jaosorior: no, it's easy to DO them -- I have them done already
20:40:50 <rm_work> the point is: do you think those would belong in python-barbicanclient?
20:40:55 <rm_work> I really hope that's an obvious "no"
20:41:08 <jaosorior> yeah... it KINDA breaks semantics
20:41:22 <rm_work> also I am hoping to push some cert convenience utilities into Castellan
20:41:58 <woodster_> yeah, the python client should be a lean as possible interface with the service API.
20:41:58 <redrobot> I think the convenience API _could_ be in python-barbicanclient... especially after some weirdness i've seen tdink_ run into
20:42:05 <jaosorior> but I still feel dubious about another level of abstraction. Kinda feels like we failed to provide proper abstraction in our API
20:42:24 <hockeynut> jaosorior glad I'm not alone there
20:42:25 <redrobot> jaosorior +1 that was one of the concerns that came up in infra
20:42:34 <rm_work> I don't think that's true
20:42:57 <rm_work> if you ONLY wanted to store secrets in Barbican, then using python-barbicanclient would be fine
20:43:17 <woodster_> which is how the project started 2 years ago :)
20:43:22 <rm_work> but I think it makes sense for ANY project to allow for different implementations, just for ease of dev/testing
20:43:36 <rm_work> we use the LocalConf plugin right now in every stage of dev/test
20:43:43 <redrobot> rm_work but we could provide that with a test object for testing purposes
20:43:52 <jaosorior> redrobot: +1
20:43:53 <rm_work> only when we move to production would we switch to the Barbican plugin
20:43:58 <redrobot> rm_work the way that keystoneclient provides testing objects
20:44:02 <rm_work> hmm
20:44:19 <redrobot> the only good argument I've heard is people who want to bypass barbican completely
20:44:31 <woodster_> redrobot +1
20:44:55 <rm_work> so you think CertManager / KeyManager should just live in python-barbicanclient now?
20:44:56 <redrobot> which rellerreller had a use case for
20:45:12 <redrobot> rm_work I'm still not 100%, but I'm starting to lean that way
20:45:26 <jaosorior> well, something we should definitely discuss further in the meetup
20:45:31 <redrobot> I'm sure we'll discuss this some more
20:45:35 <redrobot> jaosorior +1
20:45:39 <rm_work> hmm, k
20:45:53 <redrobot> ok, moving on, b/c I don't think we'll be able to cover all of the agenda items.
20:46:11 <redrobot> #topic L-release Design Sessions
20:46:20 <redrobot> #link https://etherpad.openstack.org/p/barbican-L-design-sessions
20:46:26 <redrobot> woodster_ did you add these?
20:46:41 <woodster_> I mainly added that to raise awareness...never too late to plan for L
20:46:58 <woodster_> ...and we did that about this time before the Paris summit I recall
20:47:37 <woodster_> eventually we can vote on sessions worthy of their own design sessions, vs discussion at our table
20:47:48 <redrobot> yep, definitely good to stay on top of these things
20:48:01 <redrobot> I'm sure we'll have plenty to add to the etherpad during the mid-cycle
20:48:38 <redrobot> any questions/comments about this?
20:48:47 <woodster_> yep, so can move to next agenda item if you'd like
20:48:49 <redrobot> if not I think we may be able to squeeze in one of jaosorior's bug questions?
20:48:58 <jaosorior> hopefully :D
20:49:06 <redrobot> #topic Migration Scripts
20:49:06 <alee> woodster_, sorry - are these for the meeting or for the summit?
20:49:25 <redrobot> alee the ehterpad is to start planning the vancouver summit
20:49:29 <woodster_> alee, for the summit, just trying get word out about the etherpad
20:49:37 <alee> woodster_, ok
20:49:43 <redrobot> Migration scripts are not being ran (according to the bugs that I've found) up to which revision should we keep(support)?
20:49:52 <jaosorior> yup
20:50:09 <jaosorior> so I noticed a BUNCH of migration scripts had bugs, specially on the downgrade functions
20:50:14 <jaosorior> and... nobody had complained
20:50:15 <alee> woodster_, good thinking ahead -- I'm just trying to figure out whats happening the nexttwo  weeks
20:50:21 <jaosorior> so I'm guessing nobody was really running them
20:50:26 <redrobot> I think that Grenade is the correct tool to test these things, but I have never looked into it
20:50:41 <jaosorior> so then I stumbled with one that... honestly was taking me too long to fix
20:50:43 <redrobot> regarding the support question, that's easy
20:50:55 <jaosorior> and then I thought...is it really worth it? So I thought maybe it would be better to delete the older ones
20:50:58 <redrobot> we need to be able to provide a schema migration from Juno -> Kilo
20:51:33 <woodster_> redrobot, but once the new release cycle starts, we start with a clean slate (i.e. no alembic migration modules) correct?
20:51:52 <redrobot> woodster_ that's a good question... I don't know the answer to that.
20:52:15 <woodster_> grenade + other databases in the test (like PostgreSQL) maybe
20:52:37 <redrobot> woodster_ I'm not super familiar with alembic... is there a way to reset the schema?  ie. squash all the migrations and make that the new schema base?
20:53:19 <woodster_> well, the schema is initialized by the models in our models.py module.  The alembic scripts apply deltas to that.
20:53:29 <jaosorior> redrobot: I have no idea about that. But a fresh installation of Barbican would not even use the alembic scripts
20:53:48 <jaosorior> even the "initial" alembic migration script is actually just a placeholder
20:53:53 <jaosorior> doesn't really do anything
20:53:55 <woodster_> I can take a look at that though before next week
20:54:05 <redrobot> woodster_ sounds good
20:54:22 <woodster_> jaosorior, I think it just establishes the intial version stamp on the db
20:54:25 <redrobot> #action woodster_ to look into alembic migrations to understand what is needed to support Juno -> Kilo migration.
20:54:57 <jaosorior> yeah, the hash is used for the database
20:55:01 <jaosorior> but that's about it
20:55:19 <redrobot> I think ideally, at the start of the Cycle, we would reset the base schema
20:55:37 <redrobot> so that at the end of the cycle, we are able to migrate from the previous release to the current one.
20:55:38 <woodster_> redrobot +1
20:55:43 <jaosorior> redrobot: I'm not sure about that
20:56:00 <redrobot> jaosorior the assumption is that most operators will be running the official release
20:56:04 <jaosorior> since we still need to support migrating from Juno to Kilo, no? so then the hashes still need to be kept consistent
20:56:35 <redrobot> jaosorior so, for the Kilo release, the base should be the schema barbican had for the Juno-final release
20:56:41 <woodster_> I'll see if I can dig up info from other projects on it
20:57:01 <jaosorior> redrobot: yes
20:57:39 <rm_work> 3 minutes?
20:57:43 <rm_work> 2 minutes.
20:57:58 <redrobot> jaosorior and we need to be able to apply migrations such that when Kilo releases, the migrations can bring an existing Juno DB up to the new schema
20:58:14 <redrobot> I _think_ that's what grenade can do for us
20:58:20 <redrobot> but we'll see what woodster_  can dig up :)
20:58:23 <jaosorior> woodster_: From what I've noticed, keystone keeps all of them
20:58:32 <woodster_> I did add one more agenda item
20:58:35 <morganfainberg> we do not
20:58:38 <jaosorior> no?
20:58:44 <morganfainberg> we started collapsing migrations.
20:58:47 <jaosorior> I see a bunch of havana ones there
20:58:52 <jaosorior> oooh
20:58:53 <jaosorior> that sounds better
20:58:55 <morganfainberg> yes we are supporting n-2
20:59:05 <morganfainberg> we did the first collapse in juno
20:59:11 <morganfainberg> so we support havana->juno
20:59:29 <morganfainberg> this cycle we will support icehouse -> kilo
20:59:38 <morganfainberg> :)
20:59:42 <jaosorior> morgainfainberg: Thanks man, that was super quick :)
20:59:54 * morganfainberg swears he doesn't lurk in these channels to look awesome like that
20:59:54 <redrobot> just in the nick of time too
21:00:01 <redrobot> thanks everyone!
21:00:04 <redrobot> #endmeeting