[foreman-dev] Re: Seeding templates overrides custom changes - should we lock templates we ship?

[Andrew Schofield]

As a heavy and active user, I'd fully support locking. There are quite 
often new features / functionalities / bugfixes / new OS support etc in the 
new templates. Reading these differences and utilising these as a reference 
for our custom templates is a good way to go imho.

On Friday, February 17, 2017 at 9:05:13 AM UTC-5, Marek Hulán wrote:
>
> Hello foreman-devs, 
>
> recently I was told about the bug that we override all templates in 
> database 
> whenever we run db:seed. From the code [1] and commit message [2], it was 
> not 
> the intended behavior. It was supposed to check whether user made some 
> changes 
> and only apply the new version if the template was not touched. Sadly, the 
> method only checks the name attribute for changes [3], so if "only" 
> template 
> content was changed, we still override it. 
>
> While I can try to fix it to originally intended behavior, I'd like to ask 
> whether it wouldn't be better to use this opportunity and start locking 
> templates we ship by default. The recommended workflow for users would be 
> to 
> clone the template if custom changes are needed. We'd always update locked 
> templates. Obviously, user would need to merge new version to cloned 
> template 
> on his own. With foreman_templates plugin it should be easy enough to 
> export 
> templates and see the diff between default and customized template, apply 
> the 
> changes user wants and then reimport them back. 
>
> I think this would be overall better user experience and safer workflow. 
> The 
> originally intended behavior would never update a template that user 
> modified. 
> That means after update user ends up with template from old Foreman 
> version 
> (with custom changes) that might not be compatible with the new Foreman 
> version. This is more likely to happen than before because we now version 
> templates in community-repo and we don't keep backward compatibility as we 
> did 
> before. 
>
> Thanks for reading, thoughts? 
>
> [1] 
> https://github.com/theforeman/foreman/blob/1.14.0/db/seeds.d/07-provisioning_templates.rb#L98
>  
> [2] https://github.com/theforeman/foreman/commit/ 
> d4ed70154fa9f6c83597adc784240e3865845563 
> 
>  
> [3] https://github.com/theforeman/foreman/blob/1.14-stable/db/seeds.rb#L33 
>
> -- 
> 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.

Re: [foreman-dev] Broadening katello-deploy's horizons

[Eric D Helms]

Looks like the "Forklift" maintainers team does not have the necessary
rights to manage the repository. Could this team please be given the
requisite permission updates?

On Thu, Feb 16, 2017 at 11:15 AM, Eric D Helms  wrote:

> This task has been finalized with Forklift moving to theforeman Github
> organization proper. All issues and PRs have been moved and Github should
> properly redirect.
>
> https://github.com/theforeman/forklift
>
>
> Eric
>
> On Mon, Jan 23, 2017 at 3:01 PM, Eric D Helms 
> wrote:
>
>> Thanks for setting that up Daniel!
>>
>> On Jan 23, 2017 2:13 PM, "Daniel Lobato"  wrote:
>>
>>> Team is ready at https://github.com/orgs/theforeman/teams/forklift
>>>
>>> On Sun, Jan 22, 2017 at 11:02 PM, Ivan Necas  wrote:
>>> > Eric D Helms  writes:
>>> >
>>> >> Reviving this thread.
>>> >>
>>> >> In one weeks time, I'd like to officially move Forklift to the Foreman
>>> >> organization. If there are any objections or concerns, speak now or
>>> forever
>>> >> hold your peace.
>>> >
>>> > +1000 for moving.
>>> >
>>> > -- Ivan
>>> >
>>> >>
>>> >> The following developers currently have write access and thus I'd
>>> like to
>>> >> request a team setup to ensure we keep access:
>>> >>
>>> >> ehelms (admin)
>>> >> jlsherrill (admin)
>>> >> stbenjam
>>> >> ekohl
>>> >> johnpmitsch
>>> >> bbuckingham
>>> >> beav
>>> >>
>>> >> Thanks,
>>> >> Eric
>>> >>
>>> >> On Wed, Jun 1, 2016 at 11:01 AM, Eric D Helms 
>>> wrote:
>>> >>
>>> >>> The katello-deploy repository has been officially renamed to
>>> 'forklift' in
>>> >>> concert with the code updates. The next step is to move this
>>> officially
>>> >>> into theforeman organization on Github.
>>> >>>
>>> >>> On Wed, May 25, 2016 at 11:36 AM, Eric D Helms >> >
>>> >>> wrote:
>>> >>>
>>> 
>>> 
>>>  On Wed, May 25, 2016 at 10:14 AM, Ewoud Kohl van Wijngaarden <
>>>  ew...@kohlvanwijngaarden.nl> wrote:
>>> 
>>> > On Wed, May 25, 2016 at 10:13:34AM -0400, Eric D Helms wrote:
>>> > > The first stage of this has been completed, with the code
>>> switching to
>>> > > forklift. The next two stages would be:
>>> > >
>>> > >  1) Rename the repository
>>> > >  2) Transfer to theforeman github organization
>>> > >
>>> > > I am of the opinion those two should be done at the same time,
>>> with 1
>>> > week
>>> > > pre-warning to users and developers to allow for update
>>> preparation to
>>> > > their usage, scripts and automation so that they do it once and
>>> not
>>> > twice.
>>> > > I'll leave this idea open for comment for a few days and then
>>> plan for
>>> > the
>>> > > one week cycle.
>>> >
>>> > I believe that Github will redirect, at least on transfer.
>>> >
>>> 
>>>  Nice - in that case I'll bump up the time table.
>>> 
>>> 
>>> >
>>> > --
>>> > 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.
>>> >
>>> 
>>> 
>>> 
>>>  --
>>>  Eric D. Helms
>>>  Red Hat Engineering
>>>  Ph.D. Student - North Carolina State University
>>> 
>>> >>>
>>> >>>
>>> >>>
>>> >>> --
>>> >>> Eric D. Helms
>>> >>> Red Hat Engineering
>>> >>> Ph.D. Student - North Carolina State University
>>> >>>
>>> >>
>>> >>
>>> >>
>>> >> --
>>> >> Eric D. Helms
>>> >> Red Hat Engineering
>>> >>
>>> >> --
>>> >> 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.
>>>
>>>
>>>
>>> --
>>> Daniel Lobato
>>>
>>> @dlobatog
>>> daniellobato.me
>>>
>>> GPG: http://keys.gnupg.net/pks/lookup?op=get=0x7A92D6DD38D6DE30
>>>
>>
>
>
> --
> Eric D. Helms
> Red Hat Engineering
>



-- 
Eric D. Helms
Red Hat Engineering

-- 
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] Seeding templates overrides custom changes - should we lock templates we ship?

[Tom McKay]

+1 to locking

I have messed up a production install by changing a template for personal
use, not realizing that they span other orgs... oops!

On Fri, Feb 17, 2017 at 9:04 AM, Marek Hulán  wrote:

> Hello foreman-devs,
>
> recently I was told about the bug that we override all templates in
> database
> whenever we run db:seed. From the code [1] and commit message [2], it was
> not
> the intended behavior. It was supposed to check whether user made some
> changes
> and only apply the new version if the template was not touched. Sadly, the
> method only checks the name attribute for changes [3], so if "only"
> template
> content was changed, we still override it.
>
> While I can try to fix it to originally intended behavior, I'd like to ask
> whether it wouldn't be better to use this opportunity and start locking
> templates we ship by default. The recommended workflow for users would be
> to
> clone the template if custom changes are needed. We'd always update locked
> templates. Obviously, user would need to merge new version to cloned
> template
> on his own. With foreman_templates plugin it should be easy enough to
> export
> templates and see the diff between default and customized template, apply
> the
> changes user wants and then reimport them back.
>
> I think this would be overall better user experience and safer workflow.
> The
> originally intended behavior would never update a template that user
> modified.
> That means after update user ends up with template from old Foreman version
> (with custom changes) that might not be compatible with the new Foreman
> version. This is more likely to happen than before because we now version
> templates in community-repo and we don't keep backward compatibility as we
> did
> before.
>
> Thanks for reading, thoughts?
>
> [1] https://github.com/theforeman/foreman/blob/1.14.0/db/seeds.
> d/07-provisioning_templates.rb#L98
> [2] https://github.com/theforeman/foreman/commit/
> d4ed70154fa9f6c83597adc784240e3865845563
> [3] https://github.com/theforeman/foreman/blob/1.14-stable/db/seeds.rb#L33
>
> --
> 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.
>

-- 
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] Sosreport parsing and import into centralized log manager

[Martin Bačovský]

Hi,

as I promised on yesterday's demo [1] I'm here with some information about
proof of concept I'm currently working on.

I've put together skeleton of tool [2] that is able to parse logs collected
by sosreport or foreman-debug and send the structured log events to the
centralized log manager.

What I have is parser for yum.log (low hanging fruit) and first attempt for
generic syslog parser. Parsing syslog is challenging because many tools is
logging there in different formats but the results seem promising.

The resulting stream of events is in GELF format and can be directed to
Journald, Graylog, Logstash or any other tool with GELF support.

If you are interested in more details, check the readme [2] on GitHub.

My plans are to add importers for more logs and explore what benefits could
such tool bring.

I'd like to know if people find such tool helpful and of course I welcome
any kind of contribution.

Lastly I'd like to stress out that this tool is not intended to become
solution for centralized logging in the Foreman ;)

Have a great day,
Martin



[1] https://youtu.be/Zz0Bgt87wPE?t=42m28s
[2] https://github.com/mbacovsky/grokngelf

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