Re: [openstack-dev] [oslo] request_id deprecation strategy question

2014-11-25 Thread Ihar Hrachyshka
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 21/10/14 11:52, Steven Hardy wrote:
 On Mon, Oct 20, 2014 at 03:27:19PM -0700, Joe Gordon wrote:
 On Mon, Oct 20, 2014 at 11:12 AM, gordon chung g...@live.ca
 wrote:
 
 The issue I'm highlighting is that those projects using the
 code now
 have
 to update their api-paste.ini files to import from the new
 location, presumably while giving some warning to operators
 about the impending removal of the old code.
 This was the issue i ran into when trying to switch projects to 
 oslo.middleware where i couldn't get jenkins to pass -- grenade
 tests successfully did their job. we had a discussion on
 openstack-qa and it was suggested to add a upgrade script to
 grenade to handle the new reference and document the switch. [1] 
 if there's any issue with this solution, feel free to let us
 know.
 
 Going down this route means every deployment that wishes to
 upgrade now has an extra step, and should be avoided whenever
 possible. Why not just have a wrapper in project.openstack.common
 pointing to the new oslo.middleware library. If that is not a
 viable solution, we should give operators one full cycle where
 the oslo-incubator version is deprecated and they can migrate to
 the new copy outside of the upgrade process itself. Since there
 is no deprecation warning in Juno [0], We can deprecate the
 oslo-incubator copy in Kilo and remove in L.
 
 
 I've proposed a patch with a compatibility shim which may provide
 one way to resolve this:
 
 https://review.openstack.org/129858

FYI some projects (e.g. neutron or swift) also utilize catch_errors
filter, so I've requested another shim for the middleware module in
oslo-incubator: https://review.openstack.org/136999

 
 Steve
 
 ___ OpenStack-dev
 mailing list OpenStack-dev@lists.openstack.org 
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 
-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2.0.22 (Darwin)

iQEcBAEBCgAGBQJUdKOOAAoJEC5aWaUY1u578K8H/jUb3eLE4bItGfkuzZ9uAes9
7ekva40wgNK3u96DMGbBIKOFxbljvXt5tlIPKjw26cW1G834VeGsuyB+3ql53aGD
Y743L4NOvzRwAnlorh35CbjEXu+RSfCEw5Y7w3K7N4kVfsQ8Zw2NObAq4hk1wKJ7
bc6maJZa6D8nptY7q8bCsLsrXudnpRLsfqbei7NurQawBGGhikaSkB1Vk/8eHuNL
PA8T9m4Ya70zueInhPnNgB7v3YagV0fLgYE+SMQF66HL7Vak3vrmfgD03pI1QtWV
NQkEiccAS2teEf5jijznFC2t4DtJ5vclIfKNWaoMUEz4pg01oE/85eBE+34h22o=
=NkCt
-END PGP SIGNATURE-

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [oslo] request_id deprecation strategy question

2014-10-21 Thread Steven Hardy
On Mon, Oct 20, 2014 at 03:27:19PM -0700, Joe Gordon wrote:
On Mon, Oct 20, 2014 at 11:12 AM, gordon chung g...@live.ca wrote:
 
   The issue I'm highlighting is that those projects using the code now
  have
   to update their api-paste.ini files to import from the new location,
   presumably while giving some warning to operators about the impending
   removal of the old code.
  This was the issue i ran into when trying to switch projects to
  oslo.middleware where i couldn't get jenkins to pass -- grenade tests
  successfully did their job. we had a discussion on openstack-qa and it
  was suggested to add a upgrade script to grenade to handle the new
  reference and document the switch. [1]
  if there's any issue with this solution, feel free to let us know.
 
Going down this route means every deployment that wishes to upgrade now
has an extra step, and should be avoided whenever possible. Why not just
have a wrapper in project.openstack.common pointing to the new
oslo.middleware library. If that is not a viable solution, we should give
operators one full cycle where the oslo-incubator version is deprecated
and they can migrate to the new copy outside of the upgrade process
itself. Since there is no deprecation warning in Juno [0], We can
deprecate the oslo-incubator copy in Kilo and remove in L.

Yeah, this is pretty much my take on it - it's unfortunate that we missed
the opportunity to add a deprecation warning for Juno, but given that we
did, we're probably stuck with deprecation for Kilo and remove in L.

Unless there's some dispensation to the normal backwards-compat policy for
paste configs? (as opposed to the project .conf files, where I know you
can't do this, because I've been shouted at for trying it in the past ;)

Having a shim put back into oslo-incubator, with deprecation warning for
Kilo, then sync that to all projects before making the switch seems to be
a reasonable compromise to me.

Steve

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [oslo] request_id deprecation strategy question

2014-10-21 Thread Steven Hardy
On Mon, Oct 20, 2014 at 03:27:19PM -0700, Joe Gordon wrote:
On Mon, Oct 20, 2014 at 11:12 AM, gordon chung g...@live.ca wrote:
 
   The issue I'm highlighting is that those projects using the code now
  have
   to update their api-paste.ini files to import from the new location,
   presumably while giving some warning to operators about the impending
   removal of the old code.
  This was the issue i ran into when trying to switch projects to
  oslo.middleware where i couldn't get jenkins to pass -- grenade tests
  successfully did their job. we had a discussion on openstack-qa and it
  was suggested to add a upgrade script to grenade to handle the new
  reference and document the switch. [1]
  if there's any issue with this solution, feel free to let us know.
 
Going down this route means every deployment that wishes to upgrade now
has an extra step, and should be avoided whenever possible. Why not just
have a wrapper in project.openstack.common pointing to the new
oslo.middleware library. If that is not a viable solution, we should give
operators one full cycle where the oslo-incubator version is deprecated
and they can migrate to the new copy outside of the upgrade process
itself. Since there is no deprecation warning in Juno [0], We can
deprecate the oslo-incubator copy in Kilo and remove in L.


I've proposed a patch with a compatibility shim which may provide one way
to resolve this:

https://review.openstack.org/129858

Steve

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [oslo] request_id deprecation strategy question

2014-10-20 Thread Sandy Walsh
Does this mean we're losing request-id's?

Will they still appear in the Context objects?

And there was the effort to keep consistent request-id's in cross-service 
requests, will this deprecation affect that?

-S


From: Steven Hardy [sha...@redhat.com]
Sent: Monday, October 20, 2014 10:58 AM
To: openstack-dev@lists.openstack.org
Subject: [openstack-dev] [oslo] request_id deprecation strategy question

Hi all,

I have a question re the deprecation strategy for the request_id module,
which was identified as a candidate for removal in Doug's recent message[1],
as it's moved from oslo-incubator to oslo.middleware.

The problem I see is that oslo-incubator deprecated this in Juno, but
(AFAICS) all projects shipped Juno without the versionutils deprecation
warning sync'd [2]

Thus, we can't remove the local openstack.common.middleware.request_id, or
operators upgrading from Juno to Kilo without changing their api-paste.ini
files will experience breakage without any deprecation warning.

I'm sure I've read and been told that all backwards incompatible config
file changes require a deprecation period of at least one cycle, so does
this mean all projects just sync the Juno oslo-incubator request_id into
their kilo trees, leave it there until kilo releases, while simultaneously
switching their API configs to point to oslo.middleware?

Guidance on how to proceed would be great, if folks have thoughts on how
best to handle this.

Thanks!

Steve


[1] http://lists.openstack.org/pipermail/openstack-dev/2014-October/048303.html
[2] 
https://github.com/openstack/oslo-incubator/blob/stable/juno/openstack/common/middleware/request_id.py#L33

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [oslo] request_id deprecation strategy question

2014-10-20 Thread Steven Hardy
On Mon, Oct 20, 2014 at 02:17:54PM +, Sandy Walsh wrote:
 Does this mean we're losing request-id's?

No, it just means the implementation has moved from oslo-incubator[1] to
oslo.middleware[2].

The issue I'm highlighting is that those projects using the code now have
to update their api-paste.ini files to import from the new location,
presumably while giving some warning to operators about the impending
removal of the old code.

All I'm seeking to clarify is the most operator sensitive way to handle
this transition, given that we seem to have missed the boat on including a
nice deprecation warning for Juno.

Steve

[1] 
https://github.com/openstack/oslo-incubator/blob/stable/juno/openstack/common/middleware/request_id.py#L33
[2] 
https://github.com/openstack/oslo.middleware/blob/master/oslo/middleware/request_id.py

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [oslo] request_id deprecation strategy question

2014-10-20 Thread Sandy Walsh
Phew :)

Thanks Steve. 

From: Steven Hardy [sha...@redhat.com]
Sent: Monday, October 20, 2014 12:52 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [oslo] request_id deprecation strategy question

On Mon, Oct 20, 2014 at 02:17:54PM +, Sandy Walsh wrote:
 Does this mean we're losing request-id's?

No, it just means the implementation has moved from oslo-incubator[1] to
oslo.middleware[2].

The issue I'm highlighting is that those projects using the code now have
to update their api-paste.ini files to import from the new location,
presumably while giving some warning to operators about the impending
removal of the old code.

All I'm seeking to clarify is the most operator sensitive way to handle
this transition, given that we seem to have missed the boat on including a
nice deprecation warning for Juno.

Steve

[1] 
https://github.com/openstack/oslo-incubator/blob/stable/juno/openstack/common/middleware/request_id.py#L33
[2] 
https://github.com/openstack/oslo.middleware/blob/master/oslo/middleware/request_id.py

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [oslo] request_id deprecation strategy question

2014-10-20 Thread gordon chung
 The issue I'm highlighting is that those projects using the code now have
 to update their api-paste.ini files to import from the new location,
 presumably while giving some warning to operators about the impending
 removal of the old code.
This was the issue i ran into when trying to switch projects to oslo.middleware 
where i couldn't get jenkins to pass -- grenade tests successfully did their 
job. we had a discussion on openstack-qa and it was suggested to add a upgrade 
script to grenade to handle the new reference and document the switch. [1]
if there's any issue with this solution, feel free to let us know.
[1] 
http://eavesdrop.openstack.org/irclogs/%23openstack-qa/%23openstack-qa.2014-10-10.log
 (search for gordc)
cheers,
gord  ___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [oslo] request_id deprecation strategy question

2014-10-20 Thread Joe Gordon
On Mon, Oct 20, 2014 at 11:12 AM, gordon chung g...@live.ca wrote:

  The issue I'm highlighting is that those projects using the code now have
  to update their api-paste.ini files to import from the new location,
  presumably while giving some warning to operators about the impending
  removal of the old code.

 This was the issue i ran into when trying to switch projects to
 oslo.middleware where i couldn't get jenkins to pass -- grenade tests
 successfully did their job. we had a discussion on openstack-qa and it was
 suggested to add a upgrade script to grenade to handle the new reference
 and document the switch. [1]

 if there's any issue with this solution, feel free to let us know.


Going down this route means every deployment that wishes to upgrade now has
an extra step, and should be avoided whenever possible. Why not just have a
wrapper in project.openstack.common pointing to the new oslo.middleware
library. If that is not a viable solution, we should give operators one
full cycle where the oslo-incubator version is deprecated and they can
migrate to the new copy outside of the upgrade process itself. Since there
is no deprecation warning in Juno [0], We can deprecate the oslo-incubator
copy in Kilo and remove in L.


[0] first email in this thread



 [1]
 http://eavesdrop.openstack.org/irclogs/%23openstack-qa/%23openstack-qa.2014-10-10.log
  (search
 for gordc)

 cheers,
 *gord*

 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev