Monday, 2014-09-22

*** dimtruck is now known as zz_dimtruck00:09
*** zz_dimtruck is now known as dimtruck00:20
*** dimtruck is now known as zz_dimtruck00:30
*** zz_dimtruck is now known as dimtruck00:39
*** dimtruck is now known as zz_dimtruck01:18
*** zz_dimtruck is now known as dimtruck01:19
*** alee has joined #openstack-barbican02:02
*** alee_out has quit IRC02:02
*** dimtruck is now known as zz_dimtruck02:24
*** zz_dimtruck is now known as dimtruck03:41
*** usimba has joined #openstack-barbican03:46
*** dimtruck is now known as zz_dimtruck03:51
*** usimba has quit IRC07:51
*** zz_dimtruck is now known as dimtruck09:34
*** dimtruck is now known as zz_dimtruck09:44
*** juantwo_ has joined #openstack-barbican10:45
*** juantwo has quit IRC10:48
*** juantwo_ has quit IRC11:53
*** juantwo has joined #openstack-barbican11:54
*** openstackgerrit has joined #openstack-barbican12:14
*** woodster_ has joined #openstack-barbican12:25
openstackgerritA change was merged to openstack/barbican-specs: Stop using intersphinx  https://review.openstack.org/12129113:02
*** nkinder_ has quit IRC13:12
openstackgerritA change was merged to openstack/barbican: Typos 'asychronous' and 'formated'  https://review.openstack.org/12282513:13
*** denis_makogon has quit IRC13:34
*** zz_dimtruck is now known as dimtruck13:44
*** dimtruck is now known as zz_dimtruck13:53
*** jaosorior has joined #openstack-barbican13:54
jaosoriorHello people :D13:55
*** ayoung has joined #openstack-barbican14:11
*** nkinder_ has joined #openstack-barbican14:14
*** zz_dimtruck is now known as dimtruck14:29
*** atiwari has joined #openstack-barbican14:31
chellygelhey jaosorior !!14:48
chellygelhow are you?14:48
jaosoriorchillin' reviewing some code14:50
jaosoriorhow's it going over there?14:50
jaosoriorParis already booked and everything? :D14:51
chellygelhaha yeah, it looks like the team is getting everything ready for the presentation :)14:55
chellygelyou will be going, right?14:55
jaosoriorawesome, where are you guys staying?14:55
chellygelumm, im not sure. i'm not able to go this year!14:56
chellygelbut, i think they are taking care of all that stuff this week14:56
*** paul_glass has joined #openstack-barbican14:56
chellygelhope its close enough to grab a beer with you though! haha14:56
chellygelor wine.. whatever14:56
chellygelhaha14:56
*** bubbva_ has quit IRC14:57
*** bubbva_ has joined #openstack-barbican14:58
jaosoriorBoth :P14:58
jaosoriorWell, I'm staying at the Mercure in case they have the option for that one14:58
chellygeli'll pass that along!14:58
jaosoriorBut bummer that you couldn't make it :/14:58
chellygelno worries!14:58
*** paul_glass has quit IRC14:59
chellygelim just going to have high expectations as to the gifts the team has to bring back to me ;P14:59
jaosoriorHaha nice14:59
jaosoriorWhat's new over there?15:00
*** paul_glass has joined #openstack-barbican15:02
chellygelnothing too much on my end. nothing exciting worth sharing15:03
chellygelhow about yourself?15:03
*** paul_glass1 has joined #openstack-barbican15:05
*** paul_glass has quit IRC15:08
*** jamielennox has quit IRC15:22
*** kebray has joined #openstack-barbican15:23
*** jorge_munoz has joined #openstack-barbican15:27
rm_workjaosorior: thanks for the +1s :) hopefully should be in a state where people can pass these reviews without too much hesitation15:40
jaosoriorrm_work: no prob dude. Sorry about the delays in the reviews. Lately I've been doing OpenStack stuff only on my free time. Too many other things in my backlog that my PO put as high prio :/ . But hopefully it calms down soon and I can use my work time again :)15:45
*** SheenaG1 has joined #openstack-barbican15:49
redrobotrm_work yo!15:52
woodster_jaosorior: thanks for the free cycles on Barbican!15:54
openstackgerritArvind Tiwari proposed a change to openstack/barbican: Code clean-up due to type order enhancement  https://review.openstack.org/12126915:57
rm_workredrobot: :)15:58
rm_workredrobot: you wanna go +2 me? :)15:59
redroboteh... it's definitely much better15:59
redrobotwhat's the deal with the **kwargs in the constructors?  why do we need to account for unexpected arguments?16:00
redrobotThey're not being used in the constructor AFAICT16:00
redrobotany chance we can make consumer registration work off the Continaer objects?16:01
redrobotDo we still want to have the delete() method on the Container?  I'm not seeing it right now.16:06
*** usimba has joined #openstack-barbican16:09
rm_workredrobot: **kwargs in the constructors allow passing through the direct response from a GET, which includes some stuff we throw away16:09
*** usimba has quit IRC16:09
*** usimba has joined #openstack-barbican16:09
redroboteh... that's ugly. :-\16:10
rm_workredrobot: the whole point of consumer is that we DON'T ever do a GET without registering, and if it were on the objects, it'd require GETing the object first :P16:10
rm_workredrobot: if you saw the alternative, you'd say this was really clean :)16:10
rm_workthe alternative is mangling the GET returns manually16:11
redrobotI would prefer that, since consumer code won't see it anyway.  I would rather consuming code not be allowed to pass in whatever to the constructor16:11
rm_workeither blacklisting some attributes (which assumes we know 100% of what's coming back, and would break if anything new showed up) or whitelisting by creating a new dict, which would be crazy verbose and really just isn't necessary16:11
rm_workredrobot: well, consuming code doesn't ever call the constructors16:12
redrobotit's a public class, so they're not _supposed_ to instantiate directly, but they could anyway, and allowing **kwargs doesn't sit well with me16:12
rm_workwell, what exactly could they do with it?16:13
rm_workthey literally get thrown away16:13
rm_workand that is preventing what would probably be an extra 40 lines of code for no reason16:13
redrobotright, but the signature of the constructor allows anything to be passed in.  I would rather be explicit about what is needed to instantiate the object.16:13
rm_workit is explicit about what is actually used16:14
rm_worki'm not JUST using kwargs16:14
redrobotright, but catch-all kwargs is a bad practice in my book.16:14
redrobotespecially because we're not doing anything with it16:14
rm_workI'll pastebin you later today what the alternative looks like16:14
rm_workit is really ugly16:14
rm_workand makes the factory methods gross16:15
rm_workfor, again, no real benefit that I can see16:15
rm_workredrobot: nothing against pep8 here for you to fall back on… >_>16:16
rm_workdon't think I'm going to be changing this one :(16:16
rm_workwould be sad to not get your +2, but not the end of the world I guess16:16
redrobotnope, just my opinion that **kwargs make for ugly fragile code16:17
rm_workredrobot: funny, because the alternative is what's fragile :P16:17
rm_workkwargs here specifically prevent breakage in any scenario16:17
rm_workI'm interested in your definition of "fragile"16:18
redrobotbasically, what you see as a benefit "I can pass in whatever, and it doesn't matter" seems like a deficiency to me.  I would prefer that constructors accept only what they need16:19
redrobotit encourages bad code in that you no longer care about what is bing passed in, to the point where you don't really know what goes in, and whether it's needed or not.16:20
redrobotmakes it harder to refactor later, so you'll always need **kwargs there.16:20
rm_workredrobot: would you seriously rather mangle the REST Response from Barbican to remove specific variables?16:20
rm_workor the alternative16:20
rm_workwould you rather specifically compile a new dict to pass through?16:20
rm_workI'd assume the latter would be the only reasonable choiced16:21
rm_work*choice16:21
redroboteither that, or explicity .get every property you need from the response16:21
redrobotwe don't expect users of the lib to pass in raw responses, so I don't think we should expose that in the method sigs16:22
rm_workwe don't expect users to USE the classes directly either16:22
redrobotthey could, by reading the constructor sig, and passing in the client object.16:24
woodster_rm_work: what are the **kwargs there for again?  I don't see them used?16:24
rm_workthey are not used16:24
rm_workthey're to allow a clean interface between the constructors for the classes and the GET Response from Barbican16:25
rm_workwe pull out what we want as specific args and leave the rest of the stuff we don't care about in kwargs16:25
reaperhulkand this is to avoid building a new dict?16:25
redrobotor to avoid .getting every property we do need.16:26
rm_workyes, because what is the point of building a new dict here?16:26
rm_workyeah, those two16:26
rm_workI could also have put in each arg specifically and just not used them16:26
redrobotI don't think avoiding either one of those is worth adding a catch-all to the constructors16:26
reaperhulkThe point is you're now creating an implicit assumption that the kwarg naming in the constructor will always match the key naming in the JSON response...16:26
rm_workthat is the idea, yes -- the constructor should match the barbican GET response16:27
redrobotI think that .getting each property individually also gives you the benefit of not necessarily needing the response to match the constructor.16:27
rm_workI guess that just falls into the category of painfully verbose, to me -- since we know what's getting read on the other side, what's the difference? we're now ignoring anything left in the original dict, just the same16:29
rm_workit's getting thrown away without being read exactly the same16:29
rm_workjust now we're being 15 times as verbose but in a redundant way16:29
redrobotrm_work yes, but we don't have to add a catch-all **kwargs to the constructor signature.16:30
redrobotand I see that as a huge benefit16:30
rm_worki still don't see why16:30
redrobotsince these are not private classes, and they could be instantiated by consuming code16:30
rm_worksure16:30
rm_workbut… why is that dangerous?16:30
redrobotbasically reducing the contract of the constructor16:30
rm_workdo you think people will just randomly code their stuff to throw funny args at it like "haha_my_extra_arg=8" for no reason?16:31
redrobotit's not dangerous, per-se.  I think it's just ugly/bad code.16:31
rm_workI'm firmly in the camp that the alternative looks worse16:32
rm_workI think if you go back just a bit in patchsets, it WAS explicit16:32
rm_workat some point16:32
rm_workblah, if *everyone* likes it better your way, fine <_<16:34
rm_workthis just looks 100% cleaner to me16:34
rm_workit's depressing watching this stuff go from slick and clean to … bleh16:35
redrobotsorry rm_work...  It's just that I'd rather have a clean interface, than clean code16:36
openstackgerritA change was merged to openstack/kite: Work toward Python 3.4 support and testing  https://review.openstack.org/11878016:36
redrobotthe interface hides the uglyness16:36
redrobotrm_work care for some Korean loonch?16:41
rm_workredrobot: i'm down16:41
rm_workwhich one16:42
rm_workredrobot: will have to meet you there, I'm at home :P16:42
redrobotSeoul Asian Market & Cafe16:42
rm_workbut could leave whenev16:42
redrobotchellygel and I are leaving the rack in 3 min.16:42
rm_worklol k16:42
rm_workmight be a few after you16:42
rm_workbut i'll leave now16:42
rm_workfeel free to be delayed slightly :P16:46
*** bdpayne has joined #openstack-barbican16:51
*** juantwo_ has joined #openstack-barbican17:00
*** juantwo has quit IRC17:03
*** gyee has joined #openstack-barbican17:21
*** akoneru has joined #openstack-barbican17:34
*** gyee has quit IRC17:43
*** gyee has joined #openstack-barbican17:53
*** juantwo_ has quit IRC18:01
*** juantwo has joined #openstack-barbican18:01
*** arunkant_work has joined #openstack-barbican18:01
arunkant_workwoodster_, jvrbanac: Can you please review https://review.openstack.org/#/c/110817/ . There are no significant changes since your last review.18:27
*** gyee has quit IRC18:30
*** openstack has joined #openstack-barbican18:55
aleewoodster_, jvrbanac redrobot - can you start reviewing https://review.openstack.org/117845 ?18:55
*** jenkins-keep has joined #openstack-barbican19:09
*** kebray has quit IRC19:30
*** kaitlin-farr has joined #openstack-barbican19:45
*** rellerreller has joined #openstack-barbican19:46
SheenaG1redrobot: we still having the 3 o'clock?19:59
redrobotSheenaG1 yes!  Thanks for the heads up19:59
SheenaG1woot woto19:59
SheenaG1woot*19:59
redrobotWeekly Meeting starting now in #openstack-meeting-alt20:00
*** gyee has joined #openstack-barbican20:02
*** kebray has joined #openstack-barbican20:08
*** ayoung is now known as ayoung-afk20:20
*** jaosorior has quit IRC20:22
*** kebray has quit IRC20:26
*** kebray has joined #openstack-barbican20:30
*** usimba has quit IRC20:49
*** bdpayne has quit IRC20:57
aleeakoneru, so you're all set then on the jenkins errors?20:58
akonerualee, yes. i will know once i update my CR.20:58
openstackgerritAbhishek Koneru proposed a change to openstack/barbican: Add asymmetric key generation in dogtag plugin  https://review.openstack.org/11784521:11
atiwariredrobot, yt?21:17
redrobotatiwari yep, what's up?21:17
atiwariredrobot, wondering what is holding https://review.openstack.org/#/c/118697/?21:17
atiwarido we need more review ?21:18
redrobotatiwari yeah, looks like it just needs someone to +Worflow.  If I have time today, I'll take a look at it.21:18
atiwariok21:18
atiwariredrobot, one more. can some look in to https://review.openstack.org/#/c/121269/?21:19
atiwarithanks21:19
redrobotatiwari I'll try to get to that too, have you looked into the dsvm failure?21:20
atiwariredrobot, yep "The Barbican (non-admin) API failed to respond within 20 seconds"21:20
atiwarican not relate with change I have made21:21
atiwariI will also dig more21:21
openstackgerritArvind Tiwari proposed a change to openstack/barbican: Code clean-up due to type order enhancement  https://review.openstack.org/12126921:29
*** SheenaG1 has quit IRC21:30
*** bdpayne has joined #openstack-barbican21:30
*** alee is now known as alee_meeting21:31
*** rellerreller has quit IRC21:32
rm_workredrobot: oh, and yeah, .delete() was inexplicably missing, I've added it21:48
*** paul_glass1 has quit IRC21:49
openstackgerritA change was merged to openstack/barbican: Fixing the PYTHONHASHSEED bug with our unittests  https://review.openstack.org/12138622:12
*** kaitlin-farr has quit IRC22:22
akonerureaperhulk, ping22:23
reaperhulkwhat's up22:23
reaperhulkSaw you pinging over the weekend, sorry I didn't catch you22:23
akonerureaperhulk, i have a problem with my CR. the gate-barbican-python26 tests are failing. need some help22:25
akonerureaperhulk, in the console.html, i see the following error - barbican.tests.plugin.test_dogtagNon-zero exit code (2) from test listing.22:25
akonerureaperhulk, the complete log - http://logs.openstack.org/45/117845/6/check/gate-barbican-python26/1ed319b/console.html22:25
reaperhulktaking a look22:27
reaperhulk:/ useless console output, heh22:28
reaperhulklet me try checking your CR out and running locally22:28
akoneruhttps://review.openstack.org/#/c/117845/22:28
akoneruhmm. ok.22:28
rm_workredrobot: I decided to move my line a bit, I'm willing to show the user something they shouldn't really be seeing in the function signature, in order to keep the code quite a bit cleaner22:30
rm_workabout to submit22:30
reaperhulkwell at least it's consistent. I'm able to replicate locally. Now to convince testr to actually show me something useful.22:30
redrobotrm_work smh... so totally not what we all agreed on :-P22:31
rm_work<_<22:31
akonerureaperhulk, so, you seem to be running tox - i tried setting it up but wasn't able to do it. Any docs i can refer to?22:31
rm_workI think you'll be ok with it22:32
redrobotmaybe?  ...  are you specifying secre_refs in the RSA and Cert containers?22:32
redrobotif so, what happens when I set it?22:32
reaperhulkakoneru: All you need for tox is "pip install tox". Then when you do something like "tox -e py26" it will build a virtualenv and run the tests inside it based on the config in tox.ini (py26 being python 2.6 of course)22:32
rm_workredrobot: right, that's exactly it... and if you set it... it "works", but there's no validation, so it might explode when you try to save it, but that's the user's fault I guess22:33
rm_workbut if they actually do set it up right, it'll work22:33
rm_workjust sub-optimal, IMO22:33
redrobotso what does dir(RSAContainer.__init__) have to say?22:33
rm_workI'm actually testing now to make sure that what I just said is correct22:34
rm_workwell, i got delayed a bit by pulling barbican master and having to reset my DB22:34
akonerureaperhulk, ok22:34
redrobotit would be awesomer if it just wasn't in the init args at all22:34
rm_workwell, they're ... a bit different22:34
rm_workis the problem22:35
rm_worksecret_refs is a list of *refs*22:35
rm_workthe other args (the ones used for creation) are supposed to be Secret objects22:35
rm_workso the only way to keep it lazy on get() operations is to continue to allow secret_refs to go through22:35
redrobotbut for RSAContainer for example, you wouldn't be able to user secret_refs correctly anway.22:36
rm_workwell, you *could*22:36
rm_workit's possible22:36
redrobotsince you cant' specify which is what in a list?22:36
rm_workyou can22:36
rm_workit's just hard :P22:36
rm_workand actually, I realized I was being inconsistent with that22:37
redrobotso, it's a list of hrefs you pass to the Container constructor?22:37
rm_workyes22:37
jenkins-keepProject openstack-barbican-cloudcafe build #35: STILL FAILING in 14 min: http://jenkins.cloudkeep.io/job/openstack-barbican-cloudcafe/35/22:37
jenkins-keepJohn Vrbanac: Fixing the PYTHONHASHSEED bug with our unittests22:37
rm_workwhich is a bit funky22:37
rm_workI am changing it now to take a list of Secrets22:38
rm_workI think22:38
rm_workwell22:38
rm_workboth, technically22:38
rm_worksince it still needs to be able to take the refs to stay lazy <_<22:38
rm_workhonestly it is WAY easier to just create it and use the .add() function, lol22:39
redrobothaha... then remove secret_refs from the constructor altogether?22:39
rm_worktempted, but then it doesn't adhere to the BP22:40
redrobotthat's ok, I think we're way past adhering to the BP by now22:40
rm_worktrue22:40
reaperhulkakoneru: Your problem is a syntax error in python2.6 on line 150 of dogtag.py22:40
reaperhulk        if secret_type in {sstore.SecretType.PUBLIC,22:40
reaperhulk                           sstore.SecretType.PRIVATE}:22:40
reaperhulkThat isn't valid syntax in python 2.622:40
reaperhulkSwitch it to a list or tuple22:41
akonerureaperhulk, oh. thanks! will get it corrected. So for running tox -e py26, should i pre install pyhton 2.6 on the system? Or will tox install 2.6 in the virtualenv that it creates?22:42
reaperhulkYeah you'll need "python2.6" available in your $PATH22:42
reaperhulkSo pre-install it22:42
akonerureaperhulk, oh. ok. thanks!22:43
rm_workredrobot: oh, right, I remember now why I used secret_refs22:45
*** kebray has quit IRC22:46
rm_workerk, maybe not22:46
rm_workthis is a mess T_T22:46
rm_worki'm going to redo this whole bit22:46
redrobotrm_work (╯°□°)╯︵ ┻━┻22:47
rm_workyes22:47
woodster_¯\(°_o)/¯22:53
chellygellololol23:03
*** dimtruck is now known as zz_dimtruck23:05
openstackgerritAbhishek Koneru proposed a change to openstack/barbican: Add asymmetric key generation in dogtag plugin  https://review.openstack.org/11784523:06
*** nkinder_ has quit IRC23:07
*** akoneru is now known as akoneru_afk23:23
*** akoneru_afk has quit IRC23:28
*** atiwari has quit IRC23:29
*** zz_dimtruck is now known as dimtruck23:42
*** arunkant_work has quit IRC23:54

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