Open Stack

On 06/10/2013 05:15 PM, Robert Collins wrote:
> On 11 June 2013 08:32, Mark McLoughlin <markmc at redhat.com> wrote:
>> Hi
>>
>> Having metadata in each project describing its non-python requirements
>> is definitely a good thing. As is having some way of turning that
>> metadata into a "check these deps are satisfied" or "install these deps"
>> disto-specific command.
>>
>> I think it's great you've kicked this off - it's a great starting point
>> for finding a workable solution. I'm actually kinda surprised we never
>> had e.g. tools/install-deps.sh type scripts long ago.
>
> :) We do in devstack, but eesh thats harsh on a workstation.
>
>> The first thing I notice is that the list of requirements is a list of
>> debian packages and versions. Obviously, anyone who doesn't use a debian
>> distro wouldn't like to have to cater first for debian and then for
>> their preferred distro when adding a dep. I think the project has gone
>> beyond having a single first class distro, so I think this needs
>> improving.
>>
>> (I've an obvious bias here - but the concern honestly does go beyond
>> just me)
>
> I agree; here are my thoughts on some approaches for this.
>
> A - have a golden list, and describe everything in those terms. When
> platforms (debian/ubuntu/fedora/rhel) etc disagree, whoever doesn't
> match the golden list has to translate. We can build and ship a global
> translation list, as well as per-project translation lists.
>
> B - have platform specific rules in other-requirements.txt. e.g.
> linux-image-generic [platform:ubuntu]
> linux-image [platform:debian]
> kernel [platform:rpm]
>
> In diskimage-builder we took approach A and it's working well - we
> support Fedora easily using it.
>
> For bindep I've design in *both* A and B from the get-go. B is working
> right now, but A is missing a way to describe additional mappings
> without changing the bindep code (e.g. embedding extra metadata in
> other-requirements.txt, or a new file, or $whatever).

I'd take a look at what's in devstack today, it gets kind of complicated 
when you start doing ubuntu, debian, suse, fedora, etc. The data is 
mostly there about the larger set, broken out by service. There are some 
exceptions where you only need certain packages for certain features 
(for instance libvirt just became optional in devstack so the xen folk 
don't have to install it when not needed).

Honestly, would be totally awesome if that code could live somewhere 
other than devstack, way too much effort is spent on keeping that up as 
every distro spin comes out.

	-Sean

-- 
Sean Dague
http://dague.net