<div dir="ltr">Hi Dmitry!<div><br></div><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><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><div><br></div><div>Thanks,</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jan 28, 2015 at 2:45 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=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><br></div><div>It's not clear what problem you are going to solve with putting serializers</div><div>alongside with deployment scripts/tasks.</div></blockquote></span><div>I see two possible uses for specific serializer for tasks:</div><div>1. Compute additional information for deployment based not only on what is present in astute.yaml</div><div>2. Request information from external sources based on values stored in fuel inventory (like some token based on credentials)</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>For sure there is no way for this serializers to have access to the database,</div><div>because with each release there will be a huge probability to get this</div><div>serializers broken for example because of changes in database schema.</div><div>As Dmitry mentioned in this case solution is to create another layer</div><div>which provides stable external interface to the data.</div><div>We already to have this interface where we support versioning and backward</div><div>compatibility, in terms of deployment script it's astute.yaml file.</div></blockquote></span><div>That is the problem, it is impossible to cover everything by astute.yaml.</div><div>We need to think on a way to present all data available in nailgun as deployment configuration</div><div><br></div></div><br><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>