*** bdpayne has quit IRC | 00:00 | |
reaperhulk | there isn't | 00:00 |
---|---|---|
reaperhulk | so add-header would be a legit thing to try for dsvm | 00:00 |
rm_work | though I'm not sure WHERE i add that | 00:01 |
rm_work | not in the vassals config i think? because that syntax isn't right for the vassal config | 00:01 |
reaperhulk | looks like --add-header might work for the CLI and "addheader:Connection: close" is what is potentially used in the configs, but *shrug* | 00:03 |
reaperhulk | I also find the uwsgi config files baffling | 00:03 |
rm_work | yeah | 00:04 |
rm_work | add-header = Connection: close | 00:05 |
rm_work | it keeps the quotes if they exist <_< | 00:05 |
rm_work | and now: * Closing connection 0 | 00:05 |
rm_work | nice | 00:05 |
rm_work | running tests... | 00:05 |
rm_work | tests pass | 00:05 |
rm_work | alrigh | 00:05 |
rm_work | *alright! | 00:05 |
rm_work | so… that's the way to go | 00:06 |
rm_work | abandoning my patch… <_< | 00:06 |
reaperhulk | Yep, but now you know way more and the next time this obscure BS comes up you'll already remember what to do | 00:07 |
rm_work | T_T | 00:07 |
rm_work | truth | 00:07 |
rm_work | always learning | 00:07 |
rm_work | but always more to learn :P | 00:07 |
rm_work | so should I make THIS a separate CR? | 00:07 |
rm_work | or do it in my change | 00:08 |
reaperhulk | make it a separate CR and we can land that immediately | 00:08 |
reaperhulk | Does this change it for devstack only or for everything? | 00:08 |
reaperhulk | (I assume devstack only) | 00:08 |
rm_work | err | 00:08 |
rm_work | well, whatever uses the default vassal configs | 00:08 |
rm_work | I assume any operator would be tweaking those | 00:08 |
rm_work | because the default is like, single-process <_< | 00:08 |
reaperhulk | put 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 |
reaperhulk | I suspect it will be fine (plus it's a big bonus that it fixes a serious issue with our testing) | 00:09 |
rm_work | does anyone use *uwsgi* in production? :P | 00:09 |
reaperhulk | apparently we will | 00:10 |
reaperhulk | but we won't use default configs | 00:10 |
rm_work | hmm… need a commit message | 00:11 |
dstufft | wrt keep alive | 00:11 |
dstufft | python-barbicanclient will I think | 00:11 |
rm_work | dstufft: hmm, does it? | 00:11 |
rm_work | well | 00:11 |
dstufft | it uses a requests session I think | 00:11 |
dstufft | and requests sessions use persistent connections | 00:11 |
dstufft | it'll still *work* | 00:11 |
rm_work | T_T | 00:11 |
dstufft | it just won't have persistent connections anymore | 00:12 |
*** xianghui has quit IRC | 00:12 | |
reaperhulk | IMO this is basically a (much better) workaround until we pull uwsgi out of our devstack config entirely | 00:12 |
rm_work | dstufft: should I push this change for review or not? :P would you +1 it? | 00:12 |
rm_work | or +2, not sure who you are exactly :P | 00:12 |
reaperhulk | haha | 00:12 |
reaperhulk | he's core. | 00:12 |
dstufft | I'm fine with it as a work around until we pull uwsgi out of devstack | 00:12 |
rm_work | kk | 00:12 |
*** xianghui has joined #openstack-barbican | 00:12 | |
dstufft | might want to add a comment that it effectively disables persistent connections though | 00:13 |
dstufft | and pipelining ofc, but nobody implements pipelining anyways | 00:13 |
* dstufft goes again for a bit | 00:18 | |
rm_work | damnit i typed up a huge message and then git decided it couldn't read the vim output T_T | 00:19 |
rm_work | alright, typed up an equally lengthy but maybe not quite as good one, reviewing in a sec | 00:23 |
openstackgerrit | Adam Harwell proposed a change to openstack/barbican: Force uWSGI to set "Connection: close" header https://review.openstack.org/112735 | 00:26 |
openstackgerrit | Adam Harwell proposed a change to openstack/barbican: Add support to Barbican for consumer registration https://review.openstack.org/107845 | 00:28 |
rm_work | oh whoops | 00:28 |
rm_work | wrong rebase | 00:28 |
openstackgerrit | Adam Harwell proposed a change to openstack/barbican: Add support to Barbican for consumer registration https://review.openstack.org/107845 | 00:30 |
rm_work | there we go | 00:30 |
rm_work | reaperhulk: so when did you think we could get THAT one through? :P | 00:31 |
reaperhulk | the force uwsgi? | 00:32 |
reaperhulk | We should have that landed tomorrow. | 00:32 |
rm_work | k | 00:32 |
rm_work | that would be awesome | 00:32 |
rm_work | … shortly followed by my original CR? :P | 00:32 |
reaperhulk | landed or rejected, but hoping for landed obviously | 00:33 |
rm_work | heh | 00:33 |
reaperhulk | I need to re-review that CR, but will do so momentarily | 00:33 |
rm_work | literally nothing has changed | 00:33 |
rm_work | since the last time you guys reviewed it | 00:33 |
rm_work | every patchset has been rebasing | 00:33 |
rm_work | T_T | 00:33 |
reaperhulk | so you haven't fixed the things we listed yet? | 00:33 |
rm_work | err | 00:33 |
reaperhulk | No point to me re-reviewing it if so :) | 00:33 |
rm_work | since the last time everyone *workflowed it* | 00:33 |
rm_work | lol | 00:33 |
reaperhulk | gotcha | 00:33 |
rm_work | i thought you were a +2… maybe not | 00:34 |
reaperhulk | last time i looked at it was Tuesday | 00:34 |
reaperhulk | yesterday I was flying most of the day | 00:34 |
rm_work | ah nope just the two Johns | 00:35 |
rm_work | and Doug workflowed it | 00:35 |
rm_work | though 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_work | nor did everyone else apparently? :P | 00:35 |
reaperhulk | I did. | 00:35 |
rm_work | lol | 00:36 |
reaperhulk | We 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 devstack | 00:36 |
rm_work | rofl | 00:36 |
reaperhulk | So for doing it yourself you earn big points from me | 00:36 |
rm_work | well, 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_work | s/just about // | 00:37 |
reaperhulk | kudos withdrawn and placed in chellygel's hopper | 00:38 |
rm_work | :P | 00:38 |
rm_work | reaperhulk: so where are you now exactly? | 00:40 |
reaperhulk | Makawao, Maui | 00:40 |
rm_work | nice | 00:40 |
rm_work | I have been meaning to do "work from beach" | 00:41 |
rm_work | are you literally just traveling and working at the same time? | 00:41 |
reaperhulk | yep | 00:41 |
rm_work | yeah | 00:41 |
rm_work | that's what I'd really like to be doing at some point | 00:41 |
rm_work | I've talked about working from the Bahamas | 00:41 |
reaperhulk | Today has been a stupidly productive day since I had to get up at 5am for standup and then just kept working | 00:41 |
rm_work | heh | 00:41 |
reaperhulk | Plus the beaches are closed due to inbound hurricane so bah | 00:41 |
rm_work | my team is not very "work remote" friendly tho :( | 00:42 |
reaperhulk | working remote is challenging. Every team has to develop its own techniques. I've definitely been in situations where it just wasn't practical | 00:42 |
rm_work | I mean, I think it's perfectly practical, they just don't like it :P | 00:42 |
rm_work | I mean, I've been at home for the past two hours or so | 00:44 |
rm_work | way more productive than I was pretty much the whole day *at* work | 00:45 |
rm_work | too much distraction | 00:45 |
rm_work | I guess I may as well go do something else now, it is 7:45pm :P | 00:46 |
rm_work | and I suppose I'm just waiting for my patchsets to get approved now | 00:46 |
rm_work | well, 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 |
reaperhulk | yep, go do some not code | 00:47 |
rm_work | the barbican python client is kind of a mess T_T | 00:47 |
rm_work | yeah maybe i'll go play some Minecraft :P | 00:48 |
*** rm_you has joined #openstack-barbican | 00:51 | |
*** ayoung has joined #openstack-barbican | 00:53 | |
*** gyee has quit IRC | 01:21 | |
*** alee has joined #openstack-barbican | 01:28 | |
*** bdpayne has joined #openstack-barbican | 04:26 | |
*** jaosorior has joined #openstack-barbican | 04:48 | |
*** bdpayne has quit IRC | 05:16 | |
*** bdpayne has joined #openstack-barbican | 05:21 | |
*** bdpayne has quit IRC | 05:43 | |
openstackgerrit | OpenStack Proposal Bot proposed a change to openstack/barbican: Imported Translations from Transifex https://review.openstack.org/112764 | 06:10 |
*** crc32 has quit IRC | 06:50 | |
*** jamielennox is now known as jamielennox|away | 07:33 | |
*** arunkant has quit IRC | 10:23 | |
*** arunkant has joined #openstack-barbican | 10:25 | |
*** ayoung has quit IRC | 12:13 | |
openstackgerrit | Gerome Chardon proposed a change to openstack/barbican: Clean code https://review.openstack.org/112845 | 12:29 |
openstackgerrit | Gerome Chardon proposed a change to openstack/barbican: Clean old comments (already implemented utils.getLogger) https://review.openstack.org/112845 | 12:45 |
openstackgerrit | Gerome Chardon proposed a change to openstack/barbican: Clean old comments (already implemented) https://review.openstack.org/112845 | 12:54 |
*** lecalcot has joined #openstack-barbican | 13:05 | |
*** lecalcot has quit IRC | 13:50 | |
*** russellb is now known as rustlebee | 13:50 | |
*** ayoung has joined #openstack-barbican | 13:53 | |
*** lecalcot has joined #openstack-barbican | 13:56 | |
*** SheenaG1 has joined #openstack-barbican | 14:02 | |
*** Kevin_Bishop has joined #openstack-barbican | 14:14 | |
*** akoneru has joined #openstack-barbican | 14:37 | |
*** mdorman has joined #openstack-barbican | 14:42 | |
*** paul_glass has joined #openstack-barbican | 14:50 | |
*** mdorman has quit IRC | 14:51 | |
*** mdorman has joined #openstack-barbican | 14:51 | |
jaosorior | Guys, 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 all | 15:02 |
*** lecalcot has quit IRC | 15:06 | |
*** lecalcot has joined #openstack-barbican | 15:08 | |
*** lecalcot has quit IRC | 15:08 | |
jvrbanac | jaosorior, 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-barbican | 15:09 | |
jaosorior | jvrbanac, thanks man :) | 15:09 |
jvrbanac | alee, redrobot, reaperhulk ^^ | 15:10 |
rm_work | also https://review.openstack.org/#/c/112735/ :P | 15:18 |
rm_work | already got 3x +2s this time | 15:18 |
rm_work | in record time, so obviously it must be broken and I should abandon it, lol | 15:18 |
rm_work | we were waiting on… comment from ryanpetrello I think? and maybe woodster_ and redrobot to take a look | 15:19 |
ryanpetrello | hrm | 15:20 |
*** jenkins-keep has joined #openstack-barbican | 15:20 | |
ryanpetrello | what was the reasoning for that? | 15:20 |
ryanpetrello | seems a bit heavy-handed | 15:20 |
rm_work | ryanpetrello: yes, it is | 15:21 |
rm_work | ryanpetrello: so, uWSGI apparently doesn't ever set that header | 15:21 |
rm_work | and I *think* it's not technically pecan's job to set it either | 15:22 |
rm_work | according to the RFC | 15:22 |
rm_work | so 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 |
ryanpetrello | hrm | 15:23 |
rm_work | ryanpetrello: uWSGI leaves all connections open, which breaks clients that are expecting (and rightly, because of RFC spec) that they should be sending the Close header | 15:23 |
ryanpetrello | I’d expect the server in question to handle that header, not a framework | 15:23 |
rm_work | right | 15:24 |
rm_work | so uWSGI *is* the server | 15:24 |
rm_work | in this case | 15:24 |
ryanpetrello | right | 15:24 |
rm_work | so, then it's uWSGI's problem | 15:24 |
ryanpetrello | do other servers illustrate the same issue? | 15:24 |
ryanpetrello | e.g., did you try gunicorn? | 15:24 |
rm_work | I have never heard of gunicorn :) | 15:24 |
ryanpetrello | yea, I only brought it up because it’s configuration is pretty similar to UWSGI | 15:25 |
ryanpetrello | pecan also has a plugin | 15:25 |
ryanpetrello | e.g., `pip install gunicorn && pecan_gunicorn some_pecan_config_file.py` | 15:25 |
ryanpetrello | should let you test it pretty quickly | 15:25 |
rm_work | ryanpetrello: I can test it | 15:25 |
rm_work | let me check | 15:25 |
*** ayoung has quit IRC | 15:26 | |
rm_work | so, the part that concerns me is "some_pecan_config_file.py", since we use vassal configs to run our stuff with uWSGI and Paste | 15:29 |
rm_work | also, where does pecan_gunicorn come from? :P | 15:31 |
rm_work | ryanpetrello: ok | 15:40 |
rm_work | tested with a new simple_app | 15:40 |
rm_work | gunicorn results in: | 15:40 |
rm_work | connection closed | 15:41 |
rm_work | uwsgi results in: | 15:41 |
rm_work | connection left intact | 15:41 |
rm_work | for a simple curl | 15:41 |
rm_work | so yeah, uwsgi is not operating properly (at least by default) | 15:41 |
rm_work | asking in #uwsgi | 15:51 |
rm_work | ryanpetrello: does this sound like a good explanation of the problem? http://pastebin.com/raw.php?i=Yv5jVpCj | 15:53 |
ryanpetrello | yep, that sounds reasonable to me | 15:53 |
rm_work | so, any idea how I'd convert the barbican vassal configs to use gunicorn? :P | 15:55 |
rm_work | or 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_work | at least temporarily, until we can properly move away from uwsgi? | 15:56 |
ryanpetrello | no, I’m okay w/ the UWSGi change | 15:56 |
ryanpetrello | it just seemed like a potential UWSGI bug to me | 15:56 |
ryanpetrello | and I wanted to understand the problem | 15:56 |
rm_work | oh, yeah totally | 15:56 |
rm_work | is anyone actually in the castle today? redrobot / woodster_ / chellygel? | 15:59 |
SheenaG1 | I believe chellygel is on ETO | 15:59 |
SheenaG1 | Not sure about the other two | 16:00 |
rm_work | woot, well, at least I've got you SheenaG1 :) | 16:00 |
rm_work | I guess you're probably not at the castle though... | 16:00 |
SheenaG1 | No, but I'm in the office! | 16:01 |
SheenaG1 | In AUS. | 16:01 |
*** gyee has joined #openstack-barbican | 16:01 | |
rm_work | heh | 16:01 |
rm_work | was wondering for a sec if you were in SYD | 16:01 |
SheenaG1 | I wish. | 16:01 |
rm_work | follow reaperhulk's lead | 16:02 |
SheenaG1 | Work from ANYWHERE | 16:03 |
SheenaG1 | Unfortunately, I'm way less effective in e-threats | 16:03 |
redrobot | when I grow up I want to be a badass who works from anywhere just like reaperhulk | 16:03 |
rm_work | yeah actually I had been thinking about doing that for a while, reaperhulk beat me to it by a bit though | 16:04 |
rm_work | nice that his team is cool with that :P | 16:04 |
rm_work | redrobot: you ARE here :P | 16:04 |
rm_work | redrobot: go ahead. review and approve THIS change. there's no way this could go badly for me. | 16:04 |
redrobot | yeah, trying to catch up with IRC. | 16:04 |
rm_work | https://review.openstack.org/#/c/112735/ | 16:04 |
redrobot | rm_work the vassal config? done | 16:05 |
rm_work | redrobot: you have a bit, this also goes back to yesterday evening | 16:05 |
rm_work | nice | 16:05 |
rm_work | EXCELLENT. | 16:05 |
rm_work | now go approve https://review.openstack.org/#/c/107845/ :P | 16:05 |
redrobot | rm_work the idea is to merge just enough to keep you coming back for more... | 16:06 |
rm_work | hehe | 16:06 |
rm_work | well, you already have me for python-barbicanclient | 16:07 |
rm_work | guaranteed :) | 16:07 |
rm_work | I think people wanted to see a BP for the revamp on that? | 16:08 |
rm_work | I guess I can technically add containers support without doing any of that other stuff | 16:08 |
rm_work | but I *would* like to land some of those changes in Juno | 16:08 |
rm_work | and 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 :P | 16:09 |
redrobot | yeah, blueprint would be awesome... I just have to make some time over a weekend or something to make it happen. | 16:09 |
rm_work | alright | 16:09 |
rm_work | woo thanks for the +2 woodster_ :P | 16:12 |
openstackgerrit | A change was merged to openstack/barbican: Force uWSGI to set "Connection: close" header https://review.openstack.org/112735 | 16:18 |
reaperhulk | status update: bored by this hurricane/tropical storm | 16:22 |
reaperhulk | time to review some code | 16:22 |
rm_work | heh | 16:22 |
rm_work | reaperhulk: ooh, ooh, do mine :P | 16:22 |
reaperhulk | that's the plan | 16:22 |
rm_work | sweet | 16:23 |
rm_work | <3 | 16:23 |
reaperhulk | I found some more %'s :D | 16: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_work | reaperhulk: lol | 16:29 |
reaperhulk | +2, all you need is a workflow now | 16:29 |
rm_work | reaperhulk: i ALMOST fixed the rest of them in the other tests, but i didn't want to bloat this change with other people's stuff | 16:29 |
rm_work | were there really more in my code too? T_T | 16:29 |
reaperhulk | yeah, 3 more | 16:29 |
rm_work | fff | 16:29 |
reaperhulk | in repositories.py | 16:30 |
reaperhulk | doesn't matter though, we'll fix it as a separate CR | 16:30 |
rm_work | kk | 16:31 |
rm_work | woot. | 16:36 |
rm_work | just need redrobot or jvrbanac maybe :P | 16:36 |
rm_work | jvrbanac: want to review https://review.openstack.org/#/c/107845/ again? :) | 16:36 |
*** lecalcot has quit IRC | 16:36 | |
*** Kevin_Bishop has quit IRC | 16:36 | |
*** lecalcot has joined #openstack-barbican | 16:53 | |
*** akoneru is now known as akoneru_lunch | 16:55 | |
*** paul_glass has quit IRC | 17:03 | |
*** paul_glass has joined #openstack-barbican | 17:04 | |
*** bdpayne has joined #openstack-barbican | 17:12 | |
*** jaosorior has quit IRC | 17:22 | |
*** lecalcot has quit IRC | 17:27 | |
*** lecalcot has joined #openstack-barbican | 17:28 | |
*** bdpayne has quit IRC | 17:31 | |
*** bdpayne has joined #openstack-barbican | 17:32 | |
*** akoneru_lunch is now known as akoneru | 17:46 | |
*** Kevin_Bishop has joined #openstack-barbican | 17:51 | |
openstackgerrit | A change was merged to openstack/barbican: Add support to Barbican for consumer registration https://review.openstack.org/107845 | 17:52 |
*** ayoung has joined #openstack-barbican | 17:54 | |
*** lecalcot has quit IRC | 17:58 | |
*** lecalcot has joined #openstack-barbican | 18:00 | |
openstackgerrit | Chelsea Winfree proposed a change to openstack/barbican: Add Certificate Interface & Symantec Plugin https://review.openstack.org/107190 | 18:14 |
*** SheenaG11 has joined #openstack-barbican | 18:16 | |
*** SheenaG1 has quit IRC | 18:19 | |
alee | woodster_, ping | 18:22 |
woodster_ | alee: hey Ade | 18:24 |
alee | woodster_, hey -- just a couple of quick questions .. | 18:25 |
alee | woodster_, I'm starting to look at implementing the dogtag plugin side of the cert issuance. | 18:26 |
alee | but before I do that of course, I need to know whats coming in. | 18:26 |
*** jaosorior has joined #openstack-barbican | 18:26 | |
alee | woodster_, the relevant spec is this one? https://review.openstack.org/#/c/108429/5/specs/juno/add-certificate-type-to-order-resource.rst,cm | 18:26 |
jaosorior | hockeynut, woodster, even though ListOrder in singular sounds strange, I got it from python-openstackclient who usr the same notation for List* commands | 18:27 |
jaosorior | * woodster_ | 18:28 |
alee | woodster_, and are there any code CR's yet - or are we waiting for the spec to be approved? | 18:28 |
jaosorior | * usr | 18:29 |
jaosorior | * use, damn cellphone | 18:29 |
woodster_ | jaosorior: that sounds reasonable then, could you add that comment to the CR then? | 18:30 |
*** SheenaG11 has quit IRC | 18:31 | |
woodster_ | alee: there is also a CR that Arvind is working on | 18:31 |
jaosorior | I'm not on my computer :/ I'm actually in a festival | 18:31 |
*** SheenaG1 has joined #openstack-barbican | 18:31 | |
alee | woodster_, which one is that? | 18:32 |
woodster_ | alee: this one: https://review.openstack.org/#/c/87405/ | 18:32 |
*** SheenaG11 has joined #openstack-barbican | 18: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 |
alee | woodster_, wasn't some of that broken up into another CR? | 18:34 |
*** SheenaG11 has left #openstack-barbican | 18:34 | |
*** lecalcot has quit IRC | 18: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,cm | 18:35 |
*** lecalcot has joined #openstack-barbican | 18:35 | |
*** SheenaG1 has quit IRC | 18:36 | |
alee | woodster_ yeah - I've been reviewing the smaller one. BTW, I had asked some questions on that one which we need to hammer out | 18: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 |
alee | woodster_, 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 |
alee | woodster_, sorry gotta go. back in a hour or so . | 18:37 |
woodster_ | alee: ok | 18:38 |
chellygel | hey 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 now | 18:43 |
chellygel | rather, i rebased and pushed | 18:43 |
rm_work | woot woot | 18:46 |
rm_work | chellygel: that shouldn't have affected any of the tox tests, just the tempest stuff -- it failed on py27? | 18:47 |
hockeynut | thanks for checking on that jaosorior | 18:47 |
openstackgerrit | Kevin Bishop proposed a change to openstack/barbican: First attempt at adding the symantecssl library https://review.openstack.org/110144 | 18:47 |
rm_work | uhh what happened to openstackgerrit -- it is spitting out the wrong URL format for changes today >_> | 18:49 |
rm_work | missing /#/c/ | 18:49 |
jaosorior | hockeynut: doing my best | 18:50 |
*** SheenaG1 has joined #openstack-barbican | 18:50 | |
hockeynut | :-) | 18:51 |
Kevin_Bishop | Hey woodster_, I updated the CR if you'd like to take a look. | 18:51 |
rm_work | weird though, i see it there in py27 too, so strange, didn't think those tests used uwsgi at all | 18:51 |
Kevin_Bishop | Thanks in advance | 18:51 |
rm_work | chellygel: oh shit, did that py27 fail with the same Conection Reset error, except *during the cryptography build*?! | 18:52 |
rm_work | 2014-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_work | 2014-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_work | it didn't even get to the barbican code | 18:53 |
rm_work | yeah, not related to my fix | 18:53 |
rm_work | just looks the same :P so i can see the jump to that conclusion | 18:53 |
woodster_ | chellgell: Maybe try a recheck no bug on that | 18:53 |
rm_work | it was during the PyTest run for cryptography it looks like? maybe reaperhulk has an idea, but hopefully it's a one-time | 18:54 |
woodster_ | Kevin_Bishop: thanks, I'll take a look | 18:54 |
rm_work | woodster_: well she already had to rebase on mine, so the time for recheck is a bit late | 18:54 |
rm_work | her change is queued in Zuul right now | 18:55 |
woodster_ | that's true...just wait it out. :) | 18:55 |
chellygel | haha, just got this | 18:57 |
chellygel | glad that all got resolved without me looking | 18:57 |
rm_work | chellygel: 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_work | I guess you are my team-away-from-home | 19:25 |
rm_work | :) | 19:25 |
reaperhulk | oh look, rm_work's CR landed | 19:26 |
rm_work | reaperhulk: :P | 19:26 |
rm_work | thanks for the effort | 19:26 |
reaperhulk | not much effort on my part compared to you | 19:26 |
reaperhulk | While I have power and wifi again I'm going to try to quickly submit the % => format CR | 19:26 |
rm_work | well, some at least :) | 19:26 |
rm_work | reaperhulk: i was thinking about just whipping that out | 19:27 |
rm_work | but you can have it if you want :P | 19:27 |
rm_work | does it need a bug filed? | 19:28 |
rm_work | that's the only part i'm not really a fan of :P | 19:28 |
hockeynut | woodster ping | 19:29 |
hockeynut | woodster_ ping | 19:29 |
hockeynut | woodster_____________________________ ping :-) | 19:29 |
hockeynut | ah, nevermind - found an existing bug that tsv opened. Failing a PUT to secret with binary data. Bug is https://bugs.launchpad.net/barbican/+bug/1350988 | 19:31 |
reaperhulk | so many %s... | 19:33 |
alee | woodster_, 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 help | 19:47 |
hockeynut | just ran into the bug I linked to above. I put some more info into launchpad for it. tsv is assigned to it | 19:47 |
hockeynut | we 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 only | 19:49 |
woodster_ | alee: looking at question too... | 19:49 |
hockeynut | multithreaded woodster_ ! | 19:50 |
openstackgerrit | Venkat Sundaram proposed a change to openstack/python-barbicanclient: remove tenant-id from uri https://review.openstack.org/112149 | 19:50 |
rm_work | wow, so | 19:52 |
rm_work | reaperhulk / dstufft: http://tools.ietf.org/html/rfc7230#section-6.3 | 19:52 |
rm_work | according to this | 19:52 |
rm_work | A recipient determines whether a connection is persistent or not | 19:52 |
rm_work | based on the most recently received message's protocol version and | 19:52 |
rm_work | Connection header field (if any): | 19:52 |
rm_work | o If the "close" connection option is present, the connection will | 19: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 connection | 19:52 |
rm_work | will persist after the current response; | 19:52 |
rm_work | so the DEFAULT is actually keep-alive | 19:52 |
rm_work | unless the client specifically passes in a Connection: close header | 19:53 |
reaperhulk | yeah HTTP/1.1 has been that way from the beginning | 19:53 |
reaperhulk | 1.0 is the only thing that required keep-alive to be explicitly passed | 19:53 |
alee | woodster_, 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 |
alee | woodster_, and make that explicit in the plugin contract | 19: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-createretrieve | 19:55 |
alee | woodster_, either that or we need to return a tuple with each of the individual fields | 19:55 |
rm_work | reaperhulk: so then it's gunicorn that is operating in a strange way and closing all connections?! | 19:56 |
rm_work | though it looks like that's because gunicorn doesn't *support* keepalives | 19:56 |
dstufft | rm_work: isn't the client sending Connection: close | 19:59 |
rm_work | I am actually not sure | 20:00 |
rm_work | It might not be? | 20:00 |
hockeynut | woodster_ this is 2 step binary | 20:00 |
dstufft | if the client wasn't sending Connection: close then the middleware wouldn't do anything | 20:00 |
rm_work | maybe all of our tests need to have extra headers added? | 20:00 |
rm_work | ah | 20:00 |
rm_work | yeah, that is true | 20:00 |
dstufft | because you're just reflecting the value the client sent | 20:00 |
woodster_ | ale: just added a comment to that CR | 20:00 |
rm_work | well, i am testing again with this simple-app | 20:00 |
rm_work | and adding Connection:close to my curl request does not do anything there either :/ | 20:01 |
rm_work | so yeah | 20:01 |
dstufft | although the client should be closing conncetions after it receives a response if it sent Connection: close | 20:01 |
rm_work | uwsgi is not respecting the connection:close I've sent as the client | 20:01 |
dstufft | but the server should also be closing connections | 20:01 |
woodster_ | alee: a tuple would probably be cleaner actually | 20:01 |
dstufft | rm_work: I have all of this in my brain right now because I've been writing an HTTP server heh | 20:03 |
dstufft | so the RFCs are fresh on my mind | 20:03 |
alee | woodster_, yes - I think so too. no DTO needed | 20:05 |
rm_work | LOL ok | 20: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 compliant | 20:05 |
rm_work | [15:04:17] <unbit> yes for sure | 20:05 |
rm_work | [15:04:25] <unbit> as well gunicorn is not expected to be put on the public network | 20:05 |
rm_work | [15:04:34] <unbit> as well as basically every application server | 20:05 |
reaperhulk | heh, that's an oversimplification. while most app servers do have something in front, not all are designed to require it | 20:05 |
rm_work | whelp, uWSGI is | 20:06 |
rm_work | so that's that then | 20:06 |
rm_work | [15:06:41] <rm_work> so you would never recommend we expose uWSGI directly | 20:07 |
rm_work | [15:06:48] <unbit> absolutely | 20:07 |
woodster_ | rm_work: I have seen blogs that put nginx in front of uwsgi, in the context of performance optimization though | 20:12 |
rm_work | yeah, well… apparently in the case of uwsgi it isn't considered "optional" | 20:13 |
*** openstackgerrit has quit IRC | 20:20 | |
chellygel | can i get a workflow +2 again? https://review.openstack.org/#/c/107190/ | 20:30 |
chellygel | O:) | 20:31 |
dstufft | gunicorn is not designed to be exposed publically | 20:33 |
dstufft | doing so makes it trivial to DoS | 20:33 |
rm_work | yeah | 20:33 |
rm_work | apparently same with uwsgi | 20:33 |
dstufft | I don't tihnk that's ane xcuse for implementing HTTP wrong though | 20:33 |
dstufft | HTTP Proxies are supposed to operate using the same HTTP as a client would | 20:35 |
reaperhulk | okay chellygel +1 approving | 20:36 |
SheenaG1 | w00t w00t | 20: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 concern | 20:37 |
reaperhulk | given that rm_work just talked to uwsgi's author I'd say having it work "correctly" is actually unlikely. | 20:40 |
rm_work | yeah he was basically like "why are you doing this" | 20:40 |
rm_work | and "no, it is operating as designed" | 20:41 |
rm_work | and "if you need it to work the way you are expecting, use nginx or some other proxy in front" | 20:41 |
rm_work | he 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 IRC | 20:43 | |
*** bubbva has joined #openstack-barbican | 20: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_work | yeah, I think uwsgi is maybe just not a good way to go | 20:44 |
rm_work | or else, just leave this workaround in place, since it seems to be fine for demo/test deployments <_< | 20:44 |
reaperhulk | there, that was a bunch of tedious BS | 20:47 |
rm_work | reaperhulk: ah, you completed the %s fixes? | 20:51 |
reaperhulk | dunno about completed. got the vast majority of them though | 20:51 |
reaperhulk | I'll have to think about whether I want to write something to gate them | 20:51 |
woodster_ | chellygel: Congrats! | 20:54 |
dstufft | gunicorn is a pretty OK container, so is twisted | 20:55 |
*** paul_glass has quit IRC | 20:56 | |
hockeynut | reaperhulk - a lot of those go away when tsv's CR for removing tenant ID from URIs lands. | 20:58 |
reaperhulk | so this is going to be a colossal conflict | 20:58 |
reaperhulk | hooraaaaay | 20:58 |
reaperhulk | (his can land first) | 20:58 |
hockeynut | no matter what, you can always answer "doesn't matter...I'm at the beach" | 20:59 |
*** alee is now known as alee_afk | 21:01 | |
woodster_ | that should be reaperhulk's away message | 21:03 |
*** SheenaG1 has quit IRC | 21:14 | |
*** Kevin_Bishop has quit IRC | 21:17 | |
rm_work | well, is reaperhulk ETO or actually still working, just not from here? :P | 21:37 |
*** bubbva has quit IRC | 21:40 | |
reaperhulk | I dunno what ETO is | 21:42 |
reaperhulk | always workin' | 21:43 |
rm_work | :P | 21:43 |
rm_work | uhhh hmmm i may have a problem | 21:48 |
*** lecalcot has quit IRC | 21:50 | |
*** lecalcot has joined #openstack-barbican | 21:51 | |
rm_work | I am pretty sure cd70a208c621400c3a26efccdf0a3135ff6ed44b breaks getting secrets for my setup... | 21:55 |
rm_work | http://pastebin.com/raw.php?i=AMNuiGmQ | 21:56 |
rm_work | appears when trying to get a decrypted secret (in a local dev setup) | 21:56 |
rm_work | only after that commit | 21:56 |
rm_work | yep | 21:57 |
rm_work | that commit added an arg to the __init__ of SecretDTO | 21:57 |
rm_work | and didn't update all of the places that call it | 21:58 |
rm_work | specifically "store_crypto.py" line 108-110 | 21:58 |
rm_work | i think it should be transport_key=None | 21:58 |
rm_work | alee_afk: you are afk i guess T_T | 21:59 |
rm_work | although 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_work | http://pastebin.com/raw.php?i=QUrUZ24U | 22:01 |
rm_work | though that seems to happen before that commit too :( | 22:03 |
rm_work | so not related to alee_afk's change | 22:03 |
rm_work | reaperhulk: you around to see what I'm talking about? | 22:05 |
rm_work | hmm, stopped being able to reproduce the second thing | 22:07 |
rm_work | but the first issue is still valid -- cd70a208c621400c3a26efccdf0a3135ff6ed44b introduces a regression for getting decrypted secrets | 22:08 |
rm_work | "Code to pass through transport_key_id when storing secret" | 22:08 |
rm_work | even the comment: | 22:09 |
rm_work | :param transport_key: presence of this parameter indicates that the | 22:09 |
rm_work | secret has been encrypted using a transport key. | 22:09 |
rm_work | implies it should be optional, I believe | 22:09 |
*** lecalcot has quit IRC | 22:29 | |
*** lecalcot has joined #openstack-barbican | 22:30 | |
*** crc32 has joined #openstack-barbican | 22:31 | |
rm_work | looks like there was only one spot missed | 22:34 |
rm_work | the fix could also be to just pass "None" there | 22:34 |
rm_work | again -- StoreCryptoAdapterPlugin.get_secret on line 108 | 22:35 |
*** openstackgerrit has joined #openstack-barbican | 22:39 | |
woodster_ | rm_work: Ugh. I think we need to push for 100% coverage, starting to bite us after these big restructures | 22:45 |
*** lecalcot has quit IRC | 22:45 | |
rm_work | woodster_: 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_work | wish alee_afk was here to comment | 22:46 |
rm_work | I am GUESSING the original intent was for it to be an optional parameter | 22:47 |
woodster_ | rm_work: the transport key is always optional | 22:47 |
rm_work | yeah | 22:47 |
rm_work | I assumed so | 22:47 |
rm_work | it's a two-line change (only because PEP8 forces it onto the next line) | 22:48 |
rm_work | should I just… git-review it? | 22:48 |
rm_work | woodster_: ^^ | 22:49 |
woodster_ | rm_work: if it fixes that test, yes please | 22:51 |
rm_work | there doesn't appear to BE a test for it | 22:51 |
rm_work | I only noticed because I am testing the client and I need to actually get decrypted secrets in it :P | 22:51 |
rm_work | I 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 bug | 22:53 |
rm_work | woodster_: "LP bug"? | 22:54 |
rm_work | oh | 22:54 |
rm_work | launchpad | 22: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 tests | 22:54 |
rm_work | blegh, I have to submit a bug to launchpad: ? | 22:55 |
rm_work | :/ | 22:55 |
rm_work | alright | 22:55 |
rm_work | wasn't this merged? https://bugs.launchpad.net/barbican/+bug/1344365 | 22:56 |
rm_work | why is it still on "Fix Committed" | 22:56 |
rm_work | woodster_: https://bugs.launchpad.net/barbican/+bug/1354603 | 23:03 |
rm_work | look ok? | 23:03 |
dstufft | woodster_: +1000 100% coverage | 23:03 |
rm_work | never submitted a bug to Openstack before | 23:03 |
dstufft | Mandatory coverage is the best | 23:04 |
dstufft | woodster_: there's a thing, diff-cover, that makes it so you can see the coverage of lines changed in a patch too | 23:04 |
dstufft | it's a reasonable balance between 100% coverage all the time and trying to slowly get coverage increased | 23:04 |
woodster_ | Nice! | 23:04 |
dstufft | https://github.com/edx/diff-cover | 23:05 |
openstackgerrit | Adam Harwell proposed a change to openstack/barbican: Make transport_key an optional arg in SecretDTO https://review.openstack.org/113044 | 23:06 |
woodster_ | rm_work, hockeynut I think Steve might be looking at this too | 23:06 |
rm_work | hmm k | 23:06 |
rm_work | welllllll | 23:06 |
rm_work | I just put in a review for it :P | 23:06 |
rm_work | can always abandon | 23:06 |
woodster_ | Yep! | 23:07 |
woodster_ | dstufft: we've talked about making 100% coverage a gate | 23:08 |
dstufft | woodster_: 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 go | 23:09 |
dstufft | since you can make it require 100% coverage for all _changed_ lines | 23:09 |
dstufft | IOW if you add or change a line, if it's not covered then your patch also needs to add tests | 23:09 |
dstufft | after awhile you end up at 100% coverage, or close to it, and mandating 100% coverage is easier | 23:10 |
rm_work | well, bbl | 23:13 |
rm_work | heading to dinner :P | 23:13 |
woodster_ | Thanks again folks have a good weekend | 23:20 |
*** mdorman has quit IRC | 23:25 | |
*** akoneru has quit IRC | 23:37 | |
*** jaosorior has quit IRC | 23:42 | |
bdpayne | I'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-barbican | 23:58 |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!