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