incubator-cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Hugo Trippaers <HTrippa...@schubergphilis.com>
Subject RE: [DISCUSS] Packaging in 4.1
Date Wed, 06 Feb 2013 13:03:15 GMT
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.

Cheers,

Hugo

> -----Original Message-----
> From: Pradeep Soundararajan [mailto:pradeep.soundararajan@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:wido@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 <wido@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: rohityadav89@gmail.com [mailto:rohityadav89@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 <david@gnsa.us> wrote:
> >>>
> >>>> On Sun, Feb 3, 2013 at 3:58 PM, Rohit Yadav <bhaisaab@apache.org>
> wrote:
> >>>>
> >>>>> On Sun, Feb 3, 2013 at 3:07 PM, David Nalley <david@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
> >>>>
> >>>
> >>
> >
> >

Mime
View raw message