builds. This gives a good indication whether bugs
are being resolved or introduced over time.
INDEPTH
included in this process, as we find e-mail to be a sufficient means of communication. The outlined process for building RPMs using Jenkins
helps us track the hacks we use to manipulate important packages for our systems.
Conclusion
I have discussed a method for setting up tools to develop RPMs against a custom distribution managed by Cobbler. Along with Trac, package developers can maintain updated RPMs of critical applications while managing communication. However, this process is not without gaps.
First, I’ll go over the gaps present in Jenkins, discussing core and plugin gaps that were not found. Then I’ll discuss the gaps in Cobbler regarding repository management. These two systems are lacking in integration, although that can be worked around.
MultiSCM is a functionality in Jenkins that would simplify the package building process.
There is a MultiSCM plugin
(https://wiki.jenkins-ci.org/display/
JENKINS/Multiple+SCMs+Plugin);
however, it is advertised as a proof-of-concept code. The hope is that the radio button selection for SCM would turn into a set of check boxes.
There are related bugs, but they have
not seen traction in years. Package development is another good example of the need to download and poll for updates on code from multiple places.
Here are links to information on the Jenkins Multiple SCMs Bugs:
Q https://issues.jenkins-ci.org/
browse/JENKINS-7192
Q https://issues.jenkins-ci.org/
browse/JENKINS-9720
Static code analysis tools are available as plugins for Jenkins
(https://wiki.jenkins-ci.org/display/
JENKINS/Violations), although these plugins do not include rpmlint. These plugins create graphs to track the number of warnings and errors in code over time. To perform the same task for packaging would be very helpful.
However, you can work around this gap by using the generic plot plugin (https://wiki.jenkins-ci.org/display/
JENKINS/Plot+Plugin) and another build step for each job.
Mock has a very well defined interface and workflow. A generic plugin to use Mock in Jenkins would be very useful. The plugin should include configuring the chroot configuration. Two kinds of build jobs also could be created, one using spec and source files, the other using
INDEPTH
106 / AUGUST 2014 / WWW.LINUXJOURNAL.COM
source RPMs. A test also would need to be created to verify that Mock can be run without prompting for a user password. This plugin would be very helpful for automating this process, as we currently have to copy scripts between jobs.
There are some additions to Cobbler that would be useful for this process as well. There are no per-repo triggers. The ability to tell Trac that packages went from repo test to repo prod would be useful.
Furthermore, the ability to tell Jenkins to build a package because a dependent package updated also would be useful.
The other useful addition to Cobbler would be the ability to remove older RPMs in the destination tree while synchronizing from the remote mirror.
Cobbler repositories, if the “breed”
is yum, build up in an append-only fashion. Processes for managing the space may be run periodically by removing the RPMs and then synchronizing the repository again.
However, this leaves the repository in a broken state until the process is complete. This feature could be useful in any Cobbler deployment, as it would make sure repositories do not continue to take up space when RPMs are not needed.
Trac does not need any additional
plugins to integrate better with Cobbler or Jenkins. We have found some
usability issues with manipulating large tables in the wiki format. Some plugin to make editing large tables easier in the wiki format would be useful for us. Also, editing long pages becomes an issue if you cannot put comments throughout the page. We validate our procedures by having members of the group who are unfamiliar with the system read through the procedure. The reader should be able to comment on but not edit parts of the page. We have worked around or found plugins on the Trac Hacks page (http://www.trac-hacks.org) to resolve these issues.
The final request is for some level of certification from distribution maintainers to certify third-party packages. Many of the third-party packages we have applied to this process to do not support all distribution configurations.
A certification from distribution maintainers validating that software distributed by third-party vendors have packaged their software appropriately for the distribution would help customers determine the cost of support.
This is by no means a complete solution for organizations to build customized critical applications.
INDEPTH
There are still gaps in the system that we have to work around using scripts or manual intervention. We constantly are working on the process and tools to make them better, so any suggestions to improve it are welcome. However, these tools do fill the need to support customization of CRITICAL APPLICATIONS FOR (0# AT %-3,
Acknowledgement
The research was performed using
%-3, A NATIONAL SCIENTIFIC USER FACILITY SPONSORED BY THE $EPARTMENT OF %NERGYS /FFICE OF "IOLOGICAL AND %NVIRONMENTAL Research and located at Pacific
Northwest National Laboratory.Q
David Brown is a high-performance computing system administrator with a B.S. in Computer Science from Washington State University. He has worked at the Pacific Northwest National Laboratory (PNNL) in the Environmental and Molecular Sciences Laboratory (EMSL) since January 2007. He also is a Fedora Package Maintainer and supports several scientific and administrative packages that are used in HPC environments. He has experience in high-performance filesystems (Lustre) and cloud technology (OpenStack).
Send comments or feedback via http://www.linuxjournal.com/contact or to [email protected].