<div dir="ltr"><div>Hi all,</div><div><br></div><div>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.</div></div><div class="gmail_extra"><br><div class="gmail_quote">2015-07-24 11:58 GMT+03:00 Igor Kalnitsky <span dir="ltr"><<a href="mailto:ikalnitsky@mirantis.com" target="_blank">ikalnitsky@mirantis.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hello,<br>
<br>
My 2 cents on it.<br>
<br>
Following plan C requires a huge effort from developer, and it may be<br>
unacceptable when FF is close and there're a lot of work to do. So it<br>
looks like the plan B is most convenient for us and eventually we will<br>
have all features in fuel2.<br>
<br>
Alternatively we can go with C.. but only if implementing support in<br>
either fuel or fuel2 may be postponed to SCF.<br>
<br>
Thanks,<br>
Igor<br>
<span class=""><br>
On Fri, Jul 24, 2015 at 10:58 AM, Evgeniy L <<a href="mailto:eli@mirantis.com">eli@mirantis.com</a>> wrote:<br>
> Hi Sebastian, thanks for clarification, in this case I think we<br>
> should follow plan C, new features should not slow us down<br>
> in migration from old to new version of the client.<br>
><br>
> On Thu, Jul 23, 2015 at 8:52 PM, Sebastian Kalinowski<br>
</span>> <<a href="mailto:skalinowski@mirantis.com">skalinowski@mirantis.com</a>> wrote:<br>
<span class="">>><br>
>> 2015-07-23 18:28 GMT+02:00 Stanislaw Bogatkin <<a href="mailto:sbogatkin@mirantis.com">sbogatkin@mirantis.com</a>>:<br>
>>><br>
>>> Hi,<br>
>>><br>
>>> can we just add all needed functionality from old fuel client that fuel2<br>
>>> needs, then say that old fuel-client is deprecated now and will not support<br>
>>> some new features, then add new features to fuel2 only? It seems like best<br>
>>> way for me, cause with this approach:<br>
>>> 1. Clients will can use only one version of client (new one) w/o<br>
>>> switching between 2 clients with different syntax<br>
>>> 2. We won't have to add new features to two clients.<br>
>><br>
>><br>
>> Stas, of course moving it all to new fuel2 would be the best way to do it,<br>
>> but this refactoring took place in previous release. There is no one that<br>
>> ported a single command (except new ones) since then and there is no plan<br>
>> for doing so since other activities have higher priority. And features are<br>
>> still coming so it would be nice to have a policy for the time all commands<br>
>> will move to new fuel2.<br>
>><br>
>>><br>
>>><br>
</span><span class="">>>> On Thu, Jul 23, 2015 at 9:19 AM, Evgeniy L <<a href="mailto:eli@mirantis.com">eli@mirantis.com</a>> wrote:<br>
>>>><br>
>>>> Hi,<br>
>>>><br>
>>>> The best option is to add new functionality to fuel2 only, but I<br>
>>>> don't think that we can do that if there is not enough functionality<br>
>>>> in fuel2, we should not ask user to switch between fuel and fuel2<br>
>>>> to get some specific functionality.<br>
>>>> Do we have some list of commands which is not covered in fuel2?<br>
>>>> I'm just wondering how much time will it take to implement all<br>
>>>> required commands in fuel2.<br>
>><br>
>><br>
>> So to compare: this is a help message for "old" fuel [1] and "new" fuel2<br>
>> [2]. There are only "node", "env" and "task" actions covered and even they<br>
>> are not covered in 100%.<br>
>><br>
>> [1] <a href="http://paste.openstack.org/show/404439/" rel="noreferrer" target="_blank">http://paste.openstack.org/show/404439/</a><br>
</span>>> [2] <a href="http://paste.openstack.org/show/404440/" rel="noreferrer" target="_blank">http://paste.openstack.org/show/404440/</a><br>
<span class="">>><br>
>><br>
>>>><br>
>>>><br>
>>>> Thanks,<br>
>>>><br>
>>>> On Thu, Jul 23, 2015 at 1:51 PM, Sebastian Kalinowski<br>
</span><div><div class="h5">>>>> <<a href="mailto:skalinowski@mirantis.com">skalinowski@mirantis.com</a>> wrote:<br>
>>>>><br>
>>>>> Hi folks,<br>
>>>>><br>
>>>>> For a some time in python-fuelclient we have two CLI apps: `fuel` and<br>
>>>>> `fuel2`. It was done as an implementation of blueprint [1].<br>
>>>>> Right now there is a situation where some new features are added just<br>
>>>>> to old `fuel`, some to just `fuel2`, some to both. We cannot simply switch<br>
>>>>> completely to new `fuel2` as it doesn't cover all old commands.<br>
>>>>> As far as I remember there was no agreement how we should proceed with<br>
>>>>> adding new things to python-fuelclient, so to keep all development for new<br>
>>>>> commands I would like us to choose what will be our approach. There are 3<br>
>>>>> ways to do it (with some pros and cons):<br>
>>>>><br>
>>>>> A) Add new features only to old `fuel`.<br>
>>>>> Pros:<br>
>>>>> - Implement feature in one place<br>
>>>>> - Almost all features are covered there<br>
>>>>> Cons:<br>
>>>>> - Someone will need to port this features to new `fuel2`<br>
>>>>> - Issues that forced us to reimplement whole `fuel` as `fuel2`<br>
>>>>><br>
>>>>> B) Add new features only to new `fuel2`<br>
>>>>> Pros:<br>
>>>>> - Implement feature in one place<br>
>>>>> - No need to cope with issues in old `fuel` (like worse UX, etc.)<br>
>>>>> Cons:<br>
>>>>> - Not all features are covered by `fuel2` so user will need to switch<br>
>>>>> between `fuel` and `fuel2`<br>
>>>>><br>
>>>>> C) Add new features to both CLIs<br>
>>>>> Pros:<br>
>>>>> - User can choose which tool to use<br>
>>>>> - No need to port feature later...<br>
>>>>> Cons:<br>
>>>>> - ...but it still doubles the work<br>
>>>>> - We keep alive a tool that should be replaced (old `fuel`)<br>
>>>>><br>
>>>>><br>
>>>>> Best,<br>
>>>>> Sebastian<br>
>>>>><br>
>>>>> [1] <a href="https://blueprints.launchpad.net/fuel/+spec/re-thinking-fuel-client" rel="noreferrer" target="_blank">https://blueprints.launchpad.net/fuel/+spec/re-thinking-fuel-client</a><br>
>>>>><br>
>>>>><br>
</div></div><span class="">>>>>> __________________________________________________________________________<br>
>>>>> OpenStack Development Mailing List (not for usage questions)<br>
>>>>> Unsubscribe:<br>
</span>>>>>> <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<span class="">>>>>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
>>>>><br>
>>>><br>
>>>><br>
>>>><br>
>>>> __________________________________________________________________________<br>
>>>> OpenStack Development Mailing List (not for usage questions)<br>
>>>> Unsubscribe:<br>
</span>>>>> <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<span class="">>>>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
>>>><br>
>>><br>
>>><br>
>>><br>
>>> __________________________________________________________________________<br>
>>> OpenStack Development Mailing List (not for usage questions)<br>
>>> Unsubscribe:<br>
</span>>>> <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<span class="">>>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
>>><br>
>><br>
>><br>
>> __________________________________________________________________________<br>
>> OpenStack Development Mailing List (not for usage questions)<br>
</span>>> Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<span class="">>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
>><br>
><br>
><br>
> __________________________________________________________________________<br>
> OpenStack Development Mailing List (not for usage questions)<br>
</span>> Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<span class="">> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
><br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
</span>Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature"><div dir="ltr"><div>Kind Regards,</div><div>Fedor Zhadaev</div><div>Junior Software Engineer, Mirantis Inc.</div><div>Skype: zhadaevfm</div><div>E-mail: <a href="mailto:fzhadaev@mirantis.com" target="_blank">fzhadaev@mirantis.com</a></div></div></div>
</div>