mozilla :: #releng

16 Mar 2017
01:20ewongmshal ping
01:20ewongdang..wrong channel
01:21ewongmshal to #build
01:22mbrandtA question, one of our bouncer tests is failing on the firefox-esr-latest alias. https://product-details.mozilla.org/1.0/firefox_versions.json shows "FIREFOX_ESR": "45.8.0esr" yet 52.0esr is being served up. Is this expected?
01:26mbrandtI suspect it's a timing issue related to when firefox_versions.json gets updated but want to confirm.
01:28nthomasmaybe a mismatch in expectations
01:29nthomasany idea what firefox-esr-latest is used for ?
01:29nthomashttps://www.mozilla.org/en-US/firefox/organizations/all/ uses specific versions, no stub for ESR to use -latest like it would be on beta or release
01:29nthomasso just a convenience product ?
01:29akiiirc we had a 2 release overlap -- possibly esr52 isn't "live" until 52.2.0 ?
01:30mbrandtyeah, that's my understanding. It's redirect that lives in go-bouncer
01:34nthomasI dunno, should probably push new users towards 52 while we keep 48 going for those with existing installs
01:35mbrandtThe test touches an sometimes awkward intersection, the failure may be related to https://bugzilla.mozilla.org/show_bug.cgi?id=1296376
01:36nthomasso it turns out that both esr45 and esr52 update the alias, see https://hg.mozilla.org/releases/mozilla-esr45/file/default/testing/mozharness/configs/releases/bouncer_firefox_esr.py#l8 and https://hg.mozilla.org/releases/mozilla-esr52/file/default/testing/mozharness/configs/releases/bouncer_firefox_esr.py#l8
01:36nthomasits going to depend on the order they were done
01:36nthomasneed to make a choice
01:37akir.ail just disabled the 45 part
01:37akiper email
01:37nthomasreviewed patch not quite landed ?
01:37nthomasah
01:38akiassuming the bouncer alias and download.m.o are the same
01:38nthomasyep
01:39* mbrandt nods
01:39nthomasso email query -> r.ail adjusts bouncer -> mbrandt notices -> we read email :-)
01:39mbrandt:-D
01:39nthomasadded you to the bug
01:39mbrandtWhatever it takes.
01:40mbrandtgracias
01:40nthomashttps://groups.google.com/forum/#!topic/mozilla.release.engineering/_AAxSdjqzxY is the email
01:41* mbrandt subscribes and goes "wee .. more emails to filter"
01:41mbrandtthx nthomas
01:41nthomasno problemo
01:42mbrandthasta luego
06:56flodjlorenzo: heads up, if you try to build a beta for Fennec https://bugzilla.mozilla.org/show_bug.cgi?id=1347753
06:56flod(speechless)
07:06ewongflod pardon my ignorance.. is OVH a good host?
07:07flodis the one managed by Community IT, not our choice
07:07flodthey want to get rid of OVH, so they set manual renewal each month, and it's the second time they get all server suspended because they forgot to do it
07:08ewongflod: each month?
07:08flodyes
07:08ewongouch.
07:10ewongI do remember that they were migrating off ovh when I was participating in CiT.. but that was like two years ago.. and I guess the processes are too deep and convoluted to migrate off? (not that I'm judging CiT.. I'm not..)
07:10ewongflod what were they planning to migrate to?
07:10flodI think the only migration path is to a different hosting with support only to docker
07:10ewongmakes sense.
07:11ewongflod how much is it on a monthly basis?
07:11ewongflod if you don't mind me asking
07:11flodI have no clue :-)
07:12flodI know the VPS used by my own community is 19 , but for example I have no idea how many VPS we have, or how much that dedicated server costs
07:14flodfrom a 2-years old bug, I think we have between 15 and 20 servers of sort
07:14ewongah
07:14ewongflod thanks for the info
07:14flodnp, I pinged folks in #communityit
07:15flodfrom previous experience, they'll call OVH, ask for an extended grace period while they find someone to pay the bill :-\
07:16ewong:(
07:21jlorenzoflod: got it. Thanks for the heads up. Just to make sure, in the context of a release, l10n-community is only used as the l10n dashboard, right?
07:21flodonly for the stores app
07:21flodall the critical infrastructure is hosted by IT in self managed VMs
07:21jlorenzoWhich fills the play store strings?
07:21flodso, the only problem is when you try to get the stores description from mozapk
07:21flodyes
07:22jlorenzoGot it!
07:22jlorenzoWe have about a day in front of us, then
07:27gcoxStupid question, maybe. Is it "right" that you can't build because of a community VM being down because it belongs to community? Or, is that something that we should be bringing in-house (either relops or IT) for whatever reason?
07:28flodit's far from a stupid question
07:28flodwe only used that server for web dashboards, nothing critical. This dependency was introduced relatively recently
07:29flodwhile it made sense to use that server for these services before, it probably doesn't now
07:31gcoxDisclaimer, I'm IT, so I'm interested in it from a "I don't want to find out I should've had this all along" point of view. But I also, from a casual glance, don't know if it's something I should spin a VM for, or should guide to relops for them to cloud up. We have an l10n VM in the datacenter but it's always seemed like a legacy thing / not a great fit, from the little involvement I had.
07:33flodI plan to talk with the rest of the group to figure out a solution for this, I have zero knowledge of how an internal VM looks like (Axel does), the kind of constraints, etc.
07:37gcoxSounds good. I think it was Axel's l10n VM that I'm remembering. We spun some refresh for it a month or three ago.
12:02Callekwhimboo: I'm going to assume that you no longer need me from yesterdays ping...?
12:06whimbooCallek: nope. all find. aki-away thankfully helped me
13:30h4writerhey. I was wondering if there is a "efficient" way to fetch a revision from try server. (Maybe without pulling the whole tree)? (Purpose is to make arewefastyet to run try server revisions)
13:32RyanVMh4writer: hg pull should just work
13:32RyanVMhg pull -r <whatever>
13:32RyanVMit&#39;ll pull from whatever the last common ancestor in your tree is
13:33RyanVMnote: you&#39;ll want to pull from https:// rather than ssh:// (the default for the firefoxtrees extension)
13:33CallekRyanVM: h4writer hg robustcheckout stuff should be a good efficency thing (as in, using the unified rpeo too)
13:33h4writerRyanVM: hmm, that starts to look promising. How do you get the initial repo? I assume hg clone will just fetch everything
13:34Callekclone the unified repo then pull <rev> from try
13:34RyanVMh4writer: just use mozilla-central
13:34CallekRyanVM: no, use unified
13:34CallekRyanVM: it has a more efficient storage and transport design
13:34RyanVMok
13:34RyanVMmy frame of reference is admittedly working locally, not in CI :)
13:34Callek(especially because try revs can also be from aurora, beta, etc)
13:34h4writerinteresint. Thanks. Gonna try that
13:35RyanVMCallek: and of course, I have aurora/beta/etc in my local clone too :P
13:35CallekRyanVM: yea, I didn&#39;t use unified locally yet, I&#39;m not a fan of bookmark magic, so using `hg pull fxtrees` locally, but I really want the unified&#39;s better storage/transport
13:36RyanVMwhat&#39;s the difference between unified and fxtrees? (I use the same)
13:36Callek(:gps tells me he will convert m-c and others to the better format in H1)
13:36CallekRyanVM: unified has bookmarks for the repos heads and stuff
13:36CallekI just don&#39;t like bookmark workflow too well (I&#39;ve broken my clone a few times using it locally)
13:37RyanVMso bookmarks vs. tagging magic?
13:37RyanVMand head juggling?
13:38CallekRyanVM: and fxtrees doesn
13:38Callekt use tags, it uses a &quot;fake&quot; tag of some sort
13:38* Callek forgets the term
13:38Callekso yea, head juggling
13:38RyanVMI don&#39;t remember either, but I do remember it being a bit hacky whatever gps was doing
13:39CallekRyanVM: reading http://mozilla-version-control-tools.readthedocs.io/en/latest/hgmozilla/unifiedrepo.html is a good idea of the workflow with that
13:39RyanVMthx
13:40* RyanVM pulls mozilla-unified to see how much smaller it is vs. his local fxtrees repo
13:40padenotRyanVM, it&#39;s a million times better on different aspects, once you decide to accept the workflow change
13:40RyanVMa lot of those benefits at the top are the same as m-c w/ fxtrees
13:40* padenot stopped using mq a month back, won&#39;t go back
13:41RyanVMi.e. hg up between branches and such
13:41padenotyeah, I see a difference in speed without measuring
13:41padenotor so I think
13:41RyanVMeww, one big drawback: &quot;These repositories do not include extra branches, notable the *_RELBRANCH branches. If youve ever pulled the mozilla-beta or mozilla-release repositories, you know how annoying the presence of these branches can be.&quot;
13:42RyanVMkind of a problem if doing uplifts is something you still do :P
13:42CallekRyanVM: can still pull them I bet
13:42RyanVMCallek: &quot;If you are already using a unified repository workflow (such as with the firefoxtree extension, hg pull will complete quicker because you are pulling from 1 repository instead of N. This also means less overall work for the server.&quot; seems like the big win
13:43CallekRyanVM: yea, its a big win, but I&#39;m not sold on changing workflow again just yet
13:43RyanVMworkflow looks basically the same otherwise RE: uplifts
13:45Callekyea
13:46RyanVMcool, so it mostly looks like a more efficient version of what I&#39;m already doing, that&#39;s nice :)
13:46CallekI don&#39;t see a big downside overall, I just don&#39;t want to change again (I am a recent mq convert)
13:46RyanVMi still use a combo of mq for some things and regular old heads for others
13:46RyanVMhaven&#39;t really played with bookmarks much yet
13:47Tomcat|sheriffdutyCallek: KWierso|afk has also created a awesome documentation https://wiki.mozilla.org/Sheriffing/How:To:SheriffingFromUnifiedRepos
13:47RyanVMand yeah, I guess the relbranch stuff isn&#39;t the end of the world assume you&#39;d just pull them as a new head as needed
13:47RyanVMand prune it off later
13:49RyanVMerr, mozilla-unified doesn&#39;t include autoland?!
13:49RyanVMthat&#39;s...a deal breaker
13:49RyanVMi suppose I understand why
13:50RyanVMgiven target audiences and non-publishing and all
13:50Tomcat|sheriffdutyit does https://hg.mozilla.org/hgcustom/version-control-tools/file/default/pylib/mozautomation/mozautomation/repository.py
13:50Tomcat|sheriffdutyintegration -> autoland
13:51Tomcat|sheriffdutyoh i see
13:52Tomcat|sheriffdutyyeah
13:52Tomcat|sheriffdutyand we don&#39;t push follow ups also not anymore to autoland RyanVM
13:52RyanVMyou still need to backout from there...
13:52Tomcat|sheriffdutyso its just &quot;manually&quot; for merges
13:52Tomcat|sheriffdutyoh yeah true
13:53RyanVMryanvm@ubuntu:~/repos$ du -hs mozilla mozilla-unified
13:53RyanVM5.3G mozilla
13:53RyanVM4.4G mozilla-unified
13:53RyanVMwow, that&#39;s not nothing
13:59dustinCallek: fyi I landed the patch in bug 1347889
14:02Callekdustin: thanks
14:21travis-cibuild-buildbot-configs#2486 (master - 6312e2a : Mihai Tabara): The build passed. (https://travis-ci.org/mozilla-releng/build-buildbot-configs/builds/211764495)
14:26h4writerCallek: I&#39;m a bit stuck now. I cloned the unified repo. Now doing hg update -r &quot;try_revision&quot; or hg pull -r &quot;try_revision&quot; or hg up try is not working ?
14:27jcristauhg pull -r $try_revision https://hg.mozilla.org/try
14:27jcristau?
14:28h4writeroh
14:28Callekh4writer: yea what jcristau said
14:29travis-cibuild-buildbot-configs#2487 (production - 534ac6f : Mihai Tabara): The build passed. (https://travis-ci.org/mozilla-releng/build-buildbot-configs/builds/211767840)
14:29h4writerCallek: jcristau that works, thanks!
17:17travis-cibuild-puppet#1069 (production - d3ae7bb : Chris AtLee): The build passed. (https://travis-ci.org/mozilla/build-puppet/builds/211834314)
17:18travis-cibuild-puppet#1068 (master - f7d9214 : Chris AtLee): The build passed. (https://travis-ci.org/mozilla/build-puppet/builds/211834308)
17:48travis-cibuild-tools#1687 (master - 34926c7 : ffxbld): The build passed. (https://travis-ci.org/mozilla/build-tools/builds/211844016)
19:29travis-cibuild-puppet#1071 (master - 127a2c5 : Chris AtLee): The build passed. (https://travis-ci.org/mozilla/build-puppet/builds/211879739)
19:45rstrongbhearsum: do you know who is the tech person at Mozilla that manages the CDN?
19:46bhearsumrstrong: not 100% sure, but oremj is a good starting point
19:46rstrongthanks!
19:46bhearsumno problem
22:36gkwnthomas: our loaner machines are 10.7 - the machines where we would be fuzzing in their spare time, are they 10.7 too?
22:36nthomasall the same
22:36gkwnthomas: are there plans to boost the minimum version anytime soon?
22:36nthomaswere planning to cross compile mac using linux hosts
22:37gkwnthomas: so these mac machines will no longer exist? I thought we are still maintaining some as test machines (not build machines)
22:37nthomasI dont know if they are compatible with existing test pools, seems unlikely
22:37* gkw is grappling with ancient gdb versions on 10.7
22:38gkwnthomas: how are we going to do Mac testing then. Is fuzzing on releng machines&#39; spare time still a sensible option? (last I understood it, it was going to be Mac-only)
22:39nthomasso fuzzing jobs are happening on the build machines right now, and that need will go away if we cross-compile. Unit/talos Testing is going to have to stay on native hardware, but thats a seperate pool of machines
22:41nthomasdoes that clear it up ?
22:41catleegkw: you need to work on porting your fuzzing jobs to taskcluster
22:41nthomasI dont know if there are any plans for the h/w afterwards. Going to take a while for it to ride the trains anyway
22:41catleeeven the testers will be using taskcluster soon
22:42* nthomas thoroughly agrees with moving forward, with appropriate agreements about how much resource is available
22:43akii think fuzzing will make queue priorities more important
23:24gkwcatlee / nthomas: I guess we&#39;ll have newer OS&#39;es after moving to taskcluster and also EC2 which I presume?
23:24gkwi.e. Windows/Linux
17 Mar 2017
No messages
   
Last message: 7 days and 7 hours ago