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