Open Stack

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