936601 - Give graydon the ability to test Android 2.3 on an emulator work live in Ash

Status: RESOLVED FIXED

(Infrastructure & Operations Graveyard :: CIDuty, task, P2)

Description

[Armen [:armenzg]]

graydon, would you be able to describe what you think you would need?
How far do you think we're from being able to put your code changes live and iterate from there? What are our current list of items to knock off?

Thanks!

Comment 1

[Graydon Hoare :graydon]

Depends on the cost of iteration. I'd be happy to try with the current AVDs (currently rebuilding the arm ones after feedback on the x86 ones from gbrown) and the changes I proposed to the unit test script in bug 910092. Who or what will I be disturbing by iterating on this? Just a random "red" showing up for emulator tests on a test branch somewhere?

Comment 2

[Armen [:armenzg]]

We would only be running this on Ash since we can test mozharness changes in there (http://hg.mozilla.org/users/asasaki_mozilla.com/ash-mozharness) by re-triggering jobs.

Setting this up can easily take weeks or days. I hope to do some experimenting and documentation on how to make projects like this iterate faster.

Comment 3

[Ed Morley [:emorley]]

(Tweaking summary since from bugmail this sounded like a TBPL request)

Comment 4

[Armen [:armenzg]]

Attachment: wip - buildbot-configs to add android 2.3 jobs to Ash

Comment 5

[Armen [:armenzg]]

Attachment: [buildbot-configs] add Android 2.3 jobs to Ash

This patch does the trick, however, I'm not sure if this is the right way.

Unfortunately, the "android" platform is only enabled on mobile masters which are on scl1 or on scl3. This means that the Ubuntu ec2 test machines are set on slavealloc to connect to them as the only builders that would need them would be the Android 2.3 Emulator ones.

In the case of android-x86, I could do this on the "linux test masters" by adding this:
    "limit_mobile_platforms": [
      "android-x86"
    ],

If I did that with "android", it would enable the tegra, panda and emulator builders, even though we would not get any pandas or tegras to connect to it because of slavealloc.

If I wanted, I could add another platform, however, IIUC it would require adding an extra sendchange to the Android builds.

What do you think I should do?

On another note, I'm not sure if I want to share the "android" platform with the Android 2.3 emulator builders as they actually should have a reboot step, unlike tegras and pandas.

Comment 6

[Aki Sasaki (not active)]

Comment on attachment 833152 [details] [diff] [review]
[buildbot-configs] add Android 2.3 jobs to Ash

test-masters.sh says:
ValueError: Schedulers must have unique names, but 'tests-ash-ubuntu64_vm-opt-unittest' was a duplicate

I think you have to rename the slave_platform.
That's why we have ubuntu64_vm-b2gdt in b2g_config.py ...
http://hg.mozilla.org/build/buildbot-configs/file/1bc432c630d8/mozilla-tests/b2g_config.py#l73

I'm going to minus this, but I think this patch is good once we have the slave_platform renamed.

Comment 7

[Justin Wood (:Callek)]

Comment on attachment 833152 [details] [diff] [review]
[buildbot-configs] add Android 2.3 jobs to Ash

Review of attachment 833152 [details] [diff] [review]:
-----------------------------------------------------------------

f+ if you address aki's r-

Comment 8

[Armen [:armenzg]]

Attachment: [buildbot-configs] add Android 2.3 jobs to Ash

Comment 9

[Armen [:armenzg]]

Attachment: [tools] add Android plaftorms to Linux testers (android, android-armv6, android-noion & android-2.3)

I dislike this but it is the most clean way I can think of fix this.
With this patch we will have the following builders on both the Linux test masters and the mobile test masters:
* android-armv6
* android-noion
* android-2.3
* android

On the mobile masters we would have the test boards that would take jobs for:
* android-armv6, android-noion and android

On the linux test masters we would have the tst-linux.*-ec2 machines to take jobs for:
* android-2.3

Comment 10

[Armen [:armenzg]]

Attachment: [puppet] add vm_android_2_3 to BuildSlaves.py for the test masters

Comment 11

[Armen [:armenzg]]

Here is the difference of the builders (test-masters.sh passes):
macair buildbot-configs hg:[default!] $ diff  list_of_builders_linux_tester.txt  list_of_builders_linux_tester.old.txt 
4468,4470d4467
< Android 2.3 Emulator ash opt test android_2_3-set-1 ScriptFactory
< Android 2.3 Emulator ash opt test android_2_3-set-2 ScriptFactory
< Android 2.3 Emulator ash opt test android_2_3-set-3 ScriptFactory
macair buildbot-configs hg:[default!] $ diff list_of_builders_panda_tester.txt list_of_builders_panda_tester.old.txt 
539,541d538
< Android 2.3 Emulator ash opt test android_2_3-set-1 ScriptFactory
< Android 2.3 Emulator ash opt test android_2_3-set-2 ScriptFactory
< Android 2.3 Emulator ash opt test android_2_3-set-3 ScriptFactory

Comment 12

[Chris Cooper [:coop] (he/him)]

Comment on attachment 8340078 [details] [diff] [review]
[buildbot-configs] add Android 2.3 jobs to Ash

Review of attachment 8340078 [details] [diff] [review]:
-----------------------------------------------------------------

::: mozilla-tests/mobile_config.py
@@ +16,5 @@
>  reload(localconfig)
>  from localconfig import SLAVES, TRY_SLAVES, GLOBAL_VARS, GRAPH_CONFIG
>  from config import MOZHARNESS_REBOOT_CMD
>  
> +TALOS_REMOTE_FENNEC_OPTS = {

Thanks for the cleanup here.

@@ +852,5 @@
>  }
>  # End of Androidx86 configurations
>  
> +# Beginning Android 2.3 configurations
> +ANDROID_2_3_MOZHARNESS_DICT = [

Can I just note my distaste with naming data structures after the data type that will represent them, i.e. _DICT? This isn't even a DICT at the top-level! I know it's a pattern repeated elsewhere, but that doesn't make it right (just consistently wrong).

Comment 13

[Armen [:armenzg]]

Comment on attachment 8340081 [details] [diff] [review]
[puppet] add vm_android_2_3 to BuildSlaves.py for the test masters

https://hg.mozilla.org/build/puppet/rev/2c7e6e3967bd

Comment 14

[Armen [:armenzg]]

Comment on attachment 8340080 [details] [diff] [review]
[tools] add Android plaftorms to Linux testers (android, android-armv6, android-noion & android-2.3)

https://hg.mozilla.org/build/tools/rev/c5f290bc8707

Comment 15

[Armen [:armenzg]]

I will deploy the last patch on Monday morning.

Comment 16

[Armen [:armenzg]]

Comment on attachment 8340078 [details] [diff] [review]
[buildbot-configs] add Android 2.3 jobs to Ash

https://hg.mozilla.org/build/buildbot-configs/rev/83dcdbb3d056

With all that happened today I forgot to land this.
I will make it go live first thing in the morning.

Comment 17

[Armen [:armenzg]]

Live in production.

I will be manually triggering some jobs.
They should show up in here:
https://tbpl.mozilla.org/?tree=Ash&jobname=Android&showall=1

Comment 18

[Armen [:armenzg]]

Hi graydon,
Can you please check this and let me know if you got everything you need for now?
https://tbpl.mozilla.org/?tree=Ash&jobname=Android 2.3 Emulator ash opt test android_2_3&showall=1

You can modify mozharness for those jobs by landing changes to http://hg.mozilla.org/users/asasaki_mozilla.com/ash-mozharness.
It is like a Try server but for mozharness.

Once you land a change, you have to re-trigger the jobs you want and that will grab the latest code from that repo.

Does this help?

Comment 19

[Armen [:armenzg]]

I thought we had already landed the androidarm.py config since it was NPOTB.
> IOError: Can't find android/androidarm.py in ['.', '/builds/slave/test/scripts/scripts/../configs', '/builds/slave/test/scripts/scripts/../../configs']!

Comment 20

[Armen [:armenzg]]

Found it:
https://bug910092.bugzilla.mozilla.org/attachment.cgi?id=831850

It is bitrotten.

Comment 21

[Graydon Hoare :graydon]

Yeah. I guess I misunderstood, thought that was one of the pieces you were going to land. I'm going to interact with it by landing on mozharness-ash and retriggering. LMK if you want me to not do this / do something else / wait for someone else to work on it instead, thanks.

Comment 22

[Armen [:armenzg]]

(In reply to Graydon Hoare :graydon from comment #21)
> Yeah. I guess I misunderstood, thought that was one of the pieces you were
> going to land. I'm going to interact with it by landing on mozharness-ash
> and retriggering. LMK if you want me to not do this / do something else /
> wait for someone else to work on it instead, thanks.

With all that many pieces I missed it.
Last I wrote was that if you could land it (but I don't recall if we spoke anything on the side):
https://bugzilla.mozilla.org/show_bug.cgi?id=910092#c108

Would you mind landing it to the official mozharness repo? I'm happy to review again if needed.

Let's take it to bug 910092.