<div dir="ltr">Hi, Folks<div><br></div><div><b>* Intro </b></div><div><b><br></b></div><div><div>During Iteration 3 our Enhancements Team as long as other folks worked on the feature called "Task Based Deployment with Astute". Here is a link to its blueprint: <a href="https://blueprints.launchpad.net/fuel/+spec/task-based-deployment-astute">https://blueprints.launchpad.net/fuel/+spec/task-based-deployment-astute</a></div><div><br></div><div>Major implication of this feature complition is that our deployment process will be drastically optimized allowing us to decrease deployment time of typical clusters at least by 2,5 times (for BVT/CI cases) and by order of magnitude for 100-node clusters. </div><div><br></div><div>This is achieved by real parallelization of deployment tasks execution which assumes that we do not wait for the whole 'deployment group/role' to deploy, but we only wait for particular tasks to finish. For example, we could deploy 'database' task on secondary controllers as soon as 'database' task is ready on the first controller. As our deployment workflow consists only of a small amount of such synchronization points as 'database' task, we will be able to deploy majority of deployment tasks in parallel shrinking deployment time to "time-of-deployment-of-the-longest-node". This actually means that our standard deployment case for development and testing will take 30 minutes on our CI servers thus drastically improving developers and users experience, as well as shrinking down time of overall acceptance testing, time for bug reproducing and so on. This feature also allows one to use 7.0 role-as-a-plugin feature in much more effective way as current split-services-with-plugins feature may lead to very inoptimal deployment flow which might take up to <b>6 hours</b> even for the simplest HA cluster, while it would take again <b>30 minutes</b> with <b>Task-Based </b>approach.</div><div>Also, when multi-roles were used we ran several tasks for each role each time it was used, making deployment suboptimal again.<br></div><div><br></div><div><br></div><div><b>* Short List of Work Items</b></div><div><br></div><div><div>As we started a little bit lately during iteration 3 we worked on design and specification of this feature in a way so that its introduction will bring in almost zero chance of regression with ability to disable it. Here is the summary<br></div></div><div><br></div><div>So far we introduce several pieces of code:</div><div>1. New version of tasks format introducing cross-node dependencies between tasks</div><div>2. Changes to Nailgun<br></div><div>  a. deduplication of tasks for roles [In Progress]</div><div>  b. support for new tasks format [In Progress]</div><div>  c. new engine that generates an array of hashes of tasks info consumable by new Astute engine [In Progress]. </div><div>3. Changes to Astute<br></div><div> a. Tasks dependencies parser and visualizer [Ready for review]</div><div> b. Deployment engine capable of graph traversing and reporting [Read for Review]</div><div> c. Async wrapper for shell-based tasks [Ready for review]</div><div>4. Changes to Fuel Library<br></div><div> a. Add additional fields into existing Fuel Library deployment tasks for cross-dependencies [In Progress]. </div><div><br></div><div><b>* Ensurance of Little Regression and Backward Compatibility</b></div><div><br></div><div>As we worked on being backward-compatible from the day one, this engine is enabled ONLY when 2 requirements are met:</div><div><br></div><div>1. It is globally enabled in Nailgun settings.yaml</div><div>2. ALL tasks scheduled for deployment execution have v2.0.0 </div><div><br></div><div>This list seems a little bit huge, but this changes are isolated and granular and actually affect the sequence in which tasks are executed on the nodes. This means that there will be actually no difference from the view of resulting functioning of the cluster. This feature can be safely disabled if user does not want to use it. </div><div><br></div><div>But if user wants to work with it, he can gain enormous improvement in speed, his own engineering/development/testing velocity as well as in Fuel user experience.</div><div><br></div><div><b>* Additional Cons of the Feature</b></div><div><br></div><div>Moreover, this feature improves how the following use cases are also addressed:</div><div><br></div><div><b>1. When user deploys a specific set of nodes or tasks</b></div><div>It will be possible to introduce additional flag for deploy/task run handler for Nailgun to pick up dependencies of specified tasks, even if they are currently not in place in current deployment graph. This means that instead of running</div><div><br></div><div><b><i>fuel nodes --node-id 2,3 --deploy </i> </b></div><div><br></div><div>and see how it fails as node-1 contains some of the tasks that are required by nodes 2 and 3, user will be calm about it as he will be able to specify an option to populate deployment flow with needed tasks. No more</div><div><br></div><div><b><i>fuel nodes --node-id 2 --tasks netconfig</i></b>  -> Fail, because you forgot to specify some of the required tasks, e.g. hiera, globals.</div><div><br></div><div><b>2. Post-deployment plugin installation</b><br></div><div><br></div><div>This feature also makes post-deployment plugin installation much easier as plugin installation will happen almost in matter of minutes instead of hours.</div><div><b><br></b></div><div><b>3. Cluster re-deployment for some of LCM cases support</b></div><div><b><br></b></div><div>Whenever user can change settings on the nodes and trigger full cluster redeployment or whenever he wants to get tainted cluster converge back to the previous state deployed by Fuel, he will get his cluster back into operational state in 30 minutes.</div><div><b><br></b></div><div><b>4. Better capabilities for separated services plugins</b></div><div><b><br></b></div><div>Task-based approach allows one to deploy things with separate services in much more flexible ways. E.g one will not have to introduce 2 roles in the plugin for controller to detach keystone services, e.g. pre-keystone-controller-tasks and post-keystone-controller-tasks. All he will need is to introduce "skipped" keystone task for controllers so that keystone is deployed only on the node with keystone role.</div><div><br></div><div><b>* Merge plan</b></div><div><br></div><div>Merge Astute changes - ETA Dec 4rd<br></div><div>Merge Nailgun changes - ETA Dec 4rd</div><div>Prepare Fuel Library changes - ETA Dec 3rd<br></div><div>Test this feature on Scale Lab and against swarm - ETA SCF</div><div>Make decision whether to enable task-based deployment engine by default - SCF</div><div><b><br></b></div><div><b>* Summary</b></div><div><b><br></b></div><div>This feature brings a lot of benefits for everyone. Its current implementation introduces 0 chances for regressions as it will be disabled by default and it will require specific actions for a user to start using this feature. In meanwhile we will test this feature at Scale Lab and against swarm and custom tests. And by SCF we may decide whether to switch to it based on the reported results. If it happens before SCF, we will be able to significantly ramp up our development and bugfixing velocity.</div><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></div>