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