Re: [Puppet Users] Re: Puppet Dashboard Radiator view thru iframe
Got an answer directly as google showed this/my message as deleted. Firefox extension to show websites in a grid was the solution. Or stagger two Firefox browsers lol High tech! :) Brett Sent from my iPhone > On Feb 26, 2014, at 14:19, Brett Swift wrote: > > did you ever solve this? I just tried the same setup - no luck. > > >> On Monday, 14 October 2013 12:20:26 UTC-6, Matt Shields wrote: >> Is it possible to create an iframe in an html page and display the Radiator >> view in the Puppet Dashboard? For some reason all my other NOC iframe's are >> displaying with the exception of the Radiator view >> >> Matt > > -- > You received this message because you are subscribed to a topic in the Google > Groups "Puppet Users" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/puppet-users/Jw0-kwZD0WI/unsubscribe. > To unsubscribe from this group and all its topics, send an email to > puppet-users+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/puppet-users/bcb5c97d-56f8-4847-82ab-8cc033b3b8a7%40googlegroups.com. > For more options, visit https://groups.google.com/groups/opt_out. -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/683CC73E-6C07-4D43-93C6-5B6388CB5A67%40gmail.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [Puppet Users] beaker ec2 example, should this work?
I was just testing the host config file from puppetdb coupled with the documentation on the beaker documentation. I was actually going to omit the error message. That's actually all of it except for the json output of the compiled beaker configs. I can send the full output in the morning. It looks like the Google Compute Engine docs are more complete... It doesn't matter where it runs. Mostly looking for a free tier cloud to get started with. I'm not sure aws micro would even be big enough anyways. But it'd be cool to get it working. Thanks Brett Sent from my iPhone On Oct 6, 2014, at 19:13, Ken Barber wrote: >>> I've seen how the puppetdb module uses ec2 to execute beaker tests. I've >>> tried setting this up as well and am getting some errors. >>> >>> Is there a working example of using the different hypervisors? >>> >>> I see this: >>> https://github.com/puppetlabs/beaker/wiki/Creating-A-Test-Environment#ec2-support >>> but the documentation doesn't suggest it's a polished feature :) >>> >>> It might be helpful to document a project that has an example of all the >>> hypervisors, as each one will have different required / optional parameters >>> in the nodeset configuration file. >>> >>> Indented below is the error when running `beaker --hosts >>> spec/acceptance/nodesets/ec2-west-el6-64mda-el6-64a.cfg` - I pulled that >>> example from the puppetdb project, and as per the documentation have a .fog >>> file set up.. I was hoping to get an authentication or configuration error >>> on first run. >>> >>> Beaker::Hypervisor, found some ec2 boxes to create >>> Failed: errored in CLI.provision >>> # >>> /Projects/live_modules/puppet-shawlib/.bundle/ruby/2.1.0/gems/beaker-1.19.1/bin/beaker:6 >>> /Users/bswift/.rvm/gems/ruby-2.1.2/bin/ruby_executable_hooks:15 >>> /Users/bswift/.rvm/gems/ruby-2.1.2/bin/ruby_executable_hooks:15 >>> >>> >>> I don't have much to go on there.. >> >> The exception seems a little truncated, is that it? BTW Instead of >> annotating what has happened in a paragraph, just provide the full >> example in your shell in a gist or something, it says the message much >> more simply :-). Sort of like this: >> https://gist.github.com/kbarber/97f45eba0f922497901a. Or better yet, >> if you can create a repository with the basics of the above so I can >> take a look that would be much much easier. >> >> I must warn you, the aws_sdk.rb code was written in a massive hurry, >> and thus has very little error protection so if everything isn't spot >> on, it might break. > > FWIW also - I wouldn't test the state of the puppetdb module testing > pieces, we've been waiting for our QA & Module teams to automate those > tests for a about a year now :-(. But honestly, they haven't been ran > for quite some time - so I'd be dubious. > > The PuppetDB source code itself (ie. puppetdb server, not the module) > however does use the AWS EC2 test stuff, and thats a better example to > use. > > ken. > > -- > You received this message because you are subscribed to a topic in the Google > Groups "Puppet Users" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/puppet-users/AzcyYneW820/unsubscribe. > To unsubscribe from this group and all its topics, send an email to > puppet-users+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/puppet-users/CAE4bNT%3DgHWf5zD3j8GD8%2BYXsf5HCwYPvSXcH2Veka2O2_b5w_w%40mail.gmail.com. > For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/7D366F34-582B-4B85-9276-04DA77A7A7E4%40gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: [Puppet Users] beaker ec2 example, should this work?
Hmmm. I'm pretty sure the puppelabs_spec_helper gave me a beaker target Brett Sent from my iPhone On Oct 7, 2014, at 15:15, Ken Barber wrote: >> Nice. I'll look out for your packer project. I've been using it to build >> our vagrant boxes, but haven't yet built any for vSphere or external cloud. > > Its not my project, its a private project we have. So I can't speak > around if we'll release it or not - just to be clear :-). > >> I'm getting this error: >> ruby/2.1.0/gems/aws-sdk-1.42.0/lib/aws/core/resource.rb:238:in `rescue in >> block in define_attribute_getter': unable to find the image >> (AWS::Core::Resource::NotFound) >> >> Are your AMI's public? >> Gist: >> https://gist.github.com/brettswift/176b802bfe31dae369e9 > > I would presume not? Honestly, I would look into creating your own > most probably. Not because they don't work, just that you could > probably do a better quality job and then own the process yourself. > Start with a good basis, like the endorsed Centos AMI's for example: > > http://wiki.centos.org/Cloud/AWS > > Then apply the necessary customisations on top with packer using the > amazon-ebs builder as a good 'entry level' way of doing it: > http://www.packer.io/docs/builders/amazon-ebs.html > >> Using your sample project, if I include the puppetlabs_spec_helper in the >> Gemfile, it doesn't error but completes rather quickly saying there are no >> tests (obviously). But it doesn't bawk on any ec2 configuration. > > So puppetlabs_spec_helper assists with the unit testing side of things > and has nothing directly to do with beaker, so look into rspec-puppet > for the long story around that. puppetlabs_spec_helper provides a > number of utilities and helps bridge the testing parts with various > different versions of puppet basically, but the main piece of work > that users should focus on is rspec-puppet. > > Basically from a user perspective the helper gives you a rake task: > `rake spec` and a file like so: > https://github.com/puppetlabs/puppetlabs-puppetdb/blob/master/.fixtures.yml > that will help you automatically retrieve the other modules your > module depends on during testing time. As opposed to just running > `rspec spec/unit` for example. So yeah, chalk and cheese ... > > ken. > > -- > You received this message because you are subscribed to a topic in the Google > Groups "Puppet Users" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/puppet-users/AzcyYneW820/unsubscribe. > To unsubscribe from this group and all its topics, send an email to > puppet-users+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/puppet-users/CAE4bNTnCuq80Zj%2ByuzNQcqUErz7viufhhdPHsHpyicQkNkKqTg%40mail.gmail.com. > For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/D4E401BC-37FB-4DCC-8682-EF76FD68C300%40gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: [Puppet Users] beaker ec2 example, should this work?
The default.yaml is in the gist I supplied. I used the el6 and centos6 64 from your sample project. An Ami search on aws by the name or Ami ID didn't turn up any results which is why I thought they were private. I'll try building an Ami with packer.Are there any conventions that need to go into the VM required by beaker? Brett Sent from my iPhone On Oct 7, 2014, at 16:25, Ken Barber wrote: Using your sample project, if I include the puppetlabs_spec_helper in the Gemfile, it doesn't error but completes rather quickly saying there are no tests (obviously). But it doesn't bawk on any ec2 configuration. >>> >>> So puppetlabs_spec_helper assists with the unit testing side of things >>> and has nothing directly to do with beaker, so look into rspec-puppet >>> for the long story around that. puppetlabs_spec_helper provides a >>> number of utilities and helps bridge the testing parts with various >>> different versions of puppet basically, but the main piece of work >>> that users should focus on is rspec-puppet. >>> >>> Basically from a user perspective the helper gives you a rake task: >>> `rake spec` and a file like so: >>> https://github.com/puppetlabs/puppetlabs-puppetdb/blob/master/.fixtures.yml >>> that will help you automatically retrieve the other modules your >>> module depends on during testing time. As opposed to just running >>> `rspec spec/unit` for example. So yeah, chalk and cheese ... >> >> Hmmm. I'm pretty sure the puppelabs_spec_helper gave me a beaker target > > Yep you are right, it was added in January by blkperl. I didn't realize this. > > So in response to your original question: > Using your sample project, if I include the puppetlabs_spec_helper in the Gemfile, it doesn't error but completes rather quickly saying there are no tests (obviously). But it doesn't bawk on any ec2 configuration. > > Perhaps its because its using the `default.yml` definition that it is > not complaining. Perhaps that AMI is public and fine. Check > `spec/acceptance/nodesets/default.yml` in your project for what this > contains. > > All the rake task seems to do is run beaker with --color and the > spec/acceptance directory as a path, so beakers defaults everywhere > else kick in. Which makes sense, in this case there are several > BEAKER_* style variables that are used to setup the details in CI for > example. This is because CI software such as Jenkins uses environment > variables as a primary API between the Jenkins job data and the jobs > scripts being executed. > > https://github.com/puppetlabs/beaker/wiki/How-to-Write-a-Beaker-Test-for-a-Module > > The BEAKER_set allows for a basic way of executing a particular > nodeset for example, which is rather nice. Perfect for a matrix job in > Jenkins to iterate across your distros. > > ken. > > -- > You received this message because you are subscribed to a topic in the Google > Groups "Puppet Users" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/puppet-users/AzcyYneW820/unsubscribe. > To unsubscribe from this group and all its topics, send an email to > puppet-users+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/puppet-users/CAE4bNT%3DPeu-CEU50yFTgoyWhywHAPbqz6tbD_PVTKznv-FDPqw%40mail.gmail.com. > For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/B5314982-8BA2-4583-9CE0-E838CD0B8679%40gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: [Puppet Users] Re: hiera - multiple backends - failure to lookup value in only one backend.
Just figured this out this morning. It was the $::role. It's a variable
declared in site.pp inside a node block. ( poor man's role classification)
$role seems to have fixed things
Hopefully this release is smooth now!
Thanks
Brett
Sent from my iPhone
> On Mar 19, 2015, at 07:30, jcbollinger wrote:
>
>
>
>> On Wednesday, March 18, 2015 at 4:40:38 PM UTC-5, Brett Swift wrote:
>> I've found the time to deliver a multiple hiera backend for our ops guys,
>> and I'm seeing some weird behaviour.
>>
>> With a single backend, it works great - add host level configs in the host
>> hierarchy, and common stuff in what we had a 'role' hierarchy.
>>
>> I have since split the backends, so there is one .git repo (we call it
>> hostdata) holding the 'hosts' tier, and the main hieradata repo holding
>> other tiers. (For us this made sense as our Ops guys almost never modify
>> anything other than at the host level).
>
>
> In the split, did you change any hierarchy levels or data in any way, other
> than moving some of the data files to the appropriate location for a
> different backend?
>
>
>>
>> The Problem: What I'm seeing, is sometimes hiera doesn't find what it should
>> be finding, and I am trying to figure out some odd behaviour. I'll try to
>> demonstrate this below:
>>
>> I use eyaml without a key, in order to get two yaml backends. Hacky, but
>> it should work...
>>
>> ---
>> :backends:
>> - eyaml
>> - yaml
>>
>> :hierarchy:
>> - "host/%{::hostname_lower}"
>> - "cluster/%{::cluster}/%{role}"
>> - "roles/%{role}"
>> - "project/%{::project}"
>> - "subnet/%{::subnet}"
>> - common
>> - users
>>
>> :yaml:
>>:datadir: /etc/puppetlabs/puppet/environments/%{::environment}/hieradata
>>
>>
>> :eyaml:
>>:datadir: /etc/puppetlabs/puppet/hostdata/master
>>:extension: yaml
>
>
> Have you verified that all those Puppet variables you're interpolating have
> the right values at the time and place of the affected lookups?
>
>
>> hostdata as it's host specific doesn't use environments. It's just a single
>> branch. You'll see the folders here:
>>
>> [bswift@devcorepptl900 puppet]$ ls -gG
>> /etc/puppetlabs/puppet/environments/the900/hieradata
>>
>> drwxrwxr-x 4 4096 Mar 17 10:14 cluster
>> -rw-rw-r-- 1 3286 Mar 18 07:31 common.yaml
>> drwxrwxr-x 2 4096 Mar 17 10:14 project
>> drwxrwxr-x 2 4096 Mar 18 07:31 roles
>> drwxrwxr-x 2 4096 Mar 17 10:14 subnet
>> -rw-rw-r-- 1 5238 Mar 17 10:14 users.yaml
>>
>> [bswift@devcorepptl900 puppet]$ ls -gG /etc/puppetlabs/puppet/hostdata/master
>>
>> drwxrwxr-x 2 12288 Mar 18 07:30 host
>>
>>
>> puppet.conf snippet:
>> environment = the900
>>
>>
>>
>> The strange behaviour I've been noticing is that if a param is set in hiera
>> in the first backend, it finds it. If it's in the second one, it
>> doesn't... but only sometimes.
>>
>> One param it won't find if it's in the second backend. But if I put it in
>> the host level backend it finds it..but then this causes other params to
>> fail their lookups.
>>
>> I see this by running puppet master --compile and looking at the hiera
>> lookups, as well by notify's in my module manifests.
>
>
> It would be worthwhile to test whether this is really associated with the
> order of the backends, or whether it is tied directly to the backends
> themselves. So for instance, if you deconfigure the eyaml backend, leaving
> only the yaml, then do you still get unexpected lookup failures for keys that
> the yaml backend should be able to provide data for? Also, if you swap the
> order of yaml and eyaml, do the problems stick to the yaml backend? Do they
> move to the eyaml backend? Does anything change if you keep the backend
> order, but swap which data are served by which backend?
>
> Also, do your results depend on the type of lookup you are performing? Your
> example seems to be describing a problem with automated data binding, which
> would be a priority lookup (like calling the plain hiera() function). Where
> you see contradictory results, are they associated with array-merge and/or
> hash-merge lookups?
>
>
>>
>> Specifically my module has a `puppet::puppet_type` which is master or agent.
>>
>> my environment is set to 'the900' and hiera.yaml eyaml datadir is directed
>> to hostdata/the900 as well. (not master for this one - off test).
>>
>> [bswift@devcorepptl900 puppet]$ cat
>> environments/the900/hieradata/roles/puppetmaster.yaml
>>
>> puppet::puppet_type: master
>>
>>
>> puppet::puppet_type doesn't resolve.
>>
>> but if I move puppet::puppet_type: to hostdata, the other backend.. in
>> the appropriate host file.. it does resolve.
>>
>> What is going on here?
>
>
> I don't know yet, but I suspect either a problem with your variables
> $::cluster, $::role, etc., an issue associated with data layout (possibly
> file or directory permissions), or possibly unexpected behavior of the eyaml
