← Back to team overview

openstack team mailing list archive

Re: Proposal for new devstack (v2?)

 

Although yes package managers do know how to pick up a version, they sometimes do this automatically with a newer version (if u leave out the version).

This then brings back the problem of how exactly do people with other distributions know what version is going to work if the package manager selects the versions. Having it in the file at least gives people the knowledge that the given version was used by developers for creating a given openstack release and should be stable if they ever want to install that release in the future.

Distromatch might make sense, but it still doesn't resolve the version issue (I am not an expert on distromatch).

Right now this is (but hopefully won't be in the future) a big pain when trying to get openstack running (or even developed on) in another distribution. How do we know which version developers have been using, well we go to ubuntu 11, check that version and hope that the version is available in the other distribution (this is problematic since if its not and say its a python version, then u have to pray that the package will have all the necessary functions/classes - since python won't check until called, thanks to duck typing). So even though yes there are a lot of versions specified and a lot of packages specified it does seem like this is what is needed for a large project like openstack.

I've seen ubuntu switch out versions sometimes though (ie blah-ubuntu1 to blah-ubuntu2), so I am not sure about 1 version, 1 active version maybe, but for a large project should the openstack community just expect that blah-ubuntu2 will work for everyone (hopefully nothing major changed between 1 and 2). Since everyone at openstack was say developing with blah-ubuntu1, changing to blah-ubuntu2 shouldn't happen unless its really needed since this may cause regressions or other problems.

-Josh

On 1/24/12 2:57 AM, "Bernhard M. Wiedemann" <ubuntubmw@xxxxxxxx> wrote:

On 01/17/2012 08:20 PM, Joshua Harlow wrote:
> My goals were/are/(may continue to be, haha) the following:
>
>
>   1.  Add in enough abstraction so that you can look at how each component is installed/uninstalled/started/stopped by looking at a single file (maybe 2 files)
>   2.  Have the ability to start/stop in different manners (not always screen)
>   3.  Have the ability to have pkg/pip installation (and definition separate from the main code, already starting to be done), in more than 1 distro.
>      *   This allows others to easily know what versions of packages work for a given openstack release for more than one distro (yes that's right, more than ubuntu)
>   4.  Increase the level of documentation (probably not going to be in the end, inline like what is in devstack, since that just doesn't seem maintainable in the long-term)
>      *   This may mean having documentation created similar to nova, glance, as a separate documentation document/page....
>
> Still be simple "enough" to run and use so that the non-python dev can install from trunk without having to understand what is going on.
>
> -Josh

I was looking into how easy it would be to support openSUSE / SLES in
devstack v2 and saw that there are currently 17 json files containing
package names (with 293 versions) for ubuntu-oneiric and rhel-6.
Shouldn't there be some better way than to list all this redundant
information there, which makes it hard to maintain/extend?

E.g. the distro's package manager already knows about dependencies and
usually has just one version of a package for a given distribution anyway.
And there was even one project about mapping package-names of one Linux
distribution to another:
http://enricozini.org/2011/debian/distromatch/
So it should be possible to build upon it, and just list packages once.

Ciao
Bernhard M.

_______________________________________________
Mailing list: https://launchpad.net/~openstack
Post to     : openstack@xxxxxxxxxxxxxxxxxxx
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp


References