It looks like most people agree on option C (implement features in fuel and fuel2) and in the meantime we should slowly progress with moving fuel to fuel2.
2015-07-27 16:12 GMT+02:00 Sergii Golovatiuk <sgolovat...@mirantis.com>: > 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 > >
__________________________________________________________________________ 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