[GitHub] [cloudstack] onitake commented on issue #3557: cloud-init fails to fetch metadata when shared networks are present

2019-08-26 Thread GitBox
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

2019-08-26 Thread GitBox
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

2019-08-16 Thread GitBox
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

2019-08-16 Thread GitBox
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

2019-08-16 Thread GitBox
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

2019-08-15 Thread GitBox
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