Open Stack

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.

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.
>
> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150723/fd548893/attachment.html>