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

[Jon McKenzie]

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 and choose which host, 
> > hostgroup, etc. gets which mutator and what order the mutators should 
> run, 
> > but this would take a little bit more effort to implement). Ideally, the 
> > ENC data would be exposed in the web UI along each part of the chain so 
> > that operators can inspect and validate its correctness -- at the very 
> > least, a 'before' and 'after' image could be displayed. 
> > 
> > Before I start building something, I'd like to get some thoughts on this 
> > idea. Would other people find this useful? Are there other approaches 
> > people have tried and 

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

[David Davis]

Lzap,

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


David

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.
>
> --
> 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.
>

-- 
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] Re: Pushed downstream translations to Transifex

[bk]

Bump on this. Any feedback is appreciated.

On Friday, July 29, 2016 at 1:13:19 PM UTC-4, bk wrote:
>
> This is a followup to the ConfigCamp discussion on translations. 
>
> During the Satellite 6.2 release, Red Hat engaged a set of professional 
> translators to localize the application. This was done in an internal 
> instance of Zanata, and therefore not available to the community. During 
> ConfigCamp we analyzed Zanata, and felt it would be a step back and 
> therefore did not suggest moving all translations. Instead, we worked on 
> some scripts to load strings directly into Transifex. This would allow 
> the normal translation process to occur, and the strings would get 
> pulled in when appropriate. 
>
> I have loaded in all translations from the internal Zanata instance into 
> Transifex. These are marked as "unreviewed" so you can use Transifex to 
> review the changes. 
>
> I have not yet loaded any changed translations into transifex. You can 
> see the changes at [1]. There is one diff file per language. I would 
> like to give folks a week (until 5 August) to review before I push them 
> in. If folks can not do this, the strings would still be marked as 
> unreviewed so the tool can be used to find the changes. 
>
> Please let me know if you have comments on the process, or if you have 
> concerns with the changed translations. I can send along the individual 
> diff files if that would help (they are not diff format). 
>
> Also, if anyone who has the ability to post notifications to Transifex 
> could add this there I would appreciate it. 
>
> -- bk 
>
> [1] https://gist.github.com/bkearney/3c22b57d19656b04e1b10387e0b5452a 
> 
>  
>

-- 
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?

[Tom McKay]

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).

-- 
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] updates to test_develop_pull_request update subjobs

[Greg Sutcliffe]

Hi all,

Ori sent a pin to develop today[1] for the fast_gettext gem, however the
update17 subjob was still failing. Since these jobs are (I think) meant to
test db migrations on the currently supported versions, it seemed right to
update them to test against 1.11-stable and 1.12-stable.

So, I've updated the subjobs to be update111 and update112 repsectively.
However, update112 was still failing, as it also required the gem
pinning[2], so I've cherry-picked that commit. Update111 is fine because
the Gemfile in 1.11-stable already defines a lower version of
fast_gettext[3].

TL;DR test_develop_pull_request should be working again, but you may need
to kick the tests if you sent PRs in the last day or so.

[1]
https://github.com/theforeman/foreman/commit/46597839accd8533db119d56135a9b6ed9e01f87
[2] https://github.com/theforeman/foreman/blob/1.11-stable/Gemfile#L23
[3]https://github.com/theforeman/foreman/blob/1.12-stable/Gemfile#L21


-- 
Greg
IRC: gwmngilfen

-- 
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?

[Ivan Necas]

On Wed, Aug 3, 2016 at 4:26 PM, 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.

Just to make sure we are on the same page, we are not talking about
merging it into Foreman and not having the Katello sub-project,
it's about Katello having it's own tree not being in the Foreman
tree [1]. So effectively it's just a moving it to the similar place where
the rest of plugins is, rather than treating it specially.

[1] - http://projects.theforeman.org/projects

-- Ivan

>
> I don't know, I would not like to see Discovery project merged into the
> Core. I'd like to keep all plugins separate.
>
> --
> 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.

-- 
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]

> For example, several dev teams are experimenting with redmine "versions"
> for their sprints[1]. I don't think that a single version can include

One more thing. This will pollute Target versions, I don't like this.

Can't we simply use Issue trackers for that? Redmine is quite good in
creating trackers and associating it. Also, it creates nice place for
conversation about the sprint.

An example of such a tracker:

http://projects.theforeman.org/issues/10294

-- 
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]

> 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.

-- 
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?

[Andrew Kofink]

+1 to less separation of the two projects in our overhead organization of
issues/features.

Andrew Kofink

Software Engineering Intern
Red Hat Satellite 6
akof...@redhat.com

On Wed, Aug 3, 2016 at 4:08 AM, Marek Hulán  wrote:

> +1 for moving into Foreman project subtree
>
> --
> Marek
>
> On Tuesday 02 of August 2016 17:36:53 Ivan Necas wrote:
> > I think having everything under one tree makes sense. Long-term, the
> > goal is to turn
> > Katello to not feel like a separate project, but rather an extension.
> >
> > +1
> >
> > Of course I'm not aware of some possible consequences if there are any?
> >
> > -- Ivan
> >
> > On Tue, Aug 2, 2016 at 3:56 PM, Tom McKay 
> wrote:
> > > As we try to work towards better bugzilla and redmine component
> > > definitions
> > > and relations, I keep finding myself wishing I could use redmine for
> both
> > > foreman and katello issues together.
> > >
> > > For example, several dev teams are experimenting with redmine
> "versions"
> > > for their sprints[1]. I don't think that a single version can include
> > > issues from both foreman and katello projects. If katello was a
> > > subproject of foreman, though, then teams could bring any issue into
> > > their sprint view.
> > >
> > > Is there a case for keeping katello separate any longer, or can we
> > > combine?
> > >
> > > [1]
> > >
> http://projects.theforeman.org/projects/foreman/roadmap#Team_Ivan_Iteratio
> > > n_1
> > >
> > > --
> > > 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.
>

-- 
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] No uploader

[Marek Hulán]

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.