Is there a way to upgrade OS using Puppet without exec to run yum?

TL;DR this is not a good idea. Do the update manually, or with a different form of automation.

Why it's a bad idea

I don't think that you should go down this path at all.

Generally, the idea to use Puppet to make sure that an update of the OS has been successfully completed is sound, at least from an academic standpoint. Puppet's goal is to allow you to define a state, and take care of the specifics of reaching this state.

That being said, Puppet would require a (fictional) distro type, so that you could specify

# pseudo code! Do not try at home or at all!
distro {
    'CentOS',
        version => '6.6';
}

You could conceivably go ahead and implement such a type, with the capability to try and perform a synchronization action to get from whatever your current release is to the one you have requested.

However, such a process can be infinitely complex and has virtually unlimited possibilities for failure and system corruption (of done wrong or at all). As such, it does not really lend itself very well to any form of automation.

As for Puppet specifically, you would want to add logic to your distro type/provider to recover from all sorts of weird states and achieve a clean one. The mere thought of such an endeavor is making me dizzy.

What would be less painful

Write a shell script. If the number of machines is too large to do them in batches using cssh (as I would probably do for anything below a few hundred nodes), create a simple wrapper that will do all you need. Deploy it with Puppet, and yes, do use an exec resource if you want Puppet to trigger the update. Consider

exec { 'echo /my/update/script | at now+10min': }

so that the puppet agent process is not the parent of the yum instance that will do all the work. This might prove disastrous.

Still, I'd launch the yum commands manually if it is at all feasible.

I agree that upgrading an OS through puppet looks like being too error-prone and at last unpredictable. But this isn't really true if you follow three rules:

1. Manage machines with a maximum level of standardization regarding OS configuration. To get this you have to manage them strictly through puppet.
   No pets, only cattle!
2. You have at least one test stage.
3. Your deployment mechanism assures that the exact puppet code you tested runs on the next stage.
4. The upgrade itself has to be the very last step on a puppet run.
5. As already discussed, the command for a necessary reboot must not be a parent of the puppet process. Otherwise the puppet run ends with an error at least.

I use the following puppet code for upgrading ubuntu machines from 12 to 14:

class os_upgrade {  
   # Script for automatic reboot after the puppet run
   file {'/tmp/reboot_after_puppetrun.sh' :
     content => "watch -g ls -l ${::puppet_vardir}/state;nohup /sbin/reboot\n",
     mode    => '0755',
   }  
   # Unattended upgrade
   exec { 'do-release-upgrade' :
     command   => '/usr/bin/do-release-upgrade -f DistUpgradeViewNonInteractive -m server',
     logoutput => true,
     onlyif    => "test $::operatingsystemrelease != '14.04'",
     notify    => Exec['reboot_after_upgrade'],
     timeout   => 1800,
   }  
   # Trigger the reboot as a background job to avoid puppet parentship
   exec { 'reboot_after_upgrade' :
     command     => "/usr/bin/nohup /tmp/reboot_after_puppetrun.sh&",
     refreshonly => true,
   }
}

To meet point 4 you have to define a stage and make sure the above mentioned class is attributed correctly.

In site.pp:

stage {'post': subscribe => Stage['main']}
node 'your_machine' {
  class { 'os_upgrade' :
    stage => 'post',
  }