On Thursday, 16 April 2015 14:01:29 UTC+2, henrik lindberg wrote:
>
> On 2015-16-04 4:30, Bostjan Skufca wrote:
> > Just recently I was looking at the environments part of puppet
> > implementation, and I have stumbled upon this curious gimmick.
> >
> > There
, Bostjan Skufca wrote:
>
> I've just benchmarked catalog compilation, with and without caching
> results in Puppet::Environments::get_conf() function.
>
> Without cache: 19 seconds (to compile catalog of 1633 resources)
> With cache: 9 seconds.
>
> Again I wond
I've just benchmarked catalog compilation, with and without caching results
in Puppet::Environments::get_conf() function.
Without cache: 19 seconds (to compile catalog of 1633 resources)
With cache: 9 seconds.
Again I wonder: why are results of Puppet::Environments::get_conf() not
cached?
Tha
Just recently I was looking at the environments part of puppet
implementation, and I have stumbled upon this curious gimmick.
There is Puppet::Environments class, which is a class for general
Environments management (searching, loaders, caching, etc).
Then there is Puppet::Node::Environment whic
On Saturday, 21 March 2015 21:57:02 UTC+1, Trevor Vaughan wrote:
>
> In my opinion, this is one of the areas where Puppet shines and it is
> something that needs to be actively supported.
>
> Let the systems be safe by default and easy to use but don't stifle the
> power users lest they be alie
On Saturday, 21 March 2015 20:02:23 UTC+1, Felix Frank wrote:
>
> On 03/19/2015 12:19 PM, Bostjan Skufca wrote:
> >
> > I think my note about suggesting git's way of providing "plumbing and
> > porcelain" interfaces as good approach still stands.
On Friday, 20 March 2015 20:54:40 UTC+1, John Bollinger wrote:
>
>
>
> On Thursday, March 19, 2015 at 6:19:19 PM UTC-5, Bostjan Skufca wrote:
>
> [...] This is the reason why I came up with the EEL idea. The more I think
>> about it, the more natural it seems for pup
On Thursday, 19 March 2015 20:30:08 UTC+1, John Bollinger wrote:
>
> Why? You have two separate masters managing disjoint aspects of the
> target machines, via disjoint sets of agents. Why do they need (or even
> want) to share *anything*?
> Right. So what is the advantage in them sharing an
On Thursday, 19 March 2015 01:51:17 UTC+1, Felix Frank wrote:
>
> On 03/19/2015 01:08 AM, Bostjan Skufca wrote:
>
> - both agents request the same environment: one master returns the whole
> system catalog, the other just bits to manage primary puppet
>
>
> I don&#x
, as environment prefix "dept2_" would
be invalid in .../env/dept1/ directory.
> On Friday, 13 March 2015 16:52:13 UTC+1, Bostjan Skufca wrote:
>>
>> For such an occasion I like to say that, yes, doing "rm -rf /" is bad,
>> but as a sysadmin I still wan
On Monday, 16 March 2015 14:55:23 UTC+1, John Bollinger wrote:
>
>
>
> On Thursday, March 12, 2015 at 5:33:35 PM UTC-5, Bostjan Skufca wrote:
>>
>>
>>
>> On Thursday, 12 March 2015 20:30:23 UTC+1, John Bollinger wrote:
>>>
>>>
>>>
On Thursday, 12 March 2015 23:31:58 UTC+1, Felix Frank wrote:
>
> On 03/11/2015 05:56 PM, Bostjan Skufca wrote:
> >
> > I would like to hear your opinion about this, and whether this would
> > be useful for you.
> >
>
> Hi,
>
> I don't b
On Thursday, 12 March 2015 23:58:03 UTC+1, Aaron Stone wrote:
>
> Neat idea. I would consider using this for automatic git-checkout of
> project branches, rather than preemptively checking out all branches by
> cron or git-hook.
>
I haven't thought about this before, but now it seems very feasi
On Thursday, 12 March 2015 20:30:23 UTC+1, John Bollinger wrote:
>
>
>
> On Wednesday, March 11, 2015 at 11:56:44 AM UTC-5, Bostjan Skufca wrote:
>>
>> Hi all,
>>
>> I would like to propose a new feature for puppet master: External
>> Environment Locat
Hi all,
I would like to propose a new feature for puppet master: External
Environment Locator (EEL)
The main objective would be to make locating puppet environment locations
more flexible compared to directory environments. Basic functionality would
facilitate usage of external program to conv
On Wednesday, 11 March 2015 03:41:45 UTC+1, Bostjan Skufca wrote:
>
> EEL - External Environment Locator
>
> Proposed new master setting:
> environment_terminus = /path/to/external/environment/locator.sh
>
I was too fast for my own good.
This is what I intended to actually w
I do not want to assume anything about how others use tools that are given to
them. What I do know is that I like tools that provide flexibility and can be
adapted to my needs. This particular case here is something that feels quite
natural, especially if you consider how much code needs to be c
On Monday, 9 March 2015 17:33:27 UTC+1, Joshua Partlow wrote:
>
> On Mon, Mar 9, 2015 at 9:05 AM, Henrik Lindberg > wrote:
>
>> On 2015-09-03 14:54, Felix Frank wrote:
>>
>>> On 03/09/2015 02:16 PM, Henrik Lindberg wrote:
>>>
It would be splendid if we could define modulepath paths with
>
On Monday, 9 March 2015 17:05:22 UTC+1, henrik lindberg wrote:
>
> On 2015-09-03 14:54, Felix Frank wrote:
> > I also fail to see the value in that. Do you mean to allow an
> > environment to extend itself to a whole different file system tree?
> > Wouldn't that just be horrible for organizing
On Monday, 9 March 2015 14:54:14 UTC+1, Felix Frank wrote:
>
> On 03/09/2015 02:16 PM, Henrik Lindberg wrote:
> >> It would be splendid if we could define modulepath paths with
> >> $environment as variable part of path, like this:
> >> modulepath = /path/to/$environment/modules
> >> manifest =
t enabled for these settings, some
design-based reason?
Tnx,
b.
On Sunday, 8 March 2015 20:27:31 UTC+1, Bostjan Skufca wrote:
>
> Hi all,
>
> this change I have not yet implemented, but I believe it might be nice to
> have.
>
> Currently in environment.conf we can specify mo
Hi all,
this change I have not yet implemented, but I believe it might be nice to
have.
Currently in environment.conf we can specify modulepath with relative or
absolute paths to module directories, like this:
modulepath = modules/:/some/other/location/env_name/
manifest = /path/to/env_name/man
Hi there,
I like to have my environments organized into multiple subdirectories.
Puppet configuration supports that by defining multiple paths for
environmentpath setting, separated by ':'.
However, I find it very convenient to use this simple configuration line:
environmentpath = /etc/puppet/e
Yes, it works without static_compiler setting.
On Tuesday, 23 October 2012 22:37:07 UTC+2, Andy Parker wrote:
>
> And this exact setup works if you don't use the static_compiler?
>
> On Mon, Oct 22, 2012 at 5:23 PM, Bostjan Skufca
> > wrote:
> > Also, puppet
Also, puppetmaster.conf was configured as before, and site.pp included
filebucket as described previously.
b.
On Tuesday, 23 October 2012 01:58:30 UTC+2, Luke Kanies wrote:
>
> On Oct 22, 2012, at 4:49 PM, Andy Parker >
> wrote:
>
> > On Mon, Oct 22, 2012 at 4:
source(s)
modules/itsis-test/a at
/etc/puppet/itsis_dev/modules/itsis/itsis-test/manifests/init.pp:4
info: //client.example.org/Puppet: Retrieving plugin
err: //client.example.org/Puppet: Could not retrieve catalog from remote
server: Error 400 on SERVER: Could not retrieve information from
environment production source(s)
se I might need to add somewhere? Do I need to
configure fileserver.conf? Currently normal puppet runs work without it
being present on the master.
b.
On Tuesday, 23 October 2012 00:38:48 UTC+2, Bostjan Skufca wrote:
>
> Hi all,
>
> the post below was originally intended for this l
Hi all,
the post below was originally intended for this list, but was unfortunately
misdirected to puppet-users. As some debate has already begun around it, I
will not duplicate its content here, so please see for yourself:
https://groups.google.com/forum/?fromgroups=#!topic/puppet-users/d4F9ESn
Seems reasonable, modified, tested, pushed.
b.
On Jan 20, 5:02 am, Daniel Pittman wrote:
> On Wed, Jan 19, 2011 at 17:28, Bostjan Skufca
>
> wrote:
> > After a brief discussion on puppet-users list I've completed the
> > feature #5936 modification. The patch i
Hi all!
After a brief discussion on puppet-users list I've completed the
feature #5936 modification. The patch is below, feature ticket is
opened and there in the comments there is also github pull url (can't
edit it):
https://github.com/bostjan/puppet/tree/feature/master/5936
-
Ahh, I was looking in the test/ instead of spec/ directory...
Please excuse the quantity of my posts, but I would also like to ask
what actually is expected to be tested?
Thanks,
b.
On Sep 16, 4:01 pm, Steven Jenkins wrote:
> Bostjan Skufca wrote:
> > Can you hint me an URL/book wh
Can you hint me an URL/book where I can learn about RSpec tests? This
is a totally new subject to me.
Thanks,
b.
On Sep 16, 3:30 am, James Turnbull wrote:
> 2009/9/16 Bostjan Skufca :
>
>
>
> > Hi!
>
> > I have created types and providers for managing basi
Hi!
I have created types and providers for managing basic MySQL accounts
(users, databases, grants). I have also found couple of solutions
already made on the net. Which makes me wonder - why are there no
mysql types/providers already included in puppet source package? Are
there some licensing is
t this requires the "user" and "host" parameters to be defined as
namevars. Can this be done? Does it contradict with internal design of
puppet?
This mysql thing is just a demonstrative example, I can find other
uses of this.
b.
On Sep 13, 6:01 am, Luke Kanies wrote:
>
Hi,
Does puppet support combined namevars?
Thanks,
b.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Puppet Developers" group.
To post to this group, send email to puppet-dev@googlegroups.com
To unsubscribe from
35 matches
Mail list logo
