Re: [Openstack] Packaging changes based on discussions at ODS
Monty Taylor wrote: Totally in terms of the decisions and re-visiting it. I think you're totally right, of course, in terms of that. Your initial email used terms like we are going to, we will or I'll follow up with implementation details as they happen which certainly sounds like it's an already-made decision. I'm a bit surprised that you come up with these conclusions based on last week's discussions, and that the existing release team (which is ultimately responsible for those release deliverables) wasn't asked for comments before coming up with such a strong direction. 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) I think you are conflating two problems, and decide to throw out the baby with the bath water. One issue is the release packages, the other is the release cycle PPAs. We don't really want to do post-release maintenance on packages in the release PPAs, and therefore they are not really usable long-term as a production install option. One option is definitely to stop producing them. I just don't see how you jump from that to let's stop producing any packages. We have been producing packages in PPAs for trunk, milestone-proposed and last-milestone, and those packages are useful. They are used daily by testers, developers and integrators. They are by no means an end product, but they have their own value. Replacing *all of them* by a single trunk pip repository is just wrong. Where will we call for testing on milestone-proposed ? Where will integrators be able to easily get the last milestone ? Those packages *are* used. PPA stats show more than 33k uses for nova-core/trunk, 350 uses of milestone-proposed and 480 uses of the milestone PPA. In summary, I agree we should now question the release PPAs. I don't see why we should remove all the other ones in the process. And I disagree with your presentation of the general consensus and your already-decided plan. -- Thierry Carrez (ttx) Release Manager, OpenStack ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Packaging changes based on discussions at ODS
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* a...@openstack.org my blog http://justwriteclick.com/ | my bookhttp://xmlpress.net/publications/conversation-community/| LinkedIn http://www.linkedin.com/in/annegentle | Delicioushttp://del.icio.us/annegentle| Twitter http://twitter.com/annegentle On Thu, Oct 13, 2011 at 11:04 AM, Monty Taylor mord...@inaugust.com 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 Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Packaging changes based on discussions at ODS
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* a...@openstack.org mailto:a...@openstack.org 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 mord...@inaugust.com mailto:mord...@inaugust.com 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