Hi Will,
So naturally including telnet as a transport leaves me with some major
reservations. It's terribly insecure, being the main one. Previously I
had considered it from an April Fools perspective :)
That being said, I'm concerned about some of the direction I see Ansible
being used in network "automation" cases. While the Arista module in
particular provides a nice abstraction that runs on the box -- and other
modules can speak API, the goal of Ansible isn't really to be a command
blaster that just keys off return codes.
Thus for things that speak telnet, I'm wondering if local modules that
speak telnet, and understand the results of the communication, thus
providing resource level abstractions are a better way to go. Ok, I'm not
asking. I *know* they are.
So if we're talking about, say, TechnologyFoo boxes or something, having a
module like foo_vlan is a lot better than running telnet and blasting
commands and parsing output.
That's not what Ansible's meant to be.
Connections exist to push Ansible modules *only*, ergo if it's not pushing
modules, I'd really prefer to see:
- local_action: blippy_vlan arg=1234 arg2=5678 host={{
inventory_hostname }}
Thus the abstraction is in place, things are more readable, and we don't
get to the scenario where people are misleading putting telnetd on their
boxes and we get flamed for "endorsing" it. (Further, rcp? Ick? And do
many of these things have writeable filesystems and even run python?)
Anyway, connections deliver and deploy modules -- if a device speaks a
protocol, a connection plugin in Ansible should not exist for the protocol,
the module should instead speak that protocol.
A good example of this is how the F5/BigIP stuff for load balancing works,
and also the EC2 provisioning modules.
We don't, for instance, have a "SOAP" connection.
Hope this makes sense about the level of abstractions we are looking for
and what a connection in Ansible does.
Ultimately all of this "let's talk to this device" stuff is interesting,
but I don't want it to distract us from the resource model and modelling
things at the right levels of abstraction.
Thanks!!!
On Tue, Mar 18, 2014 at 4:04 PM, Will McLendon <[email protected]> wrote:
> Greetings all,
>
> Not sure if this is the appropriate place for a feature request, but here
> goes --
>
> in my searching it does not look like telnet is an available transport
> method in Ansible -- would it be possible to get it added? I know it's not
> preferred, but I am (trying) to use Ansible to help rapid staging and
> deployment of network switches, and some vendors kit unfortunately does not
> ship with SSH enabled by default, but does have telnet enabled. If I could
> use Ansible to telnet to the device, I think I could have it run the
> appropriate commands to enable SSH as part of the staging process.
>
> Thanks,
>
> Will
>
> --
> You received this message because you are subscribed to the Google Groups
> "Ansible Project" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to [email protected].
> To post to this group, send email to [email protected].
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/ansible-project/80918963-33e7-4f78-b911-f4f412df3147%40googlegroups.com<https://groups.google.com/d/msgid/ansible-project/80918963-33e7-4f78-b911-f4f412df3147%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
> For more options, visit https://groups.google.com/d/optout.
>
--
You received this message because you are subscribed to the Google Groups
"Ansible Project" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/ansible-project/CAEVJ8QP02-XZ0CLzAWNCRNN%2B9zt3WCCJ%3Dqr-9nigG52idO1irQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
