[chef] Re: Re: Re: Chef client managing remote systems?


Chronological Thread 
  • From: Ranjib Dey < >
  • To: " " < >
  • Subject: [chef] Re: Re: Re: Chef client managing remote systems?
  • Date: Mon, 28 Sep 2015 12:39:10 -0700

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 < " target="_blank"> > 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
- Organizing nodes in environments

We can see that with the AWS resources
https://supermarket.chef.io/cookbooks/aws

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,


On Mon, 28 Sep 2015 11:05:14 -0700
Ranjib Dey < "> > wrote:

> 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 < "> >
> 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.
> >
> > Regards,
> >
> > [1]
> >
> > https://www.juniper.net/techpubs/en_US/junos-ansible1.0/topics/task/program/junos-ansible-playbooks-creating-executing.html
> >
> >
> > --
> > Rafał Trójniak
> > WEB : http://trojniak.net/
> > : ">
> > Jid : ">
> > GPG  key-ID : 9A9A9E98
> > ABC8 83DF E717 6B76 CE49
> > BAFD 4F6F 854F 9A9A 9E98
> >



--
Rafał Trójniak
WEB : http://trojniak.net/
: ">
Jid : ">
GPG  key-ID : 9A9A9E98
ABC8 83DF E717 6B76 CE49
BAFD 4F6F 854F 9A9A 9E98




Archive powered by MHonArc 2.6.16.

§