<div dir="ltr">Dmitry,<div><br></div><div>>> <span style="font-size:12.8000001907349px">But why to add another interface when there is one already (rest api)?</span><br><div><br></div><div>I'm ok if we decide to use REST API, but of course there is a problem which</div><div>we should solve, like versioning, which is much harder to support, than versioning</div><div>in core-serializers. Also do you have any ideas how it can be implemented?</div><div>You run some code which get the information from api on the master node and</div><div>then sets the information in tasks? Or you are going to run this code on OpenStack</div><div>nodes? As you mentioned in case of tokens, you should get the token right before</div><div>you really need it, because of expiring problem, but in this case you don't</div><div>need any serializers, get required token right in the task.</div><div><br></div><div>>> <span style="font-size:12.8000001907349px">What is your opinion about serializing additional information in plugins code? How it can be done, without exposing db schema?</span></div><div><span style="font-size:12.8000001907349px"><br></span></div><div><span style="font-size:12.8000001907349px">With exposing the data in more abstract way the way it's done right now</span></div><div><span style="font-size:12.8000001907349px">for the current deployment logic.</span></div><span class="im" style="font-size:12.8000001907349px"></span><div><br></div><div>Thanks,</div></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></div>