<div dir="ltr">Guys<div><br></div><div>I would just like to point out that we will certainly need to consume resources from 3rd party sources also. We also want to remove any specific data manipulation from puppet code. Please, consider these use cases also.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jan 29, 2015 at 12:06 AM, Dmitriy Shulyak <span dir="ltr"><<a href="mailto:dshulyak@mirantis.com" target="_blank">dshulyak@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 class="gmail_extra"><div class="gmail_quote"><span class=""><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>1. as I mentioned above, we should have an interface, and if interface doesn't</div><div>    provide required information, you will have to fix it in two places,</div><div>    in Nailgun and in external-serializers, instead of a single place i.e. in Nailgun,</div><div>    another thing if astute.yaml is a bad interface and we should provide another</div><div>    versioned interface, or add more data into deployment serializer.</div></blockquote></span><div>But why to add another interface when there is one already (rest api)? And plugin developer</div><div>may query whatever he want (detailed information about volumes, interfaces, master node settings).</div><div>It is most full source of information in fuel and it is already needs to be protected from incompatible changes.</div><div><br></div><div>If our API will be not enough for general use - ofcourse we will need to fix it, but i dont quite understand what do</div><div>you mean by - fix it in two places. API provides general information that can be consumed by serializers (or any other service/human actually),</div><div>and if there is some issues with that information - API should be fixed. Serializers expects that information in specific format and makes</div><div>additional transformation or computation based on that info.</div><div><br></div><div>What is your opinion about serializing additional information in plugins code? How it can be done, without exposing db schema?</div><span class=""><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>2. it can be handled in python or any other code (which can be wrapped into tasks),</div><div>    why should we implement here another entity (a.k.a external serializers)?</div></blockquote></span></div>Yep, i guess this is true, i thought that we may not want to deliver credentials to the target nodes, and only token that can be used</div><div class="gmail_extra">for limited time, but...</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" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature"><div dir="ltr">Yours Faithfully,<br>Vladimir Kuklin,<br>Fuel Library Tech Lead,<br>Mirantis, Inc.<br>+7 (495) 640-49-04<br>+7 (926) 702-39-68<br>Skype kuklinvv<br>45bk3, Vorontsovskaya Str.<br>Moscow, Russia,<br><a href="http://www.mirantis.ru/" target="_blank">www.mirantis.com</a><br><a href="http://www.mirantis.ru/" target="_blank">www.mirantis.ru</a><br><a href="mailto:vkuklin@mirantis.com" target="_blank">vkuklin@mirantis.com</a></div></div>
</div>