openstack team mailing list archive

[Monty Taylor <mordred@xxxxxxxxxxxx>]

Totally in terms of the decisions and re-visiting it. I think you're
totally right, of course, in terms of that.

Here's the problem in a nutshell... I can continue to cut packages ...
but we don't have anybody dedicated to maintaining the contents of the
packages that we create post-release. (we only just now even got
branches for maintenance of the branches post-release, and those are
really mainly a place for the distros to coordinate)

As it winds up now, the way we're releasing packages to the PPA, because
we have to backport upwards of 20 packages, we have a mini linux
distribution. That's fine - and the world knows how to manage linux
distributions - but it creates the implication that we are going to
continue to maintain the release once it's made. Security fixes would be
the big thing ... when a security bug hits diablo, who is going to
manage getting it in to a package release that we as the project are
releasing? What about security bugs in the 20 backported packages?

Now - don't get me wrong. I think it's actually an excellent idea to
publish packages in the way that we have been... in fact, I set up the
original version of it in the first place, and I've been a strong
supporter of it by way of forcing all of the CI builds to use packages
rather than source. So I definitely see the value in having an OpenStack
release targetted at Lucid or at Squeeze. I've been arguing for the
necessity of that for a while ... since it is an area in which the
traditional disto model completely and utterly fails. (mainly because
it's an area in which they are not even trying, since it's kind of
opposite from their model) But to do that takes a will from the project
to support release that we've made - and it was pretty clear in the SRU
talks that the project as it stands now (or at least the devs of the
project) is unwilling and uninterested in supporting such an effort. The
only people who expressed a vocal interest in ongoing maint of diablo
post release _were_ the distros... so since they are the ones bringing
the firepower, we're sort of left with their model of user support.

There's my brain dump. I am ALL EARS for suggestions. And please, just
so that we can keep this discussion focused, I don't actually need any
help in solving the technical challenges of how we cut packages. That's
easy and solved already. The main problem here is the challenge of how
we get appropriate content in to the packages in a post-release world.

Thanks for bringing it up Anne! I really do hope we can find the proper
solution here.

Monty

On 10/15/2011 03:47 PM, Anne Gentle wrote:
> Hi all -
> 
> I believe the packages are the source of many many complaints about the
> documentation for Diablo, so I feel my reputation as a writer is on the
> line due to the bad experience people are having with installing (all)
> the OpenStack projects right now.
> 
> I was in the backporting session last week, and many distros sound like
> they'd prefer to package up themselves. However I didn't hear such a
> strong conclusion that the CI team would stop packaging completely
> except for devs. This seems like a poor choice for supporting the many
> non-devs in our community.
> 
> If there are packages that work and are being maintained, I will point
> the official docs to them, but it seems poor form to point official docs
> to seemingly unofficial packages.
> 
> My main goal here is to stop the (justified) complaining about the docs
> not working. If the best way to do that is to point to specific team's
> packages, please let me know. 
> 
> One additional note that I have to also add. I don't really think it's
> fair to have a mostly dev-audience make decisions about something that
> affects the installation and getting started process so drastically. Can
> we please revisit the discussion and continue it more here?
> 
> Thanks,
> Anne
> *Anne Gentle*
> anne@xxxxxxxxxxxxx <mailto:anne@xxxxxxxxxxxxx>
> my blog <http://justwriteclick.com/> | my book
> <http://xmlpress.net/publications/conversation-community/> | LinkedIn
> <http://www.linkedin.com/in/annegentle> | Delicious
> <http://del.icio.us/annegentle> | Twitter <http://twitter.com/annegentle>
> On Thu, Oct 13, 2011 at 11:04 AM, Monty Taylor <mordred@xxxxxxxxxxxx
> <mailto:mordred@xxxxxxxxxxxx>> wrote:
> 
>     Hey all,
> 
>     There were many exciting and productive conversations around packaging
>     and the role of OpenStack as an upstream entity in producing distro
>     packages. Turns out, the general consensus was that the project was
>     spending a bunch of effort to produce packages that no one was using or
>     really interested in using. Additionally, we were making packages in an
>     attempt to help make the distros lives easier, but it actually was
>     making things more difficult.
> 
>     As a result, in order to be a good upstream that facilitates the works
>     of distros and other packagers, for essex we're going to stop producing
>     ubuntu packages as an output of the project. Instead we will rely on the
>     distros and integrators/vendors to provide an end-user consumable thing
>     and keep our focus on supporting developers. This has several specific
>     changes:
> 
>     - Jenkins jobs are going to start using the venv/pip-based version of
>     run_tests.sh.
> 
>     - We will not be uploading nova/swift/glance/keystone to PPAs.
> 
>     - We will still maintain a PPA with backport packages of depends for dev
>     purposes (things like libvirt) This will be a new PPA though, as there
>     is really no point in having separate PPAs for each project any more.
> 
>     - We will be setting up a PyPI mirror into which we will publish
>     pip-able packages for every trunk commit. This will be more useful for
>     devs wanting to develop, say, nova against the latest keystone. It will
>     not be intended for people to deploy from.
> 
>     - We're going to base a bunch of jenkins integration testing jobs on the
>     devstack work from cloudbuilders, as it does a simple deploy into a
>     container and is something that a dev can use locally to reproduce
>     problems that they might see reported by jenkins.
> 
>     It's going to take us a little bit to get this sorted in a way that's
>     not disruptive. If we do it right, you should mostly not notice - other
>     than the PPA change for folks who are wanting to install depend packages
>     - but I'll announce that when it happens... and of course the old ppas
>     will still exist but just be deprecated.
> 
>     I'll follow up with implementation details as they happen.
> 
>     Thanks!
>     Monty
> 
>     _______________________________________________
>     Mailing list: https://launchpad.net/~openstack
>     <https://launchpad.net/%7Eopenstack>
>     Post to     : openstack@xxxxxxxxxxxxxxxxxxx
>     <mailto:openstack@xxxxxxxxxxxxxxxxxxx>
>     Unsubscribe : https://launchpad.net/~openstack
>     <https://launchpad.net/%7Eopenstack>
>     More help   : https://help.launchpad.net/ListHelp
> 
>