Friday, 2014-08-08

*** bdpayne has quit IRC00:00
reaperhulkthere isn't00:00
reaperhulkso add-header would be a legit thing to try for dsvm00:00
rm_workthough I'm not sure WHERE i add that00:01
rm_worknot in the vassals config i think? because that syntax isn't right for the vassal config00:01
reaperhulklooks like --add-header might work for the CLI and "addheader:Connection: close" is what is potentially used in the configs, but *shrug*00:03
reaperhulkI also find the uwsgi config files baffling00:03
rm_workyeah00:04
rm_workadd-header = Connection: close00:05
rm_workit keeps the quotes if they exist <_<00:05
rm_workand now: * Closing connection 000:05
rm_worknice00:05
rm_workrunning tests...00:05
rm_worktests pass00:05
rm_workalrigh00:05
rm_work*alright!00:05
rm_workso… that's the way to go00:06
rm_workabandoning my patch… <_<00:06
reaperhulkYep, but now you know way more and the next time this obscure BS comes up you'll already remember what to do00:07
rm_workT_T00:07
rm_worktruth00:07
rm_workalways learning00:07
rm_workbut always more to learn :P00:07
rm_workso should I make THIS a separate CR?00:07
rm_workor do it in my change00:08
reaperhulkmake it a separate CR and we can land that immediately00:08
reaperhulkDoes this change it for devstack only or for everything?00:08
reaperhulk(I assume devstack only)00:08
rm_workerr00:08
rm_workwell, whatever uses the default vassal configs00:08
rm_workI assume any operator would be tweaking those00:08
rm_workbecause the default is like, single-process <_<00:08
reaperhulkput it up and people can review. woodster_ may have an opinion there. I am okay with this but I also have way less experience with this server than he does ;)00:09
reaperhulkI suspect it will be fine (plus it's a big bonus that it fixes a serious issue with our testing)00:09
rm_workdoes anyone use *uwsgi* in production? :P00:09
reaperhulkapparently we will00:10
reaperhulkbut we won't use default configs00:10
rm_workhmm… need a commit message00:11
dstufftwrt keep alive00:11
dstufftpython-barbicanclient will I think00:11
rm_workdstufft: hmm, does it?00:11
rm_workwell00:11
dstufftit uses a requests session I think00:11
dstufftand requests sessions use persistent connections00:11
dstufftit'll still *work*00:11
rm_workT_T00:11
dstufftit just won't have persistent connections anymore00:12
*** xianghui has quit IRC00:12
reaperhulkIMO this is basically a (much better) workaround until we pull uwsgi out of our devstack config entirely00:12
rm_workdstufft: should I push this change for review or not? :P would you +1 it?00:12
rm_workor +2, not sure who you are exactly :P00:12
reaperhulkhaha00:12
reaperhulkhe's core.00:12
dstufftI'm fine with it as a work around until we pull uwsgi out of devstack00:12
rm_workkk00:12
*** xianghui has joined #openstack-barbican00:12
dstufftmight want to add a comment that it effectively disables persistent connections though00:13
dstufftand pipelining ofc, but nobody implements pipelining anyways00:13
* dstufft goes again for a bit00:18
rm_workdamnit i typed up a huge message and then git decided it couldn't read the vim output T_T00:19
rm_workalright, typed up an equally lengthy but maybe not quite as good one, reviewing in a sec00:23
openstackgerritAdam Harwell proposed a change to openstack/barbican: Force uWSGI to set "Connection: close" header  https://review.openstack.org/11273500:26
openstackgerritAdam Harwell proposed a change to openstack/barbican: Add support to Barbican for consumer registration  https://review.openstack.org/10784500:28
rm_workoh whoops00:28
rm_workwrong rebase00:28
openstackgerritAdam Harwell proposed a change to openstack/barbican: Add support to Barbican for consumer registration  https://review.openstack.org/10784500:30
rm_workthere we go00:30
rm_workreaperhulk: so when did you think we could get THAT one through? :P00:31
reaperhulkthe force uwsgi?00:32
reaperhulkWe should have that landed tomorrow.00:32
rm_workk00:32
rm_workthat would be awesome00:32
rm_work… shortly followed by my original CR? :P00:32
reaperhulklanded or rejected, but hoping for landed obviously00:33
rm_workheh00:33
reaperhulkI need to re-review that CR, but will do so momentarily00:33
rm_workliterally nothing has changed00:33
rm_worksince the last time you guys reviewed it00:33
rm_workevery patchset has been rebasing00:33
rm_workT_T00:33
reaperhulkso you haven't fixed the things we listed yet?00:33
rm_workerr00:33
reaperhulkNo point to me re-reviewing it if so :)00:33
rm_worksince the last time everyone *workflowed it*00:33
rm_worklol00:33
reaperhulkgotcha00:33
rm_worki thought you were a +2… maybe not00:34
reaperhulklast time i looked at it was Tuesday00:34
reaperhulkyesterday I was flying most of the day00:34
rm_workah nope just the two Johns00:35
rm_workand Doug workflowed it00:35
rm_workthough yeah for some reason i didn't really consider "hey, if i had to recheck 23 times, what does this mean for everyone else if it gets merged"00:35
rm_worknor did everyone else apparently? :P00:35
reaperhulkI did.00:35
rm_worklol00:36
reaperhulkWe discussed it a bit in the context of me saying "this is obviously unacceptable" and everyone else agreeing but none of us knowing what to do about it because nobody wants to dig into devstack00:36
rm_workrofl00:36
reaperhulkSo for doing it yourself you earn big points from me00:36
rm_workwell, for the record I did just about break down and beg for help yesterday (and chellygel was a big help researching the stuff that got me started on the right path)00:37
rm_works/just about //00:37
reaperhulkkudos withdrawn and placed in chellygel's hopper00:38
rm_work:P00:38
rm_workreaperhulk: so where are you now exactly?00:40
reaperhulkMakawao, Maui00:40
rm_worknice00:40
rm_workI have been meaning to do "work from beach"00:41
rm_workare you literally just traveling and working at the same time?00:41
reaperhulkyep00:41
rm_workyeah00:41
rm_workthat's what I'd really like to be doing at some point00:41
rm_workI've talked about working from the Bahamas00:41
reaperhulkToday has been a stupidly productive day since I had to get up at 5am for standup and then just kept working00:41
rm_workheh00:41
reaperhulkPlus the beaches are closed due to inbound hurricane so bah00:41
rm_workmy team is not very "work remote" friendly tho :(00:42
reaperhulkworking remote is challenging. Every team has to develop its own techniques. I've definitely been in situations where it just wasn't practical00:42
rm_workI mean, I think it's perfectly practical, they just don't like it :P00:42
rm_workI mean, I've been at home for the past two hours or so00:44
rm_workway more productive than I was pretty much the whole day *at* work00:45
rm_worktoo much distraction00:45
rm_workI guess I may as well go do something else now, it is 7:45pm :P00:46
rm_workand I suppose I'm just waiting for my patchsets to get approved now00:46
rm_workwell, I have a ton of work to do on the barbican python client, but i have about half of that done already on my machine at work and i didn't get it checked in anywhere yet :(00:47
reaperhulkyep, go do some not code00:47
rm_workthe barbican python client is kind of a mess T_T00:47
rm_workyeah maybe i'll go play some Minecraft :P00:48
*** rm_you has joined #openstack-barbican00:51
*** ayoung has joined #openstack-barbican00:53
*** gyee has quit IRC01:21
*** alee has joined #openstack-barbican01:28
*** bdpayne has joined #openstack-barbican04:26
*** jaosorior has joined #openstack-barbican04:48
*** bdpayne has quit IRC05:16
*** bdpayne has joined #openstack-barbican05:21
*** bdpayne has quit IRC05:43
openstackgerritOpenStack Proposal Bot proposed a change to openstack/barbican: Imported Translations from Transifex  https://review.openstack.org/11276406:10
*** crc32 has quit IRC06:50
*** jamielennox is now known as jamielennox|away07:33
*** arunkant has quit IRC10:23
*** arunkant has joined #openstack-barbican10:25
*** ayoung has quit IRC12:13
openstackgerritGerome Chardon proposed a change to openstack/barbican: Clean code  https://review.openstack.org/11284512:29
openstackgerritGerome Chardon proposed a change to openstack/barbican: Clean old comments (already implemented utils.getLogger)  https://review.openstack.org/11284512:45
openstackgerritGerome Chardon proposed a change to openstack/barbican: Clean old comments (already implemented)  https://review.openstack.org/11284512:54
*** lecalcot has joined #openstack-barbican13:05
*** lecalcot has quit IRC13:50
*** russellb is now known as rustlebee13:50
*** ayoung has joined #openstack-barbican13:53
*** lecalcot has joined #openstack-barbican13:56
*** SheenaG1 has joined #openstack-barbican14:02
*** Kevin_Bishop has joined #openstack-barbican14:14
*** akoneru has joined #openstack-barbican14:37
*** mdorman has joined #openstack-barbican14:42
*** paul_glass has joined #openstack-barbican14:50
*** mdorman has quit IRC14:51
*** mdorman has joined #openstack-barbican14:51
jaosoriorGuys, if you have time to review the cliff CR it would be greatly appretiated: https://review.openstack.org/#/c/107587/ I won't be able to log in much at these times (only in the morning) all next week, and the week after that I won't be able to work on stuff at all15:02
*** lecalcot has quit IRC15:06
*** lecalcot has joined #openstack-barbican15:08
*** lecalcot has quit IRC15:08
jvrbanacjaosorior, I reviewed it the other day. I'll try to get a couple more reviewers to look at it. I know a number of people are out on vacation, so things are running a bit slow right now.15:08
*** lecalcot has joined #openstack-barbican15:09
jaosoriorjvrbanac, thanks man :)15:09
jvrbanacalee, redrobot, reaperhulk ^^15:10
rm_workalso https://review.openstack.org/#/c/112735/ :P15:18
rm_workalready got 3x +2s this time15:18
rm_workin record time, so obviously it must be broken and I should abandon it, lol15:18
rm_workwe were waiting on… comment from ryanpetrello I think? and maybe woodster_ and redrobot to take a look15:19
ryanpetrellohrm15:20
*** jenkins-keep has joined #openstack-barbican15:20
ryanpetrellowhat was the reasoning for that?15:20
ryanpetrelloseems a bit heavy-handed15:20
rm_workryanpetrello: yes, it is15:21
rm_workryanpetrello: so, uWSGI apparently doesn't ever set that header15:21
rm_workand I *think* it's not technically pecan's job to set it either15:22
rm_workaccording to the RFC15:22
rm_workso we're trying to make sure: a) whose domain does setting the Connection header fall in? and b) is there a better way to tell uWSGI to do it right?15:23
ryanpetrellohrm15:23
rm_workryanpetrello: uWSGI leaves all connections open, which breaks clients that are expecting (and rightly, because of RFC spec) that they should be sending the Close header15:23
ryanpetrelloI’d expect the server in question to handle that header, not a framework15:23
rm_workright15:24
rm_workso uWSGI *is* the server15:24
rm_workin this case15:24
ryanpetrelloright15:24
rm_workso, then it's uWSGI's problem15:24
ryanpetrellodo other servers illustrate the same issue?15:24
ryanpetrelloe.g., did you try gunicorn?15:24
rm_workI have never heard of gunicorn :)15:24
ryanpetrelloyea, I only brought it up because it’s configuration is pretty similar to UWSGI15:25
ryanpetrellopecan also has a plugin15:25
ryanpetrelloe.g., `pip install gunicorn && pecan_gunicorn some_pecan_config_file.py`15:25
ryanpetrelloshould let you test it pretty quickly15:25
rm_workryanpetrello: I can test it15:25
rm_worklet me check15:25
*** ayoung has quit IRC15:26
rm_workso, the part that concerns me is "some_pecan_config_file.py", since we use vassal configs to run our stuff with uWSGI and Paste15:29
rm_workalso, where does pecan_gunicorn come from? :P15:31
rm_workryanpetrello: ok15:40
rm_worktested with a new simple_app15:40
rm_workgunicorn results in:15:40
rm_workconnection closed15:41
rm_workuwsgi results in:15:41
rm_workconnection left intact15:41
rm_workfor a simple curl15:41
rm_workso yeah, uwsgi is not operating properly (at least by default)15:41
rm_workasking in #uwsgi15:51
rm_workryanpetrello: does this sound like a good explanation of the problem? http://pastebin.com/raw.php?i=Yv5jVpCj15:53
ryanpetrelloyep, that sounds reasonable to me15:53
rm_workso, any idea how I'd convert the barbican vassal configs to use gunicorn? :P15:55
rm_workor would you be ok with merging the change I made to just FORCE the connections to close, on the uwsgi vassal configs (since it only affects uwsgi anyway)15:56
rm_workat least temporarily, until we can properly move away from uwsgi?15:56
ryanpetrellono, I’m okay w/ the UWSGi change15:56
ryanpetrelloit just seemed like a potential UWSGI bug to me15:56
ryanpetrelloand I wanted to understand the problem15:56
rm_workoh, yeah totally15:56
rm_workis anyone actually in the castle today? redrobot / woodster_ / chellygel?15:59
SheenaG1I believe chellygel is on ETO15:59
SheenaG1Not sure about the other two16:00
rm_workwoot, well, at least I've got you SheenaG1 :)16:00
rm_workI guess you're probably not at the castle though...16:00
SheenaG1No, but I'm in the office!16:01
SheenaG1In AUS.16:01
*** gyee has joined #openstack-barbican16:01
rm_workheh16:01
rm_workwas wondering for a sec if you were in SYD16:01
SheenaG1I wish.16:01
rm_workfollow reaperhulk's lead16:02
SheenaG1Work from ANYWHERE16:03
SheenaG1Unfortunately, I'm way less effective in e-threats16:03
redrobotwhen I grow up I want to be a badass who works from anywhere just like reaperhulk16:03
rm_workyeah actually I had been thinking about doing that for a while, reaperhulk beat me to it by a bit though16:04
rm_worknice that his team is cool with that :P16:04
rm_workredrobot: you ARE here :P16:04
rm_workredrobot: go ahead. review and approve THIS change. there's no way this could go badly for me.16:04
redrobotyeah, trying to catch up with IRC.16:04
rm_workhttps://review.openstack.org/#/c/112735/16:04
redrobotrm_work the vassal config?  done16:05
rm_workredrobot: you have a bit, this also goes back to yesterday evening16:05
rm_worknice16:05
rm_workEXCELLENT.16:05
rm_worknow go approve https://review.openstack.org/#/c/107845/ :P16:05
redrobotrm_work the idea is to merge just enough to keep you coming back for more...16:06
rm_workhehe16:06
rm_workwell, you already have me for python-barbicanclient16:07
rm_workguaranteed :)16:07
rm_workI think people wanted to see a BP for the revamp on that?16:08
rm_workI guess I can technically add containers support without doing any of that other stuff16:08
rm_workbut I *would* like to land some of those changes in Juno16:08
rm_workand I know it's apparently not linked to the Openstack release cycle, but, I need to USE the changes in another neutron change inside Juno :P16:09
redrobotyeah, blueprint would be awesome... I just have to make some time over a weekend or something to make it happen.16:09
rm_workalright16:09
rm_workwoo thanks for the +2 woodster_ :P16:12
openstackgerritA change was merged to openstack/barbican: Force uWSGI to set "Connection: close" header  https://review.openstack.org/11273516:18
reaperhulkstatus update: bored by this hurricane/tropical storm16:22
reaperhulktime to review some code16:22
rm_workheh16:22
rm_workreaperhulk: ooh, ooh, do mine :P16:22
reaperhulkthat's the plan16:22
rm_worksweet16:23
rm_work<316:23
reaperhulkI found some more %'s :D16:28
reaperhulk(I am going to let these through because we should do a separate pass to fix it in various other places anyway)16:28
rm_workreaperhulk: lol16:29
reaperhulk+2, all you need is a workflow now16:29
rm_workreaperhulk: i ALMOST fixed the rest of them in the other tests, but i didn't want to bloat this change with other people's stuff16:29
rm_workwere there really more in my code too? T_T16:29
reaperhulkyeah, 3 more16:29
rm_workfff16:29
reaperhulkin repositories.py16:30
reaperhulkdoesn't matter though, we'll fix it as a separate CR16:30
rm_workkk16:31
rm_workwoot.16:36
rm_workjust need redrobot or jvrbanac maybe :P16:36
rm_workjvrbanac: want to review https://review.openstack.org/#/c/107845/ again? :)16:36
*** lecalcot has quit IRC16:36
*** Kevin_Bishop has quit IRC16:36
*** lecalcot has joined #openstack-barbican16:53
*** akoneru is now known as akoneru_lunch16:55
*** paul_glass has quit IRC17:03
*** paul_glass has joined #openstack-barbican17:04
*** bdpayne has joined #openstack-barbican17:12
*** jaosorior has quit IRC17:22
*** lecalcot has quit IRC17:27
*** lecalcot has joined #openstack-barbican17:28
*** bdpayne has quit IRC17:31
*** bdpayne has joined #openstack-barbican17:32
*** akoneru_lunch is now known as akoneru17:46
*** Kevin_Bishop has joined #openstack-barbican17:51
openstackgerritA change was merged to openstack/barbican: Add support to Barbican for consumer registration  https://review.openstack.org/10784517:52
*** ayoung has joined #openstack-barbican17:54
*** lecalcot has quit IRC17:58
*** lecalcot has joined #openstack-barbican18:00
openstackgerritChelsea Winfree proposed a change to openstack/barbican: Add Certificate Interface & Symantec Plugin  https://review.openstack.org/10719018:14
*** SheenaG11 has joined #openstack-barbican18:16
*** SheenaG1 has quit IRC18:19
aleewoodster_, ping18:22
woodster_alee: hey Ade18:24
aleewoodster_, hey -- just a couple of quick questions ..18:25
aleewoodster_, I'm starting to look at implementing the dogtag plugin side of the cert issuance.18:26
aleebut before I do that of course, I need to know whats coming in.18:26
*** jaosorior has joined #openstack-barbican18:26
aleewoodster_, the relevant spec is this one?  https://review.openstack.org/#/c/108429/5/specs/juno/add-certificate-type-to-order-resource.rst,cm18:26
jaosoriorhockeynut, woodster, even though ListOrder in singular sounds strange, I got it from python-openstackclient who usr the same notation for List* commands18:27
jaosorior* woodster_18:28
aleewoodster_, and are there any code CR's yet - or are we waiting for the spec to be approved?18:28
jaosorior* usr18:29
jaosorior* use, damn cellphone18:29
woodster_jaosorior: that sounds reasonable then, could you add that comment to the CR then?18:30
*** SheenaG11 has quit IRC18:31
woodster_alee: there is also a CR that Arvind is working on18:31
jaosoriorI'm not on my computer :/ I'm actually in a festival18:31
*** SheenaG1 has joined #openstack-barbican18:31
aleewoodster_, which one is that?18:32
woodster_alee: this one: https://review.openstack.org/#/c/87405/18:32
*** SheenaG11 has joined #openstack-barbican18:32
woodster_Once that one lands, then we were going to connect the dots to Chelea's CR here: https://review.openstack.org/#/c/107190/18:33
aleewoodster_, wasn't some of that broken up into another CR?18:34
*** SheenaG11 has left #openstack-barbican18:34
*** lecalcot has quit IRC18:34
woodster_alee: I had asked Arvind to split his CR into one for the order type/meta, and one for the asymmetric behaviors.18:35
woodster_alee: So this file is intended to 'bridge' between barbican core and the cert plugins: https://review.openstack.org/#/c/107190/17/barbican/tasks/certificate_resources.py,cm18:35
*** lecalcot has joined #openstack-barbican18:35
*** SheenaG1 has quit IRC18:36
aleewoodster_ yeah - I've been reviewing the smaller one.  BTW, I had asked some questions on that one which we need to hammer out18:36
woodster_alee: So you could add a plugin at the same level as the symantec.py module that implemets the contract.18:36
woodster_alee: We just couldn't invoke that via the orders API until Arvind's CR gets landed.18:36
aleewoodster_, OK - I'll take another look at Arvnd's big CR.18:37
woodster_alee: That sounds good...you'll see my comments on it suggesting things Arvind could do to finihs that CR off.18:37
aleewoodster_, sorry gotta go. back in a hour or so .18:37
woodster_alee: ok18:38
chellygelhey guys my CR failed the py27 test because i didnt have the connection fix that adam had in on my branch. i repushed -- waiting for zuul now18:43
chellygelrather, i rebased and pushed18:43
rm_workwoot woot18:46
rm_workchellygel: that shouldn't have affected any of the tox tests, just the tempest stuff -- it failed on py27?18:47
hockeynutthanks for checking on that jaosorior18:47
openstackgerritKevin Bishop proposed a change to openstack/barbican: First attempt at adding the symantecssl library  https://review.openstack.org/11014418:47
rm_workuhh what happened to openstackgerrit -- it is spitting out the wrong URL format for changes today >_>18:49
rm_workmissing /#/c/18:49
jaosoriorhockeynut: doing my best18:50
*** SheenaG1 has joined #openstack-barbican18:50
hockeynut:-)18:51
Kevin_BishopHey woodster_, I updated the CR if you'd like to take a look.18:51
rm_workweird though, i see it there in py27 too, so strange, didn't think those tests used uwsgi at all18:51
Kevin_BishopThanks in advance18:51
rm_workchellygel: oh shit, did that py27 fail with the same Conection Reset error, except *during the cryptography build*?!18:52
rm_work2014-08-08 16:51:52.008 |   File "/home/jenkins/workspace/gate-barbican-python27/.tox/py27/build/cryptography/setup.py", line 174, in <module>18:52
rm_work2014-08-08 16:51:52.015 | ERROR:   py27: could not install deps [-r/home/jenkins/workspace/gate-barbican-python27/requirements.txt, -r/home/jenkins/workspace/gate-barbican-python27/test-requirements.txt]18:52
woodster_chellgell, rm_work: that looks like a socket exception, maybe trying to reach pypi?18:52
rm_workit didn't even get to the barbican code18:53
rm_workyeah, not related to my fix18:53
rm_workjust looks the same :P so i can see the jump to that conclusion18:53
woodster_chellgell: Maybe try a recheck no bug on that18:53
rm_workit was during the PyTest run for cryptography it looks like? maybe reaperhulk has an idea, but hopefully it's a one-time18:54
woodster_Kevin_Bishop: thanks, I'll take a look18:54
rm_workwoodster_: well she already had to rebase on mine, so the time for recheck is a bit late18:54
rm_workher change is queued in Zuul right now18:55
woodster_that's true...just wait it out. :)18:55
chellygelhaha, just got this18:57
chellygelglad that all got resolved without me looking18:57
rm_workchellygel: thanks again for setting me on the trail for that issue -- finally got all merged in :)18:58
chellygel:) we are all a team!18:58
rm_workI guess you are my team-away-from-home19:25
rm_work:)19:25
reaperhulkoh look, rm_work's CR landed19:26
rm_workreaperhulk: :P19:26
rm_workthanks for the effort19:26
reaperhulknot much effort on my part compared to you19:26
reaperhulkWhile I have power and wifi again I'm going to try to quickly submit the % => format CR19:26
rm_workwell, some at least :)19:26
rm_workreaperhulk: i was thinking about just whipping that out19:27
rm_workbut you can have it if you want :P19:27
rm_workdoes it need a bug filed?19:28
rm_workthat's the only part i'm not really a fan of :P19:28
hockeynutwoodster ping19:29
hockeynutwoodster_ ping19:29
hockeynutwoodster_____________________________ ping :-)19:29
hockeynutah, nevermind - found an existing bug that tsv opened.  Failing a PUT to secret with binary data.  Bug is https://bugs.launchpad.net/barbican/+bug/135098819:31
reaperhulkso many %s...19:33
aleewoodster_, ping .. back.  So did you see my question in https://review.openstack.org/#/c/111412/4/barbican/plugin/resources.py,cm ?19:37
woodster_hockeynut: let me know if you still need help19:47
hockeynutjust ran into the bug I linked to above.  I put some more info into launchpad for it.  tsv is assigned to it19:47
hockeynutwe have a comment in the code (see the remarks I added to the bug) and a flag that seems to indicate limitations to secret payloads to be text only19:49
woodster_alee: looking at question too...19:49
hockeynutmultithreaded woodster_ !19:50
openstackgerritVenkat Sundaram proposed a change to openstack/python-barbicanclient: remove tenant-id from uri  https://review.openstack.org/11214919:50
rm_workwow, so19:52
rm_workreaperhulk / dstufft: http://tools.ietf.org/html/rfc7230#section-6.319:52
rm_workaccording to this19:52
rm_workA recipient determines whether a connection is persistent or not19:52
rm_work   based on the most recently received message's protocol version and19:52
rm_work   Connection header field (if any):19:52
rm_work   o  If the "close" connection option is present, the connection will19:52
rm_work      not persist after the current response; else,19:52
rm_work   o  If the received protocol is HTTP/1.1 (or later), the connection19:52
rm_work      will persist after the current response;19:52
rm_workso the DEFAULT is actually keep-alive19:52
rm_workunless the client specifically passes in a Connection: close header19:53
reaperhulkyeah HTTP/1.1 has been that way from the beginning19:53
reaperhulk1.0 is the only thing that required keep-alive to be explicitly passed19:53
aleewoodster_, right - so it seems like we need to specify at least some fields in the container_metadata so that barbican-core knows what to look for.19:54
aleewoodster_,  and make that explicit in the plugin contract19:55
woodster_hockeynut: The two step secret create should work like this: https://github.com/cloudkeep/barbican/wiki/Application-Programming-Interface#two-step-plain-text-secret-createretrieve19:55
aleewoodster_, either that or we need to return a tuple with each of the individual fields19:55
rm_workreaperhulk: so then it's gunicorn that is operating in a strange way and closing all connections?!19:56
rm_workthough it looks like that's because gunicorn doesn't *support* keepalives19:56
dstufftrm_work: isn't the client sending Connection: close19:59
rm_workI am actually not sure20:00
rm_workIt might not be?20:00
hockeynutwoodster_ this is 2 step binary20:00
dstufftif the client wasn't sending Connection: close then the middleware wouldn't do anything20:00
rm_workmaybe all of our tests need to have extra headers added?20:00
rm_workah20:00
rm_workyeah, that is true20:00
dstufftbecause you're just reflecting the value the client sent20:00
woodster_ale: just added a comment to that CR20:00
rm_workwell, i am testing again with this simple-app20:00
rm_workand adding Connection:close to my curl request does not do anything there either :/20:01
rm_workso yeah20:01
dstufftalthough the client should be closing conncetions after it receives a response if it sent Connection: close20:01
rm_workuwsgi is not respecting the connection:close I've sent as the client20:01
dstufftbut the server should also be closing connections20:01
woodster_alee: a tuple would probably be cleaner actually20:01
dstufftrm_work: I have all of this in my brain right now because I've been writing an HTTP server heh20:03
dstufftso the RFCs are fresh on my mind20:03
aleewoodster_, yes - I think so too.  no DTO needed20:05
rm_workLOL ok20:05
rm_work[15:04:03]  <rm_work> so basically, uWSGI is not intended to be operated without another proxy?20:05
rm_work[15:04:12]  <rm_work> and by itself is not RFC compliant20:05
rm_work[15:04:17]  <unbit> yes for sure20:05
rm_work[15:04:25]  <unbit> as well gunicorn is not expected to be put on the public network20:05
rm_work[15:04:34]  <unbit> as well as basically every application server20:05
reaperhulkheh, that's an oversimplification. while most app servers do have something in front, not all are designed to require it20:05
rm_workwhelp, uWSGI is20:06
rm_workso that's that then20:06
rm_work[15:06:41]  <rm_work> so you would never recommend we expose uWSGI directly20:07
rm_work[15:06:48]  <unbit> absolutely20:07
woodster_rm_work: I have seen blogs that put nginx in front of uwsgi, in the context of performance optimization though20:12
rm_workyeah, well… apparently in the case of uwsgi it isn't considered "optional"20:13
*** openstackgerrit has quit IRC20:20
chellygelcan i get a workflow +2 again? https://review.openstack.org/#/c/107190/20:30
chellygelO:)20:31
dstufftgunicorn is not designed to be exposed publically20:33
dstufftdoing so makes it trivial to DoS20:33
rm_workyeah20:33
rm_workapparently same with uwsgi20:33
dstufftI don't tihnk that's ane xcuse for implementing HTTP wrong though20:33
dstufftHTTP Proxies are supposed to operate using the same HTTP as a client would20:35
reaperhulkokay chellygel +1 approving20:36
SheenaG1w00t w00t20:36
woodster_in uwsgi's defense, there are about a million ways to configure it :)  There is probably a configuration needed to make it work correctly in this case. The uwsgi mailing is is also very responsive if there is concern20:37
reaperhulkgiven that rm_work just talked to uwsgi's author I'd say having it work "correctly" is actually unlikely.20:40
rm_workyeah he was basically like "why are you doing this"20:40
rm_workand "no, it is operating as designed"20:41
rm_workand "if you need it to work the way you are expecting, use nginx or some other proxy in front"20:41
rm_workhe claimed that adding "--http-keepalive" to the args would cause it to actually parse the headers (which it normally doesn't do at all) but that just makes it add "keep-alive" if necessary, and doesn't ever add "close" still :(20:42
*** bubbva has quit IRC20:43
*** bubbva has joined #openstack-barbican20:43
woodster_rm_work: well, we have talked about moving from uwsgi to another container, mainly for devstack though. But maybe for local/demo deployments as well?20:43
rm_workyeah, I think uwsgi is maybe just not a good way to go20:44
rm_workor else, just leave this workaround in place, since it seems to be fine for demo/test deployments <_<20:44
reaperhulkthere, that was a bunch of tedious BS20:47
rm_workreaperhulk: ah, you completed the %s fixes?20:51
reaperhulkdunno about completed. got the vast majority of them though20:51
reaperhulkI'll have to think about whether I want to write something to gate them20:51
woodster_chellygel: Congrats!20:54
dstufftgunicorn is a pretty OK container, so is twisted20:55
*** paul_glass has quit IRC20:56
hockeynutreaperhulk - a lot of those go away when tsv's CR for removing tenant ID from URIs lands.20:58
reaperhulkso this is going to be a colossal conflict20:58
reaperhulkhooraaaaay20:58
reaperhulk(his can land first)20:58
hockeynutno matter what, you can always answer "doesn't matter...I'm at the beach"20:59
*** alee is now known as alee_afk21:01
woodster_that should be reaperhulk's away message21:03
*** SheenaG1 has quit IRC21:14
*** Kevin_Bishop has quit IRC21:17
rm_workwell, is reaperhulk ETO or actually still working, just not from here? :P21:37
*** bubbva has quit IRC21:40
reaperhulkI dunno what ETO is21:42
reaperhulkalways workin'21:43
rm_work:P21:43
rm_workuhhh hmmm i may have a problem21:48
*** lecalcot has quit IRC21:50
*** lecalcot has joined #openstack-barbican21:51
rm_workI am pretty sure cd70a208c621400c3a26efccdf0a3135ff6ed44b breaks getting secrets for my setup...21:55
rm_workhttp://pastebin.com/raw.php?i=AMNuiGmQ21:56
rm_workappears when trying to get a decrypted secret (in a local dev setup)21:56
rm_workonly after that commit21:56
rm_workyep21:57
rm_workthat commit added an arg to the __init__ of SecretDTO21:57
rm_workand didn't update all of the places that call it21:58
rm_workspecifically "store_crypto.py" line 108-11021:58
rm_worki think it should be transport_key=None21:58
rm_workalee_afk: you are afk i guess T_T21:59
rm_workalthough interestingly on the FIRST attempt to retrieve a secret right after running the barbican server, I get a different error (but really only the first time):22:01
rm_workhttp://pastebin.com/raw.php?i=QUrUZ24U22:01
rm_workthough that seems to happen before that commit too :(22:03
rm_workso not related to alee_afk's change22:03
rm_workreaperhulk: you around to see what I'm talking about?22:05
rm_workhmm, stopped being able to reproduce the second thing22:07
rm_workbut the first issue is still valid -- cd70a208c621400c3a26efccdf0a3135ff6ed44b introduces a regression for getting decrypted secrets22:08
rm_work"Code to pass through transport_key_id when storing secret"22:08
rm_workeven the comment:22:09
rm_work:param transport_key: presence of this parameter indicates that the22:09
rm_work               secret has been encrypted using a transport key.22:09
rm_workimplies it should be optional, I believe22:09
*** lecalcot has quit IRC22:29
*** lecalcot has joined #openstack-barbican22:30
*** crc32 has joined #openstack-barbican22:31
rm_worklooks like there was only one spot missed22:34
rm_workthe fix could also be to just pass "None" there22:34
rm_workagain -- StoreCryptoAdapterPlugin.get_secret on line 10822:35
*** openstackgerrit has joined #openstack-barbican22:39
woodster_rm_work: Ugh. I think we need to push for 100% coverage, starting to bite us after these big restructures22:45
*** lecalcot has quit IRC22:45
rm_workwoodster_: so what do you think -- the parameter becomes optional, or we change the one place that was missed to pass a None?22:46
rm_workwish alee_afk was here to comment22:46
rm_workI am GUESSING the original intent was for it to be an optional parameter22:47
woodster_rm_work: the transport key is always optional22:47
rm_workyeah22:47
rm_workI assumed so22:47
rm_workit's a two-line change (only because PEP8 forces it onto the next line)22:48
rm_workshould I just… git-review it?22:48
rm_workwoodster_: ^^22:49
woodster_rm_work: if it fixes that test, yes please22:51
rm_workthere doesn't appear to BE a test for it22:51
rm_workI only noticed because I am testing the client and I need to actually get decrypted secrets in it :P22:51
rm_workI guess maybe I should also write a test that would catch this… <_<22:52
woodster_rm_work: that would be preferred with that cr, against the LP bug22:53
rm_workwoodster_: "LP bug"?22:54
rm_workoh22:54
rm_worklaunchpad22:54
woodster_rm_work: the issue is we relied a lot on CAFE tests and our jenkins process is down now. We need more pecan tests22:54
rm_workblegh, I have to submit a bug to launchpad: ?22:55
rm_work:/22:55
rm_workalright22:55
rm_workwasn't this merged? https://bugs.launchpad.net/barbican/+bug/134436522:56
rm_workwhy is it still on "Fix Committed"22:56
rm_workwoodster_: https://bugs.launchpad.net/barbican/+bug/135460323:03
rm_worklook ok?23:03
dstufftwoodster_: +1000 100% coverage23:03
rm_worknever submitted a bug to Openstack before23:03
dstufftMandatory coverage is the best23:04
dstufftwoodster_: there's a thing, diff-cover, that makes it so you can see the coverage of lines changed in a patch too23:04
dstufftit's a reasonable balance between 100% coverage all the time and trying to slowly get coverage increased23:04
woodster_Nice!23:04
dstuffthttps://github.com/edx/diff-cover23:05
openstackgerritAdam Harwell proposed a change to openstack/barbican: Make transport_key an optional arg in SecretDTO  https://review.openstack.org/11304423:06
woodster_rm_work, hockeynut  I think Steve might be looking at this too23:06
rm_workhmm k23:06
rm_workwelllllll23:06
rm_workI just put in a review for it :P23:06
rm_workcan always abandon23:06
woodster_Yep!23:07
woodster_dstufft: we've talked about making 100% coverage a gate23:08
dstufftwoodster_: yea, the diff-cover thing is a good way to work towards 100% coverage without having to do the giant leap from whatever to 100% in one go23:09
dstufftsince you can make it require 100% coverage for all _changed_ lines23:09
dstufftIOW if you add or change a line, if it's not covered then your patch also needs to add tests23:09
dstufftafter awhile you end up at 100% coverage, or close to it, and mandating 100% coverage is easier23:10
rm_workwell, bbl23:13
rm_workheading to dinner :P23:13
woodster_Thanks again folks have a good weekend23:20
*** mdorman has quit IRC23:25
*** akoneru has quit IRC23:37
*** jaosorior has quit IRC23:42
bdpayneI'm looking into barbican worker configuration.  Looks like there's not default configs under https://github.com/openstack/barbican/tree/master/etc/barbican.  Are the available config options documented anywhere?23:56
*** SheenaG1 has joined #openstack-barbican23:58

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