<div dir="ltr"><span class="im" style="font-size:12.8000001907349px"><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 dir="ltr"><div><br></div><div> Each task can use some code to transform this output to the representation that is actually needed for this particular task. Whenever a task transforms this data it can access API and do version negotiation, for example. Each time this transformation is performed this task can return the data to some storage that will save this data for sake of control and troubleshooting, such as, for example, user can always see which changes are going to be applied and decide what to do next. </div><div><br></div><div>Also, this means that the process of data calculation itself is very 'lazy' or 'delayed', i. e. the data itself is calculated right at the beginning of deployment transaction, so that it is not locked to some particular details of deployment engine data processing and not prone to issues like 'oh, I cannot get VIP because it has not been allocated yet by Nailgun/oh, I cannot set it because it has already been set by Nailgun and there is no way to alter it'.</div></div></blockquote><div><br></div></span><div style="font-size:12.8000001907349px">>> To me, the two paragraphs above a contradictory. If the data calculations are lazy, I don't really see how one can introspect into changes that will be applied by a component at any given run. You just >> don't have this information, and you need to calculate it anyways to see which settings will be passed to a component. Might be I got your point wrong here. Please correct me if this is the case.</div><div style="font-size:12.8000001907349px"><br></div><div style="font-size:12.8000001907349px">Oleg, I actually meant that we do it in the following stages:</div><div style="font-size:12.8000001907349px"><br></div><div style="font-size:12.8000001907349px">1) Change stuff in any amount of business logic engines you want, configuration databases, wikipedia, 4chan, etc.</div><div style="font-size:12.8000001907349px">2) Schedule a transaction of deployment</div><div style="font-size:12.8000001907349px">3) Make 'transformers/serializers' for each of the task collect all the data and store them before execution is started</div><div style="font-size:12.8000001907349px">4) Allow user to compare differences and decide whether he actually wants to apply this change</div><div style="font-size:12.8000001907349px"><span style="font-size:12.8000001907349px">5) Commit the deployment - run particular tasks with particular set of settings which are staged and frozen (otherwise it will be impossible to  debug this stuff)</span></div><div style="font-size:12.8000001907349px">6) If there is lack of data for some task, e.g. you need some entitties to be created during the deployment so that other task will use their output or side-effects to calculate things - this task should not be executed within this transaction. This means that the whole deployment should be splitted into 2 transactions. I can mention an old story here - when we were running puppet we needed to create some stuff for neutron knowing ID of the network that had been created by another resource 5 seconds earlier. But we could not do this because puppet 'freezes' the input provided with "facts" before this transaction runs. This is exactly the same usecase.</div><div style="font-size:12.8000001907349px"><br></div><div style="font-size:12.8000001907349px">So these 6 items actually mean:</div><div style="font-size:12.8000001907349px"><br></div><div style="font-size:12.8000001907349px">1) Clear separation between layers of the system and their functional boundaries</div><div style="font-size:12.8000001907349px">2) Minimum of cross-dependencies between component data - e.g. deployment tasks should not ever produce anything that is then stored in the storage. Instead, you should have an API that provides you with data which is the result of deployment run. E.g. if you need to create a user in LDAP and you need this user's ID for some reason, your deployment task should create this user and, instead of returning this output to the storage, you just run another transaction and the task that requires this ID fetches it from LDAP.</div><div style="font-size:12.8000001907349px"><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Oct 22, 2015 at 1:25 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"><div><br></div><div>Hi Oleg,</div><div><br></div><div>I want to mention that we are using similar approach for deployment engine, the difference is that we are working not with components, but with deployment objects (it could be resources or tasks).</div><div>Right now all the data should be provided by user, but we are going to add concept of managed resource, so that resource will be able to request data from 3rd party service before execution, or by notification, if it is supported.</div><div>I think this is similar to what Vladimir describes.</div><div><br></div><div>As for the components - i see how it can be useful, for example provisioning service will require data from networking service, but i think nailgun can act as router for such cases.</div><div>This way we will keep components simple and purely functional, and nailgun will perform a role of a client which knows how to build interaction between components.</div><div><br></div><div>So, as a summary i think this is 2 different problems.</div><div><br></div><div><br></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" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" 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"><div><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>35bk3, 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></div>
</div>