Open Stack

On Tuesday, 31 de March de 2015 at 7:14, George Shuklin wrote:
>  
>  
> On 03/30/2015 11:18 AM, Kevin Benton wrote:
> > What does fog do? Is it just a client to the Neutron HTTP API? If so,  
> > it should not have broken like that because the API has remained  
> > pretty stable. If it's a deployment tool, then I could see that  
> > because the configuration options to tend to suffer quite a bit of  
> > churn as tools used by the reference implementation evolve.
> >  
>  
> As far as I understand (I'm not ruby guy, I'm openstack guy, but I  
> peeking to ruby guys attempts to use openstack with fog as replacement  
> for vagrant/virtualbox), the problem lies in the default network selection.
>  
> Fog expects to have one network and use it, and neutron network-rich  
> environment is simply too complex for it. May be it is fog to blame, but  
> result is simple: some user library worked fine with nova networks but  
> struggling after update to neutron.
>  
> Linux usually covers all those cases to make transition between versions  
> very smooth. Openstack is not.
>  
> > I agree that these changes are an unpleasant experience for the end  
> > users, but that's what the deprecation timeline is for. This feature  
> > won't break in L, it will just result in deprecation warnings. If we  
> > get feedback from users that this serves an important use case that  
> > can't be addressed another way, we can always stop the deprecation at  
> > that point.
> >  
>  
> In my opinion it happens too fast and cruel. For example: It deprecates  
> in 'L' release and will be kept only of 'L' users complains. But for  
> that many users should switch from havana to newer version. But it not  
> true, many skips few versions before moving to the new one.
>  
> Openstack releases are too wild and untested to be used 'after release'  
> (simple example: VLAN id bug in neutron, which completely breaks hard  
> reboots in neutron, was fixed in last update of havana, that means all  
> havanas was broken from the moment of release to the very last moment),  
> so users wait until bugs are fixed. And they deploy new version after  
> that. So it is something like half of the year between new version and  
> deployment. And no one wants to do upgrade right after they done  
> deployment. Add one or two more years. And only than user find that  
> everything is deprecated and removed and openstack is new and shiny  
> again, and everyone need to learn it from scratches. I'm exaggerating a  
> bit, but that's true - the older and mature installation (like big  
> public cloud) the less they want to upgrade every half of the year to  
> the shiny new bugs.
>  
> TL;DR: Deprecation cycle should take at least few years to get proper  
> feedback from real heavy users.
>  
>  


From the user POV I can’t do other thing but agree, you pictured it right,
currently we mark something for deprecation, and by the middle/end of next
cycle it’s deprecated. But most users won’t realize it’s deprecated until
it’s too late, either because they jump to use a stable version after a few stable
releases to be safe, or because they skip versions.

From the code point of view, it can, sometimes become messy, but we  
should take care of our customers…

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150331/6c206757/attachment.html>