Open Stack

Sean Dague wrote:
> On 09/10/2015 08:23 AM, Thierry Carrez wrote:
>> Now another problem you're describing is that there is no single place
>> where those filters end up, depending on the way the projects (or libs)
>> are packaged and installed. And it's up to the distros to "fix" the
>> filters_path in the configuration file so that it points to every single
>> place where those end up. It's a problem (especially when you start to
>> install things using multiple concurrent packaging systems), but it's
>> not exactly new -- it's just that libraries shipping fliters file are
>> even more likely to ship their filters somewhere weird. So maybe we can
>> continue to live with that problem we always had, until the privsep
>> system completely replaces rootwrap ?
> 
> I do get this is where we came from. I feel like this doesn't really
> address or understand that things are actually quite different when it
> comes to libraries doing rootwrap. We've spent weeks attempting various
> work arounds, and for Liberty just punted and said "os-brick, cinder,
> and nova all must upgrade exactly at the same time". Because that's the
> only solution that doesn't require pages of documentation that
> installers will get wrong some times.
> 
> I don't feel like that's an acceptable solution. And it also means that
> "living" with it means that next cycle we're going to have to say "nova,
> neutron, cinder, os-brick, and vif library must all upgrade at exactly
> the same time". Which is clearly not a thing we want. Had we figured out
> this rootwrap limitation early, os-brick would never have been put into
> Nova because it makes the upgrade process demonstrably worse and more
> fragile.

Right. The only reason why packagers got it right the first time is
because things were a lot simpler back then (Ubuntu was almost the only
game in town) and I personally got involved and made sure they got it
right. I suspect you're right when you assume that if we rely on them to
push the right things at the right places at this stage in the cycle,
that would probably go wrong in a lot of places.

I also agree that os-brick is not worth it if the cost is crappy
upgrades. I'm just unsure adding a layer of config on top will solve
things. I kinda like the idea of not relying on the filesystem at all
(as proposed by Doug) since the filesystem is so deployment-dependent.

-- 
Thierry Carrez (ttx)