Robert:
I have filed couple of bugs to track them. I work with our build
engineer on them and we will publish to maillist if any progress made, thanks.
> >
> >>
> >> 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.
I remember of it. Some customer was complaining their changes to UI were
flushed out after upgrading CloudStack, then we added this hack.
Agree it should go away as starting CS3.0 we have been planning pluggable UI
framework.
Having filed a bug for this
http://bugs.cloudstack.org/browse/CS-14666?focusedCommentId=133873#comment-133873
>
> >
> >
> >>
> >> 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.
http://bugs.cloudstack.org/browse/CS-14667?focusedCommentId=133874#comment-133874
>
> >
> >
> >>
> >> 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
http://bugs.cloudstack.org/browse/CS-14668?focusedCommentId=133875#comment-133875
> >
> >
> >>
> >> 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.
http://bugs.cloudstack.org/browse/CS-14669?focusedCommentId=133876#comment-133876
>
> > 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.
Yes. getting rid of waf is our final goal, if we can work around this then it's
not worth spending efforts on this.
>
> Robert
>
> --
> Robert Schweikert MAY THE SOURCE BE WITH YOU
> SUSE-IBM Software Integration Center LINUX
> Tech Lead
> [email protected]
> [email protected]
> 781-464-8147
