19:58:59 #startmeeting barbican 19:58:59 Meeting started Mon Sep 21 19:58:59 2015 UTC and is due to finish in 60 minutes. The chair is redrobot. Information about MeetBot at http://wiki.debian.org/MeetBot. 19:59:00 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 19:59:03 The meeting name has been set to 'barbican' 19:59:23 #topic Roll Call 19:59:33 o/ 19:59:35 Present 19:59:41 \o/ 19:59:49 o/ 20:00:58 o/ 20:01:06 As usual today's agenda can be found here: 20:01:10 #link https://wiki.openstack.org/wiki/Meetings/Barbican 20:01:29 not a whole lot of barbicaneers here today :( 20:01:36 o/ 20:01:53 ok, let's get it started 20:02:01 #topic Action Items from last meeting 20:02:06 #link http://eavesdrop.openstack.org/meetings/barbican/2015/barbican.2015-09-14-20.00.html 20:02:09 o/ 20:02:11 no updates here.... 20:02:14 * redrobot sucks at action items 20:02:22 #action redrobot to make diagrams of federation workflows discussed with Joe 20:02:33 #action edrobot to ask release managers about Barbican in Kilo release notes 20:02:37 #undo 20:02:38 Removing item from minutes: 20:02:42 #action redrobot to ask release managers about Barbican in Kilo release notes 20:02:48 ed robot, who's that guy? 20:02:49 o/ 20:03:02 elmiko lol 20:03:18 ok, moving on to the actual topics for this meeting 20:03:30 arunkant ping? 20:04:03 yes..jsut added item regarding barbicanclient failures at neutron gate 20:04:22 arunkant just making sure you were online 20:04:25 #topic Barbicanclient failures on neutron test gate 20:04:39 arunkant you have the floor 20:05:00 Its failing for all recent barbicanclient builds..so was wondering how to investigate this further. 20:05:55 I see there is a recent check added in devstack around related error area. But not sure how to identify what's needed to change for barbican. 20:06:22 Change in devstack: https://github.com/openstack-dev/devstack/commit/c71973eb04d05c2497eb930c4e1b59dcaf983085 20:07:06 arunkant I haven't looked into it... 20:07:08 Is there anybody in team who has expertise in this area ? 20:07:25 has anyone else looked at this failing gate? 20:07:41 redrobot, I've taken a look 20:07:49 diazjf anything interesting? 20:07:58 http://logs.openstack.org/43/208343/15/check/gate-tempest-dsvm-neutron-src-python-barbicanclient/bb736f2/logs/devstacklog.txt.gz 20:08:15 seems as though the error is [ERROR] /opt/stack/new/devstack/inc/python:178 The following LIBS_FROM_GIT were not installed correct: python-barbicanclient 20:08:45 I was thinking it ,maybe due to this change 20:08:46 https://github.com/openstack/barbican/commit/803a8a0256724876b98fceef24ec7cd4c2eb58a8 20:08:53 but lets ask rm_work 20:09:26 diazjf ..Looked into this futher..and there is a new check added in devstack..may be we need to add something in that regard on barbican devstack side 20:09:28 I may have some time to look into it after we get RC1 shipped 20:09:51 I would suggest asking for help in infra, or maybe with the neutron folks. 20:10:50 Would be quicker if in house expert can look into this 20:11:08 o/ 20:12:40 redrobot, so far there is no indication that issue is related to neutron code base. 20:12:53 arunkant not sure we have a devstack expert among us... rm_work would probably be the closest, but he was mostly interested in getting the lbass gate running 20:13:33 redrobot: okay will ping him and then in parallel will try to find other help 20:13:45 awesome, thanks for taking point on this arunkant 20:13:58 ok, moving on 20:14:06 #topic liberty-rc1 20:14:29 We're putting hte polish on the CAs feature 20:14:42 and by we I mean mostly dave-mccowan and alee :) 20:14:52 #link https://etherpad.openstack.org/p/barbican_cas_todo_list 20:14:57 is being used to track the pending work. 20:15:37 #link https://review.openstack.org/#/c/225387/ 20:15:42 ^^ could use some reviews 20:15:47 o/ 20:15:48 redrobot, stillwaiting for you to +2/W https://review.openstack.org/#/c/225387/' 20:16:20 redrobot, it would have been +2'ed by Oz but he's probably asleep. 20:16:26 see his last comment 20:16:34 alee I had a question about the verbs-in-routes for the urls 20:16:46 o/ 20:16:59 o/ 20:17:19 mostly curious why we're not using more restful POST / DELETE type of requests instead of add-xxx and remove-xxx 20:17:36 +1 20:17:50 redrobot, you mean the "add-to-project" ? 20:17:57 for instance 20:18:42 what we're doing gere is creating a new association between two resources -- the project and the ca 20:18:49 not creating a new resource 20:19:51 arguably the association is the new resource? 20:20:00 it just seems weird to me. 20:20:26 but I don't have any better suggestions right now :-\ 20:20:43 arguably yes - redrobot this was agreeed upon a long time ago in the bp review 20:20:54 redrobot, in kilo as I recall corectly 20:21:01 if the new associations are resources, meaning they are separate entities, then POST seems appropriate 20:21:02 so its been around for awhile 20:21:53 elmiko, redrobot I'm not opposed to changing this - but maybe not right before rc1? this seems like a great v2 thing 20:21:58 but, if the associations are just updates to an existing resource then the more restful approach would be to PUT an updated version of the resource 20:22:42 yeah... definitely something to throw on the list for v2 20:22:49 alee: fair, sorry to derail 20:23:00 I was mostly curious... definitely not wanting to hold up RC1 20:23:05 elmiko, redrobot the standard approach would be to say expose /v1/proect-cas 20:23:20 and have that as a separate resource. 20:23:43 and then yes - the standard methods would apply 20:23:53 alee dave-mccowan besides this CR, what other CRs are needed before we're ready to cut RC1 ? 20:23:59 it's a straight-forward change, limited to the controller. the only question is how it impacts schedule. 20:24:30 this CR is hot off the press: https://review.openstack.org/226039 20:24:46 redrobot, dave-mccowan again - I'd just as soon not try to redesign the api just before rc1 20:24:55 alee +1 20:25:29 that CR covers to-dos # 1, 8, and 9 I think. 20:25:46 redrobot, so I'm working on CRs for issues 2 and 3 20:26:07 and dave-mccowan is working on a patch for issue 5 20:26:13 that leave to-do #5, which I'll do next. 20:26:36 I hope to get a CR out for 2 tonight 20:26:49 and maybe 3 by tomorrow EOD 20:27:30 and then we just need reviews .. hint, hint, nudge, nudge . 20:27:42 i had a question on a use case: is there a need for a user to know his default CA? this is used when an order goes out for cert and no CA is specified. The logic is 1) project-preferred, 2) global preferred, 3) earliest created. Barbican knows this, but the average user may not. do we need a GET /cas/default ? 20:28:20 why not require a CA every time? 20:28:54 or is the feature that the user does not need to know the CA? 20:29:01 right 20:29:37 the project admin can choose a given ca for the users in the project 20:29:49 and can change those on the fly 20:30:43 dave-mccowan, I need to think a little about that and how best to do it . lets take this offline perhaps? 20:30:54 there's no more topics on the agenda 20:30:57 we can continue here 20:31:02 oh ok .. 20:31:21 well in that case, ... 20:31:27 are users still allowed to use the non-preferred CAs? 20:31:54 ie, if my project admin sets Symantec as preferred for my project, does that force me to use only symantec? 20:31:58 redrobot, it depends on what the project admin has set up but yes 20:32:31 redrobot, if your project admin selects symantec and only symantec for your project, then you can only use symantec 20:32:45 maybe we don't need a new route, just an entry in the GET /cas response that shows which is preferred for my project? 20:33:17 redrobot, if they select symanatec and dogtag as your project cas, then one will be preferred - but you can choose 20:33:42 preferred means - if ca_ref not preovided , thats the ca that will be used 20:33:54 i think the user will need access to his effective default CA, so he can read the cacert. adding GET /cas/default could be one way. changing behavior of /cas/preferred is another way. 20:34:26 changing out of GET /ca/ might be bad. is magnum already coding to the current spec? 20:34:50 it could just be an additional attribute in that response 20:35:09 "preferred_ca_ref": "http:///something..." 20:35:31 dave-mccowan, originally I did think that GET /preferred was the way to get the preferred CA 20:35:57 and I 'm not sure thats not still not a bad idea 20:36:16 * redrobot 's head explodes from too many negatives 20:36:27 alee that's what i had assumed too. but the code isn't working that way. i can fix the code to match that. 20:36:58 on the other had, GET /cas/preferred could also be interpreted as the call usied by the project admin to see which of the project cas was defined as preferred 20:37:25 and in that interpretation, would be restricted to project admins 20:37:53 I still think this should all be information that is conveyed by just issuing a GET to /cas 20:38:47 alee /v3/ should have two root resources: /cas/ and /project-cas/ to avoid that confusion. 20:39:14 dave-mccowan, right - the previuos conversation was timely .. 20:40:34 dave-mccowan, and maybe thats how we fix it in v2 20:40:47 dave-mccowan, redrobot question is what to do now .. 20:41:33 all we need is a way for regular users to see the preferred CA? 20:41:55 yeah 20:42:15 I still think that GET /cas could include the information 20:42:20 in a backwards compatible way 20:42:39 redrobot, GET /cas right now returns a list of ca_refs 20:43:02 we'd have to change it to include ca_refs + attributes 20:43:28 what does the response look like? 20:43:47 { cas: [ref1, ref2, ref3] } ? 20:44:23 dave-mccowan, redrobot , woodster_ on the other hand -- if we were to change GET /cas/preferred to provide whatever the default is, that still would work for both project admin and regular user 20:44:32 can just the 1st one be the preferred one ? 20:44:34 GET /cas/ already has /all, /preferred, and /global-preferred. If we're consistent with that design, we should add /default. 20:44:56 what is a default CA? 20:45:07 how is it different from a preferred CA? 20:45:47 default is a combination of project preferred, global preferred, and earliest created... in that priority order. 20:45:48 dave-mccowan, I think we can use GET /preferred and just make it get the default 20:45:50 * redrobot feels like he doesn't know enough about this api to contribute to this conversation 20:45:58 * redrobot is going to contribute anyway 20:46:23 dave-mccowan seems confusing to me to add a new term to the api 20:46:24 alee the only issue with that is admin vs. non-admin behavior 20:46:27 dave-mccowan, if a project ca is defined, this will be the same in any case 20:47:21 dave-mccowan, we can be more specific in v2 -- if a project ca is defined, this will end up being thee preferred ca 20:47:56 redrobot, so the idea is that a project admin can define some cas to be project cas. 20:48:14 and one of those project cas to be the preferred ca 20:48:44 if he has done so, then if a request comes in without a ca_id, then the preferred ca is selected 20:48:51 preferred for the project, right? and the admin is part of the project, so why does the admin call have to be different? 20:49:19 on the other hand, if the project admin has not defined any project cas .. 20:49:41 then there is no project admin defined default ca 20:49:58 so does a request fail in that case? 20:50:16 then if a request without a ca_id comes in, it will get either a globally defined default ca 20:50:20 or the first configured ca 20:50:37 first configured CA? 20:50:54 yeah - just like we get the first plugin for secret store ... 20:51:11 first ca returned for first ca plugin 20:51:24 so, there will always be an effective preferred, even if none has been set? 20:51:39 right 20:51:44 if there is no project preferred CA defined, but there is a global-preferred ca defined: GET /preferred/ : project admin wants 404, to know he has to define one. user wants to know his default CA, so he can get the cacert. 20:52:03 dave-mccowan I would argue that a 404 is not necessary 20:52:19 dave-mccowan the admin can see the effective peferred, and set another one if that one is not the intended one 20:53:44 i can live with that 20:54:03 solf 20:54:06 sold 20:54:22 with a few minutes left in the meeting even 20:54:34 * dave-mccowan add to-do #10 to etherpad and assigned self 20:54:41 redrobot, just enough time for you to +2/W that CR 20:54:59 alee lol, I'm half way through the review... got interrupted by this meeting :) 20:55:01 So admin will see global preferred as a minimum right? 20:55:20 woodster_ GET /cas/preferred will always return a CA 20:55:21 woodster_, if defined 20:55:29 if not , the first configured 20:55:30 at a minimum, admin will see the first create CA 20:55:42 404 only if there are no CAs at all 20:56:14 hmmm.... can there be a project without access to any CAs, if there are CAs? 20:57:08 dave-mccowan, no - but having access and having cert requests being approved are two different things entirely 20:57:21 redrobot i'll add the agreed change to the next CR 20:57:33 dave-mccowan sounds good 20:58:13 dave-mccowan, but having a project with no cas is an interesting idea 20:58:16 and that's all we have time for this week 20:58:28 alee interesting.... for mitaka! :) 20:58:32 yes 20:58:37 thanks everyone! 20:58:41 #endmeeting