Kamil, thank you for the explanation. Indeed, the idea of keeping two separate entry points — one for the old functionality and another with the new cliff-based CLI makes more sense.
In addition to the advantages you mentioned it will allow us to avoid all the mess with fall-backs and concentrate on making the new CLI as it should be from the beginning. I ask you guys to take a look at the chain of patches [1] that implement this approach. 1. https://review.openstack.org/#/q/status:open+project:stackforge/python-fuelclient+branch:master+topic:bp/re-thinking-fuel-client,n,z - romcheg > 4 бер. 2015 о 12:05 Kamil Sambor <ksam...@mirantis.com> написав(ла): > > @romcheg > - the idea is to switch partially to new client so keeping one package with > two entry points: fuel and fuel_v2. It will be convenient for us to add new > commands to fuel_v2 only and switch slowly old commands to new version and > add warnings in old client commands. It will give users time to switch to new > client and it will be easy for us to migrate only old commands. Now when we > add new command we add to old client and then in future still need to migrate > it. SO keeping two entry points for fuel-client IMHO will be convenient for > developers and for users. > > Best regards, > Kamil Sambor > > On Wed, Mar 4, 2015 at 10:54 AM, Roman Prykhodchenko <m...@romcheg.me> wrote: > I’d like to resolve some questions: > > @Przemysław: > - We can avoid that message by supplying --quiet. > - Changelog is currently managed automatically by PBR so as soon as there is > a release there will be a change log > - I think #2 can be done along with #3 > > @Kamil: > - The issue is that it’s not possible to release commands in this release > because it will immediately make the CLI incompatible.For 7.0 there is a plan > to get rid of the old CLI completely and replace it with Cliff-based one. I > agree that people may forget the deprecation warning before 7.1 ISO is > available but that is partially solvable by a change log. Besides, > python-fuelclient-7.0 will be available on PyPi much earlier than 7.0 ISO is > released. > - ^ is basically the reason why we cannot use #4, because there will be > nothing new to use, at least in the 6.1 ISO. Keeping both CLIs in the source > tree will create more mess and will be terribly hard to test. > > > - romcheg > > > 4 бер. 2015 о 10:11 Kamil Sambor <ksam...@mirantis.com> написав(ла): > > > > Hi all, > > > > IMHO deprecation warning should be added only to commands that we recently > > changed (because users can switch to new interface when they see > > deprecation error) or eventually solution #2 sounds ok but is not ideal > > because people can forget about warning that they saw in previous release. > > Also we discuss 4th solution, simply we should inform users about > > deprecation of client and encourage users to use fuel_v2 client with new > > commands and parameters. > > > > Best regards, > > Kamil Sambor > > > > On Wed, Mar 4, 2015 at 9:28 AM, Przemyslaw Kaminski > > <pkamin...@mirantis.com> wrote: > > Maybe add a Changelog in the repo and maintain it? > > > > http://keepachangelog.com/ > > > > Option #2 is OK but it can cause pain when testing -- upon each fresh > > installation from ISO we would get that message and it might break some > > tests though that is fixable. Option #3 is OK too. #1 is worst and I > > wouldn't do it. > > > > Or maybe display that info when showing all the commands (typing 'fuel' > > or 'fuel -h')? We already have a deprecation warning there concerning > > client/config.yaml, it is not very disturbing and shouldn't break any > > currently used automation scripts. > > > > P. > > > > > > On 03/03/2015 03:52 PM, Roman Prykhodchenko wrote: > > > Hi folks! > > > > > > > > > According to the refactoring plan [1] we are going to release the 6.1 > > > version of python-fuelclient which is going to contain recent changes but > > > will keep backwards compatibility with what was before. However, the next > > > major release will bring users the fresh CLI that won’t be compatible > > > with the old one and the new, actually usable IRL API library that also > > > will be different. > > > > > > The issue this message is about is the fact that there is a strong need > > > to let both CLI and API users about those changes. At the moment I can > > > see 3 ways of resolving it: > > > > > > 1. Show deprecation warning for commands and parameters which are going > > > to be different. Log deprecation warnings for deprecated library methods. > > > The problem with this approach is that the structure of both CLI and the > > > library will be changed, so deprecation warning will be raised for mostly > > > every command for the whole release cycle. That does not look very user > > > friendly, because users will have to run all commands with --quiet for > > > the whole release cycle to mute deprecation warnings. > > > > > > 2. Show the list o the deprecated stuff and planned changes on the first > > > run. Then mute it. > > > The disadvantage of this approach if that there is a need of storing the > > > info about the first run to a file. However, it may be cleaned after the > > > upgrade. > > > > > > 3. The same as #2 but publish the warning online. > > > > > > I personally prefer #2, but I’d like to get more opinions on this topic. > > > > > > > > > References: > > > > > > 1. https://blueprints.launchpad.net/fuel/+spec/re-thinking-fuel-client > > > > > > > > > - romcheg > > > > > > > > > > > > __________________________________________________________________________ > > > 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 > > > __________________________________________________________________________ > 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
signature.asc
Description: Message signed with OpenPGP using GPGMail
__________________________________________________________________________ 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
