Hi,
Managed to build packages for SUSE (SLE at this time, openSUSE to follow
in the next week or so). The spec file in the source tree was a good
starting point, thanks. While I was working on this a few questions
arose and I am hoping someone can shed some light on these.
1.) Why is the client-ui creating a backup tarball of
/usr/share/cloud/management/webapps/client?
- are users expected to make UI customizations in this location?
- if users can modify the UI shouldn't there be a plugin architecture or
set of APIs, rather than letting people mess with files in a "system
owned" location? Often trying to protect user modifications like this
backfires.
2.) What is the significance of removing the cache prior to installing
the client package (rm -rf %{_localstatedir}/cache/%{name})?
- adding or removing files in %pre/%post is bad form and may have ill
side effects as these files are hidden from the packaging system.
- how would an existing cache from a previously installed package break
the package being currently installed?
3.) The client package modifies /etc/security/limits.conf. However,
limits.conf is only used by pam_limits and intended mostly for
interactive logins. As the cloud user appears to be used to run a daemon
I am wondering why the daemon is not setting it's own limits using
setrlimit()? I am not a Java expert but would think there should be
access to this functionality somehow from Java. At the very least the
package should not modify the distribution provided file, but place a
custom file in /etc/security/limits.d/
(http://linux.die.net/man/8/pam_limits).
4.) Initscripts are part of the build/install process in waf. While this
is a nice convenience for users that build CloudStack from sources on a
given system it imposes some unpleasant requirements when building a
package in a build system such as OBS
(http://www.open-build-service.org/). For example one has to pull in the
DistroX-release package.
- it would be nice to collect distribution dependent files in 1 central
directory
- have an install option that allows packagers to not install these
through the waf build and therefore basically disable the distribution
check all together
- with systemd there is a good chance that a number of distributions
will converge on the same init system (fedora and openSUSE already use
systemd), thus isolating the distribution dependence into one area makes
a lot of sense as this will hopefully slowly fade away. With init
scripts out of the waf install/build, packagers can then get the stuff
they need and copy it into the location for their distro as needed. The
waf install step could still have a --systemd or --fedoraInitInstall
option to put distro specific files into the proper location for those
people that build cloud stack from scratch on the target machine.
The project for this in the openSUSE Build service
(https://build.opensuse.org/), also OBS, is
Virtualization:Cloud:CloudStack:Testing. Hopefully I'll have time in the
next week or so to get openSUSE packages building as well and then set
up a small test cloud. Once it all works packages will move from
:Testing to Virtualization:Cloud:CloudStack and :Testing will be used to
build beta releases etc. Also anyone interested in helping out with the
OBS project you are more than welcome to pitch in.
Thanks in advance for any answers/comments
Robert
--
Robert Schweikert MAY THE SOURCE BE WITH YOU
SUSE-IBM Software Integration Center LINUX
Tech Lead
rjsch...@suse.com
rschw...@ca.ibm.com
781-464-8147
