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

[Ewoud Kohl van Wijngaarden]

On Fri, Sep 22, 2017 at 04:19:43PM -0400, 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 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


While I generally like it when a yum install just works(tm), I do get 
the feeling that doing it for every plugin causes a lot of extra load 
that shouldn't be needed. Ideally you could queue up tasks like a rake 
db:migrate, apipie:cache:index and restart until everything is done but 
I'm not sure yum can do this and if so how well that'll work.


Another question I have is whether the apipie cache can be incrementally 
generated or if it's a full regenerate every time.


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

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

[Eric D Helms]

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.