Dell - Internal Use - Confidential Normally I would say keep the original clis for a cycle but it also makes it more difficult to migrate them to using cliff. So I would vote for removing old entry points. Reworking any workflows consuming the old entry points, to use the new ones, should be pretty trivial.
Thanks, dp From: Masayuki Igawa [mailto:[email protected]] Sent: Monday, November 16, 2015 8:40 PM To: OpenStack Development Mailing List (not for usage questions) Subject: [openstack-dev] [QA][Tempest] Deprecate or drop about Tempest CLI Hi tempest CLI users and developers, Now, we are improving Tempest CLI as we discussed at the summit[1] and migrating legacy commands to tempest cli[2]. In this situation, my concern is 'CLI compatibility'. If we'll drop old CLIs support(like my patch), it might break existing workflows. So I think there are two options. 1. Deprecate old tempest CLIs in this Mitaka cycle and we'll drop them at the beginning of the N cycle. 2. Drop old tempest CLIs in this Mitaka cycle when new CLIs will be implemented. # Actually, I'd like to just drop old CLIs. :) If you have question and/or opinion, please let me know. [1] https://etherpad.openstack.org/p/tempest-cli-improvements [2] https://review.openstack.org/#/c/240399/ Best Regards, -- Masayuki Igawa
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
