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.
__________________________________________________________________________
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
