For LiveCD feature we need to extend foreman-installer. Two major
features we would like to add are
support for multiple installation scenarios (preselected installer
configuration)
support for installer plugins.
Example use case might be converting Katello installer into scenario(s)
implemented as plugin of the Foreman installer. Another example might be
plugin providing most typical installer scenarios.
Draft of necessary changes we identified follows:
Scenario:
we will use config file as it is now and extend it with name and
description to define scenario
each config file will have answer file
With this design we can avoid new config file format and have simple
upgrade path.
Multiple config files:
there will be one common directory (e.g.
/etc/foreman/installer-config.d/) where configs are stored
after the installer run the config and answer file with customized
options will be saved per selected scenario
link to last used answer/config file will help to determine what
config should be used during installer re-run
installer script has to know location of config.d/ and name of the
default config file
Installer plugins:
check scripts should be listed in config or turned into hooks
hooks_dir will be list so the hooks from the plugin can be merged with
the default ones
modules_dir will be list so the modules from the plugin can be merged
with the default ones
config file has to be able to reference resources in plugins location
Things to resolve:
how to behave when installer finds multiple scenarios and none is
specified by user. (should we offer selection or use the default? new
ideas to improve UX?)
how to setup installer before config file is selected i.e. during
scenario selection (should we use data from default config?)
If you have any concerns, please let me know, questions and ideas are
welcome as always,
Some questions inline off the top of my head. Also, if you have not seen, I
encourage you to look at our latest changes to katello-installer whereby we
are using sub-packages for each of our different installers
(capsule-installer, katello-installer, katello-devel-installer,
sam-installer) and using a base package for holding common bits (hooks,
modules) – https://github.com/Katello/katello-installer/blob/master/katello-installer.spec
Eric
> For LiveCD feature we need to extend foreman-installer. Two major
> features we would like to add are
> - support for multiple installation scenarios (preselected installer
> configuration)
> - support for installer plugins.
>
> Example use case might be converting Katello installer into scenario(s)
> implemented as plugin of the Foreman installer. Another example might be
> plugin providing most typical installer scenarios.
>
> Draft of necessary changes we identified follows:
>
> Scenario:
> - we will use config file as it is now and extend it with name and
> description to define scenario
> - each config file will have answer file
> With this design we can avoid new config file format and have simple
> upgrade path.
>
What if two scenarios conflict? e.g. As it stands now, running
foreman-installer scenario after Katello installer could break the entire
setup. I would recommend looking at my email about moving Katello to a
plugin that can be added to a Foreman for some information on our current
issues around installation.
>
> Multiple config files:
> - there will be one common directory (e.g.
> /etc/foreman/installer-config.d/) where configs are stored
> - after the installer run the config and answer file with customized
> options will be saved per selected scenario
> - link to last used answer/config file will help to determine what config
> should be used during installer re-run
> - installer script has to know location of config.d/ and name of the
> default config file
>
> Installer plugins:
> - check scripts should be listed in config or turned into hooks
> - hooks_dir will be list so the hooks from the plugin can be merged with
> the default ones
>
How might ordering be handled here if needed?
> - modules_dir will be list so the modules from the plugin can be merged
> with the default ones
>
Will this work if two scenarios lay down the same or differing versions of
the same module? Will plugins be able to carry just the modules they need
to add and rely on a core set?
···
On Mon, Jan 12, 2015 at 7:59 AM, Martin Bačovský wrote:
config file has to be able to reference resources in plugins location
Things to resolve:
how to behave when installer finds multiple scenarios and none is
specified by user. (should we offer selection or use the default? new ideas
to improve UX?)
how to setup installer before config file is selected i.e. during
scenario selection (should we use data from default config?)
If you have any concerns, please let me know, questions and ideas are
welcome as always,
+1 for converting katello-installer to be a foreman plugin. Be warned
it may be complex though - ehelms & I looked at it last year and had
to back away from it due to time constraints, but if you can solve it,
that would be awesome.
> For LiveCD feature we need to extend foreman-installer. Two major
> features we would like to add are
> - support for multiple installation scenarios (preselected installer
> configuration)
> - support for installer plugins.
>
> Example use case might be converting Katello installer into scenario(s)
> implemented as plugin of the Foreman installer. Another example might be
> plugin providing most typical installer scenarios.
>
> Draft of necessary changes we identified follows:
>
> Scenario:
> - we will use config file as it is now and extend it with name and
> description to define scenario
> - each config file will have answer file
> With this design we can avoid new config file format and have simple
> upgrade path.
I don't think the kafo config files are a particularly big deal to
change, so change it if you need to.
> Multiple config files:
> - there will be one common directory (e.g.
> /etc/foreman/installer-config.d/) where configs are stored
> - after the installer run the config and answer file with customized
> options will be saved per selected scenario
> - link to last used answer/config file will help to determine what
> config should be used during installer re-run
> - installer script has to know location of config.d/ and name of the
> default config file
>
> Installer plugins:
> - check scripts should be listed in config or turned into hooks
> - hooks_dir will be list so the hooks from the plugin can be merged with
> the default ones
> - modules_dir will be list so the modules from the plugin can be merged
> with the default ones
> - config file has to be able to reference resources in plugins location
>
> Things to resolve:
> - how to behave when installer finds multiple scenarios and none is
> specified by user. (should we offer selection or use the default? new
> ideas to improve UX?)
> - how to setup installer before config file is selected i.e. during
> scenario selection (should we use data from default config?)
Please consider automated unit testing of these configurations, and
especially the interactions with plugins (yet more?). The very basic
configuration we have today in foreman-installer is prone to errors
already, so to add any complexity means it needs tests else it'll be
even more fragile.
What precisely are you planning with regard to scenarios and plugins?
I'm not very much in favour of complicating the installer.
Thanks for your comments. I'll reply inline.
> Some questions inline off the top of my head. Also, if you have not
> seen, I encourage you to look at our latest changes to
> katello-installer whereby we are using sub-packages for each of our
> different installers (capsule-installer, katello-installer,
> katello-devel-installer, sam-installer) and using a base package for
> holding common bits (hooks, modules) –
> https://github.com/Katello/katello-installer/blob/master/katello-installer.spec
It seems that even with the installer plugins the sub-packages could be
possible. The plan is to keep as much of the original code as possible.
>
> Eric
>
>
> For LiveCD feature we need to extend foreman-installer. Two major
> features we would like to add are
> - support for multiple installation scenarios (preselected
> installer configuration)
> - support for installer plugins.
>
> Example use case might be converting Katello installer into
> scenario(s) implemented as plugin of the Foreman installer.
> Another example might be plugin providing most typical installer
> scenarios.
>
> Draft of necessary changes we identified follows:
>
> Scenario:
> - we will use config file as it is now and extend it with name and
> description to define scenario
> - each config file will have answer file
> With this design we can avoid new config file format and have
> simple upgrade path.
>
>
> What if two scenarios conflict? e.g. As it stands now, running
> foreman-installer scenario after Katello installer could break the
> entire setup. I would recommend looking at my email about moving
> Katello to a plugin that can be added to a Foreman for some
> information on our current issues around installation.
If user wish to re-install existing installation with something else he
should understand the consequences. At least we can detect and warn or
ask for confirmation if the scenario is different form the one that was
used last time. Is it some recent email? Could you share a link to the
email or add some hints for what and where should I search?
>
>
> Multiple config files:
> - there will be one common directory (e.g.
> //etc/foreman/installer-config.d//) where configs are stored
> - after the installer run the config and answer file with
> customized options will be saved per selected scenario
> - link to last used answer/config file will help to determine what
> config should be used during installer re-run
> - installer script has to know location of config.d/ and name of
> the default config file
>
> Installer plugins:
> - check scripts should be listed in config or turned into hooks
> - hooks_dir will be list so the hooks from the plugin can be
> merged with the default ones
>
>
> How might ordering be handled here if needed?
I would assume that alphabetically with priority according the search
path. Practice shows if that is enough.
>
> - modules_dir will be list so the modules from the plugin can be
> merged with the default ones
>
>
> Will this work if two scenarios lay down the same or differing
> versions of the same module? Will plugins be able to carry just the
> modules they need to add and rely on a core set?
That is the plan. Modules brought by plugin should be visible to the
plugin only (or to dependent plugins). If you overwrite core module you
should be aware of that and should test it. It shouldn't affect
scenarios from core or other modules.
···
On 01/12/2015 04:15 PM, Eric D Helms wrote:
> On Mon, Jan 12, 2015 at 7:59 AM, Martin Bačovský > <martin.bacovsky@gmail.com > wrote:
- config file has to be able to reference resources in plugins
location
Things to resolve:
- how to behave when installer finds multiple scenarios and none
is specified by user. (should we offer selection or use the
default? new ideas to improve UX?)
- how to setup installer before config file is selected i.e.
during scenario selection (should we use data from default config?)
If you have any concerns, please let me know, questions and ideas
are welcome as always,
Martin
--
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
<mailto:foreman-dev+unsubscribe@googlegroups.com>.
For more options, visit https://groups.google.com/d/optout.
> > For LiveCD feature we need to extend foreman-installer. Two major
> > features we would like to add are
> > - support for multiple installation scenarios (preselected installer
> > configuration)
> > - support for installer plugins.
> >
> > Example use case might be converting Katello installer into scenario(s)
> > implemented as plugin of the Foreman installer. Another example might be
> > plugin providing most typical installer scenarios.
> >
> > Draft of necessary changes we identified follows:
> >
> > Scenario:
> > - we will use config file as it is now and extend it with name and
> > description to define scenario
> > - each config file will have answer file
> > With this design we can avoid new config file format and have simple
> > upgrade path.
>
> I don't think the kafo config files are a particularly big deal to
> change, so change it if you need to.
IIRC, the biggest motivation was not to introduce third config file. The
upgrade process is side effect and seems as a benefit.
>
> > Multiple config files:
> > - there will be one common directory (e.g.
> > /etc/foreman/installer-config.d/) where configs are stored
> > - after the installer run the config and answer file with customized
> > options will be saved per selected scenario
> > - link to last used answer/config file will help to determine what
> > config should be used during installer re-run
> > - installer script has to know location of config.d/ and name of the
> > default config file
> >
> > Installer plugins:
> > - check scripts should be listed in config or turned into hooks
> > - hooks_dir will be list so the hooks from the plugin can be merged with
> > the default ones
> > - modules_dir will be list so the modules from the plugin can be merged
> > with the default ones
> > - config file has to be able to reference resources in plugins location
> >
> > Things to resolve:
> > - how to behave when installer finds multiple scenarios and none is
> > specified by user. (should we offer selection or use the default? new
> > ideas to improve UX?)
> > - how to setup installer before config file is selected i.e. during
> > scenario selection (should we use data from default config?)
>
> Please consider automated unit testing of these configurations, and
> especially the interactions with plugins (yet more?). The very basic
> configuration we have today in foreman-installer is prone to errors
> already, so to add any complexity means it needs tests else it'll be
> even more fragile.
>
> What precisely are you planning with regard to scenarios and plugins?
> I'm not very much in favour of complicating the installer.
I leave more complex answer for Martin but the scenario was meant something
like:
foreman + foreman_proxy + puppet
foreman only
foreman_proxy + puppet
foreman + katello all in one (added by plugin)
I think this would simplify the installer by providing most common "default"
answer files.
···
On Monday 12 of January 2015 14:59:22 Dominic Cleal wrote:
> On 12/01/15 12:59, Martin Bačovský wrote:
> > For LiveCD feature we need to extend foreman-installer. Two major
> > features we would like to add are
> > - support for multiple installation scenarios (preselected installer
> > configuration)
> > - support for installer plugins.
> >
> > Example use case might be converting Katello installer into scenario(s)
> > implemented as plugin of the Foreman installer. Another example might be
> > plugin providing most typical installer scenarios.
> >
> > Draft of necessary changes we identified follows:
> >
> > Scenario:
> > - we will use config file as it is now and extend it with name and
> > description to define scenario
> > - each config file will have answer file
> > With this design we can avoid new config file format and have simple
> > upgrade path.
>
> I don't think the kafo config files are a particularly big deal to
> change, so change it if you need to.
>
> > Multiple config files:
> > - there will be one common directory (e.g.
> > /etc/foreman/installer-config.d/) where configs are stored
> > - after the installer run the config and answer file with customized
> > options will be saved per selected scenario
> > - link to last used answer/config file will help to determine what
> > config should be used during installer re-run
> > - installer script has to know location of config.d/ and name of the
> > default config file
> >
> > Installer plugins:
> > - check scripts should be listed in config or turned into hooks
> > - hooks_dir will be list so the hooks from the plugin can be merged with
> > the default ones
> > - modules_dir will be list so the modules from the plugin can be merged
> > with the default ones
> > - config file has to be able to reference resources in plugins location
> >
> > Things to resolve:
> > - how to behave when installer finds multiple scenarios and none is
> > specified by user. (should we offer selection or use the default? new
> > ideas to improve UX?)
> > - how to setup installer before config file is selected i.e. during
> > scenario selection (should we use data from default config?)
>
> Please consider automated unit testing of these configurations, and
> especially the interactions with plugins (yet more?). The very basic
> configuration we have today in foreman-installer is prone to errors
> already, so to add any complexity means it needs tests else it'll be
> even more fragile.
Fragility in terms of plugin interactions or just the installer's
behavior itself?
Isn't a lot of the latter coming from Ruby 1.8.7 support? We still
encounter odd things that push the katello-installer over the magic GC
cliff. A few weeks ago, we updated puppetlabs-apache, and suddenly 90%
of installs segfault. We've pinned it, but that's a temporary solution
not sure what we can do other than moving to SCL eventually.
> What precisely are you planning with regard to scenarios and plugins?
> I'm not very much in favour of complicating the installer.
There's a lot of duplicated effort in katello-installer, I would much
rather maintain a plugin to foreman-installer for katello and the
capsule and only have to manage Katello-specific things.
But, if I'm remembering the issue correctly (I may not be), but last
year sometime we had to move theforeman-foreman_proxy into being called
by katello-capsule instead of being at the top level because otherwise
it introduces one of the odd ruby segfault issues, so at the moment I
don't think the pluginification would even work on 1.8.7-based
installer.
···
On Mon, Jan 12, 2015 at 02:59:22PM +0000, Dominic Cleal wrote:
> On 12/01/15 12:59, Martin Bačovský wrote:
Plugin interactions, and successfully generating catalogs with different
permutations of scenarios/config files/answers.
···
On 13/01/15 11:28, Stephen Benjamin wrote:
> On Mon, Jan 12, 2015 at 02:59:22PM +0000, Dominic Cleal wrote:
>> Please consider automated unit testing of these configurations, and
>> especially the interactions with plugins (yet more?). The very basic
>> configuration we have today in foreman-installer is prone to errors
>> already, so to add any complexity means it needs tests else it'll be
>> even more fragile.
>
> Fragility in terms of plugin interactions or just the installer's
> behavior itself?
The scenarios Marek added are good example of what to use the scenarios
for. However it is not my intention to define the content of the
scenarios now. Even the scenarios Marek mentioned can be part of some
optional installer plugin with no additional hooks and modules.
For a start my plan is to keep the current answer/config as the default
(and only scenario). The plugins should live in separate place and
should not interfere with the core foreman-installer in any way but the
additional scenarios. Plugin's hooks and modules should be accessible
just from the plugin's scenarios or maybe from plugins that depends on
it. I don't expect installer plugins can break the core installer but it
is definitely good idea to cover that with tests.
Dominic, did I covered your concerns?
M
···
On 01/13/2015 11:44 AM, Marek Hulan wrote:
> Hello,
>
> my 2 cents below in text
>
> On Monday 12 of January 2015 14:59:22 Dominic Cleal wrote:
>> On 12/01/15 12:59, Martin Bačovský wrote:
>>> For LiveCD feature we need to extend foreman-installer. Two major
>>> features we would like to add are
>>> - support for multiple installation scenarios (preselected installer
>>> configuration)
>>> - support for installer plugins.
>>>
>>> Example use case might be converting Katello installer into scenario(s)
>>> implemented as plugin of the Foreman installer. Another example might be
>>> plugin providing most typical installer scenarios.
>>>
>>> Draft of necessary changes we identified follows:
>>>
>>> Scenario:
>>> - we will use config file as it is now and extend it with name and
>>> description to define scenario
>>> - each config file will have answer file
>>> With this design we can avoid new config file format and have simple
>>> upgrade path.
>> I don't think the kafo config files are a particularly big deal to
>> change, so change it if you need to.
> IIRC, the biggest motivation was not to introduce third config file. The
> upgrade process is side effect and seems as a benefit.
>
>>> Multiple config files:
>>> - there will be one common directory (e.g.
>>> /etc/foreman/installer-config.d/) where configs are stored
>>> - after the installer run the config and answer file with customized
>>> options will be saved per selected scenario
>>> - link to last used answer/config file will help to determine what
>>> config should be used during installer re-run
>>> - installer script has to know location of config.d/ and name of the
>>> default config file
>>>
>>> Installer plugins:
>>> - check scripts should be listed in config or turned into hooks
>>> - hooks_dir will be list so the hooks from the plugin can be merged with
>>> the default ones
>>> - modules_dir will be list so the modules from the plugin can be merged
>>> with the default ones
>>> - config file has to be able to reference resources in plugins location
>>>
>>> Things to resolve:
>>> - how to behave when installer finds multiple scenarios and none is
>>> specified by user. (should we offer selection or use the default? new
>>> ideas to improve UX?)
>>> - how to setup installer before config file is selected i.e. during
>>> scenario selection (should we use data from default config?)
>> Please consider automated unit testing of these configurations, and
>> especially the interactions with plugins (yet more?). The very basic
>> configuration we have today in foreman-installer is prone to errors
>> already, so to add any complexity means it needs tests else it'll be
>> even more fragile.
>>
>> What precisely are you planning with regard to scenarios and plugins?
>> I'm not very much in favour of complicating the installer.
> I leave more complex answer for Martin but the scenario was meant something
> like:
> * foreman + foreman_proxy + puppet
> * foreman only
> * foreman_proxy + puppet
> * foreman + katello all in one (added by plugin)
>
> I think this would simplify the installer by providing most common "default"
> answer files.
>
>>> For LiveCD feature we need to extend foreman-installer. Two major
>>> features we would like to add are
>>> - support for multiple installation scenarios (preselected installer
>>> configuration)
>>> - support for installer plugins.
>>>
>>> Example use case might be converting Katello installer into scenario(s)
>>> implemented as plugin of the Foreman installer. Another example might be
>>> plugin providing most typical installer scenarios.
>>>
>>> Draft of necessary changes we identified follows:
>>>
>>> Scenario:
>>> - we will use config file as it is now and extend it with name and
>>> description to define scenario
>>> - each config file will have answer file
>>> With this design we can avoid new config file format and have simple
>>> upgrade path.
>> I don't think the kafo config files are a particularly big deal to
>> change, so change it if you need to.
>>
>>> Multiple config files:
>>> - there will be one common directory (e.g.
>>> /etc/foreman/installer-config.d/) where configs are stored
>>> - after the installer run the config and answer file with customized
>>> options will be saved per selected scenario
>>> - link to last used answer/config file will help to determine what
>>> config should be used during installer re-run
>>> - installer script has to know location of config.d/ and name of the
>>> default config file
>>>
>>> Installer plugins:
>>> - check scripts should be listed in config or turned into hooks
>>> - hooks_dir will be list so the hooks from the plugin can be merged with
>>> the default ones
>>> - modules_dir will be list so the modules from the plugin can be merged
>>> with the default ones
>>> - config file has to be able to reference resources in plugins location
>>>
>>> Things to resolve:
>>> - how to behave when installer finds multiple scenarios and none is
>>> specified by user. (should we offer selection or use the default? new
>>> ideas to improve UX?)
>>> - how to setup installer before config file is selected i.e. during
>>> scenario selection (should we use data from default config?)
>> Please consider automated unit testing of these configurations, and
>> especially the interactions with plugins (yet more?). The very basic
>> configuration we have today in foreman-installer is prone to errors
>> already, so to add any complexity means it needs tests else it'll be
>> even more fragile.
> Fragility in terms of plugin interactions or just the installer's
> behavior itself?
>
> Isn't a lot of the latter coming from Ruby 1.8.7 support? We still
> encounter odd things that push the katello-installer over the magic GC
> cliff. A few weeks ago, we updated puppetlabs-apache, and suddenly 90%
> of installs segfault. We've pinned it, but that's a temporary solution
> - not sure what we can do other than moving to SCL eventually.
>
>> What precisely are you planning with regard to scenarios and plugins?
>> I'm not very much in favour of complicating the installer.
> There's a lot of duplicated effort in katello-installer, I would much
> rather maintain a plugin to foreman-installer for katello and the
> capsule and only have to manage Katello-specific things.
I agree
>
> But, if I'm remembering the issue correctly (I may not be), but last
> year sometime we had to move theforeman-foreman_proxy into being called
> by katello-capsule instead of being at the top level because otherwise
> it introduces one of the odd ruby segfault issues, so at the moment I
> don't think the pluginification would even work on 1.8.7-based
> installer.
Thanks for the warnings, could you please point me to the rough date
and/or list/issue where the Ruby 1.8.7 issues were discussed?
The plan is to do minimal changes mostly around the picking right config
file and module/hook paths, hopefully we can avoid the issues.
···
On 01/13/2015 12:28 PM, Stephen Benjamin wrote:
> On Mon, Jan 12, 2015 at 02:59:22PM +0000, Dominic Cleal wrote:
>> On 12/01/15 12:59, Martin Bačovský wrote:
–
Dominic Cleal
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+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
–
Best Regards,
> >>>For LiveCD feature we need to extend foreman-installer. Two major
> >>>features we would like to add are
> >>>- support for multiple installation scenarios (preselected installer
> >>>configuration)
> >>>- support for installer plugins.
> >>>
> >>>Example use case might be converting Katello installer into scenario(s)
> >>>implemented as plugin of the Foreman installer. Another example might be
> >>>plugin providing most typical installer scenarios.
> >>>
> >>>Draft of necessary changes we identified follows:
> >>>
> >>>Scenario:
> >>>- we will use config file as it is now and extend it with name and
> >>>description to define scenario
> >>>- each config file will have answer file
> >>>With this design we can avoid new config file format and have simple
> >>>upgrade path.
> >>I don't think the kafo config files are a particularly big deal to
> >>change, so change it if you need to.
> >>
> >>>Multiple config files:
> >>>- there will be one common directory (e.g.
> >>>/etc/foreman/installer-config.d/) where configs are stored
> >>>- after the installer run the config and answer file with customized
> >>>options will be saved per selected scenario
> >>>- link to last used answer/config file will help to determine what
> >>>config should be used during installer re-run
> >>>- installer script has to know location of config.d/ and name of the
> >>>default config file
> >>>
> >>>Installer plugins:
> >>>- check scripts should be listed in config or turned into hooks
> >>>- hooks_dir will be list so the hooks from the plugin can be merged with
> >>>the default ones
> >>>- modules_dir will be list so the modules from the plugin can be merged
> >>>with the default ones
> >>>- config file has to be able to reference resources in plugins location
> >>>
> >>>Things to resolve:
> >>>- how to behave when installer finds multiple scenarios and none is
> >>>specified by user. (should we offer selection or use the default? new
> >>>ideas to improve UX?)
> >>>- how to setup installer before config file is selected i.e. during
> >>>scenario selection (should we use data from default config?)
> >>Please consider automated unit testing of these configurations, and
> >>especially the interactions with plugins (yet more?). The very basic
> >>configuration we have today in foreman-installer is prone to errors
> >>already, so to add any complexity means it needs tests else it'll be
> >>even more fragile.
> >Fragility in terms of plugin interactions or just the installer's
> >behavior itself?
> >
> >Isn't a lot of the latter coming from Ruby 1.8.7 support? We still
> >encounter odd things that push the katello-installer over the magic GC
> >cliff. A few weeks ago, we updated puppetlabs-apache, and suddenly 90%
> >of installs segfault. We've pinned it, but that's a temporary solution
> >- not sure what we can do other than moving to SCL eventually.
> >
> >>What precisely are you planning with regard to scenarios and plugins?
> >>I'm not very much in favour of complicating the installer.
> >There's a lot of duplicated effort in katello-installer, I would much
> >rather maintain a plugin to foreman-installer for katello and the
> >capsule and only have to manage Katello-specific things.
> I agree
> >
> >But, if I'm remembering the issue correctly (I may not be), but last
> >year sometime we had to move theforeman-foreman_proxy into being called
> >by katello-capsule instead of being at the top level because otherwise
> >it introduces one of the odd ruby segfault issues, so at the moment I
> >don't think the pluginification would even work on 1.8.7-based
> >installer.
> Thanks for the warnings, could you please point me to the rough date and/or
> list/issue where the Ruby 1.8.7 issues were discussed?
> The plan is to do minimal changes mostly around the picking right config
> file and module/hook paths, hopefully we can avoid the issues.
···
On Tue, Jan 13, 2015 at 02:52:16PM +0100, Martin Bačovský wrote:
> On 01/13/2015 12:28 PM, Stephen Benjamin wrote:
> >On Mon, Jan 12, 2015 at 02:59:22PM +0000, Dominic Cleal wrote:
> >>On 12/01/15 12:59, Martin Bačovský wrote:
–
Dominic Cleal
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+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
–
Best Regards,
> However it is not my intention to define the content of the scenarios now.
Are you sure that it will cover all the scenarios Marek described then?
> For a start my plan is to keep the current answer/config as the default (and
> only scenario). The plugins should live in separate place and should not
Since this looks like a big change and refactoring, I'd rather see more
scenarios covered to catch all design issues and decisions. At lest the
two most important ones:
Hopefully the changes will not be as big as you expect, but it makes
sense to see that the concept works on more scenarios.
The two you mentioned are clear and will be used as prove of concept
scenarios.
I'm not very familiar with real-life deployments of Foreman so I will be
glad if someone joins and help me to design other scenarios that make
sense and will help to discover issues in installer changes.
···
On 01/14/2015 09:55 AM, Lukas Zapletal wrote:
>> However it is not my intention to define the content of the scenarios now.
> Are you sure that it will cover all the scenarios Marek described then?
>
>> For a start my plan is to keep the current answer/config as the default (and
>> only scenario). The plugins should live in separate place and should not
> Since this looks like a big change and refactoring, I'd rather see more
> scenarios covered to catch all design issues and decisions. At lest the
> two most important ones:
>
> - foreman + katello
> - smart proxy
