Re: Re: [foreman-dev] Proposal: Let's make notifications optional
On 12/20, Walden Raines wrote: > I also added an item to the Team UX backlog to make the notifications use > websockets (or similar) instead of the polling. The polling annoys me as > well. Definitely the way to go, I've been experimenting with ActionCable and it's not only cleaner (way less code, check out our polling code) but more efficient. https://github.com/dlobatog/foreman/tree/actioncable The biggest limitation is https://github.com/phusion/passenger/issues/1202 - which I'm able to circumvent with mod_proxy_wstunnel, http://anycable.io/ as Ohad mentioned on IRC the other day looks like a feasible suggestion (if a bit more involved) > > Cheers, > Walden > > On Wed, Dec 20, 2017 at 5:02 AM, Tomas Strachota <tstra...@redhat.com> > wrote: > > > On Wed, Dec 20, 2017 at 9:09 AM, Ohad Levy <ohadl...@gmail.com> wrote: > > > > > > > > > On Wed, Dec 20, 2017 at 10:07 AM, Lukas Zapletal <l...@redhat.com> > > wrote: > > >> > > >> Hello, > > >> > > >> while I agree that notifications is useful feature to our users, its > > >> one second polling mechanism is killing me during development, it > > >> makes watching logs or debugging sessions a nightmare. > > >> > > >> I propose an Administer - Setting option to completely turn it off - > > >> no notification bell icon, no polling. If there is someone who things > > >> users should not be given this option, let's make this an > > >> environmental variable. > > >> > > >> Opinions? > > > > > > 1. a Global setting, followed by a user setting sounds sane to me. > > > 2. do you know that there is a global env already? just run: > > > > > > NOTIFICATIONS_POLLING=100 foreman start > > > > Great, I didn't know that. > > > > Polling annoys me in development as well, but this env variable is > > enough for me. Thanks! > > > > > > > >> > > >> -- > > >> 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. > > > > -- > 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=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: Re: [foreman-dev] RFC Auto Refresh on ForemanTasks#Tasks Page
t;>>> > >>>>> > >>>>> -- > >>>>> 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. > >>>>> > >>>> > >>>> > >>>> > >>>> -- > >>>> Andrew Kofink > >>>> akof...@redhat.com > >>>> IRC: akofink > >>>> Software Engineer > >>>> Red Hat Satellite > >>>> > >>>> -- > >>>> 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. > >> > >> > >> -- > >> 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. -- Daniel Lobato Garcia @dLobatog blog.daniellobato.me daniellobato.me GPG: http://keys.gnupg.net/pks/lookup?op=get=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: Re: [foreman-dev] Nominating additional maintainers in foreman-core
On 12/06, Ewoud Kohl van Wijngaarden wrote: > On Wed, Dec 06, 2017 at 02:40:36PM +0200, Tomer Brisker wrote: > > Shimon Shtein - has 75 merged commits [1] and has taken part in the reviews > > of 64 merged commits[2]. > > +1 +1 > > > Michael Moll - has 71 merged commits [3] and has taken part in the reviews > > of 130 merged commits[4]. He is also already a long time maintainer of > > several of our other repos and has proven to be a responsible maintainer. > > +1 +1 > > -- > 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=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] Is it time to remove turbolinks?
On 12/06, Walden Raines wrote: > I am seeing more and more issues [1][2] around turbolinks and I'm wondering > if it's time to remove it from foreman. I have seen it recommended that > one shouldn't use the back button in foreman; I thought that request was > reserved for poorly written php sites that resubmit forms when the back > button is pressed, we're better than that! :) If someone suggests the back button shouldn't be used within foreman because that breaks something - it's our fault. I recall some problems in some pages like Products/Errata etc.. but haven't seen any in a whlie The request is used by Basecamp, GitHub, and modern Ruby applications, but honestly that's just an ad-hominem. (notice the blue bar when you click on a link in GitHub) > > Are the benefits of turbolinks worth the cost? Does anyone have any > metrics on the difference in page load times with and without > "turbo"links? Do the test, it's considerably faster to use it, I'm happy to provide metrics. In fact for cached pages it can easily be 100ms (/subnets, /settings, etc) https://www.speedshop.co/2015/05/27/100-ms-to-glass-with-rails-and-turbolinks.html In fact, there's room to make it faster (data-turbolinks-permanent) > > Any additional thoughts on its removal? Unless there are serious blockers or anything that cannot be done with Turbolinks that we need to do, I really oppose this. If you have another alternative that's not pushState that makes Foreman faster and is as easy to use, I'd be glad to hear it > > Cheers, > Walden > > [1] https://bugzilla.redhat.com/show_bug.cgi?id=1522740 > [2] http://projects.theforeman.org/issues/21480 > > -- > 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=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: Re: [foreman-dev] [RFC] Deprecate and move Github RFC repo content
On 11/15, Tomer Brisker wrote: > Since I already suggested this some months ago, obvious +1 from me :) > > On Wed, Nov 15, 2017 at 1:41 PM, Greg Sutcliffe <g...@emeraldreverie.org> > wrote: > > +1 to moving them to the Redmine wiki. The RFC repo was a good > > experiment but handled badly (at least some of the blame for that is on > > me). At this point I don't think it's possible to rescue it. > > > > On 15/11/17 10:52, Sean O'Keeffe wrote: > >> Without wanting to hijack this thread... I think this is actually one of > >> the areas Discourse can benefit us, generally as a community I think were > >> not very good at making a decision after a discussion. I think some of the > >> features it seems to provide (voting system) could help with that. > > > > Clearly I'm going to +1 that comment too ;) - the other really useful > > thing is the per-thread analytics you can get about views, top links, etc. > > > > Greg > > > > -- > > 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. If it helps, I think https://github.com/blog/2471-introducing-team-discussions looks also like a good tool for these kind of discussions, without any need for a moderator. The discussions are restricted to people in the GitHub team. > > > > -- > Have a nice day, > Tomer Brisker > 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. -- Daniel Lobato Garcia @dLobatog blog.daniellobato.me daniellobato.me GPG: http://keys.gnupg.net/pks/lookup?op=get=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: Re: [foreman-dev] Kanban tools and redmine
On 11/28, Ewoud Kohl van Wijngaarden wrote: > On Tue, Nov 28, 2017 at 04:29:01PM -0500, Walden Raines wrote: > > I really like the idea of a trello/kanboard like tool but I hate having to > > update tasks in multiple places. Another idea I had was to switch (back) > > to using GH issues and use GH projects [2] as well. > > Just going to jump on the GH projects. While I really like the idea, for me > they're too limiting since they're only within a single repo while a lot of > work involves multiple PRs in different repos. > > > [2] https://help.github.com/articles/about-project-boards/ Projects in GitHub are also per-team, https://github.com/orgs/theforeman/projects, which allows to track issues in multiple repos. I'm fine with anything, but as Lukas said previously, the less places we have to look at the better. BZ + GitHub would work for me, we would have to update our Redmine automation to BZ of course. > > -- > 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=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: Re: Re: [foreman-dev] Re: 1.15.4 - 1.16 RC.1 - 1.17 status
On 11/20, Ohad Levy wrote: > On Sun, Nov 19, 2017 at 10:35 PM, Ewoud Kohl van Wijngaarden < > ew...@kohlvanwijngaarden.nl> wrote: > > > On Sun, Nov 19, 2017 at 11:27:57AM +0200, Ohad Levy wrote: > > > >> > >> Can anyone shed some light on ETA for 1.16 GA? > >> > >> > > I should have given an update earlier. > > > > So far we've been wanting to include the foreman tasks as a service from > > core rather than from foreman-tasks. As always we want that change to first > > land in develop but we've been struggling with broken nightlies for quite > > some time. It loked like it was fixed since the builds started to pass > > aagin but we have no validation on the actual UI. Turns out that's broken > > and we have no automated testing for this. > > > > Would it be an option to ship 1.16 without dynflow service in the core or > > would that break things? > > > AFAIU - nothing uses it atm as we were uncertain if it can really be > used.. there is some code in core regarding that, so I'm not sure if that > matters... Daniel? It definitely can be used as proven by: https://github.com/theforeman/foreman/pull/4240 https://github.com/Katello/katello/pull/6750 https://github.com/Katello/katello/pull/6752 https://github.com/theforeman/foreman/pull/4717 Not having a separate service to run Dynflow doesn't have many implications now that nothing is using it. If foreman-tasks still ships the service to start/stop the dynflow executor, we're still fine (same as 1.15). Even without tasks, there's always a dynflow executor running with Foreman (https://github.com/theforeman/foreman/blob/1.16-stable/config/application.rb#L245) but this one cannot be stopped or started without restarting Passenger too. > > > > > > > -- > > 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=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: Re: [foreman-dev] Regular Foreman-core issue triage?
I do check Redmine issues everyday (http://projects.theforeman.org/projects/foreman/activity) If there are many, I restrict the search to just Foreman (with subprojects). Usually it doesn't take more than 30 minutes. I basically look for: - New issues: if they look critical or very easy I might work on a fix right away. There are few critical issues like that. - Ready for testing: if I'm interested I look at the PR. but at least I know about what was fixed - Closed: same, and also set the Release flag if it's not set I like the flow of visiting this Activity page every day to keep track of things, for me it's not a significant time investment & ROI is good, so -1 On 11/15, Greg Sutcliffe wrote: > On 15/11/17 07:42, Tomer Brisker wrote: > > One concern though is the amount of time it would take > > We could time-limit it to one hour, and start with "New" issues each > time, sorted by oldest first. That way anything we don't get to one week > would be present the next week. That's still better than we have today, > and as we improve we might get on top of it. > > Greg > > -- > 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=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: Re: [foreman-dev] Building a Rails 5.1 SCL
On 11/02, Ewoud Kohl van Wijngaarden wrote: > On Thu, Nov 02, 2017 at 11:24:26AM +0100, Daniel Lobato Garcia wrote: > > Just one question, my understanding is that you prefer to do this (SCL) > > because we are uncertain of the time/effort required for vendoring the > > gems/npm > > packages. Given that long-term we would have to keep up building SCLs > > (which if I’m not wrong are going to be less used from EL8 onward) and > > maintaining > > packages (which consumes a great deal of our time). > > My expectation is that vendorizing RPMs would cost a similar time as > building the SCL. Given separate packaging has a lot of benefits over > bundling[1]. > > Thinking about this, we currently don't check the licenses of bundled npm > modules in our existing packaging. It's possible we currently ship something > we're not legally allowed to ship but we simply don't know.o Problem is - it's pretty much impossible to make npm work with the rpm model. Dependencies are different between libraries such that this is common: A depends on C > 1.5 B depends on C = 1.0 Foreman depends on A and B If we don't bundle, there's no way to tell RPM to install C >= 1.5 and C = 1.0 at the same time (as far as I know). About the legality problem - I think we should start creating some script that parses all the dependencies we have and their licenses and make a summary, then detect any possible conflicts... > > With regards to EL8 I think you're hinting at the modularization effort > that's currently in Fedora. For those unaware: it's aimed to be a much > better version of SCLs. Better integrated in the system but also allow > easily producing containers. At the moment there's still little > documentation and we'll likely support EL7 for a while so at this point I'm > not planning much. What we do want to do is move from our own Koji instance > to COPR. That should be prepared for modularization. Developing the SCL in > COPR can be seen as a first step in this process. > > [1]: > https://fedoraproject.org/wiki/Bundled_Libraries?rd=Packaging:Bundled_Libraries#Why_Bundled_Libraries_are_a_problem > > > Parallel to this effort, do you think it’s worth moving forward with the > > vendorization of npm so that gems can follow suit? > > Personally I'd say gems shouldn't follow suit unless maintaining the SCL > proves too much work. In fact, the only reason I currently accept npm > vendorization is that we currently can't keep up with the changes. If we can > develop sufficient tooling I'd actually like to roll back npm vendorization > too when we can provide the same developer flexibility. As I said above - npm vendorization (at the level we do now with bundled-npm packages) isn't possible to roll back, at least to my knowledge > > -- > 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=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] Building a Rails 5.1 SCL
I agree with all of that, definitely something to do in a different repository. Just one question, my understanding is that you prefer to do this (SCL) because we are uncertain of the time/effort required for vendoring the gems/npm packages. Given that long-term we would have to keep up building SCLs (which if I’m not wrong are going to be less used from EL8 onward) and maintaining packages (which consumes a great deal of our time). Parallel to this effort, do you think it’s worth moving forward with the vendorization of npm so that gems can follow suit? -- Daniel Lobato Garcia @dLobatog blog.daniellobato.me daniellobato.me GPG: http://keys.gnupg.net/pks/lookup?op=get=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] Katello Packaging Migration to Foreman Packaging Plan Proposal
On 10/20, Eric D Helms wrote: > All, > > One of the items on the Roadmap I've sent out is centralizing packaging > into a single repository. The last time I tried this I attempted to go > whole hog migrating all things all at once. In order to make this more > approachable, and to encourage reviews, I would like to follow the > following plan in this rough order for nightlies only: > > 1) Move comps to foreman-packaging and update mash scripts > 2) copy releasers and tito.props to foreman-packaging for katello > repositories > 3) Move packages 1 by 1 to foreman-packaging starting leaving nightly RPMs > (rubygem-katello, hammer_cli_katello, and katello-installer) for last. This > will involve a PR to foreman-packaging and PR to katello-packaging adding > to the former and removing from the latter. > 4) Update katello-packaging README to indicate deperecation > > I am sending this plan along to gather feedback, find holes in the plan and > to get approval/disapproval from the community in taking this step. > > My plan would be to begin this migration towards the end of next week. I think it sounds great, ping me when you submit these PRs if you want someone to take a look. Would koji be affected by this? For example, new katello packages in the foreman-packaging repository would need to be in foreman tags or still the katello tags? If the latter, any reason why it would not make sense to change that to treat it like any other plugin? > > -- > 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. -- Daniel Lobato Garcia @dLobatog blog.daniellobato.me daniellobato.me GPG: http://keys.gnupg.net/pks/lookup?op=get=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: Re: [foreman-dev] unscheduled 1.15.5
Similarly I think the installer is meant to be updated to work with 7.4 - https://github.com/theforeman/foreman-installer/commit/f07567ee06742155a079f076823c6a3bfbc38120 On 10/03, Lukas Zapletal wrote: > Ondra, > > what fixes are you talking about? Is this the container selinux > installation issue? > > If there is a chance of sneaking in > > https://github.com/theforeman/foreman/pull/4555 > > if this is merged in the deadline, that would be great. Pretty > important provisioning DHCP issue there. > > LZ > > On Tue, Oct 3, 2017 at 10:35 AM, Ondrej Prazak <opra...@redhat.com> wrote: > > Hi, > > there will be a 1.15.5 Foreman release. Main motivation behind this is to > > get SELinux fixes into 1.15, but if you are aware of any critical fix that > > should go in there, let me know. > > > > Have a nice day, > > Ondrej Prazak > > > > -- > > 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. -- Daniel Lobato Garcia @dLobatog blog.daniellobato.me daniellobato.me GPG: http://keys.gnupg.net/pks/lookup?op=get=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: Re: [foreman-dev] Release process & permissions
On 09/28, Ewoud Kohl van Wijngaarden wrote: > While I agree we should automate a lot, I agree with Eric. Doing a Foreman > release should involve a human to keep the end-to-end quality. Just giving > permissions is wrong. > > For example in Foreman 1.15.5 the installer was tagged and released before I > could push in my changes. That communication failure might have been partly > my fault but IMHO the job of a release manager is to communicate with all > the maintainers if everything is in place for a release. > > Now you state it as a problem that you need a lot of people, but you need to > communicate with them anyway. Yes, the tagging and releasing should be > scripted but planning a release will require humans. > > Like Eric I think we should start by documenting. Right now it's a huge > black box for most people, let's start there. The process is pretty well documented, http://projects.theforeman.org/projects/foreman/wiki/Release_Process contains everything that has to be done step by step > > On Wed, Sep 27, 2017 at 09:19:10PM -0400, Eric D Helms wrote: > > There are two considerations that I'd like to put forth as we think about > > this: > > > > 1) Instead of adding jobs, we re-think and re-write the release job in > > Pipeline syntax similar to my starter here -- > > https://github.com/theforeman/foreman-infra/pull/323 > > 2) We don't automate all the things as there are some tasks that should be > > done by a human. The tedious, repetitive bits we should automate. The > > aspects that require some human foresight, approval or double checking of > > we should either require a releaser to "yes" to a job over or to perform > > semi-automated in that the user uses tooling but ultimately has input. For > > example, cherry picking should be 90% automated but 10% human input to > > ensure nothing seems off since our issue-to-change is not flawless. > > > > While we have some automation already in place, from my experience I would > > recommend one of the following approaches. > > > > 1) create a flow chart of every action that has to happen using something > > like plantuml with parallel actions where possible > > 2) Create a new release job, starting either from the beginning or the end > > of the process and add each next step to it > > > > > > Eric > > > > On Wed, Sep 27, 2017 at 10:46 AM, Daniel Lobato Garcia <elobat...@gmail.com> > > wrote: > > > > > Hi devs, > > > > > > After a few releases, and now that I'm trying to help someone else to > > > take over in case it's needed, I found a roadblock. > > > > > > Whoever is doing the release, needs to have **many** permissions. > > > > > > Otherwise, it doesn't make much sense for a person to take over release > > > responsibilities. For example, if Ondrej has to do 1.15.5, he would need > > > the following permissions (see at the end of the email). > > > > > > Of course there are alternatives: > > > > > > 1 is to have the release nanny be supervised by people who have 'earned' > > > these permissions. This is a bad idea because some of the tasks just > > > cannot be 'supervised'. The nanny would have to ask someone to tag > > > repositories, modify jenkins jobs, upload GPG signatures, post to the > > > mailing list, tag new builds in Koji... > > > > > > 2 is to extend http://ci.theforeman.org/view/Release%20pipeline/ and > > > make it a real pipeline from 0 to release completed. At this moment, > > > releases that are not the first RC1 are mostly automated by > > > https://github.com/dlobatog/foreman_release and > > > https://github.com/theforeman/tool_belt. > > > > > > My proposal is to go forward with 2. Give Jenkins permissions to do all > > > of the actions needed, and whoever is the release nanny, ideally only > > > has to make sure all of the steps are moving forward. If something > > > breaks, figure out how to fix it for the next release. > > > > > > This would mean making a few extra jobs before and after the current > > > release pipeline. In my opinion, it's the way to go to ensure anyone can > > > take over this responsibility. > > > > > > At this moment, we are in a situation where only people who > > > mostly have permissions everywhere can successfully do a release without > > > asking many people for favors. > > > > > > Personally if we complete this, I see it as a big win as it would dwarf > > > our bus factor for release managers & all
[foreman-dev] Release process & permissions
Hi devs, After a few releases, and now that I'm trying to help someone else to take over in case it's needed, I found a roadblock. Whoever is doing the release, needs to have **many** permissions. Otherwise, it doesn't make much sense for a person to take over release responsibilities. For example, if Ondrej has to do 1.15.5, he would need the following permissions (see at the end of the email). Of course there are alternatives: 1 is to have the release nanny be supervised by people who have 'earned' these permissions. This is a bad idea because some of the tasks just cannot be 'supervised'. The nanny would have to ask someone to tag repositories, modify jenkins jobs, upload GPG signatures, post to the mailing list, tag new builds in Koji... 2 is to extend http://ci.theforeman.org/view/Release%20pipeline/ and make it a real pipeline from 0 to release completed. At this moment, releases that are not the first RC1 are mostly automated by https://github.com/dlobatog/foreman_release and https://github.com/theforeman/tool_belt. My proposal is to go forward with 2. Give Jenkins permissions to do all of the actions needed, and whoever is the release nanny, ideally only has to make sure all of the steps are moving forward. If something breaks, figure out how to fix it for the next release. This would mean making a few extra jobs before and after the current release pipeline. In my opinion, it's the way to go to ensure anyone can take over this responsibility. At this moment, we are in a situation where only people who mostly have permissions everywhere can successfully do a release without asking many people for favors. Personally if we complete this, I see it as a big win as it would dwarf our bus factor for release managers & allow us to release at any pace we desire (right now it's slow because we can't truly release things from one day to the next due to the work involved). Thoughts? Here's the list of permissions: Github: - Push in foreman, foreman-selinux, foreman-installer, smart-proxy, foreman-infra, foreman-packaging Transifex - - Allow to change the auto-update URL to point to latest -stable branch Redmine - - Create new "Found in Release" version Jenkins - - Modify jobs - Run jobs Koji - - Create tags - SSH access to update the mash scripts - Create packages - Tag builds Repository servers - ssh in deb.theforeman.org - ssh in yum.theforeman.org Announcements - - Post to foreman-announce - Merge access in theforeman.org - Change IRC message - Publish in Twitter, G+ ------- -- Daniel Lobato Garcia @dLobatog blog.daniellobato.me daniellobato.me GPG: http://keys.gnupg.net/pks/lookup?op=get=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: 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 <elobat...@gmail.com> > 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=0x7A92D6DD38D6DE30 > > > Keybase: https://keybase.io/elobato > > > > > > > > -- > > Daniel Lobato Garcia > > > > @dLobatog > > blog.daniellobato.me > > daniellobato.me > > > > GPG: http://keys.gnupg.net/pks/lookup?op=get=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=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: Re: [foreman-dev] Re: Bundler is unable to solve deps for fresh checkout
Eventually I changed the release_tarballs to Ruby 2.4 and it went through. On 09/21, Lukas Zapletal wrote: > I just upgraded, but I think putting Gemfile.lock (even an older one > from 1.14 stable branch) could work. Weird really. > > On Wed, Sep 20, 2017 at 6:57 PM, Daniel Lobato <elobat...@gmail.com> wrote: > > http://ci.theforeman.org/view/Release%20pipeline/job/release_tarballs > > > > seems to have suffered from this today (Monday 1.15.4 tarballs were built > > just fine) > > > > Did you find any other way to fix this? Switching to 2.4 could be an option, > > probably > > putting a Gemfile.lock on every tagged release isn't a bad idea either. > > > > On Thursday, September 14, 2017 at 3:13:29 PM UTC+2, Lukas Zapletal wrote: > >> > >> Hey, > >> > >> when I do fresh foreman clone with clean Ruby version (tried 2.0.0 and > >> 2.4.1), bundle install is not able to resolve dependencies and loops > >> forever. I am using latest stable bundler, tried also pre1 version. > >> > >> Can someone confirm and provide a workaround? I think copying > >> Gemfile.lock from someone else should do it. Can someone attach a > >> pastebin me one? I currently have my workstation down (CPU in RMA) and > >> got clean setup. > >> > >> If this is confirmed, it is quite an issue for newcomers. The second > >> command new developer is asked to execute fails hard. Any suggestions? > >> > >> LZ > >> > >> -- > >> 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. > > > > -- > 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. -- Daniel Lobato Garcia @dLobatog blog.daniellobato.me daniellobato.me GPG: http://keys.gnupg.net/pks/lookup?op=get=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
[foreman-dev] Re: 1.15.4 - 1.16 RC.1 - 1.17 status
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. > > - 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=0x7A92D6DD38D6DE30 > Keybase: https://keybase.io/elobato -- Daniel Lobato Garcia @dLobatog blog.daniellobato.me daniellobato.me GPG: http://keys.gnupg.net/pks/lookup?op=get=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
[foreman-dev] 1.15.4 - 1.16 RC.1 - 1.17 status
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. - 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 - 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. 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=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] Permissions cleanup
On 09/11, Greg Sutcliffe wrote: > Hi all, > > In the context of the plugins-bus-factor discussion, etc, it occurred > to me that we still have a lot of people with access who aren't really > active any more - this can make it hard to see where action is needed. > > We've never really done a permissions cleanup before, so I thought it > might be time. Here's a list of people / things I found that I'd like > to fix. I've tried to keep this to core and related stuff, as plugins > are free to handle their own affairs, to a large extent (also the list > would be huge). In vaguely alphabetical order then: > > * Amos Benari: > * Github: no commits in over a year, remove commit on > - community-templates > - foreman > - rfcs > - smart-proxy > - theforeman.org > * Brian Gupta: > * Github: no commits in over a year, remove commit on > - community-templates > - foreman > - foreman-selinux > - hammer_cli > - rfcs > - smart-proxy > * Remove Admin level on Redmine, last login, Apr 2015 > * Brandorr (Brian's org) also has an SSH key for the infra. Since we > still host some stuff with them, let's leave that for now. > * Dominic Cleal: > * GitHub - Owner status: > While commit access lasts for a year, Dom has not been seen on > the mailing lists, Redmine, or Github since May/June (with the > exception of a single commit in July). In the context of having > active owners that we discussed previously, I propose we demote > him from owner level. > * Joseph Magen (istratrade): > * Github: no commits in over a year, remove commit on > - community-templates > - foreman > - foreman-selinux > - rfcs > - smart-proxy > * Corey Osman (logicminds): > * Github: no commits in over a year, remove commit on > - community-templates > - foreman > - foreman-selinux > - rfcs > - smart-proxy > * Sam Kottler: > * Github: no commits in over a year, remove commit on > - foreman-installer > - foreman-packaging > - foreman-infra > - community-templates > - kafo > - foreman-bats > - redmine (our fork) > - prprocessor > - jenkins-job-builder (our fork) > * Remove SSH key on infra > > There's probably more, but that's a first pass. Thoughts? +1 to all -- Daniel Lobato Garcia @dLobatog blog.daniellobato.me daniellobato.me GPG: http://keys.gnupg.net/pks/lookup?op=get=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] Foreman core nightly is currently broken
This commit has been reverted from 1.15-stable and 1.16-stable On 09/05, Ohad Levy wrote: > Hi, > > Following up on the recent thread about merging PR's, just to let you know > that develop branch is currently broken due to [1] and PR to fix it as > already available at [2] and hopefully it will be back to usual business > within the next few hours. > > Please don't merge any JS related commits until the issue is resolved. > > thanks, > Ohad > > [1] https://github.com/theforeman/foreman/pull/4792 > [2] https://github.com/theforeman/foreman/pull/4809 > > -- > 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=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] What is the process to get new resources added to transifex?
On 08/30, Bryan Kearney wrote: > I would like to see katello and katello-bastion added to transifex. Once > that is done, I can ask folks to add string syncing to the build process. I > can translate, but I dont have access to add resources. > > -- bk I think you would need to gather the .po files for the projects you want to add, then upload them to https://www.transifex.com/foreman/foreman/content/ The administrators at the moment according to https://www.transifex.com/foreman/public/ are: lzap, ohadlevy, domcleal mhulan, Claer. They could add the .po files or add you as another aministrator. > > -- > 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=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] Test failures and merging PRs
On 08/28, Marek Hulán wrote: > Hello devs, > > since there was a discussion on foreman-dev IRC channel recently about merging > PRs in Foreman core even if there's some build failed, I talked to few people > and decided to describe here what I think is current way of how it works. I'm > also attaching one suggestion at the end that came up after the discussion. > > Please, add questions, comments or simple +1 so we all know whether we're on > the same page. > > Core PR runs 7 checks - foreman, katello, codeclimate, hound, prprocessor, > upgrade, continuous-integration/travis-ci/pr. In ideal case they are all green > and after review, the PR is merged. There are several cases where we can merge > even if the PR is red. > > 1) codeclimate is red > > This can be ignored, we never agreed on using this as a hard metric for the > PR. The motivation to introduce it was mainly to save some time to reviewer. > We don't have to run it manually to get indications whether there's something > introducing a big complexity [1]. From my experience it sometimes leads to > worse code, since author splits the logic into more methods to lower e.g. > cyclomatic complexity but it should be judged separately in every case. It should be taken care of whenever possible. Most of the times it's certainly right and notices typical problems like stupidly long classes, duplication, etc.. https://codeclimate.com/github/rails/rails itself enforces it unless a maintainer vets the PR. (ad hominem fallacy, I know) > > 2) foreman is red > > This can happen because of intermittent tests failures. If the PR is clearly > not causing new ones and commiter is aware of this error, the PR is merged > with message like "test unrelated" comments. If we are not sure, we retrigger > the run, > > If Foreman develop branch is broken, we need to merge the PR to fix it so this > is another exception. Usually we trigger the jenkins job manually first to see > that the PR fixes the issue. Makes sense to me, generally. The only con I've seen since I started contributing is that few people care to fix intermittent tests, which caused the job to be red for weeks at times > > 3) katello is red > > If katello becomes red only for this PR, we analyze what causes it. Usually it > means that we change some internal things that have impact on Katello. In such > case, we're doing our best to send a fixing PR to Katello or we ping someone > with better knowledge in this area. We don't merge the PR until it's resolved, > then usually we merge both parts at the same time. This sounds good. Ideally the contributor sends the patch to Katello, please. > > If it turns out there are more PRs that are failing with same errors, we merge > PRs if we're sure they don't introduce new Katello failures. At this time, > we're not blocking merges until Katello is green again. (*) here the > suggestion applies I don't think this is fair. If the Katello job is red, it's our responsibility to bring it back to green. When the causes for the job to be red are unknown, merging more stuff in Foreman will certainly NOT make it easier to understand them. In fact it may just aggravate the problem. So I would say *no* - at least on PRs I'm reviewing, I'm not merging if Katello is red. > > 4) upgrade is red > > this is very similar to katello job, if there's some issue in upgrade, we > should not merge the PR. I remember though, there was a time when we knew the > job is broken which fall under "known to be broken" category. Same as 3. > > 5) There's no 5, all the rest must be green. Sometimes hound service does not > respond and remains in "running" state, then it's retriggered by the reviewer. > prprocessor and travis must always be happy. > > Now the promised suggestion. When we see katello/upgrade job is broken on > multiple PRs, the first reviewer who spots it should notify the rest of > developers about "from now on, we ignore tests XY". The ideal channel seems to > be this list. This helps Katello devs to find out when it started, what were > the commits that first induced it. Sorry, I don't think this is a better idea than the current (unspoken) approach to block PRs until Katello is merged. It's good you started this thread, as clearly people have different assumptions on this topic as we didn't talk about it much. If we reach to some conclusions, updating https://theforeman.org/handbook.html with them would be good to have some reference set in stone (or in bytes (: ). > > [1] https://groups.google.com/forum/#!topic/foreman-dev/p7ESagXwNwk > > Thanks for comments > > -- > Marek > > -- > You received this message because you are subscribed to the Google Groups > "foreman-dev" group. > To unsubscribe
Re: [foreman-dev] [Infra] Openshift V2 Sunsetting: Redmine and Prprocessor
On 08/25, Eric D Helms wrote: > All, > > I wanted to make everyone aware that its been announced that Openshift V2 > will be closing down on September 30th. We currently run our Redmine and > Prprocessor on this infrastructure. This means that we will either need to > find new homes for these or migrate them to Openshift V3. More details will > follow as we work toward a solution. If anyone has concerns, or different > suggestions feel free to share them here. Isn't theforeman.org also running on OpenShift v2? > > -- > 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. -- Daniel Lobato Garcia @dLobatog blog.daniellobato.me daniellobato.me GPG: http://keys.gnupg.net/pks/lookup?op=get=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
[foreman-dev] Foreman 1.16 branching update
Hi everyone, As you probably have noticed, 1.16 release candidates have not been released on time. This happened because of many things, particularly that we had broken nightlies for around 2 weeks when we were supposed to branch (https://groups.google.com/forum/?fromgroups#!topic/foreman-dev/u1IhzomISIO). That was solved, but now we're experiencing intermittent failures in the Katello test matrix. Additionally EPEL removing http-parser-devel broke nightlies https://github.com/theforeman/foreman-packaging/pull/1772 and fog 1.41 needs to be updated too https://github.com/theforeman/foreman-packaging/pull/1775 Other than that, I am missing permissions to do steps 2 and 3 on the Koji servers (section Package build systems in http://projects.theforeman.org/projects/foreman/wiki/Release_Process). The rest of the process is already done (copying tags, cloning Debian repos using freight, updating jobs, etc..) There is no dynflow executor deployed with 1.16 or nightlies yet, so https://github.com/theforeman/puppet-foreman/pull/530 https://github.com/theforeman/foreman-packaging/pull/1549 would have to get in before the first RC release. Branching could happen without these being merged though. If you know other issues that are bound to happen if some PR is not merged by the RC, please raise it in this thread to ensure we pay attention to it. Best regards, sorry for the delay - it's all in the name of stability and a solid release :) -- Daniel Lobato Garcia @dLobatog blog.daniellobato.me daniellobato.me GPG: http://keys.gnupg.net/pks/lookup?op=get=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] Plugin gems with a single author
On 08/18, Greg Sutcliffe wrote: > Hi all, > > As per the newly-merged plugin policy, I've taken a quick pass over all > the gems listed in the RPM packaging (which is more comprehensive than > the Deb packaging), grepped for "foreman" and "proxy", and then used > the Rubygems API to filter for gems with a single author. > > This list was pretty long, so for brevity, I've also removed things > which are (as far as I know) not in active use at the moment (we can > always revisit that and run this again later). > > Below is the list of gems that need an additional maintainer, grouped > by owner. Could these people please add a second author to the gem, > just in case? If you've got someone in mind just go for it, if you want > help deciding who show be added, feel free to reply here. > > Daniel Lobato Garcia: > - foreman_ansible > - foreman_ansible_core Added agx and mhulan for these 2 > - foreman_azure Added ehelms (2nd most prolific contributor) > - foreman_cockpit Added thomasmckay (2nd most prolific contributor with a rubygems account) > > Dominic Cleal: > - foreman_bootdisk > - foreman_hooks > - foreman_setup > - hammer_cli_foreman_bootdisk > - smart_proxy_dns_route53 > > Ewoud Kohl van Wijngaarden: > - smart_proxy_dns_powerdns > > Greg Sutcliffe: > - foreman_column_view > - foreman_default_hostgroup > > Marek Hulan: > - foreman_chef > - smart_proxy_chef > > Lukas Zapletal: > - smart_proxy_discovery_image > > Ohad Levy: > - foreman_memcache > > Since I'm on the list, who wants adding to my plugins? :) > > Regards > Greg > -- > IRC / Twitter: @gwmngilfen > Diaspora: gwmngil...@joindiaspora.com > > -- > 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=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: Re: [foreman-dev] Proposal/Request - Foreman Ansible plugin - Dynamic inventory parameters definition
On 08/21, Pietro Gabelli wrote:
> Maybe this will help you: is definitely possibile to use the varaibles
> defined in Foreman in an Ansible Playbook: by definig some parameters in
> Foreman on the host, and then executing a role with something like: *-
> debug: msg="Here all the host variables {{ hostvars }}" *all the host's
> variables are shown.
> Organizing them with a JSON formatter like
> *https://jsonformatter.curiousconcept.com/* and then searching for the
> variable name, it can be see that all the host parameters are inside
> foreman_params.
> Therefore, they can be accessed inside a playbook with something like *{{
> foreman_params['my_parameter'] }}* .
>
> With that, I have created some roles to try to extend the functionalities
> of the Ansible Plugin. Using parameters and by writing roles that use those
> parameters, I can write a list of tasks to execute on a host, launch a
> single playbook on an host, using options like --syntax-check; I can also
> import the roles inside a git repository specifying the user's credentials,
> import a given role from ansible-galaxy.
> The sky is the limit with the freedom of user-defined parameters!
>
> So far, my host has 10 variables, with pretty random names, that has been
> used successfully in the roles I've created (they don't have to start with
> "ansible_" to be used in a playbook): the only thing is that you have to
> launch the role from the plugin inside Foreman, using Anbile from the
> command line in the host doesn't work.
>
> An other thing: is that if the parameter has some of the YAML special
> chars, to make it work you can wrap the entire value with something like *{%
> raw %}* *var_value* *{% endraw %}*: otherwise it can't be used and there
> will be issues even with roles that use other parameters.
>
> I'm sorry if this post is inappropriate: if you need, feel free to remove
> it.
> I'm finishing a 2-months internship that had the objective to integrate
> Ansible with Foreman and Katello using the roles, so this was part of the
> work I've done.
That sounds interesting, if you feel like publishing your experience in
the Foreman blog https://theforeman.org/blog/ ,
https://github.com/theforeman/theforeman.org/ is all open ;)
>
> Thank you for your work, I look forward to see the next Foreman Community
> Demo.
> Best
> Pietro Gabelli
>
> On Monday, July 17, 2017 at 2:54:30 PM UTC+2, Daniel Lobato wrote:
> >
> > On 07/14, juraj@gmail.com wrote:
> > > Hi,
> > >
> > > first of all, I'd like to thank you for the great work you've done so
> > far.
> > > I really admire all of you guys.
> > > My programming skills are not so good so I'll only lend my hand in
> > > proposing an idea or two that might be useful.
> > >
> > > Before I run Ansible role directly I can specify certain connection
> > > parameters in an Ansible inventory file.
> > > As you know the same option is available in the Foreman GUI interface
> > via
> > > parameters (Global parameters, Host group parameters etc.).
> > > However, there is one limitation and that is the list of parameters
> > > administrators can specify is limited. To get an idea which parameters
> > are
> > > available
> > > one can take a look in the following ruby scripts
> > >
> > >
> > /opt/theforeman/tfm/root/usr/share/gems/gems/foreman_ansible-1.4.5/app/services/foreman_ansible/inventory_creator.rb
> >
> > > and
> > >
> > /opt/theforeman/tfm/root/usr/share/gems/gems/foreman_ansible-1.4.5/app/models/setting/ansible.rb
> >
> > > .
> > >
> > > The problem arise when somebody needs a parameter that is not listed
> > there.
> > > Okay, you can edit both above mentioned scripts and then restart
> > Foreman,
> > > but every time the official update is applied, you have to add all
> > > necessary code changes again. This sucks and I believe everyone agrees
> > with
> > > me.
> > >
> > > So the idea I'd suggest is that, let administrators define what
> > parameter
> > > they need/want without hard-coding into Foreman Ansible plugin ruby
> > > scripts, OR
> > > make them hard-coded but the list of available parameter must be
> > complete.
> > >
> > > What do you think?
> >
> > I think it makes a lot of sense and at this point it's an easier thing
> > to implement than having to add a new parameter every time someone
> > requests it (or Ansible releases something new). I would expect
> > something like that for Foreman-Ansible 1.5 or 1.6
> >
>
Re: Re: [foreman-dev] Proposal/Request - Foreman Ansible plugin - Dynamic inventory parameters definition
On 07/17, Daniel Lobato Garcia wrote: > On 07/14, juraj.fun...@gmail.com wrote: > > Hi, > > > > first of all, I'd like to thank you for the great work you've done so far. > > I really admire all of you guys. > > My programming skills are not so good so I'll only lend my hand in > > proposing an idea or two that might be useful. > > > > Before I run Ansible role directly I can specify certain connection > > parameters in an Ansible inventory file. > > As you know the same option is available in the Foreman GUI interface via > > parameters (Global parameters, Host group parameters etc.). > > However, there is one limitation and that is the list of parameters > > administrators can specify is limited. To get an idea which parameters are > > available > > one can take a look in the following ruby scripts > > > > /opt/theforeman/tfm/root/usr/share/gems/gems/foreman_ansible-1.4.5/app/services/foreman_ansible/inventory_creator.rb > > and > > /opt/theforeman/tfm/root/usr/share/gems/gems/foreman_ansible-1.4.5/app/models/setting/ansible.rb > > . > > > > The problem arise when somebody needs a parameter that is not listed there. > > Okay, you can edit both above mentioned scripts and then restart Foreman, > > but every time the official update is applied, you have to add all > > necessary code changes again. This sucks and I believe everyone agrees with > > me. > > > > So the idea I'd suggest is that, let administrators define what parameter > > they need/want without hard-coding into Foreman Ansible plugin ruby > > scripts, OR > > make them hard-coded but the list of available parameter must be complete. > > > > What do you think? > > I think it makes a lot of sense and at this point it's an easier thing > to implement than having to add a new parameter every time someone > requests it (or Ansible releases something new). I would expect > something like that for Foreman-Ansible 1.5 or 1.6 For the record, the change was already merged in https://github.com/theforeman/foreman_ansible/pull/95/files so next release will have this > > > > > > > > > > > -- > > 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=0x7A92D6DD38D6DE30 > Keybase: https://keybase.io/elobato -- Daniel Lobato Garcia @dLobatog blog.daniellobato.me daniellobato.me GPG: http://keys.gnupg.net/pks/lookup?op=get=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
[foreman-dev] State of Nightlies
Hi devs, nightlies have been stalled for 20 days (http://ci.theforeman.org/job/release_nightly_test_rpm/lastStableBuild/) which causes delays on releasing 1.16. We fixed most of the dependency errors we had as you can see in the commit history (https://github.com/theforeman/foreman-packaging/commits/rpm/develop) At the moment we are stuck on packaging Foreman itself. For some reason one of the dependencies (nodejs-react) cannot find one if its subdependencies (object-assign). Here is the error log: http://koji.katello.org/kojifiles/work/tasks//1/build.log nodejs-react builds fine and object_assign is in the node_modules directory. The current PR trying to build Foreman: https://github.com/theforeman/foreman-packaging/pull/1739 If you have found this error or you can reproduce it building locally that would help. Thanks! -- Daniel Lobato Garcia @dLobatog blog.daniellobato.me daniellobato.me GPG: http://keys.gnupg.net/pks/lookup?op=get=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] Taking over plugins - do we need a policy?
On 07/18, Greg Sutcliffe wrote: > Hi all, > > I've been thinking for a while about plugins, and how to continue them > when original authors move on. It's only natural that developers will > come and go, so we need to think about how to deal with this. We've got > a few examples of this now, and have had others in the past. > > 1) I'm playing with Salt in my spare time at the moment, with a view to > (maybe) taking on the foreman_salt plugin, since Stephen is no longer > working on it. However, it's only chance that I know this fact - > there's no easy way for an author to mark a plugin as "orphaned". > > 2) Some plugins are awaiting changes but the author hasn't responded > (yet!). Foreman_bootdisk has some open PRs at the moment that fall into > this category (PRs 42, 43 for example), and default_hostgroup has pen > issues (oops!). Presumably we need a way to ping authors and find out > if they're just AFK or have stepped away from the plugin entirely. > > 3) Some plugins are definitely abandoned. I recall Chris Pisano taking > over the foreman_banner plugin last year and struggling to get in touch > with the original author at all. > > For context, Fedora does have a policy for this that makes some sense: > > https://fedoraproject.org/wiki/Policy_for_nonresponsive_package_maintai > ners > > That's quite heavy, but some of the points make sense. So, do we need > to add something to our docs about this. My gut feeling is: > > * Yes, we do > * Only applies to plugins in "theforeman" GitHub repo > * We need to add extra maintainers to the Rubygems *before* the author > leaves - Chris had a real issue here. This could be a requirement of > getting aplugin packaged, for example. +1 to this, I am stuck with foreman-docker where I want to give publish access to Bastilian but I can't > * We need to allow authors to "abandon" a plugin clearly (something > like how the Arch User Repository does it maybe?) I think marking this in a GitHub issue, README or somewhere like that would be enough, not sure if we need anything more formal than that (there are 1000s of packages in Fedora, only a few 10s of plugins?) > > Thoughts? > Greg > > -- > 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=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
[foreman-dev] 1.16 branching in approximately 2 weeks
As per http://projects.theforeman.org/projects/foreman/wiki/Foreman_116_Schedule, 1.16 is due to be branched soon, in 2 weeks approximately. Please help to make develop more stable during this process, be it through thorough testing, bugfixing or improving documentation. Help with updating the manual would be appreciated, see the list of tasks in: - https://github.com/theforeman/theforeman.org/issues/903 - The tracker does NOT have any 1.16 specifics set yet, please add any new feature or change you think that is worth documenting for 1.16 Some translations are nearing 100% completion, we welcome contributions that help finishing them for the next release: - https://www.transifex.com/foreman/foreman/foreman/ If you have any critical fixes that you think should be included in 1.16 in any of the core projects, please reply to this read to raise attention over them. Maintainers feel free to set the 1.16 label to any PR of that nature. Best, -- Daniel Lobato Garcia @dLobatog blog.daniellobato.me daniellobato.me GPG: http://keys.gnupg.net/pks/lookup?op=get=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] Re: Plugins configuration managment platform
On 06/29, Fairouz el ouazi wrote: > Hi, thank for your answer , my platform can communicate over REST API . > you said that it would be quite easy to develop a plugin for my cfgmgmt . > Can you give me a point from where to start . or documentation . Here are some docs on how to write your own plugin: https://theforeman.org/plugins/#3.WritingYourOwn For the use case you're asking about, I would recommend looking into the commit history of similar projects, namely: https://github.com/theforeman/foreman_chef https://github.com/theforeman/foreman_ansible https://github.com/theforeman/foreman_salt/ > > Le mercredi 28 juin 2017 11:50:40 UTC+2, Fairouz el ouazi a écrit : > > > > Hi everyone , > > > > I'm a beginner in using foreman ,So before in take the adventure i > > want to know if the fact that it exists a plugin for managing chef is there > > any chance to develop a new one that will manage my own platform X > > (PLatform that manage IOT devices ) . So at place of having chef client i > > will have foreman dealing with the devices of my X platform . ??? > > > > I really need your help or some ideas or if anyone has face the same > > uses cases ? > > > > > > -- > 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=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: Re: [foreman-dev] Nomination for an additional GitHub org owner
On 06/29, Tomer Brisker wrote: > Well, how about our fearless community leader? > Makes sense to me that managing the community includes the github repos > when needed - adding maintainers, migrating repos etc. > I nominate Greg Sutcliffe to be another owner of the git org as he is > available in European times. > Greg has been an active member, contributor and maintainer for quite a few > years now and should have no problem helping out with these tasks. > +1 too. (also to Eric's ownership, there were just too many +1s I don't think mine would've made any difference) > > On Mon, Jun 26, 2017 at 4:41 PM, Greg Sutcliffe <greg.sutcli...@gmail.com> > wrote: > > > On Mon, 2017-06-26 at 10:25 +0300, Tomer Brisker wrote: > > > +1 to adding Eric, although that won't solve the issue of Ohad and > > > Dominic being busy and having no owner available on this side of the > > > globe. > > > > That's fair, do you want to start a new nomination thread to address > > that? :P > > > > Greg > > > > -- > > 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. > > > > > > -- > Have a nice day, > Tomer Brisker > 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. -- Daniel Lobato Garcia @dLobatog blog.daniellobato.me daniellobato.me GPG: http://keys.gnupg.net/pks/lookup?op=get=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] Re: Revert removal of @host.params for host_param
Right now 1.15 is released. I decided not to document the deprecation as the consensus seems to maintain both ways of addressing this. The deprecations are still going to show up in the logs, so I suggest someone submits a PR to remove the deprecations and cherry-pick it for 1.15.1 2017年4月20日木曜日 10時19分19秒 UTC+9 Andrew Schofield: > > At the very least support both. This is a point release and this is a > pretty major change for a non-major release. > > As per the comment from Ewoud the bulk of people who will use this use it > in ERB and templates. The templates being probably the easiest to 'fix'. > Personally, keeping this permanently and proxying to me seems like the > right thing to do. This functionality has existed for years and is very > heavily documented all over the place. > > On Wednesday, April 19, 2017 at 12:39:40 PM UTC-4, Greg Sutcliffe wrote: >> >> On Wed, 2017-04-19 at 14:10 +0300, Tomer Brisker wrote: >> > Since it seems there wasn't an agreement on reverting this made in >> > time for 1.15, I'd say we should support both for now and reconsider >> > in the future pending a rewrite of the template engine using a proxy >> > object as we discussed. >> >> +1, supporting both seems like the way forward. >> >> Greg >> > -- 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: 1.15.0 release status
Thanks - all packages are out now, freight cache needs to be updated by someone with access to deb.theforeman.org, see the steps in: http://projects.theforeman.org/projects/foreman/wiki/Release_Process#Completion-tasks Similarly, those who have permissions please update Twitter, IRC and Google+ , I've just posted the announcement to foreman-users On Thu, May 11, 2017 at 4:12 PM, Dominic Cleal <domi...@cleal.org> wrote: > On 11/05/17 02:16, Daniel Lobato wrote: >> Thanks, it seems like either I don't understand the combination filter >> or it didn't work >> (https://github.com/theforeman/foreman-infra/blob/cb03c58b7b2bf3b5c61a125e4c32841a07a6a274/puppet/modules/jenkins_job_builder/files/theforeman.org/yaml/jobs/release_test.yaml#L33) >> >> combination-filter: 'os == "el7" || os == "f24" || os == "jessie" || >> (os == "stretch" && version != "1.14" && version != "1.15") || os == >> "trusty" || os == "xenial"' > > It should have been using major_version, fixed. > >> http://ci.theforeman.org/job/release_push_deb/ doesn't have a >> combination filter so it just publishes to the other 3 repos.(jessie >> trusty and xenial). > > Fixed, added stretch. > > -- > Dominic Cleal > domi...@cleal.org > > -- > 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 @dlobatog daniellobato.me GPG: http://keys.gnupg.net/pks/lookup?op=get=0x7A92D6DD38D6DE30 -- 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: 1.15.0 release status
Thanks, it seems like either I don't understand the combination filter or it didn't work (https://github.com/theforeman/foreman-infra/blob/cb03c58b7b2bf3b5c61a125e4c32841a07a6a274/puppet/modules/jenkins_job_builder/files/theforeman.org/yaml/jobs/release_test.yaml#L33) combination-filter: 'os == "el7" || os == "f24" || os == "jessie" || (os == "stretch" && version != "1.14" && version != "1.15") || os == "trusty" || os == "xenial"' I removed it from the job just to run it once and it passes fine. http://ci.theforeman.org/job/release_push_deb/ doesn't have a combination filter so it just publishes to the other 3 repos.(jessie trusty and xenial). http://ci.theforeman.org/view/Release%20pipeline/ On Thu, May 11, 2017 at 2:02 AM, Michael Moll <kved...@kvedulv.de> wrote: > Hi, > > On Thu, May 11, 2017 at 01:57:26AM +0900, Daniel Lobato wrote: >> Currently the pipeline is stuck on tests for Debian Stretch (not sure >> if just an artifact or a real failure yet, investigating). > > Stretch is not supported with 1.15 (and known to fail). So that should > get overriden for 1.15 (or whatever the approach is with these jobs in > similar situations). > > Regards > -- > 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. -- Daniel Lobato @dlobatog daniellobato.me GPG: http://keys.gnupg.net/pks/lookup?op=get=0x7A92D6DD38D6DE30 -- 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] Re: 1.15.0 release status
Update, RPMS are signed and signatures are uploaded. Currently the pipeline is stuck on tests for Debian Stretch (not sure if just an artifact or a real failure yet, investigating). Help investigating the issue would be appreciated :) After tests pass on Debian stretch both RPMs and debs will be pushed to their respective repos as you can see in the pipeline. http://ci.theforeman.org/view/Release%20pipeline/ On Tue, May 9, 2017 at 8:04 PM, Daniel Lobato <elobat...@gmail.com> wrote: > Hi Foreman devs, > > Our 1.15 release is almost there! Tagging is done. I kicked off the release > pipeline, which means the first release tarballs are on their way. > > After that I will sign them and continue so we can build rpms & debs. As > soon as that's ready I will sign and publish them. > > I am boarding a plane now, hopefully when I land the tarballs will be ready > to be signed :) Sorry for the slight delay! > > In case something goes wrong let me know on this thread. > > Best regards, -- Daniel Lobato @dlobatog daniellobato.me GPG: http://keys.gnupg.net/pks/lookup?op=get=0x7A92D6DD38D6DE30 -- 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] 1.15.0 release status
1.15.1 is expected to be released around 2 weeks after .0. >From what I see the biggest change seems to be https://github.com/theforeman/foreman-packaging/pull/1627 (for debs) rpm-wise the changes are not as critical I think, so if they can be built for 1.15.1 that'd be good, there are 2 weeks of nightlies to test hammer before the release. On Tue, May 9, 2017 at 10:55 PM, Tomas Strachota <tstra...@redhat.com> wrote: > Since Hammer CLI 0.10.2 contains significant usability improvements > around ssl certificates (fetching certs without need of root > permissions) and sessions (retry on expiry) I think that we should > definitely include it in 1.15.1 if it's not possible to include it in > 1.15.0. > > T. > > On Tue, May 9, 2017 at 1:15 PM, Dominic Cleal <domi...@cleal.org> wrote: >> On 09/05/17 12:04, Daniel Lobato wrote: >>> Our 1.15 release is almost there! Tagging is done. I kicked off the >>> release pipeline, which means the first release tarballs are on their way. >> >> I guess you don't want Hammer CLI 0.10.2 packages to be merged at this >> point then - do you want them merged after this release for 1.15.1, or >> do not include it in the 1.15 series? >> >> (There were requests at >> https://github.com/theforeman/foreman-packaging/pull/1641 and 1638 that >> would have needed your approval. They also require a number of >> dependency changes/additions.) >> >> -- >> Dominic Cleal >> domi...@cleal.org >> >> -- >> 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 @dlobatog daniellobato.me GPG: http://keys.gnupg.net/pks/lookup?op=get=0x7A92D6DD38D6DE30 -- 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] 1.15.0 release status
Hi Foreman devs, Our 1.15 release is almost there! Tagging is done. I kicked off the release pipeline, which means the first release tarballs are on their way. After that I will sign them and continue so we can build rpms & debs. As soon as that's ready I will sign and publish them. I am boarding a plane now, hopefully when I land the tarballs will be ready to be signed :) Sorry for the slight delay! In case something goes wrong let me know on this thread. Best regards, -- 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] Nominating Daniel Lobato for commiter to release related tasks
On 04/26, Dominic Cleal wrote: > On 25/04/17 12:45, Marek Hulán wrote: > > On úterý 25. dubna 2017 9:19:40 CEST Dominic Cleal wrote: > >> On 24/04/17 12:59, Marek Hulán wrote: > >>> based on our handbook [1]. I'd like to nominate Daniel for commit access > >>> to > >>> > >>> the following repositories: > >>> - foreman-infra > >>> - foreman-installer > >>> - foreman-packaging ( to branch and cherry-pick to the release branch ) > >>> > >>> Daniel contributes to the project for a long time, also in this area > >>> [2][3][4] and always has only the best intentions. He worked on 1.15 RC1 > >>> and I think there's no reason why he shouldn't have access to places > >>> which are needed to update during the release process. > >> These repos all have active maintainers and so making a pull request (as > >> Daniel's done on two of them) is a better way to make changes. I don't > >> think commit access is necessary to submit updates to these repos and > >> shouldn't be encouraged here for Foreman releases. > > I'm happy to hear that there are active maintainers. I'm not sure whether > > you > > suggest that it is the reason why commit access should not be granted? I > > think > > the more active committers the better. Doing this through PR is fine and as > > you say, it can find issues. But if other devs send PRs, I think it makes > > sense if Daniel can merge them. Commit access is also required to create > > branches and tags which I don't think needs any form of reviewing. > > > > I'm sorry if it seemed like I'm encouraging pushing commits directly without > > PR during release process. That was not subject of this nomination. > > OK, sorry, that's what I thought you were suggesting. In that case, I > don't think Daniel's had much involvement with the foreman-infra or > foreman-installer projects to warrant commit access. He's opened a lot > of PRs against foreman-packaging, but I'd want to see fewer common > errors in recent PRs before seconding him for commit access. It's true I've made sloppy mistakes on -packaging (especially recently). I'm happy to pay more attention on future PRs to avoid having other people (mostly you.. though :/) have to double-check carefully my PRs. For -infra I don't really need commit access, however you're the only active maintainer, which is not an ideal situation in case something needs to be done during holidays etc.. About -installer, I don't mean to update anything there, except for tagging stuff for the releases. I'm not sure if there's a way to give permission to just branch and tag but not commit to the develop branch. > > -- > Dominic Cleal > domi...@cleal.org > > > -- > 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=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] Re: Heads up: Use ApplicationRecord base for your models
On 04/12, Lukas Zapletal wrote: > > Heads up! > > > > PG::UndefinedTable: ERROR: relation "application_records" does not exist > > This error appears to show up when Rails devel environment is reloaded > on change. We are tracking this down, but be careful until we find > this. https://github.com/theforeman/foreman/pull/4454 is merged, I take it this is now fixed on develop > > -- > 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. -- Daniel Lobato Garcia @dLobatog blog.daniellobato.me daniellobato.me GPG: http://keys.gnupg.net/pks/lookup?op=get=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
[foreman-dev] Re: Revert removal of @host.params for host_param
Sorry to relive the topic but https://github.com/theforeman/foreman/pull/4219 didn't get in, and it's time to update the documentation for 1.15 including deprecations. Since reverting the change is probably something not to be done during RC, I wonder what to do. The options are: 1. Keep the code as-is - which forces people to change their templates for 1.17 for little benefit imo 2. Support both options - this would just require to remove the deprecations for the next RC which is not a problem 3. Support both options and reconsider to remove the helpers? Let me know what you think, I lean towards 2 or 3 as I explained in here previously. 2017年1月11日水曜日 17時05分42秒 UTC+1 Daniel Lobato: > > Hi foreman devs, > > Just noticed today https://github.com/theforeman/foreman/pull/3983/files > after some comments on IRC. What's the background behind this change? > > As far as I can see, this merely moves > > @host.param to host_param > @host.param_true? to host_param_true? > @host.param_false? to host_param_false? > @host.info to host_enc > > without gaining anything from the change. This will force people to > change their templates (including our community templates) when the > deprecation is removed, and there's nothing to gain. > > Does someone know what's the rationale behind this change? As it stands > right now, I propose reverting that commit entirely to avoid inflicting > that pain on users - which include many devs who maintain templates. > > Best, > > -- > Daniel Lobato Garcia > > @dLobatog > blog.daniellobato.me > daniellobato.me > > GPG: http://keys.gnupg.net/pks/lookup?op=get=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.
Re: Re: [foreman-dev] Re: 1.15 branching in approximately 2 weeks
Tests in the pipeline for 1.15 RC1 rpms & debs passed on Friday - http://ci.theforeman.org/view/Release%20pipeline/job/release_test/106/ Plan is to announce the release tomorrow, according to the shared planning with Katello 3.4 RC1. You can see our tentative calendar here: https://calendar.google.com/calendar/embed?src=gbmpm6r1rsfok5k633ii240bck%40group.calendar.google.com Best, PS: If you're impatient enough to not wait until tomorrow, you can find the builds that will be published at http://koji.katello.org/ :) On 03/28, Daniel Lobato wrote: > Hi all, > > I will begin branching Foreman, theforeman.org, community-templates > and translations in approximately 5 hours. > If you have signed up to branch any of the projects in this thread, > please feel free to do so any time today. > > Remember, after branching, we still have time to submit patches to > ensure the release is stable during the RC period. > Expect a new RC to come out every week approximately since now. > > Thanks for your collaboration! > > On Thu, Mar 16, 2017 at 11:45 AM, Dmitri Dolguikh <witlessb...@gmail.com> > wrote: > > On Wed, Mar 15, 2017 at 8:10 AM, Tomas Strachota <tstra...@redhat.com> > > wrote: > >> On Tue, Mar 14, 2017 at 2:28 PM, Daniel Lobato <elobat...@gmail.com> wrote: > >>> We're planning to do the branching on all projects on March 28th - > >>> please keep it in mind and try to get > >>> things that would be important for 1.15 by then. > >>> > >>> I do not have commit access everywhere, so please check the following > >>> list and reply if you > >>> could take care of cherry-picking and branching: > >>> > >>> foreman - Daniel - dlobatog > >>> foreman-installer - Stephen - stbenjam > >>> smart-proxy - Daniel - dlobatog - (or Dmitri - witlessb if you prefer) > > > > yes can do. > > -d > > > >>> foreman-selinux - Lukas - lzap > >>> foreman-packaging - Eric - ehelms > >>> theforeman.org - Daniel - dlobatog > >>> translations - Daniel - dlobatog > >>> community-templates - Daniel - dlobatog > >>> hammer-cli - Tomas? Martin? > >>> hammer-cli-foreman - Tomas? Martin? > >> > >> I'll take care of hammer branching and release. > >> > >>> puppet-foreman - ? > >>> puppet-foreman_proxy - ? > >>> > >>> > >>> On Fri, Mar 10, 2017 at 7:43 PM, Daniel Lobato Garcia > >>> <elobat...@gmail.com> wrote: > >>>> As per > >>>> http://projects.theforeman.org/projects/foreman/wiki/Foreman_115_Schedule, > >>>> 1.15 is due to be branched soon, in 2 weeks approximately. > >>>> > >>>> Please help to make develop more stable during this process, be it > >>>> through > >>>> thorough testing, bugfixing or improving documentation. > >>>> > >>>> Help with updating the manual would be appreciated, see the list of > >>>> tasks in: > >>>> - https://github.com/theforeman/theforeman.org/issues/765 > >>>> > >>>> Some translations are nearing 100% completion, we welcome contributions > >>>> that help finishing them for the next release: > >>>> - https://www.transifex.com/foreman/foreman/foreman/ > >>>> > >>>> If you have any critical fixes that you think should be included in 1.15 > >>>> in any of the core projects, please reply to this read to raise > >>>> attention over them. Maintainers feel free to set the 1.15 label to > >>>> any PR of that nature. > >>>> > >>>> Best, > >>>> > >>>> -- > >>>> Daniel Lobato Garcia > >>>> > >>>> @dLobatog > >>>> blog.daniellobato.me > >>>> daniellobato.me > >>>> > >>>> GPG: http://keys.gnupg.net/pks/lookup?op=get=0x7A92D6DD38D6DE30 > >>>> Keybase: https://keybase.io/elobato > >>> > >>> > >>> > >>> -- > >>> Daniel Lobato > >>> > >>> @dlobatog > >>> daniellobato.me > >>> > >>> GPG: http://keys.gnupg.net/pks/lookup?op=get=0x7A92D6DD38D6DE30 > >>> > >>> -- > >>> 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, s
Re: [foreman-dev] Re: 1.15 branching in approximately 2 weeks
Hi all, I will begin branching Foreman, theforeman.org, community-templates and translations in approximately 5 hours. If you have signed up to branch any of the projects in this thread, please feel free to do so any time today. Remember, after branching, we still have time to submit patches to ensure the release is stable during the RC period. Expect a new RC to come out every week approximately since now. Thanks for your collaboration! On Thu, Mar 16, 2017 at 11:45 AM, Dmitri Dolguikh <witlessb...@gmail.com> wrote: > On Wed, Mar 15, 2017 at 8:10 AM, Tomas Strachota <tstra...@redhat.com> wrote: >> On Tue, Mar 14, 2017 at 2:28 PM, Daniel Lobato <elobat...@gmail.com> wrote: >>> We're planning to do the branching on all projects on March 28th - >>> please keep it in mind and try to get >>> things that would be important for 1.15 by then. >>> >>> I do not have commit access everywhere, so please check the following >>> list and reply if you >>> could take care of cherry-picking and branching: >>> >>> foreman - Daniel - dlobatog >>> foreman-installer - Stephen - stbenjam >>> smart-proxy - Daniel - dlobatog - (or Dmitri - witlessb if you prefer) > > yes can do. > -d > >>> foreman-selinux - Lukas - lzap >>> foreman-packaging - Eric - ehelms >>> theforeman.org - Daniel - dlobatog >>> translations - Daniel - dlobatog >>> community-templates - Daniel - dlobatog >>> hammer-cli - Tomas? Martin? >>> hammer-cli-foreman - Tomas? Martin? >> >> I'll take care of hammer branching and release. >> >>> puppet-foreman - ? >>> puppet-foreman_proxy - ? >>> >>> >>> On Fri, Mar 10, 2017 at 7:43 PM, Daniel Lobato Garcia >>> <elobat...@gmail.com> wrote: >>>> As per >>>> http://projects.theforeman.org/projects/foreman/wiki/Foreman_115_Schedule, >>>> 1.15 is due to be branched soon, in 2 weeks approximately. >>>> >>>> Please help to make develop more stable during this process, be it through >>>> thorough testing, bugfixing or improving documentation. >>>> >>>> Help with updating the manual would be appreciated, see the list of >>>> tasks in: >>>> - https://github.com/theforeman/theforeman.org/issues/765 >>>> >>>> Some translations are nearing 100% completion, we welcome contributions >>>> that help finishing them for the next release: >>>> - https://www.transifex.com/foreman/foreman/foreman/ >>>> >>>> If you have any critical fixes that you think should be included in 1.15 >>>> in any of the core projects, please reply to this read to raise >>>> attention over them. Maintainers feel free to set the 1.15 label to >>>> any PR of that nature. >>>> >>>> Best, >>>> >>>> -- >>>> Daniel Lobato Garcia >>>> >>>> @dLobatog >>>> blog.daniellobato.me >>>> daniellobato.me >>>> >>>> GPG: http://keys.gnupg.net/pks/lookup?op=get=0x7A92D6DD38D6DE30 >>>> Keybase: https://keybase.io/elobato >>> >>> >>> >>> -- >>> Daniel Lobato >>> >>> @dlobatog >>> daniellobato.me >>> >>> GPG: http://keys.gnupg.net/pks/lookup?op=get=0x7A92D6DD38D6DE30 >>> >>> -- >>> 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. -- Daniel Lobato @dlobatog daniellobato.me GPG: http://keys.gnupg.net/pks/lookup?op=get=0x7A92D6DD38D6DE30 -- 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] Re: 1.15 branching in approximately 2 weeks
We're planning to do the branching on all projects on March 28th - please keep it in mind and try to get things that would be important for 1.15 by then. I do not have commit access everywhere, so please check the following list and reply if you could take care of cherry-picking and branching: foreman - Daniel - dlobatog foreman-installer - Stephen - stbenjam smart-proxy - Daniel - dlobatog - (or Dmitri - witlessb if you prefer) foreman-selinux - Lukas - lzap foreman-packaging - Eric - ehelms theforeman.org - Daniel - dlobatog translations - Daniel - dlobatog community-templates - Daniel - dlobatog hammer-cli - Tomas? Martin? hammer-cli-foreman - Tomas? Martin? puppet-foreman - ? puppet-foreman_proxy - ? On Fri, Mar 10, 2017 at 7:43 PM, Daniel Lobato Garcia <elobat...@gmail.com> wrote: > As per > http://projects.theforeman.org/projects/foreman/wiki/Foreman_115_Schedule, > 1.15 is due to be branched soon, in 2 weeks approximately. > > Please help to make develop more stable during this process, be it through > thorough testing, bugfixing or improving documentation. > > Help with updating the manual would be appreciated, see the list of > tasks in: > - https://github.com/theforeman/theforeman.org/issues/765 > > Some translations are nearing 100% completion, we welcome contributions > that help finishing them for the next release: > - https://www.transifex.com/foreman/foreman/foreman/ > > If you have any critical fixes that you think should be included in 1.15 > in any of the core projects, please reply to this read to raise > attention over them. Maintainers feel free to set the 1.15 label to > any PR of that nature. > > Best, > > -- > Daniel Lobato Garcia > > @dLobatog > blog.daniellobato.me > daniellobato.me > > GPG: http://keys.gnupg.net/pks/lookup?op=get=0x7A92D6DD38D6DE30 > Keybase: https://keybase.io/elobato -- Daniel Lobato @dlobatog daniellobato.me GPG: http://keys.gnupg.net/pks/lookup?op=get=0x7A92D6DD38D6DE30 -- 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] 1.15 branching in approximately 2 weeks
As per http://projects.theforeman.org/projects/foreman/wiki/Foreman_115_Schedule, 1.15 is due to be branched soon, in 2 weeks approximately. Please help to make develop more stable during this process, be it through thorough testing, bugfixing or improving documentation. Help with updating the manual would be appreciated, see the list of tasks in: - https://github.com/theforeman/theforeman.org/issues/765 Some translations are nearing 100% completion, we welcome contributions that help finishing them for the next release: - https://www.transifex.com/foreman/foreman/foreman/ If you have any critical fixes that you think should be included in 1.15 in any of the core projects, please reply to this read to raise attention over them. Maintainers feel free to set the 1.15 label to any PR of that nature. Best, -- Daniel Lobato Garcia @dLobatog blog.daniellobato.me daniellobato.me GPG: http://keys.gnupg.net/pks/lookup?op=get=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: Re: Re: [foreman-dev] Notifications API & UI available - quick HOWTO
On 01/23, Tom McKay wrote: > Wish list... > > + Every notification we add to this system should be required to have a > unique ID based on where it is in the code. This ID could be leveraged for > access insights, docs, etc. (Maybe this is already the case?) It's the case - the notification blueprint comes with a 'subject' field which is meant for specifying which object does this notification 'stem from' > + Dedicated notifications API/CLI/UI to manage notifications and messages > (search, delete older than X, etc.) > + Ability to subscribe to notifications in the UI (eg. I see a message in > the history that is not normally displayed in the UI, I choose to > "subscribe to message ID=X") Not sure what messages like that you see..? Sounds interesting but I can't thing of any example > > I'm looking forward to a unified notification framework. > > > On Mon, Jan 23, 2017 at 11:54 AM, Daniel Lobato Garcia <elobat...@gmail.com> > wrote: > > > On 01/23, Tom McKay wrote: > > > Is there a dedicated page where these notifications are displayed? For > > > example, if I mark one as "read" and it disappears, where do I go to see > > it > > > in a history view? > > > > It doesn't dissapear, it's displayed but the group isn't in bold anymore > > and it will not display '1 new event'. > > > > It dissapears though when the notification is expired. > > > > > > > > On Fri, Jan 20, 2017 at 12:08 PM, Lukas Zapletal <l...@redhat.com> > > wrote: > > > > > > > When ERROR message appears in Smart Proxy log buffer, we could make a > > > > notification. > > > > > > > > Maybe when a host is discovered, not sure. > > > > > > > > LZ > > > > > > > > On Fri, Jan 20, 2017 at 1:15 PM, Daniel Lobato Garcia > > > > <elobat...@gmail.com> wrote: > > > > > Hi Foreman devs, > > > > > > > > > > Thanks to Gail Steiger and Ohad Levy - > > > > > https://github.com/theforeman/foreman/pull/4170 > > > > > https://github.com/theforeman/foreman/pull/3902 > > > > > > > > > > https://cloud.githubusercontent.com/assets/ > > > > 598891/21989268/91469e06-dc0a-11e6-828f-44d37183c572.png > > > > > https://cloud.githubusercontent.com/assets/ > > > > 598891/21989267/91440f06-dc0a-11e6-8940-d1f1a100e79b.png > > > > > > > > > > we have now a fancy-looking notifications drawer in Foreman! It works > > > > > and looks nice, and I'd recommend taking a look at both the React > > > > > implementation and the Rails part as neither are complicated to > > > > > understand in my opinion. > > > > > > > > > > Now, what's this notifications drawer useful for if we don't have any > > > > > notifications? That's where you come into play: > > > > > > > > > > Notifications in Foreman are stored in what we call a > > > > > "NotificationBlueprint", which stores the information about the > > > > > notification (e.g, level, message, subject..). The blueprint should > > > > > contain information about what happened and ideally how to diagnose > > or > > > > > resolve the problem (if it's a problem) > > > > > > > > > > The idea is that plugins or Foreman itself will define these > > blueprints > > > > > somwhere (via the engine, or a db seed, for example). > > > > > > > > > > In order to trigger them, you need to instantiate a Notification > > object > > > > > that uses the NotificationBlueprint you defined. This Notification > > will > > > > > store information related to the recipients (e.g: when will the > > > > > notification expire, who is it meant for, etcetera). This will > > > > > automatically setup the notification for consumption by users. > > > > > > > > > > > > > > > > > > > > Here's some example code: > > > > > > > > > > a = NotificationBlueprint.new( > > > > > :group => 'Hi There', > > > > > :message => "Hello, I'm back", > > > > > :level => 'info', > > > > > :subject => SmartProxy.first, > > > > > :name => 'example', > > > > > :expires_in => 1.hour > > > > > ) > > > > > b
Re: [foreman-dev] Plan for dropping Puppet 3 in the installer modules
On 01/23, Ewoud Kohl van Wijngaarden wrote: > Hello all, > > We should come up with a plan for dropping Puppet 3 in our installer > modules. > > Officially Puppet 3 is already EOL since 1-1-2017. We also know that > both puppetlabs and voxpupuli (our only dependencies) are dropping > Puppet 3 support. > > That said we also know that many of our users are still on Puppet 3 and > upgrading is hard for many. > > My proposal is to deprecate using our modules with 1.15 and drop it in > master for 1.16. We can still keep Puppet 3 branches but they are on a > best-effort basis and no backwards incompatible changes. > > Thoughts on this? Sound reasonable to me -- Daniel Lobato Garcia @dLobatog blog.daniellobato.me daniellobato.me GPG: http://keys.gnupg.net/pks/lookup?op=get=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: Re: [foreman-dev] Notifications API & UI available - quick HOWTO
On 01/23, Tom McKay wrote:
> Is there a dedicated page where these notifications are displayed? For
> example, if I mark one as "read" and it disappears, where do I go to see it
> in a history view?
It doesn't dissapear, it's displayed but the group isn't in bold anymore
and it will not display '1 new event'.
It dissapears though when the notification is expired.
>
> On Fri, Jan 20, 2017 at 12:08 PM, Lukas Zapletal <l...@redhat.com> wrote:
>
> > When ERROR message appears in Smart Proxy log buffer, we could make a
> > notification.
> >
> > Maybe when a host is discovered, not sure.
> >
> > LZ
> >
> > On Fri, Jan 20, 2017 at 1:15 PM, Daniel Lobato Garcia
> > <elobat...@gmail.com> wrote:
> > > Hi Foreman devs,
> > >
> > > Thanks to Gail Steiger and Ohad Levy -
> > > https://github.com/theforeman/foreman/pull/4170
> > > https://github.com/theforeman/foreman/pull/3902
> > >
> > > https://cloud.githubusercontent.com/assets/
> > 598891/21989268/91469e06-dc0a-11e6-828f-44d37183c572.png
> > > https://cloud.githubusercontent.com/assets/
> > 598891/21989267/91440f06-dc0a-11e6-8940-d1f1a100e79b.png
> > >
> > > we have now a fancy-looking notifications drawer in Foreman! It works
> > > and looks nice, and I'd recommend taking a look at both the React
> > > implementation and the Rails part as neither are complicated to
> > > understand in my opinion.
> > >
> > > Now, what's this notifications drawer useful for if we don't have any
> > > notifications? That's where you come into play:
> > >
> > > Notifications in Foreman are stored in what we call a
> > > "NotificationBlueprint", which stores the information about the
> > > notification (e.g, level, message, subject..). The blueprint should
> > > contain information about what happened and ideally how to diagnose or
> > > resolve the problem (if it's a problem)
> > >
> > > The idea is that plugins or Foreman itself will define these blueprints
> > > somwhere (via the engine, or a db seed, for example).
> > >
> > > In order to trigger them, you need to instantiate a Notification object
> > > that uses the NotificationBlueprint you defined. This Notification will
> > > store information related to the recipients (e.g: when will the
> > > notification expire, who is it meant for, etcetera). This will
> > > automatically setup the notification for consumption by users.
> > >
> > >
> > >
> > > Here's some example code:
> > >
> > > a = NotificationBlueprint.new(
> > > :group => 'Hi There',
> > > :message => "Hello, I'm back",
> > > :level => 'info',
> > > :subject => SmartProxy.first,
> > > :name => 'example',
> > > :expires_in => 1.hour
> > > )
> > > b = Notification.new(
> > > :notification_blueprint => a,
> > > :initiator => User.find_by_login('dlobatog'),
> > > :audience => Notification::AUDIENCE_GLOBAL,
> > > )
> > >
> > > --
> > >
> > > What actions would you like to see as notifications in Foreman? We want
> > > the drawer to only contain important information, as to not overwhelm
> > > the user with notifications.
> > >
> > > So things like: 'host failed a puppetrun' is probably too common an event
> > > to have notifications for, but things like 'this TFTP proxy went down'
> > > or 'your RH subscription is about to expire' is a much more important
> > > notification that should show up. A cronjob could check out the health
> > > of your infrastructure to add these notifications, or ... do you have
> > > any ideas? Please reply in this thread as I'd love to see the drawer
> > > getting some use ASAP for 1.15 :)
> > >
> > > Best,
> > >
> > > --
> > > Daniel Lobato Garcia
> > >
> > > @dLobatog
> > > blog.daniellobato.me
> > > daniellobato.me
> > >
> > > GPG: http://keys.gnupg.net/pks/lookup?op=get=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 htt
[foreman-dev] Notifications API & UI available - quick HOWTO
Hi Foreman devs,
Thanks to Gail Steiger and Ohad Levy -
https://github.com/theforeman/foreman/pull/4170
https://github.com/theforeman/foreman/pull/3902
https://cloud.githubusercontent.com/assets/598891/21989268/91469e06-dc0a-11e6-828f-44d37183c572.png
https://cloud.githubusercontent.com/assets/598891/21989267/91440f06-dc0a-11e6-8940-d1f1a100e79b.png
we have now a fancy-looking notifications drawer in Foreman! It works
and looks nice, and I'd recommend taking a look at both the React
implementation and the Rails part as neither are complicated to
understand in my opinion.
Now, what's this notifications drawer useful for if we don't have any
notifications? That's where you come into play:
Notifications in Foreman are stored in what we call a
"NotificationBlueprint", which stores the information about the
notification (e.g, level, message, subject..). The blueprint should
contain information about what happened and ideally how to diagnose or
resolve the problem (if it's a problem)
The idea is that plugins or Foreman itself will define these blueprints
somwhere (via the engine, or a db seed, for example).
In order to trigger them, you need to instantiate a Notification object
that uses the NotificationBlueprint you defined. This Notification will
store information related to the recipients (e.g: when will the
notification expire, who is it meant for, etcetera). This will
automatically setup the notification for consumption by users.
Here's some example code:
a = NotificationBlueprint.new(
:group => 'Hi There',
:message => "Hello, I'm back",
:level => 'info',
:subject => SmartProxy.first,
:name => 'example',
:expires_in => 1.hour
)
b = Notification.new(
:notification_blueprint => a,
:initiator => User.find_by_login('dlobatog'),
:audience => Notification::AUDIENCE_GLOBAL,
)
--
What actions would you like to see as notifications in Foreman? We want
the drawer to only contain important information, as to not overwhelm
the user with notifications.
So things like: 'host failed a puppetrun' is probably too common an event
to have notifications for, but things like 'this TFTP proxy went down'
or 'your RH subscription is about to expire' is a much more important
notification that should show up. A cronjob could check out the health
of your infrastructure to add these notifications, or ... do you have
any ideas? Please reply in this thread as I'd love to see the drawer
getting some use ASAP for 1.15 :)
Best,
--
Daniel Lobato Garcia
@dLobatog
blog.daniellobato.me
daniellobato.me
GPG: http://keys.gnupg.net/pks/lookup?op=get=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] Foreman plugin accessing katello host data like asigned content view
On 01/16, Daniel Kuffner wrote: > Hi All, > > I'm generally interested if it is possible to access from within a > foreman_plugin data from Katello plugin (plugin accesses data from other > plugin). > For example I would like to extract the content-view/asigned repository > information for a given host. Yes, after initialization your plugin should be able to access all katello properties. The foreman-docker plugin for instance does different things depending on whether Katello is available or not, like in: github.com/theforeman/foreman-docker/blob/master/app/views/containers/steps/image.html.erb > > regards, > Daniel > > -- > 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=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] HoundCI - annoying?
On 01/11, Timo Goebel wrote: > Hi devs, > > I'm usually not very easily annoyed. What get's me started though > eventually is when things don't work properly. > HoundCI is one of those things. > > My main concern is, that I get an e-mail and/or Github notification for > every single comment. These can easily be ten or more e-mails. They're not > grouped as other reviews. > In addition, the inline comments are very distracting when reviewing a PR > imho. When the issues are fixed, I'd prefer for the comments to be removed. > When reviewing a PR, I usually don't care about the style issues. I just > want to see if there are some problems or if all is fine. > > Back in the days, code style was checked by Jenkins. I think, it did a far > better job in displaying style issues. With the current Jenkins Github > plugin it believe would be easily possible to show style issues as a > separate line along with all the other CI checks. I don't think it did a better job displaying the issues. I do remember having to point up people to the exact jenkins page where rubocop failures showed up, as it wasn't immediately obvious what happened. Inline comments show new contributors what's failing right there. That was my motivation for using Hound, also Javascript linting and saving us the trouble of having more jobs in jenkins was also a nice side benefit > > One argument in favor of HoundCI is, that it checks JavaScript style. But I > think, that can easily be set up in Jenkins as well by running eslint. > > Any comments? How do others feel? > > Timo > > -- > 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=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: Re: [foreman-dev] Revert removal of @host.params for host_param
On 01/12, Marek Hulán wrote: > > > > > I strongly disagree that this does not have big benefits. Using internal > > > Foreman objects in templates is a bad practice. It blocks us from > > > improving > > > our code. Therefore it's very important to build a DSL that users can use > > > in templates and keep that compatible. We can then later change the > > > implementation of host_param_true method without any templates changing. > > > Think > > > of this as a templating API. > > > > > > Another less significant benefit is that for plugins it's easier to > > > wrap/alias > > > the template method rather than manipulating something that's used > > > internally in @host. Still not ideal but that should be solved by > > > https://github.com/ theforeman/foreman/pull/3701 > > > > > > Of course it will require users to migrate to new template helpers which > > > is > > > why we move there slowly and hopefully with proper deprecations. I was > > > hoping to do the update for community-templates since it's very easy > > > migration. > > > > > > If you think it's too complicated for users we could provide rake task or > > > migration. But please don't revert this. > > > > Yes, if you provided a migration it would be much better. That doesn't > > really solve the problem with people using the foreman_templates plugin > > who will have those changes reverted, but I guess it's better than nothing. > > > > There's still dozens of other things allowed for @host in the Jail that > > aren't covered by these macros. What's the plan for those? > > Whenever we have a chance, we should move from internal objects to macros. The > more macros we have the higher the chance is that we can keep templates > compatible. Sorry but I oppose this. Some internal objects are quite stable, in fact people rely upon them successfully - but we break the compatibility for apparent advantages that IMO are not worth the hassle. @host.operatingsystem, @host.architecture, etc... and @host.params, are very stable objects that can safely be called from templates and expect that will work for a long time. Not only our users do it. We also relied upon these internal objects for years. The first community templates PRs which are 4 years old used @host.params, @host.operatingsystem, etc.. Those are stable enough to not warrant writing a macro for them What we did on #16740 is basically renaming things around and deprecating params for macros that don't do anything but calling @host.params themselves. I would argue for the opposite way of thinking. When we change how these internal APIs work, we should deprecate them. If these APIs remain stable, don't change anything as it provides no value, and brings headaches and wastes time. Time wasted on writing this thread, on the people who write and review PRs in the project and associated ones (templates, the migration to new macros, fixing anything that might break, and adding more LOC which complicate our codebase). > > > I still think this provides more headaches than any benefits. > > I hope that following helps > * https://github.com/theforeman/community-templates/pull/343 > * https://github.com/theforeman/foreman/pull/4187 > * https://gist.github.com/ares/5435226ef0317613535101765404d3f5 > > -- > Marek > > > > > > > - Stephen > > > > > -- > > > 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. > > -- > 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=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
[foreman-dev] Revert removal of @host.params for host_param
Hi foreman devs, Just noticed today https://github.com/theforeman/foreman/pull/3983/files after some comments on IRC. What's the background behind this change? As far as I can see, this merely moves @host.param to host_param @host.param_true? to host_param_true? @host.param_false? to host_param_false? @host.info to host_enc without gaining anything from the change. This will force people to change their templates (including our community templates) when the deprecation is removed, and there's nothing to gain. Does someone know what's the rationale behind this change? As it stands right now, I propose reverting that commit entirely to avoid inflicting that pain on users - which include many devs who maintain templates. Best, -- Daniel Lobato Garcia @dLobatog blog.daniellobato.me daniellobato.me GPG: http://keys.gnupg.net/pks/lookup?op=get=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] [Ansible] Support for playbook execution, not just role execution
On 12/23, gerrit.schwerth...@avid.com wrote: > Hello, > > currently, the Ansible plugin is limited to execute Ansible roles. However, > there are several reasons for considering direct Ansible playbook > execution. > > Just with roles, there is a lack of control over the execution order as the > structuring element, the playbook, is statically created by the plugin. In > addition to that, some fundamental features of Ansible on playbook-level > cannot be used with roles, for example strategies > <http://docs.ansible.com/ansible/playbooks_delegation.html#rolling-update-batch-size> Dependencies and ordering with roles can be accomplished at the role level (not via Foreman) - check http://docs.ansible.com/ansible/playbooks_roles.html#role-dependencies > Therefore, I think, that the plugin should support playbook execution, not > just role execution. > > What do you think about this? I would really appreciate some more thoughts > before starting to work on this. I'm afraid it's an area where the project clashes with Ansible Tower quite a lot. To be fair I think playbooks would fit better as another provider for Foreman remote execution model. Unfortunately I couldn't finish the provider, but it worked (for my dev usecase :) ) https://github.com/theforeman/foreman_ansible/pull/18 > > Thanks for reading. > > --Gerrit > > -- > 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=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] Foreman Button Proposals
On 12/21, junzh...@redhat.com wrote: > > > Hi, All > > > Recently I have been looking on the Foreman Action Buttons and created a > proposal for the buttons usability improvement. > > The proposals are is the following: > > > 1 - Each page should have one clear call to action, where the primary > action button is always blue, but all others are the secondary > buttons(gray). There is an accessibility reason being that on enter the > primary button should be enacted. It's possible that there could be no > primary action button on a page. > > 2 - Address inconsistent use of the close icon in modals and other screens. > > 3 - Change buttons with “New” labels to use the appropriate PF icons + the > “Create” label, as specified by PatternFly. I think I do agree with 1 and 3. The 'x' button however at times might be hard to see, so if you get started with this: 1. send PRs for each section separately, reviewers will appreciate this :) 2. send them across theforeman/foreman, foreman_discovery, foreman-docker katello/katello and other plugins that form part of the community and contain UI sections. 3. I'm dubious as to whether the single 'x' will make it easier to discover, at first glance it looks like something I'd struggle to find but let's see on the PRs. You can start by making that change in all parts that are non-controversial though! > > > The detail information is in the PDF file, please have a review. > > Before I begin working on fixing these items in the code, I’d love to get > everyone’s feedback. > Thanks June, your effort on making Foreman adopt Patternfly is highly appreciated > > Thanks > > June - UXD Team > > -- > 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=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
[foreman-dev] Nominating Katello.org devs for theforeman/theforeman.org commit access
Hi devs, I'd like to nominate ehelms, jlsherrill, beav and johnpmitch for commit access on theforeman.org. They have been maintaining katello.org this year, and from what I see these are the top contributors in that repository. I think they should be able to merge documentation in theforeman.org too now that the projects website merged with ours https://github.com/Katello/katello.org/graphs/contributors?from=2016-01-13=2016-12-06=c They all understand the project domain pretty well and they've been driving the migration to theforeman.org so all in all I think it makes sense for them to become committers. Objections or comments in private welcome, public replies to this thread preferred. :) Best, -- Daniel Lobato Garcia @dLobatog blog.daniellobato.me daniellobato.me GPG: http://keys.gnupg.net/pks/lookup?op=get=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: Re: [foreman-dev] Use mention-bot to increase reviews?
On 12/06, Sean O'Keeffe wrote: > Hows this going for everybody? I personally quite like it Personally it's just noise for me, but if it works for some people it causes no harm > > On Fri, Oct 28, 2016 at 12:36 PM, Greg Sutcliffe <greg.sutcli...@gmail.com> > wrote: > > > On 27 October 2016 at 14:55, Ohad Levy <ohadl...@gmail.com> wrote: > > > >> > >> On Mon, Oct 17, 2016 at 4:02 PM, Greg Sutcliffe <greg.sutcli...@gmail.com > >> > wrote: > >> > >>> On 13 October 2016 at 13:28, Eric D Helms <ericdhe...@gmail.com> wrote: > >>> > >>>> This has been turned on for the Katello repo, if devs find it needs > >>>> tweaking there is a configuration file that can be added ( > >>>> https://github.com/facebook/mention-bot#configuration). > >>>> > >>> > >>> How's that going for you? > >>> > >>> Dominic or Ohad, could you turn it on for the other repos mentioned, as > >>> a trial? Thanks! > >>> > >> > >> Done. > >> > > > > Thanks. It's already pinged me for a review, so that was cool. > > > > Lets see how it goes for a few weeks and we can see if we want to expand > > to other repos. Feedback welcome as we go :) > > > > Greg > > > > -- > > 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=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: Re: Creating a plugin-for-tests (was [foreman-dev] Plugin test failures)
On 11/03, Greg Sutcliffe wrote: > > > > You should file a bug against Foreman immediately if you see that a > > plugin interface has been broken, so we can ensure the change isn't > > released and a fix can be written. > > > > Fair enough - in this case it's an interface that wasn't tested and a user > has found > it subsequently (#17203 in set_hostgroup_defaults), so I think the > not-releasing-it > option is gone. I'll open an issue to write some tests for that interface, > though. > > More generally, does it make sense for someone to do an audit of the most > common > places that plugins hook in, and make sure we have tests for them? The 'problem' is that the places plugins hook in are usually parts of the app, e.g 'Host.foo', 'computeresource.bar'. The defined endpoints for the plugin API are usually fine, but other methods that are equally as important to the plugin could change behavior unexpectedly. Personally I think from core the important part is being aware of these changes and communicating them promptly - helping to fix them when possible too. > > Cheers > Greg > > -- > 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=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] Smart or Foreman Proxy? Let's do Foreman Smart Proxy
On 10/14, Lukas Zapletal wrote: > Hello, > > we have Smart Proxy in the Foreman Core, WebUI/API/CLI and also in our > Core documentation, but in the installer and package name it's > foreman-proxy. This creates confusion. It doesn't help that ManageIQ also refers to 'smart proxy' on their docs :) http://talk.manageiq.org/t/where-to-run-the-smart-proxy/836 > I suggest to "communicate" it from now on with new official name: > > Foreman Smart Proxy +1 will make an effort to use that term. > > This will help us to "teach" our users that this is essentially the same > thing. The suggested changes are easy and non-intrusive: > > * Rename "Smart Proxy" to "Foreman Smart Proxy" in our documentation > * Rename "Smart Proxy" to "Foreman Smart Proxy" in our codebase > > Controller names, API/CLI and internals all stays with "smart-proxy" of > course, the idea is only to logically connect these terms. > > This was brought at (*) and I would like to bring it here for broad > discussion: > > (*) https://github.com/theforeman/rfcs/pull/23/files#r83370195 > > -- > 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. -- Daniel Lobato Garcia @dLobatog blog.daniellobato.me daniellobato.me GPG: http://keys.gnupg.net/pks/lookup?op=get=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] Use mention-bot to increase reviews?
On 10/11, Greg Sutcliffe wrote: > We've spoken before about increasing the pool of reviewers, and one issue > is the increasingly large amount of notification email (especially if you > subscribe to a lot of our repos). > > So I was browsing some other repos today and stumbled upon this: > > https://github.com/facebook/mention-bot > > It's basically a tool to figure out who might be good reviewers for a pull > request, and mention them by name so that they get a notification. This > allows people to get a heads-up on repos they're not subscribed to, but > have contributed to. > > Worth enabling on a few repos and giving it a try? +1 from me - there's always time to shut it down if it doesn't help > > Cheers > -- > Greg > IRC: gwmngilfen > > -- > 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=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] Foreman Development getting started
On 10/10, 'Denis Müller' via foreman-dev wrote: > Hello dear developers, > first of all thank you for such a great project like foreman. > > We are using foreman in our company for a about 3 years but we would like > to extend some features. For example hammer-cli "host list". We would like > to have here an additional column for "description". How could u do that? Description of host? That field does not exist, so you would have to add it on Foreman core https://github.com/theforeman/foreman/ - there are recent commits that add the 'description' field to various objects, I hope that can serve as a reference. As for hammer, it essentially reads whatever the Foreman API has, so you'd have to expose that field in the Foreman API, and then make https://github.com/theforeman/hammer-cli-foreman/blob/master/lib/hammer_cli_foreman/host.rb read it > > What is the best to get started with development on foreman/hammer etc.? This is the best way to get started: https://theforeman.org/contribute.html > > What programming language is useul, ruby, puppet? Mostly Ruby, the installer modules are in Puppet though so if you want to improve the installer that'd be useful too. > > Is there a entry source to get started? > > We would like to help ourself and the community with development on this > great project. > > Greets, > Denis > > -- > 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=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] Please welcome a new gem in town: foreman_devel
On 10/09, ssht...@redhat.com wrote: > First version is available here: https://github.com/ShimShtein/foreman_devel > > The end goal of this plugin would be a one stop shop for foreman core and > plugins developers that will supply a set of tools that will aide the > development process. > I have started it by adding generator that would automatically add a > migration to a plugin, with naming convention that will enable easier > uninstallation of plugins. The discussion of this feature is in the rfc > <https://github.com/theforeman/rfcs/pull/15>. > > In my vision, it would be a repository for generators, rake tasks e.t.c to > aid plugin developers to write foreman plugins. > > Things that I think should be in the plugin: > generator for the whole template - create a plugin in one step > generator for plugin declaration > generator for assets handling > generator for gettext > generator for seeds > > Feel free to criticize it, suggest different names, suggest different > solutions, add things to my todo list. Basically any input will be welcome. > +1, thanks Shimon, I think this is something I would use if we can get it to mature I hope it can become something like Forklift. If this is meant for core too as you say - I think adding gems like 'better_errors', 'brakeman' or 'pry-byebug' to the Gemfile.local would be useful. Other things I'm thinking is changing the test db to run in memory as Lukas showed in a thread here a while ago, and making sure your plugin PRs run on Jenkins (that could be a bit tricky) > Thanks! > Shim > > -- > 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=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] Plugin test failures
Remove your test db, then try RAILS_ENV=test ruby -I'test' test/unit/foreman/access_permissions_test.rb and you'll see it happening. I think it's just because tests are loaded earlier than permissions from plugins now. On Tue, Oct 4, 2016 at 12:39 PM, Ivan Necas <ine...@redhat.com> wrote: > So far, I can tell this PR > https://github.com/theforeman/foreman/pull/3843 introduced the > behaviour > > as it's green on > http://ci.theforeman.org/job/test_plugin_matrix/2059/database=mysql,ruby=2.3,slave=fast/ > and red on following commit > http://ci.theforeman.org/job/test_plugin_matrix/2060/database=mysql,ruby=2.3,slave=fast/ > > Perhaps the change is the access permissions test was in lib, and not > it's part of the unit > > Still no idea why it happens in jenkins only > > -- Ivan > > On Mon, Oct 3, 2016 at 10:35 PM, Ivan Necas <ine...@redhat.com> wrote: >> The only think I can tell so far is that I can't reproduce this >> locally and I have no >> idea on what might be different from my vs. jenkins environment that causes >> this >> to happen. >> >> -- Ivan >> >> On Mon, Oct 3, 2016 at 10:28 PM, Stephen Benjamin <step...@redhat.com> wrote: >>> Tasks, salt and a bunch of plugins are failing tests, has anyone has a >>> chance to look into it? e.g.: >>> >>> http://ci.theforeman.org/job/test_plugin_matrix/2015/#showFailuresLink >>> >>> This most recent failure has me thinking again about the difficulties of >>> being a plugin maintainer >>> for Foreman. >>> >>> Would it be possible to get a standard plugin in Foreman's test matrix for >>> PR? Perhaps tasks is a good >>> candidate. Not on all databases/rubies, but something might help gain >>> awareness of the impact of >>> certain changes on plugins. Katello is there, but it doesn't run all (any?) >>> of Foreman's tests. >>> >>> Along side that, we should be tracking what plugin maintainers need to do >>> to update from one release >>> to the next. >>> >>> It really is a recurring problem for me, that Salt is constantly broken due >>> to incompatibilities >>> introduced in Foreman. We do a poor job of tracking them. Maybe if I'm >>> lucky someone is nice >>> enough to send a mail to foreman-dev. Or if the planets align, someone >>> opens a PR to foreman_salt >>> and fixes it. But more often than not, my project just goes red and I have >>> to figure out why. >>> But this is just a side thing, and I rarely get to immediately look at >>> failures. They end up piling >>> up. >>> >>> Very frustrating, as when I do find time to work on it, it's not to do >>> something cool, but just >>> to figure out what changed in core and how to fix it in the plugin :-\ >>> >>> >>> - Stephen >>> >>> -- >>> 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 @dlobatog daniellobato.me GPG: http://keys.gnupg.net/pks/lookup?op=get=0x7A92D6DD38D6DE30 -- 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] Adding GitHub label for all UI/Visual enhancements
On 08/25, Eric D Helms wrote: > Is the thought that hopefully reviewers are adding this new label or that > the PR bot is adding the label based on some code criteria of the PR? Reviewers > > On Thu, Aug 25, 2016 at 10:50 AM, Ohad Levy <ohadl...@gmail.com> wrote: > > > Hi, > > > > Now that we have a dedicated UX professional (Hi Roxanne :-) ) > > I would like to suggest that we add a new label for every work that has a > > UI element to it, the aim is to expose UI changes to wider group (e.g > > beside the reviewer) that other people can provide feedback, ideally across > > all foreman core and plugins that has a UI element to them. > > > > This could help to ensure consistency in our UI and improve the discussion > > around look and feel. > > > > thanks! > > Ohad > > > > -- > > 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. > > > > > > -- > Eric D. Helms > Red Hat Engineering > Ph.D. Student - North Carolina State University > > -- > 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=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: Re: [foreman-dev] Hash rocket syntax
On 08/19, Lukas Zapletal wrote: > > As discussed on IRC yesterday there should be consistency and there is an > > option to autofix with rubocop if the style is changed to change existing > > code with less effort. > > TL;DR - Let's keep Rubocop away from rockethash thing. > > What the consistency gives us? We all know there are two ways and both > will work. Let's avoid big bangs that will make cherry picking harder > and just let's slowly improve as the time goes on. Not sure what cherry-picking becomes harder after this change? It's just that people might have to rebase their PRs? That's a small price to pay considering code is read 1000x more often than written. > I see no point in changing a single line of code from old to new syntax > just for that. We should only change it when changing logic. > > Even if Rubocop is able to check only for changed lines, I won't like > that at all. I do not want to switch my brain between Smart Proxy and > Foreman Core codebases. Both ways should work and be accepted. Let's > only make the old syntax preferable when reviewing and that's it. Precisely that's the painpoint, reviewers shouldn't have to pay attention to that. One of the points for having style guidelines is that the code looks and reads as if it had been written by one person. Think of it from the POV of the ocassional contributor who is just confused about which syntax to use because the code mixes them both for no reason. > I think we implemented Rubocop far beyond what's reasonable point. It > make sense for dangerous constructs, but not in this case (and few > others). I'd argue the opposite, in foreman_docker or foreman_ansible I think rubocop (with *all* cops enabled) helped maintain good coding standards immensely and making the project *much easier* to read and get used to. Again I think we're really bikeshedding when the purpose of a style guide is to stop it and make code look more homogeneous > > -- > 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. -- Daniel Lobato Garcia @dLobatog blog.daniellobato.me daniellobato.me GPG: http://keys.gnupg.net/pks/lookup?op=get=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: Re: [foreman-dev] Possible Feature Requst: Discussion: EC2 Subnet Display - include comment/description field in seperate view
On 08/12, Matt Darcy wrote: > That's really wise feedback and appreciated. > > I think I'll try to pull a proper feature request for this, as I've hit two > or three solid requirements for this now and it was used as a negative > against using foreman. > > Thanks, I pretty much agree it'd be very useful - can you open an issue on http://projects.theforeman.org/issues/ to keep track of it? > > Matt > > > On Thursday, 11 August 2016 07:37:35 UTC+1, Marek Hulán wrote: > > > > On Tuesday 09 of August 2016 08:22:38 Matt Darcy wrote: > > > I've been doing a little bit of POC work on foreman 1.11 with EC2 (not > > > bothered moving to 1.12 for this POC as it's not really version > > specific). > > > > > > when building/modifying a host the EC2 compute plugin pulls a list of > > > subnets assigned to the account/compute resource associated to the > > foreman > > > compute resource target. this is nice and simple to use, however some > > > recent experience of what is in essence quite a small AWS estate, 6 > > VPCs, > > > at 9 subnets each, this become quite scappy as the list of 54 IP > > subnets, > > > totally out of any order was presented to the support team and without > > any > > > meaningful information about the subnets removed some of the ease and > > > management selling points that using foreman for the project been built > > on. > > > > > > In the POC I started looking at the ability to pull not only the IP CIDR > > > blocks but the comment field associated with the CIDR blocks. > > > > > > My initial tests look like it's possible to get the info, and I'd > > imagine > > > it's not too hard to create a second display box next to the IP list to > > > list the comments, or include a second field in the single box, but I'm > > > nowhere near that yet > > > > > > I thought I'd open up a short discussion (hopefully) about this as a > > > feature request and see if there is anything I've not considered > > > implication wise or anything I'd not seen the bigger picture on before > > > raising the feature request and looking to work on it and gather some > > > people to work on it. > > > > > > I'm currently looking at foreman for a much bigger EC2 deployment, which > > > will have many more subnets and without something human readable it will > > be > > > a much harder sell to use going forward. > > > > > > thoughts ? > > > > > > Matt > > > > Hello > > > > that sounds as a good addition to me. I'd prefer combining into a single > > select box, the second one would be hard to get in sync. I can imagine the > > comment being too long so some trimming might be considered. > > > > -- > > 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. -- Daniel Lobato Garcia @dLobatog blog.daniellobato.me daniellobato.me GPG: http://keys.gnupg.net/pks/lookup?op=get=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] Webpack merged into develop branch
On 08/10, Tomer Brisker wrote: > Hello, > > I am happy to inform you that Webpack has finally been added to Foreman. > This step which will help us modernize our front-end code, take advantage > of the blooming javascript eco-system, and easily integrate technologies > such as ES2015, React, js unit testing and more. > A deep-dive will be scheduled soon to explain all the changes, but there > are a few details that require your attention for running the current > develop branch. > > This change requires a slight change to your workflow in the development > environment. First, you need to run `npm install` to get all of the needed > node modules to install (similar to `bundle install` for gems). > Second, to run your server in development environment, you should use > `foreman start` which will run both the rails server and the webpack > live-reload development server. If you wish to use a non-default setting > for the rails server (e.g. using puma), you can set the RAILS_STARTUP > environment variable with the relevant command (see Procfile for an > example). > > Please note that running this way will limit the ability to use pry for > debugging, as foreman prevents stdin echo. To use with pry, you can run > both servers separately in different terminals - run rails as usual in one, > and run `./node_modules/.bin/webpack-dev-server --config > config/webpack.config.js` in the other. Alternatively use pry-remote https://github.com/mon-ouie/pry-remote and you can still use 'foreman start' with it > Also, new javascript code should be put in webpack/assets/javascript and > placed inside modules, using ES2015 syntax, whenever possible. Old code > will be gradually migrated into that location. > > -- > Have a nice day, > Tomer Brisker > 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. -- Daniel Lobato Garcia @dLobatog blog.daniellobato.me daniellobato.me GPG: http://keys.gnupg.net/pks/lookup?op=get=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: Re: [foreman-dev] Webpack merged into develop branch
On 08/12, Tomas Strachota wrote: > On 08/10/2016 02:01 PM, Tomer Brisker wrote: > >Please note that running this way will limit the ability to use pry for > >debugging, as foreman prevents stdin echo. To use with pry, you can run > >both servers separately in different terminals - run rails as usual in > >one, and run `./node_modules/.bin/webpack-dev-server --config > >config/webpack.config.js` in the other. > > I noticed that when I run rails in development env, the webpack's hostname > in assets is set to localhost. So of course it doesn't work when you're > developing on a different host. Can this be tuned right away in some config > or does it need additional patches to switch the hostname? I think this should cover that? It was merged just yesterday https://github.com/theforeman/foreman/commit/42ba771cc8bfc09257c15c5d388542d4d1b69358 -- Daniel Lobato Garcia @dLobatog blog.daniellobato.me daniellobato.me GPG: http://keys.gnupg.net/pks/lookup?op=get=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] Katello test coverage report
On 08/05, David Davis wrote: > Thanks to Andrew we’re now generating a test coverage report in Jenkins for > the katello on every PR and when code gets merged to master. We should be > able to track our code coverage over time using these reports and hopefully > it’ll improve our test coverage. > > To view the coverage report for a PR, if you go to the test_katello_pr_core > job page, you should see a new icon on the left with the caption “Rcov > report”. If you click on that you should see a coverage report like this: > > <http://ci.theforeman.org/job/test_katello_pr_core/2908/database=postgresql,ruby=2.2/rcov/> > http://ci.theforeman.org/job/test_katello_pr_core/2908/database=postgresql,ruby=2.2/rcov/ > > We’re still tweaking the settings—like right now it seems to only show > coverage for foreman files. > > One thing to note is that if you see the following error when your job runs > in Jenkins, you may need to rebase against master: > > <https://gist.github.com/daviddavis/17e7b09588180e121502cbe1cb63fdd7> > https://gist.github.com/daviddavis/17e7b09588180e121502cbe1cb63fdd7 Just an addendum - we have http://codeclimate.com/ checking out our PRs in Foreman core to provide stats about code 'cleanliness' - you can hook it up to a test reporting tool so it automatically tells you on every PR https://docs.codeclimate.com/docs/setting-up-test-coverage It'd free up some Jenkins resources & lists it separately in the PR so you might want to consider it > > *tl;dr - rebase your katello PRs!* > > David > > -- > 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=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: Re: Re: [foreman-dev] sprints vs trackers [was: Possible to move redmine Katello project under] Foreman?
On 08/04, Lukas Zapletal wrote: > Please, can we please not create these crazy "backlogs" and the dance > around and just use RedMine as it was design for? Otherwise we will be > doing nothing but tossing tickets from backlog to backlog. The idea is to do that in 30m or so every two weeks > * Put an item on "backlog" = create new Feature, NEW state > > * Put it on "sprint" = associate with feature issue (*) > > * Resolve issue, set Target Foreman version we ship it into > > * Profit! This is what we've been doing for some time, the process is fine but how can you prioritize a backlog of 6488 open issues? If the answer is adding the ones we think are most important to an etherpad, it's Pruning the search results to only show 'categories' owned by a team or certain plugins, isn't a good solution for getting less issues, as that field isn't that reliable & still returns 1000s of issues I'm all open to ideas that allow us to have a concise backlog we can prioritize from -- Daniel Lobato Garcia @dLobatog blog.daniellobato.me daniellobato.me GPG: http://keys.gnupg.net/pks/lookup?op=get=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: Re: Re: [foreman-dev] Deprecate EL6?
On 07/29, Dmitri Dolguikh wrote: > > The migration would be complicated for users who run TFTP/DHCP/DNS > > (etc..) on the same host. > > Why would it be complicated? Backup config files, restore them on the > new machine and run migrations. Sorry, I meant 'more complicated'. It's more complicated to migrate all the config files when we don't provide a simple script like we do for the Foreman database. > > -d > > -- > 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=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
[foreman-dev] Re: Re: Re: Status of RPM packaging for npm modules in Foreman
On 07/22, Daniel Lobato Garcia wrote:
> On 07/22, Daniel Lobato Garcia wrote:
> > On 07/21, Daniel Lobato Garcia wrote:
> >
> > > 3. Put node_modules in a new package (foreman-npm-assets?) that
> > > foreman-assets %install section puts in the right place?
> > >
> > > - Upsides:
> > > - relatively easy to do
> > > - jenkins can automate it
> > >
> > > - Downsides:
> > > - less control or information for users about what's installed with
> > >foreman, although we could specify the dependencies under
> > >"Provides: bundled-npm()"
> > >
> > > - Success with POC: haven't tried
> >
> > Update - I tried to make a POC for this quickly
> > https://github.com/theforeman/foreman-packaging/pull/1240
> >
> > I think it could work if there's a way of telling RPM to not care about
> > the requirements -i.e: it notices there are multiple npm(tap-stream)
> > versions and complains about that...
> >
> > To be fair I didn't expect RPM to read the contents of
> > %{nodejs_sitelib} and figure out all the dependencies!
>
> Update 2:
>
> It's working! - http://i.imgur.com/c8CPRqq.gif
>
> Brief summary:
>
> The way foreman-node_modules works is by dumping node_modules in
> /opt/foreman/node_modules, then copying that sources to the Foreman root
> to ensure webpack:compile can run. Aside from that the Foreman package
> itself now has a BuildDependency on node itself (& libuv) to run
> webpack.
>
> That way we ensure no other program finds stuff it shouldn't on
> %{nodejs_sitelib}
> and we don't conflict with the nodejs-XXX packages provided by the
> linux distribution.
>
> It's not building in Jenkins, but it's just because I have not put the
> sources for foreman-node_modules anywhere yet. You should be able to
> build it with mockchain locally.
>
> I think this solution would be a good compromise considering the
> difficulties 2. (bundled-npms) had and also it's much less intrusive -
> other packages need not to care about our npm deps at all.
More updates -
bundled npms are building fine in f24, however on el7 they're not
building yet. Part of the reason is that I have not been able to build
an npm registry cache that satisfies both.
A bit worrisome - the version of npm used in el7 isn't able to build the
cache for certain versions of some packages. For example:
https://github.com/theforeman/foreman-packaging/pull/1246#issuecomment-235877288
It might mean we have to use older versions so that older node/npm can
deal with it of some libraries.
BTW we would've missed these errors if we had gone with
packaging options 3 or 4!
Please follow
https://github.com/theforeman/foreman-packaging/milestone/1 if you want
to be on top of things or want to help :)
>
> >
> > --
> > Daniel Lobato Garcia
> >
> > @dLobatog
> > blog.daniellobato.me
> > daniellobato.me
> >
> > GPG: http://keys.gnupg.net/pks/lookup?op=get=0x7A92D6DD38D6DE30
> > Keybase: https://keybase.io/elobato
>
>
>
> --
> Daniel Lobato Garcia
>
> @dLobatog
> blog.daniellobato.me
> daniellobato.me
>
> GPG: http://keys.gnupg.net/pks/lookup?op=get=0x7A92D6DD38D6DE30
> Keybase: https://keybase.io/elobato
--
Daniel Lobato Garcia
@dLobatog
blog.daniellobato.me
daniellobato.me
GPG: http://keys.gnupg.net/pks/lookup?op=get=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
[foreman-dev] Re: Re: Status of RPM packaging for npm modules in Foreman
On 07/22, Daniel Lobato Garcia wrote:
> On 07/21, Daniel Lobato Garcia wrote:
>
> > 3. Put node_modules in a new package (foreman-npm-assets?) that
> > foreman-assets %install section puts in the right place?
> >
> > - Upsides:
> > - relatively easy to do
> > - jenkins can automate it
> >
> > - Downsides:
> > - less control or information for users about what's installed with
> >foreman, although we could specify the dependencies under
> >"Provides: bundled-npm()"
> >
> > - Success with POC: haven't tried
>
> Update - I tried to make a POC for this quickly
> https://github.com/theforeman/foreman-packaging/pull/1240
>
> I think it could work if there's a way of telling RPM to not care about
> the requirements -i.e: it notices there are multiple npm(tap-stream)
> versions and complains about that...
>
> To be fair I didn't expect RPM to read the contents of
> %{nodejs_sitelib} and figure out all the dependencies!
Update 2:
It's working! - http://i.imgur.com/c8CPRqq.gif
Brief summary:
The way foreman-node_modules works is by dumping node_modules in
/opt/foreman/node_modules, then copying that sources to the Foreman root
to ensure webpack:compile can run. Aside from that the Foreman package
itself now has a BuildDependency on node itself (& libuv) to run
webpack.
That way we ensure no other program finds stuff it shouldn't on
%{nodejs_sitelib}
and we don't conflict with the nodejs-XXX packages provided by the
linux distribution.
It's not building in Jenkins, but it's just because I have not put the
sources for foreman-node_modules anywhere yet. You should be able to
build it with mockchain locally.
I think this solution would be a good compromise considering the
difficulties 2. (bundled-npms) had and also it's much less intrusive -
other packages need not to care about our npm deps at all.
>
> --
> Daniel Lobato Garcia
>
> @dLobatog
> blog.daniellobato.me
> daniellobato.me
>
> GPG: http://keys.gnupg.net/pks/lookup?op=get=0x7A92D6DD38D6DE30
> Keybase: https://keybase.io/elobato
--
Daniel Lobato Garcia
@dLobatog
blog.daniellobato.me
daniellobato.me
GPG: http://keys.gnupg.net/pks/lookup?op=get=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
[foreman-dev] Status of RPM packaging for npm modules in Foreman
atog/npm2rpm Best, -- Daniel Lobato Garcia @dLobatog blog.daniellobato.me daniellobato.me GPG: http://keys.gnupg.net/pks/lookup?op=get=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] Rubocop cops in Foreman
I tried to voice my comments here https://github.com/theforeman/foreman/pull/3617 On 06/21, David Davis wrote: > In order to have a more consistent rubocop configuration across Foreman and > Katello, I’d like to bring some cops that Katello has disabled in its > rubocop configuration over to Foreman. These are cops that we’ve decided > are a little bit too strict. > > Currently they are disabled in the rubocop todo file in foreman meaning > they are *not* being enforced but they could potentially be if someone > removes them from the todo file. > > I’m hoping to get some feedback as to which ones people would like *not* to > be disabled. I’ll collect the feedback and then open a PR based on it. For > reference, here is our rubocop configuration in Katello: > > <https://github.com/Katello/katello/blob/master/.rubocop.yml> > <https://github.com/Katello/katello/blob/master/.rubocop.yml> > https://github.com/Katello/katello/blob/master/.rubocop.yml > > And here are the cops I’d like to disable: > > Style/LeadingCommentSpace > <http://www.rubydoc.info/github/bbatsov/rubocop/Rubocop/Cop/Style/LeadingCommentSpace> > Style/IfUnlessModifier > <http://www.rubydoc.info/github/bbatsov/rubocop/Rubocop/Cop/Style/IfUnlessModifier> > Style/RescueModifier > <http://www.rubydoc.info/github/bbatsov/rubocop/Rubocop/Cop/Style/RescueModifier> > Style/AssignmentInCondition > <http://www.rubydoc.info/github/bbatsov/rubocop/Rubocop/Cop/Lint/AssignmentInCondition> > Style/WhileUntilModifier > <http://www.rubydoc.info/github/bbatsov/rubocop/Rubocop/Cop/Style/WhileUntilModifier> > Style/AlignParameters > <http://www.rubydoc.info/github/bbatsov/rubocop/Rubocop/Cop/Style/AlignParameters> > Style/ParenthesesAroundCondition > <http://www.rubydoc.info/github/bbatsov/rubocop/Rubocop/Cop/Style/ParenthesesAroundCondition> > Style/DotPosition > <http://www.rubydoc.info/github/bbatsov/rubocop/Rubocop/Cop/Style/DotPosition> > Style/Lambda > <http://www.rubydoc.info/github/bbatsov/rubocop/Rubocop/Cop/Style/Lambda> > Style/RedundantSelf > <http://www.rubydoc.info/github/bbatsov/rubocop/Rubocop/Cop/Style/RedundantSelf> > Style/RedundantReturn > <http://www.rubydoc.info/github/bbatsov/rubocop/Rubocop/Cop/Style/RedundantReturn> > Style/SpaceInsideHashLiteralBraces > <http://www.rubydoc.info/github/bbatsov/rubocop/Rubocop/Cop/Style/SpaceInsideHashLiteralBraces> > Style/SingleLineBlockParams > <http://www.rubydoc.info/github/bbatsov/rubocop/Rubocop/Cop/Style/SingleLineBlockParams> > Style/Next <http://www.rubydoc.info/gems/rubocop/RuboCop/Cop/Style/Next> > Style/FormatString > <http://www.rubydoc.info/github/bbatsov/rubocop/Rubocop/Cop/Style/FormatString> > Style/GuardClause > <http://www.rubydoc.info/github/bbatsov/rubocop/Rubocop/Cop/Style/GuardClause> > Style/StringLiterals > <http://www.rubydoc.info/github/bbatsov/rubocop/Rubocop/Cop/Style/StringLiterals> > Style/WordArray > <http://www.rubydoc.info/github/bbatsov/rubocop/Rubocop/Cop/Style/WordArray> > Rails/ScopeArgs > <http://www.rubydoc.info/github/bbatsov/rubocop/Rubocop/Cop/Rails/ScopeArgs> > Style/EachWithObject > <http://www.rubydoc.info/gems/rubocop/RuboCop/Cop/Style/EachWithObject> > Style/SymbolProc > <http://www.rubydoc.info/gems/rubocop/RuboCop/Cop/Style/SymbolProc> > > Let me know if there are any questions. Thanks. > > David > > -- > 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=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] Revamping the news section of the website frontpage - design discussion
On 06/30, Greg Sutcliffe wrote: > This would make us very similar to sites such as centos.org, ovirt.org, > apache.org, gluster.org and so on, who all make sure there's some form of > "Latest News" that catches the users' eye within the screen area of the > very first page load. > > Attached is a rough mockup I did in Gimp using the "latest news" section > from ovirt.org. Clearly we can work on what content should be displayed - > it's the layout that I want to get right up front, since that's where the > work is. Putting the first few blog entries up front will also allow us to > remove the link from the top, since overcrowding has been mentioned as a > concern. Sorry, I think losing the whitespace (blue) we have, at the cost of moving the most important parts of the frontpage (description, 'get started' and 'learn more') isn't worth it. Also moving these things to the left looks worse IMO and make them seem less important. > > My second concern is about getting important info to people not loading the > frontpage, such as large events or important CVEs. This is less serious, > but we may as well consider it - according to the analytics, only 22% of > users have "/" as the landing page. However, the 2nd place is only 5% and > it quickly drops off from there, so the options seems to be (a) only the > frontpage, or (b) some kind of info on every page. > > The PR at [1] is a suggested option for this, used to highlight things we > think people really shouldn't miss. It's intended for infrequent use, maybe > a few times a year. I don't think it's good to have it always-on - it will > lose its impact value then. Honestly I'd prefer that (just one line!) for things like that, the yearly survey, releases, CVEs, critical events... I realize others will disagree. > So, voices wanted! I have a short-term goal of promoting the birthday > events as much as I can (the lovely people who have donated their time and > venues to us deserve the best promotion we can give back), but I also want > to get the revamp right. I'd like to hear: > > (a) does the proposed design work for you? No, sorry > (b) if not, what would be your counter-proposal for highlighting > news/events etc? Top banner (1 line at most) on top of every page? I think it'll be rather difficult, or impossible (not to mention slow) to keep everyone happy with this. If you can some designer to make your proposal of last news on the frontpage look good without making the main elements more important, I guess that'd work. https://github.com/theforeman/foreman/pull/3400 would also work great and no one has to change the frontpage in that case :) > (c) should we keep the top banner for occasional use? Yes. It'd be a pain to measure but there are certain actions we need from the community (testing RCs, filling the survey, upgrading, going to events...) that I think we'd get more input on if we had that in there. > Thanks! > > [1] https://github.com/theforeman/theforeman.org/pull/651 > > Greg > > -- > 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=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] Re: flot.js seems dead
On 06/20, gstei...@redhat.com wrote: > I've started working on replacing flot with patternfly and c3.js. This > change depends on the Webpack PR being merged. > > The implementation includes EcmaScript 2015 and React.js. > > I would be happy to receive comments on my work in the linked PR > <https://github.com/theforeman/foreman/pull/3603> Awesome! I'll do my best to review it and hopefully learn some flux in the meantime. I was wondering if you've taken a look at https://gerrit.ovirt.org/ovirt-engine-dashboard ? It's another project that uses Patternfly and has a few components already implemented. They're open to moving that kind of stuff to a shared repo, if you'd be willing to collaborate they're on IRC and mailing lists @ https://www.ovirt.org/community/ > > On Monday, May 4, 2015 at 12:13:47 PM UTC+3, Tomer Brisker wrote: > > > > Hello, > > I ran into a bug [1] today that originated from flot.js, the library we > > use for drawing all graphs in foreman. > > I was planning to submit a PR to get it fixed in the library and noticed > > the last commit was over a year ago. > > A bit of further investigation led to a thread on their mailing list [2] > > and an open issue [3] which seem to indicate that the project is indeed > > dead. > > > > While this still works for us right now with minor workarounds, we should > > start looking into finding a replacement library for charts that is > > actively maintained. > > This would require quite a few changes, so I think it won't make it in by > > 1.9, hopefully 1.10 will be a good target release for replacing it. > > If anyone has any comments or suggestions for a replacement (or wants to > > take over maintaining flot.js) feel free to reply. > > > > [1] http://projects.theforeman.org/issues/7533 > > [2] https://groups.google.com/forum/#!topic/flot-graphs/XLNK6eWRUlU > > [3] https://github.com/flot/flot/issues/1430 > > -- > > Have a nice day, > > Tomer Brisker > > > > -- > 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=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: Re: [foreman-dev] Foreman Sentry plugin
On 06/10, Brandon Weeks wrote: > As a start I've uploaded it to RubyGems, I'll take a look at > foreman-packaging to get it built into deps/rpms. debs are quite easy as any dependencies (sentry-raven) would not have to be packaged, bundler takes care of that. Feel free to copy a simple plugin like foreman_cockpit and modify it and you'll get it done easily. for rpms, you'd need to package sentry-raven too. Using 'gem2rpm gemname.gem > rubygem-gemname.spec', then 'spec2scl -i rubygem-gemname.spec' will get you 95% of the way there. Feel free to submit a PR like that then ping me and I'll try to point out the changes you need to do. https://github.com/theforeman/foreman-packaging/tree/rpm/develop contains some help in the README. You may want to try Dominic's new gem2rpm templates which convert gems to foreman-packaging specs with just 1 command :) https://github.com/theforeman/foreman-packaging/pull/1165 For both, Jenkins will try to build packages from your PR and it's quite fast so you can get feedback about what went wrong easily. After you have packages, installer support is trivial to add (https://github.com/theforeman/foreman-installer/pull/165/files) As always feel free to holler at us on IRC or github too for any help you may need with that! > > [0] https://rubygems.org/gems/foreman_sentry > > On Friday, June 10, 2016 at 1:11:41 AM UTC-7, Ewoud Kohl van Wijngaarden > wrote: > > > > On Thu, Jun 09, 2016 at 05:07:14PM -0700, Brandon Weeks wrote: > > > At Square we use Sentry <https://getsentry.com> for exception tracking > > > across all of our internal applications. To help my team detect and > > resolve > > > problems with our Foreman environment I created foreman_sentry > > > <https://github.com/brandonweeks/foreman_sentry>, a small plugin that > > loads > > > Raven <https://github.com/getsentry/raven-ruby>, the Sentry client for > > > Ruby. While the hosted version of Sentry is a paid product, the project > > > itself is open source <https://github.com/getsentry/sentry> and is free > > to > > > host yourself. > > > > As another Sentry user I think this is very interesting. Any plans to > > package 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. -- Daniel Lobato Garcia @dLobatog blog.daniellobato.me daniellobato.me GPG: http://keys.gnupg.net/pks/lookup?op=get=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
[foreman-dev] Re: Nominating Timo Goebel for theforeman/foreman commit access
Reminder - 2 days left if you have any objections or comments! On 06/02, Daniel Lobato Garcia wrote: > Hi devs, > > I'd like to nominate Timo Goebel (timogoebel on Github & IRC) for commit > access to theforeman/foreman repo. > > He's been contributing to the puppet modules, community-templates, bootdisk > and Foreman for some time, particularly on the VMWare/vsphere side of things. > He's been running Foreman on production for years already and gave > local talks about it.(www.meetup.com/AWS-Meetup-Karlsruhe/events/229036956/) > > Most importantly and the reason why I thought of him as a person that > could become a committer is his involvement on ipv6 support lately, > where he's been submitting consistently good code. > > I think he understands very well the problem domain, and he will be > committed to maintain and improve the code quality of the project, as > well as providing good feedback from a production installations. > > Some examples of his contributions: > > https://github.com/theforeman/foreman/pull/3420 > https://github.com/theforeman/foreman/pull/3424 > https://github.com/theforeman/foreman/pull/3498 > https://github.com/theforeman/foreman/pull/3499 > https://github.com/theforeman/foreman/commit/5131edbfab258c0862c987f238049ee81a1cd13f > https://github.com/theforeman/foreman/commit/8ca6c6bbc5242c29a8039d1e6a1d09d1a454164c > https://github.com/theforeman/foreman/commit/2328beb569d3f0e51043202d3a00a3b30879d244 > https://github.com/theforeman/puppet-puppet/pull/389 > https://github.com/theforeman/foreman_bootdisk/pull/19 > > Lastly I'd encourage him to start reviewing already! > > Objections or comments in private are welcome, but public replies to this > thread are preferred :) > > Best, > > -- > Daniel Lobato Garcia > > @dLobatog > blog.daniellobato.me > daniellobato.me > > GPG: http://keys.gnupg.net/pks/lookup?op=get=0x7A92D6DD38D6DE30 > Keybase: https://keybase.io/elobato -- Daniel Lobato Garcia @dLobatog blog.daniellobato.me daniellobato.me GPG: http://keys.gnupg.net/pks/lookup?op=get=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] smart-proxy rake test fails for me
On 06/07, paul kelly wrote: > Hi Folks, Hi! > I am attempting to run the smart-proxy tests and am getting some errors. > I suspect a mismatched gem somewhere. Could someone confirm that this > selection of gems is correct for running under ruby-2.0.0-p353? > Alternatively could I get a copy of this information from the Jenkins CI > environment? You can see what gems are installed here: http://ci.theforeman.org/job/test_proxy_develop_pr_core/804/puppet=4.3.0,ruby=2.0.0/consoleFull Anyway, what errors are you seeing when you run tests? Have you tried 'bundle exec rake test' (that uses gems in the smart-proxy bundle)? -- Daniel Lobato Garcia @dLobatog blog.daniellobato.me daniellobato.me GPG: http://keys.gnupg.net/pks/lookup?op=get=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
