Jira (FACT-2128) fact mountpoints does not correctly calculates mountpoint capacity
Title: Message Title
Valentyna updated an issue
Facter / FACT-2128
fact mountpoints does not correctly calculates mountpoint capacity
Change By:
Valentyna
I have (root /) mountpoint my df output looks:root@test:~# df /dev/sdb2 Filesystem 1K-blocks Used Available Use% Mounted on /dev/sdb2 19555608 15911760 2627432 86% /df displays correct data as {color:#14892c}*86%*{color} used on this mountpoint.Fact mountpoints displays:root@test:~# facter mountpoints./{ available => "3.48 GiB", available_bytes => 3731296256, capacity => "81.37%", device => "/dev/sdb2", filesystem => "ext4", options => [ "rw", "relatime", "errors=remount-ro", "stripe=32624", "data="" ], size => "18.65 GiB", size_bytes => 20024942592, used => "15.17 GiB", used_bytes => 16293646336 }It displays only {color:#d04437}*81.37%*{color} of used space.I`ve read df manpage on [http://manpages.ubuntu.com/manpages/trusty/man1/df.1posix.html] which describes where to get differrent types of spaces and how to calculate used space. As a result I`ve created cpp file which correctly calculates available, free and used space. [^disk_usage.cpp] {color:#14892c} I `ve get output:{color} fragment size 4096 blocks size in f_frsize units 4888902 free blocks 910962 free blocks for unprivileged users: 656858 total 19555608 available: 2627432 used: 15911760 *usedpercent: 85.827690*
Add Comment
This message was sent by Atlassian JIRA (v7.7.1#77002-sha1:e75ca93)
Jira (FACT-2128) fact mountpoints does not correctly calculates mountpoint capacity
Title: Message Title Valentyna updated an issue Facter / FACT-2128 fact mountpoints does not correctly calculates mountpoint capacity Change By: Valentyna Attachment: disk_usage.cpp 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.335834.1574154809000.42703.1574407380150%40Atlassian.JIRA.
Jira (FACT-2128) fact mountpoints does not correctly calculates mountpoint capacity
Title: Message Title
Valentyna updated an issue
Facter / FACT-2128
fact mountpoints does not correctly calculates mountpoint capacity
Change By:
Valentyna
I have (root /) mountpoint my df output looks:root@test:~# df /dev/sdb2 Filesystem 1K-blocks Used Available Use% Mounted on/dev/sdb2 19555608 15911760 2627432 86% /df displays correct data as {color:#14892c}*86%*{color} used on this mountpoint.Fact mountpoints displays:root@test:~# facter mountpoints./{ available => "3.48 GiB", available_bytes => 3731296256, capacity => "81.37%", device => "/dev/sdb2", filesystem => "ext4", options => [ "rw", "relatime", "errors=remount-ro", "stripe=32624", "data=""> ], size => "18.65 GiB", size_bytes => 20024942592, used => "15.17 GiB", used_bytes => 16293646336 }It displays only {color:#d04437}*81.37%*{color} of used space.I`ve read df manpage on [http://manpages.ubuntu.com/manpages/trusty/man1/df.1posix.html] which describes where to get differrent types of spaces and how to calculate used space. As a result I`ve created cpp file which correctly calculates available, free and used space. #include #include#include #include#includeint main(int argc, char* argv [ ^disk_usage.cpp ] ) { struct statfs stats; statfs("/", ); printf("fragment size %lu\n", stats.f_frsize); printf("blocks size in f_frsize units %lu\n", stats.f_blocks); printf("free blocks %lu\n", stats.f_bfree); printf("free blocks for unprivileged users: %lu\n", stats.f_bavail); unsigned long *total* = stats.f_blocks * stats.f_frsize / 1024; unsigned long *available* = stats.f_bavail * stats.f_frsize / 1024; unsigned long *free* = stats.f_bfree * stats.f_frsize / 1024; unsigned long *used* = total - free; float uf = used + available; float usedpercent = used / uf * 100; printf("total %lu\n", total); printf("available: %lu\n", available); printf("used: %lu\n", used); printf("percent: %f\n", usedpercent);} {color:#14892c} {color:#59afe1} I`ve get output:{color} {color}{color:#33} fragment size 4096blocks size in f_frsize units 4888902free blocks 910962free blocks for unprivileged users: 656858total 19555608available: 2627432used: 15911760 {color:#14892c} *usedpercent: 85.827690* {color}{color}
Add
Jira (FACT-2128) fact mountpoints does not correctly calculates mountpoint capacity
Title: Message Title
Valentyna updated an issue
Facter / FACT-2128
fact mountpoints does not correctly calculates mountpoint capacity
Change By:
Valentyna
I have (root /) mountpoint my df output looks:root@test:~# df /dev/sdb2Filesystem 1K-blocks Used Available Use% Mounted on/dev/sdb2 19555608 15877636 2661556 15911760 2627432 86% /df displays correct data as {color:#14892c}*86%*{color} used on this mountpoint.Fact mountpoints displays:root@test:~# facter mountpoints./ { available => "3. 51 48 GiB", available_bytes => 3766226944 3731296256 , capacity => "81. 19 37 %", device => "/dev/sdb2", filesystem => "ext4", options => [ "rw", "relatime", "errors=remount-ro", "stripe=32624", "data=""> ], size => "18.65 GiB", size_bytes => 20024942592, used => "15. 14 17 GiB", used_bytes => 16258715648 16293646336 }It displays only {color:#d04437}*81. 19 37 %*{color} of used space.I think `ve read df manpage on [http://manpages.ubuntu.com/manpages/trusty/man1/df.1posix.html] which describes where to solve the problem instead get differrent types of dividing spaces and how to calculate used space. As a result I`ve created cpp file which correctly calculates available, free and used space.#include #include#include #include#includeint main(int argc, char * argv[]) { color struct statfs stats; statfs("/", ); printf("fragment size %lu\n", stats.f_frsize); printf("blocks size in f_frsize units %lu\n", stats.f_blocks); printf("free blocks %lu\n", stats.f_bfree); printf("free blocks for unprivileged users : #d04437}Used÷1K %lu\n", stats.f_bavail); unsigned long *total* = stats.f_blocks * stats.f_frsize / 1024; unsigned long *available* = stats.f_bavail * stats.f_frsize / 1024; unsigned long *free* = stats.f_bfree * stats.f_frsize / 1024; unsigned long *used* = total - blocks free; float uf = used + available; float usedpercent = used / uf * 100; printf("total %lu\n", total); printf("available: %lu\n", available); printf("used: %lu\n", used); printf("percent: %f\n", usedpercent);} {color :#14892c } * 15877632÷19555608×100= {color:# FF 59afe1 } *81,19%* I`ve get output: {color} , should divide {color :#14892c } *Available÷1K-blocks* {color :#33 } ex. 100−2661560÷ fragment size 4096blocks size in f_frsize units 4888902free blocks 910962free blocks for unprivileged users: 656858total 19555608 ×100= available: 2627432used: 15911760 {color:#14892c}* 86,38%* usedpercent: 85 . 827690* {color} {color}
Jira (PUP-10150) Ruby stacktraces no longer interleave Puppet Code stacktraces
Title: Message Title Glenn Sarti commented on PUP-10150 Re: Ruby stacktraces no longer interleave Puppet Code stacktraces Something else I noticed is that the new Stack uses line number 0 for the entrypoint into a manifest which is a change of behaviour. This is important because Puppet uses Base 1 line numbers so a line number of 0 isn't valid. Perhaps nil? or even ignore it? 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.336155.1574344871000.42695.1574401680578%40Atlassian.JIRA.
Jira (PUP-10150) Ruby stacktraces no longer interleave Puppet Code stacktraces
Title: Message Title Glenn Sarti commented on PUP-10150 Re: Ruby stacktraces no longer interleave Puppet Code stacktraces > Is that the value in a Puppet only stack or both interleaved? Puppet stack probably. Maybe more complicated but perhaps `-debug` shows puppet stack and `-trace` shows interleaved? 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.336155.1574344871000.42685.1574399400260%40Atlassian.JIRA.
Jira (PUP-10150) Ruby stacktraces no longer interleave Puppet Code stacktraces
Title: Message Title Justin Stoller commented on PUP-10150 Re: Ruby stacktraces no longer interleave Puppet Code stacktraces Debugging Control Repos, seeing which manifests call others, is very useful. Is that the value in a Puppet only stack or both interleaved? 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.336155.1574344871000.42681.1574398140207%40Atlassian.JIRA.
Jira (PUP-10150) Ruby stacktraces no longer interleave Puppet Code stacktraces
Title: Message Title Justin Stoller commented on PUP-10150 Re: Ruby stacktraces no longer interleave Puppet Code stacktraces re: the last puppet function isn't in the stack with the extension of ExternalFileError. I have a hunch that the error which `fail` is throwing (which is a ParseError and should contain the correct PuppetStack) is being caught, wrapped, and re-thrown between the fail throwing it and the last include being called. Maybe in AST.safeevaluate? I think that is a solvable problem though w/o removing the ensure and I'd be happy to do more spelunking after we get some more comment from the community. 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.336155.1574344871000.42675.1574398080802%40Atlassian.JIRA.
Jira (PUP-10150) Ruby stacktraces no longer interleave Puppet Code stacktraces
Title: Message Title Glenn Sarti commented on PUP-10150 Re: Ruby stacktraces no longer interleave Puppet Code stacktraces As for the questions in the puppet-dev email: > Is interleaving the Puppet stack trace into the Ruby stack trace valuable to most users (and should go back to being the default)? It's very useful as a Puppet developer, and for Customer Support escalating to engineering. But as a beginner/intermediate user, the stack trace from ruby is over-whelming. > Are there workflows where you'd like to see just one (the Puppet stack), the other (Ruby), or both (ie, do we need more trace options, and if so how important are they relative to each other)? Debugging Control Repos, seeing which manifests call others, is very useful. 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.336155.1574344871000.42671.1574395380298%40Atlassian.JIRA.
Jira (PUP-10150) Ruby stacktraces no longer interleave Puppet Code stacktraces
Title: Message Title Glenn Sarti commented on PUP-10150 Re: Ruby stacktraces no longer interleave Puppet Code stacktraces I like the idea of extending ExternalFileError class I did a quick proof of concept for it C:\Source\puppet [master ≡ +0 ~4 -0 !]> be puppet apply tmp\test.pp Warning: Facter: Fact resolution fact='puppet_classes', resolution='' resolved to an invalid value: Expected all to be one of [Integer, Float, TrueClass, FalseClass, NilClass, String, Array, Hash], but was Symbol STACK PUSH STACK CALLING #>.evaluate Puppet::Pops::Evaluator::EvaluatorImpl STACK PUSH STACK CALLING #<#:0x076a4d00 @closure_scope=nil, @loader=(ModuleLoader::FileBased 'puppet_system' '')>.call include STACK PUSH STACK CALLING #<#:0x076a4d00 @closure_scope=nil, @loader=(ModuleLoader::FileBased 'puppet_system' '')>.call include STACK PUSH STACK CALLING #<#:0x076874a8 @closure_scope=nil, @loader=(ModuleLoader::FileBased 'puppet_system' '')>.call fail CALLING function 3x function_fail
Jira (PUP-10150) Ruby stacktraces no longer interleave Puppet Code stacktraces
Title: Message Title
Glenn Sarti commented on PUP-10150
Re: Ruby stacktraces no longer interleave Puppet Code stacktraces
I'll add some more context as to how I found this. The VSCode extension offers a debugging facility. As part of that, when an exception occurs it queries the current call stack. Internally in the Debug Server, I've monkey patched the compiler so I can trap the exception and then query the available Puppet Stack. As per my original ticket title, because the PuppetStack is popped BEFORE the exception is handled I couldn't get access to the Puppet call stack. This behaviour is different to a regular Ruby Stack, where the call stack is not modified. Now I know that my use case is far from normal, and that I'm using monkey patches and private APIs, so any breakages aren't really a Puppet problem. The missing tracing information in the stacktrace as all I could think of from a regular user point of view. Given this nested manifest
class nest1 {
fail('somethinng')
}
class nest2 {
include nest1
}
include nest2
And some basic puts debugging STACK PUSH - An object is pushed onto the PuppetStack STACK CALLING - PuppetStack is calling the actual code. STACK POP - An object is popped onto the PuppetStack So you can see the stack calling the evaluator, then the include function twice, and finally the fail function
Jira (FACT-2096) Windows system32 environment variable issue after installation of "RDS-RD-Server"
Title: Message Title Jarret Lavallee updated an issue Facter / FACT-2096 Windows system32 environment variable issue after installation of "RDS-RD-Server" Change By: Jarret Lavallee CS Priority: Needs Priority Reviewed 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.332946.1572508394000.42515.1574377200386%40Atlassian.JIRA.
Jira (PUP-10039) Add serverlist resolver
Title: Message Title Melissa Stone assigned an issue to Melissa Stone Puppet / PUP-10039 Add serverlist resolver Change By: Melissa Stone Assignee: Melissa Stone 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.326143.1569367897000.42116.1574364120176%40Atlassian.JIRA.
Jira (PUP-10039) Add serverlist resolver
Title: Message Title Melissa Stone updated an issue Puppet / PUP-10039 Add serverlist resolver Change By: Melissa Stone Sprint: Coremunity Hopper Platform Core KANBAN 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.326143.1569367897000.42114.1574364060860%40Atlassian.JIRA.
Jira (PUP-10150) Ruby stacktraces no longer interleave Puppet Code stacktraces
Title: Message Title Justin Stoller commented on PUP-10150 Re: Ruby stacktraces no longer interleave Puppet Code stacktraces I've updated the title with what I think is the user facing effect. wrt the concern about not having a puppet stack available at the time of error formatting I think we could updated `ExternalFileError` to store the `PuppetStack.stacktrace` on creation and then extend the formatting to either print the puppet stack, ruby stack, or interleave them based on configuration. I'm unsure how valuable different parts of that work are, so I've also brought this ticket up to the Puppet community mailing list. 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.336155.1574344871000.42068.1574362560285%40Atlassian.JIRA.
Jira (PUP-10150) Ruby stacktraces no longer interleave Puppet Code stacktraces
Title: Message Title Justin Stoller updated an issue Puppet / PUP-10150 Ruby stacktraces no longer interleave Puppet Code stacktraces Change By: Justin Stoller Summary: Ruby stacktraces no longer interleave Puppet Stack Trace is cleared before exception handlers can query it Code stacktraces 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.336155.1574344871000.42049.1574362321173%40Atlassian.JIRA.
Jira (PUP-10150) Puppet Stack Trace is cleared before exception handlers can query it
Title: Message Title Charlie Sharpsteen updated an issue Puppet / PUP-10150 Puppet Stack Trace is cleared before exception handlers can query it Change By: Charlie Sharpsteen Affects Version/s: PUP 6.11.0 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.336155.1574344871000.42006.1574360760617%40Atlassian.JIRA.
Jira (PUP-10150) Puppet Stack Trace is cleared before exception handlers can query it
Title: Message Title Henrik Lindberg commented on PUP-10150 Re: Puppet Stack Trace is cleared before exception handlers can query it Justin Stoller The interleaving is of value for someone on a deep bug hunt in Ruby if/when you want to see both where you ended up and how you got there via intermediate Ruby. This was of value to me when working on some evaluator / call stuff. For puppet users and the typical use of the puppet stack there is no value in the interleaving (they always see the filtered result anyway). However, as you point out, when there is an exception and the ruby stack is dumped out - when things were interleaved you got both at the same time - which sometimes is of value when reporting an issue. Doubt that most puppet users manage to interpret what they are looking at (i.e. won't see the interleaves puppet things, or don't know how to use that). For puppet users, the puppet stack is probably of more value (to find their problems in their code). A thought; not interleaving makes it possible to add information that could not be represented in the Ruby stack - for example also recording the position on the line (i.e. to differentiate between several calls on the same line) if we ever want to do that. 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
Jira (PUP-10149) Systemd provider daemon-reload broken in puppet 6.11.0
Title: Message Title Heston Hoffman commented on PUP-10149 Re: Systemd provider daemon-reload broken in puppet 6.11.0 Will do! 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.335940.157420669.41872.1574358600191%40Atlassian.JIRA.
Jira (PUP-8076) language specification needs to be updated with changes from feature_puppet-tasks
Title: Message Title Alex Dreyer commented on PUP-8076 Re: language specification needs to be updated with changes from feature_puppet-tasks No we haven't but formalizing the features of the plan language is something I'm starting on 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.217205.1508413541000.41864.1574358480165%40Atlassian.JIRA.
Jira (PUP-10097) Protect against binary diffs
Title: Message Title Josh Cooper commented on PUP-10097 Re: Protect against binary diffs Makes sense Ciprian Badescu 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.328673.1570644934000.41839.1574357640613%40Atlassian.JIRA.
Jira (PUP-10150) Puppet Stack Trace is cleared before exception handlers can query it
Title: Message Title Justin Stoller assigned an issue to Justin Stoller Puppet / PUP-10150 Puppet Stack Trace is cleared before exception handlers can query it Change By: Justin Stoller Assignee: Justin Stoller 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.336155.1574344871000.41834.1574357340172%40Atlassian.JIRA.
Jira (PUP-10150) Puppet Stack Trace is cleared before exception handlers can query it
Title: Message Title Justin Stoller commented on PUP-10150 Re: Puppet Stack Trace is cleared before exception handlers can query it Would it be valuable to print the puppet stack as its own trace, or is it the interleaving of them with the ruby code valuable? (Or are there use cases for both?) 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.336155.1574344871000.41824.1574356140108%40Atlassian.JIRA.
Jira (PUP-10150) Puppet Stack Trace is cleared before exception handlers can query it
Title: Message Title Justin Stoller commented on PUP-10150 Re: Puppet Stack Trace is cleared before exception handlers can query it One thing that I wasn't clear from the description, there still is a ruby stack trace with `--trace`, right. ie, this is what I see on master: puppet (master *$%<>) :: be puppet apply broken.pp --trace Warning: Facter: Could not find a default route. Using first non-loopback interface Error: Evaluation Error: Error while evaluating a Function Call, somethinng (file: /Users/justin/Backup/code/work/puppet/broken.pp, line: 3, column: 3) on node localhost /Users/justin/Backup/code/work/puppet/lib/puppet/parser/functions/fail.rb:10:in `block in get_binding' /Users/justin/Backup/code/work/puppet/lib/puppet/parser/functions.rb:206:in `block (2 levels) in newfunction' /Users/justin/Backup/code/work/puppet/lib/puppet/util/profiler/around_profiler.rb:58:in `profile' /Users/justin/Backup/code/work/puppet/lib/puppet/util/profiler.rb:51:in `profile' /Users/justin/Backup/code/work/puppet/lib/puppet/parser/functions.rb:199:in `block in newfunction'
Jira (PUP-10140) puppet service and puppet-agent failing on windows
Title: Message Title Barr Iserloth commented on PUP-10140 Re: puppet service and puppet-agent failing on windows Gheorghe Popescu Yep, it's fixed! Thanks so much! 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.335096.1573682215000.41766.1574353680163%40Atlassian.JIRA.
Jira (FACT-2134) Facter should distinguish between CentOS 8 and CentOS 8 Stream
Title: Message Title John Bollinger created an issue Facter / FACT-2134 Facter should distinguish between CentOS 8 and CentOS 8 Stream Issue Type: Improvement Affects Versions: FACT 3.14.3 Assignee: Unassigned Created: 2019/11/21 7:57 AM Priority: Normal Reporter: John Bollinger CentOS 8 comes in two flavors, distinguished by name and package-release policy. Standard CentOS 8 follows the conventional RHEL versioning and release model, but CentOS Stream follows a rolling-release model that, among other things, makes minor OS version numbers less significant. Presently, Facter's OS-related facts do not distinguish between these, but they should. Behaviors that for regular CentOS 8 are conditional on minor version numbers should have different or no conditions on CentOS [8] Stream, but Facter does not presently provide a means to discriminate between them. It's unclear to me, however, exactly how Facter should present the difference. It's also unclear whether the CentOS project can be expected at any point to moot the issue, say by updating its -release files to include a distinction that Facter picks up with its existing code. Add Comment
Jira (PUP-10150) Puppet Stack Trace is cleared before exception handlers can query it
Title: Message Title
Glenn Sarti created an issue
Puppet / PUP-10150
Puppet Stack Trace is cleared before exception handlers can query it
Issue Type:
Bug
Assignee:
Unassigned
Created:
2019/11/21 6:01 AM
Priority:
Normal
Reporter:
Glenn Sarti
Puppet Version: 6.11.1 Puppet Server Version: N/A OS Name/Version: Windows 10 As part of https://github.com/puppetlabs/puppet/pull/7754 the Puppet Stack Trace feature was modified to use an independent stack trace storing mechanism, however this may have introduced an unforseen behaviour change. Previously users would be able to trace how Puppet has traversed the invocations within a Manifest file. For example int the given manifest
class nest1 {
fail('somethinng')
}
class nest2 {
include nest1
Jira (PUP-10025) puppet describe does not show top-level docs
Title: Message Title David Schmitt updated an issue Puppet / PUP-10025 puppet describe does not show top-level docs Change By: David Schmitt Fix Version/s: PUP 6.y 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.246931.1524479943000.41631.1574344200163%40Atlassian.JIRA.
Jira (PUP-10140) puppet service and puppet-agent failing on windows
Title: Message Title Gheorghe Popescu commented on PUP-10140 Re: puppet service and puppet-agent failing on windows Barr Iserloth is the issue fixed in PE? 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.335096.1573682215000.41534.1574324280819%40Atlassian.JIRA.
