cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Henri Gomez <henri.go...@gmail.com>
Subject Re: [DISCUSS] Packaging in 4.1
Date Mon, 04 Feb 2013 20:22:04 GMT
Nice to see native packages for Cloudstack :

https://github.com/noaresare/incubator-cloudstack/tree/master/packaging

CentOS 6.3 and Debian.


Did there is plan to add Fedora, openSUSE, SLES or will it be done by
these distributions packagers ?

2013/2/4 Wido den Hollander <wido@widodh.nl>:
> Hey,
>
> I just pushed everything to the Github repo[0]:
>
>  dpkg-genchanges -b >../cloudstack_4.1.0-0.0.snapshot+2_amd64.changes
> dpkg-genchanges: binary-only upload - not including any source code
>  dpkg-source --after-build cloudstack
> dpkg-buildpackage: binary only upload (no source included)
>
> wido@wido-desktop:~/repos/cloudstack$ ls -l ../*.deb
> -rw-r--r-- 1 wido wido   176298 Feb  4 21:14
> ../cloudstack-agent_4.1.0-0.0.snapshot+2_all.deb
> -rw-r--r-- 1 wido wido     2382 Feb  4 21:14
> ../cloudstack-awsapi_4.1.0-0.0.snapshot+2_all.deb
> -rw-r--r-- 1 wido wido     2302 Feb  4 21:14
> ../cloudstack-cli_4.1.0-0.0.snapshot+2_all.deb
> -rw-r--r-- 1 wido wido 24629096 Feb  4 21:14
> ../cloudstack-common_4.1.0-0.0.snapshot+2_all.deb
> -rw-r--r-- 1 wido wido     2280 Feb  4 21:14
> ../cloudstack-docs_4.1.0-0.0.snapshot+2_all.deb
> -rw-r--r-- 1 wido wido 85635152 Feb  4 21:14
> ../cloudstack-management_4.1.0-0.0.snapshot+2_all.deb
> -rw-r--r-- 1 wido wido    91854 Feb  4 21:14
> ../cloudstack-usage_4.1.0-0.0.snapshot+2_all.deb
> wido@wido-desktop:~/repos/cloudstack$
>
> I can't guarantee that they work for 100%, but it should be a start!
>
> Wido
>
> [0]: https://github.com/noaresare/incubator-cloudstack/commits/packaging
>
>
> On 02/04/2013 06:04 PM, Wido den Hollander wrote:
>>
>>
>>
>> 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