<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Jun 10, 2013 at 5:15 PM, Robert Collins <span dir="ltr"><<a href="mailto:robertc@robertcollins.net" target="_blank">robertc@robertcollins.net</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 11 June 2013 08:32, Mark McLoughlin <<a href="mailto:markmc@redhat.com">markmc@redhat.com</a>> wrote:<br>
> Hi<br>
<div class="im">><br>
> Having metadata in each project describing its non-python requirements<br>
> is definitely a good thing. As is having some way of turning that<br>
> metadata into a "check these deps are satisfied" or "install these deps"<br>
> disto-specific command.<br>
><br>
> I think it's great you've kicked this off - it's a great starting point<br>
> for finding a workable solution. I'm actually kinda surprised we never<br>
> had e.g. tools/install-deps.sh type scripts long ago.<br>
<br>
</div>:) We do in devstack, but eesh thats harsh on a workstation.<br>
<div class="im"><br>
> The first thing I notice is that the list of requirements is a list of<br>
> debian packages and versions. Obviously, anyone who doesn't use a debian<br>
> distro wouldn't like to have to cater first for debian and then for<br>
> their preferred distro when adding a dep. I think the project has gone<br>
> beyond having a single first class distro, so I think this needs<br>
> improving.<br>
><br>
> (I've an obvious bias here - but the concern honestly does go beyond<br>
> just me)<br>
<br>
</div>I agree; here are my thoughts on some approaches for this.<br>
<br>
A - have a golden list, and describe everything in those terms. When<br>
platforms (debian/ubuntu/fedora/rhel) etc disagree, whoever doesn't<br>
match the golden list has to translate. We can build and ship a global<br>
translation list, as well as per-project translation lists.<br>
<br>
B - have platform specific rules in other-requirements.txt. e.g.<br>
linux-image-generic [platform:ubuntu]<br>
linux-image [platform:debian]<br>
kernel [platform:rpm]<br>
<br>
In diskimage-builder we took approach A and it's working well - we<br>
support Fedora easily using it.<br></blockquote><div><br></div><div style>Are we sure there is always a 1:1 mapping? It seems like we had at least one case where a dependency was in a single package on one platform but in split across multiple packages on another. I can't think of that case, though, so maybe I'm imagining things.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
For bindep I've design in *both* A and B from the get-go. B is working<br>
right now, but A is missing a way to describe additional mappings<br>
without changing the bindep code (e.g. embedding extra metadata in<br>
other-requirements.txt, or a new file, or $whatever).<br>
<div class="im"><br>
> What might work is if we built in a dependence on the<br>
> openstack/requirements repo. Like for python deps, we'd use that repo to<br>
> describe the unified set of dependencies for all of openstack and<br>
> individual projects would specify a subset of those dependencies.<br>
<br>
</div>I think thats a good idea in it's own right, but orthogonal to the<br>
mapping problem? How is it relevant to the mapping problem - what have<br>
I missed?<br></blockquote><div><br></div><div style>Keeping a single golden list with the right version numbers consistent across all of the projects.</div><div style><br></div><div style>Could we release a package that just contains the list as a data file that bindep can use? That would keep the dependency list for OpenStack separate from bindep, making the tool more likely to be reusable and avoiding the copying problem.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im"><br>
> We could also use openstack/requirements to maintain a mapping of distro<br>
> agnostic requirement name/version to distro specific package<br>
> name/version. Maybe bindep would look use the distro mapping table to<br>
> apply other-requirements.txt or maybe we'd have a utility to copy the<br>
> appropriate parts of the mapping table into other-requirements.txt.<br>
><br>
> Bikeshed - other-requirements could be system-requirements.txt or<br>
> distro-requirements.txt ?<br>
<br>
</div>Certainly, I have no strong attachments here. Blue is fine :). What I<br>
will say is that if 'distro agnostic' means 'pick a name *no* distro<br>
is using if *any distro deviates from another distro*', then that way<br>
lies a lot of pain and burden. I'd *much* rather say 'distro agnostic<br>
means Debian' or 'distro agnostic means Ubuntu', not to "bless" such a<br>
distro as far as OpenStack is concerned, but to just give us a stable<br>
and comprehensive list of packages as a starting point.<br></blockquote><div><br></div><div style>I assume we'll want to pin versions of these packages, just as we do with the Python requirements. If that's the case, we need a mapping list for each distro anyway. The golden list would map some standard name to the distro package with a version. The dependency lists in a given project would include the "generic" name without the version.</div>
<div style><br></div><div style>Doug</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im"><br>
> Anyway, just some ideas ...<br>
><br>
>> I think this could live very happily as an oslo component, like pbr<br>
>> does. It provides a small CLI, and a Python library which can be used<br>
>> from things like pbr or CI scripts, if they want to layer on it.<br>
><br>
> It could come under oslo, but I'd like to see it gain a good deal of<br>
> traction first. Obviously adding other-requirements.txt to projects<br>
> would be a good first step. Using it in devstack would be next?<br>
<br>
</div>Sure. If folk are happy using non-integrated things in (integrated<br>
things|the gate), then I'll be delighted to move this onto stackforge<br>
and start submitting patches here and there.<br>
<div class="im"><br>
> Basically, I think this could move to stackforge and we could see how it<br>
> evolves before moving it to oslo.<br>
><br>
> Why wait?<br>
><br>
> Well, if we include it in oslo, it will imply some interface stability<br>
> guarantees that will make it harder to evolve the idea.<br>
><br>
> Also, oslo-core is already finding the review workload pretty hard to<br>
> keep on top of ... so I'm reluctant to pull in another project which is<br>
> very new and isn't in use anywhere yet. We have lots of work with our<br>
> core focus on the project's copy-and-paste technical debt.<br>
><br>
> So, again - I'm up for including it oslo at some point, but let's get it<br>
> in use in a bunch of places first.<br>
<br>
</div>Cool, sure thing.<br>
<div class="im HOEnZb"><br>
-Rob<br>
--<br>
Robert Collins <<a href="mailto:rbtcollins@hp.com">rbtcollins@hp.com</a>><br>
Distinguished Technologist<br>
HP Cloud Services<br>
<br>
</div><div class="HOEnZb"><div class="h5">_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br></div></div>