Open Stack

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 <ksambor at 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 <me at 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 <ksambor at 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 <pkaminski at 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-request at 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-request at 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-request at 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-request at 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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150306/9dc8fa84/attachment.pgp>