Merge lp:~dpigott/lava-dispatcher/add-bootloader-support into lp:lava-dispatcher

Proposed by Dave Pigott
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
Reviewer Review Type Date Requested Status
Dave Pigott Approve
Review via email: mp+135151@code.launchpad.net

Description of the change

Added in an option to specify a bootloader in the json file. If not specified, it defaults to 'u_boot'

To post a comment you must log in.
Revision history for this message
Fathi Boudra (fboudra) 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.

Revision history for this message
Fathi Boudra (fboudra) wrote :
Revision history for this message
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.

Revision history for this message
Dave Pigott (dpigott) wrote :

And actually, since it is indeed a free format string, then if somebody decides to call u_boot "neddy-the-bootloader" we have no way of knowing what sort of bootloader it really is. I guess what I'm advocating is that we should standardise on a naming convention in the hwpacks. Otherwise we are asking for a lot of trouble.

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.

Revision history for this message
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.

Revision history for this message
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?

Revision history for this message
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.

Revision history for this message
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'.

Revision history for this message
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://code.launchpad.net/~dpigott/lava-dispatcher/add-bootloader-support/+merge/135151
> You are the owner of lp:~dpigott/lava-dispatcher/add-bootloader-support.

Revision history for this message
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://code.launchpad.net/~dpigott/lava-dispatcher/add-bootloader-support/+merge/135151
> You are the owner of lp:~dpigott/lava-dispatcher/add-bootloader-support.

Revision history for this message
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.

Revision history for this message
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.

Revision history for this message
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.

Revision history for this message
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.

Revision history for this message
Dave Pigott (dpigott) :
review: Approve

Preview Diff

[H/L] Next/Prev Comment, [J/K] Next/Prev File, [N/P] Next/Prev Hunk
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):

Subscribers

People subscribed via source and target branches