Open Stack

Is that common list going to be synced with the subcomponents sometime
soon?

I was thinking about having update.py insert a tool that can generate a
rpm spec file (to start).

Then when that 'tool' is launched in from say the subcomponents tools/ dir
it would create a barebones rpm package & spec file. People can then
modify that barebones one as they like. Having the good set of
dependencies right next to that tool will help.

On 8/9/12 10:53 AM, "Joshua Harlow" <harlowja at yahoo-inc.com> wrote:

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