| openstackgerrit | John Wood proposed openstack/barbican: Fix diff-cover gate broken by parent CR https://review.openstack.org/139894 | 00:10 |
|---|---|---|
| *** stanzi has joined #openstack-barbican | 00:34 | |
| *** crc32 has quit IRC | 00:58 | |
| *** gyee has quit IRC | 01:19 | |
| greghaynes | alee_: Left you a comment on your cert order spec | 01:32 |
| *** ryanpetrello has joined #openstack-barbican | 01:45 | |
| *** stanzi has quit IRC | 01:45 | |
| *** zz_dimtruck is now known as dimtruck | 01:49 | |
| *** stanzi has joined #openstack-barbican | 01:53 | |
| *** ryanpetrello has quit IRC | 02:10 | |
| *** ayoung has joined #openstack-barbican | 02:17 | |
| *** dave-mccowan_ has joined #openstack-barbican | 03:19 | |
| *** dave-mccowan has quit IRC | 03:22 | |
| *** dave-mccowan_ is now known as dave-mccowan | 03:22 | |
| *** david-lyle is now known as david-lyle_afk | 03:24 | |
| *** ryanpetrello has joined #openstack-barbican | 03:27 | |
| *** kebray has joined #openstack-barbican | 03:32 | |
| *** dave-mccowan_ has joined #openstack-barbican | 03:48 | |
| *** dave-mccowan has quit IRC | 03:50 | |
| *** dave-mccowan_ is now known as dave-mccowan | 03:50 | |
| *** kebray has quit IRC | 03:51 | |
| *** kebray has joined #openstack-barbican | 04:00 | |
| *** kebray has quit IRC | 04:00 | |
| *** kebray has joined #openstack-barbican | 04:01 | |
| *** ryanpetrello has quit IRC | 04:02 | |
| *** kebray has quit IRC | 04:16 | |
| *** kebray has joined #openstack-barbican | 04:18 | |
| *** kebray has quit IRC | 04:18 | |
| *** stanzi has quit IRC | 04:23 | |
| *** stanzi has joined #openstack-barbican | 04:27 | |
| *** dave-mccowan has quit IRC | 04:59 | |
| *** dimtruck is now known as zz_dimtruck | 05:22 | |
| *** stanzi has quit IRC | 05:48 | |
| *** stanzi has joined #openstack-barbican | 05:54 | |
| openstackgerrit | OpenStack Proposal Bot proposed openstack/barbican: Imported Translations from Transifex https://review.openstack.org/140242 | 06:12 |
| *** stanzi has quit IRC | 06:24 | |
| openstackgerrit | Merged openstack/barbican: Dont set debug and verbose as our example https://review.openstack.org/140140 | 06:33 |
| *** russellb has quit IRC | 06:43 | |
| *** russellb has joined #openstack-barbican | 06:44 | |
| *** tkelsey has joined #openstack-barbican | 07:20 | |
| *** tkelsey has quit IRC | 07:24 | |
| *** xianghui has joined #openstack-barbican | 08:02 | |
| *** darrenmoffat has quit IRC | 08:31 | |
| *** darrenmoffat has joined #openstack-barbican | 08:36 | |
| *** tkelsey has joined #openstack-barbican | 09:22 | |
| *** tkelsey has quit IRC | 09:26 | |
| *** tkelsey has joined #openstack-barbican | 09:52 | |
| *** woodster_ has quit IRC | 10:30 | |
| *** tkelsey has quit IRC | 11:39 | |
| *** jamielennox is now known as jamielennox|away | 12:29 | |
| *** xianghui has quit IRC | 12:41 | |
| *** dave-mccowan has joined #openstack-barbican | 12:48 | |
| *** xianghui has joined #openstack-barbican | 13:08 | |
| *** xianghui has quit IRC | 13:14 | |
| *** dave-mccowan has quit IRC | 13:17 | |
| *** dave-mccowan has joined #openstack-barbican | 13:18 | |
| *** alee_ has quit IRC | 13:35 | |
| *** woodster_ has joined #openstack-barbican | 13:48 | |
| openstackgerrit | Merged openstack/kite: Workflow documentation is now in infra-manual https://review.openstack.org/139335 | 13:56 |
| openstackgerrit | Merged openstack/python-kiteclient: Workflow documentation is now in infra-manual https://review.openstack.org/139378 | 13:58 |
| *** SheenaG1 has joined #openstack-barbican | 14:08 | |
| *** nkinder has quit IRC | 14:11 | |
| openstackgerrit | Merged openstack/barbican: Imported Translations from Transifex https://review.openstack.org/140242 | 14:11 |
| *** dave-mccowan has quit IRC | 14:14 | |
| *** dave-mccowan has joined #openstack-barbican | 14:15 | |
| *** dave-mccowan_ has joined #openstack-barbican | 14:22 | |
| *** dave-mccowan has quit IRC | 14:25 | |
| *** dave-mccowan_ is now known as dave-mccowan | 14:25 | |
| *** rellerreller has joined #openstack-barbican | 14:26 | |
| *** ryanpetrello has joined #openstack-barbican | 14:26 | |
| *** JeffF has quit IRC | 14:33 | |
| *** stanzi has joined #openstack-barbican | 14:43 | |
| *** alee_ has joined #openstack-barbican | 14:45 | |
| *** bdpayne has joined #openstack-barbican | 14:53 | |
| openstackgerrit | Robert Clark proposed openstack/barbican: Adding client certificates to connection credentials https://review.openstack.org/135217 | 14:55 |
| *** zz_dimtruck is now known as dimtruck | 14:56 | |
| *** stanzi has quit IRC | 14:57 | |
| *** ametts has joined #openstack-barbican | 15:02 | |
| *** nkinder has joined #openstack-barbican | 15:02 | |
| *** kebray has joined #openstack-barbican | 15:18 | |
| *** kebray has quit IRC | 15:28 | |
| *** JeffF has joined #openstack-barbican | 15:29 | |
| openstackgerrit | Robert Clark proposed openstack/barbican: Adding client certificates to connection credentials https://review.openstack.org/135217 | 15:33 |
| *** kgriffs|afk is now known as kgriffs | 15:48 | |
| *** ryanpetrello has quit IRC | 15:49 | |
| *** kebray has joined #openstack-barbican | 15:56 | |
| *** kebray has quit IRC | 15:56 | |
| alee_ | woodster_, greghaynes - responded to your comments | 16:11 |
| *** kgriffs is now known as kgriffs|afk | 16:12 | |
| *** lordbyron8201 has joined #openstack-barbican | 16:22 | |
| *** stanzi has joined #openstack-barbican | 16:25 | |
| openstackgerrit | Robert Clark proposed openstack/barbican: Adding client certificates to connection credentials https://review.openstack.org/135217 | 16:30 |
| *** ryanpetrello has joined #openstack-barbican | 16:30 | |
| *** lordbyron8201 has quit IRC | 16:37 | |
| *** ryanpetrello has quit IRC | 16:42 | |
| *** ayoung has quit IRC | 16:44 | |
| *** ayoung has joined #openstack-barbican | 16:44 | |
| *** stanzi has quit IRC | 16:46 | |
| *** gyee has joined #openstack-barbican | 16:47 | |
| openstackgerrit | Douglas Mendizábal proposed openstack/barbican: Remove version from endpoints in catalog https://review.openstack.org/127865 | 16:50 |
| *** elmiko has joined #openstack-barbican | 17:00 | |
| *** lordbyron8201 has joined #openstack-barbican | 17:11 | |
| *** ryanpetrello has joined #openstack-barbican | 17:13 | |
| elmiko | is there a trick to running the tox tests locally? | 17:15 |
| elmiko | i'm seeing a lot of errors coming out of test_kmip and another one | 17:15 |
| redrobot | elmiko maybe try rebuilding the tox environments? I haven't had any problems running tox. | 17:20 |
| elmiko | redrobot: k, i'll give it a shot | 17:20 |
| *** alpha_ori has quit IRC | 17:23 | |
| *** alpha_ori has joined #openstack-barbican | 17:25 | |
| greghaynes | alee_: ok, responded | 17:27 |
| alee_ | greghaynes, thanks looking | 17:27 |
| greghaynes | alee_: If its still contetious we can move ahead. I dont think its *that* huge of an issue and I really want that patch :) | 17:27 |
| greghaynes | er, set of patches | 17:28 |
| *** ayoung is now known as ayoung-lunch | 17:35 | |
| alee_ | greghaynes, yeah -- I think that barbican-core needs to do the validation for the interface it defines (cases 1,2,3) and the plugin needs to do validation for the interface it defines (case 4). | 17:38 |
| greghaynes | Yep, so the way heat solved stuff like this is to just have a set of properties we import and then the core knows how to validate those properties | 17:38 |
| alee_ | greghaynes, if the docs indicate that the "metadata" is plugin specific - then that should change because we are changing the contract | 17:38 |
| elmiko | redrobot: i regen'd the tox environment, but i keep getting this error in my output http://paste.openstack.org/show/148029/ am i missing something? | 17:39 |
| alee_ | greghaynes, right but the difference is that in this case there are two different apis. | 17:39 |
| alee_ | greghaynes, one in which barbican -core defines an interface | 17:40 |
| alee_ | (cases 1,2,3) | 17:40 |
| alee_ | and one in which the plugin defines the interface | 17:40 |
| alee_ | (case 4) | 17:40 |
| alee_ | there is a separate spec for discovery/validation of case 4 | 17:40 |
| alee_ | https://review.openstack.org/129377 | 17:41 |
| alee_ | greghaynes, its a question of who owns and defines the interface | 17:41 |
| greghaynes | Yes, exactly | 17:41 |
| greghaynes | Im not sure what value the metadata field provides if its not plugin specific then | 17:42 |
| openstackgerrit | John Wood proposed openstack/barbican: Fix diff-cover gate broken by parent CR https://review.openstack.org/139894 | 17:42 |
| greghaynes | seems like its now just "stuff that may or may not be used by the core and is sent to the plugin" | 17:42 |
| redrobot | elmiko interesting... I'm not very familiar with the kmip plugin, mabye rellerreller can chime in? | 17:43 |
| alee_ | greghaynes, I think we are getting tied up in semantics .. you could rename the field to "request_fields" | 17:43 |
| greghaynes | yep, thats what I was trying to say with 'why not just pass in the whole request context' | 17:43 |
| alee_ | greghaynes, well - it is passed to the plugin .. | 17:44 |
| alee_ | but the question is what to do with it beforehand | 17:44 |
| alee_ | for cases 1,2,3 we can do validation in barbican-core | 17:44 |
| alee_ | so that the plugins don't have to do it. | 17:44 |
| rellerreller | elmiko kaitlin worked on the KMIP plugin | 17:45 |
| alee_ | for case 3 especially, there is logic that needs to be written | 17:45 |
| rellerreller | I will ping her to get online | 17:45 |
| alee_ | to get the public key and generate a csr etc. | 17:45 |
| greghaynes | alee_: a similar question, what if a plugin only implements the cmc api? | 17:45 |
| alee_ | that would be very hard to do in the plugin | 17:45 |
| greghaynes | alee_: who does the validation of the metadata properties in that case? | 17:45 |
| alee_ | greghaynes, well cmc api is case 1,2 | 17:46 |
| alee_ | greghaynes, barbican-core does the validation | 17:46 |
| *** kaitlin-farr has joined #openstack-barbican | 17:46 | |
| rellerreller | elmiko kaitlin-farr is the one who wrote the KMIP plugin | 17:47 |
| kaitlin-farr | Hi elmiko | 17:47 |
| rellerreller | She should be able to answer your questions. Is anyone else having problems running the tox tests? | 17:47 |
| greghaynes | alee_: yes, so one thought I had for the snakeoil pluign is to just implement case 1,2 as the default metadata properties | 17:47 |
| kaitlin-farr | Sorry elmiko, you'll have to catch me up, I missed the previous conversation | 17:47 |
| redrobot | kaitlin-farr hi! elmiko is seeing this error when trying to run tox. Do you have any clues as to what may be wrong? http://paste.openstack.org/show/148029/ | 17:48 |
| alee_ | greghaynes, and I think that will be just fine. | 17:48 |
| elmiko | kaitlin-farr: hi | 17:48 |
| greghaynes | alee_: seems like if we let core do the validation, then we are saying you must always specify a request_type for that plugin | 17:48 |
| alee_ | greghaynes, your supports() method will be used to ensure your plugin is not called for case 4 | 17:48 |
| elmiko | kaitlin-farr: no prob, i'm trying to run 'tox -epy27' from a fresh checkout and keep getting this error http://paste.openstack.org/show/148029/ | 17:48 |
| elmiko | just curious if i missed something in setup | 17:49 |
| alee_ | greghaynes, yeah there must always be a request_type | 17:49 |
| alee_ | why is that a problem? | 17:49 |
| greghaynes | its not, its just not beneficial either. If we instead had a common validation method for the metadata that happened in the plugin that field isnt requred and then the case 4 for this plugin would be to 'just work' but with the same properties as case 1,2 | 17:50 |
| greghaynes | I dunno, I kind of would like to see how the implementation turns out so if you want to just go for it as the spec says im fine with it | 17:51 |
| greghaynes | just wanted to bring up the point :) | 17:51 |
| kaitlin-farr | elmiko, one moment, I am looking it over. So far I'm not able to reproduce it :( | 17:52 |
| *** ryanpetrello has quit IRC | 17:52 | |
| alee_ | its a good point -- but from the point of view of having written a plugin - I'd appreciate it if barbican-core did the validation for me | 17:52 |
| elmiko | kaitlin-farr: doh! maybe it's just something on my end then. | 17:52 |
| alee_ | where it can | 17:52 |
| greghaynes | alee_: well all you care about as a plugin writer is that you dont have to reimplement the validation every time | 17:53 |
| greghaynes | alee_: and that could be done by a decorator or inheritence just as easily | 17:53 |
| alee_ | greghaynes, ideally I dont even have to think about it. | 17:53 |
| greghaynes | yep | 17:53 |
| kaitlin-farr | elmiko you mentioned it was a fresh install? did you modify the config file? | 17:53 |
| elmiko | kaitlin-farr: i have mods in /etc/barbican but not in the local etc | 17:54 |
| *** ryanpetrello has joined #openstack-barbican | 17:54 | |
| alee_ | greghaynes, and remember that case 3 requires code that can only be done in barbican-core | 17:54 |
| alee_ | ie. getting the secret, generating the csr etc. | 17:54 |
| alee_ | thats not something I want to rewrite in the plugin | 17:54 |
| greghaynes | Ah, that is a good point | 17:55 |
| greghaynes | So long term im totally convinced this will end up as properties in the wsme/heat resources style.. but this seems good for now | 17:56 |
| alee_ | greghaynes, fair enough :) | 17:56 |
| alee_ | greghaynes, If it does, the changes will be internal to barbican mostly -- but lets see how it goes. | 17:57 |
| * greghaynes making review a +1 | 17:57 | |
| greghaynes | yep | 17:58 |
| alee_ | cool thanks | 17:58 |
| *** david-lyle_afk is now known as david-lyle | 17:58 | |
| alee_ | woodster_, ? | 17:59 |
| kaitlin-farr | elmiko, do you have a value defined for ca_certs in your /etc config file? | 18:02 |
| elmiko | kaitlin-farr: nothing beyond the default value | 18:03 |
| elmiko | kaitlin-farr: i just removed /etc/barbican and reran the tests, same results | 18:06 |
| kaitlin-farr | oh bummer | 18:06 |
| kaitlin-farr | elmiko, I've got to run to another meeting soon, but let me try one last thing | 18:08 |
| *** jamielennox|away is now known as jamielennox | 18:09 | |
| elmiko | kaitlin-farr: k, i'll try pushing my change up to reviews.o.o, hopefully it will pass there =) | 18:09 |
| *** bdpayne has quit IRC | 18:11 | |
| kaitlin-farr | hmm elmiko, sorry, I'm not sure why that error is occurring for you at the moment. I'll keep an eye out for your patch though to see if the error occurs there | 18:13 |
| *** kaitlin-farr has quit IRC | 18:14 | |
| *** jamielennox is now known as jamielennox|away | 18:16 | |
| openstackgerrit | Michael McCune proposed openstack/barbican: Changing ModelBase.save to correct updated time https://review.openstack.org/140423 | 18:18 |
| *** paul_glass has joined #openstack-barbican | 18:42 | |
| *** bdpayne has joined #openstack-barbican | 19:00 | |
| *** bdpayne has quit IRC | 19:07 | |
| *** lisaclark_ has left #openstack-barbican | 19:12 | |
| woodster_ | alee, are you there? | 19:19 |
| alee_ | woodster_, yup | 19:34 |
| alee_ | woodster_, you ready to approve the cert api spec? | 19:35 |
| *** kebray has joined #openstack-barbican | 19:37 | |
| *** redrobot changes topic to "Blueprint Vidyo Hangout this Thursday December 11 at 1500 UTC https://wiki.openstack.org/wiki/Barbican/Kilo#Kilo_Blueprint_Hangout" | 19:39 | |
| woodster_ | alee_, I'll take a look at those latest comments...having a planning meeting now, but after that I'll take a look | 19:44 |
| alee_ | woodster_, sounds good. did you need me for anything? | 19:44 |
| alee_ | woodster_, going to update the other spec for comments now. | 19:44 |
| woodster_ | alee_ oh not right now | 19:44 |
| alee_ | ok | 19:45 |
| alee_ | woodster_, rellerreller , rm_work so -- going through the comments on https://review.openstack.org/#/c/129048/3/specs/kilo/identify-cas.rst,cm | 19:53 |
| *** paul_glass has quit IRC | 19:54 | |
| alee_ | woodster_, rellerreller, rm_work - it seems the consensus is to have two tables ProjectPreferredCA and ProjectCA, right? | 19:55 |
| rellerreller | alee_ I'm cool with that | 19:55 |
| alee_ | woodster_, rellerreller , rm_work not sure what the consensus on ca metadata is .. | 19:55 |
| *** paul_glass has joined #openstack-barbican | 19:56 | |
| alee_ | rellerreller seems to favor ca_metadata table, so does rm_work - I think, woodster_ seems to want to add columns to the ca_table .. | 19:57 |
| alee_ | am I capturing that right? | 19:57 |
| *** lordbyron8201 has quit IRC | 19:57 | |
| *** ametts has quit IRC | 19:57 | |
| woodster_ | alee_ that's all correct | 19:58 |
| alee_ | woodster_, rm_work , rellerreller - so I'm OK with implementing whatever you guys decide on ca_metadata .. | 19:59 |
| alee_ | woodster_, I could see more information about the ca being added over time | 20:00 |
| *** ayoung-lunch is now known as ayoung | 20:00 | |
| alee_ | which is why I suggested the metadata approach | 20:00 |
| *** paul_glass has quit IRC | 20:01 | |
| alee_ | rellerreller, rm_work ? | 20:02 |
| woodster_ | alee_ yeah, I prefer avoiding key/value tables if the attributes are mostly known/static...it is easier to debug with the database with simple tables, and one less join to mess with | 20:02 |
| redrobot | alee_ why do we need a preferred CA instead of requiring the CA to be specified every time? | 20:03 |
| alee_ | redrobot, well I think it would be nicer not to require clients to know which ca's are there. | 20:04 |
| alee_ | redrobot, otherwise doing a cert request requires two calls -- one to get the ca_ids | 20:05 |
| alee_ | and one to make the request | 20:05 |
| alee_ | redrobot, knowing the ca_id is useful for the client only if they want to do something special | 20:06 |
| *** gyee has quit IRC | 20:06 | |
| alee_ | if they are using the common api - then they should not care. | 20:06 |
| redrobot | Initially you would need two calls, but you could potentially cache the ca_id after that. | 20:06 |
| redrobot | I see the benefit, I'm just playing devil's advocate since I think it would be easier to make a first pass at this where CA is required. | 20:07 |
| alee_ | and if they are in a project and that project has been set up to use a preferred ca, then they should not need to know that either | 20:07 |
| alee_ | redrobot, I don't think its too hard to implement. | 20:07 |
| alee_ | and I don't want to force two calls on the ca at the outset | 20:08 |
| alee_ | I mean on barbican .. | 20:08 |
| alee_ | redrobot, the ca_id will be a guid generated by barbican and so will be meaningless to a user. most folks will likely never have to specify it. | 20:10 |
| rm_work | yeah, personally am in favor of both of the things i proposed (hopefully that's obvious) :P | 20:10 |
| rm_work | aren't you guys in sprint planning? >_> | 20:11 |
| redrobot | rm_work yep... and I'm so bored I'm looking at BPs :-P | 20:12 |
| *** stanzi has joined #openstack-barbican | 20:12 | |
| alee_ | redrobot, awesome - you can be the decider on the ca_metadata vs. columns in ca table debate .. | 20:14 |
| greghaynes | is the pki module used for dogtag not the same pki module thats on pypi | 20:15 |
| greghaynes | I think its not | 20:15 |
| alee_ | greghaynes, its not the same. | 20:15 |
| greghaynes | wow | 20:15 |
| greghaynes | that is *amazing* | 20:15 |
| alee_ | the dogtag module is not in pypi right now .. | 20:15 |
| alee_ | what is? | 20:15 |
| greghaynes | at first I was amazed that they chose the name pki for that module | 20:16 |
| greghaynes | (they being dogtag) | 20:16 |
| greghaynes | but the fact that pki already is taken by another module on pypi makes that even better :) | 20:16 |
| alee_ | greghaynes, well - I guess there is an advantage to being there first .. yeah, we'll get the dogtag module up there in the next month or two. Probably named dogtag-pki or somesuch | 20:18 |
| greghaynes | ++ to that | 20:18 |
| rellerreller | alee_ sorry I had to step out for a second because my project lead on another project stepped in my office | 20:32 |
| *** joel-coffman has joined #openstack-barbican | 20:33 | |
| rellerreller | alee_ joel-coffman has PhD in databases. He has thoughts on CA metadata. | 20:33 |
| joel-coffman | can you describe the scenario and proposed designs? | 20:34 |
| rellerreller | joel-coffman The question is whether the CA table should have one additional column that contains a JSON string of key-value pairs or create a new CA_METADATA table the has the columns CA_ID | KEY | VALUE | 20:34 |
| alee_ | joel-coffman, or the third option is just a bunch of columns | 20:35 |
| joel-coffman | okay | 20:35 |
| joel-coffman | the second choice is typically preferred for arbitrary (e.g., user specified) metadata | 20:35 |
| joel-coffman | the key value pairs aren't limited in any way -- that is, you can have as many as you want | 20:36 |
| *** kebray has quit IRC | 20:36 | |
| joel-coffman | JSON strings are potentially limited by the size of the column -- e.g., VARCHAR(255) | 20:36 |
| *** kebray has joined #openstack-barbican | 20:37 | |
| alee_ | joel-coffman, the data that will be stored in this table will be information about the ca -- so things like a name, description, maybe subject key identifier .. | 20:37 |
| alee_ | this data will be pretty much static - ie. loaded in from the plugin when needed | 20:37 |
| alee_ | or perhaps refreshed periodically | 20:38 |
| joel-coffman | it's also considerably more expensive to update a single key-value pair when the information is stored in a JSON encoding | 20:38 |
| joel-coffman | separate columns in the CA table are good if all the keys (name, description, subject key identifier) are known in advance | 20:39 |
| alee_ | joel-coffman, yeah -- my inclination is towards option 2 (metadata table) or option 3 (bunch of columns) | 20:39 |
| joel-coffman | otherwise, a separate table is generally preferrable | 20:39 |
| greghaynes | alee_: Hey, where does the source for that dogtag pki module live? | 20:40 |
| joel-coffman | seems the most reasonable to me | 20:40 |
| greghaynes | not having the easiest time finding it | 20:40 |
| alee_ | joel-coffman, the columns are known to some extent in advance --- but as we end up implementing this feature, we may end up needing more columns. | 20:40 |
| alee_ | which is why I suggested metadata | 20:40 |
| joel-coffman | the other issue to consider is if the columns would be common to *all* CAs | 20:41 |
| joel-coffman | you don't want to have a bunch of NULL values in the table because the attributes aren't relevant | 20:41 |
| alee_ | joel-coffman, right -- potentially there could be null values for a given ca. | 20:41 |
| joel-coffman | yeah, that should be avoided if possible | 20:42 |
| alee_ | joel-coffman, perhaps you can comment in the spec? | 20:42 |
| joel-coffman | link? | 20:42 |
| *** crc32 has joined #openstack-barbican | 20:42 | |
| alee_ | https://review.openstack.org/#/c/129048/3/specs/kilo/identify-cas.rst,cm | 20:43 |
| greghaynes | I think the general term for what youre describing with the ID, key, val is called entity-attribute-value schema, FYI | 20:43 |
| greghaynes | and its a pretty common pattern :) | 20:43 |
| alee_ | greghaynes, https://git.fedorahosted.org/cgit/pki.git/ | 20:44 |
| greghaynes | ty | 20:44 |
| alee_ | greghaynes, feel free to comment on the spec too. | 20:44 |
| joel-coffman | thanks, I'll review the spec (probably tomorrow) and make additional comments | 20:45 |
| alee_ | joel-coffman, cool - thanks | 20:46 |
| alee_ | greghaynes, https://git.fedorahosted.org/cgit/pki.git/tree/base/common/python/pki | 20:46 |
| rellerreller | joel-coffman thanks! | 20:46 |
| joel-coffman | no problem | 20:46 |
| joel-coffman | hadn't come to my attention before now | 20:46 |
| *** lordbyron8201 has joined #openstack-barbican | 20:55 | |
| *** jamielennox|away is now known as jamielennox | 20:59 | |
| greghaynes | alee_: Is there an API for doing CSR's? | 21:04 |
| alee_ | greghaynes, you mean to create one? | 21:05 |
| alee_ | greghaynes, sorry - in meeting .. | 21:05 |
| greghaynes | to actually get the sig from a CA | 21:05 |
| greghaynes | its ok | 21:06 |
| alee_ | redrobot, whats latest about midcycle? | 21:07 |
| redrobot | alee_ hoping for a definitive answer from finance before the next Monday meeting | 21:08 |
| alee_ | redrobot, ok thanks | 21:08 |
| redrobot | alee_ currently playing email tag with Geekdom SF to try to secure the space... | 21:08 |
| *** kebray has quit IRC | 21:11 | |
| openstackgerrit | John Wood proposed openstack/barbican: Fix diff-cover gate broken by parent CR https://review.openstack.org/139894 | 21:13 |
| *** joel-coffman has quit IRC | 21:15 | |
| *** kebray has joined #openstack-barbican | 21:17 | |
| openstackgerrit | John Wood proposed openstack/barbican: Fix diff-cover gate broken by parent CR https://review.openstack.org/139894 | 21:35 |
| *** dave-mccowan_ has joined #openstack-barbican | 21:44 | |
| *** dave-mccowan has quit IRC | 21:47 | |
| *** dave-mccowan_ is now known as dave-mccowan | 21:47 | |
| *** paul_glass has joined #openstack-barbican | 21:50 | |
| *** dave-mccowan_ has joined #openstack-barbican | 21:54 | |
| *** dave-mccowan has quit IRC | 21:56 | |
| *** dave-mccowan_ is now known as dave-mccowan | 21:56 | |
| *** ryanpetrello has quit IRC | 22:05 | |
| *** stanzi has quit IRC | 22:17 | |
| *** alee_ has quit IRC | 22:27 | |
| *** ryanpetrello has joined #openstack-barbican | 22:37 | |
| *** ryanpetrello has quit IRC | 22:44 | |
| *** ryanpetrello has joined #openstack-barbican | 22:46 | |
| *** rellerreller has quit IRC | 22:47 | |
| *** nkinder has quit IRC | 23:04 | |
| *** jamielennox is now known as jamielennox|away | 23:05 | |
| *** paul_glass has quit IRC | 23:11 | |
| *** mikedillion has joined #openstack-barbican | 23:16 | |
| *** mikedillion has quit IRC | 23:23 | |
| *** mikedillion has joined #openstack-barbican | 23:23 | |
| *** jamielennox|away is now known as jamielennox | 23:24 | |
| *** gyee has joined #openstack-barbican | 23:33 | |
| *** JeffF has left #openstack-barbican | 23:50 | |
| *** dimtruck is now known as zz_dimtruck | 23:53 | |
| *** crc32 has quit IRC | 23:59 | |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!