[openstack-dev] [packaging] Adding packaging as an OpenStack project

Allison Randal allison at lohutok.net
Wed Jun 3 23:30:56 UTC 2015

On 06/03/2015 03:31 PM, Haïkel wrote:
> 2015-06-03 23:41 GMT+02:00 Allison Randal <allison at lohutok.net>:
> I have to disagree on that point, integration with underlying OS and low-level
> services is important. If that integration doesn't exists, it's
> off-loaded to the
> operators. So downstream packages bring more value than pip deployment,
> as it will pull dependencies (not just things from PyPI), working combination
> with underlying OS components etc.
> Packages could be used in a variety of different configurations, even ones we
> didn't expect. Any sensitive scenario that we can't support is likely
> to be a packaging
> bug for me.
> In some cases, it makes sense for fine-tuning, but generally, you just want to
> get things work and tweak your configuration.

Oh, yeah, I'm making an implicit distinction here that should be
explicit. There are two different types of dependencies for an OpenStack

- system dependencies that have to be installed on the same machine as
the service, like a Python library used within the Nova code

- service dependencies like a database, message queue, or other
OpenStack service, which might be running on the same machine or might
be running on a completely different machine

System dependencies should be installed by the distro packaging, and
you're right, distro packaging has an advantage over pip for installing
non-Python system dependencies. (Though, typically with pip you're using
it over the top of some other system config management tool, so the
disadvantage is easy enough to iron out.)

Service dependencies is where the problems lie, because neither pip nor
distro packaging were designed as orchestration tools.

>> Both pip and distro packaging should be consumable by any set of config
>> management/orchestration tools, which means just install the software
>> with minimal configuration.
> +1
> As a matter of fact, I prefer that packages to be as agnostic as
> possible about the
> deployment and let that work to the orchestration tool.

I'm a big fan of using the right tool for the job.


More information about the OpenStack-dev mailing list