Hi, can we just add all needed functionality from old fuel client that fuel2 needs, then say that old fuel-client is deprecated now and will not support some new features, then add new features to fuel2 only? It seems like best way for me, cause with this approach: 1. Clients will can use only one version of client (new one) w/o switching between 2 clients with different syntax 2. We won't have to add new features to two clients.
On Thu, Jul 23, 2015 at 9:19 AM, Evgeniy L <e...@mirantis.com> wrote: > Hi, > > The best option is to add new functionality to fuel2 only, but I > don't think that we can do that if there is not enough functionality > in fuel2, we should not ask user to switch between fuel and fuel2 > to get some specific functionality. > Do we have some list of commands which is not covered in fuel2? > I'm just wondering how much time will it take to implement all > required commands in fuel2. > > Thanks, > > On Thu, Jul 23, 2015 at 1:51 PM, Sebastian Kalinowski < > skalinow...@mirantis.com> wrote: > >> Hi folks, >> >> For a some time in python-fuelclient we have two CLI apps: `fuel` and >> `fuel2`. It was done as an implementation of blueprint [1]. >> Right now there is a situation where some new features are added just to >> old `fuel`, some to just `fuel2`, some to both. We cannot simply switch >> completely to new `fuel2` as it doesn't cover all old commands. >> As far as I remember there was no agreement how we should proceed with >> adding new things to python-fuelclient, so to keep all development for new >> commands I would like us to choose what will be our approach. There are 3 >> ways to do it (with some pros and cons): >> >> A) Add new features only to old `fuel`. >> Pros: >> - Implement feature in one place >> - Almost all features are covered there >> Cons: >> - Someone will need to port this features to new `fuel2` >> - Issues that forced us to reimplement whole `fuel` as `fuel2` >> >> B) Add new features only to new `fuel2` >> Pros: >> - Implement feature in one place >> - No need to cope with issues in old `fuel` (like worse UX, etc.) >> Cons: >> - Not all features are covered by `fuel2` so user will need to switch >> between `fuel` and `fuel2` >> >> C) Add new features to both CLIs >> Pros: >> - User can choose which tool to use >> - No need to port feature later... >> Cons: >> - ...but it still doubles the work >> - We keep alive a tool that should be replaced (old `fuel`) >> >> >> Best, >> Sebastian >> >> [1] https://blueprints.launchpad.net/fuel/+spec/re-thinking-fuel-client >> >> __________________________________________________________________________ >> 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
