20:00:17 <redrobot> #startmeeting barbican 20:00:18 <openstack> Meeting started Mon Feb 9 20:00:17 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:19 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 20:00:21 <openstack> The meeting name has been set to 'barbican' 20:00:26 <redrobot> #topic Roll Call 20:00:33 <jaosorior> o/ 20:00:42 <hockeynut> o/ 20:00:51 <tsv> o/ 20:01:04 <woodster_> o/ 20:01:20 <dave-mccowan> o/ 20:01:21 <elmiko> yo/ 20:02:00 <rellerreller> o/ 20:02:02 <redrobot> a little light on barbicaneers today... but that's no problem! :) 20:02:09 <redrobot> as usual the agenda can be found here: 20:02:14 <redrobot> #link https://wiki.openstack.org/wiki/Meetings/Barbican 20:02:29 <jvrbanac> o/ 20:02:47 <arunkant> o/ 20:02:53 <redrobot> Ok, let's get this started 20:02:59 <redrobot> #topic Kilo-2 20:03:10 <redrobot> #link https://launchpad.net/barbican/kilo/kilo-2 20:03:24 <redrobot> In case you missed it, Kilo Milestone 2 was released last week 20:03:37 <redrobot> many thanks to jaosorior for all the hard work 20:03:45 <hockeynut> + oo 20:03:47 <redrobot> and everyone else too! 20:03:50 <jaosorior> :D 20:03:54 <alee> o/ 20:04:04 <redrobot> not trying to leave anyone out :) 20:04:26 <woodster_> jaosorior: thanks! 20:04:32 <redrobot> and just so that you guys can put this in your calendar 20:04:38 <redrobot> Kilo-3 is due March 19 20:05:08 <rm_work> o/ 20:05:09 <redrobot> And as you may know Kilo-3 will be the Feature Freeze date for the Kilo cycle 20:05:21 <redrobot> #link https://wiki.openstack.org/wiki/Kilo_Release_Schedule 20:05:31 <redrobot> ok, moving on... 20:05:38 <chellygel> super late o/ 20:05:49 <redrobot> #topic Swift + Castellan 20:05:58 <redrobot> I'm not sure who proposed this topic? 20:06:41 <redrobot> Bueller? 20:06:42 <tsv> i believe this is carry forward from last time, woodster ? 20:06:55 <redrobot> actual text was "Update on Swift integration with KeyManager, if/when moving to Castellan" 20:07:10 <rellerreller> Whatever happened to that? At the summit everything seemed unresolved. 20:07:19 <rm_work> oh, per last time I think there was some argument about whether Castellan was even ... necessary? or something? 20:07:27 <rm_work> (I still think yes) 20:07:30 <tsv> redrobot, last week i asked if we know when swift will be using barbican and if they are using castellan 20:07:40 <woodster_> reaperhulk, did you add that one? I'm curious about it, so maybe I did, but can't recall :) 20:07:47 <tsv> woodster said he will check with swift and let us know 20:08:02 <tsv> woodster, is that correct ? 20:08:32 <woodster_> #action reaperhulk was the closest to that integration effort, I'll follow up with him 20:08:59 <woodster_> he's around the office today, but probably catching up after a week off 20:09:56 <redrobot> Ok, we can table this until next week 20:10:01 <redrobot> moving on 20:10:09 <redrobot> #topic Barbican packaging 20:10:31 <redrobot> Just wanted to give a heads up that xaeth is currently working on getting Barbican into Fedora 20:10:59 <redrobot> you may have seen him in the channel asking questions 20:11:21 <redrobot> also not sure who added this to agenda... is there anything else that needed to be talked about on this topic? 20:12:59 <alee> redrobot, not sure but I will be working with him to do the fedora reviews 20:13:11 <alee> so they should go pretty quickly 20:13:18 <redrobot> alee awesome! 20:13:46 <alee> and then we start the steps to get it into RHOS 20:13:50 <redrobot> hopefully we'll be able to release Kilo final straight to the Fedora repos 20:14:07 <redrobot> alee RHOS != RDO ? 20:14:13 <alee> yup 20:14:22 <alee> yeah same same 20:14:28 <redrobot> cool 20:14:48 <redrobot> ok, moving on 20:14:53 <redrobot> #topic L-Summit 20:15:14 <redrobot> First, a reminder that today is the last day to propose talks for the Vancouver summit 20:15:24 * redrobot remembers he's still got to submit his 20:16:09 <redrobot> Second, we were asked about space accommodations for Barbican 20:16:18 <redrobot> apparently the summit will be a little different this time 20:16:23 <redrobot> and there won't be "pods" anymore 20:16:43 <elmiko> boo =( 20:16:49 <jaosorior> so... what will replace pods? 20:16:53 <redrobot> I was thinking that we would probably be ok with a room that can fit 10-15 in lieu of the pods 20:17:05 <redrobot> they're being replaced with "fishbowls" 20:17:18 <redrobot> which I _think_ means your own space, but I'm not 100% on that. 20:17:33 <elmiko> interesting 20:17:37 <woodster_> that is odd...is a fishbowl a first come first served set of tables, like Paris? :) 20:17:51 <redrobot> woodster_ lol, I hope not 20:18:10 <redrobot> #action redrobot to clarify what "fishbowl" space will be 20:18:14 <woodster_> but 'pods' aren't to be confused with 'fishbowls' then 20:18:42 <woodster_> Just noting that there is an etherpad to start collecting design/table session topics here: 20:18:43 <woodster_> #link https://etherpad.openstack.org/p/barbican-L-design-sessions 20:18:54 <redrobot> I'll try to have a better answer for you guys next week... I mainly wanted to know if y'all think 10-15 peeps would be about accurate for what-used-to-be-pods 20:19:10 <woodster_> that sounds good to me 20:19:46 <rellerreller> I think that sounds about right 20:20:20 <redrobot> ok, awesome... 20:20:27 <redrobot> man we're tearing through the agenda this week. 20:20:38 <redrobot> #topic Mid-Cycle Meetup 20:20:59 <redrobot> #link https://wiki.openstack.org/wiki/Sprints/BarbicanKiloSprint 20:21:23 <redrobot> the Mid-Cycle meetup is next week 20:21:54 <redrobot> we have an etherpad for keeping track of topics we want to discuss 20:21:58 <redrobot> #link https://etherpad.openstack.org/p/barbican-kilo-sprint 20:22:17 <SheenaG1> Related (kind of): would anyone be interested in an outing to a giant pinball arcade in Austin during the visit? I think we should have enough folks with cars that we can swing it, as it's not downtown 20:22:22 <woodster_> already?!? coming up quick...just need to land that quote bp before then if possible to stay on track :) 20:22:52 <redrobot> it would be awesome if we can get some more ideas on the etherpad before next week so that we can start thinking about an agenda for the mid-cycle 20:23:28 <redrobot> woodster_ +1 ... it would be awesome if we can get all Essential and High priority BPs landed before the mid-cycle 20:23:45 <redrobot> but if we don't we can definitely make BP reviews the first agenda item we tackle next week. 20:23:55 <woodster_> ...and then figure out what we can do for the final Kilo release :) 20:24:34 <redrobot> woodster_ indeed... one of the goals for the mid-cycle is to have a good idea of what we can land for Kilo-3 20:25:43 <redrobot> SheenaG1 I would definitely love to get some pinball action in 20:26:20 <redrobot> which brings up a good point: we can also add afterhours stuff to the etherpad :) I hear Austin is a fun place, and we have quite a few barbicaneer natives there. 20:26:59 <SheenaG1> I'm a native now! If you guys have ideas, put 'em up and I can find good places to go. 20:27:20 <hockeynut> we can all come up with some good ideas (6th St, cough, cough) 20:27:46 <redrobot> yup... Omni hotel happens to be within crawling distance of 6th St 20:28:06 <hockeynut> perfect. 20:28:11 <jaosorior> anybody gonna be there on the 15th? That's when I arrive 20:29:09 <redrobot> jaosorior I won't be there until Monday morning... but jvrbanac, reaperhulk, SheenaG1 all live out there 20:29:25 <SheenaG1> and hockeynut and tdink_ 20:29:30 <alee> jaosorior, I arrive on the 14th. Will be staying with some friends north of Austin till Mon morning. 20:29:47 <woodster_> sounds like hockeynut will be waiting for you on 6th... 20:29:54 <hockeynut> Chuys 20:30:14 <jaosorior> well, to the people there, I'll ping you soon to meet up for pints then :D 20:30:29 <hockeynut> jaosorior looking forward to it! 20:30:47 <redrobot> any other comments about the mid-cycle? 20:32:37 <redrobot> Ok, moving on... 20:32:42 <redrobot> #topic Action Items 20:33:00 <redrobot> so one of the things I want to get better at, is reviewing action items from the previous meeting 20:33:37 <redrobot> I'm going to try to review action items after the roll call at the beginning of the meeting 20:33:45 * redrobot realizes he forgot to do that this meeting 20:34:08 <redrobot> so, for last week woodster_ had an action to look into alembic juno -> kilo migration 20:34:29 <redrobot> woodster_ I saw your email to the ML asking about Grenade + Tempest 20:34:35 <redrobot> woodster_ any other updates on that front? 20:35:03 <redrobot> #link http://lists.openstack.org/pipermail/openstack-dev/2015-February/056346.html 20:35:19 <woodster_> I'm still digging into that one. It appears you can branch with the latest alembic version, and I believe Ceilometer is doing that now. I've been more focused on the grenade issue, but I'll keep digging into the alembic migration across releases 20:36:00 <redrobot> #action woodster_ to continue researching alembic support for Juno -> Kilo migration 20:36:08 <woodster_> so essentially each release you make a branch for that release. You also make a alembic version that catches you up to the previous release. 20:36:16 <woodster_> yep, will fine tune that understanding 20:36:58 <woodster_> BTW, regarding Swift/Barbican interaction: SheenaG1 pointed out that a Swift encryption CR landed already (I don’t think rellerreller’s Castellan comment made it in though): 20:36:59 <redrobot> woodster_ thanks 20:37:05 <woodster_> #link https://review.openstack.org/#/c/123220 20:37:31 <woodster_> (I think that was the remaining action item) 20:38:30 <redrobot> woodster_ interesting... thanks for the link. Definitely need to keep an eye out on the implementation. 20:38:42 <redrobot> ok, moving on... 20:38:57 <redrobot> #topic Soft Deletes and Quotas 20:39:08 <redrobot> hockeynut did you want to talk about this? 20:39:13 <hockeynut> certainly 20:39:27 <hockeynut> currently our deletes are soft deletes - marked as deleted in the DB but they still take up space 20:39:42 <hockeynut> new BP implements quotas - and these deleted items are counted against your quota 20:40:18 <hockeynut> that makes testing painful as many create/delete cycles will eat up your quota very quickly, and that violates the principle of least astonishment 20:40:43 <redrobot> I see you didn't get any responses on the ML :( 20:40:45 <redrobot> #link http://lists.openstack.org/pipermail/openstack-dev/2015-February/056126.html 20:41:23 <redrobot> Also, here's the quota BP 20:41:25 <redrobot> #link https://review.openstack.org/#/c/132091/ 20:41:26 <hockeynut> so I think we need to look at delete and how do we reconcile with the quotas so that audit/etc requirements are handled and we still enforce what we need to enforce 20:42:15 <redrobot> I guess the obvious question would be "Can we just not count soft-deleted secrets towards the quota?" 20:42:32 <woodster_> Until we have hard delete capability, I believe we need to count soft deleted resources against a quota otherwise these quotas do no good to prevent system abuse. 20:42:40 <hockeynut> redrobot that could lead to someone loading up our DB with orphaned secrets 20:42:47 <hockeynut> leading to perf problems, etc 20:42:56 <hockeynut> woodster_ is correct 20:43:00 <hockeynut> (as usual) 20:43:09 <woodster_> I'm thinking a background process could hard delete secrets after a brief period of time...but that is not so deterministic for testing 20:43:25 <tsv> some EDI systems i worked in the past have a separate audit db where old/unused data is moved to after a period of time. the audit db could further be archived or deleted 20:43:39 <woodster_> we could also add a cloud-admin hard delete feature 20:43:41 <hockeynut> tsv yes, thats a valid option (archive) 20:44:16 <hockeynut> woodster_ I like that one best - another rbac role so only special folks can delete type=discard or somesuch 20:44:31 <woodster_> it would be nice to have a way via API to hard delete synchronously to testing phases 20:44:58 <hockeynut> yes - an option on delete (for appropriately roled users) seems to make the most sense and would be easiest to implement 20:45:09 <woodster_> well, with the quote bp, we are introducing the 'cloud admin' concept to Barbican (so not the barbican admin) 20:45:42 <hockeynut> could (or maybe not) be more finegrained - something to think about 20:46:01 <woodster_> ...that user could perform hard deletes perhaps...seems scary to me though 20:46:11 <arunkant> But once the limit is reached..then what is the behavior client is expected to do? Raise the limit as hard delete is not an option? I mean it adds additional logic on client side. 20:47:14 <woodster_> well, client's would not be able to raise that limit, only the admin could do that. 20:47:16 <arunkant> to do this error handling as over time..you can reach the limit on a system which have number of deleted keys 20:47:19 <jaosorior> woodster_: +1 20:47:48 <woodster_> so it seems that independent of this quota bp, we would need a bp to address hard deletes once and for all 20:47:50 <hockeynut> not even sure that this superdelete would be for anyone but the admin 20:47:57 <hockeynut> woodster_ + oo 20:48:30 <hockeynut> I'm tossing some notes into https://etherpad.openstack.org/p/barbican-kilo-sprint 20:48:53 <alee> its a little confusing for someone to have - say a quota of 100 secrets - and then actually end up with say 50 because of deletes. 20:48:59 <tsv> woodster, hockeynut, is this soft delete limitation due to audit pursposes or rbac ? i mean, if audit reasons, even admin cannot delete right ? 20:49:06 <alee> do we need a separate quota for deleted entries? 20:49:27 <redrobot> alee +1 that's an interesting idea 20:49:38 <woodster_> if folks are concerned though, the quota implementation could initially not count soft deleted resources? 20:50:07 <arunkant> alee + 1...yes over period of time..system will have deleted, expired keys..which will periodically require the need of raising these limits 20:50:08 <woodster_> tsv, the original reason was out of concern for mistaken hard deletes I believe 20:50:23 <hockeynut> woodster_ or at least a sql script to clean 'em out :-) 20:50:43 <tsv> woodster, thanks. hockeynut +1 :) 20:50:44 <alee> arunkant, or removing /archiving them 20:50:45 <woodster_> hockeynut, +1 20:51:10 <hockeynut> another option - make hard delete a 2nd call after a normal delete - kind of an "are you sure?" 20:51:18 <hockeynut> plenty of interesting ideas... 20:51:38 <redrobot> yeah... definitely sounds like we might have to revisit this next week 20:51:49 <hockeynut> yup 20:51:52 <woodster_> there was also talk in the past of having a per project or per secret hard/soft delete policy 20:52:20 <alee> if we have a separate quota for deleted entries then we can easily separate the quota problem from the delete problem. basically we can solve the quota problem - and we'll have the infrastructure for another quota. 20:52:21 <arunkant> alee, yes..provided there is mechanism to do in barbican via API or some periodic cleanup mechanism 20:52:24 <woodster_> ...as there are some compliance regimes that require a true hard deletion (if I recall from the distant past) 20:53:02 <hockeynut> gc 4 secrets 20:53:08 <hockeynut> (c) 2015 20:53:15 <alee> seems to me that dealing with soft/hard deletes is a whole separate BP 20:53:22 <hockeynut> alee + oo 20:53:38 <hockeynut> and not a trivial BP 20:53:44 <woodster_> alee +1 that's what I'm in favor of. I'd like to keep independent of the quota bp if possible. 20:53:44 <jaosorior> alee: +1 20:53:55 <tsv> alee, +1 20:53:58 <woodster_> alee, the exception being quota on deleted secrets 20:54:32 <hockeynut> woodster_ that would be a possible solution in the delete BP, right? The current BP would go forward as-is? 20:55:13 <redrobot> I like the idea of having a quota on "auditable secrets" ie, the soft deleted ones 20:55:25 <alee> woodster_, right -- I'm thinking we allow current quota BP to go forward - counting deleted secrets in the quota. 20:55:33 <woodster_> hockeynut, I'd prefer that...so we can land that innitial bp and get traction on it. The delete issue would only add to that API (or else provide other means to delete) 20:55:36 <alee> then subsquent bp makes this a separate quota 20:55:42 <hockeynut> woodster_ yessir 20:56:03 <woodster_> +1's all around then :) 20:56:16 <hockeynut> alee yup - unless we decide that another quota isn't the best solution (right now just lots of options that all need some deep thought and queso) 20:56:20 <woodster_> ...so if folks can review teh quote bp in that context... 20:56:38 <alee> hockeynut, right 20:56:40 <arunkant> woodster_, +1 20:56:46 <woodster_> hockeynut,...and pints as jaosorior mentioned 20:56:57 <hockeynut> perfect 20:57:06 <redrobot> ok, so it seems we're in agreement then. 20:57:13 <redrobot> which is great, because we're almost out of time. 20:57:20 <tsv> woodster_, thanks for your latest comments. redrobot, hockeynut, could you please check on the replies to your comments ? 20:57:21 <hockeynut> a happy coincidence 20:57:29 <redrobot> tsv will do 20:57:33 <hockeynut> yep 20:57:38 <tsv> thanks 20:57:45 <jaosorior> woodster_: +2 20:57:54 <redrobot> No IRC meeting next week because of the Mid-Cycle 20:58:12 <redrobot> See y'all in Austin! 20:58:17 <hockeynut> looking forward to seeing y'all ! 20:58:27 <alee> <start shameless plug> I have a bunch of pretty large code CRs that have been hangling out for awhile. Would love to get traction on these before mid-cycle. <end plug> 20:58:28 <hockeynut> PS its 80 and sunny today 20:59:00 <redrobot> alee I owe you a ton of reviews... I'll get to at least some of them tonight 20:59:09 <alee> redrobot, thanks 20:59:21 <redrobot> thanks everyone for coming 20:59:24 <redrobot> #endmeeting