Open Stack

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