Re: [foreman-dev] Database and Service Actions in RPM Post Scripts

[Christopher Duryee]

On Fri, Sep 22, 2017 at 4:19 PM, Eric D 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 would like if the only code in the RPM scripts was to land the bits on
the system's disk and nothing more. If the RPM scripts break, it is
difficult to find out what happened, and we already provide
foreman-installer to handle updating the system. The RPM scripts doing
things like db:seed and restarts can cause confusion when the application
starts up in a half-ready state during a maintenance window. Many users are
not aware that these types of things can even happen via %post, and are
surprised by it. They are also surprised if application error messages or
unusual return codes appear during RPM install.

-- 
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] Katello pulp_export_destination checks happen inside the application

[Christopher Duryee]

On Sun, Aug 20, 2017 at 4:02 PM, Ewoud Kohl van Wijngaarden <
ew...@kohlvanwijngaarden.nl> wrote:

> Hello all,
>
> While working on splitting the Katello installation from its services I
> ran into the pulp_export_destination setting. That made me look at the
> Repository Export[1] which assumes the pulp server and application server
> share the same filesystem.
>
> That means I'm stuck in attempting to split services to different machines
> where I don't want to assume a shared filesystem. Looking at the containers
> it's not handled there either. I don't see a way to support this feature
> without a major rewrite of the code but I'm not familiar with the Katello
> code base.
>
> Anyone has advice on how to deal with this?
>

I think if Pulp took a parameter to publish to a non-default location, we
would not need to do the extra copy step that ties Katello and Pulp closely
together. Currently it is needed because we need the export to land in
pulp_export_destination.


>
> [1]: https://github.com/Katello/katello/blob/master/app/lib/actio
> ns/katello/repository/export.rb
>
> --
> 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] obtaining "bare" list of hosts from foreman

[Christopher Duryee]

Howdy,

Work is being done in http://projects.theforeman.org/issues/18975 to make
the host api faster. However, sometimes a simple list of hosts will
suffice, and the user can then loop through each host in their script and
fetch the info or perform updates one by one.

Would it make sense to add a "minimal" option to the hosts call, in order
to only send back the host ID and name? I can put in an RFE for this but I
wanted to get feedback first in case there was a better method of
accomplishing the same thing.

-- 
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] Performance analysis deep-dive, what would you like to hear about?

[Christopher Duryee]

On Tue, May 9, 2017 at 9:01 AM,  wrote:

> Hey, I want to do a performance analysis deep-dive.
>
> What I had in mind:
>
> 1. Installation of tooling in development environment
> 2. Simple request breakdown (view, sql)
> 3. Debugging API request
> 4. Time graph (flamegraph)
> 5. Memory consumption
> 6. Installation in prod env
> 7. Analyzing POST requests
>
> Feel free to ask questions and suggest topics that you want me to cover.
>

This list looks good, thanks for covering it. Can you also add how to check
if a foreman instance is maxed out on passenger workers via
passenger-status?


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