Open Stack

Thanks.

I'll see what I can do to help out here :-)

I'd like to even provide sample rpm spec files and debian package building
using such lists.

That'd be nice for everyone (even if somewhat controversial).

On 8/8/12 10:49 PM, "Monty Taylor" <mordred at inaugust.com> wrote:

>Hi hi!
>
>On 08/08/2012 09:41 PM, Joshua Harlow wrote:
>> Although just a few questions.
>> 
>> What is the format of these files (why is a custom format used, yaml
>>seems
>> nice?).
>
>It's a python requirements list format as consumed by pip and used in
>tools/pip-requires
>
>> How do we connect the format to what a component needs, since this seems
>> to be the 'superlist'?
>
>The idea is that the projects will sync their pip requirements to this.
>
>> Is it useful to also connect this to rpms/deb names (maybe not fully
>> specified versions?)
>
>Sure! The repo is there and gerrit managed, so if there is interest in
>maintaining more meta-packaging info in there, awesome!
>
>> When building a package (say a rpm), the above would be pretty useful to
>> include in the spec file. IE say I want to build a openstack-nova spec
>> file, I need to know the versions and the distribution names for the pip
>> packages listed there and what pip packages are needed for this package.
>> Is this requirements repo the right place for that info? What about
>>system
>> level packages like libvirt? Or since nova executes many shell commands
>> (iptables...) those versions seem important to list also.
>
>The main thing trying to be solved right now is just to get pip versions
>aligned. I agree, other things also need alignment, but that's a WAY
>larger problem, and fraught with peril. As much as I'd love to solve it,
>this is purely trying to express the set of python pip requirements that
>are actually needed at the moment. If we can get those in line, the
>distro package libs should potentially be the next stop...
>
>
>> On 8/8/12 6:34 PM, "Joshua Harlow" <harlowja at yahoo-inc.com> wrote:
>> 
>>> Yippie, this will help for others that are building there own packages.
>>>
>>> Thx!
>>>
>>> On 8/8/12 6:08 AM, "Monty Taylor" <mordred at inaugust.com> wrote:
>>>
>>>> Hey all!
>>>>
>>>> One of the goals from the last ODS was to have a common set of package
>>>> requirements across all of the projects. After talking through a bunch
>>>> of different options, the one that sucked the least was to have a
>>>>global
>>>> list that can be copied/synced from. To that end, we've gone through
>>>>the
>>>> list of everything that all of the packages declare that they use,
>>>>have
>>>> correlated that with what devstack _actually_ installs (it's not what
>>>> you think in all cases) and made the initial list from that. It has
>>>>been
>>>> pushed to the openstack/requirements project in Gerrit and the
>>>> openstack-common core team has core-approval access.
>>>>
>>>> What does this mean effectively today? Nothing.
>>>>
>>>> However, there is now a global list, and a utility with that global
>>>>list
>>>> to update the list of things in your project to match the versions
>>>>found
>>>> in the global list without adding new dependencies (python-swiftclient
>>>> probably doesn't need django after all) It works pretty much the same
>>>>as
>>>> the openstack-common update.py script - but since it's a list, you
>>>>don't
>>>> _really_ have to use that script for any reason if you don't want to.
>>>>
>>>> Adding new dependency libraries to the project should be done via
>>>>first
>>>> getting a patch landed to the openstack/requirements project adding
>>>>the
>>>> library- then landing the patch in the project. That will allow the
>>>> folks who focus on packaging and whatnot to look for problematic
>>>> libraries (like M2Cryto wound up being) or problematic versions
>>>>(glance
>>>> thinks it wants 0.2.3 of anyjson right now, but a newer version is in
>>>> ubuntu)
>>>>
>>>> Eventually, depending on how we feel about how this all works, there
>>>>has
>>>> been discussion about adding a test to milestone-proposed branches to
>>>> ensure that package versions in projects are in sync with the global
>>>> list. That allows people to drift some during a dev cycle, or to take
>>>>a
>>>> little bit to update to a newer version if it's a bit ugly.
>>>>
>>>> Have fun!
>>>> Monty
>>>>
>>>>
>>>> _______________________________________________
>>>> OpenStack-dev mailing list
>>>> OpenStack-dev at lists.openstack.org
>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>> 
>>