mozilla :: #conduit

17 Mar 2017
13:41dklmorning
13:41smacleodhey dkl
13:41dklwell figured out my mountebank issue last night so ready for to push for review
13:42dklsmacleod: something we never discussed and it may be to early is what the internal API of the Bugzilla client should look like.
13:42dklsmacleod: right now I have a function create_attachment(bug_id, attach_data, api_key) that creates one attachment at a time
13:43smacleoddkl: That seems fine to me for now. As long as it's testable and works I'm not picky at this point :)
13:43dklis the commit index code going to format the data before calling and call for each commit or would you rather you pass all commits to the function as a single call
13:43dkli mean we an work it several ways.
13:44dklthe bugzilla code could just take a series of commit objects and do the data formatting itself and send a call for each commit
13:44dklbut we may be too early to determine the best way to do it
13:44smacleoddkl: the review package will be passed (for now, later it might go out and get the info itself) all the commit information, and it will be in charge of managing the attachments. The "commits" package should known nothing of them
13:44dklok
13:45dklso i will push what i have and we can work out the details as more of the review services code starts to come together
13:46smacleodsounds good
14:11smacleodckolos: if we are writing a python wsgi app, do you guys somehow serve it using your host nginx, or should we run our own nginx to actually serve the wsgi app?
14:16ckolosnope, we serve it via a local nginx
14:16smacleodokay, so how do we expose that with dockerflow?
14:16ckoloshttps://github.com/mozilla-services/shavar/blob/master/Dockerfile
14:17smacleod(unless I'm misunderstanding and local meant in container rather than host)
14:17ckolosshavar is also a wsgi app
14:17ckolosyou can (for now) ignore the new relic stuff if you wish
14:17ckolosthe container just calls out to this script: https://github.com/mozilla-services/shavar/blob/master/startup.sh
14:17ckolosby default
14:18smacleodah, uwsgi, cool, thanks :)
14:18ckolosso I would recommend doing the same
14:18smacleodYa, we'll make our production image look like that
14:19ckolosI would also recommend adding in a admin/shell option, which really helps for debugging
14:59dklsmacleod: docker-compose.yml can reference other docker-compose.yml files inside the parent.
15:00dklsmacleod: davidwalsh: also you can confgiure the docker-compose.yml using environment variables so you could ideally have a single docker-compose.yml files for both dev and prod
15:00smacleoddkl: ya, it just seemed like davidwalsh was hitting issues with that method, due to overriding or something. So I don't know if the referencing child docker compose files is really worth the DRY
15:01dklok. just odd to have to duplicate similar code in several places but if it is unavoidable
15:01smacleod"code"... couple lines of yml heh
15:01smacleodmost of which is ENV, which is what will change
15:01dklsmacleod: davidwalsh: or create bash script to bring eveything up :)
15:02* smacleod shudders
15:02davidwalshjQuery?
15:02smacleodlol
15:04davidwalshdkl: So a bash script would just be a bunch of "cd" and "./docker-compose up", right?
15:14davidwalshsmacleod: I was wanting to avoid the copy/paste route because it would create
15:15davidwalsh... a lot of maintenance
15:15davidwalshi.e. one change becomes two
15:15smacleodWhat sort of maintenance?
15:15davidwalshWhich is why I questioned copy/paste
15:16smacleodGenerally the only change will be new env vars for new configuration to a service, I don't see it changing much so that's why I wasn't bothered
15:17smacleodotherwise you need to have two compose files per service, the base one that includes all the stuff you won't override, and the override one. Then the demo one includes all the non override ones... seems like a lot of inclusion and hoops
15:17smacleoddavidwalsh: unless I'm misunderstanding?
15:24davidwalshsmacleod: Can we do a quick 2 minute call because I'm 90% on board but I'm missing 10%?
15:25smacleodsure thing, I'll hop in your vidyo room
15:25smacleoddavidwalsh: ^
15:38davidwalshsmacleod: Where can I view our prod ports so I can try to sync them with dev?
15:39smacleoddavidwalsh: in production *everything* is 443 (https)
15:39davidwalshAhh, k
15:39smacleoddavidwalsh: only the ports we map onto the host really matter, the internal container ones don't
15:39davidwalshOK
15:39smacleodinternal collisions are fine, and containers talk to each other using the internal ports
16:01smacleodmars: don't review the flask-restplus stuff I put up
16:01smacleodI'm going to change it
17:09mcotefyi people should start giving dkl reviews :)
17:09dklwhats that? :)
17:09mcoteyou're fired
17:10dkli meant it more like 'who say wat?
17:10dklno. i can definitely look at them like i know what is going on
17:10davidwalsh"dkl is a fine gentleman with a slight accent and a valuable member of the team. 10/10" ; that's my review.
17:10dklah thanks!
17:14dklmcote: hmm 'hg push review' is hung on 'Unable to determine review identifier'
17:14dklmcote: suppose it didnt like how i put the bug id in the commit message?
17:14dklmcote: if i cancel out, update the commit message and do 'hg push review' again will it cause any issues on the reviewboard side?
17:16mcotehung? weird
17:16mcotewhat does your commit message look like?
17:16dklyeah just sitting there. i could stop it
17:17dklmcote: ah i see now. it was not all in the first line
17:17dklmy line got divided into two lines and it seems to be ignoring the second line
17:17dklif i control-c will it cause any problems?
17:18dklmcote: "commit-index: Create bugzilla.py module for accessing BMO's REST API to add
17:18dklattachments (bug 1347930) r?mars"
17:18firebothttps://bugzil.la/1347930 ASSIGNED, dkl@mozilla.com Given a set of commit patches and metadata, the Review Service should create a BMO patch attachment
17:19mcotehm that seems fine
17:19mcoteohh
17:19mcoteyeah needs to be one line
17:22dklso i need to condense my summary
18:11dklsmacleod: does 'invoke lint' work on the current commitindex code for you? I am getting 'RecursionError: maximum recursion depth exceeded' on my dev box
18:15smacleoddkl: yup, works fine for me - you must have introduced something to break it :/
18:15dklawesome
18:15smacleodIf you toss your code up for review I could take a peek later
18:16smacleoddkl: is it "invoke commitindex.lint.yapf" or "invoke commitindex.lint.flake8" that's broken?
18:16smacleod(or both)
18:17dklstrange it still fails for me locally without my patch so it must be my env. but it is running it in docker containers so i assume the env was the same for everyone
18:22dklsmacleod: https://reviewboard.mozilla.org/r/121486/diff/1#index_header
18:28smacleoddkl: it runs in Docker containers but mounts your local filesystem. Maybe your host tree is dirty somehow?
18:51dklsmacleod: yeah a fresh checkout works
18:52dklsmacleod: what are .ropeproject files?
18:57dklnm
21:02marssmacleod: question about the hg client/server extension work just came up
21:04marssmacleod: the client code calls the server to validate the client version. getting around that is not in any card at the moment. Either we need to pass an env var to the client to disable the version check call, or we need to add a card for the server-side validation check and make it return OK every time.
21:06marseither way, the version check will block Israel as soon as he tries to integration test his server-side work, so we need to solve it.
21:08* mars adds a card to implement the server-side validation check
21:12mcote16:46 < laura> I hear mcote is calling his team &quot;pipeline pipeline something something mark cote&quot;
18 Mar 2017
No messages
   
Last message: 100 days and 13 hours ago