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 Mon, 04 Feb 2013 17:03:22 GMT
Hey guys,

What do we do with the database scripts? They are needed by cloud(stack)-setup-management.
I'm thinking about adding them to the management server for now together with the scripts.
There are some python modules (cloudutils and cloud_utils) which are needed by both setup
tools in management and agent to I thought to put those in common.

Cheers,

Hugo

> -----Original Message-----
> From: Wido den Hollander [mailto:wido@widodh.nl]
> Sent: Monday, February 04, 2013 2:48 PM
> To: cloudstack-dev@incubator.apache.org
> Subject: Re: [DISCUSS] Packaging in 4.1
> 
> On 02/04/2013 02:39 PM, Noa Resare wrote:
> > I'm on the last leg of my trip home from FOSDEM right now, I hope to
> > be able to put in some work on deb packages in the next few days.
> >
> 
> I still have some pending changes on my laptop which I forgot to push to the
> Github repo[0].
> 
> I'll push them in a couple of hours, they contain a lot of what we discussed
> regarding the DEB packaging.
> 
> Wido
> 
> [0]: https://github.com/noaresare/incubator-cloudstack
> 
> > /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