Tuesday, 2014-12-09

openstackgerritJohn Wood proposed openstack/barbican: Fix diff-cover gate broken by parent CR  https://review.openstack.org/13989400:10
*** stanzi has joined #openstack-barbican00:34
*** crc32 has quit IRC00:58
*** gyee has quit IRC01:19
greghaynesalee_: Left you a comment on your cert order spec01:32
*** ryanpetrello has joined #openstack-barbican01:45
*** stanzi has quit IRC01:45
*** zz_dimtruck is now known as dimtruck01:49
*** stanzi has joined #openstack-barbican01:53
*** ryanpetrello has quit IRC02:10
*** ayoung has joined #openstack-barbican02:17
*** dave-mccowan_ has joined #openstack-barbican03:19
*** dave-mccowan has quit IRC03:22
*** dave-mccowan_ is now known as dave-mccowan03:22
*** david-lyle is now known as david-lyle_afk03:24
*** ryanpetrello has joined #openstack-barbican03:27
*** kebray has joined #openstack-barbican03:32
*** dave-mccowan_ has joined #openstack-barbican03:48
*** dave-mccowan has quit IRC03:50
*** dave-mccowan_ is now known as dave-mccowan03:50
*** kebray has quit IRC03:51
*** kebray has joined #openstack-barbican04:00
*** kebray has quit IRC04:00
*** kebray has joined #openstack-barbican04:01
*** ryanpetrello has quit IRC04:02
*** kebray has quit IRC04:16
*** kebray has joined #openstack-barbican04:18
*** kebray has quit IRC04:18
*** stanzi has quit IRC04:23
*** stanzi has joined #openstack-barbican04:27
*** dave-mccowan has quit IRC04:59
*** dimtruck is now known as zz_dimtruck05:22
*** stanzi has quit IRC05:48
*** stanzi has joined #openstack-barbican05:54
openstackgerritOpenStack Proposal Bot proposed openstack/barbican: Imported Translations from Transifex  https://review.openstack.org/14024206:12
*** stanzi has quit IRC06:24
openstackgerritMerged openstack/barbican: Dont set debug and verbose as our example  https://review.openstack.org/14014006:33
*** russellb has quit IRC06:43
*** russellb has joined #openstack-barbican06:44
*** tkelsey has joined #openstack-barbican07:20
*** tkelsey has quit IRC07:24
*** xianghui has joined #openstack-barbican08:02
*** darrenmoffat has quit IRC08:31
*** darrenmoffat has joined #openstack-barbican08:36
*** tkelsey has joined #openstack-barbican09:22
*** tkelsey has quit IRC09:26
*** tkelsey has joined #openstack-barbican09:52
*** woodster_ has quit IRC10:30
*** tkelsey has quit IRC11:39
*** jamielennox is now known as jamielennox|away12:29
*** xianghui has quit IRC12:41
*** dave-mccowan has joined #openstack-barbican12:48
*** xianghui has joined #openstack-barbican13:08
*** xianghui has quit IRC13:14
*** dave-mccowan has quit IRC13:17
*** dave-mccowan has joined #openstack-barbican13:18
*** alee_ has quit IRC13:35
*** woodster_ has joined #openstack-barbican13:48
openstackgerritMerged openstack/kite: Workflow documentation is now in infra-manual  https://review.openstack.org/13933513:56
openstackgerritMerged openstack/python-kiteclient: Workflow documentation is now in infra-manual  https://review.openstack.org/13937813:58
*** SheenaG1 has joined #openstack-barbican14:08
*** nkinder has quit IRC14:11
openstackgerritMerged openstack/barbican: Imported Translations from Transifex  https://review.openstack.org/14024214:11
*** dave-mccowan has quit IRC14:14
*** dave-mccowan has joined #openstack-barbican14:15
*** dave-mccowan_ has joined #openstack-barbican14:22
*** dave-mccowan has quit IRC14:25
*** dave-mccowan_ is now known as dave-mccowan14:25
*** rellerreller has joined #openstack-barbican14:26
*** ryanpetrello has joined #openstack-barbican14:26
*** JeffF has quit IRC14:33
*** stanzi has joined #openstack-barbican14:43
*** alee_ has joined #openstack-barbican14:45
*** bdpayne has joined #openstack-barbican14:53
openstackgerritRobert Clark proposed openstack/barbican: Adding client certificates to connection credentials  https://review.openstack.org/13521714:55
*** zz_dimtruck is now known as dimtruck14:56
*** stanzi has quit IRC14:57
*** ametts has joined #openstack-barbican15:02
*** nkinder has joined #openstack-barbican15:02
*** kebray has joined #openstack-barbican15:18
*** kebray has quit IRC15:28
*** JeffF has joined #openstack-barbican15:29
openstackgerritRobert Clark proposed openstack/barbican: Adding client certificates to connection credentials  https://review.openstack.org/13521715:33
*** kgriffs|afk is now known as kgriffs15:48
*** ryanpetrello has quit IRC15:49
*** kebray has joined #openstack-barbican15:56
*** kebray has quit IRC15:56
alee_woodster_, greghaynes - responded to your comments16:11
*** kgriffs is now known as kgriffs|afk16:12
*** lordbyron8201 has joined #openstack-barbican16:22
*** stanzi has joined #openstack-barbican16:25
openstackgerritRobert Clark proposed openstack/barbican: Adding client certificates to connection credentials  https://review.openstack.org/13521716:30
*** ryanpetrello has joined #openstack-barbican16:30
*** lordbyron8201 has quit IRC16:37
*** ryanpetrello has quit IRC16:42
*** ayoung has quit IRC16:44
*** ayoung has joined #openstack-barbican16:44
*** stanzi has quit IRC16:46
*** gyee has joined #openstack-barbican16:47
openstackgerritDouglas Mendizábal proposed openstack/barbican: Remove version from endpoints in catalog  https://review.openstack.org/12786516:50
*** elmiko has joined #openstack-barbican17:00
*** lordbyron8201 has joined #openstack-barbican17:11
*** ryanpetrello has joined #openstack-barbican17:13
elmikois there a trick to running the tox tests locally?17:15
elmikoi'm seeing a lot of errors coming out of test_kmip and another one17:15
redrobotelmiko maybe try rebuilding the tox environments?  I haven't had any problems running tox.17:20
elmikoredrobot: k, i'll give it a shot17:20
*** alpha_ori has quit IRC17:23
*** alpha_ori has joined #openstack-barbican17:25
greghaynesalee_: ok, responded17:27
alee_greghaynes, thanks looking17:27
greghaynesalee_: 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
greghayneser, set of patches17:28
*** ayoung is now known as ayoung-lunch17: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
greghaynesYep, 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 properties17:38
alee_greghaynes, if the docs indicate that the "metadata" is plugin specific - then that should change because we are changing the contract17:38
elmikoredrobot: 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 interface17:40
alee_(cases 1,2,3)17:40
alee_and one in which the plugin defines the interface17:40
alee_(case 4)17:40
alee_there is a separate spec for discovery/validation of case 417:40
alee_https://review.openstack.org/12937717:41
alee_greghaynes, its a question of who owns and defines the interface17:41
greghaynesYes, exactly17:41
greghaynesIm not sure what value the metadata field provides if its not plugin specific then17:42
openstackgerritJohn Wood proposed openstack/barbican: Fix diff-cover gate broken by parent CR  https://review.openstack.org/13989417:42
greghaynesseems like its now just "stuff that may or may not be used by the core and is sent to the plugin"17:42
redrobotelmiko 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
greghaynesyep, 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 beforehand17:44
alee_for cases 1,2,3 we can do validation in barbican-core17:44
alee_so that the plugins don't have to do it.17:44
rellerrellerelmiko kaitlin worked on the KMIP plugin17:45
alee_for case 3 especially, there is logic that needs to be written17:45
rellerrellerI will ping her to get online17:45
alee_to get the public key and generate a csr etc.17:45
greghaynesalee_: a similar question, what if a plugin only implements the cmc api?17:45
alee_that would be very hard to do in the plugin17:45
greghaynesalee_: who does the validation of the metadata properties in that case?17:45
alee_greghaynes, well cmc api is case 1,217:46
alee_greghaynes, barbican-core does the validation17:46
*** kaitlin-farr has joined #openstack-barbican17:46
rellerrellerelmiko kaitlin-farr is the one who wrote the KMIP plugin17:47
kaitlin-farrHi elmiko17:47
rellerrellerShe should be able to answer your questions. Is anyone else having problems running the tox tests?17:47
greghaynesalee_: yes, so one thought I had for the snakeoil pluign is to just implement case 1,2 as the default metadata properties17:47
kaitlin-farrSorry elmiko, you'll have to catch me up, I missed the previous conversation17:47
redrobotkaitlin-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
elmikokaitlin-farr: hi17:48
greghaynesalee_: seems like if we let core do the validation, then we are saying you must always specify a request_type for that plugin17:48
alee_greghaynes, your supports() method will be used to ensure your plugin is not called for case 417:48
elmikokaitlin-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
elmikojust curious if i missed something in setup17:49
alee_greghaynes, yeah  there must always be a request_type17:49
alee_why is that a problem?17:49
greghaynesits 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,217:50
greghaynesI 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 it17:51
greghaynesjust wanted to bring up the point :)17:51
kaitlin-farrelmiko, one moment, I am looking it over.  So far I'm not able to reproduce it :(17:52
*** ryanpetrello has quit IRC17: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 me17:52
elmikokaitlin-farr: doh! maybe it's just something on my end then.17:52
alee_where it can17:52
greghaynesalee_: well all you care about as a plugin writer is that you dont have to reimplement the validation every time17:53
greghaynesalee_: and that could be done by a decorator or inheritence just as easily17:53
alee_greghaynes, ideally I dont even have to think about it.17:53
greghaynesyep17:53
kaitlin-farrelmiko you mentioned it was a fresh install?  did you modify the config file?17:53
elmikokaitlin-farr: i have mods in /etc/barbican but not in the local etc17:54
*** ryanpetrello has joined #openstack-barbican17:54
alee_greghaynes, and remember that case 3 requires code that can only be done in barbican-core17:54
alee_ie. getting the secret, generating the csr etc.17:54
alee_thats not something I want to rewrite in the plugin17:54
greghaynesAh, that is a good point17:55
greghaynesSo long term im totally convinced this will end up as properties in the wsme/heat resources style.. but this seems good for now17: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 +117:57
greghaynesyep17:58
alee_cool thanks17:58
*** david-lyle_afk is now known as david-lyle17:58
alee_woodster_, ?17:59
kaitlin-farrelmiko, do you have a value defined for ca_certs in your /etc config file?18:02
elmikokaitlin-farr: nothing beyond the default value18:03
elmikokaitlin-farr: i just removed /etc/barbican and reran the tests, same results18:06
kaitlin-farroh bummer18:06
kaitlin-farrelmiko, I've got to run to another meeting soon, but let me try one last thing18:08
*** jamielennox|away is now known as jamielennox18:09
elmikokaitlin-farr: k, i'll try pushing my change up to reviews.o.o, hopefully it will pass there =)18:09
*** bdpayne has quit IRC18:11
kaitlin-farrhmm 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 there18:13
*** kaitlin-farr has quit IRC18:14
*** jamielennox is now known as jamielennox|away18:16
openstackgerritMichael McCune proposed openstack/barbican: Changing ModelBase.save to correct updated time  https://review.openstack.org/14042318:18
*** paul_glass has joined #openstack-barbican18:42
*** bdpayne has joined #openstack-barbican19:00
*** bdpayne has quit IRC19:07
*** lisaclark_ has left #openstack-barbican19:12
woodster_alee, are you there?19:19
alee_woodster_, yup19:34
alee_woodster_, you ready to approve the cert api spec?19:35
*** kebray has joined #openstack-barbican19: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 look19: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 now19:44
alee_ok19:45
alee_woodster_, rellerreller , rm_work so -- going through the comments on https://review.openstack.org/#/c/129048/3/specs/kilo/identify-cas.rst,cm19:53
*** paul_glass has quit IRC19:54
alee_woodster_, rellerreller, rm_work - it seems the consensus is to have two tables ProjectPreferredCA and ProjectCA, right?19:55
rellerrelleralee_ I'm cool with that19:55
alee_woodster_, rellerreller , rm_work  not sure what the consensus on ca metadata is ..19:55
*** paul_glass has joined #openstack-barbican19: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 IRC19:57
*** ametts has quit IRC19:57
woodster_alee_ that's all correct19: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 time20:00
*** ayoung-lunch is now known as ayoung20:00
alee_which is why I suggested the metadata approach20:00
*** paul_glass has quit IRC20: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 with20:02
redrobotalee_ 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_ids20:05
alee_and one to make the request20:05
alee_redrobot, knowing the ca_id is useful for the client only if they want to do something special20:06
*** gyee has quit IRC20:06
alee_if they are using the common api - then they should not care.20:06
redrobotInitially you would need two calls, but you could potentially cache the ca_id after that.20:06
redrobotI 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 either20: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 outset20: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_workyeah, personally am in favor of both of the things i proposed (hopefully that's obvious) :P20:10
rm_workaren't you guys in sprint planning? >_>20:11
redrobotrm_work yep... and I'm so bored I'm looking at BPs :-P20:12
*** stanzi has joined #openstack-barbican20:12
alee_redrobot, awesome - you can be the decider on the ca_metadata vs. columns in ca table debate ..20:14
greghaynesis the pki module used for dogtag not the same pki module thats on pypi20:15
greghaynesI think its not20:15
alee_greghaynes, its not the same.20:15
greghayneswow20:15
greghaynesthat is *amazing*20:15
alee_the dogtag module is not in pypi right now ..20:15
alee_what is?20:15
greghaynesat first I was amazed that they chose the name pki for that module20:16
greghaynes(they being dogtag)20:16
greghaynesbut 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 somesuch20:18
greghaynes++ to that20:18
rellerrelleralee_ sorry I had to step out for a second because my project lead on another project stepped in my office20:32
*** joel-coffman has joined #openstack-barbican20:33
rellerrelleralee_ joel-coffman has PhD in databases. He has thoughts on CA metadata.20:33
joel-coffmancan you describe the scenario and proposed designs?20:34
rellerrellerjoel-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 | VALUE20:34
alee_joel-coffman, or the third option is just a bunch of columns20:35
joel-coffmanokay20:35
joel-coffmanthe second choice is typically preferred for arbitrary (e.g., user specified) metadata20:35
joel-coffmanthe key value pairs aren't limited in any way -- that is, you can have as many as you want20:36
*** kebray has quit IRC20:36
joel-coffmanJSON strings are potentially limited by the size of the column -- e.g., VARCHAR(255)20:36
*** kebray has joined #openstack-barbican20: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 needed20:37
alee_or perhaps refreshed periodically20:38
joel-coffmanit's also considerably more expensive to update a single key-value pair when the information is stored in a JSON encoding20:38
joel-coffmanseparate columns in the CA table are good if all the keys (name, description, subject key identifier) are known in advance20:39
alee_joel-coffman, yeah -- my inclination is towards option 2 (metadata table) or option 3 (bunch of columns)20:39
joel-coffmanotherwise, a separate table is generally preferrable20:39
greghaynesalee_: Hey, where does the source for that dogtag pki module live?20:40
joel-coffmanseems the most reasonable to me20:40
greghaynesnot having the easiest time finding it20: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 metadata20:40
joel-coffmanthe other issue to consider is if the columns would be common to *all* CAs20:41
joel-coffmanyou don't want to have a bunch of NULL values in the table because the attributes aren't relevant20:41
alee_joel-coffman, right -- potentially there could be null values for a given ca.20:41
joel-coffmanyeah, that should be avoided if possible20:42
alee_joel-coffman, perhaps you can comment in the spec?20:42
joel-coffmanlink?20:42
*** crc32 has joined #openstack-barbican20:42
alee_https://review.openstack.org/#/c/129048/3/specs/kilo/identify-cas.rst,cm20:43
greghaynesI think the general term for what youre describing with the ID, key, val is called entity-attribute-value schema, FYI20:43
greghaynesand its a pretty common pattern :)20:43
alee_greghaynes, https://git.fedorahosted.org/cgit/pki.git/20:44
greghaynesty20:44
alee_greghaynes, feel free to comment on the spec too.20:44
joel-coffmanthanks, I'll review the spec (probably tomorrow) and make additional comments20:45
alee_joel-coffman, cool - thanks20:46
alee_greghaynes, https://git.fedorahosted.org/cgit/pki.git/tree/base/common/python/pki20:46
rellerrellerjoel-coffman thanks!20:46
joel-coffmanno problem20:46
joel-coffmanhadn't come to my attention before now20:46
*** lordbyron8201 has joined #openstack-barbican20:55
*** jamielennox|away is now known as jamielennox20:59
greghaynesalee_: 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
greghaynesto actually get the sig from a CA21:05
greghaynesits ok21:06
alee_redrobot, whats latest about midcycle?21:07
redrobotalee_ hoping for a definitive answer from finance before the next Monday meeting21:08
alee_redrobot, ok thanks21:08
redrobotalee_ currently playing email tag with Geekdom SF to try to secure the space...21:08
*** kebray has quit IRC21:11
openstackgerritJohn Wood proposed openstack/barbican: Fix diff-cover gate broken by parent CR  https://review.openstack.org/13989421:13
*** joel-coffman has quit IRC21:15
*** kebray has joined #openstack-barbican21:17
openstackgerritJohn Wood proposed openstack/barbican: Fix diff-cover gate broken by parent CR  https://review.openstack.org/13989421:35
*** dave-mccowan_ has joined #openstack-barbican21:44
*** dave-mccowan has quit IRC21:47
*** dave-mccowan_ is now known as dave-mccowan21:47
*** paul_glass has joined #openstack-barbican21:50
*** dave-mccowan_ has joined #openstack-barbican21:54
*** dave-mccowan has quit IRC21:56
*** dave-mccowan_ is now known as dave-mccowan21:56
*** ryanpetrello has quit IRC22:05
*** stanzi has quit IRC22:17
*** alee_ has quit IRC22:27
*** ryanpetrello has joined #openstack-barbican22:37
*** ryanpetrello has quit IRC22:44
*** ryanpetrello has joined #openstack-barbican22:46
*** rellerreller has quit IRC22:47
*** nkinder has quit IRC23:04
*** jamielennox is now known as jamielennox|away23:05
*** paul_glass has quit IRC23:11
*** mikedillion has joined #openstack-barbican23:16
*** mikedillion has quit IRC23:23
*** mikedillion has joined #openstack-barbican23:23
*** jamielennox|away is now known as jamielennox23:24
*** gyee has joined #openstack-barbican23:33
*** JeffF has left #openstack-barbican23:50
*** dimtruck is now known as zz_dimtruck23:53
*** crc32 has quit IRC23:59

Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!