On 2014-04-09 10:49:20 -0700 (-0700), Clint Byrum wrote: > Excerpts from Ruslan Kamaldinov's message of 2014-04-09 10:24:48 -0700: > > But, other concerns were expressed in the past. Let me quote > > Jeremy Stanley (from https://review.openstack.org/#/c/66884/): > > > This will need to be maintained in Ubuntu (and backported to > > > 12.04 in Ubuntu Cloud Archive or if necessary a PPA managed by > > > the same package maintenance team taking care of it in later > > > Ubuntu releases). We don't install test requirements > > > system-wide on our long-running test slaves unless we can be > > > assured of security support from the Linux distribution > > > vendor. [...]
Keep in mind that at the time I said that, we had not completed our transition to all single-use Jenkins slaves managed by nodepool. My analysis of the risk is thus shifted slightly now. I'm not opposed to official OpenStack projects needing arbitrary files cached locally on our nodepool images so that they can make use of them on demand without incurring download-related stability penalties (we already do this for a lot of the packages and other bits DevStack needs, for example test images). I'm also not worried by cached packages on the images which are used by some jobs for official projects without being installed by default. We've now got the ability for some jobs to opt out of sudo restrictions, and so they could in theory install these cached packages immediately prior to running their own tests. I mainly just want to make sure we're not preinstalling packages we can't trust unconditionally on all test systems. > This is a huge philosophical question for OpenStack in general. Do > we want to recommend things that we won't, ourselves, use in our > infrastructure? [...] > Basically the support model of the distro isn't compatible with > the support model of these databases. [...] This is where most of my current concerns with the situation are. OpenStack is something run on servers, which operators are almost always going to want under some sort of stable package management from a distribution with a trust chain and security support. I think we should be testing things in the sorts of ways we expect them to be deployed in production by operators, whenever possible. The current development communities around these databases don't sound like they've yet reached the maturity where they're turning out stable, long-term-supported and modularized software which would be commonly found in those sorts of environments (nor would I feel comfortable recommending them as a production solution until that changes). This is not meant in a disparaging way--it's common that projects have a high rate of churn early on as larger design decisions are made, APIs are still being fleshed out, solutions are tried and deemed untenable, et cetera and forward momentum trumps deployability/stability/maintainability. And to some degree, yes, this is the pot calling the kettle black since OpenStack itself can't seem to muster enough developers interested in keeping stable release branches maintained and testable for more than ~9 months before we're forced to EOL them due to neglect. The irony is not lost on me. ;) -- Jeremy Stanley _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev