Open Stack

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
>>
> 
>