Re: [openstack-dev] [Openstack-operators] [Neutron] Deprecating the use_namespaces option - Now's the time to speak up!
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
Re: [openstack-dev] [Openstack-operators] [Neutron] Deprecating the use_namespaces option - Now's the time to speak up!
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 majop...@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-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
Re: [openstack-dev] [Openstack-operators] [Neutron] Deprecating the use_namespaces option - Now's the time to speak up!
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
Re: [openstack-dev] [Openstack-operators] [Neutron] Deprecating the use_namespaces option - Now's the time to speak up!
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
Re: [openstack-dev] [Openstack-operators] [Neutron] Deprecating the use_namespaces option - Now's the time to speak up!
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
Re: [openstack-dev] [Openstack-operators] [Neutron] Deprecating the use_namespaces option - Now's the time to speak up!
On 3/23/2015 3:56 AM, Miguel Ángel Ajo wrote: I see you point Van, In the other hand, removing it, cleans up lot of conditional code parts (moving parts at the other side), and also the non-netns case is not tested by upstream CI, AFAIK, so it could be broken anytime and we would not notice it. Miguel Ángel Ajo On Monday, 23 de March de 2015 at 9:25, Van Leeuwen, Robert wrote: I think there are valid reasons to not use namespaces: * Fewer moving parts == less can potentialy fail * Troubleshooting is easier due to less places to look / need no familiarity with namespaces tools * If I remember correctly setting up a namespace can get really slow when you have a lot of them on a single machine IMHO, those shouldn’t be valid reasons anymore, since they were due iproute, or sudo issues that have been corrected long ago, and all distros installing neutron are supporting netns at this Well, you exactly made my point: There is lots that can and will go wrong with more moving parts. That they are fixed at the moment does not mean that there will not be a new bug in the future… Cheers, Robert van Leeuwen ___ OpenStack-operators mailing list openstack-operat...@lists.openstack.org mailto:openstack-operat...@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators __ 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 FWIW we were doing CI without namespaces before Kilo simply due to RHEL 6.5 not having the support w/o a kernel patch. Since Kilo dropped py26 support we moved to RHEL 7* for py27 and that has namespace support so it's no longer an issue for us. -- Thanks, Matt Riedemann __ 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
Re: [openstack-dev] [Openstack-operators] [Neutron] Deprecating the use_namespaces option - Now's the time to speak up!
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. - Original Message - On 3/23/2015 3:56 AM, Miguel Ángel Ajo wrote: I see you point Van, In the other hand, removing it, cleans up lot of conditional code parts (moving parts at the other side), and also the non-netns case is not tested by upstream CI, AFAIK, so it could be broken anytime and we would not notice it. Miguel Ángel Ajo On Monday, 23 de March de 2015 at 9:25, Van Leeuwen, Robert wrote: I think there are valid reasons to not use namespaces: * Fewer moving parts == less can potentialy fail * Troubleshooting is easier due to less places to look / need no familiarity with namespaces tools * If I remember correctly setting up a namespace can get really slow when you have a lot of them on a single machine IMHO, those shouldn’t be valid reasons anymore, since they were due iproute, or sudo issues that have been corrected long ago, and all distros installing neutron are supporting netns at this Well, you exactly made my point: There is lots that can and will go wrong with more moving parts. That they are fixed at the moment does not mean that there will not be a new bug in the future… Cheers, Robert van Leeuwen ___ OpenStack-operators mailing list openstack-operat...@lists.openstack.org mailto:openstack-operat...@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators __ 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 FWIW we were doing CI without namespaces before Kilo simply due to RHEL 6.5 not having the support w/o a kernel patch. Since Kilo dropped py26 support we moved to RHEL 7* for py27 and that has namespace support so it's no longer an issue for us. -- Thanks, Matt Riedemann __ 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 __ 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
Re: [openstack-dev] [Openstack-operators] [Neutron] Deprecating the use_namespaces option - Now's the time to speak up!
I think there are valid reasons to not use namespaces: * Fewer moving parts == less can potentialy fail * Troubleshooting is easier due to less places to look / need no familiarity with namespaces tools * If I remember correctly setting up a namespace can get really slow when you have a lot of them on a single machine IMHO, those shouldn’t be valid reasons anymore, since they were due iproute, or sudo issues that have been corrected long ago, and all distros installing neutron are supporting netns at this Well, you exactly made my point: There is lots that can and will go wrong with more moving parts. That they are fixed at the moment does not mean that there will not be a new bug in the future… Cheers, Robert van Leeuwen __ 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
Re: [openstack-dev] [Openstack-operators] [Neutron] Deprecating the use_namespaces option - Now's the time to speak up!
Are the setups out there *not* using the use_namespaces option? I'm curious as to why, and if it would be difficult to migrate such a setup to use namespaces. At my previous employer we did not use namespaces. This was due to a installation a few years ago on SL6 which did not have name space support at that time. I think there are valid reasons to not use namespaces: * Fewer moving parts == less can potentialy fail * Troubleshooting is easier due to less places to look / need no familiarity with namespaces tools * If I remember correctly setting up a namespace can get really slow when you have a lot of them on a single machine If you have a requirement for having all networks to be routable disabling namespaces does make sense. Since I’m currently in the design phase for such an install I’d surely like to know if it is going to be deprecated. Thx for letting us know about this :) Cheers, Robert van Leeuwen __ 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
Re: [openstack-dev] [Openstack-operators] [Neutron] Deprecating the use_namespaces option - Now's the time to speak up!
On Monday, 23 de March de 2015 at 8:20, Van Leeuwen, Robert wrote: Are the setups out there *not* using the use_namespaces option? I'm curious as to why, and if it would be difficult to migrate such a setup to use namespaces. At my previous employer we did not use namespaces. This was due to a installation a few years ago on SL6 which did not have name space support at that time. I think there are valid reasons to not use namespaces: Fewer moving parts == less can potentialy fail Troubleshooting is easier due to less places to look / need no familiarity with namespaces tools If I remember correctly setting up a namespace can get really slow when you have a lot of them on a single machine If you have a requirement for having all networks to be routable disabling namespaces does make sense. Since I’m currently in the design phase for such an install I’d surely like to know if it is going to be deprecated. Thx for letting us know about this :) Hi Van, thanks for pointing those out IMHO, those shouldn’t be valid reasons anymore, since they were due iproute, or sudo issues that have been corrected long ago, and all distros installing neutron are supporting netns at this point AFAIK. Best regards, Miguel Angel Ajo __ 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
Re: [openstack-dev] [Openstack-operators] [Neutron] Deprecating the use_namespaces option - Now's the time to speak up!
I see you point Van, In the other hand, removing it, cleans up lot of conditional code parts (moving parts at the other side), and also the non-netns case is not tested by upstream CI, AFAIK, so it could be broken anytime and we would not notice it. Miguel Ángel Ajo On Monday, 23 de March de 2015 at 9:25, Van Leeuwen, Robert wrote: I think there are valid reasons to not use namespaces: Fewer moving parts == less can potentialy fail Troubleshooting is easier due to less places to look / need no familiarity with namespaces tools If I remember correctly setting up a namespace can get really slow when you have a lot of them on a single machine IMHO, those shouldn’t be valid reasons anymore, since they were due iproute, or sudo issues that have been corrected long ago, and all distros installing neutron are supporting netns at this Well, you exactly made my point: There is lots that can and will go wrong with more moving parts. That they are fixed at the moment does not mean that there will not be a new bug in the future… Cheers, Robert van Leeuwen ___ OpenStack-operators mailing list openstack-operat...@lists.openstack.org (mailto:openstack-operat...@lists.openstack.org) http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators __ 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
Re: [openstack-dev] [Openstack-operators] [Neutron] Deprecating the use_namespaces option - Now's the time to speak up!
On 2015-03-21 02:57, Assaf Muller wrote: Hello everyone, The use_namespaces option in the L3 and DHCP Neutron agents controls if you can create multiple routers and DHCP networks managed by a single L3/DHCP agent, or if the agent manages only a single resource. Are the setups out there *not* using the use_namespaces option? I'm curious as to why, and if it would be difficult to migrate such a setup to use namespaces. i'm using it in CI/test environment, where i need to connect to the vm and the control plane at the same time. (vm network is gre) I'm asking because use_namespaces complicates Neutron code for what I gather is an option that has not been relevant for years. I'd like to deprecate the option for Kilo and remove it in Liberty. in production i use namespaces, but only because is the default. we have many clouds and none of them share the same ip range. as other have said, i think is better to have less moving parts, namespaces had problems with kernel and iproute2 before and may have problems again -- 1AE0 322E B8F7 4717 BDEA BF1D 44BB 1BA7 9F6C 6333 __ 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
