[GitHub] [cloudstack] onitake commented on issue #3557: cloud-init fails to fetch metadata when shared networks are present
onitake commented on issue #3557: URL: https://github.com/apache/cloudstack/issues/3557#issuecomment-738760809 It's not a CloudStack issue any more, but there is still a PR open to make the documentation clearer: https://github.com/apache/cloudstack-documentation/pull/132 I think it should be revisited and merged before we close this issue. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [cloudstack] onitake commented on issue #3557: cloud-init fails to fetch metadata when shared networks are present
onitake commented on issue #3557: cloud-init fails to fetch metadata when shared networks are present URL: https://github.com/apache/cloudstack/issues/3557#issuecomment-524920883 @joschi36 has pushed a proposed fix: https://code.launchpad.net/~joschi36/cloud-init/+git/cloud-init/+merge/371807 With this fix, cloud-init will first consult the host `data-server` before falling back on the previous behaviour. While this doesn't address the case where multiple default gateways are available with only some running the metadata server, it should at least be much more reliable than just looking at the latest DHCP lease. @ustcweizhou @rhtyd @DaanHoogland @PaulAngus Please let me know what you think. I'll gladly push an update to http://docs.cloudstack.apache.org/en/latest/adminguide/virtual_machines/user-data.html if you think this is the right way to go. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [cloudstack] onitake commented on issue #3557: cloud-init fails to fetch metadata when shared networks are present
onitake commented on issue #3557: cloud-init fails to fetch metadata when shared networks are present URL: https://github.com/apache/cloudstack/issues/3557#issuecomment-524793882 I think we found the "right" way to do this: If the metadata server is enabled on an interface, it will offer the special hostname `data-server` on its DNS server. This is already the case, and I really don't understand why cloud-init isn't already using that. This should always be the first host that cloud-init checks. As a second step, the "only latest lease" heuristic should go be replaced with "try all leases in reverse chronological order". Ideally, _all_ virtual routers should allow resolving the `data-server` hostname, returning the IP address of a router that has the metadata server enabled. If none of them do, the hostname shouldn't exist. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [cloudstack] onitake commented on issue #3557: cloud-init fails to fetch metadata when shared networks are present
onitake commented on issue #3557: cloud-init fails to fetch metadata when shared networks are present URL: https://github.com/apache/cloudstack/issues/3557#issuecomment-522110868 There are many different ways in which networks can be configured, and I agree that my point of view might not cover all use cases. But there's also another reason why I'd prefer cloud-init doesn't try to fetch metadata from a shared network: Since such a network is by definition not isolated, there's a higher risk that a malicious party might run a rogue DHCP server and a fake metadata server on the shared network and basically take over instances at startup. With isolated networks, this risk is much lower. This may not be a big risk in all cases, but limiting exposure should always be focused on. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [cloudstack] onitake commented on issue #3557: cloud-init fails to fetch metadata when shared networks are present
onitake commented on issue #3557: cloud-init fails to fetch metadata when shared networks are present URL: https://github.com/apache/cloudstack/issues/3557#issuecomment-521967733 The bug fix is fine, I think. If the user wishes to rely on DHCP leases, that's all right. What you describe is one possible solution, and I think cloud-init should behave like this in general. However, I also think that forcing the use of the default gateway would work best in our environment, because the default gateway will always run the metadata server. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [cloudstack] onitake commented on issue #3557: cloud-init fails to fetch metadata when shared networks are present
onitake commented on issue #3557: cloud-init fails to fetch metadata when shared networks are present URL: https://github.com/apache/cloudstack/issues/3557#issuecomment-521924587 That's a good point. The shared network offering we're using in this case does not have the UserData flag enabled. However, we have a reason for not doing this, and metadata fetching has worked for us fine until cloud-init was updated to consult NetworkManager leases. As mentioned in the upstream bug report, we would rather have the previous behaviour back, in that cloud-init always uses the default gateway as the metadata IP instead of consulting the last created DHCP lease file. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [cloudstack] onitake commented on issue #3557: cloud-init fails to fetch metadata when shared networks are present
onitake commented on issue #3557: cloud-init fails to fetch metadata when shared networks are present URL: https://github.com/apache/cloudstack/issues/3557#issuecomment-521678991 @ustcweizhou I don't think this has any influence on the issue here. cloud-init lists all lease files and consult only the newest one for determining the metadata server. If the DHCP client obtains a lease from the shared network _last_, cloud-init will use that. And since the shared network VR doesn't start the metadata server, cloud-init will not be able to obtain metadata and fail. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
