Re: [foreman-dev] [Infra] Reducing Test Matrix
Am 23.08.17 um 01:44 schrieb Eric D Helms: I would like to propose the following: 1) We drop sqlite3 entirely 2) We test all rubies on postgresql only 3) We pick the most widely used Ruby version and test mysql with that I think, Jenkins pipelines are a good thing and can make the Job configuration a lot easier. I'd like to to pitch some ideas. First of all I would propose putting the Jenkinsfile(s) in the repos alongside the code so it's more visible what happens and the job configuration follows the code lifecycle. I've also grown fond of the Docker Plugin for Jenkins. With that you can easily run tests under different ruby versions. I found that easier to setup then rvm. If you'd like, I can share the code snippets. But it's rather trivial to connfigure. You could also try to put the databases in a container. While I usually don't recommend this, it might be a good architectural choice for a CI system as you don't really need to persist data. It could also greatly decouple the jobs from the jenkins system. But first things first. One more thing: If we have more capacity, we could start replacing HoundCI by our own linting again. 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.
Re: [foreman-dev] [Infra] Reducing Test Matrix
After 1.16 branching, we will be dropping Ruby 2.1 which is only needed for Debian Jessie iirc. On Wed, Aug 23, 2017 at 2:44 AM, Eric D Helms wrote: > I am beginning to look at updating some of our test infrastructure by > re-writing Jenkins jobs into the pipeline plugin [1]. This is a new style, > with a different way of both writing and thinking about how jobs are > crafted. I've started this work by attempting to write jobs for both > Foreman and Katello [2]. > > The current test_develop job for Foreman (which runs after pull requests > are merged) is a 4x3 matrix resulting in 12 different configurations > running. They are: > > ruby: 2.1, 2.2, 2.3, 3.4 > databases: mysql, postgresql, sqlite3 > > I would like to propose the following: > > 1) We drop sqlite3 entirely > 2) We test all rubies on postgresql only > 3) We pick the most widely used Ruby version and test mysql with that > > This would effectively reduce the number of test runs in the matrix to 5 > which should in theory increase throughput of testing and keep things > focused on the most important pieces to test. Further, sqlite3 is not a > production database so I feel it not worth the resources (but it would only > add one more job to keep it). I also don't see how Ruby version should > affect database choice and thus find no reason to run the full matrix > across all rubies for Mysql. > > From what I think I know, of the Rubies: > > 2.2 -- used in RPM production > 2.1, 2.3, 2.4 -- used by Debian production > > [1] https://jenkins.io/doc/book/pipeline/ > [2] https://github.com/theforeman/foreman-infra/pull/321 > > -- > 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. > -- 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.
[foreman-dev] [Infra] Reducing Test Matrix
I am beginning to look at updating some of our test infrastructure by re-writing Jenkins jobs into the pipeline plugin [1]. This is a new style, with a different way of both writing and thinking about how jobs are crafted. I've started this work by attempting to write jobs for both Foreman and Katello [2]. The current test_develop job for Foreman (which runs after pull requests are merged) is a 4x3 matrix resulting in 12 different configurations running. They are: ruby: 2.1, 2.2, 2.3, 3.4 databases: mysql, postgresql, sqlite3 I would like to propose the following: 1) We drop sqlite3 entirely 2) We test all rubies on postgresql only 3) We pick the most widely used Ruby version and test mysql with that This would effectively reduce the number of test runs in the matrix to 5 which should in theory increase throughput of testing and keep things focused on the most important pieces to test. Further, sqlite3 is not a production database so I feel it not worth the resources (but it would only add one more job to keep it). I also don't see how Ruby version should affect database choice and thus find no reason to run the full matrix across all rubies for Mysql. >From what I think I know, of the Rubies: 2.2 -- used in RPM production 2.1, 2.3, 2.4 -- used by Debian production [1] https://jenkins.io/doc/book/pipeline/ [2] https://github.com/theforeman/foreman-infra/pull/321 -- 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] 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&search=0x7A92D6DD38D6DE30 Keybase: https://keybase.io/elobato -- You received this message because you are subscribed to the Google Groups "foreman-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to foreman-dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. signature.asc Description: PGP signature
Re: 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
> >
> > >
> > >
> > >
> > >
> > > --
> > > 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...@googlegroups.com .
> > > For more options, visit https://groups.google.com/d/optout.
> >
> >
> > --
> > Daniel Lobato Garcia
> >
> > @dLobatog
> > blog.daniellobato.me
> > daniellobato.me
> >
> > GPG: http://keys.gnupg.net/pks/lookup?op=get&search=0x7A92D6DD38D6DE30
> > Keybase: https://keybase.io/elobato
> >
>
> --
> You recei
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&search=0x7A92D6DD38D6DE30 > Keybase: https://keybase.io/elobato -- Daniel Lobato Garcia @dLobatog blog.daniellobato.me daniellobato.me GPG: http://keys.gnupg.net/pks/lookup?op=get&search=0x7A92D6DD38D6DE30 Keybase: https://keybase.io/elobato -- You received this message because you are subscribed to the Google Groups "foreman-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to foreman-dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. signature.asc Description: PGP signature
