| *** dimtruck is now known as zz_dimtruck | 00:04 | |
| *** stanzi has joined #openstack-barbican | 00:07 | |
| *** stanzi has quit IRC | 00:11 | |
| *** mixos has joined #openstack-barbican | 00:12 | |
| *** stanzi has joined #openstack-barbican | 00:21 | |
| *** openstackgerrit has quit IRC | 00:32 | |
| *** openstackgerrit has joined #openstack-barbican | 00:33 | |
| *** stanzi has quit IRC | 00:42 | |
| *** zz_dimtruck is now known as dimtruck | 00:49 | |
| *** stanzi has joined #openstack-barbican | 00:54 | |
| *** woodster_ has quit IRC | 00:56 | |
| *** cheneydc has joined #openstack-barbican | 01:02 | |
| *** stanzi has quit IRC | 01:03 | |
| *** stanzi has joined #openstack-barbican | 01:03 | |
| *** mixos has quit IRC | 01:06 | |
| *** mixos has joined #openstack-barbican | 01:07 | |
| *** stanzi_ has joined #openstack-barbican | 01:11 | |
| *** stanzi has quit IRC | 01:11 | |
| *** stanzi_ has quit IRC | 01:14 | |
| *** stanzi has joined #openstack-barbican | 01:14 | |
| *** mixos has quit IRC | 01:16 | |
| *** ccneill has quit IRC | 01:22 | |
| *** NazcaLines has quit IRC | 01:28 | |
| *** mixos has joined #openstack-barbican | 01:49 | |
| *** jaosorior has quit IRC | 02:35 | |
| *** jaosorior has joined #openstack-barbican | 02:35 | |
| *** fredyx10 has joined #openstack-barbican | 02:56 | |
| *** gyee has quit IRC | 03:04 | |
| *** stanzi has quit IRC | 03:12 | |
| *** stanzi has joined #openstack-barbican | 03:15 | |
| *** yuanying has quit IRC | 03:26 | |
| *** yuanying has joined #openstack-barbican | 03:37 | |
| *** yuanying has quit IRC | 04:05 | |
| *** yuanying has joined #openstack-barbican | 04:07 | |
| *** stanzi has quit IRC | 04:24 | |
| *** fredyx10 has quit IRC | 05:09 | |
| *** mixos has quit IRC | 05:20 | |
| *** jamielennox is now known as jamielennox|away | 05:27 | |
| *** yfujioka has joined #openstack-barbican | 05:35 | |
| *** mragupat has joined #openstack-barbican | 05:40 | |
| *** mragupat has quit IRC | 05:42 | |
| *** mragupat has joined #openstack-barbican | 05:42 | |
| *** jaosorior has quit IRC | 05:47 | |
| *** dave-mccowan has quit IRC | 05:49 | |
| *** yuanying_ has joined #openstack-barbican | 06:00 | |
| *** yuanying has quit IRC | 06:01 | |
| *** yuanying_ has quit IRC | 06:01 | |
| *** yuanying has joined #openstack-barbican | 06:01 | |
| *** jorgem has quit IRC | 06:08 | |
| *** jillysciarilly has quit IRC | 06:08 | |
| *** notmyname has quit IRC | 06:09 | |
| *** notmyname has joined #openstack-barbican | 06:10 | |
| *** jorgem has joined #openstack-barbican | 06:10 | |
| *** jillysciarilly has joined #openstack-barbican | 06:17 | |
| openstackgerrit | Vishal kumar mahajan proposed openstack/kite: Fix the parameter order of assertEqual in api test. https://review.openstack.org/265097 | 06:19 |
|---|---|---|
| *** jaosorior has joined #openstack-barbican | 06:21 | |
| openstackgerrit | Merged openstack/barbican: Use assertTrue/False instead of assertEqual(T/F) https://review.openstack.org/264215 | 06:27 |
| *** dimtruck is now known as zz_dimtruck | 06:28 | |
| *** mragupat has quit IRC | 06:45 | |
| openstackgerrit | OpenStack Proposal Bot proposed openstack/barbican: Updated from global requirements https://review.openstack.org/264411 | 06:49 |
| *** jaosorior has quit IRC | 08:16 | |
| *** jaosorior has joined #openstack-barbican | 08:16 | |
| *** f13o has joined #openstack-barbican | 08:30 | |
| *** cheneydc has quit IRC | 10:02 | |
| *** jaosorior has quit IRC | 10:37 | |
| *** jaosorior has joined #openstack-barbican | 10:38 | |
| *** mixos has joined #openstack-barbican | 12:37 | |
| *** mixos has quit IRC | 12:43 | |
| *** stanzi has joined #openstack-barbican | 13:12 | |
| *** stanzi has quit IRC | 13:37 | |
| *** cheneydc has joined #openstack-barbican | 13:47 | |
| *** fredyx10 has joined #openstack-barbican | 13:53 | |
| *** stanzi has joined #openstack-barbican | 13:57 | |
| *** fredyx10 has quit IRC | 13:58 | |
| *** jaosorior has quit IRC | 14:02 | |
| *** stanzi has quit IRC | 14:02 | |
| *** cheneydc has quit IRC | 14:09 | |
| *** dave-mccowan has joined #openstack-barbican | 14:13 | |
| *** rellerreller has joined #openstack-barbican | 14:26 | |
| *** lisaclark has joined #openstack-barbican | 14:26 | |
| *** fredyx10 has joined #openstack-barbican | 14:35 | |
| *** ajc_ has joined #openstack-barbican | 14:38 | |
| *** ajc_ has quit IRC | 14:38 | |
| *** stanzi has joined #openstack-barbican | 14:39 | |
| *** mixos has joined #openstack-barbican | 14:42 | |
| *** stanzi has quit IRC | 14:43 | |
| *** fredyx10 has quit IRC | 14:44 | |
| *** fredyx10 has joined #openstack-barbican | 14:44 | |
| *** nelsnelson has quit IRC | 14:47 | |
| *** jmckind has joined #openstack-barbican | 15:00 | |
| *** spotz_zzz is now known as spotz | 15:03 | |
| *** stanzi has joined #openstack-barbican | 15:04 | |
| *** rellerreller has quit IRC | 15:08 | |
| *** stanzi has quit IRC | 15:08 | |
| *** stanzi has joined #openstack-barbican | 15:09 | |
| *** zz_dimtruck is now known as dimtruck | 15:09 | |
| *** stanzi has quit IRC | 15:12 | |
| *** stanzi has joined #openstack-barbican | 15:12 | |
| *** peter-hamilton has joined #openstack-barbican | 15:14 | |
| *** mp1 has joined #openstack-barbican | 15:17 | |
| *** peter-hamilton has quit IRC | 15:18 | |
| *** rellerreller has joined #openstack-barbican | 15:21 | |
| *** lisaclark has quit IRC | 15:22 | |
| *** lisaclark has joined #openstack-barbican | 15:25 | |
| *** stanzi has quit IRC | 15:30 | |
| *** fredyx10 has quit IRC | 15:35 | |
| *** silos has joined #openstack-barbican | 15:36 | |
| *** fredyx10 has joined #openstack-barbican | 15:37 | |
| *** mragupat has joined #openstack-barbican | 15:38 | |
| *** stanzi has joined #openstack-barbican | 15:41 | |
| *** jmckind_ has joined #openstack-barbican | 15:41 | |
| *** fredyx10 has quit IRC | 15:41 | |
| *** fredyx10 has joined #openstack-barbican | 15:41 | |
| *** jmckind has quit IRC | 15:44 | |
| openstackgerrit | Christopher Solis proposed openstack/barbican: Create Orders Documentation https://review.openstack.org/236123 | 15:47 |
| *** kebray has joined #openstack-barbican | 15:49 | |
| *** lisaclark has quit IRC | 15:58 | |
| *** stanzi has quit IRC | 15:59 | |
| *** lisaclark has joined #openstack-barbican | 16:09 | |
| *** zigo has quit IRC | 16:09 | |
| *** zigo has joined #openstack-barbican | 16:10 | |
| *** kfarr has joined #openstack-barbican | 16:11 | |
| arunkant | rellerreller: ping | 16:25 |
| *** mp1 has quit IRC | 16:31 | |
| *** mixos has quit IRC | 16:31 | |
| *** ccneill has joined #openstack-barbican | 16:33 | |
| *** nelsnelson has joined #openstack-barbican | 16:38 | |
| rellerreller | arunkant pong | 16:39 |
| arunkant | rellerreller: I have question on the concern you mentioned in https://review.openstack.org/#/c/263972/ | 16:39 |
| rellerreller | arunkant sure | 16:39 |
| rellerreller | arunkant I don't want my review to think it is impossible or bad idea, but there are lots of details to work through. | 16:40 |
| *** gyee has joined #openstack-barbican | 16:40 | |
| arunkant | I have yet to go through trasnport key logic in detail..but looks like the concern you have to know which backend transport key is stored in ? | 16:40 |
| rellerreller | arunkant we will need definitely need to address some of the issues you mentioned. | 16:41 |
| rellerreller | arunkant correct | 16:41 |
| rellerreller | arunkant when the keys depend upon each other then you will likely need to know where it is stored. | 16:42 |
| arunkant | rellerreller: In the spec, I have added something global preferred secret store backend..this is the backend which is used when project level backend is not specified/used | 16:42 |
| rellerreller | Otherwise you could have an unencrypted key in Barbican when the user's policy does not allow that. | 16:42 |
| arunkant | rellerreller: We can always store transport key in that backend. Will that work ? | 16:43 |
| rellerreller | arunkant I don't think so. The transport keys are provided by a key management device. | 16:44 |
| rellerreller | arunkant they provide a path for the secret to be encrypted from the user all the way to the device. | 16:44 |
| rellerreller | arunkant the goal is to not let Barbican read the secret. | 16:45 |
| rellerreller | arunkant I have been thinking about the restriction that a project must have one and only one secret store. | 16:46 |
| *** f13o has quit IRC | 16:46 | |
| *** mp1 has joined #openstack-barbican | 16:46 | |
| arunkant | Okay..understood..so if we know its going to be always stored in HSM device..then use that backend...we can ask customer or deployment to have a preferred backend for transport key | 16:46 |
| rellerreller | arunkant that may provide enough of a restriction to eliminate most if not all of my concerns. I'm still trying to work through it. | 16:47 |
| *** kebray has quit IRC | 16:47 | |
| *** edtubill has joined #openstack-barbican | 16:48 | |
| arunkant | rellereller: Storing transort key in customer specified backend (in case multiple secret store is enabled)..will that work? | 16:49 |
| rellerreller | arunkant my last comment was with regards to the restriction that a project must have secret store. | 16:49 |
| rellerreller | arunkant the transport keys are provided by the backend and do not leave the backend, at least the private part of it. | 16:50 |
| arunkant | rellerreller: Ideally, we don't need to have that (as each secret has metadata about backend)..but that's just to limit the amount of work to be done in first iteration of this feature | 16:51 |
| *** lisaclark has quit IRC | 16:51 | |
| rellerreller | arunkant there is the problem about policy dictating that certain keys should not leave a backend device unencrypted. | 16:52 |
| rellerreller | If I have a symmetric that meets this requirement and I want to send it back to a user wrapped with their public key then how do we guarantee that the key does not enter Barbican unencrypted. | 16:53 |
| rellerreller | If the public key is stored in a different backend. | 16:53 |
| *** stanzi has joined #openstack-barbican | 16:55 | |
| arunkant | rellerreller: containers or groups of secrets/keys are generally tied to same project..so indirectly which means they will be stored in same backend. Will there be situation for above case | 16:55 |
| *** f13o has joined #openstack-barbican | 16:56 | |
| *** jmckind has joined #openstack-barbican | 16:56 | |
| rellerreller | arunkant it depends upon the restriction of how many secret stores can be created and what is their mapping to projects and users. I'm not sure yet. | 16:56 |
| rellerreller | arunkant I'm still not convinced that >1 secret store will be possible without exposing keystore backend storage location to user. | 16:57 |
| arunkant | rellereller: I don't forsee there are going to be many backends..as barbican has only 2-3 secret store options .. | 16:58 |
| rellerreller | arunkant even if restricted 1:1 project:secret_store then what if I want to send a symmetric key from one project to a user in another project? We would have to work through that. | 16:58 |
| *** stanzi has quit IRC | 16:58 | |
| *** stanzi has joined #openstack-barbican | 16:59 | |
| *** lisaclark has joined #openstack-barbican | 16:59 | |
| *** mragupat has quit IRC | 16:59 | |
| rellerreller | arunkant there could be lots of backend instances. Consider a public cloud with lots of customers bringing their own KMIP devices. We will have to keep track of where each instance resides and how to contact it. | 17:00 |
| *** jmckind_ has quit IRC | 17:00 | |
| arunkant | rellerreller: Yes..I am sure there are certain aspects of this needs to be ironed out . | 17:00 |
| *** mragupat has joined #openstack-barbican | 17:00 | |
| *** lisaclark has quit IRC | 17:02 | |
| arunkant | rellerreller: I am not sure Barbican has that kind of support but even if it does in future, there should not issue with having multiple secret_store and project mapping. Actually in those secnraios, we want to have support for multiple backends on project level. | 17:03 |
| *** lisaclark has joined #openstack-barbican | 17:04 | |
| *** lisaclark has quit IRC | 17:06 | |
| arunkant | rellerreller: Having global preferred transport key backend should address the concern you mentioned in review..what do you think ? | 17:07 |
| *** f13o has quit IRC | 17:08 | |
| rellerreller | arunkant that would not work. The idea is to have the private transport key generated on the backend device and never leave it. How do you envision the global transport key working? | 17:08 |
| *** silos has quit IRC | 17:09 | |
| rellerreller | arunkant let's consider the case of two backends for a project. The backends are A and B. The user wants to retrieve symmetric key foo, which is stored in B. How would that work without exposing the storage backend to the user? | 17:09 |
| *** stanzi has quit IRC | 17:10 | |
| arunkant | rellerreller: As you mentioned, a deployment will want to store transport key in a device..so barbican configuration will define what backend to use for transport key..it can be HSM backend (where it does not leave device) | 17:10 |
| *** stanzi has joined #openstack-barbican | 17:11 | |
| arunkant | rellerreller: So as part of barbican configuration, deployer will specify that, let's say, B is global preferred backend for secret store. And now lets say secret (symmetric key) is stored under project p1. | 17:12 |
| rellerreller | actually for retrieval case it would not be wrapped with transport key | 17:12 |
| arunkant | If project specific backend is not specified, then barbican will look for secret data in backend B as that's the global preferred backend . | 17:13 |
| rellerreller | arunkant but what if A is preferred backend? | 17:14 |
| arunkant | if for project p1, backend A is specified as preferred project level backend..then secret will be looked into backend A first | 17:14 |
| rellerreller | arunkant the user first make a call to Barbican to get transport key | 17:15 |
| rellerreller | then the user uses the transport key to encrypt a wrapping key that the backend device will use to encrypt the symmetric for the user. | 17:15 |
| arunkant | Okay..for transport key..we can specify a global preferred transport key store backend..which can be B (if it happens to map to HSM device)..and use that to retrieve transport key. | 17:16 |
| rellerreller | The user then makes a call to Barbican to retrieve the symmetric key and passes it the transport wrapped session key (twsk). | 17:16 |
| rellerreller | The backend then receives the twsk, decrypts it, wraps the symmetric key, and returns the key back to barbican and then the user. | 17:17 |
| rellerreller | arunkant how does Barbican know which transport key to return to the user when it makes a request to get it? | 17:17 |
| *** f13o has joined #openstack-barbican | 17:18 | |
| rellerreller | No matter which one you choose I can always say the desired key is in the other backend. | 17:18 |
| arunkant | rellerreller: Based on global preferred backend for transport key..it will look for project related transport key.. | 17:18 |
| rellerreller | arunkant there is no project related transport key. The transport key is per backend instance. | 17:19 |
| *** fredyx10 has quit IRC | 17:20 | |
| arunkant | Okay...in that case..can we transport key maintain per backend..so based on the backend where we are goin to store the secret, we use that transport key. | 17:21 |
| arunkant | I meant...can we maintain transport key per backend | 17:22 |
| rellerreller | arunkant yes, there can be a transport key per backend, but how does a user know which backend for key retrieval? The first step in returning a wrapped key is to retrieve the transport key. | 17:23 |
| *** nelsnels_ has joined #openstack-barbican | 17:24 | |
| rellerreller | arunkant the current API always returns the same transport key because their can only be one. | 17:24 |
| rellerreller | arunkant so now you must change this api to allow the user to specify a specific transport key, say for backend A or B. | 17:25 |
| arunkant | rellereller: The user will know which backend they want to use for secret storage..is not it ? ..We can always derive project specific backend information from keystone token.. | 17:25 |
| rellerreller | arunkant but then the user must somehow know where their key is stored, in A or B, so they know which transport key to request. That would be another API change to allow the user to query that information. | 17:25 |
| rellerreller | arunkant the user does not know which backend is being used. They only know which Barbican instance to call. | 17:26 |
| arunkant | So based on keystone token..if project does not have project level backend specified, then we can use trannsport key which is for global preferred backend (backend B from above example) | 17:26 |
| *** silos has joined #openstack-barbican | 17:26 | |
| rellerreller | arunkant there is nothing in the API to say store this key in this backend. | 17:26 |
| *** nelsnelson has quit IRC | 17:27 | |
| rellerreller | arunkant forget about global preferred backend. You said earlier that you wanted >1 backends per project. | 17:27 |
| arunkant | rellerreller: No...I don't want more than one backend per project..we want to have option of specifiying preferred backend for a project | 17:28 |
| arunkant | rellereller: Actually..that's something I have mentioned in spec as out-of-scope topic for this spec | 17:29 |
| rellerreller | arunkant at 12:03 you said, "we want to have support for multiple backends on project level." I took that to mean >1 backend per project. So that is not what you are saying? | 17:30 |
| arunkant | rellerreller: I meant..having support for multiple backends..where backend is specified at project level. So yes, currently we don't want to have multiple backend specified within a project. | 17:32 |
| rellerreller | arunkant so that will certainly help, and as I said before it might work. I'm just not sure yet. | 17:33 |
| rellerreller | arunkant I'm trying to think about retrieving a secret from a different project and using transport key. I think that still has issues. | 17:34 |
| *** kebray has joined #openstack-barbican | 17:34 | |
| arunkant | rellereller: As you correctly identifiied.. I can clearly see there are certain aspects where details need to be sorted out. | 17:34 |
| rellerreller | Basically the same ones that I outlined above. | 17:34 |
| rellerreller | We spent a lot of hours debating this at one of the summits until we finally said, "This is really hard. Let's just support one secret store and have multiple Barbican instances." | 17:35 |
| *** edtubill has quit IRC | 17:35 | |
| *** mp1 has quit IRC | 17:36 | |
| rellerreller | I think it's worthy of a revisit. There are definitely pros and cons to both solutions. I'm not certain which is better. | 17:36 |
| arunkant | rellerreller: As transport keys are backend level..so it should be quite straightforward..if there is project level backend specified, then provide transport key for that backend to user otherwise use from default backend (global preferred one) | 17:36 |
| rellerreller | And we need to solve the problems you outlined sooner rather than later. | 17:36 |
| rellerreller | arunkant but what if the key I want to retrieve is in another project stored in a different backend that has a different transport key? | 17:37 |
| *** diazjf has joined #openstack-barbican | 17:37 | |
| arunkant | rellereller: Yes..we certainly need to have discussion on this.. Will it be possible for you to remove -2 as that just literally stops the review process..other people in community would not even look into it. | 17:38 |
| arunkant | rellerreller: As you mentioned earlier, transport key and secret store backend has to be same. We will definitely avoid cases to allow that if it can happen..may be allow only for new projects. | 17:41 |
| *** mp1 has joined #openstack-barbican | 17:41 | |
| arunkant | rellerreller: What do you say? | 17:42 |
| rellerreller | arunkant I don't know how that works. I don't want it to accidentally get accepted somehow. See what redrobot says I'll do whatever he says. | 17:43 |
| arunkant | rellerreller: It would not be accepted without discussion. I am not core and have that kind of influence :-) ... But just requesting to have discussion going which will likley not happen with -2. | 17:45 |
| arunkant | rellerreller: Also as this is a new feature..like earlier Barbican guidelines..this will be kept disabled by default and deployment wish to you will have to enable it. | 17:47 |
| rellerreller | arunkant let's see what redrobot says. | 17:48 |
| arunkant | rellerreller: Okay...as per this discussion..looks like there is possible path for transport key wrapping issue. Its just need to be documented (which I will do in next patch). | 17:50 |
| rellerreller | arunkant sounds good. | 17:51 |
| arunkant | rellerreller: thanks for your inputs on this. | 17:51 |
| rellerreller | arunkant np. Sorry if it seems frustrating. | 17:52 |
| rellerreller | This one in particular has a lot of minute details with it. | 17:52 |
| *** ccneill has quit IRC | 17:53 | |
| arunkant | Its alright..totally agree. So I am expecting these kind of finer details to come out of this spec..with community discussion. I have tried to be detailed in spec..but will update once we have some resolution on -2 issue. | 17:54 |
| *** ccneill has joined #openstack-barbican | 17:54 | |
| rellerreller | arunkant so you cannot update spec with a -2 on it? | 17:59 |
| rellerreller | arunkant I thought -2 would just carryover to next revision. | 17:59 |
| *** jmckind has quit IRC | 17:59 | |
| *** mragupat_ has joined #openstack-barbican | 18:02 | |
| *** mp1 has quit IRC | 18:04 | |
| *** kfarr has quit IRC | 18:04 | |
| *** mragupat has quit IRC | 18:06 | |
| *** jmckind has joined #openstack-barbican | 18:07 | |
| *** silos has quit IRC | 18:08 | |
| *** stanzi has quit IRC | 18:16 | |
| *** dimtruck is now known as zz_dimtruck | 18:18 | |
| *** zz_dimtruck is now known as dimtruck | 18:42 | |
| *** ccneill has quit IRC | 18:45 | |
| *** ccneill has joined #openstack-barbican | 18:49 | |
| arunkant | rellerreller: Are you coming for mid-cycle ? | 18:52 |
| rellerreller | arunkant I will not be there, but kfarr will be. | 18:52 |
| *** stanzi has joined #openstack-barbican | 18:54 | |
| arunkant | rellerreller: Okay..I was hoping to discuss this in mid-cycle. Hopefully it can still be discussed with -2 on it. | 18:54 |
| rellerreller | arunkant there is no reason it cannot be discussed. It should be discussed. | 18:56 |
| arunkant | Hopefully yes..it should not be the case that as it has -2 from you so it needs to be cleared from you first. | 18:58 |
| openstackgerrit | Fernando Diaz proposed openstack/barbican: Warning about tox not working in Vagrant setup https://review.openstack.org/264325 | 19:17 |
| *** mp1 has joined #openstack-barbican | 19:20 | |
| *** jmckind_ has joined #openstack-barbican | 19:23 | |
| *** lisaclark has joined #openstack-barbican | 19:25 | |
| *** silos has joined #openstack-barbican | 19:25 | |
| *** jmckind has quit IRC | 19:26 | |
| *** mp1 has quit IRC | 19:30 | |
| *** mp1 has joined #openstack-barbican | 19:32 | |
| *** lisaclark has quit IRC | 19:36 | |
| *** darrenmoffat has quit IRC | 19:42 | |
| *** darrenmoffat has joined #openstack-barbican | 19:43 | |
| *** lisaclark has joined #openstack-barbican | 19:46 | |
| *** kebray has quit IRC | 19:46 | |
| *** diazjf has quit IRC | 19:51 | |
| *** kebray has joined #openstack-barbican | 20:06 | |
| *** silos has quit IRC | 20:08 | |
| *** mp1 has quit IRC | 20:10 | |
| *** mp1 has joined #openstack-barbican | 20:11 | |
| *** lisaclark1 has joined #openstack-barbican | 20:15 | |
| *** lisaclark has quit IRC | 20:16 | |
| *** nelsnels_ has quit IRC | 20:25 | |
| *** phschwartz has joined #openstack-barbican | 20:35 | |
| *** diazjf has joined #openstack-barbican | 20:36 | |
| phschwartz | When creating a client object what sets the endpoint? I am using os-client-config to load a cloud.yaml and the url for barbican is a valid https url in the service catalog, but when I print out client.secret._api.get_endpoint() it returns an http url | 20:36 |
| *** Daviey has joined #openstack-barbican | 20:38 | |
| *** nelsnelson has joined #openstack-barbican | 20:42 | |
| arunkant | rellerreller: I have tried to capture the main aspect of our todays discussion..can you please comment to see if my understanding is correct and then I can address them in next patch. ..https://review.openstack.org/#/c/263972 | 20:43 |
| *** stanzi has quit IRC | 20:46 | |
| *** silos has joined #openstack-barbican | 20:50 | |
| *** fredyx10 has joined #openstack-barbican | 21:09 | |
| *** jmckind_ has quit IRC | 21:16 | |
| *** jmckind has joined #openstack-barbican | 21:17 | |
| *** lisaclark1 has quit IRC | 21:19 | |
| arunkant | redrobot: ping | 21:26 |
| *** rhagarty has joined #openstack-barbican | 21:29 | |
| *** rellerreller has quit IRC | 21:30 | |
| *** rhagarty_ has quit IRC | 21:31 | |
| *** lisaclark has joined #openstack-barbican | 21:35 | |
| *** rhagarty_ has joined #openstack-barbican | 21:37 | |
| openstackgerrit | Jason Fritcher proposed openstack/barbican: Reimplement p11_crypto and pkcs11 modules https://review.openstack.org/243291 | 21:38 |
| *** jmckind_ has joined #openstack-barbican | 21:38 | |
| *** fredyx10 has quit IRC | 21:38 | |
| *** fredyx10 has joined #openstack-barbican | 21:38 | |
| *** rhagarty has quit IRC | 21:39 | |
| *** diazjf has quit IRC | 21:39 | |
| *** lisaclark has quit IRC | 21:40 | |
| *** jmckind has quit IRC | 21:41 | |
| *** fredyx10 has quit IRC | 21:43 | |
| *** fredyx10 has joined #openstack-barbican | 21:44 | |
| *** jmckind has joined #openstack-barbican | 22:09 | |
| *** jmckind_ has quit IRC | 22:12 | |
| *** silos has left #openstack-barbican | 22:12 | |
| *** nelsnelson has quit IRC | 22:16 | |
| *** rhagarty has joined #openstack-barbican | 22:18 | |
| *** rhagarty_ has quit IRC | 22:21 | |
| *** mixos has joined #openstack-barbican | 22:23 | |
| *** rhagarty has quit IRC | 22:24 | |
| *** rhagarty has joined #openstack-barbican | 22:24 | |
| redrobot | arunkant pong | 22:27 |
| *** rhagarty_ has joined #openstack-barbican | 22:27 | |
| *** jmckind has quit IRC | 22:28 | |
| *** rhagarty has quit IRC | 22:29 | |
| arunkant | redrobot: still there? | 22:31 |
| * redrobot waves at arunkant | 22:32 | |
| arunkant | redrobot: Can you check out the spec https://review.openstack.org/#/c/263972 .. Had discussion with rellerreller in morning about this. And he mentioned that he will wait for your comments and feedback on this. | 22:33 |
| arunkant | redrobot: I am hoping that this can be discussed in mid-cycle. | 22:35 |
| *** kebray has quit IRC | 22:37 | |
| redrobot | arunkant yes, I'm hoping we can get a lot of BPs approved next week. | 22:37 |
| redrobot | arunkant I'll try to take a look at it over the weekend. | 22:37 |
| *** kebray has joined #openstack-barbican | 22:37 | |
| arunkant | redrobot: thanks | 22:37 |
| *** rhagarty has joined #openstack-barbican | 22:47 | |
| *** diazjf has joined #openstack-barbican | 22:47 | |
| *** rhagarty_ has quit IRC | 22:49 | |
| *** stanzi has joined #openstack-barbican | 22:50 | |
| *** rhagarty has quit IRC | 22:51 | |
| *** mragupat_ has quit IRC | 22:55 | |
| *** mp1 has quit IRC | 23:01 | |
| *** diazjf has quit IRC | 23:02 | |
| *** mp1 has joined #openstack-barbican | 23:02 | |
| *** rhagarty has joined #openstack-barbican | 23:05 | |
| *** mp1 has quit IRC | 23:05 | |
| *** rhagarty_ has joined #openstack-barbican | 23:07 | |
| *** rhagarty has quit IRC | 23:10 | |
| *** dimtruck is now known as zz_dimtruck | 23:12 | |
| *** stanzi has quit IRC | 23:22 | |
| *** stanzi has joined #openstack-barbican | 23:22 | |
| *** stanzi has quit IRC | 23:25 | |
| *** stanzi has joined #openstack-barbican | 23:26 | |
| *** stanzi has quit IRC | 23:31 | |
| *** stanzi has joined #openstack-barbican | 23:31 | |
| *** stanzi has quit IRC | 23:37 | |
| *** spotz is now known as spotz_zzz | 23:38 | |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!