I am all for pulling all complex changes out of post scriplets.

On the other hand, I like that not calling an installer was always an
option, at least for minor releases. We have lots of users (mainly in
downstream) who did not buy into Puppet and they tend to modify lots
of configs manually trying to avoid installer runs as possible. This
change would make this required otherwise database wont be migrated.

I would like to have an external script that would do the work but you
could still run it outside of the installer. This is kinda Satellite 5
experience, which is not bad at all I think.

LZ

On Mon, Sep 25, 2017 at 8:02 AM, Marek Hulán <mhu...@redhat.com> wrote:
> I'd be in favor of a change and avoid running scripts in post scripts. This is
> the reason why we added "Optional Step 3 (C) - Run foreman-installer" to our
> manual [1] a long time ago. We recommend running installer after upgrade if
> users use it for initial setup. If this is too heavy step, maybe foreman-
> maintain task could be added that would ensure all is up to date.
>
> [1] https://theforeman.org/manuals/1.15/#UpgradingtoForeman1.15
>
> --
> Marek
>
> On pondělí 25. září 2017 0:54:10 CEST Andrew Schofield wrote:
>> [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
>
>
> --
> 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.



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

Reply via email to