Support of several network interfaces in system object

[Alan Evangelista]

I would like to understand why Cobbler allows user to define several 
network interfaces in system object.
Netboot and automated installation processes only require 1 network 
interface and supporting multiple
network interfaces introduce complexity. Possible motivations I see:

1) allow user to quickly alternate between different network interfaces 
for testing purposes
2) automatically setup all network interfaces in a system

imho motivation 2 is a strong point, but it goes beyond the scope of 
network installation and automated
installation. I see in http://projects.theforeman.org/issues/2240 that 
people are
requesting the same feature in Foreman to support automatic setup of all 
network interfaces
using Puppet and its integration with Foreman. I think it makes more 
sense to delegate this
task (automatic setup of all network interfaces) to a config management 
tool (eg Puppet)
than do it in Cobbler, otherwise Cobbler ends up being a "do it all" tool.

Maybe I have a restricted view of how and how much this feature is used, 
so I'd like to get
some feedback from Cobbler community.


Regards,
Alan Evangelista

[Jörgen Maas]

Hi Alan,

Here's some of the reasons i can think of why having support for multiple
interfaces would be useful:

- Not everybody is using configuration management tools (eg. small
environments)
- Configuration management integration is rather weak (atm just Puppet)
- It could be that pxe/install interface is physically separated from
management (eg. Puppet) and/or production interfaces (eg. due to security
policy)
- Managing machine specific data with configuration management tools might
not be that easy (eg. Puppet before Hiera got introduced)

Hope this helps!

Cheers,
Jörgen


On Tue, Oct 21, 2014 at 5:32 AM, Alan Evangelista <alanoe(a)linux.vnet.ibm.com
>  wrote: 
>  I would like to understand why Cobbler allows user to define several
>  network interfaces in system object.
>  Netboot and automated installation processes only require 1 network
>  interface and supporting multiple
>  network interfaces introduce complexity. Possible motivations I see:
>
>  1) allow user to quickly alternate between different network interfaces
>  for testing purposes
>  2) automatically setup all network interfaces in a system
>
>  imho motivation 2 is a strong point, but it goes beyond the scope of
>  network installation and automated
>  installation. I see in http://projects.theforeman.org/issues/2240 that
>  people are
>  requesting the same feature in Foreman to support automatic setup of all
>  network interfaces
>  using Puppet and its integration with Foreman. I think it makes more sense
>  to delegate this
>  task (automatic setup of all network interfaces) to a config management
>  tool (eg Puppet)
>  than do it in Cobbler, otherwise Cobbler ends up being a "do it all" tool.
>
>  Maybe I have a restricted view of how and how much this feature is used,
>  so I'd like to get
>  some feedback from Cobbler community.
>
>
>  Regards,
>  Alan Evangelista
>
>  _______________________________________________
>  cobbler-devel mailing list
>  cobbler-devel(a)lists.fedorahosted.org
>  https://lists.fedorahosted.org/mailman/listinfo/cobbler-devel
>

[Mark Levedahl]

On 10/21/2014 02:25 PM, Jörgen Maas wrote:
>  Hi Alan,
>
>  Here's some of the reasons i can think of why having support for 
>  multiple interfaces would be useful:
>
>  - Not everybody is using configuration management tools (eg. small 
>  environments)
>  - Configuration management integration is rather weak (atm just Puppet)
>  - It could be that pxe/install interface is physically separated from 
>  management (eg. Puppet) and/or production interfaces (eg. due to 
>  security policy)
>  - Managing machine specific data with configuration management tools 
>  might not be that easy (eg. Puppet before Hiera got introduced)
>
>  Hope this helps!
>
>  Cheers,
>  Jörgen
>
>
>  On Tue, Oct 21, 2014 at 5:32 AM, Alan Evangelista 
>  <alanoe(a)linux.vnet.ibm.com <mailto:[e-mail]>> wrote:
>
>      I would like to understand why Cobbler allows user to define
>      several network interfaces in system object.
>      Netboot and automated installation processes only require 1
>      network interface and supporting multiple
>      network interfaces introduce complexity. Possible motivations I see:
>
>      1) allow user to quickly alternate between different network
>      interfaces for testing purposes
>      2) automatically setup all network interfaces in a system
>
>      imho motivation 2 is a strong point, but it goes beyond the scope
>      of network installation and automated
>      installation. I see in http://projects.theforeman.org/issues/2240
>      that people are
>      requesting the same feature in Foreman to support automatic setup
>      of all network interfaces
>      using Puppet and its integration with Foreman. I think it makes
>      more sense to delegate this
>      task (automatic setup of all network interfaces) to a config
>      management tool (eg Puppet)
>      than do it in Cobbler, otherwise Cobbler ends up being a "do it
>      all" tool.
>
>      Maybe I have a restricted view of how and how much this feature is
>      used, so I'd like to get
>      some feedback from Cobbler community.
>
>
>      Regards,
>      Alan Evangelista
>
>      _______________________________________________
>      cobbler-devel mailing list
>      cobbler-devel(a)lists.fedorahosted.org
>      <mailto:[e-mail]>
>      https://lists.fedorahosted.org/mailman/listinfo/cobbler-devel
>
>
>
>
>
>  _______________________________________________
>  cobbler-devel mailing list
>  cobbler-devel(a)lists.fedorahosted.org
>  https://lists.fedorahosted.org/mailman/listinfo/cobbler-devel 
I have multiple
bonded interfaces and multiple vlans on all of my 
machines, and use cobbler to install those - tearing that out of cobbler 
would be a deal-breaker for me and send me packing to foreman/puppet, 
leaving cobbler behind.

Mark

[Jeff Schroeder]

On Monday, October 20, 2014, Alan Evangelista <alanoe(a)linux.vnet.ibm.com&gt;
wrote:

>  I would like to understand why Cobbler allows user to define several
>  network interfaces in system object.
>  Netboot and automated installation processes only require 1 network
>  interface and supporting multiple
>  network interfaces introduce complexity. Possible motivations I see:
>
>  1) allow user to quickly alternate between different network interfaces
>  for testing purposes
>  2) automatically setup all network interfaces in a system
>
>  imho motivation 2 is a strong point, but it goes beyond the scope of
>  network installation and automated
>  installation. I see in http://projects.theforeman.org/issues/2240 that
>  people are
>  requesting the same feature in Foreman to support automatic setup of all
>  network interfaces
>  using Puppet and its integration with Foreman. I think it makes more sense
>  to delegate this
>  task (automatic setup of all network interfaces) to a config management
>  tool (eg Puppet)
>  than do it in Cobbler, otherwise Cobbler ends up being a "do it all" tool.
>
>  Maybe I have a restricted view of how and how much this feature is used,
>  so I'd like to get
>  some feedback from Cobbler community.
>
>
>  Regards,
>  Alan Evangelista
>  
Alan,

At one of my previous employers, I used cobbler to dhcp a from scratch
Linux OS that ran in memory. It would come online and then run a small
script to connect to cobbler via the super simple xmlrpc api, get a list of
interfaces (set with the MAC address for each interface), write out
/etc/Iftar, and actually rename all of the interfaces and ip them with
cobbler as the authoritative source.

That might be a more advanced use case but is absolutely a valid one.
Please don't remove a feature like this. My take on config management
(puppet, salt, ansible, etc) is that you should setup the partitioning and
network bits before the config management runs. Please don't alienate users
just because you don't use a given feature.


-- 
Text by Jeff, typos by iPhone

[Alan Evangelista]

On 10/22/2014 12:00 AM, Jeff Schroeder wrote:
>  On Monday, October 20, 2014, Alan Evangelista 
>  <alanoe(a)linux.vnet.ibm.com <mailto:[e-mail]>> wrote:
>
>      I would like to understand why Cobbler allows user to define
>      several network interfaces in system object.
>      Netboot and automated installation processes only require 1
>      network interface and supporting multiple
>      network interfaces introduce complexity.
>
>
>
>  At one of my previous employers, I used cobbler to dhcp a from scratch 
>  Linux OS that ran in memory. It would come online and then run a small 
>  script to connect to cobbler via the super simple xmlrpc api, get a 
>  list of interfaces (set with the MAC address for each interface), 
>  write out /etc/Iftar, and actually rename all of the interfaces and ip 
>  them with cobbler as the authoritative source.
>
>  That might be a more advanced use case but is absolutely a valid one. 
>  Please don't remove a feature like this. My take on config management 
>  (puppet, salt, ansible, etc) is that you should setup the partitioning 
>  and network bits before the config management runs. Please don't 
>  alienate users just because you don't use a given feature. 
Thanks for the feedback.

I'm not alienating anybody, I'm just trying to understand Cobbler use cases.
Do not worry, features which are useful and are being used by users will not
be removed.


Regards,
Alan Evangelista

[Mann, Owen]

I use it a lot. I consider it a “basic minimum’, since kickstart supports it.  We don’t
use configuration management tools at this time (all built into Cobbler!), and it’s really
convenient to have each machine’s 6 or so interfaces in there. Besides, if PXEing from a
bond or a VLAN needs to be supported, is it that much more work to keep the rest?

Owen Mann, Interactive Data<http://www.interactivedata.com/> Omega
60 Codman Hill Rd, Boxborough, MA 01719
978-795-3758 [e-mail]<mailto:[e-mail]>
“We have to remember that what we observe is not nature in itself, but nature exposed to
our method of questioning.” -Werner Heisenberg
"Things are not what they seem; nor are they otherwise." - Buddhist saying

From: cobbler-devel-bounces(a)lists.fedorahosted.org
[mailto:[e-mail]] On Behalf Of Jeff Schroeder
Sent: Tuesday, October 21, 2014 10:00 PM
To: cobbler development list
Subject: Re: [cobbler-devel] Support of several network interfaces in system object

On Monday, October 20, 2014, Alan Evangelista
<[e-mail]<mailto:[e-mail]>> wrote:
I would like to understand why Cobbler allows user to define several network interfaces in
system object.
Netboot and automated installation processes only require 1 network interface and
supporting multiple
network interfaces introduce complexity. Possible motivations I see:

1) allow user to quickly alternate between different network interfaces for testing
purposes
2) automatically setup all network interfaces in a system

imho motivation 2 is a strong point, but it goes beyond the scope of network installation
and automated
installation. I see in http://projects.theforeman.org/issues/2240 that people are
requesting the same feature in Foreman to support automatic setup of all network
interfaces
using Puppet and its integration with Foreman. I think it makes more sense to delegate
this
task (automatic setup of all network interfaces) to a config management tool (eg Puppet)
than do it in Cobbler, otherwise Cobbler ends up being a "do it all" tool.

Maybe I have a restricted view of how and how much this feature is used, so I'd like
to get
some feedback from Cobbler community.


Regards,
Alan Evangelista

Alan,

At one of my previous employers, I used cobbler to dhcp a from scratch Linux OS that ran
in memory. It would come online and then run a small script to connect to cobbler via the
super simple xmlrpc api, get a list of interfaces (set with the MAC address for each
interface), write out /etc/Iftar, and actually rename all of the interfaces and ip them
with cobbler as the authoritative source.

That might be a more advanced use case but is absolutely a valid one. Please don't
remove a feature like this. My take on config management (puppet, salt, ansible, etc) is
that you should setup the partitioning and network bits before the config management runs.
Please don't alienate users just because you don't use a given feature.


--
Text by Jeff, typos by iPhone


*******************************************************
This message (including any files transmitted with it) may contain confidential and/or
proprietary information, is the property of Interactive Data Corporation and/or its
subsidiaries, and is directed only to the addressee(s). If you are not the designated
recipient or have reason to believe you received this message in error, please delete this
message from your system and notify the sender immediately. An unintended recipient's
disclosure, copying, distribution, or use of this message or any attachments is prohibited
and may be unlawful. 
*******************************************************

[Alan Evangelista]

On 10/22/2014 11:21 AM, Mann, Owen wrote:
>  I use it a lot. I consider it a “basic minimum’, since kickstart 
>  supports it.  We don’t use configuration management tools at this time 
>  (all built into Cobbler!), and it’s really convenient to have each 
>  machine’s 6 or so interfaces in there. Besides, if PXEing from a bond 
>  or a VLAN needs to be supported, is it that much more work to keep the 
>  rest?
>
>  
I am not sure what you meant with "if PXEing from a bond or a VLAN needs 
to be supported".
If you are talking about netboot, Cobbler does not do any network setup 
in the client before or
during netboot, it only answers DHCP/TFTP requests. If you are talking 
about *static*
network setup after netboot and before Linux installation starts, 
Cobbler does not handle that
either, it supposes network setup is retrieved from DHCP at that time. 
Maybe you meant
*static* network setup during and after Linux installation; those are 
the only ones Cobbler
do, but they have nothing to do with PXE. Automatic Linux installation 
via netboot and
full automatic network setup (all network interfaces, gateway, domain 
name servers, etc)
during/after Linux installation are independent features.

It is already clear people like the full automatic network setup feature 
and want to keep it, so
that's what we will do.


Regards,
Alan Evangelista