Open Stack

On 6/2/2017 1:14 PM, Clay Gerrard wrote:
> Can we make this (at least) two (community?) goals?
> 
> #1 Make a thing that is not paste that is better than paste (i.e. > 
> works, ie >= works & is maintained)
> #2 Have some people/projects "migrate" to it
> 
> If the goal is just "take over paste maintenance" that's maybe ok - but 
> is that an "OpenStack community" goal or just something that someone who 
> has the bandwidth to do could do?  It also sounds cheaper and probably 
> about as good.
> 
> Alternatively we can just keep using paste until we're tired of working 
> around it's bugs/limitations - and then replace it with something in 
> tree that implements only 100% of what the project using it needs to get 
> done - then if a few projects do this and they see they're maintaining 
> similar code they could extract it to a common library - but iff sharing 
> their complexity isolated behind an abstraction sounds better than 
> having multiple simpler and more agile ways to do similar-ish stuff - 
> and only *then* make a thing that is not paste but serves a similar 
> use-case as paste and is also maintained and easy to migrate too from 
> paste.  At which point it might be reasonable to say "ok, community, new 
> goal, if you're not already using the thing that's not paste but does 
> about the same as paste - then we want to organize some people in the 
> community experienced with the effort of such a migration to come assist 
> *all openstack projects* (who use paste) in completing the goal of 
> getting off paste - because srly, it's *that* important"
> 
> -Clay
> 

I don't think the maintenance issue is the prime motivator, it's the 
fact paste is in /etc which makes it a config file and therefore an 
impediment to smooth upgrades. The more we can move into code, like 
default policy and privsep, the better.

-- 

Thanks,

Matt