Matt,

Yeah, definitely! I'm actually trying to get the entire plugin upstreamed,
but blocked until this other PR gets merged:
https://github.com/ansible/ansible/pull/25012

The plugin (awsrun) works really well right now, but it is very slow. I'm
hoping that once we get it upstreamed, we'll be able to work on some
performance improvements to it, but we're still at the mercy of the AWS
APIs. :-(

Fran

On Tue, Jun 20, 2017 at 9:38 AM Matthijs Suringa <matthijs.suri...@gmail.com>
wrote:

> Hi Fran,
>
> This sounds like quite a interesting option for me to look into, but
> unfortunately I am not a good enough developer to make something like this
> myself. Do you still have this plugin, and are you willing to share?
>
> Thank you.
>
> Regards,
> Matt
>
>
> On Monday, May 23, 2016 at 4:53:09 PM UTC+1, Fran Fitzpatrick wrote:
>
>> So, it seems like what I was looking for was setting the `.default_shell`
>> property. I landed up doing something like this, and things are now looking
>> up:
>>
>>     @property
>>     def default_shell(self):
>>         if self.platform_type == 'Windows':
>>             return 'powershell'
>>         else:
>>             return 'sh'
>>
>> On Mon, May 23, 2016 at 9:28 AM Fran Fitzpatrick <francis.x....@gmail.com>
>> wrote:
>>
> 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 <
>>> francis.x....@gmail.com> 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 <jadet...@gmail.com>
>>>> 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
>>>>> ansible-deve...@googlegroups.com.
>>>>
>>>>
>>>>> For more options, visit https://groups.google.com/d/optout.
>>>>>
>>>> --
> 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
> ansible-devel+unsubscr...@googlegroups.com.
> 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 ansible-devel+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to