[Puppet-dev] Re: [ann] Action Required: New Puppet Inc. Public Key
What is the plan for releases signed with the old key? I assume they’ll stop working when the old key expires. Is that a valid assumption? If so, will existing packages be resigned with the new key, or will everyone have to upgrade to a release that comes out after Sept 12th before the old key expires? > -- You received this message because you are subscribed to the Google Groups "Puppet Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-dev/8cf99d48-b022-4cf8-9358-4223fb8942e8%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[Puppet-dev] Re: Docker module and new upstream repos
I have a work in progress version of a similar change locally also. Replies inline below: On Sunday, July 26, 2015 at 12:31:24 PM UTC-4, Gareth Rushgrove wrote: > > I'm looking at shipping a 5.0 release of the garethr/docker module to > add support for this, WIP in > https://github.com/garethr/garethr-docker/pull/311 > > And I had a few questions which I reasoned I'd ask here. > > * Previously the module defaulted to upstream docker packages for > Ubuntu, and used distro packages for everything else (because they > didn't exist). I'm proposing to change this, so everything by default > uses the upstream. And to document how you can use your distro of > choices version. Any reason why that's not the best option? > I think some people may not want that because they have internal mirrors (like we do), but it's easy to turn off the use of the public repos. > * The change in repo and the change in package-name mean a certain > level of juggling. Remove the old repo, remove the old package, add > the new, etc. I'm not sure that's best dealt with by the module, I'm > not sure I'd want updating the module to (for instance) remove docker > and every running containers on all hosts. Open to ideas about how > best to signpost this change however. > At least on Ubuntu, docker-engine conflicts with lxc-docker, so installing it automatically removes both the old generic name and the version named package. -- You received this message because you are subscribed to the Google Groups "Puppet Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-dev/c42e7550-20f0-4ec6-9c04-5e1495486299%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[Puppet-dev] Re: Announcing the Puppet Catalog Diff Viewer
On Tuesday, June 2, 2015 at 9:45:49 AM UTC-4, Raphaël Pinson wrote: > > I recently noticed that Zack Smith forked and has been maintaining > R.I.Pienaars' puppet-catalog-diff. This tool can now produce JSON reports, > which contain lots of interesting information, but are not very readable > for normal human beings. > > I've been wanting to use the tool for Puppet environment preflight, and so > I made a web interface to display and analyse those JSON reports. > > The project can be found (and forked) at > https://github.com/camptocamp/puppet-catalog-diff-viewer and a live demo > is available at http://camptocamp.github.io/puppet-catalog-diff-viewer/. > The code is pure Javascript (using Bootstrap and d3js) and doesn't store > any data whatsoever, so feel free to test your own reports on the interface. > > The tool also allows to ack diff information (all data are loss when you > reload the report though) to help filter out the information. > I think this is a fantastic idea. We use catalog diffs extensively as part of our pre-merge testing. Unfortunately, I can't seem to get it to work with the demo web page. What version of the catalog diff tool did you use this with? I tried using the latest (1.5.0), but it appears to be broken. I worked out that problem and should have a PR off later today, but when I load the JSON diff into your demo web page, I just get " Failed to parse report: missing fields" Perhaps the format of the JSON file has changed? -- You received this message because you are subscribed to the Google Groups "Puppet Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-dev/b0cf92b3-fe3d-456b-95df-4ac4341e3651%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[Puppet-dev] Re: Validation Resources
We have something almost exactly the same as this that we use internally. We also have a http_conn_validator that we use for services more like PuppetDB that need to do a HTTP request against a specific URI, or look for a specific HTTP result code. This has been huge for us to be able to automate integration testing for multiple node environments. On Thursday, May 14, 2015 at 3:11:19 PM UTC-4, Spencer Krum wrote: > > Hi Folks, > > There is currently a PR against stdlib that I am writing to you today > about: https://github.com/puppetlabs/puppetlabs-stdlib/pull/444 > Thanks to Spredzy for making this PR. > > This is tracked in jira: > https://tickets.puppetlabs.com/browse/MODULES-1982 > > This pattern has poked up a few different places. As the PR says, it has > shown up in the monogodb module and the puppetdb module. I know that > Michael Chapman added something like this to his OpenStack things and > Dan Bode as well. > > At the modules triage today we had the following reactions (please reply > if there is something you said I didn't get): > > * This is a new pattern > * Having it in stdlib means we can't iterate on it quickly > * This is a library thing, and should be a library > * Once standardized, puppetdb and other modules could be retrofitted to > use it > * This will probably change frequently as people use it and explore what > it should/can do > > We had the idea that rather than landing this in puppet-stdlib, that we > could create a module in puppet-community to hold this and other > validation/health check resources. > > We had some ideas on the name: > > puppet-healthcheck > puppet-validation > puppet-external_validate. > > It's worth noting that these are primitives for building multi-node > orchestration with Puppet. > > What do you think? Do you use these patterns? Would you? What would you > want from your library? > > Thanks, > Spencer > > > -- > Spencer Krum > ni...@spencerkrum.com > -- You received this message because you are subscribed to the Google Groups "Puppet Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-dev/ca69b22f-48d4-4718-b1fc-139a7f57e6ee%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [Puppet-dev] Ruby environment variable handling in Puppet Server
I'm not sure that we have a use case for the server, but as an aside, we do have a use case on the agent side, if that is ever a concern: We use the ability to set environment variables when doing OpenStack upgrades. OpenStack has the concept of public (publicURL) and private (internalURL) endpoints. Normally during our Puppet runs it uses the public endpoints for all API calls and provisioning. However, when we're doing upgrades, we sometimes have the external load balancer disabled so that clients can not make changes to a database we may revert. In this case, we set the OS_ENDPOINT_TYPE environment variable to 'internalURL' in our upgrade scripts. I don't know if this will ever be an issue for the agent, but in this situation a config based option would be significantly less useful. -- You received this message because you are subscribed to the Google Groups "Puppet Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-dev/2c889e90-8514-4c8c-836b-93633a2e904b%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
