Hi Sebastian, thanks for clarification, in this case I think we should follow plan C, new features should not slow us down in migration from old to new version of the client.
On Thu, Jul 23, 2015 at 8:52 PM, Sebastian Kalinowski < skalinow...@mirantis.com> wrote: > 2015-07-23 18:28 GMT+02:00 Stanislaw Bogatkin <sbogat...@mirantis.com>: > >> 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. >> > > Stas, of course moving it all to new fuel2 would be the best way to do it, > but this refactoring took place in previous release. There is no one that > ported a single command (except new ones) since then and there is no plan > for doing so since other activities have higher priority. And features are > still coming so it would be nice to have a policy for the time all commands > will move to new fuel2. > > >> >> 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. >>> >> > So to compare: this is a help message for "old" fuel [1] and "new" fuel2 > [2]. There are only "node", "env" and "task" actions covered and even they > are not covered in 100%. > > [1] http://paste.openstack.org/show/404439/ > [2] http://paste.openstack.org/show/404440/ > > > >> >>> 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 >> >> > > __________________________________________________________________________ > 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