| *** kebray has joined #openstack-barbican | 00:44 | |
| *** jamielen- has joined #openstack-barbican | 00:58 | |
| *** jamielennox has quit IRC | 01:00 | |
| *** jamielen- is now known as jamielennox | 01:01 | |
| *** kebray has quit IRC | 01:08 | |
| *** jamielennox_ has joined #openstack-barbican | 01:10 | |
| *** jamielen- has joined #openstack-barbican | 01:11 | |
| *** jamielen| has joined #openstack-barbican | 01:12 | |
| *** jamielennox has quit IRC | 01:13 | |
| *** jamielennox_ has quit IRC | 01:15 | |
| *** jamielen- has quit IRC | 01:15 | |
| *** jamielen| is now known as jamielennox | 01:18 | |
| *** jamielennox_ has joined #openstack-barbican | 01:28 | |
| *** jamielennox has quit IRC | 01:31 | |
| *** jamielennox_ is now known as jamielennox | 01:40 | |
| *** jamielen- has joined #openstack-barbican | 02:10 | |
| *** jenkins-keep has quit IRC | 02:11 | |
| *** jamielennox has quit IRC | 02:13 | |
| *** jenkins-keep has joined #openstack-barbican | 02:23 | |
| *** jamielennox has joined #openstack-barbican | 02:47 | |
| *** jamielennox_ has joined #openstack-barbican | 02:48 | |
| *** jamielen- has quit IRC | 02:52 | |
| *** jamielennox has quit IRC | 02:52 | |
| *** jamielen- has joined #openstack-barbican | 03:01 | |
| *** jamielennox_ has quit IRC | 03:05 | |
| *** kebray has joined #openstack-barbican | 03:32 | |
| openstackgerrit | John Wood proposed a change to openstack/barbican: Add initial files for certificate event handling https://review.openstack.org/115301 | 03:37 |
|---|---|---|
| *** xianghuihui has joined #openstack-barbican | 03:40 | |
| *** xianghui has quit IRC | 03:42 | |
| *** kebray has quit IRC | 03:42 | |
| *** kebray has joined #openstack-barbican | 03:43 | |
| *** jamielennox has joined #openstack-barbican | 03:47 | |
| *** jamielennox_ has joined #openstack-barbican | 03:48 | |
| *** jamielen- has quit IRC | 03:50 | |
| *** jamielennox has quit IRC | 03:52 | |
| openstackgerrit | A change was merged to openstack/python-barbicanclient: Refactor client models in python-barbicanclient https://review.openstack.org/115080 | 03:56 |
| *** jamielennox has joined #openstack-barbican | 04:14 | |
| *** jamielen- has joined #openstack-barbican | 04:15 | |
| *** jamielennox_ has quit IRC | 04:18 | |
| *** xianghuihui has quit IRC | 04:19 | |
| *** jamielennox has quit IRC | 04:19 | |
| *** kebray_ has joined #openstack-barbican | 04:20 | |
| *** kebray has quit IRC | 04:23 | |
| *** jenkins-keep has quit IRC | 04:27 | |
| *** jenkins-keep has joined #openstack-barbican | 04:27 | |
| *** jenkins-keep has quit IRC | 04:34 | |
| *** jenkins-keep has joined #openstack-barbican | 04:36 | |
| openstackgerrit | John Vrbanac proposed a change to openstack/barbican: Make a whole host of modules hacking 0.9.2 compliant https://review.openstack.org/118248 | 05:00 |
| openstackgerrit | John Vrbanac proposed a change to openstack/barbican: Updating API unit and functional tests to new hacking standards https://review.openstack.org/118249 | 05:00 |
| *** juantwo has quit IRC | 05:06 | |
| *** kebray_ has quit IRC | 05:16 | |
| *** jamielennox has joined #openstack-barbican | 05:52 | |
| *** jamielen- has quit IRC | 05:54 | |
| *** rm_work|away is now known as rm_work | 06:32 | |
| rm_work | oh hey wat | 06:42 |
| rm_work | 115080 made it? :P | 06:42 |
| rm_work | nice | 06:42 |
| rm_work | need to talk to people tomorrow about the followup patch 113393 | 06:44 |
| *** jamielennox_ has joined #openstack-barbican | 06:52 | |
| *** jamielen- has joined #openstack-barbican | 06:53 | |
| *** jamielennox has quit IRC | 06:56 | |
| *** jamielennox_ has quit IRC | 06:57 | |
| *** openstackgerrit has quit IRC | 07:02 | |
| *** jamielen- is now known as jamielennox | 07:11 | |
| *** woodster has quit IRC | 07:15 | |
| *** jamielennox is now known as jamielennox|away | 08:09 | |
| rm_work | need additional feedback on https://review.openstack.org/#/c/113393/ (especially with regard to the __str__ debate Juan and I were having) | 08:25 |
| *** jaosorior has joined #openstack-barbican | 08:25 | |
| rm_work | lol jaosorior | 08:25 |
| jaosorior | yes | 08:26 |
| rm_work | I literally JUST asked the channel for feedback 30 seconds before you joined :P | 08:26 |
| rm_work | on https://review.openstack.org/#/c/113393/ | 08:26 |
| jaosorior | haha well | 08:26 |
| jaosorior | I actually saw your comment and remembered to log in here | 08:26 |
| rm_work | heh | 08:26 |
| jaosorior | with the purpose on commenting on it | 08:26 |
| rm_work | so not unrelated :) | 08:26 |
| jaosorior | the thing is, I still don't see the usage of this __str__ function. I think most of the work should be done by formatters provided by cliff | 08:27 |
| rm_work | that's assuming the main use of the python-barbicanclient is the CLI | 08:27 |
| rm_work | I actually would assume CLI use is minimal and the main use of python-barbicanclient is as a python import to do other code | 08:28 |
| jaosorior | that is indeed the case and was going to be my next point | 08:28 |
| rm_work | so it would be nice for developers to have a good __str__ function for the objects | 08:28 |
| rm_work | I would certainly like some good str() value | 08:29 |
| jaosorior | now, since the actual main usage of the client would be python code | 08:29 |
| rm_work | whether the example I gave is the right direction, I am not so sure | 08:29 |
| jaosorior | I do see value in having a proper __str__ function | 08:29 |
| jaosorior | but | 08:29 |
| jaosorior | would it be perhaps a good idea to have some unified way of generating these string representations? | 08:29 |
| rm_work | hmm | 08:30 |
| rm_work | well | 08:30 |
| rm_work | the example I gave kind of.... is unified | 08:30 |
| jaosorior | since we already can return the "headers" with the proper values | 08:30 |
| jaosorior | like the stuff is getting passed to cliff | 08:30 |
| jaosorior | perhaps we could have the same approach to printing | 08:30 |
| rm_work | well | 08:30 |
| rm_work | I am using prettytable, but the cliff functions EMIT, they don't return | 08:30 |
| rm_work | which is problematic | 08:31 |
| rm_work | i basically had to just copy the prettytable code out of the functions they provide, and force it to store the value and return it instead of just printing it to stdout >_> | 08:31 |
| jaosorior | well, the "_get_formatted_entity" approach does return | 08:31 |
| rm_work | yeah, and I use that | 08:31 |
| jaosorior | not in the code that's in the review | 08:32 |
| rm_work | i linked a gist | 08:32 |
| jaosorior | I slightly remember you had some other stuff in other repo? or something | 08:32 |
| rm_work | in the comments | 08:32 |
| jaosorior | yeah, the gist | 08:32 |
| rm_work | https://gist.github.com/rm-you/7130dbdc858569657423 | 08:32 |
| jaosorior | haha, it's too early and I slept 3 hours, I apologize for my lack of memory | 08:32 |
| rm_work | i didn't check in that code yet (i have it done for ALL of the classes) | 08:32 |
| rm_work | because i wasn't sure if that was the way we wanted to go | 08:32 |
| rm_work | and also, now the prior CR is merged already lol | 08:32 |
| jaosorior | try it out for the review and I'll check it out | 08:32 |
| rm_work | hmm | 08:32 |
| rm_work | well now it'll be different than the rest | 08:33 |
| jaosorior | which prior cr? | 08:33 |
| rm_work | so I'd need to patch the rest... either in a new CR or as part of this one to maintain consistency? >_> ugh | 08:33 |
| rm_work | https://review.openstack.org/#/c/115080/12 | 08:33 |
| rm_work | it was two CRs in a chain | 08:33 |
| rm_work | you +1'd :P | 08:33 |
| rm_work | remember I was rewriting all of the objects, just Containers was in a different CR :P | 08:34 |
| jaosorior | well, if you think it's a better approach submit a CR to maintain consistency, depending on the 115080 CR | 08:35 |
| rm_work | well | 08:35 |
| rm_work | what *I* think is probably the BEST approach | 08:35 |
| rm_work | is to merge the containers CR with the existing _str_ method | 08:35 |
| rm_work | and then make another CR that changes all of them at once to some new method | 08:35 |
| rm_work | which could be the one I proposed in that gist | 08:36 |
| jaosorior | if you trully see value in the __str__ stuff, then other people will comment on it and it will be merged ;) | 08:36 |
| rm_work | yeah | 08:36 |
| rm_work | but i don't want to get off the rails and try to do this as part of this CR | 08:36 |
| jaosorior | push it, so far it seems like a slightly better solution | 08:36 |
| rm_work | I totally agree with you that the current __str__ is really lame | 08:36 |
| rm_work | but | 08:36 |
| rm_work | I would rather push through this CR as is | 08:36 |
| rm_work | and then do another CR to address the issue directly | 08:37 |
| jaosorior | so, do we REALLY need the __str__ stuff in this CR? can't you just get that off since it will be overwritten in another CR? | 08:37 |
| rm_work | instead of tacking it on to the Containers CR and then merging something that would be out-of-sync with the rest of the objects | 08:37 |
| rm_work | right now, the __str__ in Containers class is in-line with the rest of the objects that are already merged | 08:37 |
| jaosorior | ok, ok | 08:38 |
| rm_work | removing it OR changing it in this CR would be out-of-sync | 08:38 |
| jaosorior | lets do this | 08:38 |
| rm_work | I am serious about proposing a new CR to fix them all at once :P | 08:38 |
| rm_work | i am not trying to push it off to later and drop it | 08:38 |
| rm_work | I promise | 08:38 |
| jaosorior | I'll accept the current __str__ approach, and then we can have another CR that fixes the approach for all objects | 08:38 |
| rm_work | yes | 08:38 |
| rm_work | I will actually propose it tomorrow | 08:38 |
| jaosorior | but hopefully it will come fast | 08:38 |
| rm_work | I can do finishing touches on the plane | 08:38 |
| jaosorior | if it can be done by tomorrow, awesome | 08:38 |
| rm_work | (flying back in the morning) | 08:38 |
| rm_work | I already did 90% of the work | 08:39 |
| *** ajc_ has joined #openstack-barbican | 08:39 | |
| jaosorior | even though working with openstack is awesome | 08:39 |
| rm_work | but it is 1:40am here and my flight is at 11am :) | 08:39 |
| jaosorior | I advice you to also enjoy your free time ;) | 08:39 |
| rm_work | hehe yes i have been on vacation >_< | 08:39 |
| rm_work | but checking in on my CRs is addicting | 08:39 |
| jaosorior | hahaha I know | 08:40 |
| rm_work | so you will remove your -1? :) | 08:40 |
| rm_work | I will comment about what is going on | 08:40 |
| jaosorior | but I do recommend trying to get the most of your vacation, it will reset your mind better, trust me | 08:40 |
| jaosorior | friendly advice | 08:40 |
| jaosorior | I do appreciate the work you've been doing though, props to you Mr.! | 08:40 |
| rm_work | heh thanks | 08:41 |
| jaosorior | +1 is there | 08:42 |
| rm_work | :) | 08:42 |
| jaosorior | anyway, I'll brb | 08:42 |
| rm_work | ok | 08:42 |
| rm_work | I am going to try to go to sleep :) | 08:42 |
| *** rm_work is now known as rm_work|away | 09:37 | |
| *** rm_work|away is now known as rm_work | 09:59 | |
| *** rm_work is now known as rm_work|away | 10:13 | |
| *** ajc_ has quit IRC | 11:55 | |
| *** jaosorior has quit IRC | 12:02 | |
| *** juantwo has joined #openstack-barbican | 12:06 | |
| *** juantwo has quit IRC | 12:08 | |
| *** juantwo has joined #openstack-barbican | 12:09 | |
| *** woodster has joined #openstack-barbican | 12:21 | |
| *** denis_makogon has joined #openstack-barbican | 12:35 | |
| *** Guest22704 has joined #openstack-barbican | 12:41 | |
| *** ayoung has joined #openstack-barbican | 13:14 | |
| *** jaosorior has joined #openstack-barbican | 13:17 | |
| jaosorior | jvrbanac: regarding the parentheses comments | 13:18 |
| jaosorior | I think that the same code, without the parentheses (same indentation and everything) should be fine | 13:18 |
| jaosorior | at least it passes flake8 for me | 13:18 |
| *** ametts has joined #openstack-barbican | 13:20 | |
| *** openstackgerrit has joined #openstack-barbican | 14:06 | |
| *** paul_glass has joined #openstack-barbican | 14:14 | |
| *** paul_glass has quit IRC | 14:18 | |
| *** nkinder has joined #openstack-barbican | 14:28 | |
| *** paul_glass has joined #openstack-barbican | 14:28 | |
| woodster | arunkant: Can you take a look at this CR to see if it answers your concerns? https://review.openstack.org/#/c/115301/ | 14:48 |
| arunkant | woodster_ : Okay..will look into this soon. | 14:49 |
| woodster | jaosorior: Hey Juan, can you also take a look at https://review.openstack.org/#/c/115301/ to see if it answers your concerns? | 14:50 |
| alee | woodster, chellygel ping | 14:51 |
| woodster | alee: morning | 14:51 |
| alee | woodster, morning | 14:51 |
| alee | woodster, just going through crs | 14:51 |
| alee | woodster, chellygel was looking at the order update cr. | 14:52 |
| woodster | alee: yeah, I updated the cert event CR | 14:52 |
| alee | woodster, yup - will get to that one next | 14:52 |
| alee | woodster, chellygel - so trying to understand the update CR. | 14:52 |
| woodster | so I was reviewing the SSL cert blueprint (https://github.com/openstack/barbican-specs/blob/master/specs/juno/add-ssl-ca-support.rst) and notice that I didn't add the sub-status stuff in there :( | 14:52 |
| woodster | woodster: the overall approach you mean, or detail items in there? | 14:53 |
| alee | when an update is requested, then a new UpdateOrder task is created? | 14:53 |
| woodster | alee: yes, it is using the same Task based approach as for beginning orders. It is a generic update order handler, that just has logic for certificate workflow handling in this CR. | 14:54 |
| alee | I guess the existing task is completed .. | 14:54 |
| alee | woodster, yeah -- I guess I had questions about the status/substatus of the order | 14:55 |
| woodster | alee: you mean the initial begin order task? If so, then yes, that completed. If the order didn't complete then (with a fatal error or ssl cert being generated), then the Order record stays PENDING, and a follow on client update can be made. | 14:55 |
| alee | and the persisitence of the updated metadata before the update was attempted | 14:55 |
| alee | there is no check right now to see if the order is pending | 14:56 |
| woodster | alee: yes, the client-side meta data (in the meta JSON attribute of Order) is update prior to that UpdateOrder task call | 14:56 |
| woodster | alee: ah, got it...should be on both the API and worker sides to check that | 14:56 |
| alee | and even if there were, there is no guarantee that the order will not be completed by the time the plugin method is called. | 14:57 |
| woodster | alee: I'll let chellygel know about that | 14:57 |
| alee | woodster, I think we need to make the update attempt before persisting the new metadata | 14:57 |
| alee | woodster, or at least keeping the old metadata around. | 14:57 |
| woodster | alee: a race condition is possible, but for some cases that could only resolved by talking to the CA and having it return an error. That would be gracefully handled though | 14:58 |
| alee | woodster, yes - which is why I think you need to talk to the ca prior to updating the oder metadata | 14:59 |
| *** paul_glass has quit IRC | 14:59 | |
| woodster | alee, chellygel: so should we add a meta_update attribute to Orders, and then the UpdateTask process handles that? For cert workflows, only if the CA blesses the mods would the Order be updated? | 14:59 |
| *** atiwari has joined #openstack-barbican | 15:00 | |
| alee | woodster, you know this would be so much easier if we simply disallowed updates. If you want to update, just add a new order. | 15:01 |
| jaosorior | woodster: sure, I'll check it in a couple of hours | 15:01 |
| alee | woodster, but if we need to support it, then yes .. we'll have to do something like that | 15:01 |
| woodster | jaosorior: thanks! | 15:01 |
| atiwari | woodster, yt? | 15:03 |
| woodster | alee: I think it's ok for a plugin to reject a modify request. Eventually we'll probably want to do that check API-side. So eventually I'd like to use the Python contexts approach I noted a while back. The API controllers would then call more fine grained RPC methods on the workers, allowing for more validation checks API-side as well. | 15:03 |
| woodster | atiwari: morning | 15:03 |
| *** paul_glass has joined #openstack-barbican | 15:04 | |
| atiwari | good morning | 15:04 |
| atiwari | wondering do you have any thoughts on Nathan's comments on my cr | 15:05 |
| atiwari | https://review.openstack.org/#/c/111412 | 15:05 |
| alee | woodster, just pointing out that there are all kinds of possible race conditions which we need to be able to manage somehow. We can avoid all that by not allowing updates. | 15:05 |
| alee | woodster, does symantec even allow you to update the ca request? | 15:06 |
| atiwari | I think we are stuck on https://review.openstack.org/#/c/111412/16/barbican/plugin/interface/secret_store.py , where some extra constants are defined. | 15:06 |
| atiwari | woodster, I have added my comments in https://review.openstack.org/#/c/111412/15/barbican/plugin/interface/secret_store.py | 15:07 |
| atiwari | can we resolve it today? | 15:07 |
| atiwari | woodster, another thing. | 15:09 |
| atiwari | getting "CommandError: Only a single head is supported. The script directory has multiple heads (due to branching), which must be resolved by manually editing the revision files to form a linear sequence. Run `alembic branches` to see the divergence(s)." | 15:09 |
| alee | atiwari, why do you need ASYMMETRIC_KEY? | 15:09 |
| atiwari | on gate-barbican-devstack-dsvm, do you have any idea? | 15:09 |
| woodster | atiwari: I was hoping reaperhulk could weigh in on these comments...he is transitioning from his Hawaii vacation to the US over the next day or so though. | 15:10 |
| atiwari | alee, I thought we are will check in resource before making the call to generate | 15:11 |
| atiwari | alee, please look at https://review.openstack.org/#/c/111412/15/barbican/plugin/resources.py | 15:11 |
| atiwari | my comment | 15:11 |
| woodster | atiwari: sounds like there was a merge conflict on the alembic version files...each one has a version and a previous version. The previous version needs to be found on another version file with that as the version and so forth. My guess is that there is a version file in there that doesn't have a previous version file, or maybe more than one has the same | 15:12 |
| woodster | previous? | 15:12 |
| atiwari | woodster, how to fix this? | 15:13 |
| atiwari | :( | 15:13 |
| atiwari | alee, at the same time all the constant from https://review.openstack.org/#/c/111412/16/barbican/plugin/interface/secret_store.py@SecretType | 15:14 |
| atiwari | are not utilized | 15:14 |
| atiwari | alee, ASYMMETRIC = "asymmetric" will be set on the secret (eventually) to indicate that secret is part of an asymmetric key pair | 15:17 |
| atiwari | right now secret has no type but later it will. | 15:17 |
| alee | atiwari, well - yes and no -- what about PUBLIC/ PRIVATE | 15:17 |
| *** Guest22704 has quit IRC | 15:18 | |
| alee | atiwari, PUBLIC/PRIVATE need to be set on the secrets to indicate what they are. | 15:18 |
| atiwari | public/private will be set in the container | 15:18 |
| alee | so whats the point of PUBLIC/PRIVATE? | 15:19 |
| atiwari | woodster, how can I yank https://blueprints.launchpad.net/barbican/+spec/add-type-field-to-secrets? | 15:20 |
| atiwari | I think Huseyin no more in community | 15:21 |
| atiwari | alee, another issue is HMAC = "hmac" | 15:23 |
| atiwari | we need that on secret to improve searches | 15:23 |
| alee | atiwari, well - the same arg might apply to PUBLIC/PRIVATE vs. ASYMMETRIC | 15:26 |
| alee | atiwari, we might for example, want at some point to allow generate access to public keys - but not to private ones. | 15:26 |
| atiwari | alee, how do you make sure that a generate plug in can generate an Asymmetric? | 15:28 |
| alee | atiwari, don't we have a supports() method? | 15:28 |
| atiwari | that is on crypto plugin | 15:29 |
| atiwari | we need some check on store plugin | 15:29 |
| atiwari | thoughts? | 15:29 |
| alee | geenrate_supports() defined in secret_store.py | 15:30 |
| atiwari | correct and that calls get_secret_type(self, alg) | 15:30 |
| atiwari | from barbican/plugin/interface/secret_store.py | 15:30 |
| atiwari | woodster, I am adding spec for https://blueprints.launchpad.net/barbican/+spec/add-type-field-to-secrets. need your opinion | 15:32 |
| *** Guest22704 has joined #openstack-barbican | 15:34 | |
| alee | atiwari, there are two questions here -- what secret type should be stored in the secret_table? and whether we need an ASYMMETRIC type. | 15:34 |
| alee | atiwari, I'm coming to the view that we should store PUBLIC/PRIVATE in the secret table | 15:35 |
| atiwari | alee, right now there is no way to store type in secret | 15:35 |
| alee | because it provides us with much more info for searches , access control etc. | 15:35 |
| alee | ah - so this is all in the metadata then. | 15:36 |
| atiwari | alee, I am planning to implement type soon | 15:36 |
| atiwari | on secrets | 15:36 |
| atiwari | alee, initially we thought that secret will be a generic resource and container will define public or private | 15:37 |
| atiwari | we need some way (same as supports() in crypto plugin ) in store crypto to check if it support asymmetric keys | 15:39 |
| alee | atiwari, right - thats question #2. if we want something like ASYMMETRIC as a convenience constant, thats fine. although I think we could do without it. | 15:40 |
| alee | atiwari, I'm more interested in what we put into the db | 15:40 |
| alee | atiwari, can someone store a public key (as a public key)? | 15:41 |
| *** kebray has joined #openstack-barbican | 15:43 | |
| alee | atiwari, how do I search for all the public keys available? | 15:43 |
| alee | woodster, atiwari - does it make sense to store the secret_type as part of the secret_table? | 15:44 |
| *** gyee has joined #openstack-barbican | 15:45 | |
| atiwari | alee, there are two concerns 1)search 2)check support for Asymmetric type on store_crypto | 15:46 |
| atiwari | alee, are we on same page ?> | 15:46 |
| alee | atiwari, can one generate a public/private key pair on their own client machine and store it in barbican as a public/private key? | 15:47 |
| atiwari | alee, yes | 15:48 |
| alee | atiwari, rather than generating on barbican .. | 15:48 |
| atiwari | alee, yes | 15:48 |
| alee | atiwari, and how does one do that? | 15:48 |
| atiwari | upload pub/pri and associate with container | 15:48 |
| atiwari | container maps the type | 15:49 |
| alee | ok - so upload pub, upload priv, create container, make associations | 15:49 |
| atiwari | correct for asymmetric key | 15:49 |
| alee | atiwari, ok - how do I search for all the public keys ? | 15:50 |
| openstackgerrit | Arvind Tiwari proposed a change to openstack/barbican: Reorganize code to use store crypto plug-in https://review.openstack.org/111412 | 15:50 |
| atiwari | alee, I think that goes through container search | 15:52 |
| atiwari | search container which has pub ref | 15:52 |
| alee | ok what about searches for HMAC? | 15:54 |
| chellygel | alee, in regards to your question -- yes, the customer can update contact information for the cert order | 15:55 |
| jvrbanac | jaosorior, did I address your questions? | 15:55 |
| atiwari | alee, that is why we need https://blueprints.launchpad.net/barbican/+spec/add-type-field-to-secrets | 15:55 |
| chellygel | alee: as well as other things, im digging through the api docs now to verify each case | 15:55 |
| atiwari | alee, I am putting together a spec for the same | 15:56 |
| alee | chellygel, ok thats fine. although I imagine that there will be a number of changes that will be rejected | 15:57 |
| chellygel | yes, hoping that validation would prevent a lot of that before hand | 15:58 |
| chellygel | but you are right, we need to prepare for these situations ! but i also dont want to make scary huge CRs lol | 15:59 |
| alee | chellygel, we can keep the order update mechanism - but you're going to need to handle the possible race conditions -- and to call the update() on the plugin before updating the metadata | 15:59 |
| *** paul_glass has quit IRC | 16:01 | |
| alee | atiwari, when you store the pub/priv key, you can - but are not required to pass in a secret type to the api, right? | 16:02 |
| atiwari | yes, at the same time there is no API to pass the type | 16:03 |
| atiwari | alee, ^ | 16:03 |
| alee | ok - I guess you can pass in an algorithm and that will define the type .. | 16:05 |
| alee | but of course its not required. | 16:05 |
| alee | atiwari, ok - I think we need to revisit the search question later in K - and maybe end up adding a type field to the secrets table then .. maybe .. | 16:11 |
| atiwari | alee, correct | 16:11 |
| atiwari | let move up with J :) | 16:12 |
| alee | atiwari, for what should be defined in secret_store.py, then, we should define only those constants which are needed by barbican-core | 16:12 |
| alee | which includes things needed by get_secret_type() which is defined there | 16:12 |
| alee | are PUBLIC_KEY and PRIVATE_KEY using by barbican-core? | 16:13 |
| alee | if not, then they should be removed | 16:13 |
| atiwari | alee, OK | 16:13 |
| alee | and if the plugin wants to define them and use them, then it should do so. | 16:13 |
| alee | if store_crypto.py needs it, then it should be defined there. | 16:14 |
| atiwari | alee, IMO all the constants there in SecretType are use less right now | 16:14 |
| atiwari | those are all redundant | 16:15 |
| atiwari | do you agree? | 16:15 |
| alee | dogtag will in fact use PUBLIC_KEY/PRIVATE_KEY but we will define it there | 16:15 |
| alee | atiwari, well they are only used by get_secret_type() right? | 16:16 |
| atiwari | alee, correct | 16:16 |
| atiwari | then what is point of having all there? | 16:16 |
| atiwari | IMO, leave it like that and later we will clean them. there are lots of redundancy / useless code | 16:18 |
| atiwari | thought? | 16:18 |
| alee | and get_secret_type() is used only by the supports() methods? | 16:18 |
| atiwari | alee, IMO no | 16:18 |
| atiwari | let me check | 16:18 |
| *** paul_glass has joined #openstack-barbican | 16:19 | |
| atiwari | alee, no supports() does not use get_secret_type() | 16:19 |
| alee | we call get_secret_type() when we pass in the secret to the plugins to store. | 16:20 |
| alee | atiwari, I think there may be some value to get_secret_type() but we can look into removing it later if need be. But we should remove constants not used in barbican_core | 16:26 |
| alee | which in this case is PUBLIC_KEY/PRIVATE_KEY | 16:26 |
| alee | atiwari, having them there is confusing -- when we started to implement asymmetric key in dogtag , it was unclear to us whether to store the secrets as public/private or asymmetric .. | 16:27 |
| atiwari | alee, which one should I keep there? | 16:28 |
| atiwari | just SYMMETRIC = "symmetric"? | 16:28 |
| alee | well asymmetric is used by get_secret_type() right? | 16:28 |
| alee | we need rellerreller on here .. | 16:29 |
| openstackgerrit | Arvind Tiwari proposed a change to openstack/barbican: Reorganize code to use store crypto plug-in https://review.openstack.org/111412 | 16:34 |
| *** paul_glass has quit IRC | 16:36 | |
| atiwari | alee, rellerreller I have fixed the code as per comments | 16:36 |
| *** bdpayne has joined #openstack-barbican | 17:04 | |
| openstackgerrit | Arvind Tiwari proposed a change to openstack/barbican-specs: spec to add type field on secrets https://review.openstack.org/118409 | 17:07 |
| openstackgerrit | Arvind Tiwari proposed a change to openstack/barbican: Reorganize code to use store crypto plug-in https://review.openstack.org/111412 | 17:18 |
| *** rm_mobile has joined #openstack-barbican | 17:29 | |
| *** nkinder has quit IRC | 17:43 | |
| *** paul_glass has joined #openstack-barbican | 17:46 | |
| *** paul_glass has quit IRC | 17:46 | |
| *** paul_glass has joined #openstack-barbican | 17:46 | |
| openstackgerrit | Arvind Tiwari proposed a change to openstack/barbican: Reorganize code to use store crypto plug-in https://review.openstack.org/111412 | 17:50 |
| atiwari | alee, I have fixed you comment | 17:51 |
| alee | atiwari, ok - +2 for me, lets see if we can get it through .. | 17:52 |
| atiwari | alee, thank | 17:54 |
| atiwari | s/thanks | 17:54 |
| *** bdpayne has quit IRC | 18:01 | |
| *** bdpayne has joined #openstack-barbican | 18:01 | |
| *** kebray has quit IRC | 18:01 | |
| *** kebray has joined #openstack-barbican | 18:03 | |
| *** rm_work|away is now known as rm_work | 18:04 | |
| *** nkinder has joined #openstack-barbican | 18:06 | |
| *** jamielennox|away is now known as jamielennox_ | 18:09 | |
| *** rm_work is now known as rm_work|away | 18:14 | |
| openstackgerrit | Arvind Tiwari proposed a change to openstack/barbican: Reorganize code to use store crypto plug-in https://review.openstack.org/111412 | 18:17 |
| atiwari | woodster, thanks for your pointers on alembic issue | 18:17 |
| atiwari | I have fixed the same and pushed a new patch | 18:18 |
| jvrbanac | jaosorior, ping | 18:18 |
| woodster | atiwari: sorry for not following up, lots of meetings today... | 18:18 |
| atiwari | woodster, np I think I found the issue based on your feedback above | 18:19 |
| atiwari | thanks :) | 18:19 |
| rm_mobile | jvrbanac: I see that the third and fourth CRs are not dependent on the earlier ones | 18:36 |
| rm_mobile | I guess we're not doing that? :P | 18:36 |
| rm_mobile | Agh | 18:36 |
| rm_mobile | Gotta wireless off | 18:37 |
| rm_mobile | Taking off! Back in a bit | 18:37 |
| jaosorior | jvrbanac: hey, now I'm here | 18:38 |
| jaosorior | got an unexpected visit | 18:38 |
| jaosorior | about to check your comments now | 18:39 |
| *** rm_mobile has quit IRC | 18:41 | |
| jaosorior | jvrbanac: are you around? | 18:45 |
| jvrbanac | jaosorior, yeah sorry | 18:53 |
| jvrbanac | jaosorior, was my explanation good enough for you? | 18:53 |
| jvrbanac | jaosorior, on https://review.openstack.org/#/c/118248/ | 18:53 |
| *** ametts has quit IRC | 18:54 | |
| jaosorior | yeah, I understand your argument, at the moment I | 18:55 |
| jaosorior | I'm trying to set up the environment with the newest hacking, so I can verify something | 18:55 |
| jaosorior | before I comment | 18:55 |
| jvrbanac | jaosorior, ahh ok | 18:56 |
| jaosorior | which is if the following is valid: http://pastebin.com/ahf8A4Ki | 18:56 |
| jaosorior | because it is actually valid python syntax, I'm just not sure if hacking has something against it | 18:57 |
| jaosorior | if you have the environment setup you could also check that | 19:00 |
| jaosorior | since when I run the code with the newest hacking (with the changes your CR introduces) there still seem to be a lot of pep8 errors | 19:00 |
| jvrbanac | jaosorior, yeah all of the changes are spread across 4 CRs | 19:01 |
| jvrbanac | jaosorior, the new form you're talking about is a pep8 E113 violation | 19:02 |
| jaosorior | OK, I wasn't sure about that | 19:03 |
| jaosorior | I actually dislike that it | 19:03 |
| jaosorior | it's a violation | 19:03 |
| jaosorior | but there's nothing I can do about it | 19:03 |
| jvrbanac | jaosorior, unfortunately. I the the real answer is that we need to refactor those sections | 19:04 |
| jaosorior | true that | 19:04 |
| jaosorior | anyway, +1 | 19:05 |
| jvrbanac | jaosorior, however, I didn't want to get deep into refactoring all the things for just hacking violations. | 19:05 |
| jaosorior | I agree, you took a good approach | 19:06 |
| jaosorior | refactoring is the next step | 19:06 |
| jaosorior | woodster: checked your CR also, btw | 19:06 |
| *** lisaclark1 has joined #openstack-barbican | 19:08 | |
| *** ametts has joined #openstack-barbican | 19:24 | |
| *** lisaclark1 has quit IRC | 19:51 | |
| woodster | jaosorior: Just added responses to your comments | 19:57 |
| jaosorior | Awesome | 19:57 |
| jaosorior | woodster: in all honesty the use of inspec is quite cryptic, forgot to ask you what your intention was | 20:02 |
| woodster | jaosorior: the idea is to invoke the same method on the list of event plugins as the abstract method that is called. Another option would just be to pass in the method name by name and not do inspect. The original approach copy/pasta-ed the plugins loop which was not very elegant | 20:03 |
| *** lisaclark1 has joined #openstack-barbican | 20:04 | |
| woodster | jaosorior: would the passing the method name as a string be more explicit and therefore clearer/better? | 20:04 |
| jaosorior | Well, it would make more sense to me. Since it would be easier to decipher where the name comes from in less time | 20:06 |
| woodster | jaosorior: it would also be more performant...inspect.stack is an expensive call | 20:07 |
| alee | woodster, what do the [1][3] mean exactly? | 20:11 |
| alee | woodster, +1 for passing in function name as a string | 20:13 |
| *** lisaclark1 has quit IRC | 20:15 | |
| woodster | alee, jaosorior: nice, I'll yank that inspect stuff shortly | 20:16 |
| *** lisaclark1 has joined #openstack-barbican | 20:17 | |
| *** lisaclark1 has quit IRC | 20:24 | |
| openstackgerrit | John Wood proposed a change to openstack/barbican: Add initial files for certificate event handling https://review.openstack.org/115301 | 20:24 |
| openstackgerrit | John Wood proposed a change to openstack/barbican: Add initial files for certificate event handling https://review.openstack.org/115301 | 20:25 |
| *** kebray has quit IRC | 20:26 | |
| *** lisaclark1 has joined #openstack-barbican | 20:27 | |
| woodster | alee, jaosorior, hockeynut: Updates to the CR. Juan, I'm still thinking we need a separate CR to address the plugin exceptions issue though. | 20:29 |
| *** lisaclark1 has quit IRC | 20:30 | |
| openstackgerrit | A change was merged to openstack/barbican: Making a few modules hacking 0.9.2 compliant https://review.openstack.org/117334 | 20:30 |
| *** atiwari has quit IRC | 20:45 | |
| *** lisaclark1 has joined #openstack-barbican | 20:54 | |
| *** lisaclark1 has quit IRC | 20:54 | |
| *** lisaclark1 has joined #openstack-barbican | 20:55 | |
| *** SheenaG1 has joined #openstack-barbican | 20:59 | |
| *** juantwo has quit IRC | 20:59 | |
| *** lisaclark1 has quit IRC | 20:59 | |
| *** ametts has quit IRC | 21:10 | |
| *** atiwari has joined #openstack-barbican | 21:18 | |
| openstackgerrit | Kaitlin Farr proposed a change to openstack/barbican: Add PyKMIP to requirements https://review.openstack.org/117539 | 21:21 |
| *** atiwari has quit IRC | 21:22 | |
| *** atiwari has joined #openstack-barbican | 21:23 | |
| *** nkinder has quit IRC | 21:48 | |
| *** ayoung has quit IRC | 21:54 | |
| *** paul_glass has quit IRC | 21:55 | |
| *** atiwari has quit IRC | 22:14 | |
| *** kebray has joined #openstack-barbican | 22:16 | |
| *** SheenaG1 has quit IRC | 22:21 | |
| *** rm_mobile has joined #openstack-barbican | 22:22 | |
| *** jaosorior has quit IRC | 22:22 | |
| rm_mobile | jaosorior: pushing that CR in about 30min | 22:22 |
| rm_mobile | Damnit lol | 22:22 |
| openstackgerrit | A change was merged to openstack/barbican: Updating API unit and functional tests to new hacking standards https://review.openstack.org/118249 | 22:23 |
| openstackgerrit | Arun Kant proposed a change to openstack/barbican: Adding keystone notification listener support https://review.openstack.org/110817 | 22:28 |
| *** rm_mobile has quit IRC | 22:28 | |
| *** rm_mobile has joined #openstack-barbican | 22:29 | |
| *** bdpayne has quit IRC | 22:31 | |
| *** bdpayne has joined #openstack-barbican | 22:32 | |
| rm_mobile | Darn it reaperhulk , I don't think I'll ever get any kind of CR in without writing at least one test :P | 22:32 |
| rm_mobile | Not that I disagree... | 22:33 |
| *** juantwo has joined #openstack-barbican | 23:01 | |
| *** juantwo has quit IRC | 23:01 | |
| *** juantwo has joined #openstack-barbican | 23:01 | |
| *** AndChat|40521 has joined #openstack-barbican | 23:03 | |
| *** rm_mobile has quit IRC | 23:04 | |
| *** rm_work|away is now known as rm_work | 23:16 | |
| *** jamielen^ has joined #openstack-barbican | 23:18 | |
| openstackgerrit | Arvind Tiwari proposed a change to openstack/barbican: Reorganize code to use store crypto plug-in https://review.openstack.org/111412 | 23:19 |
| *** jamielennox_ has quit IRC | 23:20 | |
| *** AndChat|40521 has quit IRC | 23:27 | |
| *** bdpayne has quit IRC | 23:27 | |
| rm_work | wtf, can't tox py33 because testr returns an error listing tests | 23:31 |
| rm_work | this makes no sense at all | 23:31 |
| * rm_work doesn't really understand how testr works | 23:31 | |
| *** jamielennox has joined #openstack-barbican | 23:31 | |
| *** jamielen^ has left #openstack-barbican | 23:32 | |
| *** bdpayne has joined #openstack-barbican | 23:32 | |
| rm_work | any more love for https://review.openstack.org/#/c/113393/ ? :P | 23:40 |
| openstackgerrit | Adam Harwell proposed a change to openstack/python-barbicanclient: Change object __str__() to use pretty formatting https://review.openstack.org/118494 | 23:40 |
| rm_work | also, that just happened | 23:40 |
| rm_work | though it is failing py33 and i am not sure why | 23:40 |
| *** bdpayne has quit IRC | 23:55 | |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!