PE plans lack features from Bolt plans

[bastelfreak]

Use Case

I'm a puppet partner and PE customers often start to evaluate bolt and eventually switch to PE plans. Then they are surprised that the (expensive) "enterprise" solution has less features compared to bolt. I would like to see the missing features being implemented.

Describe the Solution You Would Like

The most requested features are prompt() , system::env and parallelize(). And _run_as parameter for run_command() and run_task().

Describe Alternatives You've Considered

I don't see any proper alternatives. I also raised this in the past via support tickets and multiple times on slack.

Additional Context

It would help if you could document why some functions aren't available: https://www.puppet.com/docs/pe/2023.6/plans_limitations.html#plans_limitations-unavailable-plan-language-functions

[GSPatton]

Hi @bastelfreak . Thank you for raising this. I can immediately see the use case here. For us to better understand the customer’s needs, could you please provide more details on the following:

1. How many customers, roughly, are asking for this feature? Is this a common request that you get?
2. Is the lack of these features in PE blocking customers from performing certain tasks/workflows? Would you have any examples?

Your input will help us ensure that we address your request accurately and effectively.

Best regards, Gavin

[seanmil]

Hi @GSPatton , I am a PE customer and I find the disparity in capabilities to be challenging and disappointing, doubly so by the lack of any clear and supported way for a plan to ask if it is running in Bolt or the Orchestrator (see #14 ).

In particular, I have encountered (multiple times) real cases where I have had to make compromises in the code to support Orchestrator vs. Bolt:

set_var: It works, but the docs claim it does not (as of 2021.7 LTS). I use it out of necessity anyway. Nearly all of my workflows use set_var to attach information in long and complex plans to targets. It would be great to have it officially sanctioned.

set_feature: The features/implementation concept is great and can be used in Bolt for more than the built-in features quite effectively. Think tagging systems as supporting yum vs. apt vs. zypper and dispatching the right task using implementations, or indicating a specific supported version of something (e.g. Python) to dispatch a version-compatible implementation. To support Orchestrator I basically have had to re-invent the implementation selection logic in my plan and store the feature in a target variable (as calling set_feature raises an error).

background / wait / parallelize: These are very important when running a large multi-step plan where some systems might take a lot longer to run certain tasks than others but you still need each system to complete as soon as possible. I have some workflows I can't transition to Orchestrator because of it.

run_task_with: Sometimes as a more limited work-around to the lack of background / wait/ parallelize this might be an option - except it isn't supported either.

Target data: It would also be great if the Orchestrator inventory would at least set transport correctly to pcp for the Orchestrator-connected nodes (it just defaults to ssh) as well as user to either root or Administrator or whatever the PXP agent mandates on that system.

_run_as: Even if this can't be supported, it would be great if there was a way to indicate that it should just be silently ignored OR allow it to silently pass if the specified _run_as user matches the user which the PXP agent is running as (Orchestrator should be able to know, right?) and error/warn otherwise. Otherwise you have to add Orchestrator vs. Bolt specific parameter logic for all the Task invocations.

Any one of these might be a minor annoyance, but when taken all together it makes it quite challenging to build Plans which work in either environment and, even then, the Bolt experience is often the better/faster one (e.g. due to background/parallelize) and I find myself more and more designing Tasks meant to be run via Orchestrator with Plans executed by Bolt.

Thanks!

Sean

[bastelfreak]

I agree with everything @seanmil said. Those are also the points that bother the customers I represent. A concrete example:

plan profiles::subplans::precheck::environment (
  Boolean $runs_via_bolt = true,
) {
  if $runs_via_bolt {
    $run_as = { '_run_as' => 'root' }
  } else {
    $run_as = {}
  }
  $main  = { 'action' => 'get', 'setting' => 'environment', 'section' => 'main' } + $run_as
  $main_results = run_task('puppet_conf', $primary_host, 'description', $main)

I've many plans that are triggered via bolt, for example as a precheck to peadm, but also via the PE Orchestrator. They usually do some form of health checking before we start the actual job. Since PE plans lack some features, for example the _run_as option, we always need to duplicate stuff and introduce a condition to form the function signature. And to make this more complicated, there isn't a builtin way to determine if a plan is executed by bolt or PE Orchestrator (again, see https://github.com/puppetlabs/puppet-enterprise_issues/issues/14, which was initially reported in 2021). so something like if $runs_via_bolt { } else {} is already annoying, but we need a reliable way to set $runs_via_bolt.

Other example is prompt(). Several customers introduced bolt plans in their environment because back then it wasn't available in PE, but they needed a solution for orchestration. They have huge plans that run for hours and patch a whole datacenter. They often want to print status information and ask for confirmation. Usually something like 'do you really want to reboot the loadbalancer?'. With bolt that's totally easy. With PE plans that's impossible. There's no concept of input during a plan. The workaround is now to have out::message() printing the infos + something like 'please write at server X "YES" into file foo' and then a task that runs in a loop to read the file.

Do any of the lacking features/differences block us? Not as far as I know. Does it make it incredible hard to implement certain things that are way easier in open source? Yes. And I just cannot explain to PE customers why their expensive product is worse/has less features than open source.

This effects at least a volume of 20.000 licensed PE agents and multiple customers. But I think the more interesting question is: How many people didn't migrate from Open Source to PE because of the missing features? Not so easy to measure, but we had a few customers that didn't switch to PE because of the lacking features.

[rwaffen]

Unpopular opinion: PE Plans and Tasks (and the GUI for this) may be one of the only reasons new customers decide to buy PE. Most often they are satisfied OSS customers, but the pxp/pcp Plan/Task system offers them so much more value. But like mentioned, they are also most often disappointed by what's missing in PE Plans. That's what I saw over the last years since I started with PE.

[bastelfreak]

Another problem: we often use file::write() and write_file() to write and read debug data during plans. That's just not supported on the PE orchestrator, so we're lacking that information.

[seanmil]

Another problem: we often use file::write() and write_file() to write and read debug data during plans. That's just not supported on the PE orchestrator, so we're lacking that information.

It would be great to be able to use this to attach output to plans (and/or have a good facility to format and display results).

[bastelfreak]

Yes! we write json status data between plan steps and and the end we often use https://github.com/voxpupuli/puppet-format to generate a nice ascii table and write that into a file.

[GSPatton]

Thank you for all of the really valuable feedback here folks! We are tracking this internally and I am generating some discussion on possible paths forward. I will stay in touch here for any clarifications, updates etc. Thanks again