I’m currently on network conference, where lot of automation talks is
being performed. It’s quite sad that there is almost no chef popping up
here.
There are agent-less tools used usually (like Ansible). There is a
simply reason for that:
Most of specialized networking gear is not able to run ruby (chef).
Is there other way?
There are some auto-configuration tools that manage systems remotely
(using NetConf, SSH, Telnet or SNMP). What would need to be done to be
able to do it in chef ? ( Like have a box or two, with chef client
configured to manage all the switches/routers in environment)
I have a simple example from the Ansible, which uses netconf [1]
The question:
What Would I have to do to
Disable all providers by default
Pass the ‘managed’ device locations (ip,port,type) to the chef
client
Port OHAI so it can discover system information by SNMP/SSH/NetConf
Run only supported providers on the destination host
Separate all chef-client local state (caches, temp dirs)
Anybody tried that ?
Why would I want to do that ?
The gear is usually virtualized now, right ? We have Openstack, AWS
ans so one. But still someone has to manage the physical devices they
operate on. Also, some devices has to be physical (for performance
reasons) and interact with the services (like HW Load Balancers,
Routers, Firewalls, IPSes). It would be nice to have them covered by
Chef management.
i have done similar things with chef /puppet using snmp traps. theres a
controller nodes which runs chef recipes that in turn execute those logic.
if you notice, the ansible example uses gather_facts: no, and connection:
local. which means its no more using ssh transport etc, and everything is
being executed locally. i wonder do you really need ansible or infact chef
at that point. cause even a make /rake or any standalone script would do.
but if the intention is to keep all config management together, that would
make lot of sense. and you can do ditto with chef as well. i.e. run a
controller node (or from your workstation) a recipe that has execute
statement . an improvement would be wrapping those in lwrps and making them
idempotent if possible.
On Mon, Sep 28, 2015 at 9:46 AM, Rafał Trójniak rafal@trojniak.net wrote:
Hello,
I'm currently on network conference, where lot of automation talks is
being performed. It's quite sad that there is almost no chef popping up
here.
There are agent-less tools used usually (like Ansible). There is a
simply reason for that:
Most of specialized networking gear is not able to run ruby (chef).
Is there other way?
There are some auto-configuration tools that manage systems remotely
(using NetConf, SSH, Telnet or SNMP). What would need to be done to be
able to do it in chef ? ( Like have a box or two, with chef client
configured to manage all the switches/routers in environment)
I have a simple example from the Ansible, which uses netconf [1]
The question:
What Would I have to do to
Disable all providers by default
Pass the 'managed' device locations (ip,port,type) to the chef
client
Port OHAI so it can discover system information by SNMP/SSH/NetConf
Run only supported providers on the destination host
Separate all chef-client local state (caches, temp dirs)
Anybody tried that ?
Why would I want to do that ?
The gear is usually virtualized now, right ? We have Openstack, AWS
ans so one. But still someone has to manage the physical devices they
operate on. Also, some devices has to be physical (for performance
reasons) and interact with the services (like HW Load Balancers,
Routers, Firewalls, IPSes). It would be nice to have them covered by
Chef management.
i have done similar things with chef /puppet using snmp traps. theres
a controller nodes which runs chef recipes that in turn execute those
logic.
if you notice, the ansible example uses gather_facts: no, and
connection: local. which means its no more using ssh transport etc,
and everything is being executed locally. i wonder do you really need
ansible or infact chef at that point. cause even a make /rake or any
standalone script would do. but if the intention is to keep all
config management together, that would make lot of sense. and you can
do ditto with chef as well. i.e. run a controller node (or from your
workstation) a recipe that has execute statement . an improvement
would be wrapping those in lwrps and making them idempotent if
possible.
On Mon, Sep 28, 2015 at 9:46 AM, Rafał Trójniak rafal@trojniak.net
wrote:
Hello,
I'm currently on network conference, where lot of automation talks
is being performed. It's quite sad that there is almost no chef
popping up here.
There are agent-less tools used usually (like Ansible). There is a
simply reason for that:
Most of specialized networking gear is not able to run ruby
(chef).
Is there other way?
There are some auto-configuration tools that manage systems remotely
(using NetConf, SSH, Telnet or SNMP). What would need to be done to
be able to do it in chef ? ( Like have a box or two, with chef
client configured to manage all the switches/routers in environment)
I have a simple example from the Ansible, which uses netconf [1]
The question:
What Would I have to do to
Disable all providers by default
Pass the 'managed' device locations (ip,port,type) to the chef
client
Port OHAI so it can discover system information by
SNMP/SSH/NetConf
Run only supported providers on the destination host
Separate all chef-client local state (caches, temp dirs)
Anybody tried that ?
Why would I want to do that ?
The gear is usually virtualized now, right ? We have Openstack, AWS
ans so one. But still someone has to manage the physical devices
they operate on. Also, some devices has to be physical (for
performance reasons) and interact with the services (like HW Load
Balancers, Routers, Firewalls, IPSes). It would be nice to have
them covered by Chef management.
Let's imagine we can use the each ELB instance as separate chef node.
That would result in :
Discovery of ELB using chef search (like in back-ends or monitoring)
Assignment of that ELB to environment
Information when was it last configured by ohai_time (or similar)
Ability to configure each ELB separately
What do you thing about that approach ?
Regards,
You can sorta get this working by using a separate chef-client config for each “virtual node” on the management host, by setting a different node_name for each one. Unfortunately, each one would also need a keypair; while the server would allow one client/key to manage many node objects, chef-client hardcodes client_name == node_name.
Ohai would run against the management host, and Chef would likely be borked if you modified the platform/platform family attributes, but you could use the minimal ohai flag to reduce the amount of extraneous attributes ohai collects, and make a cookbook that collects data about the network boxes and adds it to the automatic attributes (thus doing what ohai would do). The fqdn attribute may be changed if you set the node_name setting in the client.rb (and you would have to do this anyway so that chef saves the node data separately for your virtual nodes).
you can workaround those bits, storing the remote network device data
inside controller node attributes and searching against that. this is the
same challenge as in ansible (since you are not gathering facts ).
you can definitely model those network devices as first class chef nodes,
but you wont be able to gather their facts (ohai etc). storing their data
inside the controller node explicitly, represents the implementation and
the fact the those node are remote managed via the controller. Searching is
same, except they'll be predicated by the controller node.
On Mon, Sep 28, 2015 at 12:02 PM, Rafał Trójniak rafal@trojniak.net wrote:
Thanks for the response Ranjib.
Using the scripts, or only LWRPs will cut off lot of Chef functionality
I really appreciate : (Chef node) :
Searching for nodes
Node attributes auto-discovery (IP address, version and so one)
Applying roles, environments and run-lists for nodes
i have done similar things with chef /puppet using snmp traps. theres
a controller nodes which runs chef recipes that in turn execute those
logic.
if you notice, the ansible example uses gather_facts: no, and
connection: local. which means its no more using ssh transport etc,
and everything is being executed locally. i wonder do you really need
ansible or infact chef at that point. cause even a make /rake or any
standalone script would do. but if the intention is to keep all
config management together, that would make lot of sense. and you can
do ditto with chef as well. i.e. run a controller node (or from your
workstation) a recipe that has execute statement . an improvement
would be wrapping those in lwrps and making them idempotent if
possible.
On Mon, Sep 28, 2015 at 9:46 AM, Rafał Trójniak rafal@trojniak.net
wrote:
Hello,
I'm currently on network conference, where lot of automation talks
is being performed. It's quite sad that there is almost no chef
popping up here.
There are agent-less tools used usually (like Ansible). There is a
simply reason for that:
Most of specialized networking gear is not able to run ruby
(chef).
Is there other way?
There are some auto-configuration tools that manage systems remotely
(using NetConf, SSH, Telnet or SNMP). What would need to be done to
be able to do it in chef ? ( Like have a box or two, with chef
client configured to manage all the switches/routers in environment)
I have a simple example from the Ansible, which uses netconf [1]
The question:
What Would I have to do to
Disable all providers by default
Pass the 'managed' device locations (ip,port,type) to the chef
client
Port OHAI so it can discover system information by
SNMP/SSH/NetConf
Run only supported providers on the destination host
Separate all chef-client local state (caches, temp dirs)
Anybody tried that ?
Why would I want to do that ?
The gear is usually virtualized now, right ? We have Openstack, AWS
ans so one. But still someone has to manage the physical devices
they operate on. Also, some devices has to be physical (for
performance reasons) and interact with the services (like HW Load
Balancers, Routers, Firewalls, IPSes). It would be nice to have
them covered by Chef management.