On 04/27/2012 02:39 PM, Frank Zhang wrote:
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.
First I would apologize there are some unreasonable stuff in our build due to
historic reason.
No problem, the many eyeballs you get with open sourcing CloudStack will
find and help fix all this stuff ;)
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.
Could you point me which tarball you mentioned? I don't think it's for any
purpose,
it may by just a mistake.
I pulled 3.0.1 from github for this build. The relevant code in the spec
file is as follows:
%pre client-ui
if [ -d %{_datadir}/%{name}/management/webapps/client/ ]; then
pushd /tmp &>/dev/null
file=cloud-ui-backup-%(date +%%F).tar.bz2
cp -r %{_datadir}/%{name}/management/webapps/client/ .
tar cjf "$file" client/
rm -rf client/
mkdir -p /usr/share/cloud/ui-backup/
mv "$file" /usr/share/cloud/ui-backup/
popd &>/dev/null
fi
IMHO this should just go away.
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?
We used to encounter a bug that CloudStack UI went mad because these cache.
What's elegant way to solve such sort of problem?
You could add a file in the cache directory and the UI could read this
at the beginning. If there is a version mismatch the UI should clear the
cache. I am under the assumption that the UI issue only appears when the
UI is upgraded.
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).
This should be a bug. yes we should do it in our cloud-setup-management script
instead of hacking limit.conf. I will file a bug for this. Thanks
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.
Do you mean waf will automatically install dependencies packages during RPM
build if
try-build was failed?
No, if you build on a system that only contains the packages specified
as "BuildRequires" plus dependencies, you will notice that the builds
basically fail because the /etc/*-release files that the waf script is
looking for does not exist. Therefore one has to add the *-release
package as a BuildRequires to the spec file.
However, the build system itself should not be dependent on a given
release, rather it should only spell out it's dependencies. Therefore,
any system that provides the required Java environment can run CloudStack.
My pull request (https://github.com/CloudStack/CloudStack/pull/8)
follows the waf setup for SUSE, but we should really not setup the build
this way.
Yes we can do it in a better way. If it's exact problem you mentioned,
I can file a bug for this
Cool thanks.
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.
Thank Robert for working on this. By chance I used to play OBS for a short time,
It's a nice tool. I like the feature that triggers a new build for a package
when one of its dependencies
updated. Please feel free to input your advices making CloudStack elegantly
build in OBS, I will
work with our dedicated build engineer to make that happen. Patches are always
welcome as well.
I can take a shot at puling the distribution dependent stuff into a
central location, if that's OK and submit a pull request. However, if
you guys are moving to Ant from WAF this might not be worth the effort
at this point.
Robert
--
Robert Schweikert MAY THE SOURCE BE WITH YOU
SUSE-IBM Software Integration Center LINUX
Tech Lead
[email protected]
[email protected]
781-464-8147
