Hi all, Just wanted to let you know that I've been making some great headway for this. Right now I have this connection plugin running on Linux hosts perfectly, and I have logic in the plugin to determine whether or not instance is Windows/Linux, dynamically determining whether or not to do "shell" things or "powershell" things.
However, I'm running into a problem with Windows. Even though my plugin has logic to determine whether or not an instance is Windows/Linux, the Ansible *framework* seems to always think it's Linux. For example the first time the framework calls my exec_command() function [on a Windows machine], it passes the command: "mkdir <...> && chmod <...> && echo <...>" What am I missing here? How do I let the framework know, or identify somewhere within my connection plugin, that I'm expecting powershelly type things? Thanks, Fran On Thu, Apr 28, 2016 at 9:50 AM Fran Fitzpatrick < [email protected]> wrote: > Hi Sicheng, > > > I created my plugin first with 2.0 as a proof of concept (meaning I know > it works by running it a few times; probably not ready for production). > When I backported it to 1.9 (still as a POC; I'm working on getting it > production ready now), it landed up not being that hard. Here's the big > things that I've seen so far (the diff is FROM_2.0 to TO_1.9): > > NOTE: I don't consider my work production ready, so... take it with a > grain of salt. :-P > > -from ansible.plugins.connection import ConnectionBase > -from ansible.utils.vars import combine_vars > +from ansible.callbacks import vv, vvv, vvvv, verbose # since Display > doesn't seem to be in 1.9 > > -try: > - from __main__ import display > -except ImportError: > - from ansible.utils.display import Display > - display = Display() > > -class Connection(ConnectionBase): > +class Connection(object): > > # And because there is no ConnectionBase apparently, gotta get rid of > those super() calls. > > - def __init__(self, play_context, new_stdin, *args, **kwargs): > - super(Connection, self).__init__(play_context, new_stdin, > - *args, **kwargs) > + def __init__(self, runner, host, port, user, password, *args, **kwargs): > > - def _connect(self): > + def connect(self): # Looks like 1.9 needs a public connect method > > - def exec_command(self, cmd, in_data=None, sudoable=True): > - ''' run a command on the local host ''' > - super(Connection, self).exec_command(cmd, > - in_data=in_data, > - sudoable=sudoable) > - display.vvv("EXEC length {}".format(len(cmd))) > + def exec_command(self, cmd, tmp_path='', become_user=None, > sudoable=False, > + executable=None, in_data=None): > > > > > > > > > > > On Wed, Apr 27, 2016 at 9:27 PM Sicheng Tang <[email protected]> wrote: > >> Actually, I am working on implementing a custom HTTP connection plugin >> too. There are a lot of changes from 1.9 to 2.0 at the source code level, >> and I decided to implement my connection plugin on 2.0, which seems >> more object oriented. >> Did you already implemented a ASW Run Command plugin on 1.9? What word >> should I do, if I want to write my own connection plugin? Would you share >> your experiences? >> >> >> 在 2016年4月26日星期二 UTC+8上午5:26:08，Fran Fitzpatrick写道： >> >>> Hi everyone, >>> >>> I've been working on a custom connection plugin to be used with AWS Run >>> Command, allowing Ansible to be run natively on AWS instances that have the >>> SSM agent installed and the proper IAM permissions/roles assigned. The >>> major benefit of this for us is that internally we are using the SSM agent >>> everywhere, and I no longer need to have access to the instance via SSH. >>> >>> Aaaaanyway, I have a nice POC working beautifully with Ansible 2.0, and >>> I am getting ready to port our plugin to Ansible 1.9, but it definitely >>> looks like there was a ton of improvements made to connection plugins with >>> v2.0. >>> >>> Does anyone have any references on developing backwards compatible >>> connection plugins? >>> >>> Thanks, >>> Fran >>> >>> PS: First post! Woot! >>> >> -- >> You received this message because you are subscribed to a topic in the >> Google Groups "Ansible Development" group. >> To unsubscribe from this topic, visit >> https://groups.google.com/d/topic/ansible-devel/ZSuobsmIgfk/unsubscribe. >> To unsubscribe from this group and all its topics, send an email to >> [email protected]. >> For more options, visit https://groups.google.com/d/optout. >> > -- You received this message because you are subscribed to the Google Groups "Ansible Development" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
