Re: [openstack-dev] [tripleo] Patches to speed up plan operations
Hey Jirka! I wasn't aware of the other options available. Basically yes, you now just need to upload a tarball of the templates to swift. You can see in the client: -tarball.tarball_extract_to_swift_container( -swift_client, tmp_tarball.name, container_name) +_upload_file(swift_client, container_name, + constants.TEMPLATES_TARBALL_NAME, tmp_tarball.name) Other than that it should be the same. I'm not sure what files the UI wants to look at in swift, but certainly some are still there. Basically any file that exists in swift is not overwritten by the contents of the tar file. So if a file exists in swift it takes priority. I'll try to catch you on irc but I know our timezones are quite different. Thanks for looking into it! Ian On Wed, Aug 8, 2018 at 10:46 AM Jiri Tomasek wrote: > Hello, thanks for bringing this up. > > I am going to try to test this patch with TripleO UI tomorrow. Without > properly looking at the patch, questions I would like to get answers for > are: > > How is this going to affect ways to create/update deployment plan? > Currently user is able to create deployment plan by: > - not providing any files - creating deployment plan from default files in > /usr/share/openstack-tripleo-heat-templates > - providing a tarball > - providing a local directory of files to create plan from > - providing a git repository link > > These changes will have an impact on certain TripleO UI operations where > (in rare cases) we reach directly for a swift object > > IIUC it seems we are deciding to consider deployment plan as a black box > packed in a tarball, which I quite like, we'll need to provide a standard > way how to provide custom files to the plan. > > How is this going to affect CLI vs GUI workflow as currently CLI creates > the plan as part of the deploy command, rather than GUI starts its workflow > by selecting/creating deployment plan and whole configuration of the plan > is performed on the deployment plan. Then the deployment plan gets > deployed. We are aiming to introduce CLI commands to consolidate the > behaviour of both clients to what GUI workflow is currently. > > I am going to try to find answers to these questions and identify > potential problems in next couple of days. > > -- Jirka > > > On Tue, Aug 7, 2018 at 5:34 PM Dan Prince wrote: > >> Thanks for taking this on Ian! I'm fully on board with the effort. I >> like the consolidation and performance improvements. Storing t-h-t >> templates in Swift worked okay 3-4 years ago. Now that we have more >> templates, many of which need .j2 rendering the storage there has >> become quite a bottleneck. >> >> Additionally, since we'd be sending commands to Heat via local >> filesystem template storage we could consider using softlinks again >> within t-h-t which should help with refactoring and deprecation >> efforts. >> >> Dan >> On Wed, Aug 1, 2018 at 7:35 PM Ian Main wrote: >> > >> > >> > Hey folks! >> > >> > So I've been working on some patches to speed up plan operations in >> TripleO. This was originally driven by the UI needing to be able to >> perform a 'plan upload' in something less than several minutes. :) >> > >> > https://review.openstack.org/#/c/581153/ >> > https://review.openstack.org/#/c/581141/ >> > >> > I have a functioning set of patches, and it actually cuts over 2 >> minutes off the overcloud deployment time. >> > >> > Without patch: >> > + openstack overcloud plan create --templates >> /home/stack/tripleo-heat-templates/ overcloud >> > Creating Swift container to store the plan >> > Creating plan from template files in: >> /home/stack/tripleo-heat-templates/ >> > Plan created. >> > real3m3.415s >> > >> > With patch: >> > + openstack overcloud plan create --templates >> /home/stack/tripleo-heat-templates/ overcloud >> > Creating Swift container to store the plan >> > Creating plan from template files in: >> /home/stack/tripleo-heat-templates/ >> > Plan created. >> > real0m44.694s >> > >> > This is on VMs. On real hardware it now takes something like 15-20 >> seconds to do the plan upload which is much more manageable from the UI >> standpoint. >> > >> > Some things about what this patch does: >> > >> > - It makes use of process-templates.py (written for the undercloud) to >> process the jinjafied templates. This reduces replication with the >> existing version in the code base and is very fast as it's all done on >> local disk. >> > - It stores the bulk of the templates as a tarball in swift. Any >> individual files in swift take precedence over the contents of the tarball >> so it should be backwards compatible. This is a great speed up as we're >> not accessing a lot of individual files in swift. >> > >> > There's still some work to do; cleaning up and fixing the unit tests, >> testing upgrades etc. I just wanted to get some feedback on the general >> idea and hopefully some reviews and/or help - especially with the unit test >>
Re: [openstack-dev] [tripleo] Patches to speed up plan operations
Hello, thanks for bringing this up. I am going to try to test this patch with TripleO UI tomorrow. Without properly looking at the patch, questions I would like to get answers for are: How is this going to affect ways to create/update deployment plan? Currently user is able to create deployment plan by: - not providing any files - creating deployment plan from default files in /usr/share/openstack-tripleo-heat-templates - providing a tarball - providing a local directory of files to create plan from - providing a git repository link These changes will have an impact on certain TripleO UI operations where (in rare cases) we reach directly for a swift object IIUC it seems we are deciding to consider deployment plan as a black box packed in a tarball, which I quite like, we'll need to provide a standard way how to provide custom files to the plan. How is this going to affect CLI vs GUI workflow as currently CLI creates the plan as part of the deploy command, rather than GUI starts its workflow by selecting/creating deployment plan and whole configuration of the plan is performed on the deployment plan. Then the deployment plan gets deployed. We are aiming to introduce CLI commands to consolidate the behaviour of both clients to what GUI workflow is currently. I am going to try to find answers to these questions and identify potential problems in next couple of days. -- Jirka On Tue, Aug 7, 2018 at 5:34 PM Dan Prince wrote: > Thanks for taking this on Ian! I'm fully on board with the effort. I > like the consolidation and performance improvements. Storing t-h-t > templates in Swift worked okay 3-4 years ago. Now that we have more > templates, many of which need .j2 rendering the storage there has > become quite a bottleneck. > > Additionally, since we'd be sending commands to Heat via local > filesystem template storage we could consider using softlinks again > within t-h-t which should help with refactoring and deprecation > efforts. > > Dan > On Wed, Aug 1, 2018 at 7:35 PM Ian Main wrote: > > > > > > Hey folks! > > > > So I've been working on some patches to speed up plan operations in > TripleO. This was originally driven by the UI needing to be able to > perform a 'plan upload' in something less than several minutes. :) > > > > https://review.openstack.org/#/c/581153/ > > https://review.openstack.org/#/c/581141/ > > > > I have a functioning set of patches, and it actually cuts over 2 minutes > off the overcloud deployment time. > > > > Without patch: > > + openstack overcloud plan create --templates > /home/stack/tripleo-heat-templates/ overcloud > > Creating Swift container to store the plan > > Creating plan from template files in: /home/stack/tripleo-heat-templates/ > > Plan created. > > real3m3.415s > > > > With patch: > > + openstack overcloud plan create --templates > /home/stack/tripleo-heat-templates/ overcloud > > Creating Swift container to store the plan > > Creating plan from template files in: /home/stack/tripleo-heat-templates/ > > Plan created. > > real0m44.694s > > > > This is on VMs. On real hardware it now takes something like 15-20 > seconds to do the plan upload which is much more manageable from the UI > standpoint. > > > > Some things about what this patch does: > > > > - It makes use of process-templates.py (written for the undercloud) to > process the jinjafied templates. This reduces replication with the > existing version in the code base and is very fast as it's all done on > local disk. > > - It stores the bulk of the templates as a tarball in swift. Any > individual files in swift take precedence over the contents of the tarball > so it should be backwards compatible. This is a great speed up as we're > not accessing a lot of individual files in swift. > > > > There's still some work to do; cleaning up and fixing the unit tests, > testing upgrades etc. I just wanted to get some feedback on the general > idea and hopefully some reviews and/or help - especially with the unit test > stuff. > > > > Thanks everyone! > > > > Ian > > > > > __ > > 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
Re: [openstack-dev] [tripleo] Patches to speed up plan operations
Thanks for taking this on Ian! I'm fully on board with the effort. I like the consolidation and performance improvements. Storing t-h-t templates in Swift worked okay 3-4 years ago. Now that we have more templates, many of which need .j2 rendering the storage there has become quite a bottleneck. Additionally, since we'd be sending commands to Heat via local filesystem template storage we could consider using softlinks again within t-h-t which should help with refactoring and deprecation efforts. Dan On Wed, Aug 1, 2018 at 7:35 PM Ian Main wrote: > > > Hey folks! > > So I've been working on some patches to speed up plan operations in TripleO. > This was originally driven by the UI needing to be able to perform a 'plan > upload' in something less than several minutes. :) > > https://review.openstack.org/#/c/581153/ > https://review.openstack.org/#/c/581141/ > > I have a functioning set of patches, and it actually cuts over 2 minutes off > the overcloud deployment time. > > Without patch: > + openstack overcloud plan create --templates > /home/stack/tripleo-heat-templates/ overcloud > Creating Swift container to store the plan > Creating plan from template files in: /home/stack/tripleo-heat-templates/ > Plan created. > real3m3.415s > > With patch: > + openstack overcloud plan create --templates > /home/stack/tripleo-heat-templates/ overcloud > Creating Swift container to store the plan > Creating plan from template files in: /home/stack/tripleo-heat-templates/ > Plan created. > real0m44.694s > > This is on VMs. On real hardware it now takes something like 15-20 seconds > to do the plan upload which is much more manageable from the UI standpoint. > > Some things about what this patch does: > > - It makes use of process-templates.py (written for the undercloud) to > process the jinjafied templates. This reduces replication with the existing > version in the code base and is very fast as it's all done on local disk. > - It stores the bulk of the templates as a tarball in swift. Any individual > files in swift take precedence over the contents of the tarball so it should > be backwards compatible. This is a great speed up as we're not accessing a > lot of individual files in swift. > > There's still some work to do; cleaning up and fixing the unit tests, testing > upgrades etc. I just wanted to get some feedback on the general idea and > hopefully some reviews and/or help - especially with the unit test stuff. > > Thanks everyone! > > Ian > > __ > 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
Re: [openstack-dev] [tripleo] Patches to speed up plan operations
On 8/2/18 1:34 AM, Ian Main wrote: Hey folks! So I've been working on some patches to speed up plan operations in TripleO. This was originally driven by the UI needing to be able to perform a 'plan upload' in something less than several minutes. :) https://review.openstack.org/#/c/581153/ https://review.openstack.org/#/c/581141/ I have a functioning set of patches, and it actually cuts over 2 minutes off the overcloud deployment time. Without patch: + openstack overcloud plan create --templates /home/stack/tripleo-heat-templates/ overcloud Creating Swift container to store the plan Creating plan from template files in: /home/stack/tripleo-heat-templates/ Plan created. real 3m3.415s With patch: + openstack overcloud plan create --templates /home/stack/tripleo-heat-templates/ overcloud Creating Swift container to store the plan Creating plan from template files in: /home/stack/tripleo-heat-templates/ Plan created. real 0m44.694s This is on VMs. On real hardware it now takes something like 15-20 seconds to do the plan upload which is much more manageable from the UI standpoint. Some things about what this patch does: - It makes use of process-templates.py (written for the undercloud) to process the jinjafied templates. This reduces replication with the existing version in the code base and is very fast as it's all done on local disk. Just wanted to say Special Big Thank You for doing that code consolidation work! - It stores the bulk of the templates as a tarball in swift. Any individual files in swift take precedence over the contents of the tarball so it should be backwards compatible. This is a great speed up as we're not accessing a lot of individual files in swift. There's still some work to do; cleaning up and fixing the unit tests, testing upgrades etc. I just wanted to get some feedback on the general idea and hopefully some reviews and/or help - especially with the unit test stuff. Thanks everyone! Ian __ 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-dev] [tripleo] Patches to speed up plan operations
Hey folks! So I've been working on some patches to speed up plan operations in TripleO. This was originally driven by the UI needing to be able to perform a 'plan upload' in something less than several minutes. :) https://review.openstack.org/#/c/581153/ https://review.openstack.org/#/c/581141/ I have a functioning set of patches, and it actually cuts over 2 minutes off the overcloud deployment time. Without patch: + openstack overcloud plan create --templates /home/stack/tripleo-heat-templates/ overcloud Creating Swift container to store the plan Creating plan from template files in: /home/stack/tripleo-heat-templates/ Plan created. real3m3.415s With patch: + openstack overcloud plan create --templates /home/stack/tripleo-heat-templates/ overcloud Creating Swift container to store the plan Creating plan from template files in: /home/stack/tripleo-heat-templates/ Plan created. real0m44.694s This is on VMs. On real hardware it now takes something like 15-20 seconds to do the plan upload which is much more manageable from the UI standpoint. Some things about what this patch does: - It makes use of process-templates.py (written for the undercloud) to process the jinjafied templates. This reduces replication with the existing version in the code base and is very fast as it's all done on local disk. - It stores the bulk of the templates as a tarball in swift. Any individual files in swift take precedence over the contents of the tarball so it should be backwards compatible. This is a great speed up as we're not accessing a lot of individual files in swift. There's still some work to do; cleaning up and fixing the unit tests, testing upgrades etc. I just wanted to get some feedback on the general idea and hopefully some reviews and/or help - especially with the unit test stuff. Thanks everyone! Ian __ 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
