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
