20:01:09 <redrobot> #startmeeting barbican
20:01:10 <openstack> Meeting started Mon Jul 13 20:01:09 2015 UTC and is due to finish in 60 minutes.  The chair is redrobot. Information about MeetBot at http://wiki.debian.org/MeetBot.
20:01:11 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
20:01:14 <openstack> The meeting name has been set to 'barbican'
20:01:20 <redrobot> #topic Roll Call
20:01:25 <igueths> o/
20:01:28 <alee> o/
20:01:29 <rellerreller> o/
20:01:29 <elmiko> hi
20:01:49 <kfarr> o/
20:01:49 <redrobot> Also, sorry I've been AFK for the last few days
20:02:13 <chellygel> (*＾▽＾)／
20:02:20 <redrobot> I've been moving apartments, but we're getting close to normalcy
20:02:56 <dave-mccowan> \o/
20:03:05 <redrobot> As usual the agenda can be found here:
20:03:09 <redrobot> #link https://wiki.openstack.org/wiki/Meetings/Barbican#Agenda
20:03:47 <jkf> Greetings
20:03:56 <silos1> o/
20:03:56 <redrobot> jkf o/
20:04:25 <jvrbanac> o/
20:04:26 <redrobot> #topic Action Items from the last meeting
20:04:30 <redrobot> #link http://eavesdrop.openstack.org/meetings/barbican/2015/barbican.2015-07-06-20.00.html
20:04:42 <redrobot> First one is jaosorior to backport the DogTag gate fixes into stable/kilo
20:04:55 <redrobot> jaosorior ping?
20:05:21 <woodster_> o/
20:05:24 <redrobot> I don't think jaosorior is here
20:05:32 <redrobot> we can punt to next week
20:05:38 <redrobot> #action jaosorior to backport the DogTag gate fixes into stable/kilo
20:05:43 <alee> redrobot, not sure if he's still awake .. he mentioned that he opened a bug and was going to look at it this week.
20:05:50 <alee> redrobot, I'll remind him
20:06:01 <redrobot> alee awesome, thanks
20:06:09 <redrobot> next action item was for me
20:06:10 <redrobot> Next action item redrobot to ping woodster about writing a spec for the additional acl role
20:06:27 <redrobot> which I'm going to do now
20:06:55 <redrobot> woodster_ we talked about the additional ACL role, and it was suggested that it would be good to have a blueprint for the change.
20:07:12 <woodster_> that sounds good
20:07:18 <woodster_> when is the deadline for those again?
20:07:58 <redrobot> Deadline for Liberty BPs is the liberty-2 milestone
20:08:12 <redrobot> so you have until the end of July
20:08:15 <redrobot> #link https://wiki.openstack.org/wiki/Liberty_Release_Schedule
20:08:29 <woodster_> redrobot: thanks
20:08:41 <jaosorior> redrobot: I'm half here
20:09:12 <alee> jaosorior, I told redrobot I'd remind you to backport the dogtag gate fixes ..
20:09:29 <alee> jaosorior, you've been reminded :)
20:09:42 <jaosorior> alee, redrobot: Yeah, I'll take time this week to do those backports
20:09:47 <woodster_> jaosorior: just past the ballmer peak?
20:09:58 <alee> cool beans
20:10:03 <redrobot> awesome
20:10:09 <redrobot> ok, moving on to the agenda items
20:10:25 <redrobot> #topic Magnum integration
20:10:40 <redrobot> There was a thread about this last week on the ML
20:11:28 <redrobot> Magnum wants to enable TLS inside their project, and will be using Barbican to generate and store x.509 certificates.
20:12:09 <redrobot> Their team was having some trouble provisioning certs out of the box with our current setup, so I have it on my to-do list to look into that.
20:12:09 <alee> redrobot, this is something they want to do on setup only, or on a regular basis?
20:13:05 <redrobot> alee I'm not 100% on all the details, but I think they'll be provisioning new certs when new nodes spin up.
20:13:22 <alee> redrobot, ok
20:15:28 <redrobot> If anyone is interested in the details, you can find links here:
20:15:30 <redrobot> #link http://lists.openstack.org/pipermail/openstack-dev/2015-July/068993.html
20:15:56 <alee> redrobot, I'll look into it too and respond on the trhread as well.
20:16:30 <jaosorior> woodster_: Not yet :P
20:16:54 <redrobot> any other questions/comments about Magnum integration?
20:17:06 <alee> redrobot, do they have an irc channel?
20:17:16 <redrobot> alee #openstack-containers
20:17:24 <alee> redrobot, ok
20:17:42 <redrobot> ok, moving on
20:18:02 <redrobot> #topic CAs blueprint
20:18:13 <redrobot> #link http://specs.openstack.org/openstack/barbican-specs/specs/liberty/add-cas.html
20:19:01 <alee> redrobot, whats the question here?
20:19:11 <redrobot> I was reviewing this BP after it merged, and I noticed it was missing info on implementing a non dogtag version
20:19:27 <redrobot> So I think maybe we should consider making this an optional feature?
20:20:14 <alee> redrobot, well - it is optional for a ca plugin to implement this.
20:20:50 <alee> if I recall correctly, there is a default implementation of the relevant methods
20:21:39 <alee> redrobot, there is a supports_create_ca() method
20:21:46 <alee> which defaults to false
20:23:08 <alee> and a create_ca() method which defaults to throwing not implemented -- that method would not be called if supports_create_ca is false.
20:23:09 <redrobot> I guess it just wasn't clear to me from reading the spec what a non-dogtag deployment would look like
20:23:48 <alee> redrobot, in case no plugin can support this, we would end up returning No Plugin or similar
20:24:13 <alee> redrobot, just like if no plugin supported key generation of a certain type for instance
20:25:47 <redrobot> I was thinking more along the lines of optional api extensions like in nova, but I think no plugin errors would be fine
20:26:38 <alee> redrobot, I'm open either way -- no plugin error means one less thing to configure
20:26:47 <alee> in case you want to support the functionality
20:27:35 <redrobot> Anyone else care to chime in?  ...  woodster_  we had talked about optional features before.  What do you think?
20:27:46 <woodster_> redrobot: it seems the extensions api approach is a more fundamental change to the API structure of Barbican...probably worthy of its own discussion at the mid cycle
20:29:19 <redrobot> woodster_ fair enough
20:29:27 <redrobot> I added the topic to the midcycle etherpad
20:29:29 <redrobot> #link https://etherpad.openstack.org/p/barbican-liberty-midcycle
20:29:39 <redrobot> ok, moving on
20:29:54 <rellerreller> It's probably a good thing to discuss.
20:30:10 <rellerreller> I saw silos1 had a KMIP-specific proposal for the API.
20:30:19 <rellerreller> Sorry, I"m a slow typer today.
20:30:34 <redrobot> rellerreller I'll add it to the agenda
20:30:41 <redrobot> #topic copy constructor for secrets and containers
20:30:51 <redrobot> elmiko you wanted to give an update on this?
20:30:55 <elmiko> yea
20:30:58 <redrobot> #link https://review.openstack.org/#/c/127823/
20:31:13 <elmiko> i just wanted to complete the loop on the discussions we had on openstack-api
20:31:30 <elmiko> i think there is a consensus forming in the review
20:32:00 <elmiko> but we did discuss it, and aside the from PUT update of secrets (which sidetracked us), we had major solutions
20:32:11 <elmiko> the one miguelgrinberg mentions in the review and the one i suggested
20:32:32 <alee> elmiko, seems like the one you suggested is the one that got traction
20:32:40 <jvrbanac> sooo I had some input on patchset 7
20:34:00 <elmiko> so, the takeaway from the api-wg was that there isn't really an advised way to do this type of operation, some hits came up on stackoverflow for the style i suggested
20:34:01 <jvrbanac> I wasn't thrilled about having magic payloads on endpoints
20:34:10 <elmiko> and i think miguelgrinberg's is clean as well
20:34:29 <elmiko> yea, agreed jvrbanac
20:35:07 <jvrbanac> We had a similar discussion a long time ago when it came to payloads for secrets
20:35:26 <jvrbanac> fast-foward and we ended up breaking it out to a different endpoint
20:35:43 <woodster_> jvrbanac: your suggested approach is similar to Miguel's 2nd suggested one, correct?
20:36:06 <woodster_> jvrbanac: ....i.e. a POST to secrets/{UUID-to-copy}
20:36:20 <woodster_> jvrbanac: ...with or without the /copy at the end
20:36:21 <jvrbanac> woodster_, sorta. My approach was for POST http://{barbican}/v1/secrets/{uuid}/copy
20:36:44 <jvrbanac> Similar to how we do payloads
20:36:46 <elmiko> i'm not so fond of creating new endpoints for controller-esque operations
20:36:59 <alee> elmiko, +1
20:37:09 <elmiko> this style of operation has come up within the api-wg as a behavior to advise against
20:37:39 <jvrbanac> elmiko, did they say why?
20:37:59 <jvrbanac> because it feels the most explicit and discoverable
20:38:10 <elmiko> jvrbanac: it's a pretty philosophical discussion, but it has to do with REST being a state transfer mechanism around resources
20:38:18 <elmiko> and not an RPC type mechanism
20:39:04 <elmiko> jvrbanac: miguelgrinberg and stevelle are great folks to talk with about this though, their knowledge and experience are much deeper than mine
20:39:40 <elmiko> also, the o'reilly rest cookbook has some info on it
20:40:32 <elmiko> jvrbanac: does that make some sense?
20:41:46 <jvrbanac> elmiko, as much as a philosophical argument is going to be. Personally, I still think it's bad design regardless what the books say.
20:42:18 <elmiko> jvrbanac: wait, which is bad design?
20:42:47 <redrobot> I think the POST to v1/secrets/UUID is interesting
20:43:25 <elmiko> (i was speaking about POST to ../copy)
20:43:42 <alee> redrobot, that seens counter-intuitive somewhat to me.   POST /secrets?copy_ref={uuid} seems clearest to me.
20:44:35 <alee> gotta step away for a sec .. but please go on :)
20:44:57 <jvrbanac> elmiko, I was referring to magic body's or parameters. so like the /secrets?copy_ref or the copy ref in the body both feel very dirty
20:45:10 <elmiko> jvrbanac: ahh, ok
20:45:28 <elmiko> i think we all agreed that magic to the body was non-ideal
20:45:59 <elmiko> i think the feeling about query params was that they were more easily discoverable/documentable than body related changes
20:46:22 <elmiko> in all fairness, i like miguelgrinberg's approach as well.
20:47:00 <elmiko> if anyone is interested i can dig up a link to the conversation in irc after this meeting, just ping me
20:48:07 <jvrbanac> elmiko, I get the rational for those ideas. However, considering Barbican's current api design, I don't think they fit that well
20:48:21 <elmiko> jvrbanac: understandable
20:48:45 <jvrbanac> elmiko, I think it's because we're already mixing so many behaviors on our resources that it becomes confusing
20:48:59 <jvrbanac> elmiko, the same thing happened to secrets payload retrieval.
20:49:07 <jvrbanac> elmiko, just food for thought
20:49:13 <elmiko> yea, i know the feeling... (/me is working on sahara v2 api spec)
20:49:51 <elmiko> jvrbanac: fair, and i just wanted to get a few more eyes on the review. ultimately it's up to the team to make the right decision for barbican
20:50:48 <redrobot> ok, sounds like we just need more reviewers
20:51:02 <redrobot> anything else on this topic?
20:51:09 <elmiko> nothing from me
20:51:22 <alee> redrobot, elmiko , jvrbanac - more reviewers is fine, but I'd like to put this to rest soon
20:51:31 <alee> (pun intended)
20:51:34 <redrobot> lol
20:51:42 <woodster_> alee: beat met to it
20:51:46 <elmiko> alee: lol, i've said my peace. i leave it up to the group to vote on this one
20:51:50 <woodster_> alee: beat me to it
20:52:03 <alee> can we vote now ?
20:52:09 <alee> or do we need more time?
20:53:22 <jvrbanac> This is the direction everyone wants to go. Ok, but I still think it's a mistake.
20:53:41 <alee> (I didn't realize this simle spec was going to cause so much controversy)
20:54:11 <jvrbanac> lol I think any change to secrets api is going to cause some :)
20:54:21 <jvrbanac> considering the history of the api
20:54:26 <alee> indeed
20:54:26 <redrobot> one thing I don't like about the ?copy_ref=XXXX  is that XXXX is going to need to be a ful URI to be consistent with the rest of the api
20:54:30 <redrobot> and that just seems weird to me.
20:54:45 <woodster_> This one is explicit to me: POST /secrets?copy_ref={uuid}    This one I almost like but seems a bit too subtle: POST /secrets/{UUID-to-copy}
20:55:11 <alee> woodster_, my thoughts exactly
20:55:13 <woodster_> I'd be ok with the latter approach if that is the consensus though
20:55:31 <redrobot> POST /secrets?copy_ref=https://some-cloud.com/uuid
20:56:34 <woodster_> redrobot: correct
20:56:53 <jvrbanac> ?copy_ref={uuid} will most likely cause problems with federation. ?copy_ref={full_hatoas} would have to be encoded to keep parsers from barfing
20:57:12 <elmiko> jvrbanac: yea, i thought about that too with the federation
20:57:21 <woodster_> sounds like POST /secrets/{UUID-to-copy} then?
20:57:35 <elmiko> that might be the cleanest
20:57:45 <alee> ok with me
20:57:54 <woodster_> Votes for POST /secrets/{UUID-to-copy} then?
20:57:56 <woodster_> +1
20:58:00 <redrobot> +1
20:58:00 <alee> +1
20:58:03 <elmiko> +1
20:58:15 <woodster_> neys to that approach?
20:58:32 <alee> the ayes have it :)
20:58:35 <alee> awesome
20:58:42 <woodster_> (crickets... :)
20:58:50 <jvrbanac> still not a fan, but I'll just tell you I told you so in a year
20:58:55 <jvrbanac> lol
20:59:03 <alee> :) just in time for v2
20:59:07 <redrobot> #agreed Copy Secret API will use POST /v1/secrets/{UUID-to-copy}
20:59:14 <woodster_> alee: :)
20:59:18 <alee> ok - will write it up and submit later tonight
20:59:23 <redrobot> just in time for the end of the meeting
20:59:30 <alee> thanks!
20:59:39 <redrobot> and I think rellerreller left, so I'll had his topic to next week's agenda.
20:59:43 <redrobot> thanks everyone for coming!
20:59:47 <redrobot> #endmeeting