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.