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…
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
