The script sounds like a good start. If every rpm in post runs the script, and the script would be clever enough to know it it needs to run it twice or was already run in the transaction. We would have a win. Also we could have there some check (such as properly placed file somewhere), that could influence, if the script should or should not be run. Not sure it I'm not over-complicating the things by that. But anyway, having the script gives us the power to control the logic from one place as opposed to relying on the plugin specs.
-- Ivan On Mon, Sep 25, 2017 at 9:51 AM, Ohad Levy <ohadl...@gmail.com> wrote: > > > On Mon, Sep 25, 2017 at 9:30 AM, Lukas Zapletal <l...@redhat.com> wrote: >> >> 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. > > > Can we start by extracting the code into a script, and then executing the > script from post rpm trans? I dislike the fact that we are now introducing a > must have step (rake db:migrate db:seed apipie:cache:index ) which was not > required before. > > This will also can be reflected in the UI where if we have a pending db > migration for example, we can ask the user to execute that script manually > if needed. > > Ohad > >> >> 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. > > > -- > 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.
