#131 – Cloud Spend



This week on the podcast, Kyle and Dan discuss challenges on moving to the cloud, how to limit search data in non-production environments, and using XPath to modify XML files.

Show Notes

#129 – Alliance 2018 Recap


This week on the podcast, Brad Carlson, Adam Wlad and Jim Marion join Dan to recap the Alliance 2018 conference. We discuss some CPU Patching issues, the 2027 date for PeopleSoft, and PeopleTools 8.57 announcements.

Show Notes

  • Technical and Reporting Advisory Group @ 1:45
  • CPU Patching and Security @ 5:15
  • PeopleSoft 2027 @ 15:00
  • PeopleTools 8.57 – Cloud First @ 19:30
  • PeopleTools 8.57 UI Changes @ 29:15
  • Page and Field Configurator @ 40:00
  • App Designer Improvements @ 49:45
  • Stop and Shares @ 56:30
  • Learning about Fluid @ 60:00

Improve the Management of DPK Archives

In Episode 127 of the podcast, Kyle and I discuss some strategies for managing the DPK archive files. The discussion started because I am starting a PeopleTools 8.56. To upgrade each server we copy the new DPK archive files to every server and run the DPK. Having a copy of those archives on every server is redundant and not the best solution.

 

A better solution is to store the DPK archives in centralized place. We run into a problem in the DPK when the archive folder has multiple versions of the same archive. For example, if we have two versions of the Weblogic archive, the DPK will return an error because it doesn’t know which one to deploy.

This error is generated from the function get_matched_file(). get_matched_file() is a custom DPK function that looks at the DPK Archive location and returns a filename based on a tag. The tags are string values like weblogic, pshome, and jdk. The DPK looks for all the file names that match the tag. If there is more than one file, the function returns an error.

Specifying Archive Files

Instead of letting the DPK search a directroy for matching archive files, we could explicity define which archive files we want to deploy. While this isn’t as dynamic, the method would give us more control over which version of each software we deploy. It could also solve the issue with centralizing all our DPK Archives.

To use this method, we have to make two changes to the DPK:

  • Create a new hash to store the archives we want to deploy
  • Update the Puppet code to read from the new hash

Hash to Store Archive Data

In the psft_customizations.yaml file, we create a new archive_files: hash. This hash is where we can explicitly define which archive files we want to use.

archive_files:
  weblogic:             "%{hiera('archive_location')}/pt-weblogic12.2.1.2.20180116.tgz"
  tuxedo:               "%{hiera('archive_location')}/pt-tuxedo12.2.2.0.tgz"
  jdk:                  "%{hiera('archive_location')}/pt-jdk1.8.0_144.tgz"
  pshome:               "%{hiera('archive_location')}/pt-pshome8.56.06.tgz"
  oracleclient:         "%{hiera('archive_location')}/pt-oracleclient12.1.0.2.tgz"
  psapphome:            "%{hiera('archive_location')}/fscm-psapphome027.tgz"

The keys to use the hash are the DPK tags for each piece of software. This lets us leverage the built-in tagging system in the DPK. If you want to take it a step further, you can define the hash with additional variables for each version. For example, in a common.yaml file, configure the archive_files: hash like this:

archive_files:
  jdk:                  "%{hiera('archive_location')}/pt-jdk%{hiera('jdk_version')}.tgz"
  pshome:               "%{hiera('archive_location')}/pt-pshome%{hiera('tools_version')}.tgz"

Then, in your psft_customizations.yaml file you can specify:

jdk_version:    1.8.0_144
tools_version:  8.56.06

Update Puppet to Read the Hash

Next, in the tools_deployment.pp file (under dpk/puppet/modules/pt_setup/manifests) we need to modify the code to use our archive_list: hash. In the delivered code, the DPK archive location and software tag are passed to the Ruby function get_matched_files(). What we will do instead is check if the archive_list: hash is defined. If it is, we will use the path from the hash instead of calling get_matched_file. If the archive_files: hash does not have the tag defined (like pshome), the get_matched_file() function is called.

Here is the code for deplying WebLogic:

$archive_files = hiera('archive_files', '')

if $archive_files {
  $weblogic_archive_file   = $archive_files[$weblogic_tag]
} 
if $weblogic_archive_file == '' {
  $weblogic_archive_file = get_matched_file($tools_archive_location, $weblogic_tag)
}
if $weblogic_archive_file == '' {
  fail("Unable to locate archive (tgz) file for Weblogic in ${tools_archive_location}")
}

You can copy this code for the rest of the archive types in the tools_deployment.pp and app_deployment. For DPK types that you do not specify, the DPK will revert to the original behavior.

I like this setup better. We get more control over which DPK archives we deploy, we can store multiple archives in a central location, and we retain the delivered behavior as the default.

#127 – Managing DPK Archives


This week on the podcast Kyle and Dan discuss different strategies for managing DPK archive files. Dan also discovers a few small improvements in the 8.56 PS_HOME and where to find the mythical Application DPK files.

Show Notes

  • App Designer Bug in 8.56 @ 1:00
  • 8.56 PS_HOME @ 5:00
  • Client Tools Install @ 8:30
  • Application DPK @ 11:00
  • Mananging DPK Archives @ 14:30

#126 – Elasticsearch Backups


This week on the podcast, Dan and Kyle discuss options and considerations for backing up Elasticsearch. Kyle also shares a bug with the PIA startup scripts built by the DPK and Dan makes Vagrant work with a Web Filter.

Show Notes

#125 – Push Notifications and Phire



This week on the podcast, Kyle talks about Push Notifications he built for Phire and how you could extend Phire. Dan explains the pt_password DPK Puppet Type, and Kyle discusses a leak of 2 billion passwords.

Show Notes

#123 – ps_patch


This week on the podcast Dan and Kyle discuss Colton Fischer’s Web Profile discovery, Kyle shares his CPU Patching process and how he automated the process then Dan discusses how he resolved a PIA domain bug.

Show Notes

#121 – Under Review


That’s right, its another Change Assistant episode. Dan shares some updates to Change Assistant in 8.56, some 8.57 speculation, and applying PeopleTools Upgrades headlessly. Kyle shares an ACM discovery, and the PeopleTools Idea Space updates.

Show Notes

#111 – ACM Plugins

This week on the podcast, Kyle and Dan revisit the ACM (Automated Config Management). We discuss what the ACM is, how ACM works with the DPK, building custom ACM plugins and how to share ACM plugins.

Show Notes

  • Revisiting ACM @ 1:00
  • Using ACM with the Search Framework @ 5:00
  • ACM and the DPK @ 9:00
  • Building ACM Plugins @ 13:30
  • Plugins that are missing @ 21:45
  • GitHub Repository to Share ACM Plug-ins @ 30:00
  • IDEA – More options for “Copy to File”