<div dir="ltr"><div>It looks like most people agree on option C (implement features in fuel and fuel2) and in the meantime<br>we should slowly progress with moving fuel to fuel2.<br></div></div><div class="gmail_extra"><br><div class="gmail_quote">2015-07-27 16:12 GMT+02:00 Sergii Golovatiuk <span dir="ltr"><<a href="mailto:sgolovatiuk@mirantis.com" target="_blank">sgolovatiuk@mirantis.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div>Hi,<br><br></div>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<br></div></div><div class="gmail_extra"><br clear="all"><div><div><div dir="ltr">--<br>
Best regards,<br>
Sergii Golovatiuk,<br>
Skype #golserge<br>
IRC #holser<br></div></div></div><div><div class="h5">
<br><div class="gmail_quote">On Fri, Jul 24, 2015 at 11:41 AM, Oleg Gelbukh <span dir="ltr"><<a href="mailto:ogelbukh@mirantis.com" target="_blank">ogelbukh@mirantis.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">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'.<div><br></div><div>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.</div><div><br></div><div>--</div><div>Best regards,</div><div>Oleg Gelbukh</div></div><div><div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Jul 24, 2015 at 12:09 PM, Fedor Zhadaev <span dir="ltr"><<a href="mailto:fzhadaev@mirantis.com" target="_blank">fzhadaev@mirantis.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><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"><span>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></span><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>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><span><span><br>
On Fri, Jul 24, 2015 at 10:58 AM, Evgeniy L <<a href="mailto:eli@mirantis.com" target="_blank">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></span>> <<a href="mailto:skalinowski@mirantis.com" target="_blank">skalinowski@mirantis.com</a>> wrote:<span><br>
<span>>><br>
>> 2015-07-23 18:28 GMT+02:00 Stanislaw Bogatkin <<a href="mailto:sbogatkin@mirantis.com" target="_blank">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><span><span>>>> On Thu, Jul 23, 2015 at 9:19 AM, Evgeniy L <<a href="mailto:eli@mirantis.com" target="_blank">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></span>
>> [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><span><br>
<span>>><br>
>><br>
>>>><br>
>>>><br>
>>>> Thanks,<br>
>>>><br>
>>>> On Thu, Jul 23, 2015 at 1:51 PM, Sebastian Kalinowski<br>
</span></span><div><div><div><div>>>>> <<a href="mailto:skalinowski@mirantis.com" target="_blank">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></div></div>
>>>>> [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><span>>>>>> __________________________________________________________________________<br>
>>>>> OpenStack Development Mailing List (not for usage questions)<br>
>>>>> Unsubscribe:<br>
</span></span><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><span>>>>>> <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><span><br>
>>>>><br>
>>>><br>
>>>><br>
>>>><br>
>>>> __________________________________________________________________________<br>
>>>> OpenStack Development Mailing List (not for usage questions)<br>
>>>> Unsubscribe:<br>
</span></span><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><span>>>>> <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><span><br>
>>>><br>
>>><br>
>>><br>
>>><br>
>>> __________________________________________________________________________<br>
>>> OpenStack Development Mailing List (not for usage questions)<br>
>>> Unsubscribe:<br>
</span></span><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><span>>>> <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><span><br>
>>><br>
>><br>
>><br>
>> __________________________________________________________________________<br>
>> OpenStack Development Mailing List (not for usage questions)<br>
</span></span><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><span>>> <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><span><br>
>><br>
><br>
><br>
> __________________________________________________________________________<br>
> OpenStack Development Mailing List (not for usage questions)<br>
</span></span><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><span>> <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><span><br>
><br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
</span></span><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>
</span></blockquote></div><span><font color="#888888"><br><br clear="all"><div><br></div>-- <br><div><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>
</font></span></div>
<br>__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
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>
<br></blockquote></div><br></div>
</div></div><br>__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
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>
<br></blockquote></div><br></div></div></div>
<br>__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
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>
<br></blockquote></div><br></div>