Circling around to where we started here, @pixelfairy, was Scott's
suggestion about FQDN helpful? Were you able to work around the issue
by adding one for the VM?
-Toshio
On Sun, Nov 2, 2014 at 4:24 AM, pixel fairy wrote:
> the setup module (and any playbooks) takes an extra 2 min for a fedora
On Fri, Nov 7, 2014 at 6:14 AM, Michael DeHaan wrote:
> Interesting - so it's not about fact gathering at all.
>
> Experimentation to see if regular SSH commands have issues with first
> connections would be welcome.
>
> It might result in the need to file a ticket on the distro.
>
I'm still not
On Wed, Nov 5, 2014 at 2:50 PM, Greg Andrews wrote:
>
> Toshio Kuratomi wrote:
>>
>> If I have
>> only one line in my /etc/hosts file:
>>
>> 127.0.0.1 localhost
>>
>> Running: time ansible all -i "localhost," -m setup -c local
>>
>> takes anywhere from 0.9 seconds to 15 seconds.
>>
>> Adding a
Interesting - so it's not about fact gathering at all.
Experimentation to see if regular SSH commands have issues with first
connections would be welcome.
It might result in the need to file a ticket on the distro.
On Wed, Nov 5, 2014 at 5:50 PM, Greg Andrews wrote:
>
> Toshio Kuratomi wro
Toshio Kuratomi wrote:
> If I have
> only one line in my /etc/hosts file:
>
> 127.0.0.1 localhost
>
> Running: time ansible all -i "localhost," -m setup -c local
>
> takes anywhere from 0.9 seconds to 15 seconds.
>
> Adding a second line to /etc/hosts:
> 127.0.0.1 roan.lan
>
> brings runtime in
If it's not something Fedora can resolve, we *MAY* have to remove this
check on Fedora 20+ until they can, as we tend to get hammered for some
issues in other things repeatedly at times.
OTOH, 20 seconds is slow, but not insurmountable terrible.
If we can pin it down to a python function (or bett
I've been able to reproduce but not entirely consistently. If I have
only one line in my /etc/hosts file:
127.0.0.1 localhost
Running: time ansible all -i "localhost," -m setup -c local
takes anywhere from 0.9 seconds to 15 seconds.
Adding a second line to /etc/hosts:
127.0.0.1 roan.lan
bri
If someone can help isolate the slow methods on those systems, that would
be great.
We are not currently seeing this.
On Mon, Nov 3, 2014 at 2:29 PM, Scott Sturdivant wrote:
> Honestly I haven't bothered digging into ansible source, but here's my
> results on Fedora 20, same as the OP:
>
> $
Honestly I haven't bothered digging into ansible source, but here's my
results on Fedora 20, same as the OP:
$ ansible --version
ansible 1.7.2
# Without valid FQDN entry
$ time ansible all -i "localhost," -m setup -c local
0.32s user 0.11s system 2% cpu 20.528 total
# With valid FQDN entry
$ tim
"Do you have a valid FQDN entry in /etc/hosts? Without that, the setup
module slows down considerably."
Assume you're referring to the one socket.gethostname() equivalent as a DNS
hit?
I'm not sure it would be *considerably*... though interested in any timing
info you might have.
(May imply DNS
Do you have a valid FQDN entry in /etc/hosts? Without that, the setup
module slows down considerably.
On Mon, Nov 3, 2014 at 7:24 AM, Michael DeHaan wrote:
> Hmm, that's quite curious and not something I've heard reported much.
>
> There's also not much logic to get stuck in a loop in there.
>
Hmm, that's quite curious and not something I've heard reported much.
There's also not much logic to get stuck in a loop in there.
If you have Python skills, using "./hacking/test-module" from a checkout on
that machine would allow inserting some debug that could help isolate why
it may be taking
the setup module (and any playbooks) takes an extra 2 min for a fedora 20
based vm. other ansible modules, at least command(date) and yum (upgrade
all), take less than a second, on an up to date machine.
tried from os x 10.10 (homebrew) and ubuntu 14.04, both running ansible
1.7.2. heres, the -
13 matches
Mail list logo
