[Ask Puppet Labs - Bug #18191] (Closed) Mobile theme needs some love

[tickets]

Issue #18191 has been updated by Dawn Foster.

Status changed from Accepted to Closed

Cleaning up old bugs. It looks like this is resolved, but if not, you can open 
it as a new ticket here: https://tickets.puppetlabs.com/browse/ASK


Bug #18191: Mobile theme needs some love
https://projects.puppetlabs.com/issues/18191#change-102618

* Author: Dawn Foster
* Status: Closed
* Priority: Normal
* Assignee: Evgeny Fadeev
* Category: 
* Target version: 
* Keywords: 
* Branch: 

The mobile theme is really mangled ... to the point of being mostly unusable.

I tested it on iPhone (Chrome & Safari). 

The mobile theme doesn't need to be perfect. Most people will use the Ask site 
from their computers, but we'd like for it to look decent when people find 
answers via google search or if someone just wants to look at a question and 
answer.


-- 
You have received this notification because you have either subscribed to it, 
or are involved in it.
To change your notification preferences, please click here: 
http://projects.puppetlabs.com/my/account

-- 
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 http://groups.google.com/group/puppet-bugs.
For more options, visit https://groups.google.com/groups/opt_out.

[Ask Puppet Labs - Bug #18252] (Closed) set up staging server for ask.puppetlabs.com

[tickets]

Issue #18252 has been updated by Dawn Foster.

Status changed from Unreviewed to Closed

Cleaning up old bugs. I'm assuming this is resolved: 
https://tickets.puppetlabs.com/browse/ASK


Bug #18252: set up staging server for ask.puppetlabs.com
https://projects.puppetlabs.com/issues/18252#change-102617

* Author: Evgeny Fadeev
* Status: Closed
* Priority: Normal
* Assignee: Kelsey Hightower
* Category: 
* Target version: 
* Keywords: 
* Branch: 

we need a staging env to test improvements in the Q&A site deployment


-- 
You have received this notification because you have either subscribed to it, 
or are involved in it.
To change your notification preferences, please click here: 
http://projects.puppetlabs.com/my/account

-- 
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 http://groups.google.com/group/puppet-bugs.
For more options, visit https://groups.google.com/groups/opt_out.

[Ask Puppet Labs - Bug #18409] (Closed) The use of variable $ id

[tickets]

Issue #18409 has been updated by Dawn Foster.

Status changed from Unreviewed to Closed

Cleaning up old bugs. This looks like it's in the wrong bug tracker. If it's 
still an issue, you can open it as a new ticket here: 
https://tickets.puppetlabs.com


Bug #18409: The use of variable $ id
https://projects.puppetlabs.com/issues/18409#change-102616

* Author: nan wu
* Status: Closed
* Priority: Normal
* Assignee: Zack Smith
* Category: 
* Target version: 
* Keywords: $id
* Branch: 

In my site.pp,file { "C:/XSpeedRunStop/":
 source => "puppet://puppet-test-02/files/XSpeedRunStop",
 recurse => true,
 owner => $id,
 group => $id+"s",
 mode => 777,
 }
But it does not have any reaction when I first performed.when i changed the 
owner => $id to the owner => client-01\administrator,Perform kick command,This 
module performs.Then changed the owner => client-01\administrator to owner => 
$id,To perform kick command again,This module performs.In short, when I first 
execution, use $ id, the module does not perform,This is a bug?


-- 
You have received this notification because you have either subscribed to it, 
or are involved in it.
To change your notification preferences, please click here: 
http://projects.puppetlabs.com/my/account

-- 
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 http://groups.google.com/group/puppet-bugs.
For more options, visit https://groups.google.com/groups/opt_out.

[Ask Puppet Labs - Bug #18797] (Closed) Character / regarded as invalid in certificate

[tickets]

Issue #18797 has been updated by Dawn Foster.

Status changed from Unreviewed to Closed

Closing. Wrong bug tracker. If it's still an issue, you can re-open it as a new 
ticket here: https://tickets.puppetlabs.com


Bug #18797: Character / regarded as invalid in certificate
https://projects.puppetlabs.com/issues/18797#change-102615

* Author: Anonymous
* Status: Closed
* Priority: Urgent
* Assignee: 
* Category: 
* Target version: 
* Keywords: certificate
* Branch: 

Package name: puppet-3.0.2-1.el6.noarch

/ is not accepted as a valid character in puppetmaster certificate. The fix was 
to modify /usr/lib/ruby/site_ruby/1.8/puppet/ssl/base.rb

 INCORRECT:  VALID_CERTNAME = /\A[ -.0-~]+\Z/

 CORRECT:VALID_CERTNAME = /\A[ -.0-~\/]+\Z/

So that / is accepted as a valid char in certificate.

Error encountered: Could not request certificate: Certname [hidden] must not 
contain unprintable or non-ASCII characters


-- 
You have received this notification because you have either subscribed to it, 
or are involved in it.
To change your notification preferences, please click here: 
http://projects.puppetlabs.com/my/account

-- 
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 http://groups.google.com/group/puppet-bugs.
For more options, visit https://groups.google.com/groups/opt_out.

[Ask Puppet Labs - Bug #18914] (Closed) Email subscriptions - don't seem to get email when a question is asked

[tickets]

Issue #18914 has been updated by Dawn Foster.

Status changed from Investigating to Closed

Cleaning up old bugs. I'm assuming this is resolved, but if not, you can open 
it as a new ticket here: https://tickets.puppetlabs.com/browse/ASK


Bug #18914: Email subscriptions - don't seem to get email when a question is 
asked
https://projects.puppetlabs.com/issues/18914#change-102614

* Author: Ken Barber
* Status: Closed
* Priority: High
* Assignee: Evgeny Fadeev
* Category: 
* Target version: 
* Keywords: 
* Branch: 

It seems to me that I only seem to be getting an email when a question is 
answered, not asked. I've subscribed to all the options with 'Immediately':

* Asked by me
* Answered by me
* Individually selected
* Entire forum
* Comments and posts mentioning me

I would have thought 'entire forum' does the trick, but alas no.

For those who really wish to partake in ask this is very helpful, as they can 
jump in and answer when a question is asked. Also, we received some spam this 
morning and it would be faster to action if we receive this through a 
notification ie. email.


-- 
You have received this notification because you have either subscribed to it, 
or are involved in it.
To change your notification preferences, please click here: 
http://projects.puppetlabs.com/my/account

-- 
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 http://groups.google.com/group/puppet-bugs.
For more options, visit https://groups.google.com/groups/opt_out.

[Ask Puppet Labs - Bug #19144] (Closed) Account creation needs captcha-like thingy to at least reduce bots from account creation

[tickets]

Issue #19144 has been updated by Dawn Foster.

Status changed from Accepted to Closed

Cleaning up old bugs. I'm assuming this is resolved, but if not, you can open 
it as a new ticket here: https://tickets.puppetlabs.com/browse/ASK


Bug #19144: Account creation needs captcha-like thingy to at least reduce bots 
from account creation
https://projects.puppetlabs.com/issues/19144#change-102613

* Author: Ken Barber
* Status: Closed
* Priority: Normal
* Assignee: Evgeny Fadeev
* Category: 
* Target version: 
* Keywords: 
* Branch: 

Just talking to llowder on IRC about spam ...

Currently the account creation process for ask can probably be automated by 
bots ... if we added a captcha process during account creation this might 
reduce some of the spam we are seeing, or at least reduce that attack surface 
area.


-- 
You have received this notification because you have either subscribed to it, 
or are involved in it.
To change your notification preferences, please click here: 
http://projects.puppetlabs.com/my/account

-- 
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 http://groups.google.com/group/puppet-bugs.
For more options, visit https://groups.google.com/groups/opt_out.

[Ask Puppet Labs - Bug #19528] (Closed) OpenID sensitive to protocol spec

[tickets]

Issue #19528 has been updated by Dawn Foster.

Status changed from Unreviewed to Closed

Cleaning up old bugs. I'm assuming this is resolved, but if not, you can open 
it as a new ticket here: https://tickets.puppetlabs.com/browse/ASK


Bug #19528: OpenID sensitive to protocol spec
https://projects.puppetlabs.com/issues/19528#change-102612

* Author: Wil Cooley
* Status: Closed
* Priority: Normal
* Assignee: Evgeny Fadeev
* Category: 
* Target version: 
* Keywords: 
* Branch: 

I just tried to login with my OpenID without the protocol spec ("https://";), 
which I guess I seem to do regularly. The site forwarded me to my OpenID 
provider and I logged in but upon coming back I got a bare white `502 Bad 
Gateway` nginx error (I regret that I did not capture the whole error, but 
there was not much more than that).

I went through again, this time including the protocol spec and I was taken to 
a user registration page, which I assume is the expected behavior.

Without clicking "Signup" on the registration page, I went back to the sign-in 
page, entered my OpenID w/o protocol spec again, (I assume) did the bounce 
through my OpenID provider, and this time was taken back to the PL-themed 
Askbot sign-in page, now with the error banner at the top that says, "OpenID 
myexampleopenid.myopenid.com is invalid".

So, it seems like there are two separate issues and I apologize in advance for 
being a lazy reporter and conflating them:

1. The nginx-generated error page is probably not what is intended; it should 
presumably be a pretty themed error page.
2. I should be able to drop the protocol spec; I do not know if this is 
contrary to the OpenID standard or not, but I cannot imagine any harm -- there 
should never be another identity at "myexampleopenid.myopenid.com", regardless 
of whether the protocol is "https://"; or "puppet://" or "gopher://"; (ok, maybe 
those two wouldn't work, but the point stands).


-- 
You have received this notification because you have either subscribed to it, 
or are involved in it.
To change your notification preferences, please click here: 
http://projects.puppetlabs.com/my/account

-- 
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 http://groups.google.com/group/puppet-bugs.
For more options, visit https://groups.google.com/groups/opt_out.

[Ask Puppet Labs - Bug #20267] (Closed) login with google account broken - 502 bad gateway error

[tickets]

Issue #20267 has been updated by Dawn Foster.

Status changed from Investigating to Closed

Cleaning up old bugs. It looks like this one has been resolved.


Bug #20267: login with google account broken - 502 bad gateway error
https://projects.puppetlabs.com/issues/20267#change-102611

* Author: Daniel Pittman
* Status: Closed
* Priority: High
* Assignee: Evgeny Fadeev
* Category: 
* Target version: 
* Keywords: 
* Branch: 

I tried to log in with my Google account to ask.puppetlabs.com, and got sent to 
this URL: 
https://ask.puppetlabs.com/account/signin/complete/?next=%2Fusers%2F26%2Fdaniel-pittman%2Fsubscriptions%2F%3F&janrain_nonce=2013-04-17T17%3A43%3A57ZfJZ65g&openid.ns=http%3A%2F%2Fspecs.openid.net%2Fauth%2F2.0&openid.mode=id_res&openid.op_endpoint=https%3A%2F%2Fwww.google.com%2Faccounts%2Fo8%2Fud&openid.response_nonce=2013-04-17T17%3A43%3A59ZQWSGDt407Zv_sw&openid.return_to=http%3A%2F%2Fask.puppetlabs.com%2Faccount%2Fsignin%2Fcomplete%2F%3Fnext%3D%252Fusers%252F26%252Fdaniel-pittman%252Fsubscriptions%252F%253F%26janrain_nonce%3D2013-04-17T17%253A43%253A57ZfJZ65g&openid.assoc_handle=1.AMlYA9U5oDIbqGpk0k0posm9HmX3gX3CBWGqSQWrzPJDG7yPHhR5o3qOV051NA&openid.signed=op_endpoint%2Cclaimed_id%2Cidentity%2Creturn_to%2Cresponse_nonce%2Cassoc_handle&openid.sig=%2F11T908%2B2Ngr%2B5cd2gdEdCdKAWM%3D&openid.identity=https%3A%2F%2Fwww.google.com%2Faccounts%2Fo8%2Fid%3Fid%3DAItOawmDWcBs_YKoWHMKlqX_bI5tvEszn6
 
5yTMo&openid.claimed_id=https%3A%2F%2Fwww.google.com%2Faccounts%2Fo8%2Fid%3Fid%3DAItOawmDWcBs_YKoWHMKlqX_bI5tvEszn65yTMo

That reports, persistently, a "502 bad gateway" error to me.


-- 
You have received this notification because you have either subscribed to it, 
or are involved in it.
To change your notification preferences, please click here: 
http://projects.puppetlabs.com/my/account

-- 
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 http://groups.google.com/group/puppet-bugs.
For more options, visit https://groups.google.com/groups/opt_out.

[Ask Puppet Labs - Bug #21270] (Closed) RSS links broken

[tickets]

Issue #21270 has been updated by Dawn Foster.

Status changed from Re-opened to Closed

Cleaning up old bugs. I'm assuming this is resolved, but if not, you can open 
it as a new ticket here: https://tickets.puppetlabs.com/browse/ASK


Bug #21270: RSS links broken
https://projects.puppetlabs.com/issues/21270#change-102609

* Author: Joe Thompson
* Status: Closed
* Priority: Normal
* Assignee: Evgeny Fadeev
* Category: 
* Target version: 
* Keywords: 
* Branch: 




-- 
You have received this notification because you have either subscribed to it, 
or are involved in it.
To change your notification preferences, please click here: 
http://projects.puppetlabs.com/my/account

-- 
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 http://groups.google.com/group/puppet-bugs.
For more options, visit https://groups.google.com/groups/opt_out.

[Ask Puppet Labs - Bug #22464] (Closed) ask.puppetlabs.com questiontext overruns sidebar

[tickets]

Issue #22464 has been updated by Dawn Foster.

Status changed from Unreviewed to Closed

Cleaning up old bugs. I'm assuming this is resolved, but if not, you can open 
it as a new ticket here: https://tickets.puppetlabs.com/browse/ASK


Bug #22464: ask.puppetlabs.com questiontext overruns sidebar
https://projects.puppetlabs.com/issues/22464#change-102607

* Author: Ruth Linehan
* Status: Closed
* Priority: Normal
* Assignee: Evgeny Fadeev
* Category: 
* Target version: 
* Keywords: 
* Branch: 

e.g. 
https://ask.puppetlabs.com/question/2911/error-could-not-find-certificate-request-for-pe-internal-dashboard
 before it was edited to add a code block. The text of the question overruns 
the sidebar.


-- 
You have received this notification because you have either subscribed to it, 
or are involved in it.
To change your notification preferences, please click here: 
http://projects.puppetlabs.com/my/account

-- 
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 http://groups.google.com/group/puppet-bugs.
For more options, visit https://groups.google.com/groups/opt_out.

[Ask Puppet Labs - Bug #22657] (Closed) Older answers and questions are truncated

[tickets]

Issue #22657 has been updated by Dawn Foster.

Status changed from Unreviewed to Closed

Cleaning up old bugs. I'm assuming this is resolved, but if not, you can open 
it as a new ticket here: https://tickets.puppetlabs.com/browse/ASK


Bug #22657: Older answers and questions are truncated
https://projects.puppetlabs.com/issues/22657#change-102606

* Author: Lee Lowder
* Status: Closed
* Priority: Normal
* Assignee: Evgeny Fadeev
* Category: 
* Target version: 
* Keywords: 
* Branch: 

On the older questions and answers, they are being truncated.

Newer questions show "... (more)" type link, but on the older ones only the 
"..." shows.

If you edit the question or answer and click save - even if you do not change 
anything, then the full question shows.

Screenshots are attached.


-- 
You have received this notification because you have either subscribed to it, 
or are involved in it.
To change your notification preferences, please click here: 
http://projects.puppetlabs.com/my/account

-- 
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 http://groups.google.com/group/puppet-bugs.
For more options, visit https://groups.google.com/groups/opt_out.

[Ask Puppet Labs - Bug #22663] (Closed) Email filter weirdness

[tickets]

Issue #22663 has been updated by Dawn Foster.

Status changed from Unreviewed to Closed

Cleaning up old bugs. I'm assuming this is resolved, but if not, you can open 
it as a new ticket here: https://tickets.puppetlabs.com/browse/ASK


Bug #22663: Email filter weirdness
https://projects.puppetlabs.com/issues/22663#change-102605

* Author: Lee Lowder
* Status: Closed
* Priority: Normal
* Assignee: 
* Category: 
* Target version: 
* Keywords: 
* Branch: 

I have an email filter setup, set to move all emails that are from 
a...@puppetlabs.com. I have not changed this filter,and other filters work as 
expected.

The headers still show "a...@puppetlabs.com", but it is not being picked up by 
the filter so that instead of being moved to the proper folder, they are now 
being left in the inbox.

This is on Windows 7 using Thunderbird 24.0.


-- 
You have received this notification because you have either subscribed to it, 
or are involved in it.
To change your notification preferences, please click here: 
http://projects.puppetlabs.com/my/account

-- 
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 http://groups.google.com/group/puppet-bugs.
For more options, visit https://groups.google.com/groups/opt_out.

[Ask Puppet Labs - Support #23407] (Closed) Update ask.puppetlabs.com footer

[tickets]

Issue #23407 has been updated by Dawn Foster.

Status changed from Unreviewed to Closed

Recreated this bug with more details about exactly what we need to change here: 
https://tickets.puppetlabs.com/browse/ASK-1


Support #23407: Update ask.puppetlabs.com footer
https://projects.puppetlabs.com/issues/23407#change-102604

* Author: Michelle Johansen
* Status: Closed
* Priority: High
* Assignee: 
* Category: 
* Target version: 
* Keywords: 
* Branch: 

We need to change the 'Bug Tracker' footer link of ask.puppetlabs.com. Current 
Bug Tracker link is to projects.puppetlabs.com and it needs to be redirected to 
tickets.puppetlabs.com

This should happen on 12/16/2013


-- 
You have received this notification because you have either subscribed to it, 
or are involved in it.
To change your notification preferences, please click here: 
http://projects.puppetlabs.com/my/account

-- 
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 http://groups.google.com/group/puppet-bugs.
For more options, visit https://groups.google.com/groups/opt_out.

[Ask Puppet Labs - Bug #23428] (Closed) Concern on Twitter about our ask.com certificate not being secure.

[tickets]

Issue #23428 has been updated by Dawn Foster.

Status changed from Unreviewed to Closed

Cleaning up old bugs. I think I remember this being resolved. We can re-open in 
the new JIRA tracker if not: https://tickets.puppetlabs.com/browse/ASK


Bug #23428: Concern on Twitter about our ask.com certificate not being secure.
https://projects.puppetlabs.com/issues/23428#change-102603

* Author: Zach Leslie
* Status: Closed
* Priority: Normal
* Assignee: Evgeny Fadeev
* Category: 
* Target version: 
* Keywords: 
* Branch: 

Copying original jira issue here:

See this tweet: https://twitter.com/fadenb/status/411103972469256192/photo/1
I'd like to be able to respond or have someone else respond with why this is 
happening or that it's fixed before the end of the week. Any help is 
appreciated.
Thanks!
Michelle




-- 
You have received this notification because you have either subscribed to it, 
or are involved in it.
To change your notification preferences, please click here: 
http://projects.puppetlabs.com/my/account

-- 
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 http://groups.google.com/group/puppet-bugs.
For more options, visit https://groups.google.com/groups/opt_out.

[CLA Application - Bug #19900] (Closed) Odd error when confirming email

[tickets]

Issue #19900 has been updated by Dawn Foster.

Status changed from Unreviewed to Closed

Cleaning up old bugs. I'm assuming this one was resolved.


Bug #19900: Odd error when confirming email
https://projects.puppetlabs.com/issues/19900#change-102602

* Author: Matthaus Owens
* Status: Closed
* Priority: Normal
* Assignee: 
* Category: 
* Target version: 
* Keywords: 
* Branch: 

I used the github integration when trying to use the CLA app and when I used 
the link in the email 
(https://cla.puppetlabs.com/emails/confirm/bbcfcbe1492419497dbba771d62e5f17097b619f1d630ed22d472e5bc3461a56),
 the application gave me the following error: "No user found. Please try again."

I had already signed the CLA previously on redmine, and my github username does 
not match my redmine username (but the emails should be the same).


-- 
You have received this notification because you have either subscribed to it, 
or are involved in it.
To change your notification preferences, please click here: 
http://projects.puppetlabs.com/my/account

-- 
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 http://groups.google.com/group/puppet-bugs.
For more options, visit https://groups.google.com/groups/opt_out.

[CLA Application - Bug #19903] SPF soft-fail for emails from the application

[tickets]

Issue #19903 has been updated by Dawn Foster.


Cleaning up old bugs. I'm assuming this was resolved.


Bug #19903: SPF soft-fail for emails from the application
https://projects.puppetlabs.com/issues/19903#change-102600

* Author: Ken Barber
* Status: Unreviewed
* Priority: Low
* Assignee: Kelsey Hightower
* Category: 
* Target version: 
* Keywords: 
* Branch: 

Looking at the headers of an email I received from the CLA application:


Received-SPF: softfail (google.com: domain of transitioning
nore...@puppetlabs.com does not designate 66.228.49.237 as permitted
sender) client-ip=66.228.49.237;
Authentication-Results: mx.google.com;
   spf=softfail (google.com: domain of transitioning
nore...@puppetlabs.com does not designate 66.228.49.237 as permitted
sender) smtp.mail=nore...@puppetlabs.com


While its only a soft-fail, some remote SMTP systems might consider it 
potential spam and flag it, and we may find we lose some email.


-- 
You have received this notification because you have either subscribed to it, 
or are involved in it.
To change your notification preferences, please click here: 
http://projects.puppetlabs.com/my/account

-- 
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 http://groups.google.com/group/puppet-bugs.
For more options, visit https://groups.google.com/groups/opt_out.

[CLA Application - Bug #19903] (Closed) SPF soft-fail for emails from the application

[tickets]

Issue #19903 has been updated by Dawn Foster.

Status changed from Unreviewed to Closed


Bug #19903: SPF soft-fail for emails from the application
https://projects.puppetlabs.com/issues/19903#change-102601

* Author: Ken Barber
* Status: Closed
* Priority: Low
* Assignee: Kelsey Hightower
* Category: 
* Target version: 
* Keywords: 
* Branch: 

Looking at the headers of an email I received from the CLA application:


Received-SPF: softfail (google.com: domain of transitioning
nore...@puppetlabs.com does not designate 66.228.49.237 as permitted
sender) client-ip=66.228.49.237;
Authentication-Results: mx.google.com;
   spf=softfail (google.com: domain of transitioning
nore...@puppetlabs.com does not designate 66.228.49.237 as permitted
sender) smtp.mail=nore...@puppetlabs.com


While its only a soft-fail, some remote SMTP systems might consider it 
potential spam and flag it, and we may find we lose some email.


-- 
You have received this notification because you have either subscribed to it, 
or are involved in it.
To change your notification preferences, please click here: 
http://projects.puppetlabs.com/my/account

-- 
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 http://groups.google.com/group/puppet-bugs.
For more options, visit https://groups.google.com/groups/opt_out.

[CLA Application - Bug #22880] (Closed) CLA Status Change should only comment on open pull requests

[tickets]

Issue #22880 has been updated by Dawn Foster.

Status changed from Investigating to Closed

Cleaning up old bugs. This one was successfully resolved.


Bug #22880: CLA Status Change should only comment on open pull requests
https://projects.puppetlabs.com/issues/22880#change-102599

* Author: Dawn Foster
* Status: Closed
* Priority: Normal
* Assignee: Paul Jungwirth
* Category: 
* Target version: 
* Keywords: 
* Branch: 

I just changed Nate's GitHub username to match the change he made on GitHub. It 
dropped new comments that he had signed the CLA on his open pull requests, but 
it also dropped a comment on all of the closed pull requests, too. Here's one 
of them: https://github.com/puppetlabs/puppetdb/pull/696

It would seem like it should only care about open pull requests.


-- 
You have received this notification because you have either subscribed to it, 
or are involved in it.
To change your notification preferences, please click here: 
http://projects.puppetlabs.com/my/account

-- 
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 http://groups.google.com/group/puppet-bugs.
For more options, visit https://groups.google.com/groups/opt_out.

[CLA Application - Bug #23076] (Closed) CLA updates stopped between Oct 15 - Oct 21

[tickets]

Issue #23076 has been updated by Dawn Foster.

Status changed from Accepted to Closed

Cleaning up old bugs. Looks like this one was resolved.


Bug #23076: CLA updates stopped between Oct 15 - Oct 21
https://projects.puppetlabs.com/issues/23076#change-102598

* Author: eric sorenson
* Status: Closed
* Priority: Normal
* Assignee: Paul Jungwirth
* Category: 
* Target version: 
* Keywords: 
* Branch: 

Hi Paul, a couple of weeks ago we stopped getting updates from puppetcla on the 
puppetlabs projects. I don't know how to troubleshoot this. Can you please 
help? At this point I'd like both fish and instructions on how to fish since 
we've had some staff turnover and don't have internal docs on how to dig into 
problems with the app. Thanks!


-- 
You have received this notification because you have either subscribed to it, 
or are involved in it.
To change your notification preferences, please click here: 
http://projects.puppetlabs.com/my/account

-- 
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 http://groups.google.com/group/puppet-bugs.
For more options, visit https://groups.google.com/groups/opt_out.

[CLA Application - Bug #23341] (Closed) https://github.com/puppetlabs/puppet/pull/2025 never got acked by the CLA bot

[tickets]

Issue #23341 has been updated by Dawn Foster.

Status changed from Unreviewed to Closed

Cleaning up old bugs. It looks like this pull request was closed, so I'm 
closing this ticket.


Bug #23341: https://github.com/puppetlabs/puppet/pull/2025 never got acked by 
the CLA bot
https://projects.puppetlabs.com/issues/23341#change-102597

* Author: Kylo Ginsberg
* Status: Closed
* Priority: Normal
* Assignee: 
* Category: 
* Target version: 
* Keywords: 
* Branch: 

This pull may have come in while the CLA bot was down?  Anyway, the contributor 
says he signed the CLA agreement but there's no ack in the comments for that PR.


-- 
You have received this notification because you have either subscribed to it, 
or are involved in it.
To change your notification preferences, please click here: 
http://projects.puppetlabs.com/my/account

-- 
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 http://groups.google.com/group/puppet-bugs.
For more options, visit https://groups.google.com/groups/opt_out.

[Ask Puppet Labs - Bug #23428] Concern on Twitter about our ask.com certificate not being secure.

[tickets]

Issue #23428 has been updated by Josh Cooper.


The cert is valid, but the server is not including the intermediate cert 
`GeoTrust SSL CA` in the chain. This is a configuration problem on the server.


Bug #23428: Concern on Twitter about our ask.com certificate not being secure.
https://projects.puppetlabs.com/issues/23428#change-102252

* Author: Zach Leslie
* Status: Unreviewed
* Priority: Normal
* Assignee: Evgeny Fadeev
* Category: 
* Target version: 
* Keywords: 
* Branch: 

Copying original jira issue here:

See this tweet: https://twitter.com/fadenb/status/411103972469256192/photo/1
I'd like to be able to respond or have someone else respond with why this is 
happening or that it's fixed before the end of the week. Any help is 
appreciated.
Thanks!
Michelle




-- 
You have received this notification because you have either subscribed to it, 
or are involved in it.
To change your notification preferences, please click here: 
http://projects.puppetlabs.com/my/account

-- 
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 http://groups.google.com/group/puppet-bugs.
For more options, visit https://groups.google.com/groups/opt_out.

[Ask Puppet Labs - Bug #23428] Concern on Twitter about our ask.com certificate not being secure.

[tickets]

Issue #23428 has been updated by Evgeny Fadeev.


I've looked at the site certificate description in Chrome and Firefox and found 
that it appears to be "valid", confirmed by GeoTrust, Inc.

Maybe a specific build of Firefox lacks some certificates for the certificate 
authorities?
The image on the tweet says that he is using Firefox Beta, maybe that's the 
reason?


Bug #23428: Concern on Twitter about our ask.com certificate not being secure.
https://projects.puppetlabs.com/issues/23428#change-102226

* Author: Zach Leslie
* Status: Unreviewed
* Priority: Normal
* Assignee: Evgeny Fadeev
* Category: 
* Target version: 
* Keywords: 
* Branch: 

Copying original jira issue here:

See this tweet: https://twitter.com/fadenb/status/411103972469256192/photo/1
I'd like to be able to respond or have someone else respond with why this is 
happening or that it's fixed before the end of the week. Any help is 
appreciated.
Thanks!
Michelle




-- 
You have received this notification because you have either subscribed to it, 
or are involved in it.
To change your notification preferences, please click here: 
http://projects.puppetlabs.com/my/account

-- 
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 http://groups.google.com/group/puppet-bugs.
For more options, visit https://groups.google.com/groups/opt_out.

[Ask Puppet Labs - Bug #23428] Concern on Twitter about our ask.com certificate not being secure.

[tickets]

Issue #23428 has been updated by Zach Leslie.

Assignee set to Evgeny Fadeev


Bug #23428: Concern on Twitter about our ask.com certificate not being secure.
https://projects.puppetlabs.com/issues/23428#change-101889

* Author: Zach Leslie
* Status: Unreviewed
* Priority: Normal
* Assignee: Evgeny Fadeev
* Category: 
* Target version: 
* Keywords: 
* Branch: 

Copying original jira issue here:

See this tweet: https://twitter.com/fadenb/status/411103972469256192/photo/1
I'd like to be able to respond or have someone else respond with why this is 
happening or that it's fixed before the end of the week. Any help is 
appreciated.
Thanks!
Michelle




-- 
You have received this notification because you have either subscribed to it, 
or are involved in it.
To change your notification preferences, please click here: 
http://projects.puppetlabs.com/my/account

-- 
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 http://groups.google.com/group/puppet-bugs.
For more options, visit https://groups.google.com/groups/opt_out.

[Ask Puppet Labs - Bug #23428] (Unreviewed) Concern on Twitter about our ask.com certificate not being secure.

[tickets]

Issue #23428 has been reported by Zach Leslie.


Bug #23428: Concern on Twitter about our ask.com certificate not being secure.
https://projects.puppetlabs.com/issues/23428

* Author: Zach Leslie
* Status: Unreviewed
* Priority: Normal
* Assignee: 
* Category: 
* Target version: 
* Keywords: 
* Branch: 

Copying original jira issue here:

See this tweet: https://twitter.com/fadenb/status/411103972469256192/photo/1
I'd like to be able to respond or have someone else respond with why this is 
happening or that it's fixed before the end of the week. Any help is 
appreciated.
Thanks!
Michelle




-- 
You have received this notification because you have either subscribed to it, 
or are involved in it.
To change your notification preferences, please click here: 
http://projects.puppetlabs.com/my/account

-- 
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 http://groups.google.com/group/puppet-bugs.
For more options, visit https://groups.google.com/groups/opt_out.

[PuppetDB - Feature #17108] "Degraded mode" that allows Puppet to operate when PuppetDB is down - with queues and cache

[tickets]

Issue #17108 has been updated by Charlie Sharpsteen.


Redmine Issue [#17108](http://projects.puppetlabs.com/issues/17108) has been 
migrated to JIRA:

  



Feature #17108: "Degraded mode" that allows Puppet to operate when PuppetDB is 
down - with queues and cache
https://projects.puppetlabs.com/issues/17108#change-101450

* Author: Deepak Giridharagopal
* Status: Needs Decision
* Priority: Normal
* Assignee: 
* Category: 
* Target version: 
* Keywords: backlog
* Branch: 
* Affected PuppetDB version: 

Many current PuppetDB users are managing HA themselves, by setting up HTTP load 
balancers and PostgreSQL replication on their own.

Architecturally, I think we could reasonably offer application-level HA...a 
system that would be easier to setup, and would have relaxed consistency 
guarantees compared to more hardcore (and more complicated) database 
replication.

Ideas:

* the terminus code can spool write requests to disk in the event of downstream 
failure, and flush that queue when connectivity is re-established

* the terminus code can cache collection queries for a configurable amount of 
time. the cache is consulted only during failure scenarios, to allow for 
continued (albeit degraded) operation.


-- 
You have received this notification because you have either subscribed to it, 
or are involved in it.
To change your notification preferences, please click here: 
http://projects.puppetlabs.com/my/account

-- 
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 http://groups.google.com/group/puppet-bugs.
For more options, visit https://groups.google.com/groups/opt_out.

[MCollective - Bug #17086] Improve client usage in more complex ruby scripts

[tickets]

Issue #17086 has been updated by Charlie Sharpsteen.


Redmine Issue [#17086](http://projects.puppetlabs.com/issues/17086) has been 
migrated to JIRA:

  



Bug #17086: Improve client usage in more complex ruby scripts
https://projects.puppetlabs.com/issues/17086#change-101448

* Author: R.I. Pienaar
* Status: Accepted
* Priority: Normal
* Assignee: 
* Category: Backlog
* Target version: 
* Keywords: backlog
* Branch: 
* Affected mCollective version: 

Today the typical way is to use 'include MCollective::RPC' and then use some 
methods added to Object.

This works ok for simple cases and seems to do what most people want however 
there's a growing number of cases where people want to do much more complex 
things including multi agent scripts, web consoles, integration into other 
applications etc where polluting Object is a terrible idea.

The RPC::Client class should have a helper that constructs a client in the same 
was that rpcclient() does today and we should move things like printrpc etc 
into the client class for this cases.

The old method will continue to work, the new one would be along these lines:


require 'mcollective'

c = MCollective::RPC.client("rpcutil")
c.printrpc c.ping
c.printstats


Effectively the same thing as today except there isnt any real pollution or 
using of variables in the current scope etc, a simple isolated class that does 
what we do today via the mixin.


-- 
You have received this notification because you have either subscribed to it, 
or are involved in it.
To change your notification preferences, please click here: 
http://projects.puppetlabs.com/my/account

-- 
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 http://groups.google.com/group/puppet-bugs.
For more options, visit https://groups.google.com/groups/opt_out.

[MCollective - Feature #17084] General improvements to plugins

[tickets]

Issue #17084 has been updated by Charlie Sharpsteen.


Redmine Issue [#17084](http://projects.puppetlabs.com/issues/17084) has been 
migrated to JIRA:

  



Feature #17084: General improvements to plugins
https://projects.puppetlabs.com/issues/17084#change-101446

* Author: R.I. Pienaar
* Status: Accepted
* Priority: Normal
* Assignee: 
* Category: Backlog
* Target version: 
* Keywords: backlog
* Branch: 
* Affected mCollective version: 

Puppet Labs maintains a bunch of plugins, these are in various states ranging 
from good to barely functional.

We should do a full review of all the plugins:

 * Identify ones that should just be retired
 * Identify improvements that needs to be made to them esp wrt new mcollective 
features
 * Ensure they have proper test coverage and are part of the new package build 
system (#17070)
 * Create better documentation for each plugin ideally with each plugin repo 
and ideally automatically published on each build by #17070
 * retire the wiki under mcollective-plugins repo replacing it with auto 
generated docs


-- 
You have received this notification because you have either subscribed to it, 
or are involved in it.
To change your notification preferences, please click here: 
http://projects.puppetlabs.com/my/account

-- 
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 http://groups.google.com/group/puppet-bugs.
For more options, visit https://groups.google.com/groups/opt_out.

[MCollective - Feature #17085] Create an auditing system for users sites which suggests new plugins and tips

[tickets]

Issue #17085 has been updated by Charlie Sharpsteen.


Redmine Issue [#17085](http://projects.puppetlabs.com/issues/17085) has been 
migrated to JIRA:

  



Feature #17085: Create an auditing system for users sites which suggests new 
plugins and tips
https://projects.puppetlabs.com/issues/17085#change-101447

* Author: R.I. Pienaar
* Status: Investigating
* Priority: Normal
* Assignee: 
* Category: Backlog
* Target version: 
* Keywords: backlog
* Branch: 
* Affected mCollective version: 

Users should be aware when new plugin versions, mcollective versions etc are 
available.  Additionally we have a desire to gather metrics of usage, 
deployment sizes etc.

One way to do both of these things in one can be seen in the mock up below:


$ mco plugin check_update
This command will gather anonymous metrics of your collective
and submit them to Puppet Labs.  You will get a chance to review
the data prior to submission and cancel if you do not agree

Continue? (y/n): y

Gathering information about your site:

 * [> ] 26 / 26

You may review the data being sent in /tmp/xyz.json

Continue? (y/n): y

HINTS AND SUGGESTIONS:

New major release available:
You are currently running version 3.0.0 of MCollective, the current production
release is 3.2.0 which delivers significant new features, please review
http:// for information on this release

Performance concerns:
Users with a node count similar to yours generally see 'mco ping' performance
of 300ms, you site is performing at 800ms and might suggest there is an
oppertunity to optimise your middleware configuration

etc

PLUGINS:

Available updates for MColective version 3.0.0

  Plugin  Current  Avaialble
  1) agent/package1.2.21.2.3
  2) discovery/puppetdb

Available updates for MCollective version 3.2.0

  Plugin  Current  Avaialble
  3) agent/package1.2.22.0.0

View changelog for plugin (q to quit): 1

 Install and uninstall software packages

 Author: R.I.Pienaar
Version: 3.4
License: ASL2
Timeout: 180
  Home Page: https://github.com/puppetlabs/mcollective-plugins

Changes in version 1.2.3
  -
  -
  -

Changes in version 2.0.0
  -
  -
  -




-- 
You have received this notification because you have either subscribed to it, 
or are involved in it.
To change your notification preferences, please click here: 
http://projects.puppetlabs.com/my/account

-- 
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 http://groups.google.com/group/puppet-bugs.
For more options, visit https://groups.google.com/groups/opt_out.

[MCollective - Feature #17079] Actions should be categorised

[tickets]

Issue #17079 has been updated by Charlie Sharpsteen.


Redmine Issue [#17079](http://projects.puppetlabs.com/issues/17079) has been 
migrated to JIRA:

  



Feature #17079: Actions should be categorised
https://projects.puppetlabs.com/issues/17079#change-101445

* Author: R.I. Pienaar
* Status: Investigating
* Priority: Normal
* Assignee: 
* Category: Backlog
* Target version: 
* Keywords: backlog
* Branch: 
* Affected mCollective version: 

Actions come in many flavours:

 * Ones that change the systems
 * Ones that request status or data about the system
 * Ones that interact with systems like sysctl as pure information retrieval etc
 * Ones that can expose sensitive information and ones that dont
 
And many more, we should allow actions to be classified into set categories so 
that consoles like the PE console can use information in their RBAC


-- 
You have received this notification because you have either subscribed to it, 
or are involved in it.
To change your notification preferences, please click here: 
http://projects.puppetlabs.com/my/account

-- 
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 http://groups.google.com/group/puppet-bugs.
For more options, visit https://groups.google.com/groups/opt_out.

[MCollective - Bug #17077] Create a richer list of default data, validator and summary plugins

[tickets]

Issue #17077 has been updated by Charlie Sharpsteen.


Redmine Issue [#17077](http://projects.puppetlabs.com/issues/17077) has been 
migrated to JIRA:

  



Bug #17077: Create a richer list of default data, validator and summary plugins
https://projects.puppetlabs.com/issues/17077#change-101444

* Author: R.I. Pienaar
* Status: Accepted
* Priority: Normal
* Assignee: 
* Category: Backlog
* Target version: 
* Keywords: backlog
* Branch: 
* Affected mCollective version: 

We now have the ability to create custom data, validation and summary plugins 
but do not yet ship many.

 * go through existing plugins and create data, validator and summary plugins 
where sensible
 * create more statistical summary plugins - everyone knows 'average' is not 
really useful and we should add more sane ones
 * create a richer set of default validators for common things found in typical 
mco environments




-- 
You have received this notification because you have either subscribed to it, 
or are involved in it.
To change your notification preferences, please click here: 
http://projects.puppetlabs.com/my/account

-- 
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 http://groups.google.com/group/puppet-bugs.
For more options, visit https://groups.google.com/groups/opt_out.

[MCollective - Feature #17075] Reply transformations and custom targets/outputs

[tickets]

Issue #17075 has been updated by Charlie Sharpsteen.


Redmine Issue [#17075](http://projects.puppetlabs.com/issues/17075) has been 
migrated to JIRA:

  



Feature #17075: Reply transformations and custom targets/outputs
https://projects.puppetlabs.com/issues/17075#change-101443

* Author: R.I. Pienaar
* Status: Accepted
* Priority: Normal
* Assignee: 
* Category: Backlog
* Target version: 
* Keywords: backlog
* Branch: 
* Affected mCollective version: 

MCollective is effectively a systems integration framework, on its own not 
doing a whole lot but enables you to integrate various systems around unified 
AAA etc.

The only real output avenue today is to output to other things that speak 
mcollective though but this is not ideal.

A simple case might be where a user wants to initiate a monitoring check on 
machines via mcollective but have the result go to his Nagios system direct 
without needing to create some mcollective -> nagios translation daemon as is 
the current common case.

We therefore need:
 
 * Configurable output formats, mcollective output format must be just one of 
these plugins
 * A way to choose one in the API and to supply it other information like the 
IP of the Nagios server in the example above




-- 
You have received this notification because you have either subscribed to it, 
or are involved in it.
To change your notification preferences, please click here: 
http://projects.puppetlabs.com/my/account

-- 
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 http://groups.google.com/group/puppet-bugs.
For more options, visit https://groups.google.com/groups/opt_out.

[MCollective - Bug #17074] Use JSON for all serialization

[tickets]

Issue #17074 has been updated by Charlie Sharpsteen.


Redmine Issue [#17074](http://projects.puppetlabs.com/issues/17074) has been 
migrated to JIRA:

  



Bug #17074: Use JSON for all serialization
https://projects.puppetlabs.com/issues/17074#change-101442

* Author: R.I. Pienaar
* Status: Accepted
* Priority: Normal
* Assignee: 
* Category: Backlog
* Target version: 
* Keywords: backlog
* Branch: 
* Affected mCollective version: 

Today mcollective use YAML or Marshal for serialization because:

 * It's in all Rubies
 * It supports complex data types
 * The protocol uses symbols

This is not portable, it is roughly impossible to support other languages on 
the mcollective protocol because this choice effectively makes it Ruby specific.

We have ages ago vendored a JSON gem that works on older RHEL systems so we 
should consider doing everything with JSON.

A few problems:

 * today there are users who transport complex ruby types using mcollective, 
this works due to the choice of yaml/marshal as serialization and we will 
effectively downgrade mcollective if we support pure JSON.
 * the protocol has to change and this will break backwards compat unless we 
add some magical handling for strings and symbols ala the mash gem.



-- 
You have received this notification because you have either subscribed to it, 
or are involved in it.
To change your notification preferences, please click here: 
http://projects.puppetlabs.com/my/account

-- 
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 http://groups.google.com/group/puppet-bugs.
For more options, visit https://groups.google.com/groups/opt_out.

[MCollective - Bug #17072] Getting started with mcollective should be easier

[tickets]

Issue #17072 has been updated by Charlie Sharpsteen.


Redmine Issue [#17072](http://projects.puppetlabs.com/issues/17072) has been 
migrated to JIRA:

  



Bug #17072: Getting started with mcollective should be easier
https://projects.puppetlabs.com/issues/17072#change-101441

* Author: R.I. Pienaar
* Status: Accepted
* Priority: High
* Assignee: R.I. Pienaar
* Category: Backlog
* Target version: 2.3.x
* Keywords: backlog
* Branch: 
* Affected mCollective version: 

Today getting going requires one to setup ActiveMQ or RabbitMQ and 
understanding a ton of complex technology.  Additionally small sites really do 
not care that much for middleware, they want something simpler/easier else they 
just wont use mcollective.

We have a number of options here to consider:

 * Create a easier ActiveMQ distribution with a DSL to configure it something 
as simple as http://p.devco.net/97/
 * Investigate other kinds of middleware suitable for small sites like MongoDB, 
Redis etc see http://srt.ly/cj


-- 
You have received this notification because you have either subscribed to it, 
or are involved in it.
To change your notification preferences, please click here: 
http://projects.puppetlabs.com/my/account

-- 
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 http://groups.google.com/group/puppet-bugs.
For more options, visit https://groups.google.com/groups/opt_out.

[MCollective - Feature #17071] Document approaches to more scalable deployes

[tickets]

Issue #17071 has been updated by Charlie Sharpsteen.


Redmine Issue [#17071](http://projects.puppetlabs.com/issues/17071) has been 
migrated to JIRA:

  



Feature #17071: Document approaches to more scalable deployes
https://projects.puppetlabs.com/issues/17071#change-101440

* Author: R.I. Pienaar
* Status: Investigating
* Priority: Normal
* Assignee: 
* Category: Backlog
* Target version: 
* Keywords: backlog
* Branch: 
* Affected mCollective version: 

Currently the state of art regarding complex or large mcollective sites is just 
to mesh all the activemqs together.  This does not work well and is not a good 
idea given the design of ActiveMQ clustering however it seems the obvious thing 
so everyone does it.

We need to test, document, benchmark etc a scalable mcollective deploy strategy 
based on ActiveMQ


-- 
You have received this notification because you have either subscribed to it, 
or are involved in it.
To change your notification preferences, please click here: 
http://projects.puppetlabs.com/my/account

-- 
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 http://groups.google.com/group/puppet-bugs.
For more options, visit https://groups.google.com/groups/opt_out.

[MCollective - Refactor #17068] Refactor the plugin application

[tickets]

Issue #17068 has been updated by Charlie Sharpsteen.


Redmine Issue [#17068](http://projects.puppetlabs.com/issues/17068) has been 
migrated to JIRA:

  



Refactor #17068: Refactor the plugin application
https://projects.puppetlabs.com/issues/17068#change-101439

* Author: R.I. Pienaar
* Status: Accepted
* Priority: Normal
* Assignee: Pieter Loubser
* Category: Backlog
* Target version: 2.3.x
* Keywords: backlog
* Branch: 
* Affected mCollective version: 

The plugin application in mcollective has over time grown into a bit of a beast 
of inter dependant stuff, we should refactor this to be clearer code with 
better separation while maintaining current feature set.


-- 
You have received this notification because you have either subscribed to it, 
or are involved in it.
To change your notification preferences, please click here: 
http://projects.puppetlabs.com/my/account

-- 
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 http://groups.google.com/group/puppet-bugs.
For more options, visit https://groups.google.com/groups/opt_out.

[MCollective - Feature #17065] Create a scripting environment for RPC actions

[tickets]

Issue #17065 has been updated by Charlie Sharpsteen.


Redmine Issue [#17065](http://projects.puppetlabs.com/issues/17065) has been 
migrated to JIRA:

  



Feature #17065: Create a scripting environment for RPC actions
https://projects.puppetlabs.com/issues/17065#change-101438

* Author: R.I. Pienaar
* Status: Accepted
* Priority: High
* Assignee: 
* Category: Backlog
* Target version: 
* Keywords: backlog
* Branch: 
* Affected mCollective version: 

As users create more and more agents and actions they want a convenient way to 
combine these into scripts.

The RPC client libraries are ok for this though they're optimised for really 
short scripts mostly communicating with just one agent. But primarily they 
require you to know ruby and there are a large number of Puppet users who know 
Puppet but not ruby.

We should create something to allow series of requests:

 * Conveniently call out to different agents and actions
 * Create relationships between action calls
 * Be a simplified DSL rather than something complex like ruby
 * Support parameters supplied on the command line

I've previously written a quick prototype of this idea in 
https://github.com/ripienaar/puppet-mcollective and have had very regular 
feedback from the community that this is a desired feature.

The prototype is built as a Puppet type and provider allowing the use of the 
Puppet DSL and its relationships, chaining, notifying, facts etc to be used to 
create these scripts.  

If we decide to use the Puppet DSL we should also consider writing a face or 
application to call out to these scripts to provide a convenient and natural 
integration.


-- 
You have received this notification because you have either subscribed to it, 
or are involved in it.
To change your notification preferences, please click here: 
http://projects.puppetlabs.com/my/account

-- 
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 http://groups.google.com/group/puppet-bugs.
For more options, visit https://groups.google.com/groups/opt_out.

[MCollective Plugins - Feature #17060] Ability to list directories in filemgr agent/app

[tickets]

Issue #17060 has been updated by Charlie Sharpsteen.


Redmine Issue [#17060](http://projects.puppetlabs.com/issues/17060) has been 
migrated to JIRA:

  



Feature #17060: Ability to list directories in filemgr agent/app
https://projects.puppetlabs.com/issues/17060#change-101437

* Author: Drew Blessing
* Status: Code Insufficient
* Priority: Normal
* Assignee: 
* Category: 
* Target version: 
* Keywords: 
* Branch: ploubser/mcollective-filemgr-agent/tree/feature/master/17060
* Affected mCollective version: 2.2.1

It would be nice to be able to list a directory with the filemgr plugin.  This 
can be accomplished fairly easily.  I have a preliminary implementation worked 
up.  I plan to solicit some discussion on the #mcollective IRC and make 
additional changes before submitting a pull request.  


-- 
You have received this notification because you have either subscribed to it, 
or are involved in it.
To change your notification preferences, please click here: 
http://projects.puppetlabs.com/my/account

-- 
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 http://groups.google.com/group/puppet-bugs.
For more options, visit https://groups.google.com/groups/opt_out.

[MCollective - Bug #17037] inputs that are not defined in the DDL should result in an error

[tickets]

Issue #17037 has been updated by Charlie Sharpsteen.


Redmine Issue [#17037](http://projects.puppetlabs.com/issues/17037) has been 
migrated to JIRA:

  



Bug #17037: inputs that are not defined in the DDL should result in an error
https://projects.puppetlabs.com/issues/17037#change-101436

* Author: R.I. Pienaar
* Status: Accepted
* Priority: Normal
* Assignee: 
* Category: 
* Target version: 2.3.x
* Keywords: 
* Branch: 
* Affected mCollective version: 


mco rpc rpcutil ping x=y


This should raise an error, I am marking this as a parent to the long running 
jobs ticket as we should only enforce this once that is supported - because 
users are currently building their own background job feature that relies on 
this behaviour.

This will also break the RAL agent.


-- 
You have received this notification because you have either subscribed to it, 
or are involved in it.
To change your notification preferences, please click here: 
http://projects.puppetlabs.com/my/account

-- 
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 http://groups.google.com/group/puppet-bugs.
For more options, visit https://groups.google.com/groups/opt_out.

[MCollective Plugins - Bug #16447] agent registration issue with mongodb

[tickets]

Issue #16447 has been updated by Charlie Sharpsteen.


Redmine Issue [#16447](http://projects.puppetlabs.com/issues/16447) has been 
migrated to JIRA:

  



Bug #16447: agent registration issue with mongodb
https://projects.puppetlabs.com/issues/16447#change-101435

* Author: chuck scott
* Status: Accepted
* Priority: Normal
* Assignee: Richard Clamp
* Category: 
* Target version: 
* Keywords: mcollective mongodb
* Branch: 
* Affected mCollective version: 2.0.0

In discussion with 
[R.I.Pienaar](https://groups.google.com/a/puppetlabs.com/forum/?fromgroups=#!topic/pe-users/87kqLkiTUMY)

a registration issue with the 
[mcollective/agent/registration.rb](https://raw.github.com/puppetlabs/mcollective-plugins/master/agent/registration-mongodb/agent/registration.rb)
 plugin

leads to the following stack trace:

[chuck@stubhub-centos62-64-vm6 mcollective]$ tail -20 
/var/log/mcollective.log
D, [2012-09-17T10:27:11.904649 #3918] DEBUG -- : stomp.rb:197:in `receive' 
Waiting for a message from Stomp
D, [2012-09-17T10:27:11.908196 #3918] DEBUG -- : registration.rb:96:in 
`handlemsg' Updated data for host stubhub-centos62-64-vm6.local with id in 
0.00247311592102051s
E, [2012-09-17T10:27:11.908369 #3918] ERROR -- : agents.rb:138:in 
`dispatch' Execution of registration failed: undefined method `[]' for 
nil:NilClass
E, [2012-09-17T10:27:11.908454 #3918] ERROR -- : agents.rb:139:in 
`dispatch' /usr/libexec/mcollective/mcollective/agent/registration.rb:91:in 
`handlemsg'
/usr/lib/ruby/site_ruby/1.8/mcollective/agents.rb:126:in `dispatch'
/usr/lib/ruby/1.8/timeout.rb:67:in `timeout'
/usr/lib/ruby/site_ruby/1.8/mcollective/agents.rb:125:in `dispatch'
/usr/lib/ruby/site_ruby/1.8/mcollective/agents.rb:121:in `initialize'
/usr/lib/ruby/site_ruby/1.8/mcollective/agents.rb:121:in `new'
/usr/lib/ruby/site_ruby/1.8/mcollective/agents.rb:121:in `dispatch'
/usr/lib/ruby/site_ruby/1.8/mcollective/runner.rb:82:in `agentmsg'
/usr/lib/ruby/site_ruby/1.8/mcollective/runner.rb:55:in `run'
/usr/lib/ruby/site_ruby/1.8/mcollective/runner.rb:50:in `loop'
/usr/lib/ruby/site_ruby/1.8/mcollective/runner.rb:50:in `run'
/usr/lib/ruby/site_ruby/1.8/mcollective/unix_daemon.rb:30:in 
`daemonize_runner'
/usr/lib/ruby/site_ruby/1.8/mcollective/unix_daemon.rb:13:in `daemonize'
/usr/lib/ruby/site_ruby/1.8/mcollective/unix_daemon.rb:5:in `fork'
/usr/lib/ruby/site_ruby/1.8/mcollective/unix_daemon.rb:5:in `daemonize'
/usr/lib/ruby/site_ruby/1.8/mcollective/unix_daemon.rb:20:in 
`daemonize_runner'
/usr/sbin/mcollectived:43

we resolve the issue by applying the following fix:

[chuck@stubhub-centos62-64-vm6 mcollective]$ diff -u 
/usr/libexec/mcollective/mcollective/agent/registration.rb 
/usr/libexec/mcollective/mcollective/agent/registration.rb.orig
--- /usr/libexec/mcollective/mcollective/agent/registration.rb  2012-09-17 
11:44:06.362358083 -0700
+++ /usr/libexec/mcollective/mcollective/agent/registration.rb.orig 
2012-09-17 11:42:28.734447337 -0700
@@ -82,15 +82,13 @@
end
by_fqdn = {:fqdn => req[:fqdn]}
doc_id = nil
before = Time.now.to_f
begin
doc = @coll.find_and_modify(:query => by_fqdn, :update => {'$set' => req}, 
:new => true)
-  if doc
- doc_id = doc['_id']
-  else
-doc_id = @coll.insert(req, {:safe => true})
-  end
+  doc_id = doc['_id']
rescue Mongo::OperationFailure
doc_id = @coll.insert(req, {:safe => true})
ensure






-- 
You have received this notification because you have either subscribed to it, 
or are involved in it.
To change your notification preferences, please click here: 
http://projects.puppetlabs.com/my/account

-- 
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 http://groups.google.com/group/puppet-bugs.
For more options, visit https://groups.google.com/groups/opt_out.

[MCollective - Feature #16319] should be able to parse natural dates

[tickets]

Issue #16319 has been updated by Charlie Sharpsteen.


Redmine Issue [#16319](http://projects.puppetlabs.com/issues/16319) has been 
migrated to JIRA:

  



Feature #16319: should be able to parse natural dates
https://projects.puppetlabs.com/issues/16319#change-101434

* Author: R.I. Pienaar
* Status: Accepted
* Priority: Normal
* Assignee: 
* Category: Core
* Target version: 2.3.x
* Keywords: 
* Branch: 
* Affected mCollective version: 

A natural language date parser for strings like "next monday 4am" should be 
written or used.  I've used http://chronic.rubyforge.org/ a lot in the past, we 
should evaluate the pros and cons of either vendoring chronic or writing one 
for our own needs


-- 
You have received this notification because you have either subscribed to it, 
or are involved in it.
To change your notification preferences, please click here: 
http://projects.puppetlabs.com/my/account

-- 
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 http://groups.google.com/group/puppet-bugs.
For more options, visit https://groups.google.com/groups/opt_out.

[MCollective - Feature #16317] run timestamp should be recorded in rpc results

[tickets]

Issue #16317 has been updated by Charlie Sharpsteen.


Redmine Issue [#16317](http://projects.puppetlabs.com/issues/16317) has been 
migrated to JIRA:

  



Feature #16317: run timestamp should be recorded in rpc results
https://projects.puppetlabs.com/issues/16317#change-101433

* Author: R.I. Pienaar
* Status: Accepted
* Priority: Normal
* Assignee: 
* Category: SimpleRPC
* Target version: 2.3.x
* Keywords: 
* Branch: 
* Affected mCollective version: 

Given that RPC requests will now be run at future times the RPC result 
structure should be aware of the time the request was run.


-- 
You have received this notification because you have either subscribed to it, 
or are involved in it.
To change your notification preferences, please click here: 
http://projects.puppetlabs.com/my/account

-- 
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 http://groups.google.com/group/puppet-bugs.
For more options, visit https://groups.google.com/groups/opt_out.

[MCollective - Bug #16295] actions should support always being background or foreground through the ddl

[tickets]

Issue #16295 has been updated by Charlie Sharpsteen.


Redmine Issue [#16295](http://projects.puppetlabs.com/issues/16295) has been 
migrated to JIRA:

  



Bug #16295: actions should support always being background or foreground 
through the ddl
https://projects.puppetlabs.com/issues/16295#change-101432

* Author: R.I. Pienaar
* Status: Accepted
* Priority: Normal
* Assignee: R.I. Pienaar
* Category: SimpleRPC
* Target version: 2.3.x
* Keywords: 
* Branch: 
* Affected mCollective version: 

there are actions that would simply be bad to run in the foreground like yum 
update or puppet agent --test, if an agent want to add actions for this style 
of command they should be able to force in the DDL that these should always be 
run in async.

The behaviour would be something like:


mco rpc package yum_update
Action scheduled for background execution with id: 
93db89f4ba575b09804ea91197222cd5


What will happen is the servers will then schedule a background job for this 
action and potentially splay them out over some configured default interval.  

For this ticket though we just need the metadata in the DDL to indicate forced 
background or forced foreground actions.


-- 
You have received this notification because you have either subscribed to it, 
or are involved in it.
To change your notification preferences, please click here: 
http://projects.puppetlabs.com/my/account

-- 
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 http://groups.google.com/group/puppet-bugs.
For more options, visit https://groups.google.com/groups/opt_out.

[MCollective - Refactor #16249] refactor security plugins to support Message objects better

[tickets]

Issue #16249 has been updated by Charlie Sharpsteen.


Redmine Issue [#16249](http://projects.puppetlabs.com/issues/16249) has been 
migrated to JIRA:

  



Refactor #16249: refactor security plugins to support Message objects better
https://projects.puppetlabs.com/issues/16249#change-101431

* Author: R.I. Pienaar
* Status: Accepted
* Priority: Normal
* Assignee: R.I. Pienaar
* Category: Core
* Target version: 2.3.x
* Keywords: 
* Branch: 
* Affected mCollective version: 

The security plugins have methods like #encodereply and #encoderequest that 
takes a bunch of arguments all from the Message object. To improve 
maintainability these methods should be refactored to just take a Message 
instance and access the attributes in that object.


-- 
You have received this notification because you have either subscribed to it, 
or are involved in it.
To change your notification preferences, please click here: 
http://projects.puppetlabs.com/my/account

-- 
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 http://groups.google.com/group/puppet-bugs.
For more options, visit https://groups.google.com/groups/opt_out.

[MCollective - Feature #16228] requests need associated metadata

[tickets]

Issue #16228 has been updated by Charlie Sharpsteen.


Redmine Issue [#16228](http://projects.puppetlabs.com/issues/16228) has been 
migrated to JIRA:

  



Feature #16228: requests need associated metadata
https://projects.puppetlabs.com/issues/16228#change-101430

* Author: R.I. Pienaar
* Status: Accepted
* Priority: Normal
* Assignee: R.I. Pienaar
* Category: Core
* Target version: 2.3.x
* Keywords: 
* Branch: 
* Affected mCollective version: 

At present there's a few special keys to the request data, things like 
process_results, currently they are just stored in the normal data hash and 
should an unwitting user use any of them as inputs to his agent bad things 
might happen.

This is obviously bad, and we'll be adding a lot more metadata like:

 * background job or not
 * earliest time a background job might run
 * all the ones currently in the rpc data hash
 * protocol version
 * ttl override for long running jobs

and no doubt many others, so a proper solution need to be found.


-- 
You have received this notification because you have either subscribed to it, 
or are involved in it.
To change your notification preferences, please click here: 
http://projects.puppetlabs.com/my/account

-- 
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 http://groups.google.com/group/puppet-bugs.
For more options, visit https://groups.google.com/groups/opt_out.

[MCollective - Feature #16217] scheduled and long running jobs should be supported

[tickets]

Issue #16217 has been updated by Charlie Sharpsteen.


Redmine Issue [#16217](http://projects.puppetlabs.com/issues/16217) has been 
migrated to JIRA:

  <https://tickets.puppetlabs.com/browse/MCO-49>



Feature #16217: scheduled and long running jobs should be supported
https://projects.puppetlabs.com/issues/16217#change-101429

* Author: R.I. Pienaar
* Status: Accepted
* Priority: Normal
* Assignee: R.I. Pienaar
* Category: Core
* Target version: 2.3.x
* Keywords: backlog
* Branch: 
* Affected mCollective version: 

at present mcollective only support real time or near real time actions.  
Specifically long running actions arent well supported as the actions are run 
inside a ruby thread inside the mcollective process, this make them vulnerable 
to the mcollectived process being restarted by something like Puppet and in 
general they just dont really work inside a ruby thread.

We'd like to add a few extra features:

 * The ability to schedule an action to be run at some future time
 * The ability to mark an action as background or long running so it will be 
run in some other forked processes disassociated from mcollectived

The 2 cases are more or less the same thing, the 2nd is a scheduled job for 
'now' run in the same infrastructure as the first.

This will mean we need some 2nd daemon to supervise these jobs eventually this 
daemon will be in something like C and mcollectived will start it on demand.

In future we'd add:

 * Ability to have a series of dependant jobs scheduled where dependencies are 
single-host only
 * Ability to have repeating jobs schduled

The RPC library should be extended so that using the existing RPC library any 
action can be scheduled in this way, mock up UI might be:


mco rpc package yum_update --at="4 am"
Action scheduled for 2012-09-04 04:00  with id: 93db89f4ba575b09804ea91197222cd5


Using this ID the user should then later be able to do normal 
Edit/Delete/Update/Status actions:


mco rpc package yum_update --status=93db89f4ba575b09804ea91197222cd5


this command will return the exact same data structures and show the exact same 
output as if the command was a normal RPC request run right now thus reusing 
most existing knowledge in interacting with agents.  Incomplete/Not run yet 
jobs will return 'failed' statusses via the usual error reporting

For other actions like edit/delete a separate agent could probably stand in 
rather than give all agents the ability to perform these functions but that's 
unsure at present


mco schedule delete 93db89f4ba575b09804ea91197222cd5
mco schedule update 93db89f4ba575b09804ea91197222cd5 --at "5am"
mco schedule status 93db89f4ba575b09804ea91197222cd5
mco schedule list


alternatively if all agents could do their own thing we might end up in a place 
where you can only edit jobs using the agent that created them, not sure if 
that's desirable.

This ticket is just a placeholder for the basic overview of the feature, 
dependant tickets will be created for individual actions


-- 
You have received this notification because you have either subscribed to it, 
or are involved in it.
To change your notification preferences, please click here: 
http://projects.puppetlabs.com/my/account

-- 
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 http://groups.google.com/group/puppet-bugs.
For more options, visit https://groups.google.com/groups/opt_out.

[MCollective - Feature #16095] Added direct reply target type for activemq subscriptions

[tickets]

Issue #16095 has been updated by Charlie Sharpsteen.


Redmine Issue [#16095](http://projects.puppetlabs.com/issues/16095) has been 
migrated to JIRA:

  



Feature #16095: Added direct reply target type for activemq subscriptions
https://projects.puppetlabs.com/issues/16095#change-101428

* Author: Matt Carroll
* Status: Closed
* Priority: Normal
* Assignee: 
* Category: 
* Target version: 
* Keywords: activemq plugin, subscription, listener
* Branch: 
* Affected mCollective version: 

https://github.com/puppetlabs/marionette-collective/pull/49

This creates the listening subscription on the specified queue without a unique 
id so that the publishing agent can be initialised using --reply-to without 
first setting up the subscriber in order to find out the unique queue id which 
is created so it can be specified in the --reply-to option.

An example of this is that I want to be able to tell an agent to reply to the 
queue mcollective.reply.foo. If I then use the current :reply target type to 
try to subscribe to that queue after I've sent the request, it will instead 
create mcollective.reply.foo_$SOMEID and listen to that. I would like to be 
able to specify the reply queue before subscribing a listener to it.


-- 
You have received this notification because you have either subscribed to it, 
or are involved in it.
To change your notification preferences, please click here: 
http://projects.puppetlabs.com/my/account

-- 
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 http://groups.google.com/group/puppet-bugs.
For more options, visit https://groups.google.com/groups/opt_out.

[Puppet - Bug #16061] Deprecate non-UTF-8 encodings for textual content

[tickets]

Issue #16061 has been updated by Charlie Sharpsteen.


Redmine Issue [#16061](http://projects.puppetlabs.com/issues/16061) has been 
migrated to JIRA:

  



Bug #16061: Deprecate non-UTF-8 encodings for textual content
https://projects.puppetlabs.com/issues/16061#change-101427

* Author: Deepak Giridharagopal
* Status: Accepted
* Priority: Normal
* Assignee: 
* Category: 
* Target version: 3.5.0
* Affected Puppet version: 
* Keywords: 
* Branch: 

This changes semantics, so it can't be done prior to 3.0.0. Though my 
preference would be to issue a deprecation warning in 2.7.x if we can.

We currently don't specify what character sets we support for things that we 
know are textual (or things we'd like to enforce as text-only). Consequently, 
interoperability across systems or across languages on the same system is 
severely constrained...we have no idea how to encode or decode strings on the 
wire, because we don't know the original encodings of any strings. This has 
created severe headaches for PuppetDB, classic storeconfigs (thereby affecting 
Foreman), etc...we can't guarantee *reliable* storage of puppet data without 
dealing with this.

Off the top of my head, I can think of the following key places that could use 
a tightening of semantics:

* .pp files
* templates
* generate()
* facts

It may also be handy to just state up-front in the docs that all string values 
in puppet are presumed to be UTF-8. I don't believe we need to do anything 
around .rb files, as those already have ways of indicating alternate character 
sets. I believe that UTF-8 should work out-of-the-box for the vast, vast 
majority of Puppet users (who primarily use ASCII or UTF-8 already). The 
biggest impact, I think, will be on people using Latin-1 in their templates and 
.pp files...though a simple call to iconv on the command line should be enough 
to convert them all losslessly. Our deprecation warning could even include a 
reference to instructions on how to convert, if we want to get really fancy.

Notable improvements we could make beyond simple deprecation:

* change functions like template() and generate() so that they take additional, 
optional arguments which are the input encoding and output encoding. Default to 
UTF-8 for both.
* probably other stuff I can't think of right now


-- 
You have received this notification because you have either subscribed to it, 
or are involved in it.
To change your notification preferences, please click here: 
http://projects.puppetlabs.com/my/account

-- 
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 http://groups.google.com/group/puppet-bugs.
For more options, visit https://groups.google.com/groups/opt_out.

[MCollective - Bug #16012] puppetlabs' mcollective init script differs from ubuntu's

[tickets]

Issue #16012 has been updated by Charlie Sharpsteen.


Redmine Issue [#16012](http://projects.puppetlabs.com/issues/16012) has been 
migrated to JIRA:

  



Bug #16012: puppetlabs' mcollective init script differs from ubuntu's
https://projects.puppetlabs.com/issues/16012#change-101426

* Author: Christian McHugh
* Status: Investigating
* Priority: Normal
* Assignee: 
* Category: 
* Target version: 
* Keywords: 
* Branch: 
* Affected mCollective version: 

Ran into an issue with mcollective starting on ubuntu when upgrading from the 
puppetlabs apt repo. It turns out that the ubuntu package uses upstart which 
requires a "daemonize = 0" line in server.cfg. Since the puppetlabs package 
just uses init scripts that line needs to be changed to "daemonize = 1". 

It would be nice if the puppetlabs package could ship an init script on ubuntu 
to remove this difference.


-- 
You have received this notification because you have either subscribed to it, 
or are involved in it.
To change your notification preferences, please click here: 
http://projects.puppetlabs.com/my/account

-- 
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 http://groups.google.com/group/puppet-bugs.
For more options, visit https://groups.google.com/groups/opt_out.

[MCollective - Bug #15787] Rename rpc-help.erb to agent-help.erb

[tickets]

Issue #15787 has been updated by Charlie Sharpsteen.


Redmine Issue [#15787](http://projects.puppetlabs.com/issues/15787) has been 
migrated to JIRA:

  



Bug #15787: Rename rpc-help.erb to agent-help.erb
https://projects.puppetlabs.com/issues/15787#change-101425

* Author: Pieter Loubser
* Status: Accepted
* Priority: Normal
* Assignee: 
* Category: Core
* Target version: 2.3.x
* Keywords: 
* Branch: 
* Affected mCollective version: 

Our new plugin help templates are called pluginname-help.erb. We should update 
the agent help template accordingly.


-- 
You have received this notification because you have either subscribed to it, 
or are involved in it.
To change your notification preferences, please click here: 
http://projects.puppetlabs.com/my/account

-- 
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 http://groups.google.com/group/puppet-bugs.
For more options, visit https://groups.google.com/groups/opt_out.

[Puppet - Bug #15773] Start deprecating 'versionRequirement' per code comment

[tickets]

Issue #15773 has been updated by Charlie Sharpsteen.


Redmine Issue [#15773](http://projects.puppetlabs.com/issues/15773) has been 
migrated to JIRA:

  



Bug #15773: Start deprecating 'versionRequirement' per code comment
https://projects.puppetlabs.com/issues/15773#change-101424

* Author: eric sorenson
* Status: Accepted
* Priority: Normal
* Assignee: eric sorenson
* Category: plumbing
* Target version: 3.5.0
* Affected Puppet version: 
* Keywords: telly_deprecations
* Branch: 

in 3.x, module.rb says the following:

`
  # NOTICE: The fallback to `versionRequirement` is something we'd like to
  # not have to support, but we have a reasonable number of releases that
  # don't use `version_requirement`. When we can deprecate this, we should.
`

This should be slated for warnings in Telly and removal in Waldorf.


-- 
You have received this notification because you have either subscribed to it, 
or are involved in it.
To change your notification preferences, please click here: 
http://projects.puppetlabs.com/my/account

-- 
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 http://groups.google.com/group/puppet-bugs.
For more options, visit https://groups.google.com/groups/opt_out.

[Puppet - Bug #15772] Remove deprecated process execution methods in util

[tickets]

Issue #15772 has been updated by Charlie Sharpsteen.


Redmine Issue [#15772](http://projects.puppetlabs.com/issues/15772) has been 
migrated to JIRA:

  



Bug #15772: Remove deprecated process execution methods in util 
https://projects.puppetlabs.com/issues/15772#change-101423

* Author: Anonymous
* Status: Accepted
* Priority: Normal
* Assignee: 
* Category: 
* Target version: Waldorf
* Affected Puppet version: 
* Keywords: telly_deprecation
* Branch: 

All the deprecated process execution methods in util should be removed. 


-- 
You have received this notification because you have either subscribed to it, 
or are involved in it.
To change your notification preferences, please click here: 
http://projects.puppetlabs.com/my/account

-- 
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 http://groups.google.com/group/puppet-bugs.
For more options, visit https://groups.google.com/groups/opt_out.

[PuppetDB - Bug #15567] Document use of PuppetDB with SELinux

[tickets]

Issue #15567 has been updated by Charlie Sharpsteen.


Redmine Issue [#15567](http://projects.puppetlabs.com/issues/15567) has been 
migrated to JIRA:

  



Bug #15567: Document use of PuppetDB with SELinux
https://projects.puppetlabs.com/issues/15567#change-101422

* Author: Deepak Giridharagopal
* Status: Accepted
* Priority: Normal
* Assignee: 
* Category: 
* Target version: 
* Keywords: 
* Branch: 
* Affected PuppetDB version: 

>From the mailing list:


I've configured puppet to use storedconfigs and puppetDB,
If I start the puppet master using the init script puppetmaster I get a 
permission denied error when a node connects:

Master:
[root@puppet ~]# service puppetmaster start
Starting puppetmaster: [  OK  ]

Node:
[root@puppet-slave ~]# puppet agent --test
err: Could not retrieve catalog from remote server: Error 400 on SERVER: Failed 
to submit 'replace facts' command for puppet-slave.test.net to PuppetDB at 
puppet.test.net:8081: Permission denied - connect(2)
warning: Not using cache on failed catalog
err: Could not retrieve catalog; skipping run

If I start the puppet master using the script puppet command, it works fine:

Master:
[root@puppet ~]# puppet master start

Node:
[root@puppet-slave ~]# puppet agent --test
info: Caching catalog for puppet-slave.test.net
info: Applying configuration version '1340967639'
notice: /Stage[main]/Drupal/Exec[install-drupal]/returns: executed successfully
notice: Finished catalog run in 17.72 seconds

Anyone come across this behaviour before, or found a solution?

All packages are from RPM installs (except ruby gems for pupetdb)

[root@puppet ~]# rpm -qa | grep puppet
puppet-server-2.7.17-1.el6.noarch
puppetlabs-release-6-1.noarch
puppet-2.7.17-1.el6.noarch
puppetdb-0.9.1-2.el6.noarch
puppetdb-terminus-0.9.1-2.el6.noarch


I think that, at a minimum, we should document in the installation docs what 
ports and permissions need to be there for puppetdb to work in an selinux 
environment.


-- 
You have received this notification because you have either subscribed to it, 
or are involved in it.
To change your notification preferences, please click here: 
http://projects.puppetlabs.com/my/account

-- 
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 http://groups.google.com/group/puppet-bugs.
For more options, visit https://groups.google.com/groups/opt_out.

[MCollective Plugins - Bug #15472] rewrite puppet agent

[tickets]

Issue #15472 has been updated by Charlie Sharpsteen.


Redmine Issue [#15472](http://projects.puppetlabs.com/issues/15472) has been 
migrated to JIRA:

  



Bug #15472: rewrite puppet agent
https://projects.puppetlabs.com/issues/15472#change-101421

* Author: R.I. Pienaar
* Status: Investigating
* Priority: Normal
* Assignee: R.I. Pienaar
* Category: 
* Target version: 
* Keywords: backlog
* Branch: 
* Affected mCollective version: 

We have the 'puppetd' agent which comes from the days we still had a 'puppetd'.

Much have changed and puppet 3 will make pid/lock handling a lot better so we 
should rewrite this agent:

 * disable/enable/status should support the locking improvements in #3757 
including setting messages
 * the config keys should be sorted out to be consistently named
 * it should default to puppet 3 filenames, locations etc
 * status should use last_run_summary to provide a better status of last run
 * it should support more common flags especially environment, noop/no-noop/tags
 * it should potentially support getting some stats from the reports - this 
might be too slow
 * it should include the resource() data source to discover based on managed 
properties
 * it should include a puppet() data source that lets you discover currently 
running/enabled/disabled nodes as well based on things like values out of 
last_run_summary
 * it should have some data retrieval out of the last_run_summary showing some 
aggregate information like configversion, time perhaps with outlier detection



-- 
You have received this notification because you have either subscribed to it, 
or are involved in it.
To change your notification preferences, please click here: 
http://projects.puppetlabs.com/my/account

-- 
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 http://groups.google.com/group/puppet-bugs.
For more options, visit https://groups.google.com/groups/opt_out.

[PuppetDB - Feature #15020] Support for Oracle backend

[tickets]

Issue #15020 has been updated by Charlie Sharpsteen.


Redmine Issue [#15020](http://projects.puppetlabs.com/issues/15020) has been 
migrated to JIRA:

  



Feature #15020: Support for Oracle backend
https://projects.puppetlabs.com/issues/15020#change-101420

* Author: Jeff Chapin
* Status: Accepted
* Priority: Normal
* Assignee: 
* Category: 
* Target version: 
* Keywords: db database backend backlog
* Branch: 
* Affected PuppetDB version: 

It would be nice if puppetdb supported additional DB backends, such as Oracle.


-- 
You have received this notification because you have either subscribed to it, 
or are involved in it.
To change your notification preferences, please click here: 
http://projects.puppetlabs.com/my/account

-- 
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 http://groups.google.com/group/puppet-bugs.
For more options, visit https://groups.google.com/groups/opt_out.

[PuppetDB - Feature #15016] Improve warning message for invalid UTF-8 byte sequences

[tickets]

Issue #15016 has been updated by Charlie Sharpsteen.


Redmine Issue [#15016](http://projects.puppetlabs.com/issues/15016) has been 
migrated to JIRA:

  



Feature #15016: Improve warning message for invalid UTF-8 byte sequences
https://projects.puppetlabs.com/issues/15016#change-101419

* Author: Chris Price
* Status: Accepted
* Priority: Normal
* Assignee: 
* Category: 
* Target version: 
* Keywords: 
* Branch: 
* Affected PuppetDB version: 

Currently, when the puppetdb termini convert a string to UTF-8, any invalid 
byte sequences trigger a warning message that simply says "Ignoring invalid 
UTF-8 byte sequences in data to be sent to PuppetDB".  It should be fairly easy 
to provide a bit more context in these messages, which would perhaps allow 
users to determine which resource(s) triggered the warning.  Without this 
context, it can be difficult for a user to identify whether or not the 
offending resource is one that will cause problems for them, and/or to locate 
and correct it.


-- 
You have received this notification because you have either subscribed to it, 
or are involved in it.
To change your notification preferences, please click here: 
http://projects.puppetlabs.com/my/account

-- 
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 http://groups.google.com/group/puppet-bugs.
For more options, visit https://groups.google.com/groups/opt_out.

[MCollective - Feature #15006] Add PuppetDB based discovery

[tickets]

Issue #15006 has been updated by Charlie Sharpsteen.


Redmine Issue [#15006](http://projects.puppetlabs.com/issues/15006) has been 
migrated to JIRA:

  



Feature #15006: Add PuppetDB based discovery
https://projects.puppetlabs.com/issues/15006#change-101418

* Author: R.I. Pienaar
* Status: Accepted
* Priority: Normal
* Assignee: R.I. Pienaar
* Category: Backlog
* Target version: 2.1.x
* Keywords: backlog
* Branch: ploubser/mcollective-puppetdb-discovery
* Affected mCollective version: 

We should add PuppetDB based discovery, should be full featured capable of:

 * class matching with regex
 * identity matching with regex
 * fact matching with regex and all operators

It needs to support SSL certs through configuration settings but also 
unverified mode etc

It wont be sub collective aware unfortunately but the rest should be valuable, 
depends on #14763 being finished

there is a POC @ 
https://github.com/ripienaar/mc-plugins/blob/master/discovery/puppetdb/discovery/puppetdb.rb
 with some hardcoded behaviors but its capable of discovery against classes, 
facts and identities


-- 
You have received this notification because you have either subscribed to it, 
or are involved in it.
To change your notification preferences, please click here: 
http://projects.puppetlabs.com/my/account

-- 
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 http://groups.google.com/group/puppet-bugs.
For more options, visit https://groups.google.com/groups/opt_out.

[PuppetDB - Bug #14722] Purging resources that were exported resources sometimes fails

[tickets]

Issue #14722 has been updated by Charlie Sharpsteen.


Redmine Issue [#14722](http://projects.puppetlabs.com/issues/14722) has been 
migrated to JIRA:

  



Bug #14722: Purging resources that were exported resources sometimes fails
https://projects.puppetlabs.com/issues/14722#change-101417

* Author: Jason Hancock
* Status: Accepted
* Priority: Normal
* Assignee: Ken Barber
* Category: 
* Target version: 
* Keywords: 
* Branch: 
* Affected PuppetDB version: 1.1.1

I'm seeing an issue where sometimes I have an exported resource that is failing 
to be removed from the node that is collecting them after the node has been 
cleaned up by running a "puppet node clean " on the 
puppetmaster. For example, I'm exporting both nagios_host and nagios_service 
resources from my nodes and collecting them on my nagios server. On the nagios 
server, I've set up resources of these types to be purged:

resources { ['nagios_service', 'nagios_host']:
  purge  => true,
  notify => Service['nagios'],
}


If I purge a node on the puppetmaster:

puppet node clean node.example.com


On the next puppet run on the nagios server, I might get the following error 
message:

warning: /Nagios_service[node.example.com SSH]: 
Whit[Completed_stage[post]],Whit[Admissible_stage[post]],Whit[Admissible_stage[puppetcomplete]],Whit[Completed_stage[puppetcomplete]],
Whit[Completed_stage[main]],Whit[Completed_class[Nagios]],Service[nagios] still 
depend on me -- not purging


This doesn't happen all of the time, nor does it happen for all of the 
nagios_service resources for this node (other nagios_service resources get 
cleaned up just fine). I've seen this with both the nagios_host and the 
nagios_service type of resources. It will continue to occur for the same 
resource on any subsequent run of puppet on the nagios server. To remedy this, 
I have to manually remove the resource it is complaining about from the nagios 
configuration and restart the service (something I would like to avoid).

Not sure if it matters or not, but I'm using PuppetDB as the stored 
configurations backend.


-- 
You have received this notification because you have either subscribed to it, 
or are involved in it.
To change your notification preferences, please click here: 
http://projects.puppetlabs.com/my/account

-- 
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 http://groups.google.com/group/puppet-bugs.
For more options, visit https://groups.google.com/groups/opt_out.

[PuppetDB - Bug #14721] "puppet node clean" complains about missing sqlite3 lib when using PuppetDB as stored configs backend

[tickets]

Issue #14721 has been updated by Charlie Sharpsteen.


Redmine Issue [#14721](http://projects.puppetlabs.com/issues/14721) has been 
migrated to JIRA:

  



Bug #14721: "puppet node clean" complains about missing sqlite3 lib when using 
PuppetDB as stored configs backend
https://projects.puppetlabs.com/issues/14721#change-101416

* Author: Jason Hancock
* Status: Accepted
* Priority: Normal
* Assignee: Deepak Giridharagopal
* Category: 
* Target version: 
* Keywords: PuppetDB stored configs
* Branch: 
* Affected PuppetDB version: 

When using PuppetDB as the stored configurations backend(snippet from 
puppet.conf):

[master]
storeconfigs = true
storeconfigs_backend = puppetdb


And then performing a "puppet node clean ", puppet complains 
about a missing sqlite3 library, but since we're using PuppetDB as the backend, 
it really shouldn't matter that I don't have the sqlite3 gem installed. The 
exact error message is:


> puppet node clean node.example.com
notice: Revoked certificate with serial 81
notice: Removing file Puppet::SSL::Certificate node.example.com at 
'/var/lib/puppet/ssl/ca/signed/node.example.com.pem'
notice: Removing file Puppet::SSL::Certificate node.example.com at 
'/var/lib/puppet/ssl/certs/node.example.com.pem'
err: no such file to load -- sqlite3
err: Try 'puppet help node clean' for usage


Even though it complains, it does actually appear to clean up the node from 
PuppetDB, so this is more of an annoyance than anything.


-- 
You have received this notification because you have either subscribed to it, 
or are involved in it.
To change your notification preferences, please click here: 
http://projects.puppetlabs.com/my/account

-- 
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 http://groups.google.com/group/puppet-bugs.
For more options, visit https://groups.google.com/groups/opt_out.

[PuppetDB - Feature #14696] enhancements to SSL for puppet apply

[tickets]

Issue #14696 has been updated by Charlie Sharpsteen.


Redmine Issue [#14696](http://projects.puppetlabs.com/issues/14696) has been 
migrated to JIRA:

  



Feature #14696: enhancements to SSL for puppet apply
https://projects.puppetlabs.com/issues/14696#change-101415

* Author: R.I. Pienaar
* Status: Accepted
* Priority: Low
* Assignee: 
* Category: 
* Target version: 
* Keywords: 
* Branch: 
* Affected PuppetDB version: 

your typical puppet apply setup would not have a CA so there wont be certs 
prior to enabling the puppetdb terminus , when running it against a remote 
puppetdb you get:


warning: peer certificate won't be verified in this SSL session
err: Cached facts for dev4.devco.net failed: Failed to find facts from PuppetDB 
at dev3.devco.net:8081: SSL_connect returned=1 errno=0 state=SSLv3 read 
finished A: sslv3 alert bad certificate
warning: peer certificate won't be verified in this SSL session
Could not run: Could not retrieve facts for dev4.devco.net: Failed to submit 
'replace facts' command for dev4.devco.net to PuppetDB at dev3.devco.net:8081: 
SSL_connect returned=1 errno=0 state=SSLv3 read finished A: sslv3 alert bad 
certificate


So without a shared CA this leaves a few options:

 * let people specify completely custom sets of certs both on puppetdb and the 
node side as ppl might have some shared pki already
 * allow anon SSL which would at least encrypt the payload if not protect 
against MITM
 * allow plain text calls to the puppetdb and make this configurable on the 
clients



-- 
You have received this notification because you have either subscribed to it, 
or are involved in it.
To change your notification preferences, please click here: 
http://projects.puppetlabs.com/my/account

-- 
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 http://groups.google.com/group/puppet-bugs.
For more options, visit https://groups.google.com/groups/opt_out.

[PuppetDB - Feature #14608] Make "puppet node clean --unexport" work with PuppetDB

[tickets]

Issue #14608 has been updated by Charlie Sharpsteen.


Redmine Issue [#14608](http://projects.puppetlabs.com/issues/14608) has been 
migrated to JIRA:

  



Feature #14608: Make "puppet node clean --unexport" work with PuppetDB
https://projects.puppetlabs.com/issues/14608#change-101413

* Author: Deepak Giridharagopal
* Status: Accepted
* Priority: Normal
* Assignee: 
* Category: 
* Target version: 
* Keywords: customer
* Branch: 
* Affected PuppetDB version: 

The current node face has an --unexport option that tells clean to flag 
resources previously exported for a node to flip to ensure => absent (I think).

We should see if the existing implementation already works with PuppetDB (does 
it simply store a revised catalog or something), or if we need to implement our 
own support for this.

A good use case would be:

* decom a node
* have that node's nagios checks removed from the nagios server automatically 
the next time the nagios server's agent runs


-- 
You have received this notification because you have either subscribed to it, 
or are involved in it.
To change your notification preferences, please click here: 
http://projects.puppetlabs.com/my/account

-- 
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 http://groups.google.com/group/puppet-bugs.
For more options, visit https://groups.google.com/groups/opt_out.

[MCollective - Feature #14612] systemd files for mcollective.

[tickets]

Issue #14612 has been updated by Charlie Sharpsteen.


Redmine Issue [#14612](http://projects.puppetlabs.com/issues/14612) has been 
migrated to JIRA:

  



Feature #14612: systemd files for mcollective.
https://projects.puppetlabs.com/issues/14612#change-101414

* Author: Steve Traylen
* Status: Closed
* Priority: Normal
* Assignee: R.I. Pienaar
* Category: Packaging
* Target version: 2.3.3
* Keywords: mcollective, systemd, rpm, fedora
* Branch: https://github.com/puppetlabs/marionette-collective/pull/41
* Affected mCollective version: 

* A systemd file for mcollective.
* A updated .spec file that uses systemd with fedora17.

fedora 17 is due out in few days.


-- 
You have received this notification because you have either subscribed to it, 
or are involved in it.
To change your notification preferences, please click here: 
http://projects.puppetlabs.com/my/account

-- 
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 http://groups.google.com/group/puppet-bugs.
For more options, visit https://groups.google.com/groups/opt_out.

[Puppet - Bug #14458] Status unchanged when "Could not apply complete catalog"

[tickets]

Issue #14458 has been updated by Charlie Sharpsteen.


Redmine Issue [#14458](http://projects.puppetlabs.com/issues/14458) has been 
migrated to JIRA:

  



Bug #14458: Status unchanged when "Could not apply complete catalog"
https://projects.puppetlabs.com/issues/14458#change-101412

* Author: Roman Skvazh
* Status: Accepted
* Priority: Normal
* Assignee: 
* Category: reports
* Target version: 
* Affected Puppet version: 
* Keywords: dependency cycle, total, errors
* Branch: 

When puppet agent report:
Could not apply complete catalog: Found 1 dependency cycle: ... Try the 
'--graph' option and opening the resulting '.dot' file in OmniGraffle or 
GraphViz
there is no failed nodes.


-- 
You have received this notification because you have either subscribed to it, 
or are involved in it.
To change your notification preferences, please click here: 
http://projects.puppetlabs.com/my/account

-- 
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 http://groups.google.com/group/puppet-bugs.
For more options, visit https://groups.google.com/groups/opt_out.

[MCollective Plugins - Feature #14282] Blacklisted services to prevent accidental restarts

[tickets]

Issue #14282 has been updated by Charlie Sharpsteen.


Redmine Issue [#14282](http://projects.puppetlabs.com/issues/14282) has been 
migrated to JIRA:

  



Feature #14282: Blacklisted services to prevent accidental restarts
https://projects.puppetlabs.com/issues/14282#change-101411

* Author: Rilindo Foster
* Status: Accepted
* Priority: Normal
* Assignee: Richard Clamp
* Category: 
* Target version: 
* Keywords: 
* Branch: 
* Affected mCollective version: 

By default, you will be prompted if you were to execute a service action on all 
the nodes. Even so, it may be wise to add an option to read a file that 
contains a list of blacklisted services (e.g. KVM guests).

(I am tempted to write a patch myself and submit it, but I don’t think that my 
code would be acceptable anyway.) :)


-- 
You have received this notification because you have either subscribed to it, 
or are involved in it.
To change your notification preferences, please click here: 
http://projects.puppetlabs.com/my/account

-- 
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 http://groups.google.com/group/puppet-bugs.
For more options, visit https://groups.google.com/groups/opt_out.

[MCollective - Bug #14110] Work with stomp upstream to allow SSL version configurability

[tickets]

Issue #14110 has been updated by Charlie Sharpsteen.


Redmine Issue [#14110](http://projects.puppetlabs.com/issues/14110) has been 
migrated to JIRA:

  



Bug #14110: Work with stomp upstream to allow SSL version configurability
https://projects.puppetlabs.com/issues/14110#change-101409

* Author: Moses Mendoza
* Status: Accepted
* Priority: Normal
* Assignee: R.I. Pienaar
* Category: Plugins
* Target version: 2.0.x
* Keywords: 
* Branch: 
* Affected mCollective version: 

Currently, stomp ssl connection defaults to the SSLContext that is default with 
ruby ssl, which is SSLv23. With openssl 1.0, SSLv23 is disabled unless insecure 
SSLv2 ciphers are manually enabled. This means stomp over SSL won't work with 
openssl 1.0 servers by default (which is what ubuntu precise uses). We should 
work with stomp to allow a configurability of the SSL version.

related to : \#14078


-- 
You have received this notification because you have either subscribed to it, 
or are involved in it.
To change your notification preferences, please click here: 
http://projects.puppetlabs.com/my/account

-- 
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 http://groups.google.com/group/puppet-bugs.
For more options, visit https://groups.google.com/groups/opt_out.

[MCollective - Bug #14206] Lintian errors during debian build because the init script doesn't implement force-reload

[tickets]

Issue #14206 has been updated by Charlie Sharpsteen.


Redmine Issue [#14206](http://projects.puppetlabs.com/issues/14206) has been 
migrated to JIRA:

  



Bug #14206: Lintian errors during debian build because the init script doesn't 
implement force-reload
https://projects.puppetlabs.com/issues/14206#change-101410

* Author: Matthaus Owens
* Status: Code Insufficient
* Priority: Normal
* Assignee: Matthaus Owens
* Category: Packaging
* Target version: 2.0.x
* Keywords: 
* Branch: 
* Affected mCollective version: 

Debian init script needs to implement force-reload to avoid lintian errors as 
show below.

E: mcollective: init.d-script-does-not-implement-required-option 
etc/init.d/mcollective force-reload


-- 
You have received this notification because you have either subscribed to it, 
or are involved in it.
To change your notification preferences, please click here: 
http://projects.puppetlabs.com/my/account

-- 
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 http://groups.google.com/group/puppet-bugs.
For more options, visit https://groups.google.com/groups/opt_out.

[MCollective - Feature #13624] ZeroMQ Support

[tickets]

Issue #13624 has been updated by Charlie Sharpsteen.


Redmine Issue [#13624](http://projects.puppetlabs.com/issues/13624) has been 
migrated to JIRA:

  



Feature #13624: ZeroMQ Support
https://projects.puppetlabs.com/issues/13624#change-101406

* Author: Christopher Johnston
* Status: Needs Decision
* Priority: Normal
* Assignee: 
* Category: 
* Target version: 2.1.x
* Keywords: 
* Branch: 
* Affected mCollective version: 

Additional bus support for zeromq, unfortunately this would require a zeromq 
daemon of some sort but this would eliminate the complexity of setting up 
activemq and maintaining it.  


-- 
You have received this notification because you have either subscribed to it, 
or are involved in it.
To change your notification preferences, please click here: 
http://projects.puppetlabs.com/my/account

-- 
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 http://groups.google.com/group/puppet-bugs.
For more options, visit https://groups.google.com/groups/opt_out.

[Puppet - Bug #14088] Puppet yum provider for package resource does not appear to use 'release' tag to ensure latest

[tickets]

Issue #14088 has been updated by Charlie Sharpsteen.


Redmine Issue [#14088](http://projects.puppetlabs.com/issues/14088) has been 
migrated to JIRA:

  



Bug #14088: Puppet yum provider for package resource does not appear to use 
'release' tag to ensure latest
https://projects.puppetlabs.com/issues/14088#change-101408

* Author: Mark Koch
* Status: Accepted
* Priority: Normal
* Assignee: 
* Category: 
* Target version: 
* Affected Puppet version: 
* Keywords: customer
* Branch: 

Puppet's yum provider for the package resource does not appear to offer 
complete support for RPM naming/versioning.

Yum compares RPMs using the RPM naming convention (e.g 
name-version-release.arch.rpm).  Our snapshot RPMs make use of this convention 
and rely upon the fact that yum can distinguish between RPMs based on the 
release components.  

For example, in our yum snapshot repo we have;


mds-2.0.1-SNAPSHOT20120418213747.noarch.rpm
mds-2.0.1-SNAPSHOT20120418220425.noarch.rpm
mds-2.0.1-SNAPSHOT20120418221358.noarch.rpm
mds-2.0.1-SNAPSHOT20120418223400.noarch.rpm


When we run 'yum install mds-2.0.1', yum will select the rpm with release = 
SNAPSHOT20120418223400 as the latest version of mds-2.0.1.  

When we attempt to use Puppet's package resource to perform the same operation 
with


package { 'mds-2.0.1':
ensure => latest
}


Puppet appears to use rpm to gather information about the local install but 
then does not compare the result to what the yum repo can provide (.i.e. 
compare release tags).  Instead it simply ensures that an rpm with a matching 
name-version has been installed.

To workaround this issue we're currently calling yum directly using,


exec { "install mds-${meter_data_service_version}":
command => "yum -d 1 -e 1 install mds-${meter_data_service_version} -y",
path=> "/usr/bin/",
}


This is functional but couples us to yum and is not recommended practice in 
Puppet.


-- 
You have received this notification because you have either subscribed to it, 
or are involved in it.
To change your notification preferences, please click here: 
http://projects.puppetlabs.com/my/account

-- 
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 http://groups.google.com/group/puppet-bugs.
For more options, visit https://groups.google.com/groups/opt_out.

[MCollective Plugins - Feature #13625] nrpe agent should support nrpe.cfg include_file, include and include_dir option

[tickets]

Issue #13625 has been updated by Charlie Sharpsteen.


Redmine Issue [#13625](http://projects.puppetlabs.com/issues/13625) has been 
migrated to JIRA:

  



Feature #13625: nrpe agent should support nrpe.cfg include_file, include and 
include_dir option
https://projects.puppetlabs.com/issues/13625#change-101407

* Author: Christian Albrecht
* Status: Code Insufficient
* Priority: Normal
* Assignee: Richard Clamp
* Category: 
* Target version: 
* Keywords: 
* Branch: 
* Affected mCollective version: 

The nrpe agent should support nrpe.cfg include_file, include and include_dir 
option to lookup for command definitions.
I have made a pull request on github with a possible solution.

https://github.com/puppetlabs/mcollective-plugins/pull/37




-- 
You have received this notification because you have either subscribed to it, 
or are involved in it.
To change your notification preferences, please click here: 
http://projects.puppetlabs.com/my/account

-- 
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 http://groups.google.com/group/puppet-bugs.
For more options, visit https://groups.google.com/groups/opt_out.

[Puppet - Feature #12930] Provide a manifest directory where all manifests are automatically parsed.

[tickets]

Issue #12930 has been updated by Charlie Sharpsteen.


Redmine Issue [#12930](http://projects.puppetlabs.com/issues/12930) has been 
migrated to JIRA:

  



Feature #12930: Provide a manifest directory where all manifests are 
automatically parsed.
https://projects.puppetlabs.com/issues/12930#change-101405

* Author: Nigel Kersten
* Status: Investigating
* Priority: Normal
* Assignee: J.D. Welch
* Category: 
* Target version: 3.x
* Affected Puppet version: 
* Keywords: ux
* Branch: 

There is at least one major use case where users need to import a set of 
manifest files, the following pattern:


# manifests/site.pp
import nodes/*.pp


As per the parent ticket, we're looking to deprecate `import`, and the most 
obvious solution appears to be to offer a configuration option for a directory 
where all manifest files are automatically parsed, much like site.pp is now.

This option *does* need to be per-environment.

Randall, I'm looking for input from your team on the user-facing design here, 
and if this solution is appropriate, tactical info like the actual name of the 
configuration parameter.



-- 
You have received this notification because you have either subscribed to it, 
or are involved in it.
To change your notification preferences, please click here: 
http://projects.puppetlabs.com/my/account

-- 
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 http://groups.google.com/group/puppet-bugs.
For more options, visit https://groups.google.com/groups/opt_out.

[Puppet - Feature #12929] Deprecate "import"

[tickets]

Issue #12929 has been updated by Charlie Sharpsteen.


Redmine Issue [#12929](http://projects.puppetlabs.com/issues/12929) has been 
migrated to JIRA:

  <https://tickets.puppetlabs.com/browse/PUP-866>



Feature #12929: Deprecate "import"
https://projects.puppetlabs.com/issues/12929#change-101404

* Author: Nigel Kersten
* Status: Accepted
* Priority: Normal
* Assignee: Nigel Kersten
* Category: 
* Target version: 3.x
* Affected Puppet version: 
* Keywords: telly_deprecation
* Branch: 

The distinction between import and include/class declaration confuses many 
users, and we've had a number of edge cases with import that have caused even 
more confusion.

The path forward is to structure your manifests in classes in modules, and to 
follow autoloader conventions. This does make Puppet much more opinionated, but 
we believe the benefits are worth it.

Particularly this will push people towards a world where Puppet manifests are 
more easily shareable in the form of modules, and by running everyone through 
the autoloader, we'll have a much more consistent set of behaviors.

We believe there is only one major required use case for `import`, the 
following pattern:


# manifests/site.pp
import nodes/*.pp


where users have separate DSL node definitions in a nodes subdirectory, and 
wish to import them all.

We're committed to solving this use case in associated tickets.

If people have other valid use cases for import that the autoloader cannot 
support, please comment on this ticket.


-- 
You have received this notification because you have either subscribed to it, 
or are involved in it.
To change your notification preferences, please click here: 
http://projects.puppetlabs.com/my/account

-- 
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 http://groups.google.com/group/puppet-bugs.
For more options, visit https://groups.google.com/groups/opt_out.

[Puppet - Bug #12173] Masters cannot reliably distinguish between multiple versions of a type/function/plugin used in different environments

[tickets]

Issue #12173 has been updated by Charlie Sharpsteen.


Redmine Issue [#12173](http://projects.puppetlabs.com/issues/12173) has been 
migrated to JIRA:

  



Bug #12173: Masters cannot reliably distinguish between multiple versions of a 
type/function/plugin used in different environments
https://projects.puppetlabs.com/issues/12173#change-101402

* Author: Nigel Kersten
* Status: Accepted
* Priority: Normal
* Assignee: eric sorenson
* Category: environments
* Target version: 3.x
* Affected Puppet version: 2.7.0
* Keywords: telly_deprecation BD customer
* Branch: 

Quoted from a previous ticket, #4409

The key problem is that a master can’t reliably distinguish between two 
versions of the same native type that are used in different environments (or 
between an environment which uses a native type and an environment which 
doesn’t). This is due to the fact that native types are defined using ruby 
code, which the master loads into Ruby classes via “require”. Since there can 
only be one Ruby class with a given name at a time, this prevents the master 
from being able to have two different versions of the same type in two 
different environments. This makes life difficult for people who are trying to 
use a “test” environment to try out a new version of a native type on a limited 
set of nodes before deploying it to all nodes.

A secondary problem is that the location where the master looks for the 
definition of native types is not the same as the location of plug-in files 
that the master distributes to agents. This leads to confusion even for people 
who are not using a “test” environment, because it means that they have to put 
their type definitions in two places, one where they can be picked up by the 
master and one where they can be sent as plug-ins to agents.


-- 
You have received this notification because you have either subscribed to it, 
or are involved in it.
To change your notification preferences, please click here: 
http://projects.puppetlabs.com/my/account

-- 
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 http://groups.google.com/group/puppet-bugs.
For more options, visit https://groups.google.com/groups/opt_out.

[Puppet - Bug #12361] "masterlog" option does not appear to be used

[tickets]

Issue #12361 has been updated by Charlie Sharpsteen.


Redmine Issue [#12361](http://projects.puppetlabs.com/issues/12361) has been 
migrated to JIRA:

  <https://tickets.puppetlabs.com/browse/PUP-877>



Bug #12361: "masterlog" option does not appear to be used
https://projects.puppetlabs.com/issues/12361#change-101403

* Author: Chris Price
* Status: Code Insufficient
* Priority: High
* Assignee: 
* Category: logging
* Target version: 3.x
* Affected Puppet version: 
* Keywords: 
* Branch: 

"masterlog" appears in our "defaults" option list for the master, as well as in 
our documentation (e.g. 
http://docs.puppetlabs.com/references/2.7.9/configuration.html ).

However it does not appear to be used in the code anywhere (it seems that 
--logdest is the preferred method for dealing with this these days).

There were some tickets related to this in the past, some of which were marked 
as dupes (e.g. #4550); however, the issue of removing this from our 
documentation does not actually seem like a dupe of the other tickets to me.


-- 
You have received this notification because you have either subscribed to it, 
or are involved in it.
To change your notification preferences, please click here: 
http://projects.puppetlabs.com/my/account

-- 
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 http://groups.google.com/group/puppet-bugs.
For more options, visit https://groups.google.com/groups/opt_out.

[Puppet - Bug #11989] upstart service operating system confine should include redhat and centos

[tickets]

Issue #11989 has been updated by Charlie Sharpsteen.


Redmine Issue [#11989](http://projects.puppetlabs.com/issues/11989) has been 
migrated to JIRA:

  



Bug #11989: upstart service operating system confine should include redhat and 
centos
https://projects.puppetlabs.com/issues/11989#change-101401

* Author: Nathan Huff
* Status: Code Insufficient
* Priority: Normal
* Assignee: 
* Category: service
* Target version: 3.x
* Affected Puppet version: 2.7.9
* Keywords: upstart simplefix customer
* Branch: https://github.com/puppetlabs/puppet/pull/813

RedHat EL 6 and Centos 6 both use upstart for init.  The upstart service type 
should be able to be used on those systems as well.

I have done some very minor testing to make sure it at least works to ensure 
services are running and stopped.


-- 
You have received this notification because you have either subscribed to it, 
or are involved in it.
To change your notification preferences, please click here: 
http://projects.puppetlabs.com/my/account

-- 
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 http://groups.google.com/group/puppet-bugs.
For more options, visit https://groups.google.com/groups/opt_out.

[Hiera - Feature #11784] Hiera should support alternate environments

[tickets]

Issue #11784 has been updated by Charlie Sharpsteen.


Redmine Issue [#11784](http://projects.puppetlabs.com/issues/11784) has been 
migrated to JIRA:

  



Feature #11784: Hiera should support alternate environments
https://projects.puppetlabs.com/issues/11784#change-101400

* Author: Hunter Haugen
* Status: Needs More Information
* Priority: Normal
* Assignee: eric sorenson
* Category: hiera
* Target version: 2.0.0
* Keywords: hiera
* Branch: 
* Affected Hiera Version: 

Currently hiera supports one `hiera.yaml` file hardcoded to be in the same 
location as `puppet.conf` (which is the `config` puppet directive.

Having separate `hiera.yaml`'s per puppet environment would go along with 
having separate `site.pp`'s, modules, etc. per environment.


-- 
You have received this notification because you have either subscribed to it, 
or are involved in it.
To change your notification preferences, please click here: 
http://projects.puppetlabs.com/my/account

-- 
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 http://groups.google.com/group/puppet-bugs.
For more options, visit https://groups.google.com/groups/opt_out.

[MCollective - Bug #9956] servers have dependency on collective "mcollective" which can be broken by config file change

[tickets]

Issue #9956 has been updated by Charlie Sharpsteen.


Redmine Issue [#9956](http://projects.puppetlabs.com/issues/9956) has been 
migrated to JIRA:

  



Bug #9956: servers have dependency on collective "mcollective" which can be 
broken by config file change
https://projects.puppetlabs.com/issues/9956#change-101399

* Author: Luke Bigum
* Status: Accepted
* Priority: Low
* Assignee: 
* Category: Core
* Target version: 
* Keywords: 
* Branch: 
* Affected mCollective version: 

I'm using a number of collectives by specify the "collectives = foo,bar,baz" in 
the server.cfg file. When starting a 1.3.1 server, it complains that 
"mcollective" is not a valid collective, as I haven't explicitly added it.

W, [2011-10-06T17:14:50.329529 #27270]  WARN -- : base.rb:50:in 
`target_collective' Sending registration to mcollective: mcollective is not a 
valid collective
E, [2011-10-06T17:14:50.331950 #27270] ERROR -- : base.rb:29:in `run' Sending 
registration message failed: Unknown collective 'mcollective' known collectives 
are 'all'

Easy to work around, but a more robust approach might be to silently generate 
the "mcollective" collective if it's not there and it's needed so badly.


-- 
You have received this notification because you have either subscribed to it, 
or are involved in it.
To change your notification preferences, please click here: 
http://projects.puppetlabs.com/my/account

-- 
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 http://groups.google.com/group/puppet-bugs.
For more options, visit https://groups.google.com/groups/opt_out.

[MCollective Plugins - Bug #9040] mongodb-registration agent: Execution of registration failed: Symbol as array index

[tickets]

Issue #9040 has been updated by Charlie Sharpsteen.


Redmine Issue [#9040](http://projects.puppetlabs.com/issues/9040) has been 
migrated to JIRA:

  



Bug #9040: mongodb-registration agent: Execution of registration failed: Symbol 
as array index
https://projects.puppetlabs.com/issues/9040#change-101398

* Author: Shanker Balan
* Status: Code Insufficient
* Priority: Normal
* Assignee: 
* Category: 
* Target version: 
* Keywords: 
* Branch: 
* Affected mCollective version: 

Helo,   







The mongodb registration agent croaks if it encounters a non meta.rb



registration message (in my case, it was registration/agentlist.rb which were   



sending out agentlist messages) as below:   







E, [2011-08-17T01:03:16.027138 #21276] ERROR -- : agents.rb:116:in `dispatch'   



Execution of registration failed: Symbol as array index 



E, [2011-08-10T06:20:22.240545 #2168] ERROR -- : agents.rb:117:in `dispatch'



/usr/share/mcollective/plugins/mcollective/agent/registration.rb:58:in `[]' 



/usr/share/mcollective/plugins/mcollective/agent/registration.rb:58:in  



`handlemsg' 



/usr/lib/ruby/1.8/mcollective/agents.rb:104:in `dispatch'   



/usr/lib/ruby/1.8/timeout.rb:62:in `timeout'



/usr/lib/ruby/1.8/mcollective/agents.rb:103:in `dispatch'   



/usr/lib/ruby/1.8/mcollective/agents.rb:99:in `initialize'  



/usr/lib/ruby/1.8/mcollective/agents.rb:99:in `new' 
  

[MCollective - Feature #6291] Support for dpkg / deb trigger to reload agents

[tickets]

Issue #6291 has been updated by Charlie Sharpsteen.


Redmine Issue [#6291](http://projects.puppetlabs.com/issues/6291) has been 
migrated to JIRA:

  



Feature #6291: Support for dpkg / deb trigger to reload agents
https://projects.puppetlabs.com/issues/6291#change-101394

* Author: Kiall Mac Innes
* Status: Investigating
* Priority: Normal
* Assignee: 
* Category: Packaging
* Target version: 
* Keywords: 
* Branch: 
* Affected mCollective version: 

Dpkg/Deb triggers can be used to detect the installation of a new agent and 
trigger a reload of the agents via sig USR1.

This is a *nearly* completely undocumented feature of debian packaging. The 
best reference available to my knowledge is 
http://www.seanius.net/blog/2009/09/dpkg-triggers-howto/


-- 
You have received this notification because you have either subscribed to it, 
or are involved in it.
To change your notification preferences, please click here: 
http://projects.puppetlabs.com/my/account

-- 
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 http://groups.google.com/group/puppet-bugs.
For more options, visit https://groups.google.com/groups/opt_out.

[Puppet - Refactor #8758] Yumrepo should be refactored to use a provider

[tickets]

Issue #8758 has been updated by Charlie Sharpsteen.


Redmine Issue [#8758](http://projects.puppetlabs.com/issues/8758) has been 
migrated to JIRA:

  



Refactor #8758: Yumrepo should be refactored to use a provider
https://projects.puppetlabs.com/issues/8758#change-101397

* Author: Luke Kanies
* Status: In Topic Branch Pending Review
* Priority: Normal
* Assignee: 
* Category: yumrepo
* Target version: 3.5.0
* Affected Puppet version: 
* Keywords: 
* Branch: https://github.com/puppetlabs/puppet/pull/2086

The current implementation of Yumrepo has all of the work done directly in the 
type, rather than using a provider.

We should instead refactor it to use a provider, which should also make the 
code cleaner and easier to maintain.

I've got a patch that does at least a bit of this, but I never got it to 
production.


-- 
You have received this notification because you have either subscribed to it, 
or are involved in it.
To change your notification preferences, please click here: 
http://projects.puppetlabs.com/my/account

-- 
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 http://groups.google.com/group/puppet-bugs.
For more options, visit https://groups.google.com/groups/opt_out.

[Puppet - Bug #7709] expanded_relationship.dot should not have both containment and relationship edges

[tickets]

Issue #7709 has been updated by Charlie Sharpsteen.


Redmine Issue [#7709](http://projects.puppetlabs.com/issues/7709) has been 
migrated to JIRA:

  



Bug #7709: expanded_relationship.dot should not have both containment and 
relationship edges
https://projects.puppetlabs.com/issues/7709#change-101395

* Author: Jeff McCune
* Status: Accepted
* Priority: Normal
* Assignee: 
* Category: 
* Target version: 
* Affected Puppet version: 
* Keywords: cycle graph containment edge relationship frontier
* Branch: 

# Overview #

Running against master (2.7.0rc3-135-g520cbc0) I notice that using --graph has 
obvious cycles in the graph when the catalog itself does not actually have 
cycles and applies cleanly.

Please see the attached screenshot.

Talking with Daniel, the suspicion is that the graphing output is not drawing a 
distinction between containment edges and relationship edges and is displaying 
both in the graph output.

# Desired Behavior #

The graph output should only display relationship edges between resources as it 
does with Puppet 2.6 and earlier.

# Actual Behavior #

Visible cycles are displayed in the graph output when there are no relationship 
edge cycles.

# Steps to reproduce #

A simple catalog should show some resources looping against themselves.  I can 
provide example manifests upon request.




-- 
You have received this notification because you have either subscribed to it, 
or are involved in it.
To change your notification preferences, please click here: 
http://projects.puppetlabs.com/my/account

-- 
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 http://groups.google.com/group/puppet-bugs.
For more options, visit https://groups.google.com/groups/opt_out.

[MCollective Plugins - Feature #7831] Make mongo registration config more flexible

[tickets]

Issue #7831 has been updated by Charlie Sharpsteen.


Redmine Issue [#7831](http://projects.puppetlabs.com/issues/7831) has been 
migrated to JIRA:

  



Feature #7831: Make mongo registration config more flexible
https://projects.puppetlabs.com/issues/7831#change-101396

* Author: Sheldon Hearn
* Status: Code Insufficient
* Priority: Normal
* Assignee: 
* Category: 
* Target version: 
* Keywords: 
* Branch: 
* Affected mCollective version: 

The change referenced below would:

* Make timeout configurable.
* Support mongo authentication.
* Support mongo replicasets.

https://github.com/sheldonh/mcollective-plugins/commit/94530908


-- 
You have received this notification because you have either subscribed to it, 
or are involved in it.
To change your notification preferences, please click here: 
http://projects.puppetlabs.com/my/account

-- 
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 http://groups.google.com/group/puppet-bugs.
For more options, visit https://groups.google.com/groups/opt_out.

[MCollective - Feature #5376] Retrieve config variables

[tickets]

Issue #5376 has been updated by Charlie Sharpsteen.


Redmine Issue [#5376](http://projects.puppetlabs.com/issues/5376) has been 
migrated to JIRA:

  



Feature #5376: Retrieve config variables
https://projects.puppetlabs.com/issues/5376#change-101391

* Author: Gary Larizza
* Status: Accepted
* Priority: Normal
* Assignee: R.I. Pienaar
* Category: 
* Target version: 
* Keywords: 
* Branch: 
* Affected mCollective version: 

It would be handy to be able to pull the server.cfg and client.cfg 
configuration variables through mcollective to help track down client config 
issues.  R.I. had an initial implementation of this here --> 
https://gist.github.com/710504


-- 
You have received this notification because you have either subscribed to it, 
or are involved in it.
To change your notification preferences, please click here: 
http://projects.puppetlabs.com/my/account

-- 
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 http://groups.google.com/group/puppet-bugs.
For more options, visit https://groups.google.com/groups/opt_out.

[MCollective - Feature #6081] Support for debconf selections in the debian packaging.

[tickets]

Issue #6081 has been updated by Charlie Sharpsteen.


Redmine Issue [#6081](http://projects.puppetlabs.com/issues/6081) has been 
migrated to JIRA:

  



Feature #6081: Support for debconf selections in the debian packaging.
https://projects.puppetlabs.com/issues/6081#change-101393

* Author: Kiall Mac Innes
* Status: Needs More Information
* Priority: Normal
* Assignee: 
* Category: Packaging
* Target version: 
* Keywords: 
* Branch: master
* Affected mCollective version: 1.1.0

Allowing initial configuration to be performed via debconf selections makes 
automated deployment much easier.

e.g. tools like Ubuntu's CloudConfig can be used to install and setup 
mcollective.

I have a patch nearly ready for this - adding a ticket now to get a ticket # 
for the commit.


-- 
You have received this notification because you have either subscribed to it, 
or are involved in it.
To change your notification preferences, please click here: 
http://projects.puppetlabs.com/my/account

-- 
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 http://groups.google.com/group/puppet-bugs.
For more options, visit https://groups.google.com/groups/opt_out.

[Puppet - Feature #5456] package type should accept virtual package for rpm

[tickets]

Issue #5456 has been updated by Charlie Sharpsteen.


Redmine Issue [#5456](http://projects.puppetlabs.com/issues/5456) has been 
migrated to JIRA:

  



Feature #5456: package type should accept virtual package for rpm
https://projects.puppetlabs.com/issues/5456#change-101392

* Author: Michael Scherer
* Status: Accepted
* Priority: Normal
* Assignee: 
* Category: package
* Target version: 3.5.0
* Affected Puppet version: 2.6.4
* Keywords: 
* Branch: 

Rpm ( like many similar package systems ) define a system of virtual package, 
with the tag Provides.
For example, on Mandriva, we have :

$ rpm -q --provides perl-Term-Size-Any-0.1.0-2mdv2010.1
perl(Term::Size::Any) = 0.1.0
perl-Term-Size-Any = 0.1.0-2mdv2010.1

So I can use "urpmi perl(Term::Size::Any)" to install the rpm. 
On puppet, the type package do not seem to take this fully in account.
if I use this :
package { 'perl(Term::Size::Any)': ensure => installed }

The package is installed, but I see a error message :
err: /Stage[main]//Node[valstar]/Package[perl(Term::Size::Any)]/ensure: 
change from absent to present failed: Could not find package 
perl(Term::Size::Any)

Here is a patch that fix this. It should allows to use any Provides for all rpm 
based package managers, but I only checked with urpmi and yum.
It should work ok on all of them, since using a Provides instead of the exact 
rpm name is a very common feature.



-- 
You have received this notification because you have either subscribed to it, 
or are involved in it.
To change your notification preferences, please click here: 
http://projects.puppetlabs.com/my/account

-- 
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 http://groups.google.com/group/puppet-bugs.
For more options, visit https://groups.google.com/groups/opt_out.

[MCollective - Bug #5372] bldmacpkg script is broken

[tickets]

Issue #5372 has been updated by Charlie Sharpsteen.


Redmine Issue [#5372](http://projects.puppetlabs.com/issues/5372) has been 
migrated to JIRA:

  



Bug #5372: bldmacpkg script is broken
https://projects.puppetlabs.com/issues/5372#change-101390

* Author: Carl Caum
* Status: Investigating
* Priority: Normal
* Assignee: 
* Category: Packaging
* Target version: 
* Keywords: 
* Branch: 
* Affected mCollective version: 

The Mac OS X packaging script, bldmacpkg, is broken.  Something's wrong with 
the encoding, but I can't figure out what.  The code itself functions fine.


-- 
You have received this notification because you have either subscribed to it, 
or are involved in it.
To change your notification preferences, please click here: 
http://projects.puppetlabs.com/my/account

-- 
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 http://groups.google.com/group/puppet-bugs.
For more options, visit https://groups.google.com/groups/opt_out.

[Puppet - Bug #1238] Due to prefetching, Yumrepo clobbers any definition that it does not create

[tickets]

Issue #1238 has been updated by Charlie Sharpsteen.


Redmine Issue [#1238](http://projects.puppetlabs.com/issues/1238) has been 
migrated to JIRA:

  



Bug #1238: Due to prefetching, Yumrepo clobbers any definition that it does not 
create
https://projects.puppetlabs.com/issues/1238#change-101387

* Author: BMDan -
* Status: Accepted
* Priority: Normal
* Assignee: 
* Category: yumrepo
* Target version: 3.x
* Affected Puppet version: 
* Keywords: 
* Branch: 

Yumrepo appears to be checking file existence before allowing the package 
command to complete, meaning that it creates a file containing only "[remi]" 
and "enabled=1", overwriting the file that the RPM installed.

Manifests, additional debug output, etc., available upon request.  Just tell me 
what you need to know.  Workarounds especially welcomed.  Puppet v. 0.24.4, 
running with --debug --test, on Ruby 1.8.6.114-1, compiled from source with 
default options.


debug: //Node[default]/remi_enabled/Yumrepo[remi]/require: requires 
Package[remi-release-5-4.el5.remi]

...

debug: Puppet::Type::Package::ProviderRpm: Not suitable: false value
debug: Puppet::Type::Package::ProviderRpm: Executing '/bin/rpm -q 
remi-release-5-4.el5.remi --nosignature --nodigest --qf %{NAME} 
%|EPOCH?{%{EPOCH}}:{0}| %{VERSION} %{RELEASE} %{ARCH}'
debug: /Package[remi-release-5-4.el5.remi]: Changing ensure
debug: /Package[remi-release-5-4.el5.remi]: 1 change(s)
debug: Puppet::Type::Package::ProviderRpm: Executing '/bin/rpm -i --oldpackage 
http://rpms.famillecollet.com/el5.x86_64/remi-release-5-4.el5.remi.noarch.rpm'
notice: /Package[remi-release-5-4.el5.remi]/ensure: created
info: create new repo remi in file /etc/yum.repos.d/remi.repo
debug: //Node[default]/remi_enabled/Yumrepo[remi]: Changing enabled
debug: //Node[default]/remi_enabled/Yumrepo[remi]: 1 change(s)
notice: //Node[default]/remi_enabled/Yumrepo[remi]/enabled: defined 'enabled' 
as '1'
info: Filebucket[/var/lib/puppet/clientbucket]: Adding 
/etc/yum.repos.d/remi.repo(18f7009978e772c9c646b9410fa3a8b6)



-- 
You have received this notification because you have either subscribed to it, 
or are involved in it.
To change your notification preferences, please click here: 
http://projects.puppetlabs.com/my/account

-- 
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 http://groups.google.com/group/puppet-bugs.
For more options, visit https://groups.google.com/groups/opt_out.

[MCollective - Bug #5095] Handle STOMP errors better

[tickets]

Issue #5095 has been updated by Charlie Sharpsteen.


Redmine Issue [#5095](http://projects.puppetlabs.com/issues/5095) has been 
migrated to JIRA:

  



Bug #5095: Handle STOMP errors better
https://projects.puppetlabs.com/issues/5095#change-101389

* Author: R.I. Pienaar
* Status: Needs Decision
* Priority: Normal
* Assignee: 
* Category: Plugins
* Target version: 
* Keywords: 
* Branch: 
* Affected mCollective version: 0.4.10

In cases where the Stomp connection fails for whatever reason we get exceptions 
like these:


W, [2010-04-21T11:11:48.994749 #3225]  WARN -- : 3225 runner.rb:75:in `run': 
Failed to 
handle message: undefined method `body' for nil:NilClass - NoMethodError

W, [2010-04-21T11:11:48.994878 #3225]  WARN -- : 3225 runner.rb:76:in `run': 
/usr/share/mcollective/plugins/mcollective/connector/stomp.rb:64:in `receive'
/usr/lib/ruby/1.8/mcollective/runner.rb:151:in `receive'
/usr/lib/ruby/1.8/mcollective/runner.rb:52:in `run'
/usr/lib/ruby/1.8/mcollective/runner.rb:50:in `loop'
/usr/lib/ruby/1.8/mcollective/runner.rb:50:in `run'
/usr/sbin/mcollectived:49
/usr/lib/ruby/1.8/mcollective/runner.rb:38:in `daemonize'
/usr/lib/ruby/1.8/mcollective/runner.rb:30:in `fork'
/usr/lib/ruby/1.8/mcollective/runner.rb:30:in `daemonize'
/usr/sbin/mcollectived:40


Ideal behavior would be to get a usable error message saying you gave the wrong 
password.

This is problematic in that the Stomp gem prefers to do all its own error 
handling, reconnection handling etc and in many cases just dont raise errors.

I can catch this specific error but later on then errors just get logged to 
STDERR by the gem and no exceptions raised for publish errors.  Handling the 
error above and exiting or at least logging a useful hint about the problem 
would be better



-- 
You have received this notification because you have either subscribed to it, 
or are involved in it.
To change your notification preferences, please click here: 
http://projects.puppetlabs.com/my/account

-- 
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 http://groups.google.com/group/puppet-bugs.
For more options, visit https://groups.google.com/groups/opt_out.

[MCollective - Bug #5080] Need a better config class

[tickets]

Issue #5080 has been updated by Charlie Sharpsteen.


Redmine Issue [#5080](http://projects.puppetlabs.com/issues/5080) has been 
migrated to JIRA:

  



Bug #5080: Need a better config class
https://projects.puppetlabs.com/issues/5080#change-101388

* Author: R.I. Pienaar
* Status: Accepted
* Priority: Normal
* Assignee: Pieter Loubser
* Category: Backlog
* Target version: 2.3.x
* Keywords: backlog
* Branch: 
* Affected mCollective version: 

The current config class is all hard coded and horrible regex parsing at the 
moment, we should improve it:

 * config should be expressed in code, like some kind of DSL.  
 * DSL should set defaults, CLI overrides and ENV based overrides
 * DSL should set validations of configs
 * plugins config should be improved so that plugins essentially register their 
interest in specific options, with similar overrides



-- 
You have received this notification because you have either subscribed to it, 
or are involved in it.
To change your notification preferences, please click here: 
http://projects.puppetlabs.com/my/account

-- 
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 http://groups.google.com/group/puppet-bugs.
For more options, visit https://groups.google.com/groups/opt_out.

[Hiera - Bug #23409] No man pages for hiera

[tickets]

Issue #23409 has been updated by Charlie Sharpsteen.


Redmine Issue [#23409](http://projects.puppetlabs.com/issues/23409) has been 
migrated to JIRA:

  



Bug #23409: No man pages for hiera
https://projects.puppetlabs.com/issues/23409#change-101386

* Author: Josh Cooper
* Status: Accepted
* Priority: Normal
* Assignee: 
* Category: 
* Target version: 
* Keywords: 
* Branch: 
* Affected Hiera Version: 


# apt-get install hiera
...
# man hiera
No manual entry for hiera
See 'man 7 undocumented' for help when manual pages are not available.




-- 
You have received this notification because you have either subscribed to it, 
or are involved in it.
To change your notification preferences, please click here: 
http://projects.puppetlabs.com/my/account

-- 
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 http://groups.google.com/group/puppet-bugs.
For more options, visit https://groups.google.com/groups/opt_out.

[Puppet - Feature #7286] Add virtualenv support to the pip package provider

[tickets]

Issue #7286 has been updated by Jason Antman.


Daniel, is there any update on this?

I'm about to post a thread to puppet-users regarding this. It's seeming to me, 
after doing some more research, that the current "package" provider is married 
to system-wide/global packages only (also puppetlabs-nodejs using a native 
provider for global npm packages and a defined type for local ones seems to 
substantiate this). I'm starting to believe that this feature may be impossible 
within the current package type, and would require another type - something 
specific to packages in isolated/non-system-wide environments.


Feature #7286: Add virtualenv support to the pip package provider
https://projects.puppetlabs.com/issues/7286#change-101385

* Author: Jonathan Stoppani
* Status: Needs Decision
* Priority: Normal
* Assignee: Jason Antman
* Category: provider
* Target version: 
* Affected Puppet version: 
* Keywords: pip virtualenv python package
* Branch: https://github.com/SMAC/puppet/tree/feature/master/7286

Now that #6527 is merged into master, it is possible to easily add support for 
virtualenvs and fully complete #3572.

A `virtualenv` argument could be added to the `package` type in order to 
instrument `pip` to install the requested package into the given virtualenv 
directory.

For example:
 
 package { "my-python-package":
 ensure => latest,
 provider => pip,
 virtualenv => "/path/to/virtualenv
 }

The content of the virtualenv parameter will be passed directly to the 
`--environment` parameter of the `pip install` command

Some references:

* [http://pypi.python.org/pypi/pip](http://pypi.python.org/pypi/pip)
* 
[http://www.pip-installer.org/en/latest/index.html#using-pip-with-virtualenv](http://www.pip-installer.org/en/latest/index.html#using-pip-with-virtualenv)
* 
[https://github.com/puppetlabs/puppet/blob/master/lib/puppet/provider/package/pip.rb](https://github.com/puppetlabs/puppet/blob/master/lib/puppet/provider/package/pip.rb)



-- 
You have received this notification because you have either subscribed to it, 
or are involved in it.
To change your notification preferences, please click here: 
http://projects.puppetlabs.com/my/account

-- 
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 http://groups.google.com/group/puppet-bugs.
For more options, visit https://groups.google.com/groups/opt_out.

[Puppet - Bug #22848] Encoding mis-matches cause package prefetching to fail

[tickets]

Issue #22848 has been updated by Charles Olivier.


This issue seems to only affect the client side. 
Additionally, I found a quick fix, which works for me.
I use KVM on Debian 7.2 with Puppet 3 and The Foreman.
My VMs are a mix of Ubuntu and Debian boxes.  I use PXE and preseed to install 
guests.
I added the following to my /etc/default/puppet file in a post install script:

## export LANG=en_US.UTF-8

If you look in the puppet init.d script it sources the /etc/default/puppet file 
if it exists.
Thus the export is executed and the LANG environment variable is set.

I have tested with Ubuntu 13.10 and Debian 7.2 clients and i see no more red 
notifications in The Foreman.
I hope this helps anyone also frustrated with the lack of answers... :-)


Bug #22848: Encoding mis-matches cause package prefetching to fail
https://projects.puppetlabs.com/issues/22848#change-101384

* Author: Jos Backus
* Status: Investigating
* Priority: High
* Assignee: 
* Category: ruby19
* Target version: 
* Affected Puppet version: 3.3.1
* Keywords: utf8 encoding package customer
* Branch: 

One of our RPM packages has some UTF-8 characters in its description, leading 
to an exception ("Error: Could not prefetch package provider 'yum': invalid 
byte sequence in US-ASCII")  in rpm.rb, causing no packages to be upgraded as 
the yumhelper.py invocation code raises that error.

Priority=High because it breaks file { ensure => latest; }.


-- 
You have received this notification because you have either subscribed to it, 
or are involved in it.
To change your notification preferences, please click here: 
http://projects.puppetlabs.com/my/account

-- 
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 http://groups.google.com/group/puppet-bugs.
For more options, visit https://groups.google.com/groups/opt_out.

[Puppet - Feature #23373] (In Topic Branch Pending Review) Command line manipulation of puppet.conf

[tickets]

Issue #23373 has been updated by Andrew Parker.

Status changed from Merged - Pending Release to In Topic Branch Pending Review
Branch changed from https://github.com/puppetlabs/puppet/pull/2138 to 
https://github.com/puppetlabs/puppet/pull/2158

The next stage of the work that allows selecting specific sections of the 
configuration file is up. This also changes `puppet config print` to be able to 
handle the sections, too. We should do some testing to make sure that the 
settings that might happen because of hooks also work correctly... there might 
be a gap in what I did around that.


Feature #23373: Command line manipulation of puppet.conf
https://projects.puppetlabs.com/issues/23373#change-101383

* Author: Andrew Parker
* Status: In Topic Branch Pending Review
* Priority: Normal
* Assignee: Andrew Parker
* Category: 
* Target version: 3.5.0
* Affected Puppet version: 
* Keywords: 
* Branch: https://github.com/puppetlabs/puppet/pull/2158

In order to more easily support setting up new agents, it would be useful to 
have a simple command which could be used to configure the agent.
Something like `puppet config set server=puppet.example.com` would work great. 
The big open question with it is how to support sections in the presence of run 
modes. The simplest seems to be to just ignore run modes (since they don't have 
a bidirectional mapping with sections) and provide an explicit `--section` flag 
(probably with a default of `main`).
The end goal is to be able to easily build an agent install script which looks 
something like this:


yum install -y puppet
puppet config set certname=$(hostname -f)
puppet config set server=puppet.example.com
puppet config set environment=test
puppet resource service puppet ensure=running enable=true



-- 
You have received this notification because you have either subscribed to it, 
or are involved in it.
To change your notification preferences, please click here: 
http://projects.puppetlabs.com/my/account

-- 
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 http://groups.google.com/group/puppet-bugs.
For more options, visit https://groups.google.com/groups/opt_out.

[Puppet - Bug #20122] function_create_resources drops docstring

[tickets]

Issue #20122 has been updated by Henrik Lindberg.


fix included in Puppet 3.5 - see #7659


Bug #20122: function_create_resources drops docstring
https://projects.puppetlabs.com/issues/20122#change-101382

* Author: Sebastian Schmidt
* Status: Duplicate
* Priority: Normal
* Assignee: 
* Category: documentation
* Target version: 
* Affected Puppet version: 3.1.1
* Keywords: puppetdoc
* Branch: 

Hi,

I've noticed puppet doc doesn't output anything at all when the manifest is 
using ensure_resource from stdlib. I could track it down to be a parser issue.

Using this script:
require 'puppet'
Puppet[:manifestdir] = '/etc/puppet/manifests'
p = Puppet::Parser::Parser.new(Puppet::Node::Environment.new)
p.file = ARGV[0]
ret = p.parse
puts ret.to_yaml

I've dumped the ASTs of two manifests, one using function_create_resource via 
stdlib's ensure_resource and one using a plain resource:

$ cat 1.pp; echo "="; ruby dump_ast.rb 1.pp|grep doc: 
# documentation for class foo
class foo {
ensure_resource('package', 'foo', {
ensure => present,
})
}
=
!ruby/sym doc: ""
  doc: ""


$ cat 2.pp; echo "="; ruby dump_ast.rb 2.pp|grep doc: 
# documentation for class foo
class foo {
package{'foo':
ensure => present,
}
}
=
!ruby/sym doc: "documentation for class foo\n"
  doc: ""


As other functions, like join() or prefix() from stdlib don't trigger this 
issue I suspect it has to do with create_resources.

I can reproduce this with 2.7.19 and 3.1.1.

Sebastian


-- 
You have received this notification because you have either subscribed to it, 
or are involved in it.
To change your notification preferences, please click here: 
http://projects.puppetlabs.com/my/account

-- 
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 http://groups.google.com/group/puppet-bugs.
For more options, visit https://groups.google.com/groups/opt_out.

[Puppet - Bug #15735] Deprecate 'puppet kick' run mode

[tickets]

Issue #15735 has been updated by Aleksey Zhukov.


Did I get it right, that the problem is not with `kick` but with `listener` 
part, and the problem is having a network server in a privileged process and 
exposing a whole `Puppet::Network::HTTP::WEBrickREST` just to serve the `run` 
indirection? Insecure, has some overhead but doesn't look like a terrible hack 
to me. Or there are other issues with that?

As for MCollective - it has much worse overhead, mostly cognitive one - you 
have to grok it and deploy. A tiny DYI server that'd send HUP on authenticated 
request or maybe even a xinetd or, possibly, knockd could replace `kick`, 
without a hassle of having MCollective deployment just to trigger Puppet agents.


Bug #15735: Deprecate 'puppet kick' run mode
https://projects.puppetlabs.com/issues/15735#change-101375

* Author: eric sorenson
* Status: Re-opened
* Priority: High
* Assignee: eric sorenson
* Category: agent
* Target version: 3.x
* Affected Puppet version: 
* Keywords: telly_deprecation
* Branch: https://github.com/puppetlabs/puppet/pull/1129

People interested in `puppet kick` functionality should set up mcollective. 
Supporting it causes problems like #10418. Let's consider removing it for Telly.


-- 
You have received this notification because you have either subscribed to it, 
or are involved in it.
To change your notification preferences, please click here: 
http://projects.puppetlabs.com/my/account

-- 
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 http://groups.google.com/group/puppet-bugs.
For more options, visit https://groups.google.com/groups/opt_out.

[Puppet - Bug #22582] (Re-opened) Puppet ignores schedules

[tickets]

Issue #22582 has been updated by Jan  Doleschal.

Status changed from Rejected to Re-opened

Hi, 

can we re-open the Bug? It occured suddenly again, but now it looks like the 
schedule ignores the metaparameters, e.g. period always points to default (1).

Thanks

Jan


Bug #22582: Puppet ignores schedules
https://projects.puppetlabs.com/issues/22582#change-101373

* Author: Jan  Doleschal
* Status: Re-opened
* Priority: Normal
* Assignee: 
* Category: 
* Target version: 
* Affected Puppet version: 
* Keywords: 
* Branch: 

Hello, 

it´s impossible to schedule resources in a define. Everytime the schedules is 
skipped because running on an host, so the resource never gets applied.
We are running puppet 3.2.4, ruby 1.8.7 (2011-12-28 patchlevel 357) 
[x86_64-linux] on SLES11SP2.

Attached site.pp, module and debug log.

Thanks!


-- 
You have received this notification because you have either subscribed to it, 
or are involved in it.
To change your notification preferences, please click here: 
http://projects.puppetlabs.com/my/account

-- 
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 http://groups.google.com/group/puppet-bugs.
For more options, visit https://groups.google.com/groups/opt_out.

[Puppet - Bug #12653] schedule metaparameter ignored in defined type

[tickets]

Issue #12653 has been updated by Jan  Doleschal.


Hello, 

the Bug occurs in puppet 3.2.4 too.


Bug #12653: schedule metaparameter ignored in defined type
https://projects.puppetlabs.com/issues/12653#change-101371

* Author: Chip Schweiss
* Status: Needs More Information
* Priority: Normal
* Assignee: 
* Category: metaparameters
* Target version: 
* Affected Puppet version: 2.6.12
* Keywords: define, schedule
* Branch: 

I have defined:

define yumgroup($ensure = "present", $optional = false) {
case $ensure {
present,installed: {
$pkg_types_arg = $optional ? {
true => 
"--setopt=group_package_types=optional,default,mandatory",
default => ""
}
exec { "Installing $name yum group":
command => "yum -y groupinstall $pkg_types_arg $name",
unless => "yum -y groupinstall $pkg_types_arg $name 
--downloadonly",
timeout => 600,
require => Package["yum-plugin-downloadonly"];
}
}
}
}   

and call it with: 


yumgroup {
$centos6_pkg_groups:
ensure => present,
schedule => 'daily',
}


The schedule is ignored and runs every time.  If I add the schedule to the exec 
in the defined method it works as expected. 
 


-- 
You have received this notification because you have either subscribed to it, 
or are involved in it.
To change your notification preferences, please click here: 
http://projects.puppetlabs.com/my/account

-- 
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 http://groups.google.com/group/puppet-bugs.
For more options, visit https://groups.google.com/groups/opt_out.

[Puppet - Bug #23379] puppet agent 3.4.0-rc1 and windows 7 Professional (DE edition) - "Service 'Puppet Agent' (puppet) could not be installed. Verify that you have sufficient privileges to instal sys

[tickets]

Issue #23379 has been updated by Claudiu Vasadi.


Hi,

Here is the latest one I tried on (same as before but with SP1). I do not have 
an ISO because I'm using an original DVD.

Hostname:  WIN7ßDEßPUPPETP
Betriebssystemname:Microsoft Windows 7 Professional

Betriebssystemversion: 6.1.7601 Service Pack 1 Build 760
1
Betriebssystemhersteller:  Microsoft Corporation
Betriebssystemkonfiguration:   Eigenständige Arbeitsstation
Betriebssystem-Buildtyp:   Multiprocessor Free
Registrierter Benutzer:win7ßdeßpuppetp.loca
Registrierte Organisation:
Produkt-ID:00371-177-061-85347
Ursprüngliches Installationsdatum: 12.12.2013, 12:46:00
Systemstartzeit:   13.12.2013, 10:11:45
Systemhersteller:  innotek GmbH
Systemmodell:  VirtualBox
Systemtyp: x64-based PC
Prozessor(en): 1 Prozessor(en) installiert.
   [01]: Intel64 Family 6 Model 58 S
tepping 9 GenuineIntel ~3365 MHz
BIOS-Version:  innotek GmbH VirtualBox, 01.12.20
06
Windows-Verzeichnis:   C:\Windows
System-Verzeichnis:C:\Windows\system32
Startgerät:\Device\HarddiskVolume1
Systemgebietsschema:   de;Deutsch (Deutschland)
Eingabegebietsschema:  de;Deutsch (Deutschland)
Zeitzone:  (UTC+01:00) Amsterdam, Berlin, Be
rn, Rom, Stockholm, Wien
Gesamter physikalischer Speicher:  2.048 MB
Verfügbarer physikalischer Speicher:   1.443 MB
Virtueller Arbeitsspeicher: Maximale Größe:4.095 MB
Virtueller Arbeitsspeicher: Verfügbar: 3.439 MB
Virtueller Arbeitsspeicher: Zurzeit verwendet: 656 MB
Auslagerungsdateipfad(e):  C:\pagefile.sys
Domäne:WORKGROUP
Anmeldeserver: \\WIN7ßDEßPUPPETP
Hotfix(es):2 Hotfix(e) installiert.
   [01]: KB2534111
   [02]: KB976902
Netzwerkkarte(n):  1 Netzwerkadapter installiert.
   [01]: Intel(R) PRO/1000 MT-Deskto
padapter
 Verbindungsname: LAN-Verbin
dung
 DHCP aktiviert:  Ja
 DHCP-Server: 192.168.70
.254
 IP-Adresse(n)
 [01]: 192.168.70.115
 [02]: fe80::358d:8e82:c3a6:
476e

Everything I run, is done from the Administrator account. All "cmd" instances 
were started with "Open as Administrator".


Bug #23379: puppet agent 3.4.0-rc1 and windows 7 Professional (DE edition) - 
"Service 'Puppet Agent' (puppet) could not be installed. Verify that you have 
sufficient privileges to instal system services.
https://projects.puppetlabs.com/issues/23379#change-101370

* Author: Claudiu Vasadi
* Status: Needs More Information
* Priority: Normal
* Assignee: 
* Category: windows
* Target version: 
* Affected Puppet version: 
* Keywords: windows
* Branch: 

All operations were carried out under the Administrator account. Puppet 3.3.2 
was already installed and running. Reboot did not help and neither did removing 
puppet agent 3.3.2 before installing 3.4.0-rc1.

Windows is a fresh install (no other applications installed) and has no SP.


-- 
You have received this notification because you have either subscribed to it, 
or are involved in it.
To change your notification preferences, please click here: 
http://projects.puppetlabs.com/my/account

-- 
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 http://groups.google.com/group/puppet-bugs.
For more options, visit https://groups.google.com/groups/opt_out.

[Puppet - Bug #23403] (Merged - Pending Release) Error: Could not intialize global default settings: undefined method `mode=' for #

[tickets]

Issue #23403 has been updated by Josh Cooper.

Status changed from In Topic Branch Pending Review to Merged - Pending Release
Target version set to 3.4.0

Merged in [d3ed8c0](https://github.com/puppetlabs/puppet/commit/d3ed8c0) to be 
released in 3.4.0


Bug #23403: Error: Could not intialize global default settings: undefined 
method `mode=' for #
https://projects.puppetlabs.com/issues/23403#change-101366

* Author: Dominic Cleal
* Status: Merged - Pending Release
* Priority: Normal
* Assignee: 
* Category: settings
* Target version: 3.4.0
* Affected Puppet version: 3.4.0-rc2
* Keywords: 
* Branch: https://github.com/puppetlabs/puppet/pull/2150

Follow-on from #23349... regression from 3.3.x to 3.4.0-rc2.  This affects all 
Foreman users, since it's the default installer configuration 
(https://github.com/theforeman/puppet-puppet/blob/master/templates/puppet.conf.erb#L21).

With this in puppet.conf:

[main]
autosign   = $confdir/autosign.conf { mode = 664 }



# puppet --version
Error: Could not intialize global default settings: undefined method `mode=' 
for #
# rpm -q puppet
puppet-3.4.0-0.1rc2.el6.noarch


Sorry for not including the full puppet.conf entry in the earlier bug report, 
we could have avoided a round trip.


-- 
You have received this notification because you have either subscribed to it, 
or are involved in it.
To change your notification preferences, please click here: 
http://projects.puppetlabs.com/my/account

-- 
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 http://groups.google.com/group/puppet-bugs.
For more options, visit https://groups.google.com/groups/opt_out.

[Puppet - Bug #7659] (Merged - Pending Release) puppet doc fails if class contains hash

[tickets]

Issue #7659 has been updated by Josh Cooper.

Status changed from In Topic Branch Pending Review to Merged - Pending Release

Merged into master in commit 
[44f098d](https://github.com/puppetlabs/puppet/commit/44f098d) to be released 
in 3.5.0


Bug #7659: puppet doc fails if class contains hash
https://projects.puppetlabs.com/issues/7659#change-101353

* Author: Joe Crobak
* Status: Merged - Pending Release
* Priority: Normal
* Assignee: 
* Category: 
* Target version: 3.5.0
* Affected Puppet version: 2.6.8
* Keywords: puppetdoc
* Branch: https://github.com/puppetlabs/puppet/pull/2056

here's my test case:

$ cat doc_test.pp 
# Class: doc_test
# 
# Testing docs for a class with a hash
class doc_test {
  $foo = { "bar" => "baz"}
}
$ puppet doc --verbose --all doc_test.pp 
info: scanning: ["doc_test.pp"]
$ cat doc_test2.pp 
# Class: doc_test2
# 
# Testing docs for a class without a hash
class doc_test {
  $foo = "bar"
}
$ puppet doc --verbose --all doc_test2.pp 
info: scanning: ["doc_test2.pp"]
Class: doc_test2
Testing docs for a class without a hash

This might be related to #2364.


-- 
You have received this notification because you have either subscribed to it, 
or are involved in it.
To change your notification preferences, please click here: 
http://projects.puppetlabs.com/my/account

-- 
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 http://groups.google.com/group/puppet-bugs.
For more options, visit https://groups.google.com/groups/opt_out.

[Puppet - Bug #23141] OpenBSD mount(8) does not support 'remounts'; adjust mount{} type accordingly

[tickets]

Issue #23141 has been updated by Kylo Ginsberg.

Target version changed from 3.4.0 to 3.5.0

Oops forgot to update the target version.  This will come out in 3.5.0.


Bug #23141: OpenBSD mount(8) does not support 'remounts'; adjust mount{} type 
accordingly
https://projects.puppetlabs.com/issues/23141#change-101351

* Author: Jasper Lievisse Adriaanse
* Status: Merged - Pending Release
* Priority: Normal
* Assignee: Kylo Ginsberg
* Category: mount
* Target version: 3.5.0
* Affected Puppet version: 
* Keywords: 
* Branch: https://github.com/puppetlabs/puppet/pull/2140

As per subject, this adds OpenBSD to the exclusion list for the remounts 
parameter.


-- 
You have received this notification because you have either subscribed to it, 
or are involved in it.
To change your notification preferences, please click here: 
http://projects.puppetlabs.com/my/account

-- 
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 http://groups.google.com/group/puppet-bugs.
For more options, visit https://groups.google.com/groups/opt_out.

[Puppet - Bug #23414] (Unreviewed) puppet module install - strange behaviour using target-dir

[tickets]

Issue #23414 has been reported by Adrián López.


Bug #23414: puppet module install - strange behaviour using target-dir
https://projects.puppetlabs.com/issues/23414

* Author: Adrián López
* Status: Unreviewed
* Priority: Low
* Assignee: 
* Category: module tool
* Target version: 
* Affected Puppet version: 3.3.2
* Keywords: puppet module install --target-dir
* Branch: 

Using puppet as normal user, if I do
puppet module install puppetlabs/apt
It gets installed in ~/.puppet/modules/apt

But if try to download that module to a different dir
~/test/modules$ puppet module install puppetlabs/apt --target-dir .
Error: Could not install module 'puppetlabs-apt' (best)
  Module 'puppetlabs-apt' (v1.4.0) is already installed
Use `puppet module upgrade` to install a different version
Use `puppet module install --force` to re-install only this module

I expect that I could install the module several times if the target dir is 
different.

In fact, if the order is reversed:
~/test/modules$ puppet module install pdxcat/collectd --target-dir .
And then
~/test/modules$ puppet module install pdxcat/collectd
It works correctly



-- 
You have received this notification because you have either subscribed to it, 
or are involved in it.
To change your notification preferences, please click here: 
http://projects.puppetlabs.com/my/account

-- 
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 http://groups.google.com/group/puppet-bugs.
For more options, visit https://groups.google.com/groups/opt_out.