Hi,
We are evaluating Foreman for Solaris/RHEL deployment. For Solaris
deployments, in addition to DHCP reservation, we use per-host IP
configuration in sysidcfg.
In Foreman global sysidcfg file is defined with hardcoded values on Solaris
media level, which covers all Solaris deployments.
It would be nice to have per-host sysidcfg template with ability to define
sysidcfg variables.
name_service and network_interface would be the top priority, since they
are most commonly used across the environment
Regards,
AF
I'd suggest filing this in redmine as a feature request:
http://theforeman.org/projects/foreman/issues/new
However we're not doing any Solaris work, so contributions would be most
welcome.
···
On 19/11/13 05:23, Aleksei Feltin wrote:
> Hi,
>
> We are evaluating Foreman for Solaris/RHEL deployment. For Solaris
> deployments, in addition to DHCP reservation, we use per-host IP
> configuration in sysidcfg.
> In Foreman global sysidcfg file is defined with hardcoded values on
> Solaris media level, which covers all Solaris deployments.
>
> It would be nice to have per-host sysidcfg template with ability to
> define sysidcfg variables.
>
> name_service and network_interface would be the top priority, since they
> are most commonly used across the environment
–
Dominic Cleal
Red Hat Engineering
Hi Dominic,
I've raised Feature #3686: Per host Solaris dynamic sysidcfg template - Foreman
Regards,
AF
···
On Tuesday, November 19, 2013 8:13:37 PM UTC+11, Dominic Cleal wrote:
>
> On 19/11/13 05:23, Aleksei Feltin wrote:
> > Hi,
> >
> > We are evaluating Foreman for Solaris/RHEL deployment. For Solaris
> > deployments, in addition to DHCP reservation, we use per-host IP
> > configuration in sysidcfg.
> > In Foreman global sysidcfg file is defined with hardcoded values on
> > Solaris media level, which covers all Solaris deployments.
> >
> > It would be nice to have per-host sysidcfg template with ability to
> > define sysidcfg variables.
> >
> > name_service and network_interface would be the top priority, since they
> > are most commonly used across the environment
>
> I'd suggest filing this in redmine as a feature request:
>
> http://theforeman.org/projects/foreman/issues/new
>
> However we're not doing any Solaris work, so contributions would be most
> welcome.
>
> --
> Dominic Cleal
> Red Hat Engineering
>
Hi Dominic/Ohad,
Before implementing this, I'd like to get your opinion of how it should
look like by answering some basic questions.
Why do we need this at all?
Having per-host sysidcfg gives us flexibility of setting up per-host naming
information, password, services profile, etc, in Solaris this is really the
equivalent of kickstart anaconda *authconfig *and *network. *Main benefit
is a static definition of per-host IP information, so we can build Solaris
host with static IP details and avoid finish script hacks.
In addition, sysidcfg format may differ between Solaris releases.
How do I see this implemented?
At the moment it is global for all Solaris hosts. It is defined in
app/models/operatingsystems/solaris.rb
:sysid_server_path => "#{jpath}/sysidcfg/sysidcfg_primary", #
192.168.216.241:/vol/jumpstart/sysidcfg/sysidcfg_primary
Ideally would be to have per-host sysidcfg, where Foreman would create a
one under host directory, such as #{jpath}/sysidcfg/{#host}/sysidcfg
The hard question, is how we define it. Could we define it as *Provisioning
Template? *Where would that sit? Do we need to create new type, as by logic
it doesn't fit under any current types?
Regards,
Alex
···
On Tuesday, November 19, 2013 10:33:39 PM UTC+11, Aleksei Feltin wrote:
>
> Hi Dominic,
>
> I've raised http://projects.theforeman.org/issues/3686
>
> Regards,
> AF
>
>
> On Tuesday, November 19, 2013 8:13:37 PM UTC+11, Dominic Cleal wrote:
>>
>> On 19/11/13 05:23, Aleksei Feltin wrote:
>> > Hi,
>> >
>> > We are evaluating Foreman for Solaris/RHEL deployment. For Solaris
>> > deployments, in addition to DHCP reservation, we use per-host IP
>> > configuration in sysidcfg.
>> > In Foreman global sysidcfg file is defined with hardcoded values on
>> > Solaris media level, which covers all Solaris deployments.
>> >
>> > It would be nice to have per-host sysidcfg template with ability to
>> > define sysidcfg variables.
>> >
>> > name_service and network_interface would be the top priority, since
>> they
>> > are most commonly used across the environment
>>
>> I'd suggest filing this in redmine as a feature request:
>>
>> http://theforeman.org/projects/foreman/issues/new
>>
>> However we're not doing any Solaris work, so contributions would be most
>> welcome.
>>
>> --
>> Dominic Cleal
>> Red Hat Engineering
>>
>
Hi,
See comments below:
> Hi Dominic/Ohad,
>
> Before implementing this, I'd like to get your opinion of how it should
> look like by answering some basic questions.
>
> Why do we need this at all?
>
> Having per-host sysidcfg gives us flexibility of setting up per-host
> naming information, password, services profile, etc, in Solaris this is
> really the equivalent of kickstart anaconda *authconfig *and *network. *Main
> benefit is a static definition of per-host IP information, so we can build
> Solaris host with static IP details and avoid finish script hacks.
>
While I dont object, I wonder why can't this be part of a provisioning
template?
your sysidcfg can simply call a finish script (or equivalent) in foreman
and get those attributes?
>
> In addition, sysidcfg format may differ between Solaris releases.
>
This again maps well to existing provisioning templates?
>
> How do I see this implemented?
>
> At the moment it is global for all Solaris hosts. It is defined in
> app/models/operatingsystems/solaris.rb
>
> :sysid_server_path => "#{jpath}/sysidcfg/sysidcfg_primary", #
> 192.168.216.241:/vol/jumpstart/sysidcfg/sysidcfg_primary
>
> Ideally would be to have per-host sysidcfg, where Foreman would create a
> one under host directory, such as #{jpath}/sysidcfg/{#host}/sysidcfg
>
> The hard question, is how we define it. Could we define it as *Provisioning
> Template? *Where would that sit? Do we need to create new type, as by
> logic it doesn't fit under any current types?
>
Ah… so we do think alike…so must this be on the file system? (the nfs
server) or can this be quiried via a URL ?
I would say that I generally object to a per host template (since its a
template it can be amended for specific things such as fqdn, static ip, pw
etc in a generic way).
Ohad
···
On Wed, Dec 4, 2013 at 2:23 PM, Aleksei Feltin wrote:
Regards,
Alex
On Tuesday, November 19, 2013 10:33:39 PM UTC+11, Aleksei Feltin wrote:
Hi Dominic,
I’ve raised Feature #3686: Per host Solaris dynamic sysidcfg template - Foreman
Regards,
AF
On Tuesday, November 19, 2013 8:13:37 PM UTC+11, Dominic Cleal wrote:
On 19/11/13 05:23, Aleksei Feltin wrote:
Hi,
We are evaluating Foreman for Solaris/RHEL deployment. For Solaris
deployments, in addition to DHCP reservation, we use per-host IP
configuration in sysidcfg.
In Foreman global sysidcfg file is defined with hardcoded values on
Solaris media level, which covers all Solaris deployments.
It would be nice to have per-host sysidcfg template with ability to
define sysidcfg variables.
name_service and network_interface would be the top priority, since
they
are most commonly used across the environment
I’d suggest filing this in redmine as a feature request:
Foreman
However we’re not doing any Solaris work, so contributions would be most
welcome.
–
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/groups/opt_out.
Unfortunately, sysidcfg only supports NFS for traditional Jumpstart
install. HTTP/S is supported in Solaris WANBoot implementation, however it
will take significant effort to add this to Foreman.
As sysidcfg kicks off early at the install phase and supports NFS only, it
will be difficult to implement it as provisioning template, however the way
I see it as PXELinux-alike template, that will place a file to NFS in a
similar way as PXE file is transferred to tftp root. It is not an absolute
requirement to have per-host sysidcfg support, however it is highly
desirable and if such an approach doesn't conflict with established
patterns, I'd like to give it a try. Least I want to do is to implement it
and then realize that patch is not acceptable.
···
On Friday, December 6, 2013 12:33:08 AM UTC+11, ohadlevy wrote:
>
> Hi,
>
> See comments below:
>
>
> On Wed, Dec 4, 2013 at 2:23 PM, Aleksei Feltin <aleksei...@gmail.com > > wrote:
>
>> Hi Dominic/Ohad,
>>
>> Before implementing this, I'd like to get your opinion of how it should
>> look like by answering some basic questions.
>>
>> Why do we need this at all?
>>
>> Having per-host sysidcfg gives us flexibility of setting up per-host
>> naming information, password, services profile, etc, in Solaris this is
>> really the equivalent of kickstart anaconda *authconfig *and *network. *Main
>> benefit is a static definition of per-host IP information, so we can build
>> Solaris host with static IP details and avoid finish script hacks.
>>
> While I dont object, I wonder why can't this be part of a provisioning
> template?
> your sysidcfg can simply call a finish script (or equivalent) in foreman
> and get those attributes?
>
>>
>> In addition, sysidcfg format may differ between Solaris releases.
>>
> This again maps well to existing provisioning templates?
>
>>
>> How do I see this implemented?
>>
>> At the moment it is global for all Solaris hosts. It is defined in
>> *app/models/operatingsystems/solaris.rb*
>>
>> :sysid_server_path => "#{jpath}/sysidcfg/sysidcfg_primary", #
>> 192.168.216.241:/vol/jumpstart/sysidcfg/sysidcfg_primary
>>
>> Ideally would be to have per-host sysidcfg, where Foreman would create a
>> one under host directory, such as #{jpath}/sysidcfg/{#host}/sysidcfg
>>
>> The hard question, is how we define it. Could we define it as *Provisioning
>> Template? *Where would that sit? Do we need to create new type, as by
>> logic it doesn't fit under any current types?
>>
> Ah.. so we do think alike..so must this be on the file system? (the nfs
> server) or can this be quiried via a URL ?
> I would say that I generally object to a per host template (since its a
> template it can be amended for specific things such as fqdn, static ip, pw
> etc in a generic way).
>
