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