Open Stack

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 <sgolovatiuk at 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 <ogelbukh at 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 <fzhadaev at 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 <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
>>>
>>>
>>> __________________________________________________________________________
>>> 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/20150728/26dc6432/attachment.html>