[foreman-dev] Re: Discourse summary week 2 (ish)

[Andrew Schofield]

I'm generally silent in here. It's certainly a +1 from me. I like the 
formatting. I like the categories. I like the tags. I like the suggestions. 
Will it take some getting used to? Of course it will.

-- 
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: Database and Service Actions in RPM Post Scripts

[Andrew Schofield]

[I'm a user, not a developer]

I'd suggest that the RPM's *simply* drop the files onto the file system and 
the installer then does the required actions. There are a lot of moving 
parts to foreman and restarting one component can have impact on other 
components. They also duplicate actions which take place in the installer. 
The actions taken by users are (should be) yum update then a run of the 
installer. 

On Friday, September 22, 2017 at 4:19:46 PM UTC-4, Eric Helms wrote:
>
> Howdy,
>
> There have been recent conversations that have popped up on PRs, for 
> example [1], and IRC conversations around whether or not our RPM packages 
> should be performing database actions and restarting services. This thread 
> is intended to gather feedback and view points to arrive a community 
> decision on whether or not we should continue this behavior, alter it with 
> limitation or out right get rid of it.
>
> This mostly happens within Foreman and some plugins, and the actions 
> performed today:
>
>  * database migrations
>  * database seeds
>  * apipie cache
>  * httpd restart
>  * foreman-tasks restart
>
> There may be others, these are the ones I am aware of. The history of 
> these actions, as I understand it, is so that in theory you can yum install 
> a plugin and, without further action, the Foreman server continue to run 
> now with your plugin.
>
> Now, for my personal view point. Our application stack is fairly complex, 
> and there are a decently large number high percentage install plugins and 
> ecosystem of plugins in general. Plugins performing these sorta actions as 
> part of yum install has the potential to create unintended consequences. We 
> have created an idempotent installer to manage our server installations for 
> a reason, to help orchestrate changes, provide a framework for known and 
> coordinated change. And that these types of actions should be strictly 
> relegated to it.
>
> I encourage all Foreman and plugin developers to please weigh in so that 
> we may reach consensus.
>
> Thanks for your time and consideration.
>
>
> [1] https://github.com/theforeman/foreman-packaging/pull/1761
>
> -- 
> 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.

[foreman-dev] Re: Looking for facts from big servers

[Andrew Schofield]

Hi Lukas - I can probably grab some for you - give me a couple of days. 
I'll mail them directly to you - I might need to sanitize some of the data.

On Monday, July 3, 2017 at 9:52:22 AM UTC-4, Lukas Zapletal wrote:
>
> Hey, 
>
> we are redesigning UX of the discovery pages and I was wondering if 
> you can send me output of facter from some big fat servers. Looking 
> for extremes, servers with: 
>
> - lots of CPUs or cores 
> - lots of memory 
> - lots of disks or volumes 
> - or other periciphals 
>
> The command output we are interested in is: 
>
> facter --no-custom-facts --json 
>
> Please pastebin and send to the list or directly to me, thanks! The 
> purpose of this is to import these into foreman and see how it will 
> look like with the new UX design. We don't have anything yet, but we 
> would like to replace the table view with something better, stay 
> tuned. 
>
> -- 
> 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] Re: Satellite/Katello HA and DR Capabilities

[Andrew Schofield]

Use https://access.redhat.com/articles/2474581 as a reference. Need to do 
additional work and testing - it doesn't work out of the box!

We have a 2 node production cluster with one node in our DR site, running 
pacemaker and shared SAN storage. We have a floating IP. Works.

We have 4 Capsules per region sitting behind a load balancer. Works. For 
this, points to note:

- selinux is a pain (as some filesystems are shared via nfs)
- you MUST share puppet ssl and tftp boot directories as a minimum (we 
share over NFS)
- you need to set the puppet auth.conf files to accept connections from the 
LB name
- katello-consumer-ca rpms reference the node, not the LB name so you might 
want to configure subscription-manager post install.
- in Satellite, add the SAME lifecycles to each load balanced node.
- in Satellite register the LB name as a capsule (but DO NOT assign 
lifecycles) - use this capsule in your hostgroups.

On Tuesday, April 25, 2017 at 10:47:20 AM UTC-4, Unix SA wrote:
>
> I am not sure why satellite or katello is missing this basic things like 
> CNAME support or HA, if i have 5000 servers connecting to different 
> capsules with single satellite master with no HA or DR , it makes difficult 
> to recover master if it goes down.
>
> How are you guys managing HA or DR for satellite master ??
>

-- 
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] Re: Revert removal of @host.params for host_param

[Andrew Schofield]

At the very least support both. This is a point release and this is a 
pretty major change for a non-major release.

As per the comment from Ewoud the bulk of people who will use this use it 
in ERB and templates. The templates being probably the easiest to 'fix'. 
Personally, keeping this permanently and proxying to me seems like the 
right thing to do. This functionality has existed for years and is very 
heavily documented all over the place. 

On Wednesday, April 19, 2017 at 12:39:40 PM UTC-4, Greg Sutcliffe wrote:
>
> On Wed, 2017-04-19 at 14:10 +0300, Tomer Brisker wrote: 
> > Since it seems there wasn't an agreement on reverting this made in 
> > time for 1.15, I'd say we should support both for now and reconsider 
> > in the future pending a rewrite of the template engine using a proxy 
> > object as we discussed. 
>
> +1, supporting both seems like the way forward. 
>
> Greg 
>

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

[foreman-dev] Re: assistance adding new models and migrations

[Andrew Schofield]

On this line: 

>> + add_index :katello_repository_dockers, [:docker_manifest_id, 
:repository_id], :unique => true

Add a :name => "my_new_index_name_thats_shorter_than_63_chars"


On Wednesday, November 2, 2016 at 9:56:10 PM UTC-4, Tom McKay wrote:
>
> Used the other cv filter migrations to try to make mine. I'm not sure how 
> to get around this, though:
>
> ArgumentError: Index name 
> 'index_katello_repository_dockers_on_docker_manifest_id_and_repository_id' 
> on table 'katello_repository_dockers' is too long; the limit is 63 
> characters 
>
> On Wed, Nov 2, 2016 at 7:40 PM, Tom McKay  > wrote:
>
>> In the spirt of "teach me to fish", can someone guide me on how best to 
>> add new entries to the database from some new models I need? I am adding 
>> content view filters that will limit docker tags[1]. Similar models already 
>> exist for rpm packages so I had a good place to start, but I'm struggling 
>> to know what the migrations should be.
>>
>> Thanks!
>>
>>
>> [1] 
>> https://github.com/Katello/katello/compare/patternfly-compliance...thomasmckay:docker-cv-filter
>>
>
>

-- 
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] Re: High Availability - best practices docs group

[Andrew Schofield]

RedHat have published a reference architecture for Satellite 6.2 which 
covers a lot of areas - it is available 
https://access.redhat.com/sites/default/files/attachments/sat6ha-lb-refarch.pdf

On Tuesday, October 25, 2016 at 10:26:52 AM UTC-4, Chris Baldwin wrote:
>
>
>
> On Tuesday, October 25, 2016 at 10:21:30 AM UTC-4, Martin Dobrev wrote:
>>
>>
>>
>> On Tuesday, 25 October 2016 14:43:27 UTC+1, Greg Sutcliffe wrote:
>>>
>>> On 25 October 2016 at 13:53, Christopher Pisano  
>>> wrote:
>>>
 we should maybe all try and jump on a video call and talk out our 
 different experiences and come together as to what we believe *should* be 
 the best practices. 

>>>
>>> That sounds like a good idea - I can host that if needed (but you could 
>>> probably figure out a hangout yourselves :P). Would you want that public 
>>> (recorded, deep-dive style), or "private" (jn the sense that its open to 
>>> the community to join, but not recorded)?
>>>
>>>  
>> Initial talks can be private until we get some sort of draft on work 
>> required. Then we might record as well so community knows what's going on. 
>> Of course everyone's invited to participate and contribute to our talks.
>>  
>>
>>> Greg
>>>
>>
> Honestly, the opsec considerations in either scenario are the same. I 
> would suggest recording it in case there are questions later.
>
> This is my first shot at multiple-foreman documentation: 
> https://theforeman.org/manuals/1.13/index.html#5.8MultipleForemaninstances 
> . It touches on a few things Chris P. mentioned in his blog post (reposted 
> on Foreman's site), and points out a few other issues that I ran in to. It 
> doesn't address HA proxy stuff, PG pool for the DB (if needed), setting up 
> a real (not self-signed) cert, etc.
>

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