Open Stack

Assaf, can you provide some context on why this option had to be
deprecated? Isn't the no namespace case a degenerate version of all of
stuff scoped to a namespace, or is it not that simple?

I'm less convinced that deprecating is the right move here if it's just to
make the code easier to manage. We did already get one use case from
Calico...

On Mon, Mar 30, 2015 at 11:11 PM, Miguel Ángel Ajo <majopela at redhat.com>
wrote:

> 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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


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