Questions

[melck]

I try to understand some parts of code and i have some questions :

• It seems CentOS 7 have cloud-init 18.5, could we update docs and code ?
• Could we use cloudinit.util.which to find vmtoolsd ?
• Could we remove deepmerge and use cloudinit.util.mergemanydict ?
• Why do you need netiface for ? May be cloud init is sufficent ?
• Are you open to pull-request for adding deb package support ?
• Without external dependency, What do you think of adding this to cloud-init sources ?

I spent some time to understand it because i like this datasource (used with photonOS and RancherOS). I will like to use it for others OSs.

[akutz]

Hi @melck,

It seems CentOS 7 have cloud-init 18.5, could we update docs and code ?

This is only very recently. I'll update things when I have time.

Could we use cloudinit.util.which to find vmtoolsd ?

I suppose, but let me ask, what is wrong with the current approach?

Could we remove deepmerge and use cloudinit.util.mergemanydict?

Probably. I will look into it.

Why do you need netiface for ? May be cloud init is sufficent ?

This is one dependency we do need. Basically we need a good and reliable way to determine the shape of the network on the host. I was surprised to find that Python doesn't really provide anything like that by default. I did a bunch of digging, and it turns out that netifaces is widely regarded as the de facto means of querying a host for its network information with Python. Even other Python network packages recommend netifaces for the best experience.

The fact is I work with situations where there are multiple interfaces, gateways, address families, etc. I need netifaces, and thus this project has netifaces. If you can find something that provides the same solution as reliably with active development and support, then I'm all ears.

Are you open to pull-request for adding deb package support ?

Yes sir, I sure am!

Without external dependency, What do you think of adding this to cloud-init sources?

I've thought quite a lot about it, but as I indicated above, we need netifaces.

[melck]

Hi,

Could we use cloudinit.util.which to find vmtoolsd ?

I suppose, but let me ask, what is wrong with the current approach?

Some OS do not include distutils with python like debian. I think It will be better to use what's available by cloud-init.

This is one dependency we do need. Basically we need a good and reliable way to determine the shape of the network on the host. I was surprised to find that Python doesn't really provide anything like that by default. I did a bunch of digging, and it turns out that netifaces is widely regarded as the de facto means of querying a host for its network information with Python. Even other Python network packages recommend netifaces for the best experience.

The fact is I work with situations where there are multiple interfaces, gateways, address families, etc. I need netifaces, and thus this project has netifaces. If you can find something that provides the same solution as reliably with active development and support, then I'm all ears.

Thanks for explanation. I understand. Do you look if cloud-init has function to do it ? Or maybe we coud render it optionnal like a try import with warning if not present. It will suit both case (yours) and could be integrated to cloud-init.

[akutz]

This issue is being closed because this datasource has been merged into cloud-init (canonical/cloud-init#953):

Component	Source	Tests
Datasource	DataSourceVMware.py	test_vmware.py
Identification	ds-identify	test_ds_identify.py
Documentation	vmware.rst

In order to participate in the growth of this datasource moving forward, please:

• Ask a question in the #cloud-init IRC channel on Libera
• Search the cloud-init mailing list archive
• Join the cloud-init mailing list
• Report issues with Launchpad

Once again, many thanks to the wonderful community that has grown around this datasource, and I look forward to seeing everyone in the new cloud-init forums!