<div dir="ltr">Recently we had some cool work done regarding decoupling repositories from fuel-web. I think it would be really good to have Fuel UI in separate repository. +1 to the idea.</div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Nov 23, 2015 at 4:56 PM, Roman Prykhodchenko <span dir="ltr"><<a href="mailto:me@romcheg.me" target="_blank">me@romcheg.me</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word">Folks.<div><br></div><div>This happened again. Nailgun’s API was silently changed [1] breaking python-fuelclient and everything else that was relying on it.</div><div><br></div><div>I feel like this is the point when just discussing the issue is not enough so I call for a vote: Let’s separate Nailgun from Fuel UI and put them into different repositories now.</div><div><br></div><div>Please cast your votes (either +1 or -1) to this thread. You can also provide your reasoning and more thoughts.</div><div><br></div><div><br></div><div>- romcheg</div><div><br></div><div><br></div><div>1. <a href="https://review.openstack.org/#/c/240234/" target="_blank">https://review.openstack.org/#/c/240234/</a></div><div><br><div><blockquote type="cite"><div>26 жовт. 2015 р. о 11:11 Sebastian Kalinowski <<a href="mailto:skalinowski@mirantis.com" target="_blank">skalinowski@mirantis.com</a>> написав(ла):</div><div><div class="h5"><br><div><div dir="ltr" style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">2015-10-23 11:36 GMT+02:00 Igor Kalnitsky<span> </span><span dir="ltr"><<a href="mailto:ikalnitsky@mirantis.com" target="_blank">ikalnitsky@mirantis.com</a>></span>:<br><div><div><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Roman, Vitaly,<br><br>You're both saying right things, and you guys bring a sore topic up again.<br><br>The thing is that Nailgun's API isn't the best one.. but we're trying<br>to improve it step-by-step, from release to release. We have so many<br>things to reconsider and to fix that it'd require a huge effort to<br>make backward compatible changes and support it. So we decided ignore<br>backward compatibility for clients for awhile and consider our API as<br>unstable.<br><br>I agree with Roman that such changes must not be made secretly, and we<br>should at least announce about them. Moreover, every core must think<br>about consequences before approving them.<br><br>So I propose to do the following things when backward incompatible<br>change to API is required:<br><br>* Announce this change in openstack-dev ML.<br>* Wait 1 week before approving it, so anyone can prepare.<br>* Change author has to work with QA in order make sure they are<br>prepared for this change.<br><br>Any thoughts?<br></blockquote><div><br><br></div><div>+1.<br><br>Although there is one thing that you didn't mention (but probably everyone know about it)<br></div><div>is to solve the issue with fuelclient not beign tested against changes in nailgun.<br></div><div>We need not only run it for every change in nailgun (or for only those that touch files under "api"<br></div><div>dir) but also cover more endpoints with fuelclient tests against real API, not mocks, to discover<br></div><div>such issues earlier.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><br>Thanks,<br>Igor<br><div><div><br>On Wed, Oct 21, 2015 at 5:24 PM, Vitaly Kramskikh<br><<a href="mailto:vkramskikh@mirantis.com" target="_blank">vkramskikh@mirantis.com</a>> wrote:<br>> JFYI: (re-)start of this discussion was instigated by merge of this change<br>> (and here is revert).<br>><br>> And this is actually not the first time when we make backward incompatible<br>> changes in our API. AFAIR, the last time it was also about the network<br>> configuration handler. We decided not to consider our API frozen, make the<br>> changes and break backward compatibility. So now is the time to reconsider<br>> this.<br>><br>> API backward compatibility is a must for good software, but we also need to<br>> understand that introducing API versioning is not that easy and will<br>> increase efforts needed to make new changes in nailgun.<br>><br>> I'd go this way:<br>><br>> Estimate the priority of introducing API versioning - maybe we have other<br>> things we should invest our resources to<br>> Estimate all the disadvantages this decision might have<br>> Fix all the issues in the current API (like this one)<br>> Implement API versioning support (yes, we don't have this mechanism yet, so<br>> we can't just "bump API version" like Sergii suggested in another thread)<br>> Consider the current API as frozen v1, so backward incompatible changes (or<br>> maybe all the changes?) should go to v2<br>><br>><br>> 2015-10-21 20:25 GMT+07:00 Roman Prykhodchenko <<a href="mailto:me@romcheg.me" target="_blank">me@romcheg.me</a>>:<br>>><br>>> Hi folks,<br>>><br>>> I’d like to touch the aspect of Fuel development process that seems to be<br>>> as wrong as possible. That aspect is how we change the API.<br>>><br>>> The issue is that in Fuel anyone can change API at any point of time<br>>> without even warning the rest of the same component’s team. Relying on this<br>>> kind of API is basically impossible. We constantly have problems when even<br>>> components of Fuel stop working due to unexpected changes in the API.<br>>> Thinking about another software that must be integrated with Fuel is hardly<br>>> possible with the current approach.<br>>><br>>> As for a grown-up project there is a strong need for Fuel in general and<br>>> for Nailgun in particular to work on a policy for making changes to their<br>>> APIs. Living in OpenStack ecosystem we must at least take a look how it’s<br>>> done in its components and try to do something similar. After working with<br>>> Nova, Keystone, Ironic and other components I would propose to start with<br>>> the following: let’s not make any changes to the API. Instead, let’s create<br>>> a new version of Nailgun’s API that will appear in Fuel 8.0 and make all the<br>>> changes there. That is the thing that will instantaneously make lives of<br>>> other components much easier, if we make it now.<br>>><br>>> After doing the essential part let’s think about how we are going to live<br>>> with that in the future. There are several APIs in Fuel, the rest of the<br>>> email is only touching Nailgun’s REST API. I can see the things somehow like<br>>> the following:<br>>><br>>>  - Introduce API documentation by embedding Swagger and Swagger UI.<br>>>    The current approach when we leave API docs for documentation team is<br>>> not effective. Swagger generates the documentation and resolves this issue.<br>>>  - After releasing a version of Fuel, it’s API is called stable and frozen<br>>> for any changes, unless they allign API to the documentation or<br>>> documentation to the API.<br>>>  - All changes to a stable APIs must be backported to the stable version<br>>> of Fuel that introduced the corresponding API.<br>>>  - In order to guarantee that a stable API is not changed, Jenkins jobs<br>>> should make automatic checks for every new patch set<br>>><br>>> Details about all the above mentioned proposals can be discussed in<br>>> separate threads so this one will stay uncluttered. I'd like to also summon<br>>> those OpenStack folks, who tried to resolve the same issue and ask them<br>>> about any common solutions in the ecosystem.<br>>><br>>><br>>> - romcheg<br>>><br>>><br>>><br>>><br>>><br>>> __________________________________________________________________________<br>>> OpenStack Development Mailing List (not for usage questions)<br>>> Unsubscribe:<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><br>>><br>><br>><br>><br>> --<br>> Vitaly Kramskikh,<br>> Fuel UI Tech Lead,<br>> Mirantis, Inc.<br>><br>> __________________________________________________________________________<br>> OpenStack Development Mailing List (not for usage questions)<br>> Unsubscribe:<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><br>><br><br>__________________________________________________________________________<br>OpenStack Development Mailing List (not for usage questions)<br>Unsubscribe:<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><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></div></div></blockquote></div><br></div></div></div></div><span style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;float:none;display:inline!important">__________________________________________________________________________</span><br style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><span style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;float:none;display:inline!important">OpenStack Development Mailing List (not for usage questions)</span><br style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><span style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;float:none;display:inline!important">Unsubscribe:<span> </span></span><a href="mailto:OpenStack-dev-request@lists.openstack.org" style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" target="_blank">OpenStack-dev-request@lists.openstack.org</a><span style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;float:none;display:inline!important">?subject:unsubscribe</span><br style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a></div></div></div></blockquote></div><br></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>