[foreman-dev] CfgMgmtCamp 2018 tickets are available
Hi all, Quick heads up, if you're looking at coming to CfgMgmtCamp in February, then the first slice of tickets are now available (and you do need one - they're free but venue space is limited). I've got mine ;) http://cfgmgmtcamp.eu/index.html#registration 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] Discourse - summary of week 1
Please count me into Ivan category. Now with new mail experience, I want to have some time for reevaluation. If that feels as mailing list and can be used the same way, with forcing me to open webui just to use advanced features, such as poll or syntax highlight, I would lean more to pro side. But trial period would be prefered anyway. -- Marek On November 9, 2017 15:50:24 Greg Sutcliffe wrote: Hi all, If you've been avoiding the Discourse mega-thread because you're super busy, I hope this summary will be useful. I'll keep it short(ish) and still represent eveyone accurately (I hope). TLDR: cautiously positive overall, some great debate, next steps at the end of this mail Some stats so far: * 14 people have recovered password & logged in * 8 topics, 41 posts to Testing Area * 218 emails sent (that escalated fast, but can do 50k/month for free) * For the foreman-dev discussion: * 8 people involved * 35 replies (20 mine) So that's 7 people who've tried the UI but haven't commented yet, and a whole load more who haven't looked yet. On the discussion, I see (I hope this is fair!): * 3 in favour (myself, Eric, Neil) * 2 cautious (Martin, Ewoud) * 1 cautious, with a change to implementation (Ivan) * 1 against, countering with another solution (Lukas) * 1 neutral, just asking a question (Andrew) Eric is in favour of better communication tools. Neil supports the argument that there are users being turned away by mailing lists. Ewoud made the point that sometimes we have to accept changes to workflow to benefit the community. Martin & Ewoud both made good points about plain email being second class. The initial STMP provider was causing issues, we've moved to Mailgun and all seems fine with email now, see [1] for a threaded Mutt example. Lukas was clear that he's against a forum, and proposed a move to GNU Mailman plus Hyperkitty archive viewer. There was some good debate about the features/benefits/drawbacks of forums vs mailing lists here, so I encourage you to read those posts if you're undecided. Ivan seemed happier to try the forum out, but proposes running side-by-side with the mailing list for a trial period. My concern here was how to construct such a fair trial - again, worth a read. He also suggested using a forum for -users and a list for -dev. I agreed that's an option, but ideally we'd have everyone on the same platform. # What next? Most of the pushback seems to be on mailing list mode (entirely fair) but the root cause for that has been identified and fixed (it wasn't Discourse). Mailing list mode really does feel the same to me as Google Groups now (there's even a List-ID header to filter on), and I hope that feeling will be the same for others. Overall there seems enough support to working on this, but we have no need to rush to a conclusion. While we continue tests, I will now spend a little time on styling and setting it up to look like how we might *actually* use it: * I've changed the default view back to "Categories" from "Latest" * I think it's more informative for newcomers, but let me know your preference. * The imported lists are locked (view-only) so that we don't give the idea that posts here go back to the mailing lists. I'll also make: * A "Support" category (i.e foreman-users-alike) * A "Development" category (i.e. foreman-dev-alike) * An "Events" category for demos, conferences etc. * These will get inbound email addresses once Ohad is back next week. * I'll also try adding a template to the Support category, since templated posts was something that came up in an offline discussion. Testing Area will stay, it may as well for now. Feel free to play around in any of the boards. Other suggestions for things people would like to try are welcome! Discourse has many plugins[2] so I *may* try adding a few that could be useful. I don't want UI clutter, but integration with other systems is often useful. If you browse and see any good ones, let me know. We do need more traffic. Those who haven't activated their account yet, please do! Testing of @mentions, joining groups and using @group mentions, and trying the templates (once done) is especially welcome. [1] https://gist.github.com/ekohl/60f3b5bdc6559800835b9f2ea0df13c1 [2] https://meta.discourse.org/c/plugin -- You received this message because you are subscribed to the Google Groups "foreman-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to foreman-dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "foreman-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to foreman-dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [foreman-dev] Proposal: Move Foreman Jenkins Jobs to foreman-ci repository
On Thu, Nov 9, 2017 at 9:46 AM, Ewoud Kohl van Wijngaarden < ew...@kohlvanwijngaarden.nl> wrote: > On Thu, Nov 09, 2017 at 02:37:10PM +, Greg Sutcliffe wrote: > >> On 09/11/17 14:25, Ewoud Kohl van Wijngaarden wrote: >> >>> If a separate repository, would it not be as simple as adding a git clone? >>> >>> Possibly, I don't have that much insight into the entire deployment >>> flow. Hence my preference of making small changes since our backlog is >>> big enough already. Of course if you're willing to take it on then be my >>> guest. >>> >> >> Currently it's a Jenkins Job [1] that notices a change in the upstream >> repo, and deploys it to the puppetmaster. Should be trivial enough to >> make the changes you want there - adding a git submodule to the infra >> repo might "just work", looking at it. >> >> [1] http://ci.theforeman.org/job/deploy_puppet/ >> > > A git submodule might work - we wouldn't get automatic updates thus > doubling the work though. If you mean adding a separate repository to the > config then that could work well. Another option is we just move this out of puppet all together and a have a job that runs JJB whenever the repository updates to update the jobs (job-ception). > > > -- > 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 -- 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] Discourse - summary of week 1
Hi all, If you've been avoiding the Discourse mega-thread because you're super busy, I hope this summary will be useful. I'll keep it short(ish) and still represent eveyone accurately (I hope). TLDR: cautiously positive overall, some great debate, next steps at the end of this mail Some stats so far: * 14 people have recovered password & logged in * 8 topics, 41 posts to Testing Area * 218 emails sent (that escalated fast, but can do 50k/month for free) * For the foreman-dev discussion: * 8 people involved * 35 replies (20 mine) So that's 7 people who've tried the UI but haven't commented yet, and a whole load more who haven't looked yet. On the discussion, I see (I hope this is fair!): * 3 in favour (myself, Eric, Neil) * 2 cautious (Martin, Ewoud) * 1 cautious, with a change to implementation (Ivan) * 1 against, countering with another solution (Lukas) * 1 neutral, just asking a question (Andrew) Eric is in favour of better communication tools. Neil supports the argument that there are users being turned away by mailing lists. Ewoud made the point that sometimes we have to accept changes to workflow to benefit the community. Martin & Ewoud both made good points about plain email being second class. The initial STMP provider was causing issues, we've moved to Mailgun and all seems fine with email now, see [1] for a threaded Mutt example. Lukas was clear that he's against a forum, and proposed a move to GNU Mailman plus Hyperkitty archive viewer. There was some good debate about the features/benefits/drawbacks of forums vs mailing lists here, so I encourage you to read those posts if you're undecided. Ivan seemed happier to try the forum out, but proposes running side-by-side with the mailing list for a trial period. My concern here was how to construct such a fair trial - again, worth a read. He also suggested using a forum for -users and a list for -dev. I agreed that's an option, but ideally we'd have everyone on the same platform. # What next? Most of the pushback seems to be on mailing list mode (entirely fair) but the root cause for that has been identified and fixed (it wasn't Discourse). Mailing list mode really does feel the same to me as Google Groups now (there's even a List-ID header to filter on), and I hope that feeling will be the same for others. Overall there seems enough support to working on this, but we have no need to rush to a conclusion. While we continue tests, I will now spend a little time on styling and setting it up to look like how we might *actually* use it: * I've changed the default view back to "Categories" from "Latest" * I think it's more informative for newcomers, but let me know your preference. * The imported lists are locked (view-only) so that we don't give the idea that posts here go back to the mailing lists. I'll also make: * A "Support" category (i.e foreman-users-alike) * A "Development" category (i.e. foreman-dev-alike) * An "Events" category for demos, conferences etc. * These will get inbound email addresses once Ohad is back next week. * I'll also try adding a template to the Support category, since templated posts was something that came up in an offline discussion. Testing Area will stay, it may as well for now. Feel free to play around in any of the boards. Other suggestions for things people would like to try are welcome! Discourse has many plugins[2] so I *may* try adding a few that could be useful. I don't want UI clutter, but integration with other systems is often useful. If you browse and see any good ones, let me know. We do need more traffic. Those who haven't activated their account yet, please do! Testing of @mentions, joining groups and using @group mentions, and trying the templates (once done) is especially welcome. [1] https://gist.github.com/ekohl/60f3b5bdc6559800835b9f2ea0df13c1 [2] https://meta.discourse.org/c/plugin -- 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: OpenPGP digital signature
Re: [foreman-dev] speeding up tests
On úterý 7. listopadu 2017 11:12:31 CET Ivan Necas wrote: > On Tue, Nov 7, 2017 at 9:19 AM, Ohad Levy wrote: > > Hi, > > > > The challenge: > > > > As a developer, I feel under utilized waiting for tests, the current test > > suite for foreman core takes over an hour, multiply it by number of really > > simple code fixes based on comment and it takes up a good chunk of a day. > > Personally, I don't feel this issue: if it's 1 hour or 5 minutes: I'm > already doing > something else in the meantime, so I would not probably see much the > difference. Locally, I usually run just the test file that touches the code > I'm working on to have > the immediate feedback on those. Waiting a bit longer on the PR is a > price I'm willing to > pay for increasing the chance that my code runs as much as possible. I don't think it's any issue for me either. > > > I would like to suggest a short and long term solution, and would > > appreciate your feedback. > > > > Short-term: > > > > Break down test matrix into more specific groups, this will allow to > > re-trigger just a smaller part of the tests vs. the entire suit today, for > > example: > > * API tests > > * DB migrations > > * UI Integration tests > > * ... > > Not opposed. Seems like valid request. +1 > > Long term: > > > > Break down core into smaller repositories - This is probably a bigger > > topic > > then just tests, but its worth raising in this context as well.. the > > > benefits i see are: > The question: would this speed-up the things moving, in terms of getting > changes in? I would worry that the outcome would be just oposite of that. > > > * smaller repos - faster tests per repo (we would still need a plugin > > matrix kind of tests done at some point) > > We should solve the pluign matrix first, ideally on PR level: I would > recommend first mastering that before going with more split. I don't like the idea. My ceoncern is we'd have more repos without reviews. > > > * better review process - smaller repos would mean the maintainers of the > > repo actually care for all/most of the pr's - today its not the case - > > many > > PR's are handled by sub groups (e.g. anything under webpack folder is > > "someone else") > > But still, most of the reviewers at least see, what's going on there. I know > we could achieve this with more repos as well, but frankly, not sure it > would work that much in the real life. > > > * potentially better API between parts - e.g. we can create a schema > > specific repo (not saying its a good idea) - which will always work with a > > dummy rails app - in the long run - this will ensure our schema is > > resilient to upgrades and model changes in core. > > I miss the implication. Could you expand on the thoughts? > > > I would even go further and enable auto merge after review + successful > > tests, e.g. > > 1. PR is sent > > 2. repo tests are executed and pass > > 3. reviewer approve the change > > 4. larger test matrix is executed and pass > > 5. code get auto merged. > > This is ortogonal to any of the previous and makes sense to me. Good idea -- Marek -- You received this message because you are subscribed to the Google Groups "foreman-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to foreman-dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [foreman-dev] Proposal: Move Foreman Jenkins Jobs to foreman-ci repository
On Thu, Nov 09, 2017 at 02:37:10PM +, Greg Sutcliffe wrote: On 09/11/17 14:25, Ewoud Kohl van Wijngaarden wrote: If a separate repository, would it not be as simple as adding a git clone? Possibly, I don't have that much insight into the entire deployment flow. Hence my preference of making small changes since our backlog is big enough already. Of course if you're willing to take it on then be my guest. Currently it's a Jenkins Job [1] that notices a change in the upstream repo, and deploys it to the puppetmaster. Should be trivial enough to make the changes you want there - adding a git submodule to the infra repo might "just work", looking at it. [1] http://ci.theforeman.org/job/deploy_puppet/ A git submodule might work - we wouldn't get automatic updates thus doubling the work though. If you mean adding a separate repository to the config then that could work well. -- 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] speeding up tests
On čtvrtek 9. listopadu 2017 10:14:33 CET Tomas Strachota wrote: > On Tue, Nov 7, 2017 at 11:17 AM, Ivan Necas wrote: > > On Tue, Nov 7, 2017 at 9:29 AM, Lukas Zapletal wrote: > >> We should start tracking test breakages in time, if we have a test > >> that did not break for a year, lets delete it. As simple as that. It's > >> added value is almost zero. > >> > >> This is not out of my head, I've heard that on a talk somewhere. > >> Instead of deleting, we can move it to archive - run them on a nightly > >> basis, if we find this too much. Frankly, I prefer deletion. > > > > -1: the fact that the test doesn't fail in a year can be just due > > to fact that we have not worked on that area for some time. It might > > work for some project with strictly defined use-case, but for Foreman, > > I don't think thats' the case. > > -1 as well for deleting the tests. They become useful once you start > refactoring things even when the code wasn't touched for a long time. Another -1 for deleting based on time, +1 for revisting tests and deleting tests with zero value (there are such tests). Honestly I think the biggest performance improvement would be by manually going through tests and fixing them. Minimizing DB calls where possible, remove duplicated tests etc. -- Marek > > >> Also, let's ditch unit tests in favor of integration tests. We have a > >> lot of areas covered with both and this is extra work and slowing down > >> things. > > > > +1 for integration tests > unit tests: and I'm willing to talk about > > deleting unit-tests once we know that integration tests are covering the > > same. > > > > I feel unit-tests more important, when working on specific algorithm etc. > > We don't do it that often. We mostly integrate. > > +1 I see more value in integration tests in general. Unit tests for > algorithms are useful too. > I see less value in unit tests for attribute presence and simple > validations like uniqueness. > > >> LZ > >> > >> On Tue, Nov 7, 2017 at 9:19 AM, Ohad Levy wrote: > >>> Hi, > >>> > >>> The challenge: > >>> > >>> As a developer, I feel under utilized waiting for tests, the current > >>> test > >>> suite for foreman core takes over an hour, multiply it by number of > >>> really > >>> simple code fixes based on comment and it takes up a good chunk of a > >>> day. > >>> > >>> I would like to suggest a short and long term solution, and would > >>> appreciate your feedback. > >>> > >>> Short-term: > >>> > >>> Break down test matrix into more specific groups, this will allow to > >>> re-trigger just a smaller part of the tests vs. the entire suit today, > >>> for > >>> example: > >>> * API tests > >>> * DB migrations > >>> * UI Integration tests > >>> * ... > > That would definitely help to improve day-to-day developer's experience. > > >>> Long term: > >>> > >>> Break down core into smaller repositories - This is probably a bigger > >>> topic > >>> then just tests, but its worth raising in this context as well.. the > >>> benefits i see are: > >>> > >>> * smaller repos - faster tests per repo (we would still need a plugin > >>> matrix kind of tests done at some point) > >>> * better review process - smaller repos would mean the maintainers of > >>> the > >>> repo actually care for all/most of the pr's - today its not the case - > >>> many > >>> PR's are handled by sub groups (e.g. anything under webpack folder is > >>> "someone else") > >>> * potentially better API between parts - e.g. we can create a schema > >>> specific repo (not saying its a good idea) - which will always work with > >>> a > >>> dummy rails app - in the long run - this will ensure our schema is > >>> resilient to upgrades and model changes in core. > > The biggest benefit of splitting the repos is imho the need for > stabilizing the api between components. > I believe that there would be some transfer to stability of the whole > project. > >>> I would even go further and enable auto merge after review + successful > >>> tests, e.g. > >>> 1. PR is sent > >>> 2. repo tests are executed and pass > >>> 3. reviewer approve the change > >>> 4. larger test matrix is executed and pass > >>> 5. code get auto merged. > >>> > >>> -- > >>> You received this message because you are subscribed to the Google > >>> Groups > >>> "foreman-dev" group. > >>> To unsubscribe from this group and stop receiving emails from it, send > >>> an > >>> email to foreman-dev+unsubscr...@googlegroups.com. > >>> For more options, visit https://groups.google.com/d/optout. > >> > >> -- > >> Later, > >> > >> Lukas @lzap Zapletal > >> > >> -- > >> You received this message because you are subscribed to the Google Groups > >> "foreman-dev" group. To unsubscribe from this group and stop receiving > >> emails from it, send an email to > >> foreman-dev+unsubscr...@googlegroups.com. For more options, visit > >> https://groups.google.com/d/optout. > > > > -- > > You received this message because you are subscribed to the Google Groups
Re: [foreman-dev] Proposal: Move Foreman Jenkins Jobs to foreman-ci repository
On 09/11/17 14:25, Ewoud Kohl van Wijngaarden wrote: >> If a separate repository, would it not be as simple as adding a git >> clone? > > Possibly, I don't have that much insight into the entire deployment > flow. Hence my preference of making small changes since our backlog is > big enough already. Of course if you're willing to take it on then be my > guest. Currently it's a Jenkins Job [1] that notices a change in the upstream repo, and deploys it to the puppetmaster. Should be trivial enough to make the changes you want there - adding a git submodule to the infra repo might "just work", looking at it. [1] http://ci.theforeman.org/job/deploy_puppet/ -- 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] Proposal: Move Foreman Jenkins Jobs to foreman-ci repository
On Thu, Nov 09, 2017 at 09:04:55AM -0500, Eric D Helms wrote: On Thu, Nov 9, 2017 at 9:00 AM, Ewoud Kohl van Wijngaarden < ew...@kohlvanwijngaarden.nl> wrote: On Wed, Nov 08, 2017 at 07:35:04AM -0500, Eric D Helms wrote: All, I brought this idea up in a separate thread, but want to formalize it into it's own direct proposal. As of today, the Jenkins Job (JJB) configurations live buried inside the foreman-infra repository. I believe this makes them hard to discover [1] and awkward to work with being inside a puppet module. My proposal is: 1) Create foreman-ci github repository 2) Move everything under [1] to foreman-ci 3) Update the jenkins_job_builder puppet_module to clone this new repository Further, I think this will allow CI focused work to happen and be separate from the maintenance of our community infrastructure. +1 to making it more visible. I'm not sure whether a separate repo or a top level directory in foreman-infra is best. One benefit of a single repository is that they're somewhat tightly linked: the JJB version and the templates we use. I don't know when you say template here. What template? Sorry, that was a weird thing in my head: it's how we distribute the jenkins jobs. Besides the plain text files we also have some slave configs[1] and they're templated. I don't know if those should be moved too or translated into pure JJB files but it's part of how Jenkins is configured. [1]: https://github.com/theforeman/foreman-infra/tree/master/puppet/modules/slave/templates Would a we be able to move the directory to the top level and have a symlink at the puppet module level? If that'd work I'd prefer that as a first step since we wouldn't have to modify our current deployment model. If a separate repository, would it not be as simple as adding a git clone? Possibly, I don't have that much insight into the entire deployment flow. Hence my preference of making small changes since our backlog is big enough already. Of course if you're willing to take it on then be my guest. -- 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] Proposal: Move Foreman Jenkins Jobs to foreman-ci repository
On Thu, Nov 9, 2017 at 9:00 AM, Ewoud Kohl van Wijngaarden < ew...@kohlvanwijngaarden.nl> wrote: > On Wed, Nov 08, 2017 at 07:35:04AM -0500, Eric D Helms wrote: > >> All, >> >> I brought this idea up in a separate thread, but want to formalize it into >> it's own direct proposal. As of today, the Jenkins Job (JJB) >> configurations >> live buried inside the foreman-infra repository. I believe this makes them >> hard to discover [1] and awkward to work with being inside a puppet >> module. >> My proposal is: >> >> 1) Create foreman-ci github repository >> 2) Move everything under [1] to foreman-ci >> 3) Update the jenkins_job_builder puppet_module to clone this new >> repository >> >> Further, I think this will allow CI focused work to happen and be separate >> from the maintenance of our community infrastructure. >> > > +1 to making it more visible. > > I'm not sure whether a separate repo or a top level directory in > foreman-infra is best. One benefit of a single repository is that they're > somewhat tightly linked: the JJB version and the templates we use. > I don't know when you say template here. What template? > > Would a we be able to move the directory to the top level and have a > symlink at the puppet module level? If that'd work I'd prefer that as a > first step since we wouldn't have to modify our current deployment model. If a separate repository, would it not be as simple as adding a git clone? > > > Eric >> >> [1] >> https://github.com/theforeman/foreman-infra/tree/master/pupp >> et/modules/jenkins_job_builder/files/theforeman.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. > -- 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.
Re: [foreman-dev] Proposal: Move Foreman Jenkins Jobs to foreman-ci repository
On Wed, Nov 08, 2017 at 07:35:04AM -0500, Eric D Helms wrote: All, I brought this idea up in a separate thread, but want to formalize it into it's own direct proposal. As of today, the Jenkins Job (JJB) configurations live buried inside the foreman-infra repository. I believe this makes them hard to discover [1] and awkward to work with being inside a puppet module. My proposal is: 1) Create foreman-ci github repository 2) Move everything under [1] to foreman-ci 3) Update the jenkins_job_builder puppet_module to clone this new repository Further, I think this will allow CI focused work to happen and be separate from the maintenance of our community infrastructure. +1 to making it more visible. I'm not sure whether a separate repo or a top level directory in foreman-infra is best. One benefit of a single repository is that they're somewhat tightly linked: the JJB version and the templates we use. Would a we be able to move the directory to the top level and have a symlink at the puppet module level? If that'd work I'd prefer that as a first step since we wouldn't have to modify our current deployment model. Eric [1] https://github.com/theforeman/foreman-infra/tree/master/puppet/modules/jenkins_job_builder/files/theforeman.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.
Re: [foreman-dev] Proposal: Move Foreman Jenkins Jobs to foreman-ci repository
On Wed, 2017-11-08 at 07:35 -0500, Eric D Helms wrote: > All, > > I brought this idea up in a separate thread, but want to formalize it into > it's own direct > proposal. As of today, the Jenkins Job (JJB) configurations live buried > inside the foreman-infra > repository. I believe this makes them hard to discover [1] and awkward to > work with being inside a > puppet module. My proposal is: > > 1) Create foreman-ci github repository > 2) Move everything under [1] to foreman-ci > 3) Update the jenkins_job_builder puppet_module to clone this new repository > > Further, I think this will allow CI focused work to happen and be separate > from the maintenance of > our community infrastructure. > > > Eric > > [1] > https://github.com/theforeman/foreman-infra/tree/master/puppet/modules/jenkins_job_builder/fil > es/theforeman.org > We do something similar in upstream Pulp today with our jekins job templates, and it has worked out really well for us. It sounds like a good idea. -- 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: This is a digitally signed message part
Re: [foreman-dev] Proposal: Move Foreman Jenkins Jobs to foreman-ci repository
+1 It makes it better discoverable for new users/contributors and also makes the repo easier to consume by others (SatelliteQE uses it). On Wed, Nov 8, 2017 at 2:58 PM, Ohad Levy wrote: > > > On Wed, Nov 8, 2017 at 3:42 PM, Greg Sutcliffe > wrote: >> >> On 08/11/17 12:35, Eric D Helms wrote: >> > All, >> > >> > I brought this idea up in a separate thread, but want to formalize it >> > into >> > it's own direct proposal. As of today, the Jenkins Job (JJB) >> > configurations >> > live buried inside the foreman-infra repository. I believe this makes >> > them >> > hard to discover [1] and awkward to work with being inside a puppet >> > module. >> > My proposal is: >> > >> > 1) Create foreman-ci github repository >> > 2) Move everything under [1] to foreman-ci >> > 3) Update the jenkins_job_builder puppet_module to clone this new >> > repository >> > >> > Further, I think this will allow CI focused work to happen and be >> > separate >> > from the maintenance of our community infrastructure. >> >> +1 from me, its very hard to discover today. > > > +1 anything that makes it easier for a developer to understand the CI infra > better is a plus :) >> >> >> 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. -- Beste Grüße/Kind regards, Evgeni Golov Software Engineer Red Hat GmbH, http://www.de.redhat.com/, Registered seat: Grasbrunn, Commercial register: Amtsgericht Muenchen, HRB 153243, Managing Directors: Charles Cachera, Michael Cunningham, Michael O'Neill, Eric Shander -- 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] Propsing a move from Google Groups to Discourse
On 08/11/17 17:01, Ivan Necas wrote: > And, if we meet in some time (let's say 6 months from the kick off) > and look at the numbers, I think it would be much easier discussion > if we should ditch the list or not. Additionally, we would have 6 > months of hands on experience with Discourse. I'm going to assume we're talking about side-by-side for a single channel (i.e the users list). I'll focus on that, but I remain open to the option of running -dev on a list and -users on a forum, we can make that work. Still not my top choice, but doable. So, I'm all for following the data - in fact I'm actually studying Data Science at the moment in my spare time so I can be better at this for our community metrics in general (this course [1], good fun). What I think you're proposing is that we measure the amount of activity on both platforms after 6 months, and then use that as an indicator of how much people *like* each platform. The problem is that this experiment contains both systemic bais and a confounding variable. Firstly, the systemic bias: people will stay where the conversation is (i.e. the network effect). Unless everyone moves, no-one does. If we had zero users on both platforms at the start, this could probably be accounted for, but that's not the case. Secondly, the counfounding variable (nemesis of all data scientists). You're suggesting that "amount of activity" on a given platform (X) can be used to infer "willingness to use" that platform (Y). But this doesn't account for the procrastination problem (there are studies, I picked a couple [2,3]). People don't change if they don't *have* to, however much better the alternative is. So there's a variable affecting X but not Y that we can't account for, which means we can't use it for inference. > I'm not suggesting 100% agreement, on the other hand I'm serious > about listening carefully to the people that actually ARE active in > the community. 100% agree with that, that's exactly what this thread is for. I'll post that summary I mentioned shortly to try and loop some more voices in. Cheers, Greg [1] https://www.coursera.org/specializations/jhu-data-science [2] Opt-in vs opt-out organ donation - much higher donation rate with opt-out. People could *save lives* by filling out a form, and they don't. https://bmcmedicine.biomedcentral.com/articles/10.1186/s12916-014-0131-4 [3] Electricity costs. 14 million houses in the UK could be saving £200 per year (2016 data), but they don't switch. UK is actually considerating putting automatic tariff switching into law because people are so bad at this. https://www.gov.uk/government/publications/household-energy-savings-through-switching-supporting-evidence/many-households-could-save-around-200-per-year-through-switching-energy-supplier-basis-for-claim -- 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] Regular Foreman-core issue triage?
Writing this up inspired me to capture it for the long term [1]. I'd be happy to run the first one or two given my experience with it (and assuming the timeslot works) just to get into the groove. Note that our process for triaging does require some overall Redmine process change with the way we uses some of the empty and Recycle Bin releases. [1] https://github.com/theforeman/theforeman.org/pull/970 On Thu, Nov 9, 2017 at 7:54 AM, Greg Sutcliffe wrote: > On 08/11/17 16:47, Eric D Helms wrote: > [tons of useful stuff] > > Thanks Eric! I think that format will work for us too, might take a > little practice. We'll need volunteers to be the runner, ofc ;) > > On 09/11/17 07:03, Marek Hulan wrote: > > I'd join regularly, after few years for which I receive all > > notifications from redmine, I can confirm there are bugs without much > > attention. > > > > If we won't have representatives from all areas, we might need some > > tooling to ping people in redmine tickets. Again, after few years, I can > > tell that mentioning name in comment does not always work. There used to > > be a question plugin which works similarly as needinfo in BZ. Perhaps we > > could install it? > > http://www.redmine.org/projects/redmine/wiki/PluginQuestion is what > you're referring to right? Looks nice, I can look into adding it - some > Redmine work is definitely on my short-term todo list anyway. > > > Thanks Greg for bringing this up > > Still looking for suggested time slots. Perhaps I should create a poll? > > 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. > -- 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.
Re: [foreman-dev] Regular Foreman-core issue triage?
On 08/11/17 16:47, Eric D Helms wrote: [tons of useful stuff] Thanks Eric! I think that format will work for us too, might take a little practice. We'll need volunteers to be the runner, ofc ;) On 09/11/17 07:03, Marek Hulan wrote: > I'd join regularly, after few years for which I receive all > notifications from redmine, I can confirm there are bugs without much > attention. > > If we won't have representatives from all areas, we might need some > tooling to ping people in redmine tickets. Again, after few years, I can > tell that mentioning name in comment does not always work. There used to > be a question plugin which works similarly as needinfo in BZ. Perhaps we > could install it? http://www.redmine.org/projects/redmine/wiki/PluginQuestion is what you're referring to right? Looks nice, I can look into adding it - some Redmine work is definitely on my short-term todo list anyway. > Thanks Greg for bringing this up Still looking for suggested time slots. Perhaps I should create a poll? 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] [Event] Foreman Community Demo Items - Thu 16 Nov 3pm [BST]
I think there are some demo worthy PRs merged, is there a volunteer to demo them if they don't appear on agenda? I could take some. -- Marek On čtvrtek 9. listopadu 2017 13:28:23 CET Ori Rabin wrote: > Hi all, > > Demo time! As always, have a think for items which have been completed since > the last demo on 2017-10-26. There is a query that will show you items > completed (i.e. marked as closed) since the last demo [2]. Please add demo > items following the instructions on the agenda page [3]. > > If you can't be present but have something to show, add it to the > agenda and let me know - I'll be happy to talk about the feature in your > absence. Please do leave me enough time to familiarize myself with the > content > though :) > > [1] https://www.youtube.com/watch?v=QHzNIFjMpTM > [2] http://tinyurl.com/ydbo6a43 > [3] > http://projects.theforeman.org/projects/foreman/wiki/Current_Sprint_Informat > ion > > -- > Ori > IRC: orabin -- 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] Status of the nightlies
Hello all, tl;dr: nightlies are fixed, we're staying on top of them. report issues As you might have picked up, the nightlies were a bit unstable and unreliable lately. The biggest problem was that core and packaging drifted apart. For now this has been synced up. Now the challenge is to keep them synced up. For starters we introduced code owners[1]. The idea is that we have files for which we consider the packaging team the owner. They should be involved in any PR which changes these files so we can act on changes rather than seeing the nightlies fail. A compounding facter is that bundler does check dependencies where npm doesn't. With a (current) lack of tooling manual work must suffice. This is currently not yet working since the packaging team doesn't have merge permissions and even then we don't know how well it'll work in practice. Time and experience will tell. If you have a change that might affect packaging, feel free to ask @theforeman/packaging on github. In the longer term we should develop tooling that can automatically point us to problems and help us respond faster to changes. We've also talked about vendorizing NPM packages. While this is still planned, there are other high priority items (Foreman tasks to core, Rail 5.1) so no promises on the timeline. Until then we have our current solution that does work and we know how to handle. [1] https://github.com/theforeman/foreman/commit/17501e48cea4f62ee23dc04dc7a153ce3b059278 -- 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] [Event] Foreman Community Demo Items - Thu 16 Nov 3pm [BST]
Hi all, Demo time! As always, have a think for items which have been completed since the last demo on 2017-10-26. There is a query that will show you items completed (i.e. marked as closed) since the last demo [2]. Please add demo items following the instructions on the agenda page [3]. If you can't be present but have something to show, add it to the agenda and let me know - I'll be happy to talk about the feature in your absence. Please do leave me enough time to familiarize myself with the content though :) [1] https://www.youtube.com/watch?v=QHzNIFjMpTM [2] http://tinyurl.com/ydbo6a43 [3] http://projects.theforeman.org/projects/foreman/wiki/Current_Sprint_Information -- Ori IRC: orabin -- 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] Propsing a move from Google Groups to Discourse
Another update on this, almost there :) Threading now apears entirely functional. Ewoud and I ran a private test using Mailgun last night (so as not to spam everyone in case it was still broken). As you can see, in this Gist, it appears to be working in Mutt: https://gist.github.com/ekohl/60f3b5bdc6559800835b9f2ea0df13c1 Email support now feels pretty much the same to what we have today. There's even a List-ID in the headers to filter on. I've also reduced the email send delay to 5 mins, and I'm waiting for Ohad to set up an MX record for me so we can handle inbound mail directly. That will bring us from 15mins (5 min polling + 10 min delay) down to just 5 min, which is acceptable I think. I'll update again once I have the MX record. Only Ohad can do this, so my hands are tied. 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. signature.asc Description: OpenPGP digital signature
Re: [foreman-dev] speeding up tests
On Tue, Nov 7, 2017 at 11:17 AM, Ivan Necas wrote: > On Tue, Nov 7, 2017 at 9:29 AM, Lukas Zapletal wrote: >> We should start tracking test breakages in time, if we have a test >> that did not break for a year, lets delete it. As simple as that. It's >> added value is almost zero. >> >> This is not out of my head, I've heard that on a talk somewhere. >> Instead of deleting, we can move it to archive - run them on a nightly >> basis, if we find this too much. Frankly, I prefer deletion. > > -1: the fact that the test doesn't fail in a year can be just due > to fact that we have not worked on that area for some time. It might > work for some project with strictly defined use-case, but for Foreman, > I don't think thats' the case. > -1 as well for deleting the tests. They become useful once you start refactoring things even when the code wasn't touched for a long time. >> >> Also, let's ditch unit tests in favor of integration tests. We have a >> lot of areas covered with both and this is extra work and slowing down >> things. > > +1 for integration tests > unit tests: and I'm willing to talk about deleting > unit-tests once we know that integration tests are covering the same. > > I feel unit-tests more important, when working on specific algorithm etc. > We don't do it that often. We mostly integrate. +1 I see more value in integration tests in general. Unit tests for algorithms are useful too. I see less value in unit tests for attribute presence and simple validations like uniqueness. > >> >> LZ >> >> On Tue, Nov 7, 2017 at 9:19 AM, Ohad Levy wrote: >>> Hi, >>> >>> The challenge: >>> >>> As a developer, I feel under utilized waiting for tests, the current test >>> suite for foreman core takes over an hour, multiply it by number of really >>> simple code fixes based on comment and it takes up a good chunk of a day. >>> >>> I would like to suggest a short and long term solution, and would appreciate >>> your feedback. >>> >>> Short-term: >>> >>> Break down test matrix into more specific groups, this will allow to >>> re-trigger just a smaller part of the tests vs. the entire suit today, for >>> example: >>> * API tests >>> * DB migrations >>> * UI Integration tests >>> * ... That would definitely help to improve day-to-day developer's experience. >>> >>> Long term: >>> >>> Break down core into smaller repositories - This is probably a bigger topic >>> then just tests, but its worth raising in this context as well.. the >>> benefits i see are: >>> >>> * smaller repos - faster tests per repo (we would still need a plugin matrix >>> kind of tests done at some point) >>> * better review process - smaller repos would mean the maintainers of the >>> repo actually care for all/most of the pr's - today its not the case - many >>> PR's are handled by sub groups (e.g. anything under webpack folder is >>> "someone else") >>> * potentially better API between parts - e.g. we can create a schema >>> specific repo (not saying its a good idea) - which will always work with a >>> dummy rails app - in the long run - this will ensure our schema is resilient >>> to upgrades and model changes in core. The biggest benefit of splitting the repos is imho the need for stabilizing the api between components. I believe that there would be some transfer to stability of the whole project. >>> >>> I would even go further and enable auto merge after review + successful >>> tests, e.g. >>> 1. PR is sent >>> 2. repo tests are executed and pass >>> 3. reviewer approve the change >>> 4. larger test matrix is executed and pass >>> 5. code get auto merged. >>> >>> -- >>> You received this message because you are subscribed to the Google Groups >>> "foreman-dev" group. >>> To unsubscribe from this group and stop receiving emails from it, send an >>> email to foreman-dev+unsubscr...@googlegroups.com. >>> For more options, visit https://groups.google.com/d/optout. >> >> >> >> -- >> Later, >> Lukas @lzap Zapletal >> >> -- >> You received this message because you are subscribed to the Google Groups >> "foreman-dev" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to foreman-dev+unsubscr...@googlegroups.com. >> For more options, visit https://groups.google.com/d/optout. > > -- > You received this message because you are subscribed to the Google Groups > "foreman-dev" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to foreman-dev+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "foreman-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to foreman-dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
