20:00:47 <redrobot> #startmeeting barbican
20:00:47 <openstack> Meeting started Mon Jul 28 20:00:47 2014 UTC and is due to finish in 60 minutes.  The chair is redrobot. Information about MeetBot at http://wiki.debian.org/MeetBot.
20:00:48 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
20:00:50 <openstack> The meeting name has been set to 'barbican'
20:01:19 <redrobot> The agenda for todays meeting is available at:
20:01:21 <redrobot> #link https://wiki.openstack.org/wiki/Meetings/Barbican
20:01:24 <redrobot> #topic Roll Call
20:01:36 <chellygel> \o/
20:01:37 <jvrbanac> _o/
20:01:37 <rm_work> o/
20:01:46 <tsv> o/
20:01:47 <hockeynu_> o/
20:01:50 <atiwari> o/
20:01:53 <bubbva> o/
20:01:53 <woodster__> o/
20:01:57 <kaitlin-farr> o/
20:01:57 <rellerreller> o/
20:02:25 <redrobot> woohoo!  lots of barbicaneers here today
20:02:34 <jaosorior> ~o/
20:03:08 <alee> o/
20:03:18 <redrobot> alrighty then, let's get started
20:03:39 <redrobot> #topic CR: Add more types to Containers Order
20:03:49 <redrobot> #link https://review.openstack.org/#/c/87405/
20:03:58 <redrobot> atiwari did you want to talk about this?
20:04:38 <atiwari> yes, it is waiting for review, just wanted to raise that
20:05:05 <redrobot> atiwari ok
20:05:19 <redrobot> +995 lines.  Should be a fun review :)
20:05:26 <atiwari> there are more depended on this one.
20:05:27 <atiwari> yes
20:05:32 <atiwari> :)
20:05:33 <hockeynu_> is there a bp or spec?
20:06:04 <atiwari> hockeynu_, #link https://review.openstack.org/#/c/98174/
20:06:18 <hockeynu_> awesome - thx!
20:06:53 <redrobot> and it looks like the BP just needs a +1 to Workflow.  Hopefully we can get the BP merged today.
20:07:07 <atiwari> redrobot, there are more depending on this, so if we can make some progress on this, that will be awesome
20:07:19 <atiwari> redrobot, ok
20:08:03 <redrobot> everyone please try to get some eyes on both of those CRs so we can unblock atiwari and friends.
20:08:38 <atiwari> redrobot, this impl has backward compatibility on Orders resource. I will clean those duplicates in later CR
20:08:45 <atiwari> just for fyi..
20:09:19 <redrobot> atiwari ok, sounds good.  I'll try to get to the review today.  Didn't get to do much reviewing over the weekend.
20:09:29 <redrobot> ok, moving on to the next topic
20:09:30 <atiwari> np
20:09:52 <redrobot> #topic Kilo Conference Presentation Proposals
20:10:00 <redrobot> Kilo = Paris?
20:10:18 <rellerreller> Ya, I thought that was the next name
20:10:18 <redrobot> was this woodster__ or alee that added this?
20:10:25 <rellerreller> I added this
20:10:26 <woodster__> Kilo = Japan
20:11:01 <rellerreller> Icehouse was HK, Juno was Atlanta I thought???
20:11:10 <hockeynu_> ^ +1 ^
20:11:12 <redrobot> I think rellerreller is right.
20:11:22 <hockeynu_> + oo
20:11:25 <alee> woodster__, the next one after Paris is in Japan?
20:11:39 <rellerreller> Anyways, I was wondering who all submitted proposals to the next conference. I was going to keep an eye out for them in case we get to vote again this time
20:11:42 <redrobot> alee rumor has it that the next one will be Tokyo... not official yet
20:11:56 <redrobot> rellerreller yes, actually, we've submitted a few
20:12:24 <rm_work> redrobot: did you actually do an abstract for the one we talked about on Friday? :P
20:12:33 <rellerreller> We have submitted two: "Secure Key Management via Barbican's Plugin Architecture" and "Securing Data at Rest"
20:12:34 <redrobot> woodster__ submitted (or is about to submit) a proposal for a talk about the new Plugin Architecture
20:12:52 <chellygel> rellerreller, i submitted a hands-on barbican workshop with woodster__, hockeynu_ , and jvrbanac
20:13:08 <rellerreller> +1
20:13:17 <redrobot> sounds like rellerreller and woodster__ are on the same page :) ...  woodster__ were you going to ask rellerreller and alee about that submission?
20:13:41 <rellerreller> Ya, I think our submissions are similar, if not the same
20:13:59 <woodster__> I sent an email to them a bit a ago about it...seeing if they'd like to co-present due to their strong hand in the design of it all
20:14:10 <rellerreller> We can work together to get one in there. They should not be competing against each other.
20:14:13 <redrobot> rm_work nope... though I may submit one to talk about how to use the Client.
20:14:30 <alee> woodster__, must have missed that email -- maybe I was in transit - but sure :)
20:14:31 <rm_work> redrobot: hmm k, I'll try to get my bit sqeezed in on the neutron track
20:14:59 <redrobot> rm_work you didn't seem too enthused about it so I canned the idea. :-P
20:15:03 <rm_work> heh
20:15:26 <redrobot> +1 to unifying rellerreller and woodster__ talks
20:15:27 <rm_work> I am enthused about it, but it's only like 10 minutes so I just needed a tiny bite of someone else's block :P
20:16:37 <redrobot> I know jraim  is submitting a few as well
20:16:50 <redrobot> Crypto, Python 3 and PyPy - A Path Forward for OpenStackCryptography and
20:16:50 <redrobot> the oslo.crypto Takeover
20:17:00 <redrobot> 2) Key Wrapping in Barbican - A Path to Federation
20:17:10 <redrobot> 3) Transparent Encryption Using Barbican
20:17:36 <redrobot> 4) Cryptography in OpenStack: Uses and Opportunities
20:17:45 <redrobot> 5) Cryptographic Performance in Python
20:17:55 <rellerreller> 4) +1
20:18:30 <atiwari> redrobot, I was thinking of submitting a presentation session on master key encryption management.
20:18:39 <atiwari> thoughts ?
20:19:03 <atiwari> master key encryption key
20:19:27 <redrobot> atiwari sounds interesting... would this cover HP's implementation of a Crypto plugin?
20:19:59 <atiwari> I am thinking for generic plugin approach to manage MKEK
20:20:57 <atiwari> Crypto plugin can choose a MKEK plugin if required
20:21:36 <redrobot> atiwari I see... that maybe an interesting talk.  I'd go see it. :)
20:21:55 <atiwari> ok, I will submit it today
20:22:05 <hockeynu_> I would go as long as I had a barbican shirt/hat/beard
20:22:30 <redrobot> I'm trying to dig up a list of the other things we submitted
20:23:01 <redrobot> I know jvrbanac is talking about Stockade
20:23:16 <jvrbanac> :D
20:23:16 <redrobot> it's a Django-based password-sharing app that uses Barbican as a back end
20:23:38 <hockeynu_> and its awesome...
20:24:00 <redrobot> possibly doing a Barbican: where we're at and where we're going talk... I'll have to check with jraim  about that one
20:25:27 <redrobot> rellerreller sound like enough talks?  :)
20:26:14 <rellerreller> Sounds awesome!
20:26:37 <rellerreller> I hope we get several accepted.
20:28:20 <redrobot> we do too!  Rackspace is sending anyone who gets a talk approved, so we're definitely wanting to see you guys in Paris.
20:28:39 <bubbva> redrobot: those all sound interesting. wish I could be there!
20:29:47 <redrobot> ok, that's all I have on the agenda for today
20:30:07 <redrobot> is there anything else we want to talk about while we're all here?
20:30:17 <kaitlin-farr> I have a question
20:30:26 <redrobot> kaitlin-farr go ahead
20:30:46 <kaitlin-farr> jvrbanac hockeynu_ and I were just discussing an issue that popped up with a patch I submitted today: https://review.openstack.org/#/c/101582/
20:31:02 <kaitlin-farr> I added arg checks to the classes in secret_store
20:31:32 <kaitlin-farr> so I wanted to see if other people had opinions
20:31:49 <kaitlin-farr> because the arg checks sort of break some of the existing tests
20:32:01 <kaitlin-farr> the stack trace was here: http://logs.openstack.org/82/101582/3/check/gate-barbican-devstack-dsvm/db90e79/logs/screen-barbican.txt.gz
20:32:14 <redrobot> #topic Broken devstack tests due to arg checking
20:32:53 <kaitlin-farr> so I guess there's two issues:
20:33:34 <kaitlin-farr> 1 - the server returned 500 code (jvrbanac and hockeynu_, was that unexpected behavior?)
20:33:44 <hockeynu_> yes - should never get 500
20:33:45 <woodster__> I think the issue is that secret store needs to be able to accommodate different secrets flows...one step secret stores, two step secret stores (neither of which require any meta data to be provided), and secret generates (which require most or all to be provided)
20:34:10 <kaitlin-farr> and 2 - should we keep arg checks and change the existing tests to not break or remove arg checks?
20:34:15 <woodster__> You'll get a 500 if (say) a ValueError is raised...that gets treated as a 500
20:34:50 <woodster__> The validators module is where we've been putting validation logic.
20:34:54 <hockeynu_> but controller should catch that and turn it into something reasonable (4xx) right?
20:35:30 <woodster__> raising a ValueError is a programmer logic problem...that should return a 500...essentially forcing the botched logic to be fixed
20:35:39 <woodster__> it is not a client data input error for example
20:36:23 <woodster__> validation should determine if, based on the flow involved if field-a is optional or required for example
20:36:32 <hockeynu_> yes, that is true
20:37:51 <kaitlin-farr> rellerreller do you have thoughts on the arg checks?
20:38:08 <alee> woodster__, I think though that there are some cases where ValueError is being raised for client errors .. and those need to be fixed to throw the correct exceptions.
20:38:10 <woodster__> so we have talked about adding a validate() method onto the secret store plugin at some point. So the supports() method would just say if that plugin could even consider the input data or not, and the validate() would do a 'deep dive' on that data to validate it.
20:38:33 <woodster__> alee: I'd agree with that
20:38:58 <rellerreller> kaitlin-farr I'm not sure at the moment. This sounds different than what the issue was this morning.
20:39:22 <rellerreller> I need to look at the error log
20:40:10 <kaitlin-farr> woodster__ the validation would occur at the time of the post request?
20:40:44 <woodster__> kaitlin-farr: yes
20:41:06 <alee> kaitlin-farr, just so I understand - why were the arg tests failing?  was it because of invalid client data?
20:41:12 <woodster__> ...so synchronously, not waiting until the workers pick up the task
20:43:13 <kaitlin-farr> alee, the arg checks were checking if the input was valid, i.e. was defined in the list of valid constants and making sure the input wasn't none
20:43:25 <hockeynu_> alee its failing in the devstack gate - tempest test doing a simple create secret.  The POST goes thru and eventually plugin gets called for store_secret and fails because None is passed in for the type parameter in SecretDTO c'tor and that fails the new test - thus raisingthe value error
20:44:08 <woodster__> yep, on secret POSTs/stores, those fields are optional
20:44:35 <woodster__> just optional meta data about a secret that the client could choose to provide if they wish
20:45:49 <woodster__> Soooo....should we consider adding a validate method to the plugin contract for Juno, or defer until Kilo?
20:45:59 <rellerreller> If it's optional then which component determines the value for it? Should it be Barbican core or SecretStore?
20:46:05 <alee> hockeynu_, kaitlin-farr - and the type is populated from the original request?  if that data is optional, then it sounds like we need to add some defaults
20:46:22 <alee> hockeynu_, kaitlin-farr - what you've uncovered is a bug.
20:46:43 <redrobot> alee I don't think defaults make sense in this case...  some of that metadata is "sometimes-required"
20:46:52 <rellerreller> I propose Barbican core provide default value. That way it is consistent across plugins.
20:47:09 <hockeynu_> its hardcoded None
20:47:11 <alee> either that or if there is no default, then the check must be changed
20:47:20 <hockeynu_> https://github.com/openstack/barbican/blob/master/barbican/plugin/resources.py line 60
20:47:29 <redrobot> ie, if I'm storing a password and POST it to /secrets, then I don't want that to default to "algortim": "AES" for example.
20:48:14 <hockeynu_> yep - that would bad...mmmkay
20:49:21 <woodster__> a client can store any data they wish as a secret...and don't have to tell Barbican what type it is either...so it's their little 'secret' (pun alert, sorry)
20:50:03 <alee> kaitlin-farr, hockeynu_ sounds to me like we need to rethink whether the arg checks are valid, given the many types of secrets that can be stored.  and only check those args that are really required.
20:50:21 <redrobot> alee +1
20:50:25 <kaitlin-farr> Ok, that makes sense
20:50:41 <hockeynu_> yes - find the places and add a "validate_me" flag (default false)...set to true when we want validation...
20:50:55 <hockeynu_> like SecretDTO c'tor for example
20:51:21 <rellerreller> If error is on line 60 then does not seem like arg error
20:51:55 <rellerreller> It looks like Barbican core is always setting None for secret type. It needs to determine which type to set for it.
20:52:07 <hockeynu_> line 60 passes None as parm 1...then in the c'tor it checks the value of parm 1 (type) and throws ValueError since its None
20:52:09 <rellerreller> According to https://github.com/openstack/barbican/blob/master/barbican/plugin/resources.py line 60
20:53:10 <rellerreller> Now I see
20:53:10 <woodster__> well, the algorithm in line 60 is not required, as that info is saved (if provided) on the Secret entity in line 30.
20:54:07 <woodster__> now, if a plugin were to require a field to be set, that is where the plugin.validate() method could be useful. So the validate() method would be called as part of the up-front validation processing.
20:54:32 <rellerreller> If you are going to store a secret then that information needs to be provided to the secretstore
20:54:33 <hockeynu_> yep!
20:54:53 <woodster__> So for secret store and the DTO, algorithm should probably be ignored for storage operations. It is only needed for generate operations.
20:55:09 <woodster__> rellerreller: why is this info needed to *store* a secret?
20:55:14 <redrobot> we're running dangerously close to the end of the meeting... this is a good discussion though... do we want to continue on #openstack-barbican?
20:55:47 <hockeynu_> works 4 me
20:55:48 <rellerreller> The backend SecretStore may need this information. KMIP will need it.
20:55:49 <redrobot> rellerreller I think the metadata is only required to *generate* a secret
20:56:16 <rellerreller> I definitely need it for storage.
20:56:21 <redrobot> rellerreller I see... hmm...
20:56:33 <rellerreller> I need the crypto alg and crypto length
20:56:54 <alee> rellerreller, what happens if whats being stored is not a symmetric key?
20:57:11 <redrobot> I was about to say, does the K in KMIP imply that it's always a key?
20:57:11 <rellerreller> alee, what do you mean?
20:57:13 <woodster__> rellerreller: if KMIP can only store specific types of secrets, then we really will need a validate() approach
20:57:51 <redrobot> rellerreller in Barbican, a Key is a Secret, but a Secret is not necessarily a Key
20:57:51 <woodster__> rellerreller: So I can't just store a db password in KMIP then?
20:58:08 <rellerreller> KMIP can store any type of secret it just needs certain parameters. For keys it requires knowing the alg and length
20:58:17 <alee> rellerreller, we're talking about the store_secret() method, right?  So, someone could choose to store a password for example.
20:58:22 <redrobot> we have 2 minutes until we get kicked out of this room
20:58:29 <rellerreller> You can store a blob as a secret or a password
20:58:31 <woodster__> rellerreller: so what algo would I used to store a db password in KMIP?
20:58:38 <redrobot> let's continue this conversation on #openstack-barbican?  ^_^
20:58:43 <woodster__> will do...
20:58:44 <rellerreller> ok
20:58:51 * jvrbanac moving to #openstack-barbican
20:59:48 <redrobot> thanks guys!  Good meeting!  First time we have to keep talking past the cutoff
20:59:54 <redrobot> #endmeeting