date:20160128

Jira (HI-496) Hiera subkeys lookup should be configurable

2016-01-28 Thread Henrik Lindberg (JIRA)

Title: Message Title
 
 
 
 
 
 
 
 
 
 
  
 
 Henrik Lindberg updated an issue 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
 Hiera /  HI-496 
 
 
 
  Hiera subkeys lookup should be configurable  
 
 
 
 
 
 
 
 
 

Change By:
 
 Henrik Lindberg 
 
 
 

Issue Type:
 
 Bug Improvement 
 
 
 
 
 
 
 
 
 
 
 
 

 
 Add Comment 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
 
 
 

 This message was sent by Atlassian JIRA (v6.4.12#64027-sha1:e3691cc) 
 
 
 
 
  
 
 
 
 
 
 
 
 
   





-- 
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 (HI-496) Hiera subkeys lookup should be configurable

2016-01-28 Thread Henrik Lindberg (JIRA)

Title: Message Title

Henrik Lindberg commented on HI-496

Re: Hiera subkeys lookup should be configurable

I understand the pain but that will be very difficult to achieve as the defaults are using subkey lookup to get into trusted facts. Note that '.' in keys were never intended to be supported, they just happened to work.
Since this has been out now for quite some time, and there has only been one earlier issue-report where this was troublesome enough to file a ticket which we closed that with a Won't Fix (it did suggest we revert the change though), I am also going to close this the same way.
What you can do, if you are on one of the latest versions of puppet is to write a wrapper hiera backend. We now support that a hiera backend can be responsible for interpretation of subkeys. It needs to have a method that declares that it wants to do subkey handling on its own, and then the keys will be passed verbatim to the backend (instead of now, being interpreted by hiera itself).
Once you have changed all of the keys with a period in them, you can change back to the standard backend. If you are interested in doing this, I can point you to the ticket that describes how it works.

Add Comment

This message was sent by Atlassian JIRA (v6.4.12#64027-sha1:e3691cc)

--
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 (PUP-5662) Update language spec reg. Hash data type being ordered

2016-01-28 Thread Nicholas Fagerlund (JIRA)

Title: Message Title
 
 
 
 
 
 
 
 
 
 
  
 
 Nicholas Fagerlund commented on  PUP-5662 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
  Re: Update language spec reg. Hash data type being ordered  
 
 
 
 
 
 
 
 
 
 
Reviewed and created DOC-2508. 
 
 
 
 
 
 
 
 
 
 
 
 

 
 Add Comment 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
 
 
 

 This message was sent by Atlassian JIRA (v6.4.12#64027-sha1:e3691cc) 
 
 
 
 
  
 
 
 
 
 
 
 
 
   





-- 
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 (PUP-5752) Replace win32-process calls with internal API implementations that are wide-string compatible

2016-01-28 Thread Glenn Sarti (JIRA)

Title: Message Title
 
 
 
 
 
 
 
 
 
 
  
 
 Glenn Sarti commented on  PUP-5752 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
  Re: Replace win32-process calls with internal API implementations that are wide-string compatible  
 
 
 
 
 
 
 
 
 
 
Ryan Gard I haven't created any repro instructions yet. That will be the first task. My instinct is that it will require both given that it touches some core aspects of Puppet on Windows (install.rb pidlock.rb) 
 
 
 
 
 
 
 
 
 
 
 
 

 
 Add Comment 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
 
 
 

 This message was sent by Atlassian JIRA (v6.4.12#64027-sha1:e3691cc) 
 
 
 
 
  
 
 
 
 
 
 
 
 
   





-- 
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 (PDB-2366) PQL: Create command line examples in docs for PQL

2016-01-28 Thread Kenneth Barber (JIRA)

Title: Message Title
 
 
 
 
 
 
 
 
 
 
  
 
 Kenneth Barber created an issue 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
 PuppetDB /  PDB-2366 
 
 
 
  PQL: Create command line examples in docs for PQL  
 
 
 
 
 
 
 
 
 

Issue Type:
 
  Task 
 
 
 

Assignee:
 

 Unassigned 
 
 
 

Created:
 

 2016/01/28 8:51 AM 
 
 
 

Fix Versions:
 

 PDB 4.0.0 
 
 
 

Priority:
 
  Normal 
 
 
 

Reporter:
 
 Kenneth Barber 
 
 
 
 
 
 
 
 
 
 
Right now we don't have a good tutorial for PQL, we should create one (much like the AST tutorial.md). This should also contain CLI examples if possible, right now we don't ship the CLI but we will soon, I presume. 
Lori Landesman, Verne Lindner FYI. 
 
 
 
 
 
 
 
 
 
 
 
 

 
 Add Comment

Jira (PUP-3142) exec type should allow passing of arguments as an array rather than a string

2016-01-28 Thread John Bollinger (JIRA)

Title: Message Title

John Bollinger commented on PUP-3142

Re: exec type should allow passing of arguments as an array rather than a string

I'm uncertain to which provider the OP refers when he says Exec passes the command string to the shell, since that's a provider-specific behavior. Of course, running the command via a shell is exactly what the shell provider should do.
I suppose the OP is referring to the posix provider, whose whole purpose is to bypass the shell. Puppet currently implements that provider in a manner that seems to end up invoking Kernel.exec with the single-string form of the command, and, as recently came up on puppet-users, that sometimes results in the command being executed via a shell, contrary to documentation. That constitutes a bona fide bug, either in the implementation or in the docs. Inasmuch as bypassing the shell is supposed to be the distinguishing characteristic of the posix provider, I think it's hard to attribute the bug elsewhere. I therefore suggest elevating this issue to "bug" status.
Indeed, the posix provider is in a bit of a bind here, because the command is Exec's namevar, and so (I think) it must be a string. But that provider's intended and documented behavior more or less requires the command to be presented as an array – the user must be responsible for word splitting, (non-)quoting, etc., because the shell is not supposed to be involved.
If it were possible, I think it would be best to allow the command attribute to be given as an array, whose elements are ultimately passed as multiple individual arguments to Kernel.exec without interpretation (for the posix provider). Even then, a correct, single-element command array could yield the wrong behavior under unfavorable (and fairly unlikely) circumstances, but in almost all cases it would do the right thing. Other providers could handle array commands as appropriate for themselves – for example, the shell provider might joining elements with whitespace, or even with semicolons, and pass the result to the shell. Of course, an array for the resource title means something completely different, and perhaps that is an additional roadblock in the way of taking this approach.
If making the command itself be an array is indeed not possible, then there needs to be some alternative way to provide arguments separately from the command string, such as the one proposed in this issue. The posix provider cannot work correctly without.

Add Comment

Jira (PUP-5752) Replace win32-process calls with internal API implementations that are wide-string compatible

2016-01-28 Thread Ryan Gard (JIRA)

Title: Message Title
 
 
 
 
 
 
 
 
 
 
  
 
 Ryan Gard updated an issue 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
 Puppet /  PUP-5752 
 
 
 
  Replace win32-process calls with internal API implementations that are wide-string compatible  
 
 
 
 
 
 
 
 
 

Change By:
 
 Ryan Gard 
 
 
 

QA Risk Assessment Reason:
 
 Developer requested acceptance testing. 
 
 
 

QA Highest Test Level:
 
 Acceptance 
 
 
 

QA Risk Assessment:
 
 High 
 
 
 

QA Status:
 
 Reviewed 
 
 
 
 
 
 
 
 
 
 
 
 

 
 Add Comment 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
 
 
 

 This message was sent by Atlassian JIRA (v6.4.12#64027-sha1:e3691cc) 
 
 
 
 
  
 
 
 
 
 
 
 
 
   





-- 
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

Jira (PUP-5762) As manifest author I want to get errors early

2016-01-28 Thread Henrik Lindberg (JIRA)

Title: Message Title

Henrik Lindberg created an issue

Puppet / PUP-5762

As manifest author I want to get errors early

Issue Type:

Epic

Assignee:

Unassigned

Created:

2016/01/28 9:14 AM

Priority:

Normal

Reporter:

Henrik Lindberg

As an author of manifests I want to get errors at parse time rather than at evaluation time.
This will give me up front knowledge of more issues that needs to be fixed in our manifests without me having to do a full compilation and run for a node. This will save me time, and will increase quality as I expect to be able to catch more errors with parse validation as code is being checked in. (where it is impractical and expensive for us to run full acceptance tests).
I also expect that the quality of the error messages will be higher, as I expect that type inference will be done in such a way that it not only tells me what it expected the type of a value to be, but also why it expected that. This will save additional time as it makes it easier to understand what it wrong, and how to fix the problem.
I also expect that the parse time validation validates all code paths in contrast to run-time errors that only occur when conditional logic made the code path with the problem be evaluated. For me that means I will get increased confidence in the quality of our manifests.

1 2 >

1 - 100 of 124 matches

Mail list logo