On 02/06/2013 02:03 PM, Hugo Trippaers wrote:
Hey Pradeep,
I'm planning on doing some upgrade tests at the moment. All the packages will
list the packages that will be obsoleted by the new install. For users the
process should be transparent, but we will create any symlinks if that makes
life easier. For installation we should be covered by that and making it clear
in the documentation/release notes.
I think it's good to have the name of the product in the name of that package
and the installed aritifacts, but we should make it clear for end-users that
the name has changes between version 4.0 and 4.1.
I am setting up an environment to do the upgrade tests at the moment and we are
in touch with Prassana to align with his work on automated testing as well. So
for now I would like to keep the name as cloudstack unless testing proves that
this is infeasible.
+1
I'll also be setting up a couple of Ubuntu systems to test the 4.0 to
4.1 upgrade.
Wido
Cheers,
Hugo
-----Original Message-----
From: Pradeep Soundararajan [mailto:pradeep.soundarara...@citrix.com]
Sent: Wednesday, February 06, 2013 11:00 AM
To: cloudstack-dev@incubator.apache.org
Subject: RE: [DISCUSS] Packaging in 4.1
Importance: High
Thanks Hugo, Wido and Noa for bringing this to some closure :)
I am able to package rpm using "packaging/centos63/package.sh" after some
modification in the package.sh script since cloud.spec is looking for
'cloudstack' Name.
------------------------------------------------------------------------
-mkdir -p $RPMDIR/SOURCES/cloud-$VERSION
+mkdir -p $RPMDIR/SOURCES/cloudstack-$VERSION
-(cd ../../; tar -c --exclude .git --exclude dist . | tar -C
$RPMDIR/SOURCES/cloud-$VERSION -x ) -(cd $RPMDIR/SOURCES/; tar -czf
cloud-$VERSION.tgz cloud-$VERSION)
+(cd ../../; tar -c --exclude .git --exclude dist . | tar -C
+$RPMDIR/SOURCES/cloudstack-$VERSION -x ) (cd $RPMDIR/SOURCES/; tar
-czf
+cloudstack-$VERSION.tgz cloudstack-$VERSION)
-------------------------------------------------------------------------
Packaging went fine after the above modification but I have observed some
issues while installing the package. I believe you have changed the
installation path from */cloud/* to */cloudstack/* and also observed you
have changed all the rpm names from cloud* to cloudstack*. If that is a
situation then I feel we cannot upgrade from 4.0 since they were pointing to
different rpm names and they were loaded in a different location. I feel, this
would raise lot of compatibility issues here and there.
Noticed you have changed cloud-client to cloudstack-management. I feel, we
have to modify install.sh script accordingly in order to satisfy all the changed
conditions.
Time being shall we keep all the internals intact with the same name cloud
instead of cloudstack?
Please let us know if any one see any other issues.
Thanks,
Pradeep S
-----Original Message-----
From: Wido den Hollander [mailto:w...@widodh.nl]
Sent: Wednesday, February 06, 2013 1:33 AM
To: cloudstack-dev@incubator.apache.org
Subject: Re: [DISCUSS] Packaging in 4.1
On 02/05/2013 06:33 PM, Noa Resare wrote:
I built the latest from the packaging branch. I think it is shaping up
nicely. Some thoughts:
How would you feel with postponing the config directory changes until 4.2?
While I agree conceptually that they are an improvement, waiting with
them would keep the diff size down, simplifying merge and the focus of
stabilization for 4.1
Yes, I stumbled upon the same while merging master into packaging.
It doesn't hurt anybody to keep it in the current shape, the end result will be
the same.
Wido
/n
On Mon, Feb 4, 2013 at 11:33 AM, Wido den Hollander <w...@widodh.nl>
wrote:
On 02/04/2013 07:12 AM, Sudha Ponnaganti wrote:
Wanted to check when would this be implemented?? Several QA folks
depend on the packages and need this working.
We have been still building using waf but today that is also not
working as some references are removed.
Is it possible to accelerate this process or leave old way of
packaging in place till you are done with the new changes
I fully understand. As I told David, I think the DEB work is about
one day of work, but then again, there is something like $dayjob.
What might be even tougher is to get the RPM and DEB packages fully
synced. cloudstack-common for example should contain exactly the same
files in the RPM and DEB version, so Hugo and I will have to keep in touch.
I really want to have the DEB packaging working this week, period.
Wido
Thanks
/sudha
-----Original Message-----
From: rohityada...@gmail.com [mailto:rohityada...@gmail.com**] On
Behalf Of Rohit Yadav
Sent: Sunday, February 03, 2013 5:14 PM
To:
cloudstack-dev@incubator.**apache.org<cloudstack-
dev@incubator.apach
e.org>
Subject: Re: [DISCUSS] Packaging in 4.1
On Mon, Feb 4, 2013 at 4:41 AM, David Nalley <da...@gnsa.us> wrote:
On Sun, Feb 3, 2013 at 3:58 PM, Rohit Yadav <bhais...@apache.org>
wrote:
On Sun, Feb 3, 2013 at 3:07 PM, David Nalley <da...@gnsa.us> wrote:
...
So EL6 has pygments 1.1.1 - you require 1.5, so in some ways it's
worth than clint (clint is in EPEL, but no new version of
pygments in
EPEL/CentOS-Extras/CentOS-**Plus)
I want people to use pip to install the cli because it's the
easiest and because rpm/deb packages may have dependency issues
like you mentioned => may not work on all distros, what we can do
is when people install cloudstack-cli rpm or deb, it runs a script
that installs pip (if unavailable) and cloudmonkey. cloudmonkey is
pure python, so the rpm/deb can also ship bundling src tarballs of
cloudmonkey and its dependencies and install from it. Advise best
way of doing this?
I guess we won't be installing the CLI via RPMs at least for EL6.
You are assuming that they would have internet access when
installing
- which is not a valid assumption.
Honestly, the above idea makes me blanch. A package that reports as
installed, and may or may not have installed - may have installed a
compromised package (see rubygems.org compromise recently,
kernel.org, and a number of other site compromises.), or might have
installed packages I didn't know about is a Bad Idea (tm) The
sysadmin doesn't know you are installing some of the dependencies,
there is no record of those packages in the package manager, and
there might potentially be conflicts with system packages, a
security vulnerability in one of those dependencies wouldn't be caught
on audit, etc etc.
/facepalm\, it's just a problem of packaging. The package can
include cli or any other artifact's dependencies, so in case of cli,
you bundle both pygments and prettytable in cli's rpm/deb. AFAIK all
of them are pure python so easily installable. The cool people can use
pip to install.
And I really don't intend for this to sound like a rant, but the
one of the important benefits behind using packages and a package
manager is that a sysadmin needs (and often is required to have by
government
regulations) a single source of truth about the software installed
on a machine.
No, it's not a rant, I understand.
Developers love things like Maven central, pypi, CPAN, and
rubygems,
and for good reason, they are fast, flexible, and make their life
easy. To a sysadmin managing machines in production, they are
anathema; they make system state difficult or impossible to
determine, they make audits painful.
I just assumed the sysadmin who would install CloudStack, cli and
whatnot won't be stupid, at the same time I want his life to be less
miserable.
In addition they make troubleshooting
incredibly difficult. Do I have $foo installed - which version? Are
there multiple copies of $foo installed on the system? Which one is
actually being called/loaded?
Alright, but I'm talking only about the cli, since most users,
admins included, would want it to run on their machines, the
installation should be easiest, that's why I said they can use pip,
so it works on their windows, osx, linux, bsd boxes and that's why
it's pure python (written that way).
Regards.
--David
