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.
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. On Sun, Mar 29, 2015 at 12:44 PM, George Shuklin <george.shuk...@gmail.com> wrote: > On 03/24/2015 09:21 PM, Assaf Muller wrote: > >> Note that https://review.openstack.org/#/c/166888/ has been merged. >> This means that the option has been deprecated for K and will be >> removed in L. Anyone using the non-default value of False will be looking >> at errors in his logs. >> >> > Well, I have nothing to do with that option, but every time I see how > cruel is Openstack toward users, I can't avoid to compare it to Linux. They > keep code which is used by userspace forever. Even if it cause programmers > feel like they need to work more. > > I understand that Openstack is growing and there are many 'baby mistakes' > in the past. > > But next time you will be curios why someone still sitting on cactus, > remember this case. Every new release of openstack is like new software > where you need to learn everything from scratches. > > Compare this to modern Linux updates, where changes in the kernel almost > invisible for userspace and new versions are 'for new features', not for > 'oh, now I need to rewrite my libraries to support new version'. > > I'm not joking. Check out ruby's fog - it simply does not work in modern > neutron-based network. Who is to blame? Users, obviously. Lazy bums without > any respect to great work to rewrite and obsolete everything. > > > > __________________________________________________________________________ > 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 > -- Kevin Benton
__________________________________________________________________________ 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