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