<div dir="ltr">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?<div><br></div><div>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...</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Mar 30, 2015 at 11:11 PM, Miguel Ángel Ajo <span dir="ltr"><<a href="mailto:majopela@redhat.com" target="_blank">majopela@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">
<div><span style="color:rgb(160,160,168)">On Tuesday, 31 de March de 2015 at 7:14, George Shuklin wrote:</span></div>
<blockquote type="cite" style="border-left-style:solid;border-width:1px;margin-left:0px;padding-left:10px">
<span><div><div><div><br></div><div><br></div><div>On 03/30/2015 11:18 AM, Kevin Benton wrote:</div><blockquote type="cite"><div><div>What does fog do? Is it just a client to the Neutron HTTP API? If so, </div><div>it should not have broken like that because the API has remained </div><div>pretty stable. If it's a deployment tool, then I could see that </div><div>because the configuration options to tend to suffer quite a bit of </div><div>churn as tools used by the reference implementation evolve.</div></div></blockquote><div>As far as I understand (I'm not ruby guy, I'm openstack guy, but I </div><div>peeking to ruby guys attempts to use openstack with fog as replacement </div><div>for vagrant/virtualbox), the problem lies in the default network selection.</div><div><br></div><div>Fog expects to have one network and use it, and neutron network-rich </div><div>environment is simply too complex for it. May be it is fog to blame, but </div><div>result is simple: some user library worked fine with nova networks but </div><div>struggling after update to neutron.</div><div><br></div><div>Linux usually covers all those cases to make transition between versions </div><div>very smooth. Openstack is not.</div><div><br></div><blockquote type="cite"><div><div>I agree that these changes are an unpleasant experience for the end </div><div>users, but that's what the deprecation timeline is for. This feature </div><div>won't break in L, it will just result in deprecation warnings. If we </div><div>get feedback from users that this serves an important use case that </div><div>can't be addressed another way, we can always stop the deprecation at </div><div>that point.</div></div></blockquote><div>In my opinion it happens too fast and cruel. For example: It deprecates </div><div>in 'L' release and will be kept only of 'L' users complains. But for </div><div>that many users should switch from havana to newer version. But it not </div><div>true, many skips few versions before moving to the new one.</div><div><br></div><div>Openstack releases are too wild and untested to be used 'after release' </div><div>(simple example: VLAN id bug in neutron, which completely breaks hard </div><div>reboots in neutron, was fixed in last update of havana, that means all </div><div>havanas was broken from the moment of release to the very last moment), </div><div>so users wait until bugs are fixed. And they deploy new version after </div><div>that. So it is something like half of the year between new version and </div><div>deployment. And no one wants to do upgrade right after they done </div><div>deployment. Add one or two more years. And only than user find that </div><div>everything is deprecated and removed and openstack is new and shiny </div><div>again, and everyone need to learn it from scratches. I'm exaggerating a </div><div>bit, but that's true - the older and mature installation (like big </div><div>public cloud) the less they want to upgrade every half of the year to </div><div>the shiny new bugs.</div><div><br></div><div>TL;DR: Deprecation cycle should take at least few years to get proper </div><div>feedback from real heavy users.</div></div></div></span></blockquote><div><br></div></div></div><div><span style="font-size:14px">From the user POV I can’t do other thing but agree, you pictured it right,</span></div><div><span style="font-size:14px">currently we mark something for deprecation, and by the middle/end of next</span></div><div><span style="font-size:14px">cycle it’s deprecated. But most users won’t realize it’s deprecated until</span></div><div><span style="font-size:14px">it’s too late, either because they jump to use a stable version after a few stable</span></div><div><span style="font-size:14px">releases to be safe, or because they skip versions.</span></div><div><span style="font-size:14px"><br></span></div><div><span style="font-size:14px">From the code point of view, it can, sometimes become messy, but we </span></div><div><span style="font-size:14px">should take care </span><span style="font-size:14px">of our customers…</span></div><div><br></div>
<br>__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature"><div>Kevin Benton</div></div>
</div>