| *** kgriffs is now known as kgriffs|afk | 00:02 | |
| *** JeffF has quit IRC | 00:06 | |
| *** ryanpetrello has quit IRC | 00:22 | |
| *** kebray has joined #openstack-barbican | 00:28 | |
| *** ryanpetrello has joined #openstack-barbican | 00:31 | |
| openstackgerrit | John Wood proposed openstack/barbican-specs: Add worker retry and future updates support https://review.openstack.org/128113 | 00:34 |
|---|---|---|
| openstackgerrit | Adam Harwell proposed openstack/barbican: Remove py26 from tox.ini https://review.openstack.org/138570 | 00:37 |
| *** dave-mccowan_ has joined #openstack-barbican | 00:46 | |
| *** dave-mccowan has quit IRC | 00:49 | |
| *** dave-mccowan_ is now known as dave-mccowan | 00:49 | |
| *** ryanpetrello has quit IRC | 00:52 | |
| *** jorge_munoz has joined #openstack-barbican | 00:54 | |
| *** zz_dimtruck is now known as dimtruck | 00:56 | |
| *** jorge_munoz has quit IRC | 01:03 | |
| *** jorge_munoz has joined #openstack-barbican | 01:12 | |
| *** jorge_munoz has quit IRC | 01:14 | |
| *** jorge_munoz has joined #openstack-barbican | 01:23 | |
| *** dimtruck is now known as zz_dimtruck | 01:28 | |
| *** ryanpetrello has joined #openstack-barbican | 01:34 | |
| *** ryanpetrello has quit IRC | 01:48 | |
| *** jorge_munoz has quit IRC | 02:01 | |
| *** zz_dimtruck is now known as dimtruck | 02:13 | |
| *** ayoung has joined #openstack-barbican | 02:17 | |
| *** ryanpetrello has joined #openstack-barbican | 02:26 | |
| *** ryanpetrello has quit IRC | 02:31 | |
| *** dimtruck is now known as zz_dimtruck | 02:57 | |
| *** kgriffs|afk is now known as kgriffs | 02:59 | |
| *** ryanpetrello has joined #openstack-barbican | 03:02 | |
| *** kgriffs is now known as kgriffs|afk | 03:09 | |
| *** ryanpetrello has quit IRC | 03:12 | |
| *** ryanpetrello has joined #openstack-barbican | 03:31 | |
| *** zz_dimtruck is now known as dimtruck | 03:32 | |
| *** woodster_ has quit IRC | 03:40 | |
| *** kebray has quit IRC | 03:42 | |
| *** jamielennox is now known as jamielennox|away | 03:44 | |
| *** jamielennox|away is now known as jamielennox | 04:20 | |
| *** dave-mccowan has quit IRC | 04:29 | |
| *** ryanpetrello has quit IRC | 04:47 | |
| *** Nirupama has joined #openstack-barbican | 05:37 | |
| *** woodster_ has joined #openstack-barbican | 06:13 | |
| *** gyee_ has quit IRC | 06:36 | |
| *** alee has quit IRC | 07:13 | |
| *** alee has joined #openstack-barbican | 07:13 | |
| openstackgerrit | Merged openstack/barbican: Container deletion will now clean up Consumers https://review.openstack.org/136866 | 07:30 |
| *** usimha has quit IRC | 07:49 | |
| *** himhiker has joined #openstack-barbican | 07:49 | |
| *** openstackgerrit has quit IRC | 07:50 | |
| *** openstackgerrit has joined #openstack-barbican | 07:50 | |
| *** woodster_ has quit IRC | 08:20 | |
| *** himhiker has quit IRC | 09:42 | |
| *** himhiker has joined #openstack-barbican | 10:11 | |
| *** SheenaG1 has joined #openstack-barbican | 11:37 | |
| *** Nirupama has quit IRC | 12:55 | |
| *** woodster_ has joined #openstack-barbican | 13:00 | |
| *** ryanpetrello has joined #openstack-barbican | 13:07 | |
| *** ryanpetrello has quit IRC | 13:37 | |
| *** ryanpetrello has joined #openstack-barbican | 13:46 | |
| *** ryanpetrello has quit IRC | 13:50 | |
| *** dave-mccowan has joined #openstack-barbican | 13:58 | |
| *** dimtruck is now known as zz_dimtruck | 14:38 | |
| *** rellerreller has joined #openstack-barbican | 14:45 | |
| *** ayoung has quit IRC | 15:00 | |
| *** SheenaG1 has quit IRC | 15:04 | |
| *** woodster_ has quit IRC | 15:10 | |
| *** zz_dimtruck is now known as dimtruck | 15:19 | |
| *** JeffF has joined #openstack-barbican | 15:28 | |
| *** SheenaG1 has joined #openstack-barbican | 15:41 | |
| *** jorge_munoz has joined #openstack-barbican | 15:42 | |
| openstackgerrit | Merged openstack/barbican: Remove py26 from tox.ini https://review.openstack.org/138570 | 15:53 |
| *** kgriffs|afk is now known as kgriffs | 16:01 | |
| *** jorge_munoz has quit IRC | 16:05 | |
| *** kebray has joined #openstack-barbican | 16:05 | |
| *** jorge_munoz has joined #openstack-barbican | 16:08 | |
| *** jorge_munoz has quit IRC | 16:13 | |
| *** kebray has quit IRC | 16:13 | |
| alee | redrobot, ping | 16:18 |
| redrobot | alee pong | 16:18 |
| alee | redrobot, how do I change the topic branch name? | 16:18 |
| alee | ah - I see I can edit it on the review page | 16:19 |
| redrobot | alee you can change it in Gerrit | 16:19 |
| redrobot | alee yep | 16:19 |
| alee | redrobot, does that mean I need to change my branch name too? | 16:19 |
| redrobot | alee it defaults to whatever your git branch was called in your local box... you don't need to change it, but it makes it easier so you don't have to keep updating it in Gerrit. | 16:20 |
| *** jorge_munoz has joined #openstack-barbican | 16:20 | |
| alee | redrobot, ok - so it will overwrite uit again on future commits? | 16:20 |
| redrobot | alee the matching branch names help with sorting patch sets, and automagically linking them and such. | 16:20 |
| redrobot | alee yeah, I think it does change it back if you don't update it locally. | 16:20 |
| alee | ok | 16:21 |
| *** woodster_ has joined #openstack-barbican | 16:22 | |
| woodster_ | alee, I've updated the retry bp to hopefully address your comments: https://review.openstack.org/#/c/128113/ | 16:23 |
| alee | woodster_, ok thanks - I'll take a look later today | 16:24 |
| rm_work | alee: I believe if you update it in gerrit and then do "review -d #" to get the current code, it should keep the tag | 16:25 |
| rm_work | *for the next time you commit | 16:26 |
| alee | rm_work, thanks - no worries - I'll update my branches so I dont have to keep track | 16:26 |
| alee | woodster_, rellerreller -- for https://review.openstack.org/#/c/135490/2/specs/kilo/cert_api.rst,cm, any thoughts on the name for the request-type for option 3? | 16:27 |
| alee | we've gone from "generated" -> "stored_key" -> "generate" ? -> maybe something else | 16:28 |
| alee | woodster_, by the way -- did you have comments on that BP? | 16:29 |
| rellerreller | alee I think auto-generate or generate are good. I think the past tense was what got me, but I'm not too particular about this. | 16:31 |
| alee | rellerreller, the idea here is that we are creating a cert for a private key that is already stored in barbican (whether it has been generated on barbican or not) | 16:32 |
| rellerreller | alee woodster_ reaperhulk rm_work I have been putting a lot of content on the content type etherpad page, https://etherpad.openstack.org/p/barbican-formats-discussion | 16:32 |
| alee | so something with "generate" in it may not make the most sense. | 16:32 |
| alee | which is why I went with "stored_key" | 16:32 |
| rellerreller | alee I liked auto-generate because it means Barbican will auto-generate the certificate request | 16:33 |
| alee | thats true .. | 16:33 |
| rellerreller | I think stored_key is good too. | 16:33 |
| alee | I'll go with stored-key for now - and we can bikeshed it tommorow. | 16:34 |
| rellerreller | Sounds good to me | 16:35 |
| rellerreller | But what is bikeshed it? | 16:35 |
| alee | rellerreller, http://en.wikipedia.org/wiki/Parkinson%27s_law_of_triviality | 16:38 |
| alee | rellerreller, I refers pretty well to discussions for the naming of things - like for example, a new repo. | 16:39 |
| rellerreller | alee Thanks. I have not heard of this before. | 16:40 |
| alee | rellerreller, something I picked up from one of the sessions at the summit | 16:40 |
| rellerreller | alee I love bikeshedding names of new repos. If only yeti was chosen. | 16:40 |
| alee | rellerreller, hey - I was up for wigeon | 16:41 |
| openstackgerrit | Ade Lee proposed openstack/barbican-specs: Add Cert API Spec. https://review.openstack.org/135490 | 16:46 |
| *** ryanpetrello has joined #openstack-barbican | 16:53 | |
| *** paul_glass has joined #openstack-barbican | 16:58 | |
| alee | rellerreller, woodster_ - rellerreller raises an interesting question on the identify_cas BP. | 16:59 |
| alee | up to now, I've considered the PCA table as a listing of the preferred CA for a project in the case that the CA is not defined in a request. | 17:00 |
| rellerreller | I'm glad I did something good. What was my question? | 17:00 |
| alee | so there would be a 1-1 mapping from project_id -> ca_id | 17:00 |
| alee | but having the table list the possible CA's for a project is another interesting use case | 17:01 |
| alee | is so , the logic on a request would look something like this perhaps -- | 17:02 |
| alee | we define a global policy of "allow_all_cas" and default it to true. | 17:03 |
| alee | then when a cert request comes in -- if ca_id is defined , | 17:03 |
| alee | then if any entries for that project_id exist in the PCA table, then we check if the ca_id is one of those entries | 17:04 |
| *** paul_glass1 has joined #openstack-barbican | 17:04 | |
| alee | if so - we allow the request to proceed. if not, we fail with a 400 error. | 17:04 |
| alee | if no entries in the PCA table exist, then : | 17:05 |
| alee | if allow_all_cas = true, we permit the request to continue to the first available ca plugin | 17:05 |
| alee | if not, we fail with a 400 | 17:06 |
| alee | or actually 500 in this case | 17:06 |
| alee | finally we add a field in the PCA table for "preferred" | 17:06 |
| alee | so that if no ca_id is defined, then we select the ca_id specified as preferred .. | 17:07 |
| *** kebray has joined #openstack-barbican | 17:07 | |
| alee | does that sound reasonable? | 17:07 |
| alee | or useful? | 17:08 |
| *** paul_glass has quit IRC | 17:08 | |
| rellerreller | What about preferred column on global CAs? | 17:09 |
| rellerreller | I feel like updating the CAs for a project sounds like a lot of overhead as compared to setup one or two CAs for all projects | 17:10 |
| alee | rellerreller, so then adding a preferred column to the CA table .. | 17:10 |
| alee | which would specify which ca to invoke in case no project specific preferred ca is defined? | 17:11 |
| *** gyee_ has joined #openstack-barbican | 17:12 | |
| alee | rellerreller, that would be better defined that just picking the first one. | 17:12 |
| rellerreller | One thing that sticks out is that if CA ID is provided then must be in preferred CA table and if not then operation is not allowed | 17:12 |
| rellerreller | But then if CA ID is not provided then CA not in preferred list could be used? Unless I misread that part. | 17:13 |
| alee | rellerreller, no -- I think we're thinking about this differently | 17:13 |
| alee | we have two tables proposed right now .. | 17:13 |
| alee | CA table which has ca_id, ca_data | 17:14 |
| alee | PCA (ie. ProjectCA) table which maps projects to ca's | 17:14 |
| rellerreller | I feel like if request comes in with CA ID then check if in CAs table. If not there then unknown. Else proceed with request. Why check if in preferred CA table? | 17:14 |
| alee | the two tables are CA table and ProjectCA table. | 17:15 |
| rellerreller | Then PCA table is only used if no CA ID provided. Check if project has preferred CA, if so use it, else check global CA table and use preferred from there. | 17:15 |
| rellerreller | If no preferred in CAs table then error out because no default has been set. | 17:16 |
| alee | rellerreller, right - that was the original formulation -- where the PCA had a 1-1 mapping of project -> ca | 17:16 |
| alee | rellerreller, what you suggested though (or alluded to) was another interpretation of the PCA table. | 17:16 |
| rellerreller | alee that sounds good to me | 17:16 |
| rellerreller | alee Yes, I was unsure of its purpose | 17:17 |
| alee | rellerreller, so instead of saying "the PCA table is a table that consists of the preferred CA for each project , and therefor has a 1-1 mapping from project to CA" | 17:18 |
| alee | you could say this .. | 17:18 |
| alee | the PCA table consists of the set of CA's that are available to a project, with one of them being designated as the preferred one in case no ca_id is provided" | 17:19 |
| alee | then there could be many ca entries in the PCA table per project_id | 17:19 |
| alee | rellerreller, we can work out the logic -- the main question is to decide the semantics of the table | 17:20 |
| rellerreller | So would the PCA table then contain the only allowable set of CAs? | 17:20 |
| alee | (for a project) | 17:21 |
| rellerreller | Yes | 17:21 |
| alee | if a project chooses to define them | 17:21 |
| rellerreller | So if a project defines the ProjectCAs then I must use a CA in that set or else an error is returned? | 17:21 |
| alee | yup | 17:21 |
| rellerreller | And if a CA ID is not provided, and I'm in a project that uses a ProjectCA set then default is chosen from there and if not defined then error? | 17:22 |
| alee | or it can pick one from the set of project cas | 17:22 |
| alee | I'm ok with error or just pick one. | 17:23 |
| rellerreller | I think picking from global CAs is the confusing part. On one hand you restrict which CAs I can use based on the ProjectCA table and then on the other you are using a CA not in that set. | 17:24 |
| alee | rellerreller, no let me rephrase -- | 17:24 |
| alee | if a project has gone to the trouble to define project ca's, then you must select one from that set | 17:25 |
| rellerreller | I think it would be weird for a user to generate a cert not defining an ID. Then want to generate another cert with the same CA, so it specifies the CA ID of the first one. In that case it will generate an error saying cannot create cert on that CA. | 17:25 |
| alee | if no ca_id comes in, then we select from the "preferred" ca amongst the prioject cas if one is defined (and it should be) | 17:26 |
| alee | if not -- then we either error out -- or we just pick from the project ca's | 17:26 |
| alee | not picking from global ca's | 17:27 |
| rellerreller | So if ProjectCA set is defined then we guarantee that at least one is the preferred. If that is the case then that makes sense. | 17:27 |
| alee | rellerreller, whatdo you mean by "guarantee"? | 17:28 |
| rellerreller | If you have > 0 entries in ProjectCA for a project then at least one must be designated as preferred. | 17:29 |
| rellerreller | If that is not true then if CA ID is not provided and ProjectCA has >0 entries for the project then should error out if one is not designated as preferred. | 17:30 |
| alee | ok - we can do that | 17:30 |
| rellerreller | alee cool | 17:30 |
| rellerreller | alee Does that mean I can eat lunch now? | 17:31 |
| alee | rellerreller, :) absolutely | 17:31 |
| rellerreller | alee Thank you :) | 17:31 |
| alee | I should proabbly do that too .. | 17:31 |
| rellerreller | Enjoy | 17:31 |
| alee | thank you :) | 17:31 |
| alee | you too | 17:31 |
| *** ryanpetrello has quit IRC | 17:32 | |
| *** bubbva has quit IRC | 17:36 | |
| *** bubbva has joined #openstack-barbican | 17:36 | |
| *** ayoung has joined #openstack-barbican | 17:46 | |
| rm_work | rellerreller: sorry, looking at that etherpad -- not ignoring you, just busy :P | 17:48 |
| *** tiger_toes has quit IRC | 17:49 | |
| woodster_ | alee, rellerreller, I'm curious if there are use cases that would use this project-restricted CA feature right away? Or do we think this will eventually be useful for deployments? | 17:50 |
| alee | woodster_, I could imagine it being useful. Imagine if you're a reseller and your tenant wants to use his own internal ca? | 17:58 |
| kgriffs | (that 0.2 makes possible) | 18:00 |
| kgriffs | sorry, wrong window | 18:01 |
| *** bdpayne has joined #openstack-barbican | 18:05 | |
| *** paul_glass1 has quit IRC | 18:12 | |
| *** dimtruck is now known as zz_dimtruck | 18:12 | |
| openstackgerrit | Jeff Fischer proposed openstack/barbican: initial commit for DigiCert Barbican plugin. https://review.openstack.org/138812 | 18:15 |
| *** zz_dimtruck is now known as dimtruck | 18:48 | |
| *** paul_glass has joined #openstack-barbican | 19:04 | |
| rm_work | woodster_ / alee: LBaaS needs our own private CA, for example :) | 19:25 |
| *** SheenaG11 has joined #openstack-barbican | 19:32 | |
| *** SheenaG1 has quit IRC | 19:34 | |
| *** chellygelly has joined #openstack-barbican | 19:45 | |
| *** chellygelly has quit IRC | 19:49 | |
| *** paul_glass has quit IRC | 19:50 | |
| openstackgerrit | Ade Lee proposed openstack/barbican-specs: Spec for identifying CAs https://review.openstack.org/129048 | 19:57 |
| alee | rm_work, perfect :) | 19:59 |
| alee | woodster_, rellerreller, rm_work - new version of the identifying cas bp posted | 19:59 |
| rm_work | reading it now | 19:59 |
| rm_work | though I have a meeting in 45 seconds | 19:59 |
| alee | ready set go .. | 20:00 |
| rellerreller | alee thanks, off to meeting now but will take a look later | 20:00 |
| alee | thanks | 20:01 |
| *** darrenmoffat has quit IRC | 20:11 | |
| *** darrenmoffat has joined #openstack-barbican | 20:12 | |
| *** kgriffs is now known as kgriffs|afk | 20:14 | |
| *** kebray has quit IRC | 20:14 | |
| *** kebray has joined #openstack-barbican | 20:17 | |
| *** crc32 has joined #openstack-barbican | 20:20 | |
| redrobot | alee finally got through cleaning up the blueprints in Launchpad. Everything should be up to date with what's being reviewed in Gerrit. | 20:22 |
| redrobot | alee when you get some time would you mind reviewing the priority we set on all the BPs? https://blueprints.launchpad.net/barbican | 20:22 |
| alee | redrobot, looking -- was there ever anything that came from the intel folks about tpm? | 20:33 |
| redrobot | alee haven't heard anything... I can try poking Malini again | 20:33 |
| alee | redrobot, yeah -- seems like a nice-to-have | 20:34 |
| alee | redrobot, is https://blueprints.launchpad.net/barbican/+spec/add-ssl-ca-support just the old blueprint? | 20:35 |
| alee | redrobot, seems like it should be high/essential | 20:35 |
| redrobot | alee yep, it's the epic BP carried over from Juno | 20:36 |
| redrobot | alee good point... I can bump that up to essential | 20:36 |
| alee | redrobot, other than that - triage looks ok to me | 20:36 |
| redrobot | alee awesome... I figure we can start with the Essential BPs tomorrow. | 20:37 |
| *** himhiker has quit IRC | 20:37 | |
| alee | yup - I need to dust off the per-secret-policy one .. | 20:38 |
| alee | that one may or may not be ready for tommorow | 20:38 |
| *** himhiker has joined #openstack-barbican | 20:40 | |
| *** jorge_munoz has quit IRC | 20:45 | |
| *** jorge_munoz has joined #openstack-barbican | 20:47 | |
| *** himhiker has quit IRC | 20:50 | |
| *** kgriffs|afk is now known as kgriffs | 20:54 | |
| *** rellerreller has quit IRC | 21:11 | |
| *** crc32 has quit IRC | 21:15 | |
| *** ryanpetrello has joined #openstack-barbican | 21:18 | |
| woodster_ | alee, in the identify-cas bp, were you intending for the project/ca REST calls to allow a user with the admin role to change project settings for their own project, or for that user to be able to set project/ca assocs for other projects as well? | 21:20 |
| alee | woodster_, I was thinking an admin would be able to change for all projects -- and a project admin just for their own project | 21:23 |
| *** dave-mccowan has quit IRC | 21:24 | |
| alee | woodster_, not sure if the two separate roles actually exist | 21:24 |
| *** jorge_munoz has quit IRC | 21:24 | |
| woodster_ | alee, I think the calls would be different for those two users...the former requiring the admin API with calls that end with the project-id as per your original bp version, the latter as you specify in the current version. Setting the preferred ca info on the CA table would probably need to be an admin API feature. | 21:27 |
| alee | woodster_, ok that makes sense. is the admin api specified by a different url? | 21:29 |
| alee | or different port? | 21:29 |
| woodster_ | alee, yeah it'd be either one. It is a separate service for sure. We haven't crossed that bridge yet, but I'm recalling that projects were moving away from admin endpoints...not sure if that's the case really or not though. | 21:31 |
| woodster_ | redrobot, have you heard anything about project's moving away from admin API services? | 21:32 |
| *** jorge_munoz has joined #openstack-barbican | 21:33 | |
| redrobot | woodster_ alee The only project with admin endpoints that I'm familiar with is Keystone. In Keystone v2.0 there was two different endpoints (different ports) for the user api vs the admin api | 21:34 |
| redrobot | woodster_ alee In Keystone 3.0 the admin api is on the same endpoint as the user api | 21:34 |
| redrobot | I still don't know WHY they consolidated the two | 21:34 |
| woodster_ | redrobot, alee so cross-project REST calls are probably handled with a separate/special role then. It would certainly be less hassle to not have to spin up another endpoint | 21:35 |
| alee | redrobot, woodster_ right - which is what I was thinking in this case | 21:37 |
| woodster_ | two endpoints = twice the deployment headaches :) That said, it would be more secure to have a non-public admin endpoint | 21:37 |
| alee | woodster_, so -- the rule for the operation would be token scoped to project and admin role in project or global admin role | 21:38 |
| alee | woodster_, only one endpoint needed -- and this is a policy thing .. | 21:38 |
| woodster_ | alee, but that also means that a global admin user wishing to modify project/ca assocs for any project would need the REST calls that end with the {project-id} | 21:40 |
| *** dave-mccowan has joined #openstack-barbican | 21:40 | |
| woodster_ | alee, do you think there is a need for that feature though? Or would an admin for the project most likely be setting up those assocs for their own project? I think the latter, but just curious | 21:41 |
| alee | woodster_, I think most likely the admin would be setting up for their own project | 21:41 |
| openstackgerrit | John Wood proposed openstack/barbican: Update log messages to oslo.i18n https://review.openstack.org/138247 | 21:41 |
| alee | woodster_, but sometimes they need tech support :) | 21:42 |
| alee | woodster_, I'm ok with just limiting those to project admin for now | 21:42 |
| alee | (except for the global one of course) | 21:42 |
| *** jamielennox is now known as jamielennox|away | 21:42 | |
| *** dave-mccowan_ has joined #openstack-barbican | 21:42 | |
| woodster_ | alee, that could apply to all REST actions though? | 21:43 |
| *** dave-mccowan has quit IRC | 21:45 | |
| *** dave-mccowan_ is now known as dave-mccowan | 21:46 | |
| alee | woodster_, it will apply to the ones where I say "limited to project admin or admin" | 21:46 |
| woodster_ | alee, ok then the calls in the bp are good then (with minor nits I'll note shortly :) | 21:46 |
| alee | woodster_, cool - yup | 21:47 |
| alee | set-global-preferred must be admin | 21:47 |
| woodster_ | alee, admin > project-admin correct? | 21:56 |
| alee | project-admin and admin -> project-admin | 22:06 |
| alee | sorry -- yes :) | 22:06 |
| alee | woodster_, ? | 22:17 |
| woodster_ | alee, hello | 22:18 |
| alee | woodster_, I have a question about your comment in https://review.openstack.org/#/c/129377/1/specs/kilo/expose_ca_templates.rst,cm | 22:18 |
| alee | specifically about the flavor concept .. | 22:19 |
| alee | woodster_, I'm trying to understand how to apply that here .. | 22:20 |
| woodster_ | alee, oh got it. I think I just confused the template with the ca-id...you are already providing the URI to that in the order request, not a reference to the template. I'll add a note about ignoring this, sorry | 22:22 |
| alee | woodster_, ok np -- justwanted to make sure I wasn't missing something | 22:24 |
| openstackgerrit | John Wood proposed openstack/barbican: Update log messages to oslo.i18n https://review.openstack.org/138247 | 22:36 |
| *** jorge_munoz has quit IRC | 22:37 | |
| *** kebray has quit IRC | 22:52 | |
| *** kebray has joined #openstack-barbican | 22:53 | |
| *** SheenaG11 has quit IRC | 23:03 | |
| *** jamielennox|away is now known as jamielennox | 23:09 | |
| *** dimtruck is now known as zz_dimtruck | 23:17 | |
| *** ryanpetrello has quit IRC | 23:24 | |
| openstackgerrit | Jeff Fischer proposed openstack/barbican: initial commit for DigiCert Barbican plugin https://review.openstack.org/138199 | 23:35 |
| *** SheenaG1 has joined #openstack-barbican | 23:36 | |
| *** ryanpetrello has joined #openstack-barbican | 23:51 | |
| *** SheenaG1 has quit IRC | 23:55 | |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!