Hi Everyone,
I suppose most of us are using foreman not only as statistics center, but
as ENC and full circle management system.
We've been using Foreman for some time now, and are pretty excited
about opportunities it opened for us, but one thing is still not clear:
on puppetclasses page, the information, that we receiving is related only
to classes, assigned via Foreman - no info about classes that appeared on
hosts from includes.
We personally used a simple select script "SELECT host_id FROM resources
WHERE title ='$class' AND restype = 'Class';" and received class from
stored configs that reflect real usage of classes.
Maybe there is an option to make that if in settings using_storeconfigsis set to true, use the select directly from resources table, and not from
the table Foreman uses for provisioning? I think it would be just great,
and would make Foreman even more informative in case if you have more that
1500 classes 
> Hi Everyone,
>
> I suppose most of us are using foreman not only as statistics center, but
> as ENC and full circle management system.
> We've been using Foreman for some time now, and are pretty excited
> about opportunities it opened for us, but one thing is still not clear:
> on puppetclasses page, the information, that we receiving is related
> only to classes, assigned via Foreman - no info about classes that appeared
> on hosts from includes.
> We personally used a simple select script "SELECT host_id FROM resources
> WHERE title ='$class' AND restype = 'Class';" and received class from
> stored configs that reflect real usage of classes.
> Maybe there is an option to make that if in settings using_storeconfigsis set to true, use the select directly from resources table, and not from
> the table Foreman uses for provisioning? I think it would be just great,
> and would make Foreman even more informative in case if you have more that
> 1500 classes
>
if you use storeconfigs, then you should have a button with all puppet
classes under the host show page
Ohad
···
On Mon, Dec 17, 2012 at 3:35 PM, Andrei Burd wrote:
–
You received this message because you are subscribed to the Google Groups
"Foreman users" group.
To view this discussion on the web visit
https://groups.google.com/d/msg/foreman-users/-/GJ3vzf4SonYJ.
To post to this group, send email to foreman-users@googlegroups.com.
To unsubscribe from this group, send email to
foreman-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/foreman-users?hl=en.
Thanks for fast answer,
You right 100%, but you can't check how many hosts you have within a puppet
class, that puppetclasses page gives you.
Thanks again for great product.
···
On Monday, December 17, 2012 4:06:06 PM UTC+2, ohad wrote:
>
>
>
>
> On Mon, Dec 17, 2012 at 3:35 PM, Andrei Burd <burda...@gmail.com > > wrote:
>
>> Hi Everyone,
>>
>> I suppose most of us are using foreman not only as statistics center, but
>> as ENC and full circle management system.
>> We've been using Foreman for some time now, and are pretty excited
>> about opportunities it opened for us, but one thing is still not clear:
>> on *puppetclasses* page, the information, that we receiving is related
>> only to classes, assigned via Foreman - no info about classes that appeared
>> on hosts from includes.
>> We personally used a simple select script *"SELECT host_id FROM
>> resources WHERE title ='$class' AND restype = 'Class';"* and received
>> class from stored configs that reflect real usage of classes.
>> Maybe there is an option to make that if in settings *using_storeconfigs*is set to true, use the select directly from resources table, and not from
>> the table Foreman uses for provisioning? I think it would be just great,
>> and would make Foreman even more informative in case if you have more that
>> 1500 classes ;)
>>
>
> if you use storeconfigs, then you should have a button with all puppet
> classes under the host show page ;)
>
> Ohad
>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Foreman users" group.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msg/foreman-users/-/GJ3vzf4SonYJ.
>> To post to this group, send email to forema...@googlegroups.com
>> .
>> To unsubscribe from this group, send email to
>> foreman-user...@googlegroups.com .
>> For more options, visit this group at
>> http://groups.google.com/group/foreman-users?hl=en.
>>
>
>
> Thanks for fast answer,
> You right 100%, but you can't check how many hosts you have within a
> puppet class, that puppetclasses page gives you.
>
> Oh I see, I guess the problem is that normally puppet does not expose this
information outside of storeconfigs, and since storeconfigs are to
be deprecated, I could only see getting this info from puppet-db ?
we were just talking today about dropping the support for sharing a
database between storeconfigs and foreman, and afaik, this is the only
disadvantage.
maybe it makes sense to have some basic integration with puppet db for this
kind of queries?
Ohad
···
On Mon, Dec 17, 2012 at 4:17 PM, Andrei Burd wrote:
Thanks again for great product.
On Monday, December 17, 2012 4:06:06 PM UTC+2, ohad wrote:
On Mon, Dec 17, 2012 at 3:35 PM, Andrei Burd burda...@gmail.com wrote:
Hi Everyone,
I suppose most of us are using foreman not only as statistics center,
but as ENC and full circle management system.
We’ve been using Foreman for some time now, and are pretty excited
about opportunities it opened for us, but one thing is still not clear:
on puppetclasses page, the information, that we receiving is related
only to classes, assigned via Foreman - no info about classes that appeared
on hosts from includes.
We personally used a simple select script “SELECT host_id FROM
resources WHERE title =’$class’ AND restype = ‘Class’;” and received
class from stored configs that reflect real usage of classes.
Maybe there is an option to make that if in settings *using_storeconfigs
- is set to true, use the select directly from resources table, and not
from the table Foreman uses for provisioning? I think it would be just
great, and would make Foreman even more informative in case if you have
more that 1500 classes
if you use storeconfigs, then you should have a button with all puppet
classes under the host show page
Ohad
–
You received this message because you are subscribed to the Google
Groups “Foreman users” group.
To view this discussion on the web visit https://groups.google.com/d/**
msg/foreman-users/-/GJ3vzf4SonYJhttps://groups.google.com/d/msg/foreman-users/-/GJ3vzf4SonYJ
.
To post to this group, send email to forema...@googlegroups.com.
To unsubscribe from this group, send email to foreman-user…@**
googlegroups.com.
For more options, visit this group at http://groups.google.com/**
group/foreman-users?hl=enhttp://groups.google.com/group/foreman-users?hl=en
.
–
You received this message because you are subscribed to the Google Groups
"Foreman users" group.
To view this discussion on the web visit
https://groups.google.com/d/msg/foreman-users/-/NpHLNV_RmggJ.
To post to this group, send email to foreman-users@googlegroups.com.
To unsubscribe from this group, send email to
foreman-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/foreman-users?hl=en.
Wow, totally forgot about it.
Ok, we are still on the road to big cleanup before switching to Puppet 3
and stop using store configs, but thanks for the point.
Andrei.
···
On Monday, December 17, 2012 4:31:47 PM UTC+2, ohad wrote:
>
>
>
>
> On Mon, Dec 17, 2012 at 4:17 PM, Andrei Burd <burda...@gmail.com > > wrote:
>
>> Thanks for fast answer,
>> You right 100%, but you can't check how many hosts you have within a
>> puppet class, that *puppetclasses* page gives you.
>>
>> Oh I see, I guess the problem is that normally puppet does not expose
> this information outside of storeconfigs, and since storeconfigs are to
> be deprecated, I could only see getting this info from puppet-db ?
>
> we were just talking today about dropping the support for sharing a
> database between storeconfigs and foreman, and afaik, this is the only
> disadvantage.
>
> maybe it makes sense to have some basic integration with puppet db for
> this kind of queries?
>
> Ohad
>
>> Thanks again for great product.
>>
>> On Monday, December 17, 2012 4:06:06 PM UTC+2, ohad wrote:
>>>
>>>
>>>
>>>
>>> On Mon, Dec 17, 2012 at 3:35 PM, Andrei Burd wrote:
>>>
>>>> Hi Everyone,
>>>>
>>>> I suppose most of us are using foreman not only as statistics center,
>>>> but as ENC and full circle management system.
>>>> We've been using Foreman for some time now, and are pretty excited
>>>> about opportunities it opened for us, but one thing is still not clear:
>>>> on *puppetclasses* page, the information, that we receiving is related
>>>> only to classes, assigned via Foreman - no info about classes that appeared
>>>> on hosts from includes.
>>>> We personally used a simple select script *"SELECT host_id FROM
>>>> resources WHERE title ='$class' AND restype = 'Class';"* and received
>>>> class from stored configs that reflect real usage of classes.
>>>> Maybe there is an option to make that if in settings *
>>>> using_storeconfigs* is set to true, use the select directly from
>>>> resources table, and not from the table Foreman uses for provisioning? I
>>>> think it would be just great, and would make Foreman even more informative
>>>> in case if you have more that 1500 classes ;)
>>>>
>>>
>>> if you use storeconfigs, then you should have a button with all puppet
>>> classes under the host show page ;)
>>>
>>> Ohad
>>>
>>>> --
>>>> You received this message because you are subscribed to the Google
>>>> Groups "Foreman users" group.
>>>> To view this discussion on the web visit https://groups.google.com/d/**
>>>> msg/foreman-users/-/**GJ3vzf4SonYJ
>>>> .
>>>> To post to this group, send email to forema...@googlegroups.com**.
>>>> To unsubscribe from this group, send email to foreman-user...@**
>>>> googlegroups.com.
>>>>
>>>> For more options, visit this group at http://groups.google.com/**
>>>> group/foreman-users?hl=en
>>>> .
>>>>
>>>
>>> --
>> You received this message because you are subscribed to the Google Groups
>> "Foreman users" group.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msg/foreman-users/-/NpHLNV_RmggJ.
>>
>> To post to this group, send email to forema...@googlegroups.com
>> .
>> To unsubscribe from this group, send email to
>> foreman-user...@googlegroups.com .
>> For more options, visit this group at
>> http://groups.google.com/group/foreman-users?hl=en.
>>
>
>
Well, we are using lots of exported resources, and dependency #1 for it is
DB, and now i rechecked it and did not find any of references
of deprecating storeconfigs.
···
On Monday, December 17, 2012 4:45:56 PM UTC+2, Greg Sutcliffe wrote:
>
> On 17 December 2012 14:31, Ohad Levy <ohad...@gmail.com > > wrote:
> > maybe it makes sense to have some basic integration with puppet db for
> this
> > kind of queries?
>
> Not every puppet installation uses a DB (I don't) so we can't rely on
> querying one. Short of parsing manifest files, I can't think of a
> reliable way to do this.
>
So, considering PuppetDB only works with very recent versions of
Puppet, I'm wondering if we could somehow extend the proxy to support
this, since we already support a very simplistic version of this with
"import classes", how difficult would it be to import and store the
classes as a graph as well?
Thanks,
Brian
···
On Mon, Dec 17, 2012 at 9:55 AM, Andrei Burd wrote:
> Well, we are using lots of exported resources, and dependency #1 for it is
> DB, and now i rechecked it and did not find any of references of deprecating
> storeconfigs.
>
> On Monday, December 17, 2012 4:45:56 PM UTC+2, Greg Sutcliffe wrote:
>>
>> On 17 December 2012 14:31, Ohad Levy wrote:
>> > maybe it makes sense to have some basic integration with puppet db for
>> > this
>> > kind of queries?
>>
>> Not every puppet installation uses a DB (I don't) so we can't rely on
>> querying one. Short of parsing manifest files, I can't think of a
>> reliable way to do this.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Foreman users" group.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/foreman-users/-/Y0FD0-dzMAkJ.
>
> To post to this group, send email to foreman-users@googlegroups.com.
> To unsubscribe from this group, send email to
> foreman-users+unsubscribe@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/foreman-users?hl=en.
Not every puppet installation uses a DB (I don't) so we can't rely on
querying one. Short of parsing manifest files, I can't think of a
reliable way to do this.
···
On 17 December 2012 14:31, Ohad Levy wrote:
> maybe it makes sense to have some basic integration with puppet db for this
> kind of queries?
Can't this be achieved by parsing the catalogs? If proxy is on the puppet
master, it could read the catalogs and do something like a class include
audit per host.
This could be a case of a "tableless" Model, but likely would not scale
well as puppetdb will.
···
On Monday, December 17, 2012 8:45:56 AM UTC-6, Greg Sutcliffe wrote:
>
> On 17 December 2012 14:31, Ohad Levy <ohad...@gmail.com > > wrote:
> > maybe it makes sense to have some basic integration with puppet db for
> this
> > kind of queries?
>
> Not every puppet installation uses a DB (I don't) so we can't rely on
> querying one. Short of parsing manifest files, I can't think of a
> reliable way to do this.
>
That occurred to me too, but I wasn't sure if the catalogs are stored
anywhere - are they not created in memory and sent to the client? I'm
not too concerned about performance, since you would probably only
ever run this task manually, on demand…
···
On 18 December 2012 02:04, treydock wrote:
> Can't this be achieved by parsing the catalogs? If proxy is on the puppet
> master, it could read the catalogs and do something like a class include
> audit per host.
>
>
>
>>
>> > maybe it makes sense to have some basic integration with puppet db for
this
>> > kind of queries?
>>
>> Not every puppet installation uses a DB (I don't) so we can't rely on
>> querying one. Short of parsing manifest files, I can't think of a
>> reliable way to do this.
>
>
> Can't this be achieved by parsing the catalogs? If proxy is on the
puppet master, it could read the catalogs and do something like a class
include audit per host.
>
You don't even need the smart proxy:
http://docs.puppetlabs.com/guides/rest_api.html#catalogs
I think that's 2.6.something and later.
You'd still be parsing catalogs of undocumented format of course.
Mike
···
On 18 Dec 2012 03:04, "treydock" wrote:
> On Monday, December 17, 2012 8:45:56 AM UTC-6, Greg Sutcliffe wrote:
>> On 17 December 2012 14:31, Ohad Levy wrote:
>
> > Can't this be achieved by parsing the catalogs? If proxy is on the
puppet
> > master, it could read the catalogs and do something like a class include
> > audit per host.
>
> That occurred to me too, but I wasn't sure if the catalogs are stored
> anywhere - are they not created in memory and sent to the client? I'm
> not too concerned about performance, since you would probably only
> ever run this task manually, on demand…
>
> –
> You received this message because you are subscribed to the Google Groups
"Foreman users" group.
> To post to this group, send email to foreman-users@googlegroups.com.
> To unsubscribe from this group, send email to
foreman-users+unsubscribe@googlegroups.com.
> For more options, visit this group at
http://groups.google.com/group/foreman-users?hl=en.
>
I believe all catalogs are stored on disk at /var/lib/puppet/client_yamls,
at least on CentOS 6. Ill dig in some old code I wrote, but theres a way
to read catalogs through Puppet classes in Ruby. I think I used a hosts
catalog for a Drush script to find all instances of Drupal defined by
Puppet on a local node.
···
On Dec 18, 2012 4:57 AM, "Greg Sutcliffe" wrote:
> On 18 December 2012 02:04, treydock wrote:
we are now added it to our puppet classes page, with straight select form
DB, did not affected too much.
···
*____________________*
*Andrei Burd*
*Tel: +972 (546) 46 22 36*
*Skype: burdandrei*
On 18 December 2012 12:57, Greg Sutcliffe greg.sutcliffe@gmail.com wrote:
On 18 December 2012 02:04, treydock treydock@gmail.com wrote:
Can’t this be achieved by parsing the catalogs? If proxy is on the
puppet
master, it could read the catalogs and do something like a class include
audit per host.
That occurred to me too, but I wasn’t sure if the catalogs are stored
anywhere - are they not created in memory and sent to the client? I’m
not too concerned about performance, since you would probably only
ever run this task manually, on demand…
–
You received this message because you are subscribed to the Google Groups
"Foreman users" group.
To post to this group, send email to foreman-users@googlegroups.com.
To unsubscribe from this group, send email to
foreman-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/foreman-users?hl=en.
The only way I could see something like this working, is if we updated the
ENC script to parse and upload this data, and make a corresponding change
to the API to allow it consume this data. (IE: Foreman can't really reach
out to clients for data).
I still think our best bet is to deal with this at the
smart-proxy/puppetmaster level, and cache this class tree at the same time
on does an "import classes". (My apologies for oversimplifying this.)
-Brian
···
On Tue, Dec 18, 2012 at 9:39 AM, Trey Dockendorf wrote:
I believe all catalogs are stored on disk at /var/lib/puppet/client_yamls,
at least on CentOS 6. Ill dig in some old code I wrote, but theres a way
to read catalogs through Puppet classes in Ruby. I think I used a hosts
catalog for a Drush script to find all instances of Drupal defined by
Puppet on a local node.
–
http://aws.amazon.com/solutions/solution-providers/brandorr/
> The only way I could see something like this working, is if we updated the
> ENC script to parse and upload this data, and make a corresponding change
> to the API to allow it consume this data. (IE: Foreman can't really reach
> out to clients for data).
>
> I still think our best bet is to deal with this at the
> smart-proxy/puppetmaster level, and cache this class tree at the same time
> on does an "import classes". (My apologies for oversimplifying this.)
>
>
another option is to do that via mcollective ?
Ohad
···
On Wed, Dec 19, 2012 at 8:54 AM, Brian Gupta wrote:
-Brian
On Tue, Dec 18, 2012 at 9:39 AM, Trey Dockendorf treydock@gmail.comwrote:
I believe all catalogs are stored on disk at
/var/lib/puppet/client_yamls, at least on CentOS 6. Ill dig in some old
code I wrote, but theres a way to read catalogs through Puppet classes in
Ruby. I think I used a hosts catalog for a Drush script to find all
instances of Drupal defined by Puppet on a local node.
–
http://aws.amazon.com/solutions/solution-providers/brandorr/
–
You received this message because you are subscribed to the Google Groups
"Foreman users" group.
To post to this group, send email to foreman-users@googlegroups.com.
To unsubscribe from this group, send email to
foreman-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/foreman-users?hl=en.
