<div dir="ltr"><div>Hi Dmitry,</div><div><br></div><div>I've read about inventories and I'm not sure if it's what we really need,</div><div>inventory provides you a way to have some kind of nodes discovery</div><div>mechanism, but what we need is to get some abstract data and convert</div><div>the data to more tasks friendly format.</div><div><br></div><div>In another thread I've mentioned Variables [1] in Ansible, probably it</div><div>fits more than inventory from architecture point of view.</div><div><br></div><div>With this functionality plugin will be able to get required information from</div><div>Nailgun via REST API and pass the information into specific task.</div><div><br></div><div>But it's not a way to go with the core deployment. I would like to remind</div><div>you what we had two years ago, we had Nailgun which passed the information</div><div>in format A to Orchestrator (Astute), than Orchestrator converted the information</div><div>in second format B. It was horrible from debugging point of view, it's always</div><div>hard when you have to go in several places to figure out what you get</div><div>as result. Your have pretty similar design suggestion, which is dividing </div><div>searilization logic between Nailgun and some another layer in tasks</div><div>scripts.</div><div><br></div><div>Thanks,</div><div><br></div><div>[1] <a href="http://docs.ansible.com/playbooks_variables.html#registered-variables">http://docs.ansible.com/playbooks_variables.html#registered-variables</a></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Feb 2, 2015 at 5:05 PM, 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:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span>>> <span style="font-size:12.8000001907349px">But why to add another interface when there is one already (rest api)?</span><br><div><br></div></span><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></blockquote><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"><span><div></div></span></blockquote><div><br></div></span><div>We need to think about deployment serializers not as part of nailgun (fuel data inventory), but - part of another layer which uses nailgun api to</div><div>generate deployment information. Lets take ansible for example, and dynamic inventory feature [1].</div><div>Nailgun API can be used inside of ansible dynamic inventory to generate config that will be consumed by ansible during deployment.</div><div><br></div><div>Such approach will have several benefits:</div><div>- cleaner interface (ability to use ansible as main interface to control deployment and all its features)</div><div>- deployment configuration will be tightly coupled with deployment code</div><div>- no limitation on what sources to use for configuration, and how to compute additional values from requested data</div><div><br></div><div>I want to emphasize that i am not considering ansible as solution for fuel, it serves only as example of architecture.</div><span class=""><div> <br></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"><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></blockquote><div> </div></div></span><div>I think all information should be fetched before deployment. </div><span class=""><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"><span><div> </div></span></blockquote><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"><span><div></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></span><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></blockquote><div> </div></span><div>I mean what if plugin will want to generate additional data, like - <a href="https://review.openstack.org/#/c/150782/" target="_blank">https://review.openstack.org/#/c/150782/</a>? Schema will be still exposed?</div></div><div class="gmail_extra"><br></div>[1] <a href="http://docs.ansible.com/intro_dynamic_inventory.html" target="_blank">http://docs.ansible.com/intro_dynamic_inventory.html</a></div><div class="gmail_extra"><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" 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>