Re: [openstack-dev] [all][ironic] How to proceed about deprecation of untagged code?
Em 04.11.2015 17:19, Jim Rollenhagen escreveu: On Wed, Nov 04, 2015 at 02:55:49PM -0500, Sean Dague wrote: On 11/04/2015 02:42 PM, Jim Rollenhagen wrote: > On Wed, Nov 04, 2015 at 04:08:18PM -0300, Gabriel Bezerra wrote: >> Em 04.11.2015 11:32, Jim Rollenhagen escreveu: >>> On Wed, Nov 04, 2015 at 08:44:36AM -0500, Jay Pipes wrote: >>> On 11/03/2015 11:40 PM, Gabriel Bezerra wrote: >>>> Hi, >>>> >>>> The change in https://review.openstack.org/237122 touches a feature from >>>> ironic that has not been released in any tag yet. >>>> >>>> At first, we from the team who has written the patch thought that, as it >>>> has not been part of any release, we could do backwards incompatible >>>> changes on that part of the code. As it turned out from discussing with >>>> the community, ironic commits to keeping the master branch backwards >>>> compatible and a deprecation process is needed in that case. >>>> >>>> That stated, the question at hand is: How long should this deprecation >>>> process last? >>>> >>>> This spec specifies the deprecation policy we should follow: >>>> https://github.com/openstack/governance/blob/master/reference/tags/assert_follows-standard-deprecation.rst >>>> >>>> >>>> As from its excerpt below, the minimum obsolescence period must be >>>> max(next_release, 3 months). >>>> >>>> """ >>>> Based on that data, an obsolescence date will be set. At the very >>>> minimum the feature (or API, or configuration option) should be marked >>>> deprecated (and still be supported) in the next stable release branch, >>>> and for at least three months linear time. For example, a feature >>>> deprecated in November 2015 should still appear in the Mitaka release >>>> and stable/mitaka stable branch and cannot be removed before the >>>> beginning of the N development cycle in April 2016. A feature deprecated >>>> in March 2016 should still appear in the Mitaka release and >>>> stable/mitaka stable branch, and cannot be removed before June 2016. >>>> """ >>>> >>>> This spec, however, only covers released and/or tagged code. >>>> >>>> tl;dr: >>>> >>>> How should we proceed regarding code/features/configs/APIs that have not >>>> even been tagged yet? >>>> >>>> Isn't waiting for the next OpenStack release in this case too long? >>>> Otherwise, we are going to have features/configs/APIs/etc. that are >>>> deprecated from their very first tag/release. >>>> >>>> How about sticking to min(next_release, 3 months)? Or next_tag? Or 3 >>>> months? max(next_tag, 3 months)? >>> >>> -1 >>> >>> The reason the wording is that way is because lots of people deploy >>> OpenStack services in a continuous deployment model, from the master >>> source >>> branches (sometimes minus X number of commits as these deployers run the >>> code through their test platforms). >>> >>> Not everyone uses tagged releases, and OpenStack as a community has >>> committed (pun intended) to serving these continuous deployment scenarios. >>> >>> Right, so I asked Gabriel to send this because it's an odd case, and I'd >>> like to clear up the governance doc on this, since it doesn't seem to >>> say much about code that was never released. >>> >>> The rule is a cycle boundary *and* at least 3 months. However, in this >>> case, the code was never in a release at all, much less a stable >>> release. So looking at the two types of deployers: >>> >>> 1) CD from trunk: 3 months is fine, we do that, done. >>> >>> 2) Deploying stable releases: if we only wait three months and not a >>> cycle boundary, they'll never see it. If we do wait for a cycle >>> boundary, we're pushing deprecated code to them for (seemingly to me) no >>> benefit. >>> >>> So, it makes sense to me to not introduce the cycle boundary thing in >>> this case. But there is value in keeping the rule simple, and if we want >>> this one to pass a cycle boundary to optimize for that, I'm okay with >>> that too. :) >>> >>> (Side note: there's actually a third type of deployer for Ironic; one >>> that deploys intermediate releases. I think if we give them at least one >>> release and thr
Re: [openstack-dev] [all][ironic] How to proceed about deprecation of untagged code?
Em 04.11.2015 11:32, Jim Rollenhagen escreveu: On Wed, Nov 04, 2015 at 08:44:36AM -0500, Jay Pipes wrote: On 11/03/2015 11:40 PM, Gabriel Bezerra wrote: >Hi, > >The change in https://review.openstack.org/237122 touches a feature from >ironic that has not been released in any tag yet. > >At first, we from the team who has written the patch thought that, as it >has not been part of any release, we could do backwards incompatible >changes on that part of the code. As it turned out from discussing with >the community, ironic commits to keeping the master branch backwards >compatible and a deprecation process is needed in that case. > >That stated, the question at hand is: How long should this deprecation >process last? > >This spec specifies the deprecation policy we should follow: >https://github.com/openstack/governance/blob/master/reference/tags/assert_follows-standard-deprecation.rst > > >As from its excerpt below, the minimum obsolescence period must be >max(next_release, 3 months). > >""" >Based on that data, an obsolescence date will be set. At the very >minimum the feature (or API, or configuration option) should be marked >deprecated (and still be supported) in the next stable release branch, >and for at least three months linear time. For example, a feature >deprecated in November 2015 should still appear in the Mitaka release >and stable/mitaka stable branch and cannot be removed before the >beginning of the N development cycle in April 2016. A feature deprecated >in March 2016 should still appear in the Mitaka release and >stable/mitaka stable branch, and cannot be removed before June 2016. >""" > >This spec, however, only covers released and/or tagged code. > >tl;dr: > >How should we proceed regarding code/features/configs/APIs that have not >even been tagged yet? > >Isn't waiting for the next OpenStack release in this case too long? >Otherwise, we are going to have features/configs/APIs/etc. that are >deprecated from their very first tag/release. > >How about sticking to min(next_release, 3 months)? Or next_tag? Or 3 >months? max(next_tag, 3 months)? -1 The reason the wording is that way is because lots of people deploy OpenStack services in a continuous deployment model, from the master source branches (sometimes minus X number of commits as these deployers run the code through their test platforms). Not everyone uses tagged releases, and OpenStack as a community has committed (pun intended) to serving these continuous deployment scenarios. Right, so I asked Gabriel to send this because it's an odd case, and I'd like to clear up the governance doc on this, since it doesn't seem to say much about code that was never released. The rule is a cycle boundary *and* at least 3 months. However, in this case, the code was never in a release at all, much less a stable release. So looking at the two types of deployers: 1) CD from trunk: 3 months is fine, we do that, done. 2) Deploying stable releases: if we only wait three months and not a cycle boundary, they'll never see it. If we do wait for a cycle boundary, we're pushing deprecated code to them for (seemingly to me) no benefit. So, it makes sense to me to not introduce the cycle boundary thing in this case. But there is value in keeping the rule simple, and if we want this one to pass a cycle boundary to optimize for that, I'm okay with that too. :) (Side note: there's actually a third type of deployer for Ironic; one that deploys intermediate releases. I think if we give them at least one release and three months, they're okay, so the general standard deprecation rule covers them.) // jim So, summarizing that: * untagged/master: 3 months * tagged/intermediate release: max(next tag/intermediate release, 3 months) * stable release: max(next release, 3 months) Is it correct? __ 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-dev] [all][ironic] How to proceed about deprecation of untagged code?
Hi, The change in https://review.openstack.org/237122 touches a feature from ironic that has not been released in any tag yet. At first, we from the team who has written the patch thought that, as it has not been part of any release, we could do backwards incompatible changes on that part of the code. As it turned out from discussing with the community, ironic commits to keeping the master branch backwards compatible and a deprecation process is needed in that case. That stated, the question at hand is: How long should this deprecation process last? This spec specifies the deprecation policy we should follow: https://github.com/openstack/governance/blob/master/reference/tags/assert_follows-standard-deprecation.rst As from its excerpt below, the minimum obsolescence period must be max(next_release, 3 months). """ Based on that data, an obsolescence date will be set. At the very minimum the feature (or API, or configuration option) should be marked deprecated (and still be supported) in the next stable release branch, and for at least three months linear time. For example, a feature deprecated in November 2015 should still appear in the Mitaka release and stable/mitaka stable branch and cannot be removed before the beginning of the N development cycle in April 2016. A feature deprecated in March 2016 should still appear in the Mitaka release and stable/mitaka stable branch, and cannot be removed before June 2016. """ This spec, however, only covers released and/or tagged code. tl;dr: How should we proceed regarding code/features/configs/APIs that have not even been tagged yet? Isn't waiting for the next OpenStack release in this case too long? Otherwise, we are going to have features/configs/APIs/etc. that are deprecated from their very first tag/release. How about sticking to min(next_release, 3 months)? Or next_tag? Or 3 months? max(next_tag, 3 months)? Best regards, Gabriel Bezerra. __ 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] [Neutron][IPAM] Uniqueness of subnets within a tenant
Em 10.03.2015 14:34, Gabriel Bezerra escreveu: Em 10.03.2015 14:24, Carl Baldwin escreveu: Neutron currently does not enforce the uniqueness, or non-overlap, of subnet cidrs within the address scope for a single tenant. For example, if a tenant chooses to use 10.0.0.0/24 on more than one subnet, he or she is free to do so. Problems will arise when trying to connect a router between these subnets but that is left up to the tenant to work out. In the current IPAM rework, we had decided to allow this overlap in the reference implementation for backward compatibility. However, we've hit a snag. It would be convenient to use the subnet cidr as the handle with which to refer to a previously allocated subnet when talking to IPAM. If overlap is allowed, this is not possible and we need to come up with another identifier such as Neutron's subnet_id or another unique IPAM specific ID. It could be a burden on an external IPAM system -- which does not allow overlap -- to work with a completely separate identifier for a subnet. I do not know of anyone using this capability (or mis-feature) of Neutron. I would hope that tenants are aware of the issues with trying to route between subnets with overlapping address spaces and would avoid it. Is this potential overlap something that we should really be worried about? Could we just add the assumption that subnets do not overlap within a tenant's scope? An important thing to note is that this topic is different than allowing overlap of cidrs between tenants. Neutron will continue to allow overlap of addresses between tenants and support the isolation of these address spaces. The IPAM rework will support this. Carl Baldwin I'd vote for allowing against such restriction, but throwing an error in case of creating a router between the subnets. Fixing my previous e-mail: I'd vote against such restriction, but throwing an error in case of creating a router between the subnets that overlap. I can imagine a tenant running multiple instances of an application, each one with its own network that uses the same address range, to minimize configuration differences between them. __ 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] [Neutron][IPAM] Uniqueness of subnets within a tenant
Em 10.03.2015 14:24, Carl Baldwin escreveu: Neutron currently does not enforce the uniqueness, or non-overlap, of subnet cidrs within the address scope for a single tenant. For example, if a tenant chooses to use 10.0.0.0/24 on more than one subnet, he or she is free to do so. Problems will arise when trying to connect a router between these subnets but that is left up to the tenant to work out. In the current IPAM rework, we had decided to allow this overlap in the reference implementation for backward compatibility. However, we've hit a snag. It would be convenient to use the subnet cidr as the handle with which to refer to a previously allocated subnet when talking to IPAM. If overlap is allowed, this is not possible and we need to come up with another identifier such as Neutron's subnet_id or another unique IPAM specific ID. It could be a burden on an external IPAM system -- which does not allow overlap -- to work with a completely separate identifier for a subnet. I do not know of anyone using this capability (or mis-feature) of Neutron. I would hope that tenants are aware of the issues with trying to route between subnets with overlapping address spaces and would avoid it. Is this potential overlap something that we should really be worried about? Could we just add the assumption that subnets do not overlap within a tenant's scope? An important thing to note is that this topic is different than allowing overlap of cidrs between tenants. Neutron will continue to allow overlap of addresses between tenants and support the isolation of these address spaces. The IPAM rework will support this. Carl Baldwin I'd vote for allowing against such restriction, but throwing an error in case of creating a router between the subnets. I can imagine a tenant running multiple instances of an application, each one with its own network that uses the same address range, to minimize configuration differences between them. __ 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
