Open Stack

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 <ikalnitsky at 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 <eli at 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
> > <skalinowski at mirantis.com> wrote:
> >>
> >> 2015-07-23 18:28 GMT+02:00 Stanislaw Bogatkin <sbogatkin at 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 <eli at 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
> >>>> <skalinowski at 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-request at 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-request at 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-request at 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-request at 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-request at 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-request at 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: fzhadaev at mirantis.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150724/e9d817d5/attachment.html>