Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

in ipv4_address': undefined method origin' for nil:NilClass (NoMethodError) #400

Open
bby-bishopclark opened this issue Sep 21, 2017 · 5 comments

Comments

@bby-bishopclark
Copy link
Contributor

bby-bishopclark commented Sep 21, 2017

Versions:

  • Version of knife-vsphere: 2.0.0
  • Version of chef: 1.3.220

Platform Details

  • Version of vSphere: Chrome Version 60.0.3112.78
  • Version of ESXi: VMware ESXi, 5.5.0, 4722766

Scenario:

A simple-ish VM Clone op

Please paste the command and output (run with -VV). Don't forget to X out any passwords or sensitive information:

See the gist below.

Expected Result:

clone, bootstrap, etc; like normal

Actual Result:

gist here

@swalberg
Copy link
Collaborator

Hi there, sorry for the delay in responding, and thanks for gisting the full debug output.

I think the culprit is Found address fe80::250:56ff:fe99:f85e. The agent is returning the IPv6 link local address that you probably can't connect to.

Try it with the --bootstrap-ipv4 flag, and it'll continue to wait until it gets a v4 address.

@bby-bishopclark
Copy link
Contributor Author

Actually, that's on line 5 -- no fooling! But you're totally correct that it should get dead air if it was on ipv6 (I love how c7 will do that, without there being an actual network there; haven't run the 'disable ipv6' challenge on this template yet though)

@swalberg
Copy link
Collaborator

Oh I'm sorry, I missed that! I will have to look into this a bit more.

@bby-bishopclark
Copy link
Contributor Author

I think I tripped over the reason.

Our config around lists of variables, like ifcfg-eth0, often restate variables. Since those files are sourced, we'll restate parameters like bootproto= and NM_controlled;

DEVICE=eth0
BOOTPROTO=dhcp
PEERDNS=no
:
#moar
:

BOOTPROTO=static
NETMASK=255.255.254.0
IPADDR=10.53.8.46
GATEWAY=10.53.9.254
DNS1=10.21.9.210

The second bit overlays the first when the file is sourced in, so it's valid for us.

But now I think some piece is reading the file line by line, seeing the first BOOTPROTO, and quitting there. It decides that dhcp is what we're doing, but gets no address in our dry environment. Then, when it raises the nic, with its customized info, the nic either sets its old IP or ends up with none .. which is why/how only ipv6 is lit up.

Anyway, removing the first bootproto line allowed a single invocation to work. I'll close this if i can get a few more as proof. It would strongly indicate that the OS and customization are not reading the same file the same way, and those of us exploiting OS behaviour to be lazy with layers could shoot ourselve sin the foot.

@swalberg
Copy link
Collaborator

Interesting... We suggest you nuke those files in your template because they can cause problems, though this is the first time I've seen this particular problem happen because of it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants