<div dir="ltr">Hi,<div><br></div><div>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:</div><div>1. Clients will can use only one version of client (new one) w/o switching between 2 clients with different syntax</div><div>2. We won't have to add new features to two clients.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jul 23, 2015 at 9:19 AM, Evgeniy L <span dir="ltr"><<a href="mailto:eli@mirantis.com" target="_blank">eli@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">Hi,<div><br></div><div>The best option is to add new functionality to fuel2 only, but I</div><div>don't think that we can do that if there is not enough functionality</div><div>in fuel2, we should not ask user to switch between fuel and fuel2</div><div>to get some specific functionality.</div><div>Do we have some list of commands which is not covered in fuel2?</div><div>I'm just wondering how much time will it take to implement all</div><div>required commands in fuel2.</div><div><br></div><div>Thanks,</div></div><div class="gmail_extra"><br><div class="gmail_quote"><div><div class="h5">On Thu, Jul 23, 2015 at 1:51 PM, Sebastian Kalinowski <span dir="ltr"><<a href="mailto:skalinowski@mirantis.com" target="_blank">skalinowski@mirantis.com</a>></span> wrote:<br></div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="h5"><div dir="ltr"><div><div><div><div><div><div><div><div><div><div><div><div><div><div>Hi folks,<br><br></div>For a some time in python-fuelclient we have two CLI apps: `fuel` and `fuel2`. It was done as an implementation of blueprint [1].<br></div>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.<br></div>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):<br><br></div>A) Add new features only to old `fuel`.<br></div>Pros:<br></div> - Implement feature in one place<br></div> - Almost all features are covered there<br></div>Cons:<br></div> - Someone will need to port this features to new `fuel2`<br></div> - Issues that forced us to reimplement whole `fuel` as `fuel2`<br><br></div>B) Add new features only to new `fuel2`<br></div>Pros:<br></div><div> - Implement feature in one place<br></div> - No need to cope with issues in old `fuel` (like worse UX, etc.)<br></div><div>Cons:<br></div><div> - Not all features are covered by `fuel2` so user will need to switch between `fuel` and `fuel2`<br><br></div><div>C) Add new features to both CLIs<br></div><div>Pros:<br></div><div> - User can choose which tool to use<br></div><div> - No need to port feature later...<br></div><div>Cons:<br></div><div> - ...but it still doubles the work<br></div><div> - We keep alive a tool that should be replaced (old `fuel`)<br></div><div><div><div><div><div><div><div><div><div><div><div><div><div><div><br></div><div><br>Best,<br>Sebastian<br><br>[1] <a href="https://blueprints.launchpad.net/fuel/+spec/re-thinking-fuel-client" target="_blank">https://blueprints.launchpad.net/fuel/+spec/re-thinking-fuel-client</a><br></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div>
<br></div></div>__________________________________________________________________________<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>
<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>