Hi, Every functionality should be applied to both clients. Core developers should set -1 if it's not applied to second version of plugin. Though I believe we should completely get rid of first version of CLI in Fuel 8.0
-- Best regards, Sergii Golovatiuk, Skype #golserge IRC #holser On Fri, Jul 24, 2015 at 11:41 AM, Oleg Gelbukh <ogelb...@mirantis.com> wrote: > FWIW, I'm for option B, combined with clear timeline for porting features > of fuel-variant to fuel2. For example, we are developing client-side > functions for fuel-octane (cluster upgrade) extensions only for fuel2, and > don't plan to implement it for 'fuel'. > > The main reason why we can't just drop 'fuel', or rather switch it to > fuel2 syntax, IMO, is the possibility that someone somewhere uses its > current syntax for automation. However, if the function is completely new, > the automation of this function should be implemented with the new version > of syntax. > > -- > Best regards, > Oleg Gelbukh > > On Fri, Jul 24, 2015 at 12:09 PM, Fedor Zhadaev <fzhad...@mirantis.com> > wrote: > >> Hi all, >> >> I think that in current situation the best solution will be to add new >> features for the both versions of client. It may cause a little slowing >> down of developing each feature, but we won't have to return to them in >> future. >> >> 2015-07-24 11:58 GMT+03:00 Igor Kalnitsky <ikalnit...@mirantis.com>: >> >>> Hello, >>> >>> My 2 cents on it. >>> >>> Following plan C requires a huge effort from developer, and it may be >>> unacceptable when FF is close and there're a lot of work to do. So it >>> looks like the plan B is most convenient for us and eventually we will >>> have all features in fuel2. >>> >>> Alternatively we can go with C.. but only if implementing support in >>> either fuel or fuel2 may be postponed to SCF. >>> >>> Thanks, >>> Igor >>> >>> On Fri, Jul 24, 2015 at 10:58 AM, Evgeniy L <e...@mirantis.com> wrote: >>> > 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 >>> > >>> >>> >>> __________________________________________________________________________ >>> 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 >>> >> >> >> >> -- >> Kind Regards, >> Fedor Zhadaev >> Junior Software Engineer, Mirantis Inc. >> Skype: zhadaevfm >> E-mail: fzhad...@mirantis.com >> >> __________________________________________________________________________ >> 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
