Hello,
I am working on improving the hwpack names delivered by the Linaro Kernel Continuous Integration.
To start on this I needed inputs from the kernel team. currently the hwpack containing the newly built kernel debian package is named for example as hwpack_linaro-panda_20111004-1126_armel_supported.tar.gz and it includes 1) The board on which the hwpack can be booted 2) The hwpack creation timestamp includes the date in yyyymmdd format along with the time in hhmm format.
The hwpack name does not include any defconfig related information, which was used to build the kernel. Do we need to use the defconfig name as well to be part of the hwpack name ? Is there any other information you would like to include in the hwpack name ? Or do we need to continue with the current hwpack names ?
On Mon, Oct 10, 2011, Deepti Kalakeri wrote:
- The board on which the hwpack can be booted
- The hwpack creation timestamp includes the date in yyyymmdd format along
with the time in hhmm format.
The hwpack name does not include any defconfig related information, which was used to build the kernel. Do we need to use the defconfig name as well to be part of the hwpack name ? Is there any other information you would like to include in the hwpack name ? Or do we need to continue with the current hwpack names ?
We rarely use a defconfig alone; however in the case of kernel .debs, you should find the corresponding config under boot/config-`uname -r` in the .deb (dpkg-deb -x the kernel .deb to find the config).
On Mon, Oct 10, 2011 at 2:08 PM, Loïc Minier loic.minier@linaro.org wrote:
On Mon, Oct 10, 2011, Deepti Kalakeri wrote:
- The board on which the hwpack can be booted
- The hwpack creation timestamp includes the date in yyyymmdd format
along
with the time in hhmm format.
The hwpack name does not include any defconfig related information, which was used to build the kernel. Do we need to use the defconfig name as well to be part of the hwpack
name ?
Is there any other information you would like to include in the hwpack
name
? Or do we need to continue with the current hwpack names ?
We rarely use a defconfig alone; however in the case of kernel .debs, you should find the corresponding config under boot/config-`uname -r` in the .deb (dpkg-deb -x the kernel .deb to find the config).
(note that in the case of kernel CI we currently use pure defconfig configurations)
What I asked deepti to work on is to make the CI hwpacks exported through http://ci.linaro.org/kernel_hwpack/ to be better backtrack-able to the actual CI job they are coming from.
Instead of exploding the hwpack name with more info, we could also introduce a new directory level in the kernel_hwpack directory like:
kernel_hwpack/ci_job_name/HWPACK1,2,3
... and then leave the hwpack names as they are now. Maybe improve the version to rather use the git describe version of the kernel tree and not the kind of meaningless timestamp.
Hello Alexander,
Oops! I am sorry if I have misunderstood the BP https://blueprints.launchpad.net/linaro-ci/+spec/improve-hwpack-names. If we check the Acceptance criteria, it says
"Acceptance: The new name of hwpack generated by the linaro-hwpack-replace contains the defconfig information."
If we need to change the path of where the hwpack are stored and not the hwpack names then we need not have to change anything in the linaro-hwpack-replace. In that case we would need to rewrite the BP with appropriate items.
On Mon, Oct 10, 2011 at 5:52 PM, Alexander Sack asac@linaro.org wrote:
On Mon, Oct 10, 2011 at 2:08 PM, Loïc Minier loic.minier@linaro.orgwrote:
On Mon, Oct 10, 2011, Deepti Kalakeri wrote:
- The board on which the hwpack can be booted
- The hwpack creation timestamp includes the date in yyyymmdd format
along
with the time in hhmm format.
The hwpack name does not include any defconfig related information,
which
was used to build the kernel. Do we need to use the defconfig name as well to be part of the hwpack
name ?
Is there any other information you would like to include in the hwpack
name
? Or do we need to continue with the current hwpack names ?
We rarely use a defconfig alone; however in the case of kernel .debs, you should find the corresponding config under boot/config-`uname -r` in the .deb (dpkg-deb -x the kernel .deb to find the config).
(note that in the case of kernel CI we currently use pure defconfig configurations)
What I asked deepti to work on is to make the CI hwpacks exported through http://ci.linaro.org/kernel_hwpack/ to be better backtrack-able to the actual CI job they are coming from.
Instead of exploding the hwpack name with more info, we could also introduce a new directory level in the kernel_hwpack directory like:
kernel_hwpack/ci_job_name/HWPACK1,2,3
... and then leave the hwpack names as they are now. Maybe improve the version to rather use the git describe version of the kernel tree and not the kind of meaningless timestamp.
-- Alexander Sack Technical Director, Linaro Platform Teams http://www.linaro.org | Open source software for ARM SoCs
http://twitter.com/#%21/linaroorg - http://www.linaro.org/linaro-blog
On Mon, Oct 10, 2011 at 02:22:05PM +0200, Alexander Sack wrote:
On Mon, Oct 10, 2011 at 2:08 PM, Loïc Minier loic.minier@linaro.org wrote:
On Mon, Oct 10, 2011, Deepti Kalakeri wrote:
- The board on which the hwpack can be booted
- The hwpack creation timestamp includes the date in yyyymmdd format
along
with the time in hhmm format.
The hwpack name does not include any defconfig related information, which was used to build the kernel. Do we need to use the defconfig name as well to be part of the hwpack
name ?
Is there any other information you would like to include in the hwpack
name
? Or do we need to continue with the current hwpack names ?
We rarely use a defconfig alone; however in the case of kernel .debs, you should find the corresponding config under boot/config-`uname -r` in the .deb (dpkg-deb -x the kernel .deb to find the config).
(note that in the case of kernel CI we currently use pure defconfig configurations)
What I asked deepti to work on is to make the CI hwpacks exported through http://ci.linaro.org/kernel_hwpack/ to be better backtrack-able to the actual CI job they are coming from.
Instead of exploding the hwpack name with more info, we could also introduce a new directory level in the kernel_hwpack directory like:
kernel_hwpack/ci_job_name/HWPACK1,2,3
... and then leave the hwpack names as they are now. Maybe improve the version to rather use the git describe version of the kernel tree and not the kind of meaningless timestamp.
Looks better, but...
We need unique build IDs, and these are the critical thing we need to reference from the build. Anything else seems likely to result in fragility later.
The CI infrastructure can tell us what config and sources a given build was generated from, so not only do we not need to put this information in the builds, I believe that we _should not_. Sooner or later it will get inconsistent or wrong, whereas the CI server is authoritative.
Also if we try to put metadata into filenames, it will keep being found to be wrong or insufficient, so we may have to heep changing it.
By putting the build ID into the kernel image .deb or the kernel release string, we can find out everything we need to know about the build, regardless of whether we start with an installed target platform, the .debs, the hwpack or the hwpack URL.
For convenience only, we can put the job name and build ID into the URL and/or the hwpack filename, and possibly in the hwpack metadata, but it's important to remember that this is only a convenience and is not the authoritative source of the information. Personally, I'd recommend not putting the ID in too many places -- we would just end having to many different mechanisms for querying it, instead of having just one, robust, mechanism.
Thoughts?
Cheers ---Dave
On Mon, Oct 10, 2011 at 4:41 PM, Dave Martin dave.martin@linaro.org wrote:
For convenience only, we can put the job name and build ID into the
URL and/or the hwpack filename, and possibly in the hwpack metadata,
but it's important to remember that this is only a convenience and is not the authoritative source of the information. Personally, I'd recommend not putting the ID in too many places -- we would just end having to many different mechanisms for querying it, instead of having just one, robust, mechanism.
Thoughts?
Right. All this is for convenience only!
Personally I would like to be able to find the hwpack for a build easily by going to http://ci.linaro.org/kernel_hwpack/ and eyeballing the filenames/directories there. Currently you don't have a way to find out which job/tree the hwpack is coming from nor do you get any hint which build ID in that job to look at.
So given all this, how about this scheme:
http://ci.linaro.org/kernel_hwpack/%24CI_JOBNAME/hwpack_linaro-panda_YYYYMMD...
Example:
http://ci.linaro.org/kernel_hwpack/linux-next_beagle-omap2plushttps://ci.linaro.org/jenkins/view/Linux%20Next%20CI%20Builds/job/linux-next_beagle-omap2plus/ /hwpack_linaro-panda_20110927-0545.b160.tar.gz
would refer to the hwpack coming out of this build:
-> https://ci.linaro.org/jenkins/view/Linux%20Next%20CI%20Builds/job/linux-next...
Sounds good?
On Tue, Oct 11, 2011 at 5:32 PM, Alexander Sack asac@linaro.org wrote:
On Mon, Oct 10, 2011 at 4:41 PM, Dave Martin dave.martin@linaro.orgwrote:
For convenience only, we can put the job name and build ID into the
URL and/or the hwpack filename, and possibly in the hwpack metadata,
but it's important to remember that this is only a convenience and is not the authoritative source of the information. Personally, I'd recommend not putting the ID in too many places -- we would just end having to many different mechanisms for querying it, instead of having just one, robust, mechanism.
Thoughts?
Right. All this is for convenience only!
Personally I would like to be able to find the hwpack for a build easily by going to http://ci.linaro.org/kernel_hwpack/ and eyeballing the filenames/directories there. Currently you don't have a way to find out which job/tree the hwpack is coming from nor do you get any hint which build ID in that job to look at.
So given all this, how about this scheme:
http://ci.linaro.org/kernel_hwpack/%24CI_JOBNAME/hwpack_linaro-panda_YYYYMMD...
Example:
http://ci.linaro.org/kernel_hwpack/linux-next_beagle-omap2plushttps://ci.linaro.org/jenkins/view/Linux%20Next%20CI%20Builds/job/linux-next_beagle-omap2plus/ /hwpack_linaro-panda_20110927-0545.b160.tar.gz
would refer to the hwpack coming out of this build:
-> https://ci.linaro.org/jenkins/view/Linux%20Next%20CI%20Builds/job/linux-next...
Sounds good?
Yeah! This sounds good.
I have submitted the changes to include the git tree being built and the job name as below :
http://ci.linaro.org/kernel_hwpack/linux-linaro-3_0/linux-linaro-3.0_panda-o...
Let me know if we need more changes.
-- Alexander Sack Technical Director, Linaro Platform Teams http://www.linaro.org | Open source software for ARM SoCs http://twitter.com/#%21/linaroorg - http://www.linaro.org/linaro-blog
linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
On Tue, Oct 11, 2011 at 06:57:53PM +0530, Deepti Kalakeri wrote:
On Tue, Oct 11, 2011 at 5:32 PM, Alexander Sack asac@linaro.org wrote:
[...]
Example:
http://ci.linaro.org/kernel_hwpack/linux-next_beagle-omap2plushttps://ci.linaro.org/jenkins/view/Linux%20Next%20CI%20Builds/job/linux-next_beagle-omap2plus/ /hwpack_linaro-panda_20110927-0545.b160.tar.gz
would refer to the hwpack coming out of this build:
-> https://ci.linaro.org/jenkins/view/Linux%20Next%20CI%20Builds/job/linux-next...
Sounds good?
Yeah! This sounds good.
I have submitted the changes to include the git tree being built and the job name as below :
http://ci.linaro.org/kernel_hwpack/linux-linaro-3_0/linux-linaro-3.0_panda-o...
Let me know if we need more changes.
Can we please include the build number as Alexander suggested?
Also, what timezone is used to determine the date and time? I think we should use UTC, not any local timezone.
Otherwise, it looks good to me.
Cheers ---Dave
On Tue, Oct 11, 2011 at 3:42 PM, Dave Martin dave.martin@linaro.org wrote:
Also, what timezone is used to determine the date and time? I think we should use UTC, not any local timezone.
agreed on the UTC time.
On Tue, Oct 11, 2011 at 7:23 PM, Alexander Sack asac@linaro.org wrote:
On Tue, Oct 11, 2011 at 3:42 PM, Dave Martin dave.martin@linaro.orgwrote:
Also, what timezone is used to determine the date and time? I think we should use UTC, not any local timezone.
agreed on the UTC time.
Yup its UTC time.
-- Alexander Sack Technical Director, Linaro Platform Teams http://www.linaro.org | Open source software for ARM SoCs http://twitter.com/#%21/linaroorg - http://www.linaro.org/linaro-blog
On Wed, Oct 12, 2011 at 03:10:59PM +0530, Deepti Kalakeri wrote:
On Tue, Oct 11, 2011 at 7:23 PM, Alexander Sack asac@linaro.org wrote:
On Tue, Oct 11, 2011 at 3:42 PM, Dave Martin dave.martin@linaro.orgwrote:
Also, what timezone is used to determine the date and time? I think we should use UTC, not any local timezone.
agreed on the UTC time.
Yup its UTC time.
Great, thanks
---Dave
On 12 October 2011 09:25, Dave Martin dave.martin@linaro.org wrote:
On Wed, Oct 12, 2011 at 03:10:59PM +0530, Deepti Kalakeri wrote:
On Tue, Oct 11, 2011 at 7:23 PM, Alexander Sack asac@linaro.org wrote:
On Tue, Oct 11, 2011 at 3:42 PM, Dave Martin dave.martin@linaro.orgwrote:
Also, what timezone is used to determine the date and time? I think we should use UTC, not any local timezone.
agreed on the UTC time.
Yup its UTC time.
+1 on this and the naming schemed proposed by Alexander.
~Deepak
-
Alexander Sack -
Dave Martin -
Deepak Saxena -
Deepti Kalakeri -
Loïc Minier