Hello,
I'd like to know whether anyone would object if I added a support of full Chef
server installation support to foreman-installer. Note that our installer can
install puppet master and setup the integration with proxy and Foreman. My
goal is to have something similar for Chef.
I prepared a puppet module (our installer is puppet based) that sets all of
this (with correct installer parameters). If you want to review the code, you
can find it at [1]. Basically this would allow you to run installer like
foreman-installer
–foreman-foreman-url="https://facter fqdn/foreman"
–foreman-proxy-foreman-base-url="https://facter fqdn/foreman"
–enable-foreman-plugin-chef
–enable-foreman-plugin-tasks
–no-enable-puppet
–enable-foreman-proxy-plugin-chef
–enable-chef
–foreman-db-type mysql
–foreman-server-ssl-crl=""
–foreman-proxy-plugin-chef-server-url="https://facter fqdn/organizations/default"
–foreman-proxy-plugin-chef-client-name="pivotal"
–foreman-proxy-plugin-chef-private-key="/etc/opscode/pivotal.pem"
This would setup the Foreman, proxy and Chef server all in one host, with all
required plugins correctly configured. While it might not be best production
setup, it gives you something to test and play with very easily.
My question is, is anyone against this getting into foreman-installer core?
The more we're getting closer to CFGMGMT agnosticism the more we need
pluggable components. But with installer we currently don't have a way to do
this. So until we have scenarios [2] with plugin support, this seems as best
option to me.
[1] https://github.com/ares/puppet-chef
[2] https://groups.google.com/forum/#!msg/foreman-dev/nhK6zgLwnbI/AJ2hXeQ12aAJ
Thanks for comments
···
--
Marek
> Hello,
>
> I'd like to know whether anyone would object if I added a support of full Chef
> server installation support to foreman-installer. Note that our installer can
> install puppet master and setup the integration with proxy and Foreman. My
> goal is to have something similar for Chef.
>
> I prepared a puppet module (our installer is puppet based) that sets all of
> this (with correct installer parameters). If you want to review the code, you
> can find it at [1]. Basically this would allow you to run installer like
>
> foreman-installer
> --foreman-foreman-url="https://facter fqdn/foreman"
> --foreman-proxy-foreman-base-url="https://facter fqdn/foreman"
> --enable-foreman-plugin-chef
> --enable-foreman-plugin-tasks
> --no-enable-puppet
> --enable-foreman-proxy-plugin-chef
> --enable-chef
> --foreman-db-type mysql
> --foreman-server-ssl-crl=""
> --foreman-proxy-plugin-chef-server-url="https://facter > fqdn/organizations/default"
> --foreman-proxy-plugin-chef-client-name="pivotal"
> --foreman-proxy-plugin-chef-private-key="/etc/opscode/pivotal.pem"
>
> This would setup the Foreman, proxy and Chef server all in one host, with all
> required plugins correctly configured. While it might not be best production
> setup, it gives you something to test and play with very easily.
>
> My question is, is anyone against this getting into foreman-installer core?
> The more we're getting closer to CFGMGMT agnosticism the more we need
> pluggable components. But with installer we currently don't have a way to do
> this. So until we have scenarios [2] with plugin support, this seems as best
> option to me.
I think it's just fine to put it in foreman-installer for the moment.
···
On 04/07, Marek Hulan wrote:
>
> [1] https://github.com/ares/puppet-chef
> [2] https://groups.google.com/forum/#!msg/foreman-dev/nhK6zgLwnbI/AJ2hXeQ12aAJ
>
> Thanks for comments
>
> --
> 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+unsubscribe@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
–
Daniel Lobato Garcia
@eLobatoss
blog.daniellobato.me
daniellobato.me
GPG: http://keys.gnupg.net/pks/lookup?op=get&search=0x7A92D6DD38D6DE30
Keybase: https://keybase.io/elobato
Fine by me, though would you want to move puppet-chef into our GitHub
org and share the maintenance?
I'm not against adding new dependencies, but we're in the middle of a
big push towards future parser support for Puppet 4 and increasing the
quality of our modules. We need to either know that an external module
is well tested and of good quality already (it doesn't look it) or we
bring it in and make it so.
···
On 07/04/15 15:09, Marek Hulan wrote:
> I'd like to know whether anyone would object if I added a support of full Chef
> server installation support to foreman-installer. Note that our installer can
> install puppet master and setup the integration with proxy and Foreman. My
> goal is to have something similar for Chef.
>
> I prepared a puppet module (our installer is puppet based) that sets all of
> this (with correct installer parameters).
> [..]
> My question is, is anyone against this getting into foreman-installer core?
> The more we're getting closer to CFGMGMT agnosticism the more we need
> pluggable components. But with installer we currently don't have a way to do
> this. So until we have scenarios [2] with plugin support, this seems as best
> option to me.
>
> [1] https://github.com/ares/puppet-chef
–
Dominic Cleal
Red Hat Engineering
Answer in text below
> > I'd like to know whether anyone would object if I added a support of full
> > Chef server installation support to foreman-installer. Note that our
> > installer can install puppet master and setup the integration with proxy
> > and Foreman. My goal is to have something similar for Chef.
> >
> > I prepared a puppet module (our installer is puppet based) that sets all
> > of
> > this (with correct installer parameters).
> > […]
> > My question is, is anyone against this getting into foreman-installer
> > core?
> > The more we're getting closer to CFGMGMT agnosticism the more we need
> > pluggable components. But with installer we currently don't have a way to
> > do this. So until we have scenarios [2] with plugin support, this seems
> > as best option to me.
> >
> > [1] https://github.com/ares/puppet-chef
>
> Fine by me, though would you want to move puppet-chef into our GitHub
> org and share the maintenance?
That would be great, I wanted to know whether everyone is OK with it first.
> I'm not against adding new dependencies, but we're in the middle of a
> big push towards future parser support for Puppet 4 and increasing the
> quality of our modules. We need to either know that an external module
> is well tested and of good quality already (it doesn't look it) or we
> bring it in and make it so.
I'm happy to improve it before moving it if you or anyone else give me
directions.
Thanks
···
On Wednesday 08 of April 2015 10:23:03 Dominic Cleal wrote:
> On 07/04/15 15:09, Marek Hulan wrote:
–
Marek
That'd be good. The main things are to add some basic specs to check it
compiles (use rspec-puppet-facts), a standard Travis CI config etc (see
other modules or
https://github.com/theforeman/foreman-installer-modulesync), change
Modulefile to metadata.json and if you can, enable future parser and
strict variables testing (easier now than later!).
···
On 08/04/15 11:25, Marek Hulan wrote:
> Answer in text below
>
> On Wednesday 08 of April 2015 10:23:03 Dominic Cleal wrote:
>> On 07/04/15 15:09, Marek Hulan wrote:
>>> I'd like to know whether anyone would object if I added a support of full
>>> Chef server installation support to foreman-installer. Note that our
>>> installer can install puppet master and setup the integration with proxy
>>> and Foreman. My goal is to have something similar for Chef.
>>>
>>> I prepared a puppet module (our installer is puppet based) that sets all
>>> of
>>> this (with correct installer parameters).
>>> [..]
>>> My question is, is anyone against this getting into foreman-installer
>>> core?
>>> The more we're getting closer to CFGMGMT agnosticism the more we need
>>> pluggable components. But with installer we currently don't have a way to
>>> do this. So until we have scenarios [2] with plugin support, this seems
>>> as best option to me.
>>>
>>> [1] https://github.com/ares/puppet-chef
>>
>> Fine by me, though would you want to move puppet-chef into our GitHub
>> org and share the maintenance?
>
> That would be great, I wanted to know whether everyone is OK with it first.
>
>> I'm not against adding new dependencies, but we're in the middle of a
>> big push towards future parser support for Puppet 4 and increasing the
>> quality of our modules. We need to either know that an external module
>> is well tested and of good quality already (it doesn't look it) or we
>> bring it in and make it so.
>
> I'm happy to improve it before moving it if you or anyone else give me
> directions.
–
Dominic Cleal
Red Hat Engineering
