Another piece to the conversation I think is update philosophy. If you are always going to require a new image and no customization after build ever, ever, the messiness that source usually cause in the file system image really doesn't matter. The package system allows you to easily update, add, and remove packages bits at runtime cleanly. In our experimenting with OpenStack, its becoming hard to determine which philosophy is better. Golden Images for some things make a lot of sense. For other random services, the maintenance of the Golden Image seems to be too much to bother with and just installing a few packages after image start is preferable. I think both approaches are valuable. This may not directly relate to what is best for Triple-O elements, but since we are talking philosophy anyway...
Again though, I think if you wish to make the argument that packages are undesirable, then ALL packages are probably undesirable for the same reasons. Right? Why not make elements for all dependencies, instead of using distro packages to get you 90% of the way there and then using source just for OpenStack bits. If you always want the newest, latest greatest Neutron, don't you want the newest VSwitch too? I'd argue though there is a point of diminishing returns with source that packages fill. Then the argument is where is the point. Some folks think the point is all the way over to "just use packages for everything". I still think using distro packages buys you a lot, even if you are just using them to create a static golden image. Thanks, Kevin ________________________________________ From: James Slagle [james.sla...@gmail.com] Sent: Tuesday, January 07, 2014 3:59 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [TripleO] Installing from packages in tripleo-image-elements On Tue, Jan 7, 2014 at 6:12 PM, Clint Byrum <cl...@fewbar.com> wrote: > Excerpts from Fox, Kevin M's message of 2014-01-07 13:11:13 -0800: >> I was going to stay silent on this one, but since you asked... >> >> /me puts his customer hat on >> >> We source OpenStack from RDO for the packages and additional integration >> testing that comes from the project instead of using OpenStack directly. I >> was a little turned off from Triple-O when I saw it was source only. The >> feeling being that it is "too green" for our tastes. Which may be >> inaccurate. While I might be convinced to use source, its a much harder sell >> to us currently then using packages. >> > > Kevin, thanks for sharing. I think I understand that it is just a new > way of thinking and that makes it that much harder to consume. > > We have good reasons for not using packages. And we're not just making > this up as a new crazy idea, we're copying what companies like Netflix > have published about running at scale. We need to do a better job at > making sure why we're doing some of the things we're doing. Do you have a link for the publication handy? I know they use a blessed AMI approach. But I'm curious about the "not using packages" part, and the advantages they get from that. All I could find from googling is people trying to install netflix from packages to watch movies :). Their AMI build tool seems to indicate they package their apps: https://github.com/Netflix/aminator As does this presentation: http://www.slideshare.net/garethbowles/building-netflixstreamingwithjenkins-juc -- -- James Slagle -- _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
