+1 On Mon, Feb 8, 2016 at 7:58 PM, Vladimir Kozhukalov < vkozhuka...@mirantis.com> wrote:
> +1 to enable it ASAP. > > It will also affect our deployment tests (~1 hour vs. ~2.5 hours). > > Vladimir Kozhukalov > > On Mon, Feb 8, 2016 at 7:35 PM, Bulat Gaifullin <bgaiful...@mirantis.com> > wrote: > >> +1. >> >> Regards, >> Bulat Gaifullin >> Mirantis Inc. >> >> >> >> > On 08 Feb 2016, at 19:05, Igor Kalnitsky <ikalnit...@mirantis.com> >> wrote: >> > >> > Hey Fuelers, >> > >> > When we are going to enable it? I think since HCF is passed for >> > stable/8.0, it's time to enable task-based deployment for master >> > branch. >> > >> > Opinion? >> > >> > - Igor >> > >> > On Wed, Feb 3, 2016 at 12:31 PM, Bogdan Dobrelya < >> bdobre...@mirantis.com> wrote: >> >> On 02.02.2016 17:35, Alexey Shtokolov wrote: >> >>> Hi Fuelers! >> >>> >> >>> As you may be aware, since [0] Fuel has implemented a new >> orchestration >> >>> engine [1] >> >>> We switched the deployment paradigm from role-based (aka granular) to >> >>> task-based and now Fuel can deploy all nodes simultaneously using >> >>> cross-node dependencies between deployment tasks. >> >> >> >> That is great news! Please do not forget about docs updates as well. >> >> Those docs are always forgotten like poor orphans... I submitted a >> patch >> >> [0] to MOS docs, please review and add more details, if possible, for >> >> plugins impact as well. >> >> >> >> [0] https://review.fuel-infra.org/#/c/16509/ >> >> >> >>> >> >>> This feature is experimental in Fuel 8.0 and will be enabled by >> default >> >>> for Fuel 9.0 >> >>> >> >>> Allow me to show you the results. We made some benchmarks on our bare >> >>> metal lab [2] >> >>> >> >>> Case #1. 3 controllers + 7 computes w/ ceph. >> >>> Task-based deployment takes *~38* minutes vs *~1h15m* for granular >> (*~2* >> >>> times faster) >> >>> Here and below the deployment time is average time for 10 runs >> >>> >> >>> Case #2. 3 controllers + 3 mongodb + 4 computes w/ ceph. >> >>> Task-based deployment takes *~41* minutes vs *~1h32m* for granular >> >>> (*~2.24* times faster) >> >>> >> >>> >> >>> >> >>> Also we took measurements for Fuel CI test cases. Standard BVT (Master >> >>> node + 3 controllers + 3 computes w/ ceph. All are in qemu VMs on one >> host) >> >>> >> >>> Fuel CI slaves with *4 *cores *~1.1* times faster >> >>> In case of 4 cores for 7 VMs they are fighting for CPU resources and >> it >> >>> marginalizes the gain of task-based deployment >> >>> >> >>> Fuel CI slaves with *6* cores *~1.6* times faster >> >>> >> >>> Fuel CI slaves with *12* cores *~1.7* times faster >> >> >> >> These are really outstanding results! >> >> (tl;dr) >> >> I believe the next step may be to leverage the "external install & svc >> >> management" feature (example [1]) of the Liberty release (7.0.0) of >> >> Puppet-Openstack (PO) modules. So we could use separate concurrent >> >> cross-depends based tasks *within a single node* as well, like: >> >> - task: install_all_packages - a singleton task for a node, >> >> - task: [configure_x, for each x] - concurrent for a node, >> >> - task: [manage_service_x, for each x] - some may be concurrent for a >> >> node, while another shall be serialized. >> >> >> >> So, one might use the "--tags" separator for concurrent puppet runs to >> >> make things go even faster, for example: >> >> >> >> # cat test.pp >> >> notify >> >> {"A": tag => "a" } >> >> notify >> >> {"B": tag => "b" } >> >> >> >> # puppet apply test.pp >> >> Notice: A >> >> Notice: /Stage[main]/Main/Notify[A]/message: defined 'message' as 'A' >> >> Notice: B >> >> Notice: /Stage[main]/Main/Notify[B]/message: defined 'message' as 'B' >> >> >> >> # puppet apply test.pp --tags a >> >> Notice: A >> >> Notice: /Stage[main]/Main/Notify[A]/message: defined 'message' as 'A' >> >> >> >> # puppet apply test.pp --tags a & puppet apply test.pp --tags b >> >> Notice: B >> >> Notice: /Stage[main]/Main/Notify[B]/message: defined 'message' as 'B' >> >> Notice: A >> >> Notice: /Stage[main]/Main/Notify[A]/message: defined 'message' as 'A' >> >> >> >> Which is supposed to be faster, although not for this example. >> >> >> >> [1] https://review.openstack.org/#/c/216926/3/manifests/init.pp >> >> >> >>> >> >>> You can see additional information and charts in the presentation [3]. >> >>> >> >>> [0] >> >>> - >> http://lists.openstack.org/pipermail/openstack-dev/2015-December/082093.html >> >>> [1] >> >>> - >> https://specs.openstack.org/openstack/fuel-specs/specs/8.0/task-based-deployment-mvp.html >> >>> [2] - 3 x HP ProLiant DL360p Gen8 (XeonE5 6 cores/64GB/SSD) + 7 x HP >> >>> ProLiant DL320p Gen8 (XeonE3 4 cores/8-16GB/HDD) >> >>> [3] - >> >>> >> https://docs.google.com/presentation/d/1jZCFZlXHs_VhjtVYS2VuWgdxge5Q6sOMLz4bRLuw7YE >> >>> >> >>> --- >> >>> WBR, Alexey Shtokolov >> >>> >> >>> >> >>> >> __________________________________________________________________________ >> >>> OpenStack Development Mailing List (not for usage questions) >> >>> Unsubscribe: >> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >> >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >>> >> >> >> >> >> >> -- >> >> Best regards, >> >> Bogdan Dobrelya, >> >> Irc #bogdando >> >> >> >> >> __________________________________________________________________________ >> >> OpenStack Development Mailing List (not for usage questions) >> >> Unsubscribe: >> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> > >> > >> __________________________________________________________________________ >> > OpenStack Development Mailing List (not for usage questions) >> > Unsubscribe: >> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> >> __________________________________________________________________________ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: >> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> > > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
