>
> 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.
>
> 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.
>
> 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?
>
> 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? Yes we can do it in a better way. If it's exact problem
you mentioned,
I can file a bug for this
>
> 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.
Thank you.
>
> 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
