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