mozilla :: #balrog

8 Sep 2017
13:10tossjbhearsum: can I set the issue that I made a commit for to RESOLVED, or does someone on Mozilla's end do that?
13:12bhearsumtossj: feel free to :)
13:13tossjbhearsum: I'm guessing I put WORKSFORME right?
13:18bhearsumah, no - you want FIXED
13:18bhearsumwe use FIXED when a patch was required to resolve the bug. WORKSFORME is used when the reported problem cannot be reproduced
13:20tossjso I selected RESOLVED, and then another drop-down appears beside it, and the only options are INVALID, DUPLICATE, WORKSFORME, and INCOMPLETE
13:20tossjI don't see a FIXE
13:20tossjI don't see a FIXED
13:20tossjthere's also a WONTFIX
13:25bhearsumtossj: oh, that's weird
13:25bhearsummaybe you don't have the right credentials in bugzilla to do it....
13:26bhearsumin that case, just leave it for me - i'll close it as FIXED after the new code is in production
13:26bhearsumprobably next wednesday
14:31allan-silvaGood day, folks!
14:31allan-silvabhearsum, I updated #380
14:32bhearsumi probably won't be looking until later today or monday
14:44bhearsumit looks like they'll be lots of good stuff in next week's production push ;)
16:22catleebhearsum: what's the reason for not allowing a fallbackMapping when the update rate is 100?
16:22bhearsumcatlee: it's confusing, because the fallbackMapping is never used
16:22catleewouldn't leaving it there make it easier to do the right thing if the update rate gets changed again?
16:23bhearsumyeah, maybe
16:23bhearsumit's a trade off...
16:23bhearsumi was also thinking of requiring fallbackMapping if the rate is < 100
16:23catleemaybe grey it out in the UI?
16:23catleemake it <blink>
16:23bhearsumthat&#39;s a good idea
16:23bhearsumtoo bad <blink> is dead!
16:24bhearsumi&#39;ll update that bug shortly
16:37catleeI miss <blink>
16:41bhearsumjust make javascript do it! <blink>, with 10x the cpu usage!
16:50reludbhearsum: why doesn&#39;t stage fit the need for the new balrog testing environment?
16:51bhearsumrelud: two reasons: it doesn&#39;t track production code (it tracks tip of master), and the db state is more volatile - we often make a bunch of changes to it when verifying new code that&#39;s been merged
16:52reludokay. normally dev does those things, and stage does the testing thing you want, in cloudops.
16:53reludwould it be okay with you if I switched those then, and made a dev that does continuous deployment, and a stage that you do testing on, and usually matches prod?
16:53bhearsumi don&#39;t really care what it&#39;s called, so that would probably work
16:53reludso, there&#39;s a process change that would make this easier on me
16:53bhearsumwhat&#39;s that?
16:55reludwhen you want something deployed to the new environment, run `docker pull {image}:master-{hash} && docker tag {image}:master-{hash} {image}:{version_number} && docker push {image}:{version_number}`
16:56reludand if you want to redeploy an old version you can always `docker pull {image}:{version} && docker push {image}:{version}`
16:57bhearsumso the new stage environment would watch the {image}:{version_number} tag for changes?
16:57reludit would watch for tags that aren&#39;t like /latest|master.*/
16:58reludwhile new dev would watch /master.*/
16:58bhearsumand prod wouldn&#39;t autodeploy at all, presumably
16:59reludyeah, prod would still be me pushing a button. that&#39;s more about making sure someone with a pager and root is on deck for prod deploys
16:59bhearsumyup, that makes sense
16:59bhearsumis it possible to make the db resets to stage independent of deployments? i can envision cases where we&#39;d want to deploy new code, but not reset the db
17:01reludyeah. i just need to figure out how to do that. maybe a jenkins job. or a special api. idk.
17:02bhearsumtbd is fine with me :)
17:02bhearsumthat process should be fine too
17:02reludgiving shell access is probably also an option, but that sounds like a hassle to make sure the right people all get shell access in stage
17:02bhearsumit fits in well with the current deploy workflow where i tag shortly before filing the bug
17:02bhearsumyeah, an api would be easier, but we could live with shell access as a first step
17:03reludoh, what if you pushed a docker tag &#39;migrate-stage&#39;?
17:03reludthen you could reset & migrate the db separate from deploys
17:03reludand it would take me out of the process for testing db migrations before prod
17:04bhearsumit&#39;s hacky, but i bet it would work
17:04bhearsumif i understand correctly, it wouldn&#39;t even matter what hash is tagged, just that something happens with that tag?
17:05bhearsumworks for me
17:06bhearsumi want to fix as part of this too, otherwise the db resets are going to break like they did recently
17:07bhearsummost of that should be on me though
17:08bhearsumrelud: do you want to file this, or should i?
17:09reludbhearsum: you should file it. i want to get a second opinion on the implementation
17:10bhearsumsure thing
17:19bhearsumrelud: since we&#39;re doing it for stage already, mind if we watch &quot;migrate-dev&quot; to do dev resets too?
17:20reludyeah, i can definitely make dev and stage have the same mechanism
17:27reludbhearsum: what do you think of hitting to trigger the migration (which nginx would intercept and call a script for)?
17:27bhearsumoh, that&#39;s even better
17:27bhearsummaybe require a magic string in the query params to prevent accidents?
17:33reludbhearsum: would everyone with access to admin be the right audience for access to this?
17:33bhearsumrelud: i think it should be restricted to RelEng, which is a subset of those people
17:34bhearsumthere&#39;s probably an ldap group for that, if that&#39;s what you&#39;re looking for
17:43reludyeah, just verifying that i needs a different access level
17:45reludmiles: if you deploy balrog next week, please deploy cloudops-deployment/projects/balrog/ansible/playbooks/resources.yml and logging-env with App=balrog,Env=prod first. cc bhearsum
9 Sep 2017
No messages
Last message: 13 days and 7 hours ago