Re: [foreman-dev] Access to foreman-infra
On Mon, Sep 25, 2017 at 02:01:57PM +0200, Ewoud Kohl van Wijngaarden wrote: > To get more involved in foreman infra I'd like to request push access to > foreman-infra. At first I'd like to help more with the CI. +1 -- Michael Moll -- 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: Re: [foreman-dev] Re: 1.15.4 - 1.16 RC.1 - 1.17 status
On 09/24, Ohad Levy wrote: > On Wed, Sep 20, 2017 at 10:04 AM, Daniel Lobato Garcia > wrote: > > > More updates on what's going on: > > > > On 09/14, Daniel Lobato Garcia wrote: > > > Hi all, > > > > > > Just a heads up on the status of all of the upcoming releases: > > > > > > - 1.15.4 > > > - After doing all the cherry-picks, 1.15.stable went red in Jenkins > > > https://github.com/theforeman/foreman/pull/4827 fixes it, after > > > that is merged we should be able to start the usual build > > > tarballs/sign/release dance to release. > > > > This was released 2 days ago. > > > > > > > > - 1.16.RC1 > > > - Tags and packages have been added to Koji, branching was done. > > > Many dependencies need to be built in the foreman-1.16-rhel7 tag. > > > As soon as the dependencies finish building, we can start building > > > the first RC and figuring out what are the blockers and must-haves > > > for this release. > > > http://koji.katello.org/koji/tags > > > > Koji is fine now. There was a problem on the cloning tags script that is > > now fixed. I have started tagging and we should be getting the RC as > > soon as packages are signed/tested and published. > > > > No pressure - but any ETA? This was fixed on Thursday 21st IIRC - the issue is that when I cloned the tags from nightly, Koji didn't clone the builds to the new tag. I cloned all the latest builds and had to do some adjustments for some that were not meant to be there. The original problem could have been solved by this: https://github.com/theforeman/foreman-packaging/pull/1816 which we didn't know about as this argument was not required in previous version of koji (the cli program I mean) > > > > > > > > > > - 1.17.0 > > > - This should be the Rails 5 release. In addition to that, we need > > > to find a way to skip parameters parsing, for ActiveJob and > > > Katello to be more performant. As soon as this is merged we can > > > move testing to be on Rails 5. > > > https://github.com/Katello/katello/pull/6875 > > > If the CentOS team does not migrate rh-ror50 (software collection > > > for Rails 5) to http://softwarecollections.org/, it sounds like we > > > will have to do our own SCLo again. > > > > Unsolved yet. We are thinking on moving directly to Rails 5.1 to avoid > > having to change the SCL twice. > > > > > > > > Happy to help, give more details about any of these, or accept any > > > collaborators that want to nanny any of these to completion :) > > > > > > > > > Best, > > > > > > -- > > > Daniel Lobato Garcia > > > > > > @dLobatog > > > blog.daniellobato.me > > > daniellobato.me > > > > > > GPG: http://keys.gnupg.net/pks/lookup?op=get&search=0x7A92D6DD38D6DE30 > > > Keybase: https://keybase.io/elobato > > > > > > > > -- > > Daniel Lobato Garcia > > > > @dLobatog > > blog.daniellobato.me > > daniellobato.me > > > > GPG: http://keys.gnupg.net/pks/lookup?op=get&search=0x7A92D6DD38D6DE30 > > Keybase: https://keybase.io/elobato > > > > -- > > 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. -- Daniel Lobato Garcia @dLobatog blog.daniellobato.me daniellobato.me GPG: http://keys.gnupg.net/pks/lookup?op=get&search=0x7A92D6DD38D6DE30 Keybase: https://keybase.io/elobato -- 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. signature.asc Description: PGP signature
Re: [foreman-dev] Access to foreman-infra
Definitely +1. On Mon, Sep 25, 2017 at 2:48 PM, Greg Sutcliffe wrote: > On Mon, 2017-09-25 at 14:01 +0200, Ewoud Kohl van Wijngaarden wrote: > > Hello all, > > > > To get more involved in foreman infra I'd like to request push access > > to foreman-infra. At first I'd like to help more with the CI. > > +1, I'm actually surprised you don't already have it ;) > > -- > 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.
Re: [foreman-dev] Access to foreman-infra
On Mon, 2017-09-25 at 14:01 +0200, Ewoud Kohl van Wijngaarden wrote: > Hello all, > > To get more involved in foreman infra I'd like to request push access > to foreman-infra. At first I'd like to help more with the CI. +1, I'm actually surprised you don't already have it ;) -- 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] Access to foreman-infra
On pondělí 25. září 2017 14:01:57 CEST Ewoud Kohl van Wijngaarden wrote: > Hello all, > > To get more involved in foreman infra I'd like to request push access to > foreman-infra. At first I'd like to help more with the CI. > > Regards, > Ewoud Kohl van Wijngaarden +1, although I'm not in infrastructure team :-) -- Marek -- 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] Access to foreman-infra
On Mon, Sep 25, 2017 at 3:01 PM, Ewoud Kohl van Wijngaarden < ew...@kohlvanwijngaarden.nl> wrote: > Hello all, > > To get more involved in foreman infra I'd like to request push access to > foreman-infra. At first I'd like to help more with the CI. > > +1 from my side. > Regards, > Ewoud Kohl van Wijngaarden > > -- > 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] Access to foreman-infra
Hello all, To get more involved in foreman infra I'd like to request push access to foreman-infra. At first I'd like to help more with the CI. Regards, Ewoud Kohl van Wijngaarden -- 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] Re: Database and Service Actions in RPM Post Scripts
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 wrote: > > > On Mon, Sep 25, 2017 at 9:30 AM, Lukas Zapletal 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 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 sub
Re: [foreman-dev] Re: Database and Service Actions in RPM Post Scripts
On Mon, Sep 25, 2017 at 9:30 AM, Lukas Zapletal 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 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...@googleg
