Jira (PDOC-294) Improve Type Alias Docs - Parameter Support
Title: Message Title Randell Pelak commented on PDOC-294 Re: Improve Type Alias Docs - Parameter Support Sometimes Jira saves settings from the previous ticket you used, or in really fun cases, that someone else used... Anyway, I removed the things the template did that made this show up on the SLV board, but I don't know if there is anything that needs to be done to get this seen by the right people (every team does it differently). And I can't remove the template, but that shouldn't really matter. Add Comment This message was sent by Atlassian JIRA (v7.7.1#77002-sha1:e75ca93) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-bugs/JIRA.329108.1570847885000.19361.1578673980161%40Atlassian.JIRA.
Jira (PDOC-294) Improve Type Alias Docs - Parameter Support
Title: Message Title Randell Pelak updated an issue Puppet Strings / PDOC-294 Improve Type Alias Docs - Parameter Support Change By: Randell Pelak Labels: experiment Team: System Level Validation Add Comment This message was sent by Atlassian JIRA (v7.7.1#77002-sha1:e75ca93) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-bugs/JIRA.329108.1570847885000.19357.1578673800186%40Atlassian.JIRA.
Jira (PDOC-294) Improve Type Alias Docs - Parameter Support
Title: Message Title Randell Pelak commented on PDOC-294 Re: Improve Type Alias Docs - Parameter Support I think you may have used the wrong template for this ticket... This template is for requesting a performance experiment. Let me know if I am wrong, otherwise I will clear out the stuff that is making this show up on SLV. Add Comment This message was sent by Atlassian JIRA (v7.7.1#77002-sha1:e75ca93) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-bugs/JIRA.329108.1570847885000.18913.1578614460183%40Atlassian.JIRA.
Jira (BOLT-1321) running commands on localhost from a plan run as root fails starting with 1.16
Title: Message Title Randell Pelak commented on BOLT-1321 Re: running commands on localhost from a plan run as root fails starting with 1.16 Has this ticket been seen? We are currently stuck on 1.15 for our workflow... but I don't see a way to access the 1.15 documentation, so running into issues where I can't just look things up. Add Comment This message was sent by Atlassian JIRA (v7.7.1#77002-sha1:e75ca93) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-bugs/JIRA.309415.1558363198000.60979.1566236340180%40Atlassian.JIRA.
Jira (BOLT-1336) simple task fails trying to change back to user it connected with...
Title: Message Title
Randell Pelak created an issue
Puppet Task Runner / BOLT-1336
simple task fails trying to change back to user it connected with...
Issue Type:
Bug
Assignee:
Unassigned
Created:
2019/05/22 5:22 PM
Priority:
Normal
Reporter:
Randell Pelak
task: #!/bin/sh instance_username="$PT_instance_username" if [ -z "${instance_username}" ] ; then instance_username="tester" fi export git_dir="/home/$instance_username/git" if [ ! -d $git_dir/puppet-metrics-viewer ]; then
echo "git clone https://github.com/puppetlabs/puppet-metrics-viewer.git /home/$instance_username/git/puppet-metrics-viewer" > /tmp/gclone git clone https://github.com/puppetlabs/puppet-metrics-viewer.git /home/$instance_username/git/puppet-metrics-viewer chown -R $instance_username /home/$instance_username/git/puppet-metrics-viewer chgrp -R $instance_username /home/$instance_username/git/puppet-metrics-viewer fi
run: ✗ bolt task run p9_instance_setup::setup_metrics_viewer --nodes 10.234.0.19 --user centos --private-key ~/.ssh/id_rsa-acceptance --no-host-key-check --tty --run-as fanny instance_username=fanny Started on 10.234.0.19... Finished on 10.234.0.19: fatal: Could not change back to '/home/centos': Permission denied { } Successful on 1 node: 10.234.0.19 Ran on 1 node in 2.53 seconds Normally this task is run from a plan which is why the oddness of the connection user being centos... the larger picture creates the user before this and installs git and all that. Then near the end it calls this task to clone the repo... I originally tried to use the run_as so that I wouldn't have to mess with cleaning up the permissions. But it seemed to create the directory that the git clone should create, but it was empty. I debugged down to this level which does the same but gives the error. The workaround in this case it to run_as root and then have the task fix the permissions.
Jira (BOLT-1321) running commands on localhost from a plan run as root fails starting with 1.16
Title: Message Title Randell Pelak commented on BOLT-1321 Re: running commands on localhost from a plan run as root fails starting with 1.16 I reverted one version at a time back to 1.15 and it works in 1.15. So 1.16 is where the break occurred. Add Comment This message was sent by Atlassian JIRA (v7.7.1#77002-sha1:e75ca93) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-bugs/JIRA.309415.1558363198000.12433.1558372920899%40Atlassian.JIRA. For more options, visit https://groups.google.com/d/optout.
Jira (BOLT-1321) running commands on localhost from a plan run as root fails starting with 1.16
Title: Message Title Randell Pelak updated an issue Puppet Task Runner / BOLT-1321 running commands on localhost from a plan run as root fails starting with 1.16 Change By: Randell Pelak Summary: running commands on localhost from a plan run as root fails starting with 1. 20 16 Add Comment This message was sent by Atlassian JIRA (v7.7.1#77002-sha1:e75ca93) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-bugs/JIRA.309415.1558363198000.12424.1558372862283%40Atlassian.JIRA. For more options, visit https://groups.google.com/d/optout.
Jira (BOLT-1322) plan calling a plan does an apply hangs unless original plan call is run-as root
Title: Message Title
Randell Pelak updated an issue
Puppet Task Runner / BOLT-1322
plan calling a plan does an apply hangs unless original plan call is run-as root
Change By:
Randell Pelak
This is using bolt 1.20 on my macI created two plans to reproduce this from a real use case.test_run_as_hang_top.ppplan p9_instance_setup::test_run_as_hang_top ( TargetSpec $nodes, ) { run_plan(p9_instance_setup::test_run_as_hang_sub,'nodes' => $nodes, '_run_as' => 'root')}test_run_as_hang_sub.ppplan p9_instance_setup::test_run_as_hang_sub ( TargetSpec $nodes, ) { $nodes.apply_prep apply($nodes) {notice("hi") }}Then called it like thisbolt plan run p9_instance_setup::test_run_as_hang_top --nodes 10.234.0.19 --user centos --private-key ~/.ssh/id_rsa-acceptance --tty --no-host-key-checkHere is the output:Starting: plan p9_instance_setup::test_run_as_hang_topStarting: plan p9_instance_setup::test_run_as_hang_subStarting: install puppet and gather facts on 10.234.0.19Finished: install puppet and gather facts with 0 failures in 9.0 secStarting: apply catalog on 10.234.0.19I have to control C because it is permanently hung. If I add --run-as root to the bolt call like this:bolt plan run p9_instance_setup::test_run_as_hang_top --nodes 10.234.0.19 --user centos --private-key ~/.ssh/id_rsa-acceptance --tty --no-host-key-check --run-as rootIt works just fine, and reasonably fast.Starting: plan p9_instance_setup::test_run_as_hang_topStarting: plan p9_instance_setup::test_run_as_hang_subStarting: install puppet and gather facts on 10.234.0.19Finished: install puppet and gather facts with 0 failures in 8.88 secStarting: apply catalog on 10.234.0.19Finished: apply catalog with 0 failures in 11.21 secFinished: plan p9_instance_setup::test_run_as_hang_sub in 20.1 secFinished: plan p9_instance_setup::test_run_as_hang_top in 20.11 secPlan completed successfully with no resultThe _run_as root in the run_plan call doesn't have to be there to reproduce the problem. But since that plan is going to be doing an apply it seems like it should need it.Also the reason I can't just do run-as root on the command line for my real use case is due to this bug: BOLT-1321 which causes my local run_command to fail if I have run-as root.Real use case:We have been using a bolt plan to setup a p9 instance for use in running performance tests. It sets up the software, creates a user that matches the current user and copies up a lot of account configuration files so that the user can run just like they do from their mac. To do that it has to run a command running whoami to find out the user name to create on the box. That command fails if run-as root is given starting in 1.20 (BOLT-1321). The effort is split up into multiple plans because initially we want to setup software and the user. Later we might want to add an additional user, or update user config files, but not change the software. Or we might want to update the software but not touch the user. So basically there is a top level plan that calls two sub plans tha
Jira (BOLT-1322) plan calling a plan does an apply hangs unless original plan call is run-as root
Title: Message Title
Randell Pelak commented on BOLT-1322
Re: plan calling a plan does an apply hangs unless original plan call is run-as root
For the hang in both 1.20 and 1.19 the debug output ends like this: ( This is from 1.19, I didn't check the stdout to make sure there were identical.) Executing: /tmp/33da4e0e-fd7c-4e23-9179-d88da829eae2/apply_catalog.rb stdout: {"catalog":{"tags":["settings"],"name":"10.234.0.19","version":1558372267,"code_id":null,"catalog_uuid":"52431f5c-8a68-492e-a713-2b8222642c17","catalog_format":1,"environment":"bolt_catalog","resources":[{"type":"Stage","title":"main","tags":["stage","class"],"exported":false,"parameters":{"name":"main"}}, {"type":"Class","title":"Settings","tags":["class","settings"],"exported":false} ,{"type":"Class","title":"main","tags":["class"],"exported":false,"parameters":{"name":"main"}}],"edges":[ {"source":"Stage[main]","target":"Class[Settings]"} , {"source":"Stage[main]","target":"Class[main]"} ],"classes":["settings"]},"plugins":"H4sIAKvf4lwAA+y9e3/bxrUo2r/9KSZUukHGFCX5lXuYKI7rJI3PzuvaTvo7\nV1ZpiIQk1CTBAqBk1db57He95okBSVm2m3SLbSwSmPesWbPea1zMx2m9M82P\ndhbLxSKrd+qLRbYzpsej43yaDcqjP13vswufB/fuRZ/v7t55sPvgzp/27t57\n8AC+3d198KfdvbsPPr/zJ7V7zX43+iyrOi1hKB+jr9/hp8z+uczLTCXu7uO2\n7xTn86xMbrUXOCmL5WJVgVkxyZrvl3U+3RmfZuNX1XJWJbdu/ULPh8PnUHEw\nz86xge7QgcCemhS3lPp6UozVvvryy+1vfn4Mv+EJtDBLywv6odRfMxhxWmeV\nShXWU+d5faqgoTqb1+q4LGbwT3oyg1+Vqk7TMp+fQNFxMZsVc7Wc5/9cZqpO\nTwa3uPXsdTpbTDNp/bEMSFqAcbzFwmp/XyVcdwQ/E/X2q69uSRVnDuqNSnbq\n2YJWJhlKAUUtOJ/9r7zG+mpL/byo82KeTgfqm+w4XU5rVRcw2El2bBpZpDBP\nvxHbV195jTw5Vif5WTZXea2Ks6ws8wksWH2aqTKrimU5ztQ8nWWmbQIDv+2y\nKGpslj4bDZBA5bqNIDgFs0S0kqirNFKUk3A68+UsK/NxEjTSdxsxhUxD2bxa\nltkI4HWazzNs6DidVnaAkYYqbIlKSSuX8Bdh+ZY0lx4BoBCsKwW7MnZhXaln\ni2ycH+ewW+enGWxYSbsG5ep8nmJXDPTVabGcTlT2Oq/qgXqW1TWCOc4hPaoA\ncBNVZ9NppfjY4YtJNs3qLN5afoyAQo1VfZXOJzKYeXZCJw0rZcfH2Rig6Rje\nX6iChrZIS4CiOiurAdWQaeK8aC3O0ukyq7xHMJI3argAMMTjdUmLMsES8F5G\n8JDKV9n0+GDIG3CI509XslVgW2gE3SEco563pslTRkiTgbOiqXP84SAcZ2U2\nh5MAQxoX0ynOLp1OzXk2SIQQDC5BBZMl1JHExoDns0/H6iwth6oul1lvk31O\nm/txXPC2A9I6AribWIw2UL+l03yiCgK7agi1q5pQHGLANJ8TtpsrgIJiuoT9\nxlHZk0IbMsS2ZRh1XkN/sKkXgBVgIONpCotmsESwrWfYN0AETEu9pbbeSjvL\n+TSrNLgNh78C+h/oMYxwDA+7VL4P21hU+eueevt2o9Ln+XxSnFc9cyTLNIcD\n+Kg8WeKCfFuWRdlXo27nO1w4rFupGVz36giWcTmdXqh/LmHUsNIT2JyiVsmf\n34yo8cuk01N/BmgcyarQHwJJPvp8CvhvY7cJY/bxBMAohsq93oZDHMtw+DMW\n2QgEcK8ZBcNOxE7oZtuullVWIgACAlQ5XIgn0KJfIJ/YLY3MilD46ln9FYts\nCNiLrJzlVYVDlttBQ/Y7TpAbWTVFGcXJmoniNbN6nj9CiY03z50o3WDX20fb\nHLfGkJnPVTGu0ymCMTW5coZ0B264T4DDT4sJbU5VlHSVED6wOPDoglcdcSGM\nIz63/1Ms1RiQj6Y4oFgONJhcTse0Y5P8LJ/AiZRReD2kk38sK77I8EDQJW6u\nGMXd5qUg6OHQEGmMtmgk4UUE68GXUHeYThenKWAUueR74bWkX8QW8ygdv9oQ\n6vW13YVrVJ0W5z28X7C+AsiN3r5HGSxNRqt2XuY0/7ym1Sxl508yWKBFWlWA\nmqEWNMgQm1QKGzrLqCEZiqHwcMGz19l4SbASQh7eT30mVPp4mAwklplctPgj\ny2kyKVx7JYyC+jlajl/BV6qDvwkwstdAfyPEyiiOspN8TuBM12dn0BkkV7xM\nDp7DEB9PYdp99R2OU74/o3EeDvL5eLqcZHJXDMb4du09kfyFttLcEan6S1FM\nM4TaUlpOdCNrrgBYqGk6htU74hb0moZY5RcNwsOh9BXQKhGarzDgsJJkS6dl\nlk4uhHCSFbYgjeOJjVwv/Wg8m2yIIqQK9o+sFAI3dJAuFnDDYk9RhCBEmCFD\nYUqE1O4O7uNyw4Cysh0l1oWBJQ382CXP/10pFIaVvBqlD7u83etB5jdnuRzA\nuRq0+KzEtYGmEwWadDKBgRGvcgSQ8UqlNRPvsF1wJWXp+NSgXHgBbydFVs0T\nB5KgJF4082zQCaBJMzWNqQGimaV1KyDxSC9gnNhfWgMygXsWhwv49oTh294D\naZPGTeCc5XPgI5OLdDbFv/oirn+u52WZXphfgHyqusL/6V+2H45UA9wOWAH\n8Aerwh//WHQwTDSQ/NWoZZbVu2DIQ9eWFprOEzLcQ2gB5jzVZYt9PXKM2fs\nfJqfYEW6cQGJbLrvwKLl8+XrUX4yhwtsJDWqa8/JR0KZQAieegScBEmKaMfQ\nyJiOLl5exVzLX07relENd3bgbTVg+dQUuI0B4LEdwwVWO1NkdVmyNTitZ9Mt\n7HE7reGUHwFfst3S6UoiDOqU6fwkC89ufE5U1EyCEOnwPY6emu+sQZNtOPCZ\nHl4T/61DrS0IEUdUTDddmmL6IVcGWr/OwuDg3ue64Fg3WxfCpB9sXfDdNdaF\nBvc+1wX5283WBUt+uHXB1q+xLjS497cuwGSMJvnx8XvGu7F7pcqYnjB9OvyZ\nZu198kz9WmXHyym9Pc0n
Jira (BOLT-1322) plan calling a plan does an apply hangs unless original plan call is run-as root
Title: Message Title
Randell Pelak updated an issue
Puppet Task Runner / BOLT-1322
plan calling a plan does an apply hangs unless original plan call is run-as root
Change By:
Randell Pelak
This is using bolt 1.20 on my mac I created two plans to reproduce this from a real use case.test_run_as_hang_top.ppplan p9_instance_setup::test_run_as_hang_top ( TargetSpec $nodes, ) { run_plan(p9_instance_setup::test_run_as_hang_sub,'nodes' => $nodes, '_run_as' => 'root')}test_run_as_hang_sub.ppplan p9_instance_setup::test_run_as_hang_sub ( TargetSpec $nodes, ) { $nodes.apply_prep apply($nodes) {notice("hi") }}Then called it like thisbolt plan run p9_instance_setup::test_run_as_hang_top --nodes 10.234.0.19 --user centos --private-key ~/.ssh/id_rsa-acceptance --tty --no-host-key-checkHere is the output:Starting: plan p9_instance_setup::test_run_as_hang_topStarting: plan p9_instance_setup::test_run_as_hang_subStarting: install puppet and gather facts on 10.234.0.19Finished: install puppet and gather facts with 0 failures in 9.0 secStarting: apply catalog on 10.234.0.19I have to control C because it is permanently hung. If I add --run-as root to the bolt call like this:bolt plan run p9_instance_setup::test_run_as_hang_top --nodes 10.234.0.19 --user centos --private-key ~/.ssh/id_rsa-acceptance --tty --no-host-key-check --run-as rootIt works just fine, and reasonably fast.Starting: plan p9_instance_setup::test_run_as_hang_topStarting: plan p9_instance_setup::test_run_as_hang_subStarting: install puppet and gather facts on 10.234.0.19Finished: install puppet and gather facts with 0 failures in 8.88 secStarting: apply catalog on 10.234.0.19Finished: apply catalog with 0 failures in 11.21 secFinished: plan p9_instance_setup::test_run_as_hang_sub in 20.1 secFinished: plan p9_instance_setup::test_run_as_hang_top in 20.11 secPlan completed successfully with no resultThe _run_as root in the run_plan call doesn't have to be there to reproduce the problem. But since that plan is going to be doing an apply it seems like it should need it.Also the reason I can't just do run-as root on the command line for my real use case is due to this bug: BOLT-1321 which causes my local run_command to fail if I have run-as root.Real use case:We have been using a bolt plan to setup a p9 instance for use in running performance tests. It sets up the software, creates a user that matches the current user and copies up a lot of account configuration files so that the user can run just like they do from their mac. To do that it has to run a command running whoami to find out the user name to create on the box. That command fails if run-as root is given starting in 1.20 (BOLT-1321). The effort is split up into multiple plans because initially we want to setup software and the user. Later we might want to add an additional user, or update user config files, but not change the software. Or we might want to update the software but not touch the user. So basically there is a top level plan that calls two sub plans th
Jira (BOLT-1322) plan calling a plan does an apply hangs unless original plan call is run-as root
Title: Message Title
Randell Pelak created an issue
Puppet Task Runner / BOLT-1322
plan calling a plan does an apply hangs unless original plan call is run-as root
Issue Type:
Bug
Assignee:
Unassigned
Created:
2019/05/20 9:51 AM
Priority:
Normal
Reporter:
Randell Pelak
I created two plans to reproduce this from a real use case. test_run_as_hang_top.pp plan p9_instance_setup::test_run_as_hang_top ( TargetSpec $nodes, ) { run_plan(p9_instance_setup::test_run_as_hang_sub,'nodes' => $nodes, '_run_as' => 'root') } test_run_as_hang_sub.pp plan p9_instance_setup::test_run_as_hang_sub ( TargetSpec $nodes, ) { $nodes.apply_prep apply($nodes) { notice("hi") } } Then called it like this bolt plan run p9_instance_setup::test_run_as_hang_top --nodes 10.234.0.19 --user centos --private-key ~/.ssh/id_rsa-acceptance --tty --no-host-key-check Here is the output: Starting: plan p9_instance_setup::test_run_as_hang_top Starting: plan p9_instance_setup::test_run_as_hang_sub Starting: install puppet and gather facts on 10.234.0.19 Finished: install puppet and gather facts with 0 failures in 9.0 sec Starting: apply catalog on 10.234.0.19 I have to control C because it is permanently hung. If I add --run-as root to the bolt call like this: bolt plan run p9_instance_setup::test_run_as_hang_top --nodes 10.234.0.19 --user centos --private-key ~/.ssh/id_rsa-acceptance --tty --no-host-key-check --run-as root It works just fine, and reasonably fast. Starting: plan p9_instance_setup::test_run_as_hang_top Starting: plan p9_instance_setup::test_run_as_hang_sub Starting: install puppet and gather facts on 10.234.0.19 Finished: install puppet and gather facts with 0 failures in 8.88 sec Starting: apply catalog on 10.234.0.19 Finished: apply catalog with 0 failures in 11.21 sec Finished: plan p9_instance_setup::test_run_as_hang_sub in 20.1 sec Finished: plan p9_instance_setup::test_run_as_hang_top in 20.11 sec Plan completed successfully with no result The _run_as root in the run_plan call doesn't have to be there to reproduce the problem. But since that plan is going to be doing an apply it seems like it should need it. Also the reason I can't just do run-as root on the command line for my real use case is
Jira (BOLT-1321) running commands on localhost from a plan run as root fails starting with 1.20
Title: Message Title Randell Pelak updated an issue Puppet Task Runner / BOLT-1321 running commands on localhost from a plan run as root fails starting with 1.20 Change By: Randell Pelak Team: Bolt Issue Type: Improvement Bug Add Comment This message was sent by Atlassian JIRA (v7.7.1#77002-sha1:e75ca93) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-bugs/JIRA.309415.1558363198000.12292.1558371120444%40Atlassian.JIRA. For more options, visit https://groups.google.com/d/optout.
Jira (BOLT-1321) running commands on localhost from a plan run as root fails starting with 1.20
Title: Message Title
Randell Pelak created an issue
Puppet Task Runner / BOLT-1321
running commands on localhost from a plan run as root fails starting with 1.20
Issue Type:
Improvement
Assignee:
Unassigned
Created:
2019/05/20 7:39 AM
Priority:
Normal
Reporter:
Randell Pelak
I have a plan that sets up p9 instances with software and users setting. It runs whoami on the local host so it knows what user to create on the instance. This worked fine with John on 1.19 on linux. But with 1.20 it is failing for me. I personally verified it worked on 1.14 and upgraded to 1.20 on my mac and saw it fail with this error {“node”:“localhost”,“target”:“localhost”,“action”:null,“object”:null,“status”:“failure”,“result”:{“_error”:{“kind”:“puppetlabs.tasks/escalate-error”,“msg”:“Sudo password for user randell was not provided for localhost”,“details”:{},“issue_code”:“NO_PASSWORD”}}} This is the line in the plan that fails. $result_whoami = run_command('whoami',"localhost",'_catch_errors' => true) Just put that line in a plan Here is the plan invocation bolt plan run p9_instance_setup::test_whoami --nodes 10.234.0.19 --user centos --private-key ~/.ssh/id_rsa-acceptance --tty --no-host-key-check --debug --run-as root The workaround is to remove the --run-as root. While that works to get the command to run. The rest of my flow doesn't... which I will file a different ticket about.
Add Comment
Jira (BOLT-1314) tasks-hands-on-lab writing plan page improvements
Title: Message Title Randell Pelak created an issue Puppet Task Runner / BOLT-1314 tasks-hands-on-lab writing plan page improvements Issue Type: Improvement Assignee: Unassigned Created: 2019/05/16 9:08 AM Priority: Normal Reporter: Randell Pelak ON this page https://github.com/puppetlabs/tasks-hands-on-lab/tree/master/07-writing-plans This text: Use plans when you want to run several commands together across multiple nodes. For instance to remove a node from a load balancer before you deploy the new version of the application, or to clear a cache after you re-index a search engine. could use some improvement. When read it, my first thought was... tasks can already run several commands across multiple nodes. But I think what is trying to be communicated is that different sets of commands can be run on different nodes from one plan. Not sure how to make it say that though. Might need a docs person. Also, the other big win for plans is being able to apply puppet code, which should be mentioned in this section. And in the examples, the first thing I noticed is that the output of commands and tasks doesn't show up. This should be mentioned somewhere in text on this page because as a reader it was really obvious and I looked twice for something that explained why the output was missing (even though I already know roughly why, I thought I had missed a section). Probably mentioning that getting at the output is covered in advanced plans or something...
Jira (BOLT-1305) tasks-hands-on-lab writing tasks page improvements
Title: Message Title Randell Pelak created an issue Puppet Task Runner / BOLT-1305 tasks-hands-on-lab writing tasks page improvements Issue Type: Improvement Assignee: Unassigned Created: 2019/05/15 4:28 PM Priority: Normal Reporter: Randell Pelak There is no ruby example, seems like since ruby is our main language we should have an example for that. Also, most readers will only read the section on the language they use. So each example should be as complete as possible. The way it reads now, it gives additional learnings in each section per language, but the learnings are general to all tasks. Like I skipped the powershell section because I don't do powershell or even work in windows. But there is unique and interesting content in the powershell section that I would miss if I didn't read it. The python section has some tidbits about the special _output key buried in the python code. Ideally there would be either a general section with all the info followed by 4 complete examples that show all the information learned on the page, or there would be 4 pages, one per language so the user can pick the one they want and get all the information. Add Comment
Jira (BOLT-889) Upper case letters in hostname confuse bolt
Title: Message Title Randell Pelak commented on BOLT-889 Re: Upper case letters in hostname confuse bolt I suspect all that needs to be done is lowercasing the hostname... Add Comment This message was sent by Atlassian JIRA (v7.7.1#77002-sha1:e75ca93) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (BOLT-889) Upper case letters in hostname confuse bolt
Title: Message Title Randell Pelak created an issue Puppet Task Runner / BOLT-889 Upper case letters in hostname confuse bolt Issue Type: Task Assignee: Unassigned Created: 2018/10/02 12:02 PM Priority: Normal Reporter: Randell Pelak Create an entry in /etc/hosts like testRunner. clear out the known_hosts file of any entries for the host. ssh testRunner to get it into the known_hosts file the known_hosts file will lower case the name. then run this and see the issue ➜ ~ bolt command run 'echo hi' --nodes testRunner --user centos --private-key ~/.ssh/id_rsa-acceptance Started on testRunner... Failed on testRunner: Host key verification failed for testRunner: fingerprint c7:bd:cf:a9:61:41:f3:bc:31:b6:6d:ee:86:9c:5b:36 is unknown for "testRunner,10.234.3.65" Failed on 1 node: testRunner Ran on 1 node in 0.21 seconds seems like other commands like ssh must lower case the name before checking the known_hosts file or something. Add Comment
Jira (BOLT-57) Download a file
Title: Message Title Randell Pelak commented on BOLT-57 Re: Download a file Charlie Sharpsteen yeah, that would be plan A. But if we have a fancy download feature. We aren't at the point we are implementing that part just yet. Our first rev will probably just assume it hasn't changed since we put it there. But it isn't too far out now that we will want to verify that assumption... Add Comment This message was sent by Atlassian JIRA (v7.7.1#77002-sha1:e75ca93) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (BOLT-57) Download a file
Title: Message Title Randell Pelak commented on BOLT-57 Re: Download a file was asked to put my use case in here. For ref arch setup, we expect to be running on a neutral box and setting up a ref arch. But we need to allow it to be done in stages for various reasons. Once we have uploaded the pe.conf to the master in the early stages, if the user stops, and then later runs the later stages, we need to get the pe.conf from the master so that we are sure we are using the latest copy. We may have to modify it and send it back as well, so we need the full contents of the file to avoid losing any helpful comments that anyone/anything may have added. Add Comment This message was sent by Atlassian JIRA (v7.7.1#77002-sha1:e75ca93) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (BOLT-619) Use bolt gem like a libaray
Title: Message Title Randell Pelak created an issue Puppet Task Runner / BOLT-619 Use bolt gem like a libaray Issue Type: Task Assignee: Unassigned Created: 2018/06/26 3:52 PM Priority: Normal Reporter: Randell Pelak as a automation dev i want to call bolt from inside my ruby code using bolt as a library so that I don't have to parse bolts text output in my code (in case it changes slightly or what not). and so that I am insulated as much as I can be from minor bolt changes. Add Comment This message was sent by Atlassian JIRA (v7.7.1#77002-sha1:e75ca93)
Jira (PDOC-194) investigate using modules to replace current script automation
Title: Message Title Randell Pelak created an issue Puppet Strings / PDOC-194 investigate using modules to replace current script automation Issue Type: Task Assignee: Unassigned Created: 2017/12/13 11:58 AM Priority: Normal Reporter: Randell Pelak Add Comment This message was sent by Atlassian JIRA (v7.0.2#70111-sha1:88534db) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more option
Jira (PUP-7900) Can't set agent env back to production with CLI
Title: Message Title Randell Pelak created an issue Puppet / PUP-7900 Can't set agent env back to production with CLI Issue Type: Bug Assignee: Unassigned Created: 2017/09/01 2:20 PM Priority: Normal Reporter: Randell Pelak I have a PE master/agent setup. I can log onto the agent and set the environment to anything I want (doesn't have to exist on the master, but in my case did). But after I do the CLI will not let me change it back to production. And it won't even let me ask it what the environment is. I can recover from this by editing the puppet.conf manually on the agent. logged onto an agent and ran this... [root@mq0vlyukbz5upn8 ~]# puppet config print environment production [root@mq0vlyukbz5upn8 ~]# puppet config set environment nc_orch_agent_environment_settings --section main [root@mq0vlyukbz5upn8 ~]# puppet config print environment /opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/environments.rb:38:in `get!': Could not find a directory environment named 'nc_orch_agent_environment_settings' anywhere in the path: /etc/puppetlabs/code/environments. Does the directory exist? (Puppet::Environments::EnvironmentNotFound) from /opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/application_support.rb:29:in `push_application_context' from /opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/application.rb:346:in `run' from /opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/util/command_line.rb:132:in `run' from /opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/util/command_line.rb:72:in `execute' from /opt/puppetlabs/puppet/bin/puppet:5:in `' [root@mq0vlyukbz5upn8 ~]# puppet config set environment production --section main /opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/environments.rb:38:in `get!': Could not find a directory environment named 'nc_orch_agent_environment_settings' anywhere in the path: /etc/puppetlabs/code/environments. Does the directory exist? (Puppet::Environments::EnvironmentNotFound) from /opt/puppetlabs/puppet/lib/ruby/v
Jira (PUP-7778) puppet master --configprint logdir give s directory of no use
Title: Message Title Randell Pelak created an issue Puppet / PUP-7778 puppet master --configprint logdir give s directory of no use Issue Type: Task Assignee: Unassigned Created: 2017/07/13 2:20 PM Priority: Normal Reporter: Randell Pelak on a normal monolithic install of PE it returns this root@gfdxbk6b87s3nyd ~]# puppet master --configprint logdir /var/log/puppetlabs/puppet But there is absolutely nothing in that dir. Either it should be fixed to give something of use (probably puppetserver log dir) Or it should be removed so as not to cause confusion for our customers. Add Comment This message was sent by Atlassian JIRA (v6.4.14#64029-sha1:ae256fe)
Jira (FACT-1441) Add "cloud" fact that identifies Azure
Title: Message Title Randell Pelak updated an issue Facter / FACT-1441 Add "cloud" fact that identifies Azure Change By: Randell Pelak QA Risk Assessment Reason: resource limitations QA Risk Assessment: No Action Add Comment This message was sent by Atlassian JIRA (v6.4.14#64029-sha1:ae256fe) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at https://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
