Puppet

Something’s not quite right with the patch

I added a couple of debug statements to try and diagnose:

if (options.has_key?(:prompt)) then
  Puppet.debug("options prompt: #{options[:prompt]}")
  Puppet.debug("default prompt: #{default_prompt}")
  # if we've been explicitly passed an alternate prompt, we will build up a regular expression that
  # can match either the specified prompt or the default prompt
  prompt_regex = /^(?:#{Regexp.escape(options[:prompt])})|(?:#{Regexp.escape(default_prompt)})$/
  Puppet.debug("Prompt regex: #{prompt_regex}")
  # Net::Telnet.waitfor expects a hash if you want to use a regex to match the prompt:
  prompt = { "Match" => prompt_regex }
  Puppet.debug("prompt: #{prompt}")
end

The output I get is:

debug: options prompt: (?-mix:Password:)
debug: default prompt: (?-mix:[a-zA-Z0-9\-_. ]*[#>]\s?)
err: Could not send report: No route to host - connect(2)
err: Could not retrieve local facts: can't convert Regexp into String

I’m slightly confused as to why I don’t see the other debug output as i’m sure the code has to get as far as the expect call before it will timeout?!

I even commented out my own code thinking that perhaps it was somehow the cause of ‘can’t convert Regexp into String’, but it doesn’t seem to be.

That seems to do it. At least, in my fairly limited testing :)

Thanks

Gary

Awesome, thanks for the feedback.

Can you post a bit of info about what kind(s) of device(s) you’ve tested against?

Then I think we will need to get a bit of testing on some Cisco devices, and at that point this patch can be considered for integration into the main codebase.

Right now i’m just trying to talk to a HP ProCurve 2510G-48 L2 managed switch and get some facts from it. Then I hope to implement vlans and interfaces similar to the existing Cisco code. I also have some HP E4800 L3 managed switches (they’re actually non rebranded 3com’s, which are rebranded H3C S5500 switches) which I hope to implement similar functionality for at some point (but they’re less important).

The only reason for the above request was due to the switch i’m testing on. In its default config (which is how we hope to one day be able to provision a new switch) once you’re connected, if you type enable you don’t get prompted for a password. So the existing puppet code fell over at the first hurdle as there was no easy way to say, execute ‘enable’, expect Password: or expect the default prompt.

One thing we’ve been thinking that we might like to do (in the future) is to have puppet configure switch ports on the fly based on a few things. For example, it would be nice if we could define a virtual machine to be on a certain host. As part of the VM config you would tell puppet which vlans its interfaces needed to be connected to. Then using various puppet magic, the VM config would configure various switch ports to be configured correctly for whichever vlans are required by VMs on a specific host. This sort of thing may be a little way off, but it’s quite important to us at least initially to be able to configure vlans on our switches manually via puppet and we can’t do that until puppet can actually manage vlans on our switches. So this is something i’m vaguely working on whenever time allows.

Thanks for all of the extra info, that is helpful.

As i’m slowly getting further with my project to get puppet working with my own switches, I wonder if I jumped the gun on this request due to not understanding how the code worked.

As I had assumed that both the default prompt and the prompt passed to the command method should match in the output, I based my thinking around that assumption and therefore this ticket turned into more of a request for that ability rather than fully understanding what was actually happening and why it might only make sense to match against the specific prompt specified.

I realise now that there may be a situation where you would try to expect(/Password:/) or something and you really would only ever want to match on that output NEVER on the default prompt. If you received the default prompt it might actually mean that something went wrong and that you don’t want to continue.

I also realise that due to my misunderstanding of how the code worked, I had assumed that this underlying code needed to be changed to be ‘correct’ when actually it was correct and that once it was explained above how this code works (ie. it’s not a match this or match that, it’s match this if it’s not otherwise match that), I should have realised that making my switch code work this way and expect very specific things makes far far more sense than expecting something or the default prompt.

That said, I can see that there may be instances where you might want to match a prompt or the default prompt. So perhaps this functionality could somehow be changed so that by default it works how it originally worked, but also have a way to tell it to work in a way that the patch allows. Essentially supporting both, but defaulting to how it originally worked.

If I find time, perhaps i’ll be able to provide such a patch myself!

Anyhow, cutting a long post short, this patch as it is now probably should NOT end up merged into the mainline code.

I’m pretty sure this isn’t the place to ask, but I couldn’t find a better place, so:

Gary, how is management of ProCurve devices progressing? Do you have something you could share for testing?