Some of you have probably noticed: the Foreman Remote Execution plugin into smart proxy
is not compatible with Ruby 1.8.7: the main reason for this is this ancient version is
not sufficient for any concurrency work (that we obviously need to do).
Concurrency is not the only flaw that Ruby 1.8.7 has, for example we're seeing
segfaults with puppet (both with installer and when running the puppet master), caused by
garbage collector (with the workaround of adding '–profile' into puppet args: this doesn't
seem like something we should be happy about…
I don't understand all the consequences for dropping Ruby 1.8.7 for the whole codebase,
but I can definitely see the benefits we would have when doing so.
Therefore, my questions are:
would it be possible for the smart proxy to drop 1.8.7 support and move to scl on rhel6 as part of Foreman 1.10?
how would this affect the Debian world?
would it be possible to do the same for puppet?
The questions 1 and 2 really important for the remote execution team, as that
affects our further steps for making the feature running on rhel6.
The 3. question i important for anyone constrained to run on rhel6.
> Therefore, my questions are:
>
> 1. would it be possible for the smart proxy to drop 1.8.7 support and move to scl on rhel6 as part of Foreman 1.10?
The proxy wouldn't be able to automatically load its dependency on the
Puppet library on a packaged installation, it'd need frigging with load
paths or removal of "require 'puppet'".
> 2. how would this affect the Debian world?
3 of 4 distributions already use Ruby 1.9 or higher. 12.04 is probably
the only one that typically runs the smart proxy on Ruby 1.8.7 (being
the alternatives default), but that's probably easy to change via a
shebang or similar like we did with Foreman core, via the "foreman-ruby"
symlink and PassengerRuby.
> 3. would it be possible to do the same for puppet?
Puppet 4's AIO packages already provide a newer version of Ruby, so
supporting 4 in Foreman would be a logical option.
We don't distribute Puppet today, and I think it'd be a really bad idea
to provide another project's packages in an SCL configuration.
> Hi,
>
> Some of you have probably noticed: the Foreman Remote Execution plugin into smart proxy
> is not compatible with Ruby 1.8.7: the main reason for this is this ancient version is
> not sufficient for any concurrency work (that we obviously need to do).
>
> Concurrency is not the only flaw that Ruby 1.8.7 has, for example we're seeing
> segfaults with puppet (both with installer and when running the puppet master), caused by
> garbage collector (with the workaround of adding '–profile' into puppet args: this doesn't
> seem like something we should be happy about…
>
> I don't understand all the consequences for dropping Ruby 1.8.7 for the whole codebase,
> but I can definitely see the benefits we would have when doing so.
>
> Therefore, my questions are:
>
> 1. would it be possible for the smart proxy to drop 1.8.7 support and move to scl on rhel6 as part of Foreman 1.10?
In that case I'd move to SCL for every EL we support just to keep our
sanity.
> 2. how would this affect the Debian world?
Currently I think Ubuntu 12.04 still runs an old ruby, but we already
use the brightbox PPA for foreman so I think that could be re-used.
> 3. would it be possible to do the same for puppet?
This is a rather invasive change that I expect many of our users would
not like, but maybe others have a different opinion.
···
On Fri, Aug 28, 2015 at 08:04:45AM -0400, Ivan Necas wrote:
> > 1. would it be possible for the smart proxy to drop 1.8.7 support and move to scl on rhel6 as part of Foreman 1.10?
>
> The proxy wouldn't be able to automatically load its dependency on the
> Puppet library on a packaged installation, it'd need frigging with load
> paths or removal of "require 'puppet'".
Wild idea: We can move the parsing code into an external app that can
load puppet and stuff returning JSON/YAML with the expected output into
SCL-enabled Ruby1.9+ proxy.
This spawns an extra process, yes, but the operation is already pretty
expensive and users do not do this 10 times a minute.
Yeah indeed, I think that's probably the least worst solution and would
also help when supporting AIO packages.
···
On 01/09/15 13:09, Lukas Zapletal wrote:
>>> 1. would it be possible for the smart proxy to drop 1.8.7 support and move to scl on rhel6 as part of Foreman 1.10?
>>
>> The proxy wouldn't be able to automatically load its dependency on the
>> Puppet library on a packaged installation, it'd need frigging with load
>> paths or removal of "require 'puppet'".
>
> Wild idea: We can move the parsing code into an external app that can
> load puppet and stuff returning JSON/YAML with the expected output into
> SCL-enabled Ruby1.9+ proxy.
>
> This spawns an extra process, yes, but the operation is already pretty
> expensive and users do not do this 10 times a minute.
I've considered this as well and even talked about it with Dominic at
fosdem/cfgmgmtcamp/puppetcamp earlier this year. One benefit you didn't
mention is that you decouple puppet which makes the transition to puppet
4 easier. If there is a defined interface between puppet and smart-proxy
then it can use puppetlabs-strings1 rather than the current parsing
code for puppet 3.7+.
I believe this could be a good change.
···
On Tue, Sep 01, 2015 at 02:09:26PM +0200, Lukas Zapletal wrote:
> > > 1. would it be possible for the smart proxy to drop 1.8.7 support and move to scl on rhel6 as part of Foreman 1.10?
> >
> > The proxy wouldn't be able to automatically load its dependency on the
> > Puppet library on a packaged installation, it'd need frigging with load
> > paths or removal of "require 'puppet'".
>
> Wild idea: We can move the parsing code into an external app that can
> load puppet and stuff returning JSON/YAML with the expected output into
> SCL-enabled Ruby1.9+ proxy.
>
> This spawns an extra process, yes, but the operation is already pretty
> expensive and users do not do this 10 times a minute.
When touching this area, we should consider migrating the proxy to use kafo
parsers gem [1] so we:
a) have just one parsing logic to maintain,
b) get more data about class parameters,
c) work on puppet 4 parsing only once
I know c) is subset of a) but I find it important enough to repeat Also if
we could use kafo parsers maybe we don't need to run the whole proxy but just
some wrapping script?
···
On Tuesday 01 of September 2015 14:29:39 Ewoud Kohl van Wijngaarden wrote:
> On Tue, Sep 01, 2015 at 02:09:26PM +0200, Lukas Zapletal wrote:
> > > > 1. would it be possible for the smart proxy to drop 1.8.7 support and
> > > > move to scl on rhel6 as part of Foreman 1.10?> >
> > > The proxy wouldn't be able to automatically load its dependency on the
> > > Puppet library on a packaged installation, it'd need frigging with load
> > > paths or removal of "require 'puppet'".
> >
> > Wild idea: We can move the parsing code into an external app that can
> > load puppet and stuff returning JSON/YAML with the expected output into
> > SCL-enabled Ruby1.9+ proxy.
> >
> > This spawns an extra process, yes, but the operation is already pretty
> > expensive and users do not do this 10 times a minute.
>
> I've considered this as well and even talked about it with Dominic at
> fosdem/cfgmgmtcamp/puppetcamp earlier this year. One benefit you didn't
> mention is that you decouple puppet which makes the transition to puppet
> 4 easier. If there is a defined interface between puppet and smart-proxy
> then it can use puppetlabs-strings[1] rather than the current parsing
> code for puppet 3.7+.
>
> I believe this could be a good change.
>
> [1]: https://github.com/puppetlabs/puppetlabs-strings
It could give a lot more value as well, like passing on documentation
strings and types to foreman. I certainly like this idea.
···
On Tue, Sep 01, 2015 at 05:34:39PM +0200, Marek Hulan wrote:
> On Tuesday 01 of September 2015 14:29:39 Ewoud Kohl van Wijngaarden wrote:
> > On Tue, Sep 01, 2015 at 02:09:26PM +0200, Lukas Zapletal wrote:
> > > > > 1. would it be possible for the smart proxy to drop 1.8.7 support and
> > > > > move to scl on rhel6 as part of Foreman 1.10?> >
> > > > The proxy wouldn't be able to automatically load its dependency on the
> > > > Puppet library on a packaged installation, it'd need frigging with load
> > > > paths or removal of "require 'puppet'".
> > >
> > > Wild idea: We can move the parsing code into an external app that can
> > > load puppet and stuff returning JSON/YAML with the expected output into
> > > SCL-enabled Ruby1.9+ proxy.
> > >
> > > This spawns an extra process, yes, but the operation is already pretty
> > > expensive and users do not do this 10 times a minute.
> >
> > I've considered this as well and even talked about it with Dominic at
> > fosdem/cfgmgmtcamp/puppetcamp earlier this year. One benefit you didn't
> > mention is that you decouple puppet which makes the transition to puppet
> > 4 easier. If there is a defined interface between puppet and smart-proxy
> > then it can use puppetlabs-strings[1] rather than the current parsing
> > code for puppet 3.7+.
> >
> > I believe this could be a good change.
> >
> > [1]: https://github.com/puppetlabs/puppetlabs-strings
>
> When touching this area, we should consider migrating the proxy to use kafo
> parsers gem [1] so we:
> a) have just one parsing logic to maintain,
> b) get more data about class parameters,
> c) work on puppet 4 parsing only once
>
> I know c) is subset of a) but I find it important enough to repeat :-) Also if
> we could use kafo parsers maybe we don't need to run the whole proxy but just
> some wrapping script?
>
> [1] https://github.com/theforeman/kafo_parsers
Ok, let me summarize where we got so far (please correct me, if I got it wrong)
it doesn't make sense for us to do the effort of moving puppet to SCL
it makes sense to decouple puppet from smart proxy, which would mean we can run proxy
in scl
it makes sense to run the proxy in scl regardless the rhel versions, so we
have more consistent runtimes
The question I have to ask now is:
Would it be realistic for this to be part of Foreman 1.10?
If not, could we count on the fact that it will happen for Foreman 1.11?
This questions are very important for us, as they influence the steps
we do in remote execution, to make the feature available on affected OSes.
Thanks
– Ivan
···
----- Original Message -----
> On Tue, Sep 01, 2015 at 05:34:39PM +0200, Marek Hulan wrote:
> > On Tuesday 01 of September 2015 14:29:39 Ewoud Kohl van Wijngaarden wrote:
> > > On Tue, Sep 01, 2015 at 02:09:26PM +0200, Lukas Zapletal wrote:
> > > > > > 1. would it be possible for the smart proxy to drop 1.8.7 support
> > > > > > and
> > > > > > move to scl on rhel6 as part of Foreman 1.10?> >
> > > > > The proxy wouldn't be able to automatically load its dependency on
> > > > > the
> > > > > Puppet library on a packaged installation, it'd need frigging with
> > > > > load
> > > > > paths or removal of "require 'puppet'".
> > > >
> > > > Wild idea: We can move the parsing code into an external app that can
> > > > load puppet and stuff returning JSON/YAML with the expected output into
> > > > SCL-enabled Ruby1.9+ proxy.
> > > >
> > > > This spawns an extra process, yes, but the operation is already pretty
> > > > expensive and users do not do this 10 times a minute.
> > >
> > > I've considered this as well and even talked about it with Dominic at
> > > fosdem/cfgmgmtcamp/puppetcamp earlier this year. One benefit you didn't
> > > mention is that you decouple puppet which makes the transition to puppet
> > > 4 easier. If there is a defined interface between puppet and smart-proxy
> > > then it can use puppetlabs-strings[1] rather than the current parsing
> > > code for puppet 3.7+.
> > >
> > > I believe this could be a good change.
> > >
> > > [1]: https://github.com/puppetlabs/puppetlabs-strings
> >
> > When touching this area, we should consider migrating the proxy to use kafo
> > parsers gem [1] so we:
> > a) have just one parsing logic to maintain,
> > b) get more data about class parameters,
> > c) work on puppet 4 parsing only once
> >
> > I know c) is subset of a) but I find it important enough to repeat :-) Also
> > if
> > we could use kafo parsers maybe we don't need to run the whole proxy but
> > just
> > some wrapping script?
> >
> > [1] https://github.com/theforeman/kafo_parsers
>
> It could give a lot more value as well, like passing on documentation
> strings and types to foreman. I certainly like this 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+unsubscribe@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>
> Would it be realistic for this to be part of Foreman 1.10?
>
> If not, could we count on the fact that it will happen for Foreman 1.11?
>
> This questions are very important for us, as they influence the steps
> we do in remote execution, to make the feature available on affected OSes.
I think the only right way is to do evaluation and pick up this task
under your umbrella
has any of this puppet4 goodness been put into any branches we can
experiment with?
···
On Thursday, September 3, 2015 at 2:15:14 PM UTC-5, Lukas Zapletal wrote:
>
> > Would it be realistic for this to be part of Foreman 1.10?
> >
> > If not, could we count on the fact that it will happen for Foreman 1.11?
> >
> > This questions are very important for us, as they influence the steps
> > we do in remote execution, to make the feature available on affected
> OSes.
>
> I think the only right way is to do evaluation and pick up this task
> under your umbrella ;-)
>
> --
> Later,
> Lukas #lzap Zapletal
>
The remote execution team will need to look into the smart proxy on software collections
and ability to load the puppet from different source soon, probably next
I'm not aware about other work done with respect to $subject, but I might be
wrong.
– Ivan
···
----- Original Message -----
> has any of this puppet4 goodness been put into any branches we can
> experiment with?
>
> On Thursday, September 3, 2015 at 2:15:14 PM UTC-5, Lukas Zapletal wrote:
> >
> > > Would it be realistic for this to be part of Foreman 1.10?
> > >
> > > If not, could we count on the fact that it will happen for Foreman 1.11?
> > >
> > > This questions are very important for us, as they influence the steps
> > > we do in remote execution, to make the feature available on affected
> > OSes.
> >
> > I think the only right way is to do evaluation and pick up this task
> > under your umbrella ;-)
> >
> > --
> > 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+unsubscribe@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>
Also if