Tuesday, 2014-09-02

*** kebray has joined #openstack-barbican00:44
*** jamielen- has joined #openstack-barbican00:58
*** jamielennox has quit IRC01:00
*** jamielen- is now known as jamielennox01:01
*** kebray has quit IRC01:08
*** jamielennox_ has joined #openstack-barbican01:10
*** jamielen- has joined #openstack-barbican01:11
*** jamielen| has joined #openstack-barbican01:12
*** jamielennox has quit IRC01:13
*** jamielennox_ has quit IRC01:15
*** jamielen- has quit IRC01:15
*** jamielen| is now known as jamielennox01:18
*** jamielennox_ has joined #openstack-barbican01:28
*** jamielennox has quit IRC01:31
*** jamielennox_ is now known as jamielennox01:40
*** jamielen- has joined #openstack-barbican02:10
*** jenkins-keep has quit IRC02:11
*** jamielennox has quit IRC02:13
*** jenkins-keep has joined #openstack-barbican02:23
*** jamielennox has joined #openstack-barbican02:47
*** jamielennox_ has joined #openstack-barbican02:48
*** jamielen- has quit IRC02:52
*** jamielennox has quit IRC02:52
*** jamielen- has joined #openstack-barbican03:01
*** jamielennox_ has quit IRC03:05
*** kebray has joined #openstack-barbican03:32
openstackgerritJohn Wood proposed a change to openstack/barbican: Add initial files for certificate event handling  https://review.openstack.org/11530103:37
*** xianghuihui has joined #openstack-barbican03:40
*** xianghui has quit IRC03:42
*** kebray has quit IRC03:42
*** kebray has joined #openstack-barbican03:43
*** jamielennox has joined #openstack-barbican03:47
*** jamielennox_ has joined #openstack-barbican03:48
*** jamielen- has quit IRC03:50
*** jamielennox has quit IRC03:52
openstackgerritA change was merged to openstack/python-barbicanclient: Refactor client models in python-barbicanclient  https://review.openstack.org/11508003:56
*** jamielennox has joined #openstack-barbican04:14
*** jamielen- has joined #openstack-barbican04:15
*** jamielennox_ has quit IRC04:18
*** xianghuihui has quit IRC04:19
*** jamielennox has quit IRC04:19
*** kebray_ has joined #openstack-barbican04:20
*** kebray has quit IRC04:23
*** jenkins-keep has quit IRC04:27
*** jenkins-keep has joined #openstack-barbican04:27
*** jenkins-keep has quit IRC04:34
*** jenkins-keep has joined #openstack-barbican04:36
openstackgerritJohn Vrbanac proposed a change to openstack/barbican: Make a whole host of modules hacking 0.9.2 compliant  https://review.openstack.org/11824805:00
openstackgerritJohn Vrbanac proposed a change to openstack/barbican: Updating API unit and functional tests to new hacking standards  https://review.openstack.org/11824905:00
*** juantwo has quit IRC05:06
*** kebray_ has quit IRC05:16
*** jamielennox has joined #openstack-barbican05:52
*** jamielen- has quit IRC05:54
*** rm_work|away is now known as rm_work06:32
rm_workoh hey wat06:42
rm_work115080 made it? :P06:42
rm_workneed to talk to people tomorrow about the followup patch 11339306:44
*** jamielennox_ has joined #openstack-barbican06:52
*** jamielen- has joined #openstack-barbican06:53
*** jamielennox has quit IRC06:56
*** jamielennox_ has quit IRC06:57
*** openstackgerrit has quit IRC07:02
*** jamielen- is now known as jamielennox07:11
*** woodster has quit IRC07:15
*** jamielennox is now known as jamielennox|away08:09
rm_workneed 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-barbican08:25
rm_worklol jaosorior08:25
rm_workI literally JUST asked the channel for feedback 30 seconds before you joined :P08:26
rm_workon https://review.openstack.org/#/c/113393/08:26
jaosoriorhaha well08:26
jaosoriorI actually saw your comment and remembered to log in here08:26
jaosoriorwith the purpose on commenting on it08:26
rm_workso not unrelated :)08:26
jaosoriorthe 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 cliff08:27
rm_workthat's assuming the main use of the python-barbicanclient is the CLI08:27
rm_workI actually would assume CLI use is minimal and the main use of python-barbicanclient is as a python import to do other code08:28
jaosoriorthat is indeed the case and was going to be my next point08:28
rm_workso it would be nice for developers to have a good __str__ function for the objects08:28
rm_workI would certainly like some good str() value08:29
jaosoriornow, since the actual main usage of the client would be python code08:29
rm_workwhether the example I gave is the right direction, I am not so sure08:29
jaosoriorI do see value in having a proper __str__ function08:29
jaosoriorwould it be perhaps a good idea to have some unified way of generating these string representations?08:29
rm_workthe example I gave kind of.... is unified08:30
jaosoriorsince we already can return the "headers" with the proper values08:30
jaosoriorlike the stuff is getting passed to cliff08:30
jaosoriorperhaps we could have the same approach to printing08:30
rm_workI am using prettytable, but the cliff functions EMIT, they don't return08:30
rm_workwhich is problematic08:31
rm_worki 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
jaosoriorwell, the "_get_formatted_entity" approach does return08:31
rm_workyeah, and I use that08:31
jaosoriornot in the code that's in the review08:32
rm_worki linked a gist08:32
jaosoriorI slightly remember you had some other stuff in other repo? or something08:32
rm_workin the comments08:32
jaosorioryeah, the gist08:32
jaosoriorhaha, it's too early and I slept 3 hours, I apologize for my lack of memory08:32
rm_worki didn't check in that code yet (i have it done for ALL of the classes)08:32
rm_workbecause i wasn't sure if that was the way we wanted to go08:32
rm_workand also, now the prior CR is merged already lol08:32
jaosoriortry it out for the review and I'll check it out08:32
rm_workwell now it'll be different than the rest08:33
jaosoriorwhich prior cr?08:33
rm_workso I'd need to patch the rest... either in a new CR or as part of this one to maintain consistency? >_> ugh08:33
rm_workit was two CRs in a chain08:33
rm_workyou +1'd :P08:33
rm_workremember I was rewriting all of the objects, just Containers was in a different CR :P08:34
jaosoriorwell, if you think it's a better approach submit a CR to maintain consistency, depending on  the 115080 CR08:35
rm_workwhat *I* think is probably the BEST approach08:35
rm_workis to merge the containers CR with the existing _str_ method08:35
rm_workand then make another CR that changes all of them at once to some new method08:35
rm_workwhich could be the one I proposed in that gist08:36
jaosoriorif you trully see value in the __str__ stuff, then other people will comment on it and it will be merged ;)08:36
rm_workbut i don't want to get off the rails and try to do this as part of this CR08:36
jaosoriorpush it, so far it seems like a slightly better solution08:36
rm_workI totally agree with you that the current __str__ is really lame08:36
rm_workI would rather push through this CR as is08:36
rm_workand then do another CR to address the issue directly08:37
jaosoriorso, 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_workinstead of tacking it on to the Containers CR and then merging something that would be out-of-sync with the rest of the objects08:37
rm_workright now, the __str__ in Containers class is in-line with the rest of the objects that are already merged08:37
jaosoriorok, ok08:38
rm_workremoving it OR changing it in this CR would be out-of-sync08:38
jaosoriorlets do this08:38
rm_workI am serious about proposing a new CR to fix them all at once :P08:38
rm_worki am not trying to push it off to later and drop it08:38
rm_workI promise08:38
jaosoriorI'll accept the current __str__ approach, and then we can have another CR that fixes the approach for all objects08:38
rm_workI will actually propose it tomorrow08:38
jaosoriorbut hopefully it will come fast08:38
rm_workI can do finishing touches on the plane08:38
jaosoriorif it can be done by tomorrow, awesome08:38
rm_work(flying back in the morning)08:38
rm_workI already did 90% of the work08:39
*** ajc_ has joined #openstack-barbican08:39
jaosorioreven though working with openstack is awesome08:39
rm_workbut it is 1:40am here and my flight is at 11am :)08:39
jaosoriorI advice you to also enjoy your free time ;)08:39
rm_workhehe yes i have been on vacation >_<08:39
rm_workbut checking in on my CRs is addicting08:39
jaosoriorhahaha I know08:40
rm_workso you will remove your -1? :)08:40
rm_workI will comment about what is going on08:40
jaosoriorbut I do recommend trying to get the most of your vacation, it will reset your mind better, trust me08:40
jaosoriorfriendly advice08:40
jaosoriorI do appreciate the work you've been doing though, props to you Mr.!08:40
rm_workheh thanks08:41
jaosorior+1 is there08:42
jaosorioranyway, I'll brb08:42
rm_workI am going to try to go to sleep :)08:42
*** rm_work is now known as rm_work|away09:37
*** rm_work|away is now known as rm_work09:59
*** rm_work is now known as rm_work|away10:13
*** ajc_ has quit IRC11:55
*** jaosorior has quit IRC12:02
*** juantwo has joined #openstack-barbican12:06
*** juantwo has quit IRC12:08
*** juantwo has joined #openstack-barbican12:09
*** woodster has joined #openstack-barbican12:21
*** denis_makogon has joined #openstack-barbican12:35
*** Guest22704 has joined #openstack-barbican12:41
*** ayoung has joined #openstack-barbican13:14
*** jaosorior has joined #openstack-barbican13:17
jaosoriorjvrbanac: regarding the parentheses comments13:18
jaosoriorI think that the same code, without the parentheses (same indentation and everything) should be fine13:18
jaosoriorat least it passes flake8 for me13:18
*** ametts has joined #openstack-barbican13:20
*** openstackgerrit has joined #openstack-barbican14:06
*** paul_glass has joined #openstack-barbican14:14
*** paul_glass has quit IRC14:18
*** nkinder has joined #openstack-barbican14:28
*** paul_glass has joined #openstack-barbican14:28
woodsterarunkant: Can you take a look at this CR to see if it answers your concerns? https://review.openstack.org/#/c/115301/14:48
arunkantwoodster_ : Okay..will look into this soon.14:49
woodsterjaosorior: Hey Juan, can you also take a look at https://review.openstack.org/#/c/115301/ to see if it answers your concerns?14:50
aleewoodster, chellygel ping14:51
woodsteralee: morning14:51
aleewoodster, morning14:51
aleewoodster, just going through crs14:51
aleewoodster, chellygel was looking at the order update cr.14:52
woodsteralee: yeah, I updated the cert event CR14:52
aleewoodster, yup - will get to that one next14:52
aleewoodster, chellygel - so trying to understand the update CR.14:52
woodsterso 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
woodsterwoodster: the overall approach you mean, or detail items in there?14:53
aleewhen an update is requested, then a new UpdateOrder task is created?14:53
woodsteralee: 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
aleeI guess the existing task is completed ..14:54
aleewoodster, yeah -- I guess I had questions about the status/substatus of the order14:55
woodsteralee: 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
aleeand the persisitence of the updated metadata before the update was attempted14:55
aleethere is no check right now to see if the order is pending14:56
woodsteralee: yes, the client-side meta data (in the meta JSON attribute of Order) is update prior to that UpdateOrder task call14:56
woodsteralee: ah, got it...should be on both the API and worker sides to check that14:56
aleeand 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
woodsteralee: I'll let chellygel know about that14:57
aleewoodster, I think we need to make the update attempt before persisting the new metadata14:57
aleewoodster,  or at least keeping the old metadata around.14:57
woodsteralee: 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 though14:58
aleewoodster, yes - which is why I think you need to talk to the ca prior to updating the oder metadata14:59
*** paul_glass has quit IRC14:59
woodsteralee, 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-barbican15:00
aleewoodster, 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
jaosoriorwoodster: sure, I'll check it in a couple of hours15:01
aleewoodster, but if we need to support  it, then yes .. we'll have to do something like that15:01
woodsterjaosorior: thanks!15:01
atiwariwoodster, yt?15:03
woodsteralee: 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
woodsteratiwari: morning15:03
*** paul_glass has joined #openstack-barbican15:04
atiwarigood morning15:04
atiwariwondering do you have any thoughts on Nathan's comments on my cr15:05
aleewoodster, 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
aleewoodster, does symantec even allow you to update the ca request?15:06
atiwariI 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
atiwariwoodster, I have added my comments in https://review.openstack.org/#/c/111412/15/barbican/plugin/interface/secret_store.py15:07
atiwarican we resolve it today?15:07
atiwariwoodster, another thing.15:09
atiwarigetting "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
aleeatiwari, why do you need ASYMMETRIC_KEY?15:09
atiwarion gate-barbican-devstack-dsvm, do you have any idea?15:09
woodsteratiwari: 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
atiwarialee, I thought we are will check in resource before making the call to generate15:11
atiwarialee, please look at https://review.openstack.org/#/c/111412/15/barbican/plugin/resources.py15:11
atiwarimy comment15:11
woodsteratiwari: 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 same15:12
atiwariwoodster, how to fix this?15:13
atiwarialee, at the same time all the constant from  https://review.openstack.org/#/c/111412/16/barbican/plugin/interface/secret_store.py@SecretType15:14
atiwariare not utilized15:14
atiwarialee, ASYMMETRIC = "asymmetric" will be set on the secret (eventually) to indicate that secret is part of an asymmetric key pair15:17
atiwariright now secret has no type but later it will.15:17
aleeatiwari, well - yes and no -- what about PUBLIC/ PRIVATE15:17
*** Guest22704 has quit IRC15:18
aleeatiwari, PUBLIC/PRIVATE need to be set on the secrets to indicate what they are.15:18
atiwaripublic/private will be set in the container15:18
aleeso whats the point of PUBLIC/PRIVATE?15:19
atiwariwoodster, how can I yank https://blueprints.launchpad.net/barbican/+spec/add-type-field-to-secrets?15:20
atiwariI think Huseyin no more in community15:21
atiwarialee, another issue is HMAC = "hmac"15:23
atiwariwe need that on secret to improve searches15:23
aleeatiwari, well - the same arg might apply to PUBLIC/PRIVATE vs. ASYMMETRIC15:26
aleeatiwari, we might for example, want at some point to allow generate access to public keys - but not to private ones.15:26
atiwarialee, how do you make sure that a generate plug in can generate an Asymmetric?15:28
aleeatiwari, don't we have a supports() method?15:28
atiwarithat is on crypto plugin15:29
atiwariwe need some check on store plugin15:29
aleegeenrate_supports() defined in secret_store.py15:30
atiwaricorrect and that calls get_secret_type(self, alg)15:30
atiwarifrom barbican/plugin/interface/secret_store.py15:30
atiwariwoodster, I am adding spec for https://blueprints.launchpad.net/barbican/+spec/add-type-field-to-secrets. need your opinion15:32
*** Guest22704 has joined #openstack-barbican15:34
aleeatiwari, there are two questions here -- what secret type should be stored in the secret_table?  and whether we need an ASYMMETRIC type.15:34
aleeatiwari, I'm coming to the view that we should store PUBLIC/PRIVATE in the secret table15:35
atiwarialee, right now there is no way to store type in secret15:35
aleebecause it provides us with much more info for searches , access control etc.15:35
aleeah - so this is all in the metadata then.15:36
atiwarialee, I am planning to implement type soon15:36
atiwarion secrets15:36
atiwarialee, initially we thought that secret will be a generic resource and container will define public or private15:37
atiwariwe need some way (same as supports() in crypto plugin ) in store crypto to check if it support asymmetric keys15:39
aleeatiwari, 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
aleeatiwari, I'm more interested in what we put into the db15:40
aleeatiwari, can someone store a public key (as a public key)?15:41
*** kebray has joined #openstack-barbican15:43
aleeatiwari, how do I search for all the public keys available?15:43
aleewoodster, atiwari - does it make sense to store the secret_type as part of the secret_table?15:44
*** gyee has joined #openstack-barbican15:45
atiwarialee, there are two concerns 1)search 2)check support for Asymmetric type on store_crypto15:46
atiwarialee, are we on same page ?>15:46
aleeatiwari, 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
atiwarialee, yes15:48
aleeatiwari, rather than generating on barbican ..15:48
atiwarialee, yes15:48
aleeatiwari, and how does one do that?15:48
atiwariupload pub/pri and associate with container15:48
atiwaricontainer maps the type15:49
aleeok - so upload pub, upload priv, create container, make associations15:49
atiwaricorrect for asymmetric key15:49
aleeatiwari, ok - how do I search for all the public keys ?15:50
openstackgerritArvind Tiwari proposed a change to openstack/barbican: Reorganize code to use store crypto plug-in  https://review.openstack.org/11141215:50
atiwarialee, I think that goes through container search15:52
atiwarisearch container which has pub ref15:52
aleeok what about searches for HMAC?15:54
chellygelalee, in regards to your question -- yes, the customer can update contact information for the cert order15:55
jvrbanacjaosorior, did I address your questions?15:55
atiwarialee, that is why we need https://blueprints.launchpad.net/barbican/+spec/add-type-field-to-secrets15:55
chellygelalee: as well as other things, im digging through the api docs now to verify each case15:55
atiwarialee, I am putting together a spec for the same15:56
aleechellygel, ok thats fine. although I imagine that there will be a number of changes that will be rejected15:57
chellygelyes, hoping that validation would prevent a lot of that before hand15:58
chellygelbut you are right, we need to prepare for these situations ! but i also dont want to make scary huge CRs lol15:59
aleechellygel, 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 metadata15:59
*** paul_glass has quit IRC16:01
aleeatiwari, 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
atiwariyes, at the same time there is no API to pass the type16:03
atiwarialee, ^16:03
aleeok - I guess you can pass in an algorithm and that will define the type ..16:05
aleebut of course its not required.16:05
aleeatiwari, 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
atiwarialee, correct16:11
atiwarilet move up with J :)16:12
aleeatiwari, for what should be defined in secret_store.py, then, we should define only those constants which are needed by barbican-core16:12
aleewhich includes things needed by get_secret_type() which is defined there16:12
aleeare PUBLIC_KEY and PRIVATE_KEY using by barbican-core?16:13
aleeif not, then they should be removed16:13
atiwarialee, OK16:13
aleeand if the plugin wants to define them and use them, then it should do so.16:13
aleeif store_crypto.py needs it, then it should be defined there.16:14
atiwarialee, IMO all the constants there in SecretType are use less right now16:14
atiwarithose are all redundant16:15
atiwarido you agree?16:15
aleedogtag will in fact use PUBLIC_KEY/PRIVATE_KEY but we will define it there16:15
aleeatiwari, well they are only used by get_secret_type() right?16:16
atiwarialee, correct16:16
atiwarithen what is point of having all there?16:16
atiwariIMO, leave it like that and later we will clean them. there are lots of redundancy / useless code16:18
aleeand get_secret_type() is used only by the supports() methods?16:18
atiwarialee, IMO no16:18
atiwarilet me check16:18
*** paul_glass has joined #openstack-barbican16:19
atiwarialee, no  supports() does not use get_secret_type()16:19
aleewe call get_secret_type() when we pass in the secret to the plugins to store.16:20
aleeatiwari, 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_core16:26
aleewhich in this case is PUBLIC_KEY/PRIVATE_KEY16:26
aleeatiwari, 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
atiwarialee, which one should I keep there?16:28
atiwarijust SYMMETRIC = "symmetric"?16:28
aleewell asymmetric is used by get_secret_type() right?16:28
aleewe need rellerreller on here ..16:29
openstackgerritArvind Tiwari proposed a change to openstack/barbican: Reorganize code to use store crypto plug-in  https://review.openstack.org/11141216:34
*** paul_glass has quit IRC16:36
atiwarialee, rellerreller I have fixed the code as per comments16:36
*** bdpayne has joined #openstack-barbican17:04
openstackgerritArvind Tiwari proposed a change to openstack/barbican-specs: spec to add type field on secrets  https://review.openstack.org/11840917:07
openstackgerritArvind Tiwari proposed a change to openstack/barbican: Reorganize code to use store crypto plug-in  https://review.openstack.org/11141217:18
*** rm_mobile has joined #openstack-barbican17:29
*** nkinder has quit IRC17:43
*** paul_glass has joined #openstack-barbican17:46
*** paul_glass has quit IRC17:46
*** paul_glass has joined #openstack-barbican17:46
openstackgerritArvind Tiwari proposed a change to openstack/barbican: Reorganize code to use store crypto plug-in  https://review.openstack.org/11141217:50
atiwarialee, I have fixed you comment17:51
aleeatiwari, ok - +2 for me, lets see if we can get it through ..17:52
atiwarialee, thank17:54
*** bdpayne has quit IRC18:01
*** bdpayne has joined #openstack-barbican18:01
*** kebray has quit IRC18:01
*** kebray has joined #openstack-barbican18:03
*** rm_work|away is now known as rm_work18:04
*** nkinder has joined #openstack-barbican18:06
*** jamielennox|away is now known as jamielennox_18:09
*** rm_work is now known as rm_work|away18:14
openstackgerritArvind Tiwari proposed a change to openstack/barbican: Reorganize code to use store crypto plug-in  https://review.openstack.org/11141218:17
atiwariwoodster, thanks for your pointers on alembic issue18:17
atiwariI have fixed the same and pushed a new patch18:18
jvrbanacjaosorior, ping18:18
woodsteratiwari: sorry for not following up, lots of meetings today...18:18
atiwariwoodster, np I think I found the issue based on your feedback above18:19
atiwarithanks :)18:19
rm_mobilejvrbanac: I see that the third and fourth CRs are not dependent on the earlier ones18:36
rm_mobileI guess we're not doing that? :P18:36
rm_mobileGotta wireless off18:37
rm_mobileTaking off! Back in a bit18:37
jaosoriorjvrbanac: hey, now I'm here18:38
jaosoriorgot an unexpected visit18:38
jaosoriorabout to check your comments now18:39
*** rm_mobile has quit IRC18:41
jaosoriorjvrbanac: are you around?18:45
jvrbanacjaosorior, yeah sorry18:53
jvrbanacjaosorior, was my explanation good enough for you?18:53
jvrbanacjaosorior, on https://review.openstack.org/#/c/118248/18:53
*** ametts has quit IRC18:54
jaosorioryeah, I understand your argument, at the moment I18:55
jaosoriorI'm trying to set up the environment with the newest hacking, so I can verify something18:55
jaosoriorbefore I comment18:55
jvrbanacjaosorior, ahh ok18:56
jaosoriorwhich is if the following is valid: http://pastebin.com/ahf8A4Ki18:56
jaosoriorbecause it is actually valid python syntax, I'm just not sure if hacking has something against it18:57
jaosoriorif you have the environment setup you could also check that19:00
jaosoriorsince when I run the code with the newest hacking (with the changes your CR introduces) there still seem to be a lot of pep8 errors19:00
jvrbanacjaosorior, yeah all of the changes are spread across 4 CRs19:01
jvrbanacjaosorior, the new form you're talking about is a pep8 E113 violation19:02
jaosoriorOK, I wasn't sure about that19:03
jaosoriorI actually dislike that it19:03
jaosoriorit's a violation19:03
jaosoriorbut there's nothing I can do about it19:03
jvrbanacjaosorior, unfortunately. I the the real answer is that we need to refactor those sections19:04
jaosoriortrue that19:04
jaosorioranyway, +119:05
jvrbanacjaosorior, however, I didn't want to get deep into refactoring all the things for just hacking violations.19:05
jaosoriorI agree, you took a good approach19:06
jaosoriorrefactoring is the next step19:06
jaosoriorwoodster: checked your CR also, btw19:06
*** lisaclark1 has joined #openstack-barbican19:08
*** ametts has joined #openstack-barbican19:24
*** lisaclark1 has quit IRC19:51
woodsterjaosorior: Just added responses to your comments19:57
jaosoriorwoodster: in all honesty the use of inspec is quite cryptic,  forgot to ask you what your intention was20:02
woodsterjaosorior: 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 elegant20:03
*** lisaclark1 has joined #openstack-barbican20:04
woodsterjaosorior: would the passing the method name as a string be more explicit and therefore clearer/better?20:04
jaosoriorWell, it would make more sense to me. Since it would be easier to decipher where the name comes from in less time20:06
woodsterjaosorior: it would also be more performant...inspect.stack is an expensive call20:07
aleewoodster, what do the [1][3] mean exactly?20:11
aleewoodster, +1 for passing in function name as a string20:13
*** lisaclark1 has quit IRC20:15
woodsteralee, jaosorior: nice, I'll yank that inspect stuff shortly20:16
*** lisaclark1 has joined #openstack-barbican20:17
*** lisaclark1 has quit IRC20:24
openstackgerritJohn Wood proposed a change to openstack/barbican: Add initial files for certificate event handling  https://review.openstack.org/11530120:24
openstackgerritJohn Wood proposed a change to openstack/barbican: Add initial files for certificate event handling  https://review.openstack.org/11530120:25
*** kebray has quit IRC20:26
*** lisaclark1 has joined #openstack-barbican20:27
woodsteralee, 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 IRC20:30
openstackgerritA change was merged to openstack/barbican: Making a few modules hacking 0.9.2 compliant  https://review.openstack.org/11733420:30
*** atiwari has quit IRC20:45
*** lisaclark1 has joined #openstack-barbican20:54
*** lisaclark1 has quit IRC20:54
*** lisaclark1 has joined #openstack-barbican20:55
*** SheenaG1 has joined #openstack-barbican20:59
*** juantwo has quit IRC20:59
*** lisaclark1 has quit IRC20:59
*** ametts has quit IRC21:10
*** atiwari has joined #openstack-barbican21:18
openstackgerritKaitlin Farr proposed a change to openstack/barbican: Add PyKMIP to requirements  https://review.openstack.org/11753921:21
*** atiwari has quit IRC21:22
*** atiwari has joined #openstack-barbican21:23
*** nkinder has quit IRC21:48
*** ayoung has quit IRC21:54
*** paul_glass has quit IRC21:55
*** atiwari has quit IRC22:14
*** kebray has joined #openstack-barbican22:16
*** SheenaG1 has quit IRC22:21
*** rm_mobile has joined #openstack-barbican22:22
*** jaosorior has quit IRC22:22
rm_mobilejaosorior: pushing that CR in about 30min22:22
rm_mobileDamnit lol22:22
openstackgerritA change was merged to openstack/barbican: Updating API unit and functional tests to new hacking standards  https://review.openstack.org/11824922:23
openstackgerritArun Kant proposed a change to openstack/barbican: Adding keystone notification listener support  https://review.openstack.org/11081722:28
*** rm_mobile has quit IRC22:28
*** rm_mobile has joined #openstack-barbican22:29
*** bdpayne has quit IRC22:31
*** bdpayne has joined #openstack-barbican22:32
rm_mobileDarn it  reaperhulk , I don't think I'll ever get any kind of CR in without writing at least one test :P22:32
rm_mobileNot that I disagree...22:33
*** juantwo has joined #openstack-barbican23:01
*** juantwo has quit IRC23:01
*** juantwo has joined #openstack-barbican23:01
*** AndChat|40521 has joined #openstack-barbican23:03
*** rm_mobile has quit IRC23:04
*** rm_work|away is now known as rm_work23:16
*** jamielen^ has joined #openstack-barbican23:18
openstackgerritArvind Tiwari proposed a change to openstack/barbican: Reorganize code to use store crypto plug-in  https://review.openstack.org/11141223:19
*** jamielennox_ has quit IRC23:20
*** AndChat|40521 has quit IRC23:27
*** bdpayne has quit IRC23:27
rm_workwtf, can't tox py33 because testr returns an error listing tests23:31
rm_workthis makes no sense at all23:31
* rm_work doesn't really understand how testr works23:31
*** jamielennox has joined #openstack-barbican23:31
*** jamielen^ has left #openstack-barbican23:32
*** bdpayne has joined #openstack-barbican23:32
rm_workany more love for https://review.openstack.org/#/c/113393/ ? :P23:40
openstackgerritAdam Harwell proposed a change to openstack/python-barbicanclient: Change object __str__() to use pretty formatting  https://review.openstack.org/11849423:40
rm_workalso, that just happened23:40
rm_workthough it is failing py33 and i am not sure why23:40
*** bdpayne has quit IRC23:55

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