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