Merge lp:~dpigott/lava-dispatcher/add-bootloader-support into lp:lava-dispatcher
- add-bootloader-support
- Merge into trunk
Status: | Merged |
---|---|
Merged at revision: | 459 |
Proposed branch: | lp:~dpigott/lava-dispatcher/add-bootloader-support |
Merge into: | lp:lava-dispatcher |
Diff against target: |
136 lines (+17/-16) 6 files modified
lava_dispatcher/actions/deploy.py (+3/-2) lava_dispatcher/client/lmc_utils.py (+6/-6) lava_dispatcher/client/targetdevice.py (+2/-2) lava_dispatcher/device/fastmodel.py (+2/-2) lava_dispatcher/device/master.py (+2/-2) lava_dispatcher/device/qemu.py (+2/-2) |
To merge this branch: | bzr merge lp:~dpigott/lava-dispatcher/add-bootloader-support |
Related bugs: |
Reviewer | Review Type | Date Requested | Status |
---|---|---|---|
Dave Pigott | Approve | ||
Review via email: mp+135151@code.launchpad.net |
Commit message
Description of the change
Added in an option to specify a bootloader in the json file. If not specified, it defaults to 'u_boot'
Fathi Boudra (fboudra) wrote : | # |
Fathi Boudra (fboudra) wrote : | # |
Dave Pigott (dpigott) wrote : | # |
I know, and I thought long and hard about which was the right way to go. At the end of the day, the solution was much more flexible this way, since you can also get a return such as:
+------
Supported boards | Supported bootloaders
+------
linaro-vexpress | uefi,u_boot
+------
It would not be possible to decide which one to pick.
This way, the person or process creating and submitting jobs is responsible for picking the right one, and if new ones get added, then those just get done as well.
There will probably be some other work to do in the way the lava dispatcher handles things when interrupting boot, but that's not a problem when sd-mux arrives.
Dave Pigott (dpigott) wrote : | # |
And actually, since it is indeed a free format string, then if somebody decides to call u_boot "neddy-
Another key point is that if the dispatcher made a decision about the bootloader, then that goes against someone explicitly trying to specify and test a particular bootloader when we get to that point.
Andy Doan (doanac) wrote : | # |
seems okay. In general I'm a little uncomfortable with inserting a function parameter rather than appending it to the list. However, it looks like you grep'd through code and fixed all the references where this was affected.
Andy Doan (doanac) wrote : | # |
On 11/20/2012 07:47 AM, Fathi Boudra wrote:
> It's worth mentioning that 'u_boot' is just a string and can be anything.
> You can use linaro-media-create --read-hwpack to get the supported bootloaders and pass a valid string.
Yes, but that should only matter if we are auto-guessing for the user,
right? Can we just get away with requiring users to provide the
bootloader they want in the event its not u-boot?
Fathi Boudra (fboudra) wrote : | # |
On 20 November 2012 17:48, Andy Doan wrote:
> On 11/20/2012 07:47 AM, Fathi Boudra wrote:
>>
>> It's worth mentioning that 'u_boot' is just a string and can be anything.
>> You can use linaro-media-create --read-hwpack to get the supported
>> bootloaders and pass a valid string.
>
> Yes, but that should only matter if we are auto-guessing for the user,
> right? Can we just get away with requiring users to provide the bootloader
> they want in the event its not u-boot?
You're already guessing that the default bootloader is U-Boot and its
label is called 'u_boot'.
I don't think you have to guess as the hwpack provides the default
bootloader and also the label.
No interaction with the user here.
Fathi Boudra (fboudra) wrote : | # |
On 20 November 2012 16:24, Dave Pigott wrote:
> I know, and I thought long and hard about which was the right way to go. At the end of the day, the solution was much more flexible this way, since you can also get a return such as:
>
> +------
> Supported boards | Supported bootloaders
> +------
> linaro-vexpress | uefi,u_boot
> +------
>
> It would not be possible to decide which one to pick.
According to the output, default bootloader is UEFI and the label is 'uefi'.
Dave Pigott (dpigott) wrote : | # |
Yeah, I checked thoroughly, because I prefer to have function parameters in a logical sequence.
Sent from my Aldis Lamp
On 20 Nov 2012, at 15:46, Andy Doan <email address hidden> wrote:
> seems okay. In general I'm a little uncomfortable with inserting a function parameter rather than appending it to the list. However, it looks like you grep'd through code and fixed all the references where this was affected.
> --
> https:/
> You are the owner of lp:~dpigott/lava-dispatcher/add-bootloader-support.
Dave Pigott (dpigott) wrote : | # |
Ok. So what you're saying is that to support this, we need to accept a selection in the JSON file, and then use the read-hwpack option to determine if it's valid. If nothing is specified we use the first in the list for the matching device type.
That's probably enough to push it into backlog, to be honest. If my change is unsupportable, then let's just throw it away,
On 20 Nov 2012, at 16:01, Fathi Boudra <email address hidden> wrote:
> On 20 November 2012 17:48, Andy Doan wrote:
>> On 11/20/2012 07:47 AM, Fathi Boudra wrote:
>>>
>>> It's worth mentioning that 'u_boot' is just a string and can be anything.
>>> You can use linaro-media-create --read-hwpack to get the supported
>>> bootloaders and pass a valid string.
>>
>> Yes, but that should only matter if we are auto-guessing for the user,
>> right? Can we just get away with requiring users to provide the bootloader
>> they want in the event its not u-boot?
>
> You're already guessing that the default bootloader is U-Boot and its
> label is called 'u_boot'.
> I don't think you have to guess as the hwpack provides the default
> bootloader and also the label.
> No interaction with the user here.
>
> --
> https:/
> You are the owner of lp:~dpigott/lava-dispatcher/add-bootloader-support.
Andy Doan (doanac) wrote : | # |
On 11/20/2012 10:58 AM, Dave Pigott wrote:
> Ok. So what you're saying is that to support this, we need to accept a selection in the JSON file, and then use the read-hwpack option to determine if it's valid. If nothing is specified we use the first in the list for the matching device type.
>
> That's probably enough to push it into backlog, to be honest. If my change is unsupportable, then let's just throw it away,
Fathi and I discussed on IRC. I think what you have now is good. I don't
think we need to do validation of the bootloader parameter. we'll put
the responsibility on the user for now. In the, likely near, future we
can do Fathi's suggesion and validated (or automatically choose) based
on this l-m-c command.
Dave Pigott (dpigott) wrote : | # |
On 20 Nov 2012, at 17:05, Andy Doan <email address hidden> wrote:
> On 11/20/2012 10:58 AM, Dave Pigott wrote:
>> Ok. So what you're saying is that to support this, we need to accept a selection in the JSON file, and then use the read-hwpack option to determine if it's valid. If nothing is specified we use the first in the list for the matching device type.
>>
>> That's probably enough to push it into backlog, to be honest. If my change is unsupportable, then let's just throw it away,
>
> Fathi and I discussed on IRC. I think what you have now is good. I don't think we need to do validation of the bootloader parameter. we'll put the responsibility on the user for now. In the, likely near, future we can do Fathi's suggesion and validated (or automatically choose) based on this l-m-c command.
Cool.
Dave Pigott (dpigott) wrote : | # |
On 20 Nov 2012, at 17:07, Andy Doan <email address hidden> wrote:
> On 11/20/2012 10:58 AM, Dave Pigott wrote:
>> Ok. So what you're saying is that to support this, we need to accept a selection in the JSON file, and then use the read-hwpack option to determine if it's valid. If nothing is specified we use the first in the list for the matching device type.
>>
>> That's probably enough to push it into backlog, to be honest. If my change is unsupportable, then let's just throw it away,
>
> Fathi and I discussed on IRC. I think what you have now is good. I don't
> think we need to do validation of the bootloader parameter. we'll put
> the responsibility on the user for now. In the, likely near, future we
> Efaucan do Fathi's suggesion and validated (or automatically choose) based
> on this l-m-c command.
>
Actually, the sensible behaviour is for l-m-c to, by default, use the default boot loader if none is specified, since they have to inspect the hwpack anyway. Then they'll immediately fail if the requested one doesn't exist.
Andy Doan (doanac) wrote : | # |
On 11/20/2012 11:16 AM, Dave Pigott wrote:
> Actually, the sensible behaviour is for l-m-c to, by default, use the default boot loader if none is specified, since they have to inspect the hwpack anyway. Then they'll immediately fail if the requested one doesn't exist.
yeah, that's what I was trying to say. sorry I wasn't clear.
Dave Pigott (dpigott) : | # |
Preview Diff
1 | === modified file 'lava_dispatcher/actions/deploy.py' |
2 | --- lava_dispatcher/actions/deploy.py 2012-10-24 01:34:07 +0000 |
3 | +++ lava_dispatcher/actions/deploy.py 2012-11-20 13:38:19 +0000 |
4 | @@ -54,6 +54,7 @@ |
5 | 'rootfs': {'type': 'string', 'optional': True}, |
6 | 'image': {'type': 'string', 'optional': True}, |
7 | 'rootfstype': {'type': 'string', 'optional': True}, |
8 | + 'bootloader': {'type': 'string', 'optional': True, 'default': 'u_boot'}, |
9 | }, |
10 | 'additionalProperties': False, |
11 | } |
12 | @@ -69,9 +70,9 @@ |
13 | elif 'image' not in parameters: |
14 | raise ValueError('must specify image if not specifying a hwpack') |
15 | |
16 | - def run(self, hwpack=None, rootfs=None, image=None, rootfstype='ext3'): |
17 | + def run(self, hwpack=None, rootfs=None, image=None, rootfstype='ext3', bootloader='u_boot'): |
18 | self.client.deploy_linaro( |
19 | - hwpack=hwpack, rootfs=rootfs, image=image, rootfstype=rootfstype) |
20 | + hwpack=hwpack, rootfs=rootfs, image=image, rootfstype=rootfstype, bootloader=bootloader) |
21 | |
22 | |
23 | class cmd_deploy_linaro_android_image(BaseAction): |
24 | |
25 | === modified file 'lava_dispatcher/client/lmc_utils.py' |
26 | --- lava_dispatcher/client/lmc_utils.py 2012-09-27 21:59:57 +0000 |
27 | +++ lava_dispatcher/client/lmc_utils.py 2012-11-20 13:38:19 +0000 |
28 | @@ -15,7 +15,7 @@ |
29 | ) |
30 | |
31 | |
32 | -def generate_image(client, hwpack_url, rootfs_url, outdir, rootfstype=None): |
33 | +def generate_image(client, hwpack_url, rootfs_url, outdir, bootloader='u_boot', rootfstype=None): |
34 | """Generate image from a hwpack and rootfs url |
35 | |
36 | :param hwpack_url: url of the Linaro hwpack to download |
37 | @@ -43,8 +43,8 @@ |
38 | logging.info("client.device_type = %s" %client.config.device_type) |
39 | |
40 | cmd = ("sudo flock /var/lock/lava-lmc.lck linaro-media-create --hwpack-force-yes --dev %s " |
41 | - "--image-file %s --binary %s --hwpack %s --image-size 3G" % |
42 | - (client.config.lmc_dev_arg, image_file, rootfs_path, hwpack_path)) |
43 | + "--image-file %s --binary %s --hwpack %s --image-size 3G --bootloader %s" % |
44 | + (client.config.lmc_dev_arg, image_file, rootfs_path, hwpack_path, bootloader)) |
45 | if rootfstype is not None: |
46 | cmd += ' --rootfs ' + rootfstype |
47 | logging.info("Executing the linaro-media-create command") |
48 | @@ -53,11 +53,11 @@ |
49 | _run_linaro_media_create(cmd) |
50 | return image_file |
51 | |
52 | -def generate_fastmodel_image(hwpack, rootfs, odir, size="2000M"): |
53 | +def generate_fastmodel_image(hwpack, rootfs, odir, bootloader='u_boot', size="2000M"): |
54 | cmd = ("flock /var/lock/lava-lmc.lck sudo linaro-media-create " |
55 | "--dev fastmodel --output-directory %s --image-size %s " |
56 | - "--hwpack %s --binary %s --hwpack-force-yes" % |
57 | - (odir, size, hwpack, rootfs) ) |
58 | + "--hwpack %s --binary %s --hwpack-force-yes --bootloader %s" % |
59 | + (odir, size, hwpack, rootfs, bootloader) ) |
60 | logging.info("Generating fastmodel image with: %s" % cmd) |
61 | _run_linaro_media_create(cmd) |
62 | |
63 | |
64 | === modified file 'lava_dispatcher/client/targetdevice.py' |
65 | --- lava_dispatcher/client/targetdevice.py 2012-10-26 06:22:05 +0000 |
66 | +++ lava_dispatcher/client/targetdevice.py 2012-11-20 13:38:19 +0000 |
67 | @@ -50,7 +50,7 @@ |
68 | self.target_device.deploy_android(boot, system, data) |
69 | |
70 | def deploy_linaro(self, hwpack=None, rootfs=None, image=None, |
71 | - rootfstype='ext3'): |
72 | + rootfstype='ext3', bootloader='u_boot'): |
73 | if image is None: |
74 | if hwpack is None or rootfs is None: |
75 | raise CriticalError( |
76 | @@ -60,7 +60,7 @@ |
77 | "cannot specify hwpack or rootfs when specifying image") |
78 | |
79 | if image is None: |
80 | - self.target_device.deploy_linaro(hwpack, rootfs) |
81 | + self.target_device.deploy_linaro(hwpack, rootfs, bootloader) |
82 | else: |
83 | self.target_device.deploy_linaro_prebuilt(image) |
84 | |
85 | |
86 | === modified file 'lava_dispatcher/device/fastmodel.py' |
87 | --- lava_dispatcher/device/fastmodel.py 2012-11-16 00:47:20 +0000 |
88 | +++ lava_dispatcher/device/fastmodel.py 2012-11-20 13:38:19 +0000 |
89 | @@ -113,12 +113,12 @@ |
90 | |
91 | self._customize_android() |
92 | |
93 | - def deploy_linaro(self, hwpack=None, rootfs=None): |
94 | + def deploy_linaro(self, hwpack=None, rootfs=None, bootloader='u_boot'): |
95 | hwpack = download_image(hwpack, self.context, decompress=False) |
96 | rootfs = download_image(rootfs, self.context, decompress=False) |
97 | odir = os.path.dirname(rootfs) |
98 | |
99 | - generate_fastmodel_image(hwpack, rootfs, odir) |
100 | + generate_fastmodel_image(hwpack, rootfs, odir, bootloader) |
101 | self._sd_image = '%s/sd.img' % odir |
102 | self._axf = None |
103 | for f in self.config.simulator_axf_files: |
104 | |
105 | === modified file 'lava_dispatcher/device/master.py' |
106 | --- lava_dispatcher/device/master.py 2012-11-16 00:44:40 +0000 |
107 | +++ lava_dispatcher/device/master.py 2012-11-20 13:38:19 +0000 |
108 | @@ -94,10 +94,10 @@ |
109 | # we always leave master image devices powered on |
110 | pass |
111 | |
112 | - def deploy_linaro(self, hwpack, rfs): |
113 | + def deploy_linaro(self, hwpack, rfs, bootloader): |
114 | self.boot_master_image() |
115 | |
116 | - image_file = generate_image(self, hwpack, rfs, self.scratch_dir) |
117 | + image_file = generate_image(self, hwpack, rfs, self.scratch_dir, bootloader) |
118 | (boot_tgz, root_tgz, data) = self._generate_tarballs(image_file) |
119 | |
120 | self._deploy_tarballs(boot_tgz, root_tgz) |
121 | |
122 | === modified file 'lava_dispatcher/device/qemu.py' |
123 | --- lava_dispatcher/device/qemu.py 2012-11-15 21:23:20 +0000 |
124 | +++ lava_dispatcher/device/qemu.py 2012-11-20 13:38:19 +0000 |
125 | @@ -46,9 +46,9 @@ |
126 | super(QEMUTarget, self).__init__(context, config) |
127 | self._sd_image = None |
128 | |
129 | - def deploy_linaro(self, hwpack=None, rootfs=None): |
130 | + def deploy_linaro(self, hwpack=None, rootfs=None, bootloader='u_boot'): |
131 | odir = self.scratch_dir |
132 | - self._sd_image = generate_image(self, hwpack, rootfs, odir) |
133 | + self._sd_image = generate_image(self, hwpack, rootfs, odir, bootloader) |
134 | self._customize_linux(self._sd_image) |
135 | |
136 | def deploy_linaro_prebuilt(self, image): |
It's worth mentioning that 'u_boot' is just a string and can be anything.
You can use linaro-media-create --read-hwpack to get the supported bootloaders and pass a valid string.