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:w...@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 <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 > >>>> > >>> > >> > > > >
