[13:29] <smoser> otubo: https://github.com/canonical/cloud-init/pull/721 i dont want to lose that... i think we're down to just one WARN message for you to remove.
[13:33] <otubo> smoser, sorry, Scott. Had a PTO and was full of other stuff to finish this week. I'll try to update today.
[13:34] <otubo> smoser, thanks for the heads up.
[13:34] <smoser> otubo: great. hope youhad a nice vacation.
[14:44] <otubo> smoser, my tox is failing pylint with "tests/integration_tests/clouds.py:7: [E0611(no-name-in-module), ] No name 'Openstack' in module 'pycloudlib'" did anything changed lately?
[14:44] <otubo> smoser, other than that, everything looks ok. I'll push the changes now, also added some other fixes blackboxsw requested.
[14:52] <Odd_Bloke> otubo: Openstack support was introduced to pycloudlib relatively recently, so that likely indicates that you just have an older version of pycloudlib in your environment.
[14:56] <otubo> Odd_Bloke, makes sense, given that I'm running tox on RHEL-8.3, that should be indeed the case :-)
[15:14] <Odd_Bloke> tox installs pycloudlib, so a `tox --recreate -e pylint` will likely make it go away.
[18:13] <hamalq> hi i have a question : why ubuntu , opensuse , debian prefer short hostname while rhel prefer hostname as fqdn as https://github.com/canonical/cloud-init/blob/f35181fa970453ba6c7c14575b12185533391b97/cloudinit/distros/__init__.py#L259, https://github.com/canonical/cloud-init/blob/f35181fa970453ba6c7c14575b12185533391b97/cloudinit/distros/rhel.py#L94
[18:14] <hamalq> because of that the hostname in rhel will hit the 64 hostname limit which will fail cloud init
[18:21] <Odd_Bloke> hamalq: So the comment on that part points to a now-dead URL, but you can find it in the Wayback Machine: http://web.archive.org/web/20171223014319/https://www.centos.org/docs/5/html/Deployment_Guide-en-US/ch-sysconfig.html
[18:21] <Odd_Bloke> If you look at 27.1.22 on that page, it says "HOSTNAME=<value>, where <value> should be the Fully Qualified Domain Name (FQDN), such as hostname.expample.com, but can be whatever hostname is necessary."
[18:39] <hamalq> but i tried setting hostname hamalq on a rhel machine and it works
[18:45] <hamalq> Odd_Bloke: ^^ so i think this should work just fine, clould init use hostname, hostnamectl to set hostname on rhel machine and both are ok with short hostnames
[18:49] <hamalq> and the /etc/resolv.conf will have the search option with domain by default ( by cloud init)
[18:50] <hamalq> so if the hostname is hostname1.expample.com the hostname will be hostname1 and in resolve conf the search will be expample.com
[18:57] <Odd_Bloke> hamalq: Right, that would be "*can* be whatever hostname is necessary": it's still true that it "*should* be" the FQDN, so that's reasonable default behaviour.
[19:00] <hamalq> yes but that cause problems with hostname max limit 64 thats the problems i face and opensuse , debian, ubuntu already moved to short hostname bcz of the same issue with hostname max
[19:03] <hamalq> so changing the default will not cause problems and will solve an issue that may cause cloud init set hostname failure
[19:04] <hamalq> and it will align rhel with ubuntu , debian, opensuse behavior
[19:19] <Odd_Bloke> hamalq: I don't think anyone can categorically say that changing the default behaviour of code that runs on every cloud instance boot after 8 years will not cause problems.
[19:21] <Odd_Bloke> We provide configuration options for people who don't want the default behaviour (https://cloudinit.readthedocs.io/en/latest/topics/modules.html#set-hostname): are you seeing issues when using those?
[19:22] <hamalq> i can change and the tests can run :) , and i will check that option