#mcollective

chitopunk: my experience is that it will connect to all listed brokers but only send messages to one of them.

if your servers are set up to exchange messages then it doesn't matter which one they talk to.

From your queries previously and today, it seems likely that your openwire connections between the AMQ boxes aren't working correctly.

Volcane: on the reply-to issue, is the concern that the application receives back an empty array like so?

./testreplyto.rb:47: undefined method `[]' for nil:NilClass (NoMethodError)

that from this line: client.testreplyto().each do |resp|

so the problem in your eyes is that every application would require special handling of the empty array response?

Would it not also be valid to have the rpcclient catch this scenario and return an array with the queue submission message?

again, ignoring complex apps like "puppet runall" which can already big and can look for and bail if reply_to is set.

jorhett: no its that reply to significantly changes the program flow in a way most authors wont anticipate or have any way testing

jorhett: you need to construct fake but obviously error like reposnses that match what unchanged code would expect and hope they somehow cope with that - if you wanted to somehow reply with something code would gracefully degrade from

I understand that complexity. For me to get what I think is ideal will probably be a next-version solution. I'm just playing around with code and testing out ideas right now.

At the very least I want to document the best method to enable this functionality in an application or standalone client.

yes, exactly what everyone is suggesting

dont advertise the ability and do weird shit, default off and document how to enabler

so that's the tricky part here. Is the reply_to option going to disappear? What's the expected method for enabling?

Or does the client program need to add the option to its own?

Could you further explain "significantly changes the program flow in a way most authors wont anticipate or have any way testing" ??

In all of my tests it operates fine by returns nil instead of an array of results.

Is error testing the problem?

my assumption is that the listener needs to understand the errors, no?

Is this sufficient for the most basic case? https://github.com/jorhett/learning-mcollective...

_rc: what is the difference between --nodes filename and -dm flatfile -do filename"

nevermind. I found the document where it was stated that these are identical.

jorhett: already the applications can elect to enable/disable some blocks of options, I suspect it will be similar?

https://github.com/puppetlabs/marionette-collec... is how the rpc app handles it

yeah I saw that. That's why I was curious what you meant about how designing app to handle? It seems like reply_to processing is just fire/forget

From 90% of the apps I have seen out there, if we modified the rpcclient code to return "Request sent with id $id to queue $name" back in reply[:msg] they would all handle it just fine :)

obviously that's not 100% coverage but...

^^ where apps = agents I mean

Volcane: not arguing, mostly just sharing my observations

you're again utterly confused about app, agent, rpcutil and so forth

so not really possible to talk about it sensibly

Volcane: I'm pretty sure I'm not. I just typed the wrong thing.

The concern here is to do something intelligent and reasonable for custom agents/clients yeah? The rpcclient class that is used by most client apps (for mco) and standalone ruby scripts all tend to use :msg as that's what all of your examples show.

ok, go back and try type that again correctly

...?

sorry, literally cannot explain to you again how rpcutil does not relate to 'most client apps'

ship has sailed

Seriously, I have something like 100+ agents and 80+ clients I've built. (some of the clients issue requests to multiple agents)

I grok that rpcutil goes directly to the agent, skips the app entirely. Got that.

Howeve reply-to works perfectly fine today in every app I have, without using rpcutil.

It also works fine with almost every request issued to all Puppet Labs-provided apps.

excluding the cosmetic response issue.

thats not what it does

why dont you stop this believing that you're right 100%

and start paying attention to the multiple people who have tried to explain this to you?

I'm trying to understand. You say "it won't work at all" and observations of usage differ with that.

but at this point I'm done, cant convince you you're wrong, cant have a conversation about it because you dont make sense as you dont understand the basic interactions

I am trying very hard to understand what you're trying to tell me.

I think you are discounting what I know and what I have already tested unfairly.

i can only go by the word you use

you're consistantly using the wrong ones to describe what is happening

and even just interchanging the words with the correct ones

the sentence still doesnt make sense because the behavior you describe is not whats happening

I've tried last week to help you understand these, you keep insisting you understand it while persisting in not making sense

which words? Trust that I know what agents do, what apps do, etc.

so its literally not possible to have a further discussion about it

I use "apps" to mean mco clients, and "scripts" to mean standalone clients. Not sure if that's what's confusing you.

I'd really appreciate being enlightened on what you think I don't understand. I am wide open to revising my usage if you'll clarify.

well it would just be the same as last weeks n hour convo, so just go read that

I don't have that history, and there's no weblog I'm aware of.

I remember you insisting that only rpcutil could handle reply-to. Given that I can invoke all the stock client apps and send the results elsewhere successfully… it's not just rpcutil, right?

Are we disagreeing on words or on actions?

As you showed in the text, rpcutil isn't doing anything special with reply-to. It passes it along and then outputs the useful string to the user.

It's using the same rpcclient as the apps are using, no?

no i said any agent at all can do replyto it has nothing at all to do with rpcutil

so we agree on this :)

rpcutil is an agent.

I thought it was an app?

what directory does it live in?

use find -name rpcutil.rb

Yes, I understand. However it seems to issues requests to agents and it supplies an interface to mco, thus my confusion.

it does nothing at all like that

its just an agent, like any other agent

sorry, confusion == was swapping "rpc" app with "rpcutil" agent.

you can rm it and everything keeps working except things like 'mco inventory' which requests data from it

I think I made the same mistake the other night.

In this, yes you are right I was using the wrong words.

so any rpc client can make reply-to requests

but the ones that want to do so gracefully

they need logic that handles the lack of replies

and the rpc application is currently the only one that has this logic

right.

and by enabling it blindly for apps that dont have this logic

you risk a naively written app from behing badly and doing terrible things

true.

maybe a app does a request for some data

and then construct future requests based on said data

first request is some elaborate filter - only want to update php on machines with a certain version of apache

if said app handles this lack of replies incorrectly

or if we try to construct some vaguely representitive fake replies

you risk the 2nd request in that scenario being without filter for example

ie.

update php on all machines

its a trivially easy mistake to happen

Valid. Which is why I said I don't think I can achieve the "simpler" version without a chance in expectations for apps == next-version

and one we cannot detect or handle

so the only responsible thing to do is

disable reply-to handling in all apps by default

and document/support a way to enable it on ones that decide to carry the extra logic

I understand and agree with that change for Mco 2.x

I want to do two things:

1. Document clearly how to enable this functionality for client apps that want to use it.

2. Come up with a pull request that includes both code and logic that makes this part of the framework for v3 app design

sorry "code and docs"

yeah so i think the 1 will probably come from the tickets PL has for this

and 2 - personally i cant see it happening

Well #2 is up to me to come up with a compelling solution ;-)

I want it so I can avoid copy/pasting the same lines into every client app I build.