| *** SheenaG has quit IRC | 00:24 | |
| openstackgerrit | Dave McCowan proposed openstack/barbican: Implement Models and Repositories for Resource Quotas https://review.openstack.org/205894 | 00:37 |
|---|---|---|
| *** gyee has quit IRC | 00:40 | |
| *** crc32 has joined #openstack-barbican | 00:49 | |
| *** crc32 has quit IRC | 00:52 | |
| *** jvrbanac has quit IRC | 00:58 | |
| *** jvrbanac has joined #openstack-barbican | 01:00 | |
| *** crc32 has joined #openstack-barbican | 01:02 | |
| *** chlong has joined #openstack-barbican | 01:04 | |
| openstackgerrit | Pradeep Kumar Singh proposed openstack/barbican: Make tests in barbican.tests.tasks py3 compatible https://review.openstack.org/212235 | 01:15 |
| openstackgerrit | Pradeep Kumar Singh proposed openstack/barbican: Make tests in barbican.tests.tasks py3 compatible https://review.openstack.org/212235 | 01:20 |
| *** dimtruck is now known as zz_dimtruck | 01:31 | |
| *** tkelsey has joined #openstack-barbican | 01:36 | |
| *** vivek-ebay has quit IRC | 01:39 | |
| *** tkelsey has quit IRC | 01:40 | |
| openstackgerrit | Pradeep Kumar Singh proposed openstack/barbican: Make tests in barbican.tests.model py3 compatible https://review.openstack.org/212242 | 01:58 |
| *** vivek-ebay has joined #openstack-barbican | 02:06 | |
| *** SheenaG has joined #openstack-barbican | 02:07 | |
| openstackgerrit | OpenStack Proposal Bot proposed openstack/barbican: Updated from global requirements https://review.openstack.org/212243 | 02:10 |
| *** woodster_ has quit IRC | 02:10 | |
| *** edtubill has joined #openstack-barbican | 02:13 | |
| *** zz_dimtruck is now known as dimtruck | 02:15 | |
| openstackgerrit | Zhenyu Zheng proposed openstack/barbican: Drop downgrade field in alembic script.py.mako and version https://review.openstack.org/209323 | 02:27 |
| *** SheenaG has quit IRC | 02:38 | |
| *** xaeth_afk is now known as xaeth | 02:53 | |
| *** elmiko has quit IRC | 02:53 | |
| *** elmiko has joined #openstack-barbican | 02:55 | |
| *** vivek-ebay has quit IRC | 02:55 | |
| *** vivek-ebay has joined #openstack-barbican | 02:56 | |
| *** dave-mccowan has quit IRC | 03:46 | |
| *** dimtruck is now known as zz_dimtruck | 04:11 | |
| *** vivek-ebay has quit IRC | 04:12 | |
| *** vivek-ebay has joined #openstack-barbican | 04:21 | |
| *** xaeth is now known as xaeth_afk | 04:51 | |
| *** xaeth_afk is now known as xaeth | 05:01 | |
| *** vivek-ebay has quit IRC | 05:15 | |
| *** tkelsey has joined #openstack-barbican | 05:37 | |
| *** tkelsey has quit IRC | 05:41 | |
| *** crc32 has quit IRC | 05:44 | |
| *** Nirupama has joined #openstack-barbican | 05:53 | |
| *** nickrmc83 has joined #openstack-barbican | 05:58 | |
| *** edtubill has quit IRC | 06:00 | |
| *** shohel has joined #openstack-barbican | 06:12 | |
| *** shohel has quit IRC | 06:33 | |
| *** shohel has joined #openstack-barbican | 06:33 | |
| *** vivek-ebay has joined #openstack-barbican | 06:58 | |
| *** vivek-ebay has quit IRC | 07:02 | |
| *** nickrmc83 has quit IRC | 07:06 | |
| *** therve has quit IRC | 07:25 | |
| *** therve has joined #openstack-barbican | 07:25 | |
| *** openstackgerrit has quit IRC | 07:41 | |
| *** xaeth has quit IRC | 07:41 | |
| *** jkf has quit IRC | 07:41 | |
| *** openstackgerrit has joined #openstack-barbican | 07:43 | |
| *** xaeth has joined #openstack-barbican | 07:43 | |
| *** jkf has joined #openstack-barbican | 07:43 | |
| *** jkf has quit IRC | 07:45 | |
| *** shohel has quit IRC | 07:45 | |
| *** openstackgerrit has quit IRC | 07:45 | |
| *** shohel has joined #openstack-barbican | 07:45 | |
| *** xaeth has quit IRC | 07:46 | |
| *** xaeth has joined #openstack-barbican | 07:51 | |
| *** jkf has joined #openstack-barbican | 07:52 | |
| *** rm_work is now known as rm_work|away | 07:56 | |
| *** rm_work|away is now known as rm_work | 07:58 | |
| *** openstackgerrit has joined #openstack-barbican | 08:00 | |
| *** rm_work is now known as rm_work|away | 08:00 | |
| *** rm_work|away is now known as rm_work | 08:03 | |
| *** everjeje has quit IRC | 08:12 | |
| *** chlong has quit IRC | 08:13 | |
| *** tkelsey has joined #openstack-barbican | 08:19 | |
| *** rm_work is now known as rm_work|away | 08:25 | |
| *** rm_work|away is now known as rm_work | 08:25 | |
| *** rm_work is now known as rm_work|away | 08:28 | |
| *** rm_work|away is now known as rm_work | 08:29 | |
| *** nickrmc83 has joined #openstack-barbican | 08:48 | |
| *** everjeje has joined #openstack-barbican | 09:11 | |
| *** tkelsey has quit IRC | 10:18 | |
| *** shohel1 has joined #openstack-barbican | 11:02 | |
| *** shohel has quit IRC | 11:02 | |
| *** chlong has joined #openstack-barbican | 11:04 | |
| *** peter-hamilton has joined #openstack-barbican | 11:18 | |
| *** ajc_ has joined #openstack-barbican | 11:43 | |
| *** ajc_ has quit IRC | 11:43 | |
| *** alee_ has quit IRC | 11:57 | |
| *** dave-mccowan has joined #openstack-barbican | 12:00 | |
| *** shohel1 has quit IRC | 12:03 | |
| *** rellerreller has joined #openstack-barbican | 12:35 | |
| *** Nirupama has quit IRC | 12:55 | |
| *** openstackgerrit has quit IRC | 13:01 | |
| *** openstackgerrit has joined #openstack-barbican | 13:02 | |
| *** everjeje has quit IRC | 13:02 | |
| *** atiwari1 has joined #openstack-barbican | 13:13 | |
| *** atiwari has quit IRC | 13:14 | |
| *** shohel has joined #openstack-barbican | 13:20 | |
| *** lisaclark1 has joined #openstack-barbican | 13:20 | |
| hockeynut | looking thru our scripts - I see we still use keystone command (which is deprecated) as opposed to openstack command. Anyone done any work in this area yet? | 13:20 |
| *** peter-hamilton has quit IRC | 13:26 | |
| *** peter-hamilton has joined #openstack-barbican | 13:27 | |
| *** SheenaG has joined #openstack-barbican | 13:29 | |
| dave-mccowan | hockeynut i made it worse by adding more keystone commands :-) but haven't done anything to move to the openstack command. | 13:31 |
| hockeynut | LOL - I am looking at other projects to see what they do (or if we're all in the same deprecated boat) | 13:32 |
| *** xaeth is now known as xaeth_afk | 13:35 | |
| *** alee_ has joined #openstack-barbican | 13:40 | |
| openstackgerrit | Merged openstack/castellan: Remove copy_key operation https://review.openstack.org/206126 | 13:42 |
| *** lisaclark1 has quit IRC | 13:43 | |
| *** peter-hamilton has quit IRC | 13:46 | |
| *** lisaclark1 has joined #openstack-barbican | 13:50 | |
| *** peter-hamilton has joined #openstack-barbican | 13:53 | |
| *** DTadrzak has quit IRC | 13:55 | |
| *** diazjf has joined #openstack-barbican | 13:59 | |
| *** zz_dimtruck is now known as dimtruck | 14:03 | |
| *** pglass has joined #openstack-barbican | 14:05 | |
| *** spotz_zzz is now known as spotz | 14:08 | |
| *** lisaclark1 has quit IRC | 14:11 | |
| rellerreller | diazjf Here is the link to the swift spec that is creating the KeyMaster, https://review.openstack.org/#/c/193749/ | 14:14 |
| rellerreller | diazjf at the summit you and solis said you might be willing to talk with them to try and integrate Castellan instead of creating KeyMaster. | 14:14 |
| *** edtubill has joined #openstack-barbican | 14:17 | |
| *** lisaclark1 has joined #openstack-barbican | 14:17 | |
| *** DTadrzak has joined #openstack-barbican | 14:21 | |
| *** xaeth_afk is now known as xaeth | 14:25 | |
| *** silos has joined #openstack-barbican | 14:31 | |
| rellerreller | Does anyone have expert knowledge of utils.parameterized_dataset? Adding attributes does not appear to stick with the parameterized function. | 14:40 |
| rellerreller | jvrbanac you know about ^ | 14:40 |
| jvrbanac | rellerreller, I know quite a bit about it | 14:41 |
| jvrbanac | rellerreller, what do you mean by "do not appear to stick"? | 14:43 |
| *** vivek-ebay has joined #openstack-barbican | 14:50 | |
| rellerreller | jvrbanac I added a "non-standard-algorithm' attribute to a method. | 14:52 |
| rellerreller | jvrbanac in particular to the functional test_secret_create_valid_algorithms | 14:53 |
| rellerreller | jvrbanac If I run nosetests and apply the extra parameter "--attr='non-standard-algorithm'" then no tests are run | 14:53 |
| rellerreller | jvrbanan the test test_secret_create_valid_algorithms is a parameterized function test. | 14:54 |
| *** morgan_404 is now known as morgan_302 | 14:55 | |
| rellerreller | If I remove the parameterized.data_set attribute from the function and hard code in the one example value ("invalid" in this case) then rerun nosetests with attribute parameter then one test is run. | 14:55 |
| jvrbanac | rellerreller, so I haven't used nose attributes. I'm not sure if testr supports that either. | 14:56 |
| rellerreller | jvrbanac My guess is that when building the new parameterized functions that the other decorators on the function are lost. | 14:56 |
| rellerreller | jvrbanac correct. I had to import nosetests attributes | 14:56 |
| rellerreller | There was a 'positive' attribute but that attribute was imported from testtools, but we do not run our tests with test tools, so I changed it to nosetests attribute | 14:57 |
| diazjf | rellerreller, correct, Janie Richling wants to move forward with Castellan instead of the Trivial Keymaster, but she will have to convince the swift-cores | 14:58 |
| *** vivek-ebay has quit IRC | 14:59 | |
| rellerreller | diazjf thanks for the update. That would be great if swift integrates with Castellan. | 14:59 |
| diazjf | rellerreller, I'll let you know as soon as I hear more | 15:00 |
| diazjf | redrobot, wanna do hangouts today at 1:00PM CST to go over https://blueprints.launchpad.net/python-barbicanclient/+spec/remove-test-client | 15:04 |
| jvrbanac | rellerreller, so if we're running this in the gate it does need to support testr. So one of the reasons we have our own parameterized piece is that it supports nose, pytest, and testr | 15:11 |
| jvrbanac | rellerreller, however when we start supporting tagging, we'll need to make sure we pass through the information on new methods. Which sounds like the issue you're seeing right now | 15:12 |
| openstackgerrit | Nathan Reller proposed openstack/barbican: Made Functional Test Key 256 Bits https://review.openstack.org/212578 | 15:13 |
| openstackgerrit | Nathan Reller proposed openstack/barbican: Integrated with PyKMIP Pie API https://review.openstack.org/212579 | 15:13 |
| diazjf | rm_work, just took a look at https://review.openstack.org/#/c/156307/ I like the idea | 15:13 |
| rellerreller | jvrbanac That is correct. Right now I am not able to pass command line arguments to tox to limit tests by attribute. Unless I am doing something wrong, which is possible :) | 15:14 |
| rellerreller | An easy review with only one line change, https://review.openstack.org/212578 | 15:18 |
| *** SheenaG has quit IRC | 15:21 | |
| *** arunkant_ has joined #openstack-barbican | 15:22 | |
| *** kfarr has joined #openstack-barbican | 15:23 | |
| *** SheenaG has joined #openstack-barbican | 15:24 | |
| *** arunkant_ has quit IRC | 15:31 | |
| *** vivek-ebay has joined #openstack-barbican | 15:32 | |
| *** arunkant_ has joined #openstack-barbican | 15:33 | |
| *** darrenmoffat has quit IRC | 15:37 | |
| *** darrenmoffat has joined #openstack-barbican | 15:38 | |
| redrobot | diazjf sounds good | 15:43 |
| diazjf | redrobot, perfect, send me your hangouts email | 15:44 |
| *** woodster_ has joined #openstack-barbican | 15:57 | |
| *** SheenaG has left #openstack-barbican | 15:59 | |
| *** SheenaG has joined #openstack-barbican | 15:59 | |
| dave-mccowan | redrobot: are transport keys supposed to be associated with a project? for now, the project_id is not stored in the transport key repo. any admin can see all the transport keys. is that right? should the transport keys be per-plugin only, or per-project+plugin? | 16:01 |
| dave-mccowan | alee_ ^^^ | 16:03 |
| alee_ | dave-mccowan, right now, I believe they are plugin specific | 16:13 |
| alee_ | dave-mccowan, the idea is that the traansport key is related to the backend | 16:13 |
| alee_ | dave-mccowan, so in the case of dogtag, we have one transport key for the kra | 16:13 |
| dave-mccowan | alee_ so it does not make sense to enforce project level quotas on them, right? | 16:14 |
| alee_ | dave-mccowan, sure - I'd agree with that | 16:14 |
| alee_ | (until we add support for transport key per project) | 16:15 |
| alee_ | if we ever do) | 16:15 |
| *** diazjf has quit IRC | 16:20 | |
| *** lisaclark1 has quit IRC | 16:20 | |
| *** gyee has joined #openstack-barbican | 16:22 | |
| *** diazjf has joined #openstack-barbican | 16:30 | |
| *** openstackgerrit has quit IRC | 16:31 | |
| *** openstackgerrit has joined #openstack-barbican | 16:32 | |
| *** crc32 has joined #openstack-barbican | 16:33 | |
| *** lisaclark1 has joined #openstack-barbican | 16:34 | |
| *** lisaclark1 has quit IRC | 16:34 | |
| *** lisaclark1 has joined #openstack-barbican | 16:34 | |
| *** shohel has quit IRC | 16:36 | |
| dave-mccowan | alee_ by the way, i ran into a spurious failure in the dogtag gate check | 16:41 |
| alee_ | dave-mccowan, what is it? | 16:41 |
| dave-mccowan | in the secret tests, there is a create_then_expire check. it goes: create(5 second expiry), check-for-ok, wait for 10 seconds, check-for-gone | 16:42 |
| dave-mccowan | when running in parallel mode with the dogtag plugin, at least one time, it took over five seconds between create and check-for-ok. | 16:43 |
| dave-mccowan | alee_ i could fix (or hide) this by cranking up the expiry time. or try to come up with a better ideas. | 16:44 |
| *** jamielennox is now known as jamielennox|away | 16:45 | |
| *** silos has left #openstack-barbican | 16:52 | |
| alee_ | dave-mccowan, gotcha | 16:53 |
| alee_ | yeah - let me noodle a not on that | 16:54 |
| alee_ | a bit that is | 16:54 |
| dave-mccowan | alee_ the parallel running tests messed up some of the quotas tests that use shared resources. i started a skip list in my last CR. so another option to consider is to not run timing sensitive tests through the parallel run. | 16:56 |
| *** kfarr has quit IRC | 17:04 | |
| *** rellerreller has quit IRC | 17:07 | |
| *** tkelsey has joined #openstack-barbican | 17:08 | |
| dave-mccowan | alee_ back to transport keys: since those are deployment wide resources, shouldn't it require service level (not just project admin level) privileges to operate them? seems like an admin for project-a could impact project-b pretty easily. | 17:08 |
| *** vivek-ebay has quit IRC | 17:08 | |
| *** vivek-ebay has joined #openstack-barbican | 17:32 | |
| *** vivek-ebay has quit IRC | 17:32 | |
| *** edtubill has quit IRC | 17:33 | |
| *** diazjf has quit IRC | 17:41 | |
| *** diazjf has joined #openstack-barbican | 17:50 | |
| *** vivek-ebay has joined #openstack-barbican | 17:53 | |
| *** vivek-ebay has quit IRC | 17:54 | |
| *** edtubill has joined #openstack-barbican | 17:55 | |
| *** silos has joined #openstack-barbican | 17:57 | |
| *** rm_work is now known as rm_work|away | 17:58 | |
| *** rm_work|away is now known as rm_work | 18:00 | |
| rm_work | thanks diazjf -- we'll see if it pans out | 18:00 |
| diazjf | rm_work np | 18:00 |
| diazjf | redrobot, gonna start the hangout | 18:00 |
| redrobot | diazjf cool | 18:00 |
| rm_work | alee_: commented | 18:05 |
| *** rellerreller has joined #openstack-barbican | 18:09 | |
| rm_work | like three times, because i kept missing various concerns | 18:11 |
| rm_work | rellerreller: you're killing me | 18:11 |
| rellerreller | rm_work sorry | 18:12 |
| rm_work | lol | 18:12 |
| rm_work | rellerreller: np, just giving you a hard time in return :P take a look at https://review.openstack.org/#/c/156623/ | 18:12 |
| rm_work | the comments, not the trivial changes | 18:12 |
| rm_work | rellerreller: "Why is creating a container required? Why can't a normal KeyManager be used store each of the items?" | 18:13 |
| rm_work | rellerreller: the normal Keymanager COULD be used to store each of the items -- in fact i have a generic implementation in mind that will use KeyManager to actually handle 100% of the storage interaction | 18:14 |
| rm_work | Maybe what I need to do is just write it up and include it | 18:14 |
| rellerreller | rm_work that sounds great. Problem solved! | 18:14 |
| rm_work | rellerreller: i mean, I have an implementation of CertManager that works in that way :P | 18:15 |
| rm_work | but you're commenting on the interface, not the implementations, which is why I am confused | 18:15 |
| rm_work | the interface itself doesn't REQUIRE anything specific as far as storage | 18:15 |
| openstackgerrit | Adam Harwell proposed openstack/castellan: Officially add Certificate Management to scope https://review.openstack.org/156623 | 18:16 |
| rm_work | rebase | 18:16 |
| rellerreller | rm_work my comments are on the interface because I am thinking of future implementations. | 18:17 |
| rellerreller | rm_work the concept of a container is related to Barbican. If it is the only thing that supports a container then maybe an interface is not required. | 18:17 |
| rm_work | EVERYTHING supports a container | 18:18 |
| rellerreller | rm_work I know that you could plug in a bunch of different implementations behind it if you hacked things together, but I feel like that is not the best approach. | 18:18 |
| rm_work | there's no restriction that things have a "specific concept of a container" to support groupings | 18:18 |
| rm_work | as long as we have one consistent definition of how that works | 18:19 |
| rm_work | for each bqackend | 18:19 |
| rm_work | *backend | 18:19 |
| rellerreller | rm_work when you say everything supports a container then you mean that it is possible to store a group of objects together. | 18:19 |
| rellerreller | rm_work In your mind a CertificateManager implementation that writes a blob of data to file and returns UUID is a valid certificate manager. I think that is a bit of a hack to make it support containers. | 18:20 |
| silos | cd | 18:20 |
| rm_work | rellerreller: i think it doesn't matter | 18:20 |
| rm_work | rellerreller: i think we could also shove everything into PKCS12 and store THAT in the device | 18:20 |
| rm_work | if the device supports PKCS12 | 18:20 |
| *** SheenaG has quit IRC | 18:20 | |
| rm_work | there are quite a few ways to do it | 18:20 |
| rm_work | sure, some are hackier than others | 18:21 |
| rm_work | but none of them are so hacky that I think they aren't a reliable approach here | 18:21 |
| *** kfarr has joined #openstack-barbican | 18:21 | |
| rellerreller | rm_work I agree that you could use PKCS12 like that, but that is kind of hiding objects in the key manager. | 18:21 |
| rellerreller | rm_work I feel that a common interface for key managers should be fairly intuitive as to the operations it performs. | 18:22 |
| rm_work | so you absolutely want to keep objects stored individually in the keymanager, but you absolutely don't want to see a grouping of objects? | 18:22 |
| rellerreller | rm_work for instance store easily maps to register in KMIP and some similar operation in PKCS11. | 18:22 |
| rellerreller | KMIP does not support grouping objects together, and I do not know how much support is provided by PKCS11 for that. | 18:23 |
| rm_work | rellerreller: maybe it makes sense for there to be a KMIP implementation, maybe it doesn't? | 18:23 |
| rm_work | i think that's really off track | 18:23 |
| rm_work | so maybe we don't make a KMIP impl | 18:23 |
| rm_work | i am saying it is 100% possible to do, but maybe we don't need or want one | 18:23 |
| rm_work | hell, one use-case for this is just barbican_v1 -> barbican_v2 apparently | 18:24 |
| rellerreller | rm_work what other implementations have a container concept? | 18:24 |
| rm_work | the whole point is that we don't care what backends have a container, we want to be able to make a logical grouping at a higher level | 18:24 |
| rellerreller | rm_work it matters in terms of what implementations we think can support it and how easy it will be to do that. | 18:25 |
| rellerreller | rm_work for instance KMIP would have a difficult time doing that. Most implementations will not support opaque objects. | 18:26 |
| rm_work | and as I said, I can make an implementation that will work with literally any backend | 18:26 |
| rm_work | you just don't like the way it works | 18:27 |
| rellerreller | rm_work it also matters in terms of auditability. If we are creating blobs of data on highly sensitive key management devices then we should know what data reside on them. | 18:27 |
| rm_work | should you? | 18:27 |
| rm_work | or is the whole point of the KMD that the data is opaque end-to-end? | 18:28 |
| rellerreller | rm_work that is not true. Not all devices support opaque objects, so I know many KMIP devices that will not support this. | 18:28 |
| rm_work | i thought that the whole point was that a user could be secure in the knowledge that no one can read what they put in | 18:28 |
| rm_work | according to what I have read about KMIP, the ability to store arbitrary data is not in question | 18:29 |
| rm_work | i also find it interesting that with all the assertions that Certificates aren't secret data | 18:29 |
| rm_work | KMIP protocol defines interactions with Certificates explicitly | 18:30 |
| rellerreller | rm_work check out opaque data types and notice that nothing is defined. | 18:30 |
| rm_work | https://en.wikipedia.org/wiki/Key_Management_Interoperability_Protocol | 18:30 |
| rellerreller | rm_work I have no problem storing certificates. | 18:30 |
| rellerreller | rm_work I have a meeting. | 18:31 |
| rm_work | k | 18:31 |
| rm_work | "A KMIP server stores and controls Managed Objects such as Symmetric and Asymmetric keys, Certificates, and user defined objects." | 18:31 |
| rm_work | "The types of managed object that are managed by KMIP include:-" | 18:31 |
| *** tkelsey has quit IRC | 18:31 | |
| rm_work | ""Opaque Data for client and server defined extensions." | 18:31 |
| rm_work | "Secret Data (passwords)." | 18:31 |
| rm_work | if you can store a password, I can store anything I want, because any string could be a password | 18:32 |
| openstackgerrit | Adam Harwell proposed openstack/castellan: Add barbican implementation of CertManager https://review.openstack.org/211780 | 18:33 |
| openstackgerrit | Adam Harwell proposed openstack/castellan: Copy octavia.certmgr to Castellan https://review.openstack.org/156307 | 18:33 |
| rm_work | ^^ rebases | 18:33 |
| rm_work | ^^ rebases | 18:33 |
| *** edtubill has left #openstack-barbican | 18:34 | |
| *** rellerreller has quit IRC | 18:35 | |
| *** kfarr has quit IRC | 18:40 | |
| *** gyee has quit IRC | 18:45 | |
| *** diazjf has left #openstack-barbican | 18:48 | |
| *** nkinder has joined #openstack-barbican | 18:49 | |
| *** atiwari1 has quit IRC | 18:49 | |
| *** nkinder has quit IRC | 18:50 | |
| *** lisaclark1 has quit IRC | 18:54 | |
| *** lisaclark1 has joined #openstack-barbican | 18:57 | |
| *** lisaclark1 has quit IRC | 18:59 | |
| openstackgerrit | Adam Harwell proposed openstack/castellan: Example implementation for a GENERIC CertManager https://review.openstack.org/212701 | 18:59 |
| rm_work | ^^ VERY quick example of how a generic CertManager implementation would work | 18:59 |
| rm_work | alee_ / rellerreller: ^^ | 18:59 |
| rm_work | maybe now I can stop explaining this :P | 18:59 |
| *** SheenaG has joined #openstack-barbican | 19:02 | |
| *** rellerreller has joined #openstack-barbican | 19:02 | |
| *** lisaclark1 has joined #openstack-barbican | 19:05 | |
| rm_work | rellerreller: https://review.openstack.org/212701 | 19:08 |
| rm_work | wrote up an example really quick | 19:08 |
| rellerreller | rm_work I see that. | 19:09 |
| rellerreller | rm_work why not store the metadata in a common service instead of the key manager? | 19:10 |
| rm_work | which common servce? | 19:10 |
| rm_work | *service | 19:10 |
| rm_work | I understand what you're saying, my question is more rhetorical | 19:10 |
| rellerreller | rm_work you are creating the container with Service A then storing that URL to the container in some common place. THen Service B comes along, uses the container ID to get all of the different components. | 19:11 |
| rm_work | yes | 19:11 |
| rm_work | but *what* common service? some DB somewhere? | 19:11 |
| rellerreller | rm_work so why not store a URL for each secret instead of a container? | 19:11 |
| rm_work | the keyManager *is* the common service | 19:11 |
| rm_work | rellerreller: so, if you read the comments on the higher level CR https://review.openstack.org/#/c/156623/4 i did ask that question | 19:12 |
| rm_work | " If the general consensus is that the usability improvement is so trivial between this method and having no logical grouping system, then I guess I would have to cede to that view. Personally, I think there are numerous advantages to a logical grouping, not the least of which is that as a user you can more easily keep track of which Secrets link with what. If I have 20 Private Keys and 60 different X509 Certs that go with them, | 19:12 |
| rm_work | and passphrases for them and Intermediates for them -- how the heck do I keep track of that easily as a user?" | 19:12 |
| rm_work | because kfarr asked the same thing you did | 19:13 |
| rm_work | but I *don't* think that's the consensus | 19:13 |
| rm_work | I think so far that's you and her in the minority :) | 19:13 |
| rellerreller | rm_work In cinder volume encryption you create a key with Cinder and then Nova reads the key. The metadata is stored with the volume. | 19:13 |
| rm_work | rellerreller: that's a totally different case | 19:13 |
| rm_work | there's no analogue here | 19:13 |
| rellerreller | rm_work your use case is for VPNaaS or something. You create keys with one entity and then some other entity reads them and uses them. | 19:13 |
| rm_work | the *user* creates the certbundle | 19:14 |
| rellerreller | rm_work where are your slides from your presentation. I can show you. | 19:14 |
| rm_work | and then SEVERAL services read them | 19:14 |
| rm_work | there's no common place for metadata storage between LBaaS, VPNaaS, FWaaS, HEAT | 19:14 |
| rm_work | besides the KeyManager | 19:15 |
| rm_work | that's the point | 19:15 |
| rellerreller | rm_work look at your slides https://www.openstack.org/summit/vancouver-2015/summit-videos/presentation/common-use-cases-and-options-for-barbican-in-your-openstack-deployment | 19:15 |
| rm_work | ok, which slide | 19:15 |
| rellerreller | rm_work the one entitle "Neutron/LBaaS + Barbican" | 19:16 |
| rm_work | ok | 19:16 |
| rm_work | I am on that slide | 19:16 |
| rellerreller | The user creates container in Barbican and then stores container ID in Neutron LBaaS. | 19:16 |
| rm_work | yes | 19:16 |
| rellerreller | rm_work why not store each item and then store each URL to each secret in Neutron | 19:16 |
| rm_work | you want the user to create individual keys in Barbican and store 3-4 refs in Neutron-LBaaS | 19:17 |
| rm_work | I get that | 19:17 |
| rm_work | and my response to that is: | 19:17 |
| rm_work | " If the general consensus is that the usability improvement is so trivial between this method and having no logical grouping system, then I guess I would have to cede to that view. Personally, I think there are numerous advantages to a logical grouping, not the least of which is that as a user you can more easily keep track of which Secrets link with what. If I have 20 Private Keys and 60 different X509 Certs that go with them, | 19:17 |
| rm_work | and passphrases for them and Intermediates for them -- how the heck do I keep track of that easily as a user?" | 19:17 |
| rm_work | you are asking the exact same question kfarr asked | 19:17 |
| rm_work | if this is something we can standardize and abstract, why would we not want to do that? | 19:18 |
| rm_work | we can provide quite a bit of utility around the CertBundle concept | 19:19 |
| *** edtubill has joined #openstack-barbican | 19:19 | |
| rellerreller | rm_work because it is much easier to store 3 URLs as metadata as opposed to creating a new interface with new implementations of which only Barbican has a good mapping. | 19:19 |
| rm_work | things that aren't there yet, but could be eventually -- validation, parsing, etc | 19:19 |
| rm_work | rellerreller: I would want this even if Barbican had no Container mapping | 19:19 |
| rm_work | in fact I am on the warpath here again in part because it's possible Barbican won't, in the future | 19:20 |
| rm_work | and we *need* to standardize this grouping | 19:20 |
| rm_work | early, before end-users start utilizing these services | 19:21 |
| rellerreller | You keep highlighting need and emphasizing that, but I just showed that you don't need it. | 19:21 |
| rellerreller | It is possible to do LBaaS without a CetificateManager interface as you have defined it. | 19:21 |
| * peter-hamilton is eating popcorn | 19:22 | |
| rm_work | i think you're underestimating how much the user story improves | 19:22 |
| rm_work | rellerreller: oh yes, definitely | 19:22 |
| rm_work | i said as much | 19:22 |
| rm_work | i also said it would be annoying as all hell for the users | 19:22 |
| rellerreller | rm_work why is it annoying? | 19:23 |
| rm_work | there's no way I would want to individually track all of this stuff when the system can easily do it for me | 19:23 |
| rm_work | rellerreller: imagine you have 20 private keys and 60 certificates and many of them have different intermediate chains | 19:23 |
| rellerreller | rm_work I create lots of keys for volume encryption and image encyption and signing. | 19:23 |
| rm_work | ok, how do you keep track of them? | 19:23 |
| rellerreller | I associate them with an object, like a volume or image. | 19:23 |
| rm_work | erg | 19:23 |
| rm_work | except they need to be associated with EACH OTHER | 19:23 |
| rellerreller | Then I query the image and it returns the 1 or 2 items that are associated with it. | 19:24 |
| rm_work | that is fine if everything is independent | 19:24 |
| rellerreller | i.e. my many images that are encrypted, but each image only has 1 or 2 items associated with it. That is easy to manage. | 19:24 |
| rm_work | so you're saying if the user wants to set up a new VPN, they should find one of their LoadBalancers that happens to use the correct Cert/Key combo and query it and get their data back? | 19:24 |
| rm_work | that is nuts | 19:24 |
| rellerreller | When you call Neutron what is the container associated with? | 19:25 |
| rm_work | a Loadbalancer | 19:25 |
| rellerreller | What is the API call? | 19:25 |
| rellerreller | what is the method signature? | 19:26 |
| rm_work | GET http://myurl/neutron-lbaas/loadbalancers/<lb_id>/tls | 19:26 |
| rm_work | approximately | 19:26 |
| rellerreller | Can you send link to API call? | 19:26 |
| rm_work | ? | 19:27 |
| rellerreller | I don't know what the expected input and output parameters are. | 19:27 |
| rm_work | for a GET? | 19:27 |
| rm_work | sec | 19:27 |
| rellerreller | Something like this http://docs.openstack.org/developer/barbican/api/reference/secrets.html | 19:27 |
| rm_work | looking | 19:28 |
| rm_work | our docs aren't done yet | 19:28 |
| rm_work | i am hoping we have something semi-useful tho | 19:28 |
| rellerreller | What is neutron client code method signature? | 19:29 |
| rm_work | http://developer.openstack.org/api-ref-networking-v2-ext.html#lbaas-v2.0 | 19:29 |
| rm_work | not sure TLS has been added to that yet | 19:29 |
| rellerreller | So basically you are associating a container ID to LB ID, correct? | 19:30 |
| rm_work | it's one field | 19:30 |
| rm_work | so like, LBID 12345 | 19:31 |
| rm_work | might have an extra json element | 19:31 |
| rm_work | "certificate_ref": "<cert_ref>" | 19:31 |
| rm_work | in its return data structure | 19:31 |
| rellerreller | So if I wanted to know the private key, public key, and certificate associated with a LB then I would query Neutron and say GET for LB. | 19:31 |
| rm_work | sure | 19:32 |
| rellerreller | Then that would return 3 URLs for where private key, public key, and certificate are located. | 19:32 |
| rm_work | yes | 19:32 |
| rellerreller | That seems just as easy to manage as one for container, or maybe I am missing something. | 19:32 |
| rm_work | and that is a retarded workflow for tracking which PK/Certs are associated with each other in your KeyManager | 19:32 |
| rellerreller | So while I may have 100s or 1000s of keys I can easily see how they are related by viewing the metadata for a LB | 19:33 |
| rm_work | lol | 19:33 |
| rm_work | that is ... | 19:33 |
| rm_work | i don't even know how to respond to that | 19:33 |
| rm_work | can someone help me out here? | 19:33 |
| * peter-hamilton is still eating popcorn | 19:33 | |
| rm_work | LBs are just one service | 19:34 |
| rellerreller | Please do not say that is retarded. That is not helpful. | 19:34 |
| rellerreller | I'm trying to work through this. | 19:34 |
| rm_work | yeah, sorry, i am having trouble because I feel like at a fundamental level there is something you're missing | 19:34 |
| rm_work | but i can't figure out how to explain it | 19:34 |
| * redrobot pokes head in | 19:35 | |
| rm_work | and the fact that i can't figure out how to explain it is almost more frustrating | 19:35 |
| rellerreller | I would like to know if I am missing something because this is how keys and other secrets are managed in Nova, Cinder, and soon Glance. | 19:35 |
| redrobot | rm_work who's the user you keep arguing for? devs in other projects using api to talk to lbass? or end users of a cloud provider (or private cloud)? | 19:36 |
| rm_work | other keys are standalone things | 19:36 |
| rellerreller | Sahara is also looking to use KeyManager and managing secrets in a similar way. | 19:36 |
| rm_work | end users | 19:36 |
| rellerreller | I do have to leave in a minute. | 19:36 |
| rm_work | if you had a standalone key and it was associated with some CBS volume | 19:36 |
| redrobot | so you're arguing for openstack users | 19:36 |
| rm_work | it makes KINDOF a sort of sense | 19:37 |
| redrobot | and in that case, I would say that I do see value in grouping those things for them in the openstack key manager | 19:37 |
| rm_work | that if you forgot which key it was you needed, you could look up the CBS Volume that you know uses it | 19:37 |
| rm_work | but when you have a series of objects that are closely tied to each other, it does not make sense to rely on looking in another system to see how they are grouped | 19:37 |
| redrobot | where I'm having trouble is figuring out why this belongs in Castellan | 19:38 |
| rm_work | because they are meaningful outside of the other system | 19:38 |
| rm_work | if you were to delete all of your LBs, you would have no way to track which things belonged with each other | 19:38 |
| redrobot | since castellan's purpose is to allow devs to use other key managers besides the openstack key manager | 19:38 |
| rm_work | whereas if you deleted all your CBS Volumes, each key is still technically useful because you can still make use of it by itself | 19:39 |
| redrobot | rm_work what other non-barbican key managers do you need to support? | 19:39 |
| rm_work | redrobot: i am more concerned with barbican_v1 vs barbican_v2 at the moment | 19:39 |
| rm_work | which an interface like this also helps to mitigate :P | 19:39 |
| rm_work | personally as RAX, we don't need a different key manager | 19:40 |
| rellerreller | My last point and I have to leave | 19:40 |
| rellerreller | rm_work "if you were to delete all of your LBs, you would have no way to track which things belonged with each other" | 19:40 |
| rellerreller | rm_work how would you do that with just certificate URL? The problem seems the same. | 19:40 |
| rm_work | rellerreller: the "certificate_bundle_url" | 19:40 |
| rellerreller | That is a reference problem and not a container problem. | 19:40 |
| rellerreller | But if you delete LB then metadata is gone so have no certificate bundle URL. | 19:41 |
| rm_work | err | 19:41 |
| rm_work | it'd be in the keymanager | 19:41 |
| rm_work | you don't even track the keys, you track the certificatebundles | 19:41 |
| rm_work | which link together the certs with their appropriate keys and intermediates | 19:42 |
| redrobot | rm_work why not put this in python-barbicanclient if your main concern is openstack user experience? | 19:42 |
| redrobot | rm_work my understanding was your main use case for a non-barbican solution was testing? | 19:43 |
| rm_work | for US | 19:43 |
| rm_work | (RAX) | 19:43 |
| rm_work | not necessarily for any other place wanting to run LBaaS | 19:43 |
| rm_work | apparently any government facility needs to not use Barbican? | 19:43 |
| rm_work | per how I understand JHU's problem | 19:44 |
| rm_work | so any gov. linked entity running openstack-lbaas would need to use a different impl | 19:44 |
| rm_work | it's the exact same issue | 19:44 |
| *** rellerreller has quit IRC | 19:45 | |
| rm_work | I am honestly not often thinking of RAX when working on this stuff, but openstack as a whole | 19:45 |
| redrobot | but if the barbicanclient impl uses castellan then there is no issue | 19:46 |
| rm_work | uhhh what | 19:46 |
| rm_work | why would Barbican-Client use Castellan to use KMIP? >_> | 19:46 |
| redrobot | no idea, I didn't think that one through | 19:46 |
| rm_work | the whole point is that Castellan is the generic interface | 19:47 |
| redrobot | :-P | 19:47 |
| rm_work | lol | 19:47 |
| redrobot | the problem is where to store the association | 19:47 |
| rm_work | which i don't think is a problem | 19:47 |
| redrobot | if the deployment is using barbican, then barbican can store it | 19:47 |
| rm_work | if the deployment is using anything that can store data, then that system can store it | 19:47 |
| rm_work | per https://review.openstack.org/#/c/212701/1 | 19:47 |
| * peter-hamilton is out of popcorn | 19:49 | |
| elmiko | lol | 19:49 |
| elmiko | rm_work: i have to admit, the use case is going over my head (aside from the convenience angle), but the change requests lgtm codewise. | 19:51 |
| peter-hamilton | rm_work: tbh, this sounds like something that should sit on top of castellan or barbican (containers-as-a-service) | 19:53 |
| rm_work | heh | 19:53 |
| rm_work | if only that name weren't already in use :P | 19:54 |
| peter-hamilton | rm_work: :) | 19:54 |
| *** peter-hamilton has quit IRC | 19:54 | |
| rm_work | Basically, I don't see any better place to put it, i think it has enough ties to what Castellan does to make sense having it there, and i DEFINITELY don't see the harm it would cause by being there (while it seems other people see it as an End Of The World scenario) | 19:55 |
| rm_work | the best arguments I've seen that I can't instantly debunk are that "it doesn't seem to add much", but the amount of people I have talked to that think it DOES add enough to be worthwhile is a significantly larger pool... i am starting to wonder what the fight is even about | 19:56 |
| rm_work | are people opposed to this simply out of habit? | 19:56 |
| redrobot | I just want to understand more of the non-barbican implications | 19:57 |
| redrobot | like, will someone really deploy a cloud with netron-lbass talking directly to a kmip device | 19:58 |
| rm_work | well, it sounds like soon Barbican won't have a containers concept either | 19:58 |
| rm_work | and THEN what happens to us? :? | 19:58 |
| rm_work | :/ | 19:58 |
| redrobot | one argument against storing metadata as a string in the kmip device is that storage is usually very limited in HSMs | 19:59 |
| rm_work | that's valid | 20:00 |
| rm_work | how limited are we talking? | 20:01 |
| redrobot | rm_work I don't remember the exact limit, but it was in the MBs | 20:01 |
| rm_work | hmm | 20:02 |
| redrobot | rm_work we had to re-architect the pcks#11 plugin to deal with the storage limits | 20:02 |
| rm_work | well, I would imagine the "container" secret is fairly minimal compared to any of the parts | 20:02 |
| rm_work | i guess the concern would be even storing the certs in there would be large | 20:02 |
| redrobot | yeah, it would only really work for tiny clouds | 20:03 |
| *** pglbutt has joined #openstack-barbican | 20:03 | |
| rm_work | if that's the case, then even rellerreller's alternative solution (passing three refs) doesn't help | 20:04 |
| rm_work | because it has the same problem | 20:04 |
| rm_work | the "metadata secret" is trivially small comparatively | 20:04 |
| *** pglass has quit IRC | 20:05 | |
| rm_work | and in that case, you could make another implementation of CertManager, that uses split backends, HSM for the PK/passphrase, and some other backend (a db even) for the other data | 20:06 |
| rm_work | it's not as simple, but it works | 20:06 |
| rm_work | you can do an implementation of the interface that does almost anything you can think of | 20:06 |
| rm_work | most of the arguments against this are against people's visions of specific implementations and their restrictions, nothing related to the interface itself | 20:07 |
| rm_work | redrobot: ^^ | 20:07 |
| rm_work | would you agree? | 20:07 |
| *** lisaclark1 has quit IRC | 20:07 | |
| *** pglass has joined #openstack-barbican | 20:10 | |
| redrobot | eh... not sure | 20:13 |
| *** pglbutt has quit IRC | 20:14 | |
| rm_work | if i go back and look at the arguments against, i pretty much only see stuff that's related to specific implementations (and people's assumptions about how they would work) | 20:14 |
| rm_work | I could hack up a split-backend example really quickly, if that would help | 20:14 |
| openstackgerrit | OpenStack Proposal Bot proposed openstack/barbican: Updated from global requirements https://review.openstack.org/212243 | 20:16 |
| *** lisaclark1 has joined #openstack-barbican | 20:21 | |
| *** lisaclark1 has quit IRC | 20:21 | |
| *** tkelsey has joined #openstack-barbican | 20:24 | |
| redrobot | rm_work so, the way I see it, I don't really care about the end user story, but I do care about the deployment story | 20:32 |
| rm_work | poor end-users T_T | 20:32 |
| redrobot | horizon could store the key to container associations in a UI if all we care about is end users | 20:32 |
| redrobot | * key to cert | 20:32 |
| rm_work | if all you care about is UI end-users | 20:33 |
| redrobot | yeah, and I do see value in storing that _somewhere_ for openstack use | 20:33 |
| redrobot | but adding a new interface with its sets of plugins complicates deployment | 20:33 |
| rm_work | but simplifies interoperability and changes in base services :/ | 20:34 |
| *** pglass has quit IRC | 20:34 | |
| rm_work | (ie, changes in how barbican handles storing containers) | 20:34 |
| *** pglass has joined #openstack-barbican | 20:35 | |
| redrobot | I don't think services passing a single reference vs may references really makes a difference | 20:38 |
| redrobot | *many | 20:38 |
| * redrobot can't type today | 20:38 | |
| rm_work | well, as you were saying, it may not even be an option to store cert data in HSMs | 20:39 |
| rm_work | which is where Castellan CertManager using a split-backend implementation would come in useful | 20:40 |
| rm_work | but yes, technically LBaaS/etc could just use CastellanKeyManager and take three refs... | 20:41 |
| rm_work | I think it's a significantly worse end-user experience | 20:41 |
| rm_work | but it would work in a technical sense | 20:41 |
| rm_work | if that's what it comes to | 20:41 |
| *** edtubill has quit IRC | 20:44 | |
| *** tkelsey has quit IRC | 20:44 | |
| redrobot | I think it would make for a better non-barbican story | 20:45 |
| rm_work | I actually think an interface like this that allows for things like split-backend would prevent issues down the road if we decide we DO want to change the way Certs are stored (like changing it so they're just metadata on PKs even in Barbican) | 20:45 |
| rm_work | because it's inherently *not something the services care about* | 20:47 |
| rm_work | so by abstracting it away, it makes it much easier for YOU to control the story | 20:47 |
| rm_work | as opposed to leaving it up to the individual services to choose the details of how things are stored | 20:48 |
| rm_work | redrobot: ^^ | 20:48 |
| rm_work | for instance right now we store everything in Barbican, and you don't have any way to control that. if it were to be a problem in the future, you'd have to get any services to change the way they work internally, as opposed to just tweaking the CertManager impl :P | 20:49 |
| *** woodster_ has quit IRC | 20:50 | |
| *** woodster_ has joined #openstack-barbican | 20:54 | |
| redrobot | I don't like the split-backend idea, because you're basically deploying a new service just to hold cert metadata.... might as well deploy barbican at that point. | 20:56 |
| rm_work | unless you can't deploy barbican :P | 20:56 |
| rm_work | and not just cert metadata | 20:56 |
| rm_work | unless you consider the actual x509 to be "metadata" | 20:56 |
| redrobot | no, the actual X.509 is already covered by the current key_manager interface | 20:57 |
| rm_work | redrobot: unless you have limited space in an HSM | 20:57 |
| rm_work | which is the other major argument i'm hearing | 20:58 |
| redrobot | limited space argument is for storing the key->cert association | 20:58 |
| redrobot | in the device | 20:58 |
| alee_ | redrobot, I'm not sure I understand the whole "limited space in the HSM" argument. Aren't you only storing the project KEKs in the HSM? | 20:58 |
| rm_work | you can't say "the HSM has limited space, so you can't store a trivially small association" but also say "the HSM has more than enough space to store very large Certs and Intermediate Lists" | 20:58 |
| redrobot | alee_ the proposed kmip implementation would stuff the association into a password and store it in the device | 20:59 |
| redrobot | alee_ *cert_manager impl for kmip that is | 20:59 |
| rm_work | yes, which is negligible in size to the actual data being stored | 21:00 |
| alee_ | redrobot, oh - I didn't see that - but yeah - thats totally whacked .. | 21:00 |
| rm_work | the cert alone is 10x the size of the association | 21:00 |
| rm_work | or more | 21:00 |
| redrobot | rm_work yes, but it would be storing objects in the device that don' belong there | 21:00 |
| alee_ | rm_work, why does the association need to be stored as a password? | 21:00 |
| rm_work | alee_: it's just an example | 21:01 |
| rm_work | since people keep saying it isn't possible | 21:01 |
| rm_work | redrobot: according to you and others, certs don't belong there either | 21:01 |
| rm_work | since they aren't secret data | 21:01 |
| alee_ | rm_work, see my last post on the CR | 21:02 |
| *** silos has left #openstack-barbican | 21:02 | |
| alee_ | rm_work, if you want to say that this is an extension to the initial vision of castellan and that therefore kmip devices need not implement it, then that makes sense to me. | 21:02 |
| rm_work | sure | 21:03 |
| rm_work | i think that's valid | 21:03 |
| alee_ | rm_work, if you are trying to shoehorn something like kmip to implement it- then that makes no sense to me | 21:03 |
| rm_work | as i have said here before, whether or not there is a KMIP implementation is a little bit beyond the point | 21:03 |
| redrobot | well, there has to be some other non-barbican implementation for this to make sense for Castellan | 21:03 |
| rm_work | redrobot: there could practically be two *barbican* implementations | 21:04 |
| rm_work | in fact since secrets support metadata *currently*, i could make another one right now | 21:04 |
| redrobot | rm_work but your concern is deployments of lbass without barbican, right? | 21:04 |
| rm_work | that doesn't use containers | 21:04 |
| alee_ | rm_work, well the point is that you are trying to expand the original vision of castellan - and that needs to be spelled out. | 21:04 |
| rm_work | alee_: the original vision of Castellan that *I* remember did include certificates >_< | 21:05 |
| rm_work | alee_: so that is where we get a little bit lost | 21:05 |
| rm_work | but yes | 21:05 |
| redrobot | castellan does include certs | 21:05 |
| alee_ | rm_work, maybe but its not what evolved as the vision of castellan | 21:05 |
| alee_ | redrobot, really? where? | 21:05 |
| rm_work | technically there is a certificate object now | 21:05 |
| rm_work | though humorously enough the barbican implementation doesn't support it :P | 21:06 |
| redrobot | https://github.com/openstack/castellan/blob/master/castellan/common/objects/certificate.py#L30 | 21:06 |
| redrobot | alee_ ^^ | 21:06 |
| alee_ | redrobot, and where is this used? | 21:07 |
| rm_work | though realistically it's this: https://github.com/openstack/castellan/blob/master/castellan/common/objects/x_509.py | 21:07 |
| rm_work | which is the only current implementation of Certificate | 21:07 |
| rm_work | also the only one I can think of -- aren't certificates exclusively x509? | 21:07 |
| redrobot | rm_work gpg keys are technically certs as well, I think | 21:08 |
| rm_work | lol | 21:08 |
| alee_ | yes -- so this is a little redundant/confusing to say the least | 21:08 |
| rm_work | i am not really sure why that was abstracted as an additional layer | 21:09 |
| rm_work | but you'll note that the CertManager returns a CertificateBundle which *includes* Certificate and PrivateKey and Passphrase classed objects | 21:09 |
| rm_work | if you look at either implementation I added | 21:10 |
| alee_ | rm_work, I agree that the interface is useful. I do think that you attempting to create a kmip version confuses things. | 21:10 |
| rm_work | heh | 21:10 |
| rm_work | it's just an example | 21:10 |
| rm_work | and it's not KMIPCertManager | 21:10 |
| rm_work | it's GenericCertManager | 21:10 |
| rm_work | would work with LDAP or others too :P | 21:10 |
| alee_ | rm_work, yes and not a good one because it implies that something like KMIP would be required to implement this. | 21:11 |
| rm_work | i think you're reading a bit much into one implementation existing | 21:12 |
| rm_work | like it precludes others somehow? | 21:12 |
| rm_work | but that's fine | 21:12 |
| alee_ | rm_work, no - I'm just making the point that this is new and that it expands the perceived definition of castellan | 21:13 |
| alee_ | and that there is really only one implementation right now | 21:13 |
| alee_ | which would be barbican | 21:13 |
| rm_work | maybe i misunderstood -- what do you mean "it implies something like KMIP would be required" | 21:13 |
| alee_ | and so the question would be -- if there is only one real implementation of this -- why should it reside in castellan as opposed to barbican client | 21:14 |
| alee_ | ? | 21:14 |
| redrobot | the answer is that lbass doesn't want a hard barbican dependency | 21:15 |
| redrobot | but bundling certs with keys is a barbican feature | 21:15 |
| rm_work | redrobot: and an anything else feature >_> | 21:15 |
| rm_work | see: PKCS12 | 21:15 |
| rm_work | the association of "bundling certs with keys" with "barbican feature" is absurd to me | 21:16 |
| redrobot | rm_work the kmip protocol itself does not bundle certs | 21:16 |
| rm_work | no, but the concept of bundling certs with keys is a common one | 21:16 |
| alee_ | redrobot, why is that relevant? | 21:16 |
| rm_work | barbican didn't invent the idea, it just decided to implement it because it was already such a common idea :P | 21:17 |
| redrobot | alee_ trying to convince rm_work that bundling is not an "anything else" feature | 21:17 |
| rm_work | in fact if you think back a bit, LBaaS was the driving factor for you even having Typed Containers originally | 21:17 |
| rm_work | IIRC we were the first to ask for them and CertContainer was the first to exist | 21:17 |
| alee_ | rm_work, if its a common idea, I'm sure you can find a service that creates pkcs12 somewhere .. | 21:18 |
| redrobot | they're mostly used by Microsoft | 21:18 |
| rm_work | the idea is that they are used together | 21:18 |
| rm_work | they're a logical grouping | 21:18 |
| rm_work | PKCS12 is just the existing proof of that | 21:18 |
| rm_work | it's also "one implementation" | 21:18 |
| alee_ | redrobot, the idea of having some object that contains certs and keys has been around for awhile | 21:18 |
| redrobot | yeah, but I don't know of any key store that stores them as a bundle | 21:19 |
| redrobot | which is where we're all getting stuck on this | 21:19 |
| rm_work | redrobot: I look at that as a deficiency that we are in a position to resolve O_o | 21:20 |
| rm_work | not a blocker | 21:20 |
| rm_work | at some point nothing did anything, until someone decided it needed to do something, and made it so | 21:20 |
| rm_work | maybe the objection is that I'm taking a middle-out approach instead of bottom-up or top-down | 21:21 |
| alee_ | rm_work, redrobot I have to go. please add comments to the CR. I think we are making progress precisely because this is all finally being written down. | 21:21 |
| redrobot | yeah, i have to get going here pretty soon too. | 21:22 |
| rm_work | same | 21:22 |
| * alee_ thinks rm_work should have written a formal spec long ago. | 21:22 | |
| rm_work | I think I suffer from "it is so obvious in my head that how could it need a written spec" syndrome | 21:23 |
| rm_work | i can't even imagine where to start | 21:23 |
| rm_work | but you are probably correct | 21:23 |
| alee_ | that perhaps is precisely the problem .. | 21:23 |
| rm_work | maybe you could help me get a spec started for this? :P | 21:24 |
| rm_work | if nothing else it'd be more productive use of time than just arguing about it constantly :) | 21:24 |
| alee_ | I think thats exactly what I did in asking questions on the CR :/ | 21:24 |
| rm_work | heh | 21:24 |
| rm_work | true | 21:24 |
| alee_ | redrobot, so yeah please comment on the CR | 21:25 |
| redrobot | alee_ will do | 21:25 |
| *** alee_ is now known as alee_going_home | 21:26 | |
| *** tkelsey has joined #openstack-barbican | 21:27 | |
| *** tkelsey has quit IRC | 21:31 | |
| *** alee_going_home has quit IRC | 21:32 | |
| *** lisaclark1 has joined #openstack-barbican | 21:38 | |
| *** gyee has joined #openstack-barbican | 21:42 | |
| *** lisaclark1 has quit IRC | 21:43 | |
| *** lisaclark1 has joined #openstack-barbican | 21:45 | |
| *** lisaclark1 has quit IRC | 21:49 | |
| *** SheenaG has quit IRC | 21:52 | |
| *** lisaclark1 has joined #openstack-barbican | 21:53 | |
| *** lisaclark1 has quit IRC | 21:59 | |
| *** alee_ has joined #openstack-barbican | 22:02 | |
| *** morgan_302 has quit IRC | 22:04 | |
| *** morganfainberg has joined #openstack-barbican | 22:07 | |
| *** gyee is now known as gyee_500 | 22:12 | |
| *** SheenaG has joined #openstack-barbican | 22:13 | |
| *** xaeth is now known as xaeth_afk | 22:20 | |
| *** dimtruck is now known as zz_dimtruck | 22:21 | |
| *** vivek-ebay has joined #openstack-barbican | 22:26 | |
| *** SheenaG has quit IRC | 22:33 | |
| *** jamielennox|away is now known as jamielennox | 22:33 | |
| *** vivek-ebay has quit IRC | 22:46 | |
| *** vivek-ebay has joined #openstack-barbican | 22:46 | |
| *** pglass has quit IRC | 22:47 | |
| *** spotz is now known as spotz_zzz | 22:51 | |
| *** zz_dimtruck is now known as dimtruck | 22:52 | |
| *** morganfainberg is now known as morgan_404 | 22:57 | |
| *** woodster_ has quit IRC | 23:00 | |
| *** dimtruck is now known as zz_dimtruck | 23:04 | |
| *** jamielennox is now known as jamielennox|away | 23:18 | |
| *** zz_dimtruck is now known as dimtruck | 23:22 | |
| *** tkelsey has joined #openstack-barbican | 23:28 | |
| *** dimtruck is now known as zz_dimtruck | 23:32 | |
| *** tkelsey has quit IRC | 23:32 | |
| *** jamielennox|away is now known as jamielennox | 23:47 | |
| *** zz_dimtruck is now known as dimtruck | 23:54 | |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!