incubator-cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Wido den Hollander <w...@widodh.nl>
Subject Re: [DISCUSS] Packaging in 4.1
Date Mon, 04 Feb 2013 17:04:51 GMT


On 02/04/2013 06:03 PM, Hugo Trippaers wrote:
> 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.
>

Ran into the same! Had the idea to put them indeed in the management 
server package.

The python libs should indeed go into common.

Wido

> 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