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 :
> Hi,
>
> Every functionality should be applied to both clients. Core developers
> should set
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
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 'f
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 :
> Hello,
>
> My 2 cen
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..
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 <
skalinow...@mirantis.com> wrote:
> 2015-07-23 18:28 GMT+02:00 Stan
2015-07-23 18:28 GMT+02:00 Stanislaw Bogatkin :
> 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
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
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 f
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
10 matches
Mail list logo
