On Thu, Oct 19, 2017 at 11:49 AM, Lance Bragstad <lbrags...@gmail.com> wrote: > Yeah - we specifically talked about this in a recent meeting [0]. We > will be more verbose about this in the future. >
I'm glad to see a review of this. In reading the meeting logs, I understand it was well communicated that the api was going to go away at some point. Yes we all knew it was coming, but the exact time of impact wasn't known outside of Keystone. Also saying "oh it works in devstack" is not enough when you do something this major. So a "FYI, patches to remove v2.0 to start landing next week (or today)" is more what would have been helpful for the devs who consume master. It dramatically shortens the time spent debugging failures if you have an idea about when something major changes and then we don't have to go through git logs/gerrit to figure out what happened :) IMHO when large efforts that affect the usage of your service are going to start to land, it's good to send a note before landing those patches. Or at least at the same time. Anyway I hope other projects will also follow a similar pattern when they ultimately need to do something like this in the future. Thanks, -Alex > > [0] > http://eavesdrop.openstack.org/meetings/keystone/2017/keystone.2017-10-10-18.00.log.html#l-107 > > On 10/19/2017 12:00 PM, Alex Schultz wrote: >> On Thu, Oct 19, 2017 at 10:08 AM, Lance Bragstad <lbrags...@gmail.com> wrote: >>> Hey all, >>> >>> Now that we're finishing up the last few bits of v2.0 removal, I'd like to >>> send out a reminder that Queens will not include the v2.0 keystone APIs >>> except the ec2-api. Authentication and validation of v2.0 tokens has been >>> removed (in addition to the public and admin APIs) after a lengthy >>> deprecation period. >>> >> In the future can we have a notice before the actual code removal >> starts? We've been battling various places where we thought we had >> converted to v3 only to find out we hadn't correctly done so because >> it use to just 'work' and the only way we know now is that CI blew up. >> A heads up on the ML probably wouldn't have lessened the pain in this >> instance but at least we might have been able to pinpoint the exact >> problem quicker. >> >> Thanks, >> -Alex >> >> >>> Let us know if you have any questions. >>> >>> Thanks! >>> >>> >>> __________________________________________________________________________ >>> 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 > > __________________________________________________________________________ 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
