Re: [foreman-dev] No uploader

[Marek Hulán]

Ok, so there's an error in the client.rb, the underscore is missing in 
foreman_server_options (see below)

On Wednesday 03 of August 2016 01:23:57 Thomas Fee wrote:
> On the target (Chef) node, I ran "gem install chef_handler_foreman", then
> edited /etc/chef/client.rb.
> 
> Not have any additional information, I just made that file look like the
> documentation you linked to.
> 
> log_location STDOUT
> chef_server_url  "https://172.17.8.101:443;
> validation_client_name "chef-validator"
> # Using default node name (fqdn)
> 
> require 'chef_handler_foreman'
> foreman_server options :url => 'http://oz.local/foreman:8443'
 ^ here's the underscore missing
this actually causes the handler is not being created

--
Marek

> foreman_facts_upload true
> foreman_facts_whitelist ['lsb','network','cpu']
> foreman_facts_blacklist ['kernel','counters','interfaces::sit0']
> foreman_cache_file '/var/cache/chef_foreman_cache.md5'
> foreman_reports_upload true
> reports_log_level "notice"
> 
> On Wednesday, August 3, 2016 at 1:05:36 AM UTC-7, Marek Hulán wrote:
> > Hello,
> > 
> > how did you install the handler? You have to modify /etc/chef/client.rb to
> > register it. See [1] for example how to do it
> > 
> > [1] https://github.com/theforeman/chef-handler-foreman#installation
> > 
> > On Tuesday 02 of August 2016 11:46:40 Thomas Fee wrote:
> > > Trying to get chef-handler-foreman to work. At the end of a Chef
> > 
> > converge,
> > 
> > > it says
> > > 
> > > "ERROR: No uploader registered for foreman reporting, skipping facts
> > 
> > upload"
> > 
> > > "ERROR: No uploader registered for foreman reporting, skipping report
> > > upload"
> > > 
> > > So the question is, how does one get and register an uploader?

-- 
You received this message because you are subscribed to the Google Groups 
"foreman-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to foreman-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [foreman-dev] List moderation "always allow posts" errors

[Marek Hulán]

On Thursday 04 of August 2016 13:33:32 Dominic Cleal wrote:
> Are any other list moderators (of either -dev or -users) getting the
> following errors when allowing the current plus future posts from a user?
> 
> "One message has been posted. Failed to always allow posts from
> u...@example.com due to errors."
> 
> This seems to be occurring every time for me and is increasing the
> amount of moderated messages significantly. If it's affecting others
> then I'll try getting some help from Google Groups.

I haven't seen it even though I saw today two messages from the same user I 
allowed for future posts for sure.

--
Marek

-- 
You received this message because you are subscribed to the Google Groups 
"foreman-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to foreman-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[foreman-dev] RFC Add Reactjs to foreman technology stack

[Gail Steiger]

I have created an RFC [1] recommending using the react javascript library
with foreman, in addition to currently in place javascript tools. POC can
be found at [2].

Please add your comments to the pull request. I am looking forward to the
discussion.

Thank you,

Gail Steiger


[1] https://github.com/theforeman/rfcs/pull/10
[2] https://github.com/theforeman/foreman/pull/3603

-- 
You received this message because you are subscribed to the Google Groups 
"foreman-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to foreman-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Re: [foreman-dev] sprints vs trackers [was: Possible to move redmine Katello project under] Foreman?

[Lukas Zapletal]

> The problem with this approach is that it's hard to create a team
> backlog (you create a giant tracker?), plus tracker issues don't allow
> you to prioritize what do you do in each sprint.

Backlog = whole RedMine (all Feature items that are not associated with
any "sprint" tracker).

> With target versions, you can easily gather the stuff the team has done in a
> sprint (automatically), see what's 'ready for testing' and should be
> done in the next sprint, and you can prioritize your backlog of redmine
> issues.

Indeed that's nice, but that was created for version management, not
scrum management.

> Also the redmine-backlogs plugin doesn't integrate with that -
> http://projects.theforeman.org/rb/master_backlog/  - which makes
> prioritization and moving stuff from one sprint to another easier. With
> a tracker moving stuff from sprint to sprint would mean creating a new
> tracker?

Yes, I mean exactly that. But no moving from "backlog", see above.

And this plugin - it kills our instance the moment we start drag and
dropping.

This whole scrum game miss one particular aspect - agility.

Please, can we please not create these crazy "backlogs" and the dance
around and just use RedMine as it was design for? Otherwise we will be
doing nothing but tossing tickets from backlog to backlog.

 * Put an item on "backlog" = create new Feature, NEW state

 * Put it on "sprint" = associate with feature issue (*)

 * Resolve issue, set Target Foreman version we ship it into

 * Profit!

(*) or use Target version if you really think it's any benefit

-- 
Later,
 Lukas #lzap Zapletal

-- 
You received this message because you are subscribed to the Google Groups 
"foreman-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to foreman-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [foreman-dev] Possible to move redmine Katello project under Foreman?

[Lukas Zapletal]

> You do realize that every other plugin except Katello is under the foreman
> project in redmine, correct?

I haven't realized that, sorry for the noise :-)

-- 
Later,
 Lukas #lzap Zapletal

-- 
You received this message because you are subscribed to the Google Groups 
"foreman-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to foreman-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[foreman-dev] List moderation "always allow posts" errors

[Dominic Cleal]

Are any other list moderators (of either -dev or -users) getting the
following errors when allowing the current plus future posts from a user?

"One message has been posted. Failed to always allow posts from
u...@example.com due to errors."

This seems to be occurring every time for me and is increasing the
amount of moderated messages significantly. If it's affecting others
then I'll try getting some help from Google Groups.

-- 
Dominic Cleal
domi...@cleal.org

-- 
You received this message because you are subscribed to the Google Groups 
"foreman-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to foreman-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [foreman-dev] Plugin Proposal: User-defined ENC mutation

[Ewoud Kohl van Wijngaarden]

You should also consider if it should within the foreman or in node.rb.
Both have advantages and disadvantages. In a sense there's already a
mutator in place in node.rb[1].

[1]: 
https://github.com/theforeman/puppet-foreman/blob/d239f0b4104ffa6839a9fc966581bff098d93e1e/files/external_node_v2.rb#L356-L364

On Wed, Aug 03, 2016 at 10:47:35AM -0700, Jon McKenzie wrote:
> Thanks Marek, this is helpful. I'll work on an RFC to try and hash out some 
> of the details.
> 
> On Tuesday, August 2, 2016 at 9:58:59 AM UTC-4, Marek Hulán wrote:
> >
> > Hello 
> >
> > thanks for the write up. first of all - I find it useful. Not only for 
> > users but 
> > for plugin developers too. I encountered this scenario several times 
> > already, 
> > I'd like to extend ENC from plugin. For example in foreman_openscap we 
> > provide 
> > puppet module to configure scap client and we need to add the manifest to 
> > all 
> > hosts on which certain policy should be applied. In other words we need to 
> > add 
> > class and parameters for it into the ENC output. We would find the same 
> > thing 
> > useful in remote execution to configure ssh keys. 
> >
> > So I wonder if we should add some helpers to Foreman core that would allow 
> > register "mutators" and your plugin could use it and just add the UI that 
> > allows adding rules that would add mutators. Or other plugins might depend 
> > on 
> > your plugin to use mutators. I lean towards that we provide such mechanism 
> > in 
> > core, so PRs against core would be welcome (from me at least). 
> >
> > It might be worth of suggesting through our RFC repo - 
> > https://github.com/theforeman/rfcs see PRs for examples 
> >
> > Anyway let me know if I can help somehow with your effort. 
> >
> > -- 
> > Marek 
> >
> > On Monday 01 of August 2016 10:36:11 Jon McKenzie wrote: 
> > > Quite a while ago I posted a thread 
> > > <
> > https://groups.google.com/forum/#!searchin/foreman-users/%22smart$20classes 
> > > %22|sort:relevance/foreman-users/8BMaCeDXsM4/dVv5XSPqR7kJ> to the 
> > Foreman 
> > > Users group asking about the concept of "smart classes", i.e. the 
> > ability 
> > > to dynamically assign Puppet classes (similar to smart class parameters) 
> > > depending on fact or other data. I didn't get any responses, and 
> > > ultimately, our team ended up doing something 
> > > straightforward and created hostgroups for each permutation of Puppet 
> > > classes that we had in our environment (rather than sink development 
> > time 
> > > into solving the problem in a different way). Predictably, this has 
> > become 
> > > somewhat annoying to maintain as our environment has grown. 
> > > 
> > > I started thinking more about this recently, and came up with what I 
> > think 
> > > might be a workable solution to this type of requirement. Let me know 
> > what 
> > > you think. 
> > > 
> > > The basic problem is that Foreman's model for categorizing hosts is a 
> > > little bit too rigid to handle certain use cases. For my environment, 
> > there 
> > > are two basic issues: assigning a class based on fact or parameter data, 
> > > and removing inherited classes based on the same. I could imagine other 
> > > scenarios as well, however, for example retrieving a class parameter 
> > value 
> > > from an external system (rather than storing it statically within 
> > Foreman). 
> > > 
> > > For users who can't accomplish their host classification with the 
> > builtin 
> > > tools, there would be a "safety valve" of sorts -- a Foreman 
> > administrator 
> > > could define little bits of code that mutate the Foreman-generated ENC 
> > data 
> > > arbitrarily (sort of like ENC middleware), based on fact or other data 
> > > about the host. This would work in the following way: 
> > > 
> > > The admin would define ENC "mutators" in a configuration directory, e.g. 
> > > /etc/foreman/mutators.d. There would be a standard API for these 
> > mutators 
> > > that might look something like this: 
> > > 
> > > Mutator.create(:some_mutator_name) do |enc, facts| 
> > >   if facts[:ipaddress] =~ /^10\./ and 
> > !enc[:classes].has_key?('some::class') 
> > > enc[:classes]['some::class'] = nil 
> > >   end 
> > >   enc 
> > > end 
> > > 
> > > (where `facts' is a hash of the requesting host's facts and `enc' is the 
> > > standard ENC data returned by Foreman's node classifier) 
> > > 
> > > When the Foreman server boots, it would load these mutators out of the 
> > > config dir. When a Puppet server requests ENC data for a host, Foreman 
> > > would retrieve the ENC data as normal, and then run the mutators against 
> > > that data in some configurable order. Each mutator would return the 
> > mutated 
> > > ENC, and this would be passed on to the next mutator in the chain. At 
> > the 
> > > end of the chain, the final ENC data would be passed back to the Puppet 
> > > server to use for catalog compilation. (Optionally, a system could be 
> > > established to allow the web UI user to pick 

Re: [foreman-dev] Possible to move redmine Katello project under Foreman?

[Tomas Strachota]

On 08/03/2016 06:30 PM, Tom McKay wrote:



On Wed, Aug 3, 2016 at 10:26 AM, Lukas Zapletal > wrote:

> Is there a case for keeping katello separate any longer, or can we 
combine?

Because it's a plugin? And plugins have its own release cadence, own
planning (Release versions, Target versions) and Categories. I don't see
enough benefits of merging when I consider all the above.

I don't know, I would not like to see Discovery project merged into the
Core. I'd like to keep all plugins separate.


I'm suggesting that we make katello a subproject of foreman. There are
already plugin subprojects (eg. discovery). By moving it under the
single parent project other redmine features become usable (eg. loading
a sprint with issues from both foreman and katello).



+1 for moving it into a subproject and treating it the same as other 
plugins.



--
You received this message because you are subscribed to the Google
Groups "foreman-dev" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to foreman-dev+unsubscr...@googlegroups.com
.
For more options, visit https://groups.google.com/d/optout.


--
You received this message because you are subscribed to the Google Groups 
"foreman-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to foreman-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.