[05:02] <askb> Are there any known issues reading shell env variables before executing a script from the user-data ?
[05:02] <askb> the script is unable to read the updated $PATH from /etc/environment ?
[10:34] <amarao> Hello. Did anyone knows how to deal with random interfaces names? I'm trying to use cloud-init on baremetal instances, and there are many possible interface names (ens3, p4p1, e4s5, etc), and sometimes them just not 'up' for DHCP.
=== shardy is now known as shardy_lunch
[13:34] <smoser> amarao, hey.
[13:34] <smoser> so there are a couple ways to do this.
[13:34] <amarao> Hello.
[13:35] <smoser> one way is to change the random interface names off
[13:35] <smoser>  https://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/
[13:35] <smoser> that gets you the old 'eth0' and the like.
[13:36] <amarao> Yes, that's one way I though. Is any cloud-init-like way to say 'use all interfaces available'?
[13:36] <smoser> the bad thing about that is that .... it was changed for a reason.  nothing was ever really guaranteeing that nics would come up named correctly, and even the udev renaming code can fail
[13:36] <smoser> what do you want it to do ?
[13:37] <amarao> To have such image, which would be able to boot (get metadata) regardless of the name of interfaces.
[13:37] <smoser> some more background.. if cloud-init can find networking configuration from the "datasource" (the cloud provider ... whatever you want to call that), then it can use that and configure the system as described.
[13:37] <smoser> this happens on openstack with config drive and in smartOS and in maas (there, more indirectly).
[13:38] <amarao> Yes, but if that datasource is openstack metadata, it needs dhcp...
[13:38] <smoser> so you are on openstack ?
[13:38] <smoser> ironic ?
[13:38] <amarao> Ironic, to be precise.
[13:38] <amarao> Yep.
[13:39] <smoser> and not (ubuntu 12.04 precise) to be precise.
[13:39] <amarao> And I found that 4 my lab servers each has different names for their interfaces...
[13:39] <smoser> i thought that at one point ironic deployment would provide a config drive or put the config drive data somehwere in the deployed sysstem.
[13:39] <amarao> Nah. I want to run Xenial, Jessie, Centos7, and, maybe, some suse.
[13:39] <smoser> is that not the case now?
[13:40] <smoser> how is this "supposed" to work on ironic?
[13:40] <amarao> smoser: Not exactly. There was a bug in ironic (until I report it) which prevented to usage of config drive with cloud init at all.
[13:40] <smoser> so, with a config drive, it should work.
=== rangerpbzzzz is now known as rangerpb
[13:41] <amarao> https://bugs.launchpad.net/ironic/+bug/1656854
[13:41] <smoser> 'unbound' means "not connected" ?
[13:42] <amarao> I tried to use ConfigDrive, but it very unrelable. Older versions of cloud-init does not want to configure network from config drive. I was able to make it works with Xenial, but jessie is not good (cloud-init 0.7.6)
[13:42] <smoser> yeah, you're going to need newer cloud-init
[13:42] <smoser> sorry, but that just is what it is.
[13:43] <amarao> And centos7 has no newver version at all... (+ 30Mb of python dependencies which come with 0.7.6->0.7.7). So I'm falling back to dhcp...
[13:43] <smoser> amarao, thats a well written bug, thank you!
[13:43] <smoser> where do the 30M of python dependencies come from ?
[13:43] <smoser> probably in a python2 -> python3 change i suspect
[13:44] <smoser> cloud-init can still run in python2
[13:44] <smoser> but the packaging would have to be addressed to support that.
[13:44] <smoser> i realize thats a lot, and you just want it to work
[13:45] <smoser> amarao, so have you tried xenial with that unbound fix in place ?
[13:45] <amarao> Yep. For jessie I was able to use backports, (with 0.7.7), but with centos7 I feel very exhausted...
[13:46] <smoser> amarao, ^
[13:46] <amarao> smoser: That bug (with 'unbound') is fixed now, and we has our fix in place (just replaces 'unbound' with 'physical' at metadata creation). I show it as illustration that 'ConfigDrive' is not an expected way for Ironic. When I asked guys at #ironic they said that it's unusual (to use CloudDrive).
[13:47] <amarao> And there is one more problem. In ironic cloud drive is /dev/sda2 (partition at the end of the physical disk or raid array). And cloud-init docs says that CloudDrive should be whole disk, not partition.
[13:47] <amarao> "Must be a un-partitioned block device (/dev/vdb, not /dev/vdb1)" http://cloudinit.readthedocs.io/en/latest/topics/datasources/configdrive.html#version-2
[13:49] <smoser> amarao, if it has a correct label (config-v2) then it probably will work
[13:49] <amarao> I can't say this is Ironic bug, because there is no way to create 'whole disk' out of nothing in hardware environment. (And it worked as /dev/sda2 for Xenial, anyway). So it looks like bug in docs for cloud-init.
[13:49] <smoser> let me check, and i'd fix that in cloud-init.
[13:50] <amarao> Should I report it as a bug for cloud-init?
[13:50] <smoser> i'm pretty sure the doc is just wrong
[13:53] <smoser> amarao, have you tried?
[13:53] <smoser> amarao, i'm also interested in thoughts on how this realistically could work for bare metal without any locally provided information..
[13:53] <smoser> what would cloud-init be expected to do?
[13:54] <smoser> dhcp on all nics and attempt to load http://169.254.169.254/openstack on each one is going to be unreliable / timeout / racey
=== shardy_lunch is now known as shardy
[13:57] <smoser> i'm pretty sure reading current code that if the filesystem has a label of 'config-2', then it will work
[13:57] <smoser> ie, does not have to be a full dis.
[13:57] <smoser> disk
[13:57] <amarao>  smoser It's a nice point about multiple DCHP....
[13:57] <amarao> I'll report it as bug for cloud-init docs, I think.
[13:58] <amarao> it == whole disk thing
[13:58] <smoser> well,. please test and make sure i'm right or wrong :)
[14:01] <smoser> amarao, sorry to pester you... where do you get the ubuntu image / how do you make it ?
[14:05] <amarao> smoser: I build it myself.
[14:05] <smoser> how?
[14:05] <amarao> Here the main part:       DIB_CLOUD_INIT_DATASOURCES: "ConfigDrive, OpenStack"
[14:06] <amarao> + cloud-init-datasources element.
[14:06] <smoser> there is some tool that you use i guess ?
[14:06] <amarao> diskimage-builder mostly.
[14:06] <amarao> Plus dibctl to manage it.
[14:07] <amarao> (The last one is self-made and under development at https://github.com/serverscom/dibctl)
[14:07] <smoser> what pops out of diskimage-builder ?
[14:08] <smoser> ie, what is the file format of the image ?
[14:08] <amarao> qcow image. baremetal-ubuntu-xenial.img.qcow2
[14:08] <smoser> and its a full disk image ? partitioned with bootloader? ?
[14:09] <amarao> Ironic (with agent_ipmitool) write it to the baremetal node, and then writes a small ConfigDrive partition at the end (if nova boot used with --config-drive True).
[14:09] <amarao> Yes, it's a whole image with grub inside.
[14:10] <amarao> Elements: cache-url cloud-init-datasources dib-run-parts dpkg install-static package-installs ubuntu-minimal vm
[14:10] <smoser> so agent_ipmitool does a dd of that qcow image (converted to raw) to hopefully the bios boot disk.
[14:10] <amarao> ubuntu-minimal => debootstrap
[14:10] <smoser> and then it edits the partition table to add a partition at the end of the disk ?
[14:10] <amarao> Yes. It uses ipmitool to switch into PXE, and server is configured to use 1st disk to boot.
[14:11] <amarao> I believe so, but I never looked into IPA (agent) code. But there is a /dev/sda2 inside instance with all metadata (including networking-data.json)
[14:11] <amarao> Unfortunately networking-data.json is ignored by older cloud-inits :(
[14:11] <amarao> <0.7.7
[14:20] <smoser> amarao, yes it is.
[14:22] <amarao> smoser: thanks, I got confirmation. I'll try to use ConfigDrive before giving up. Jessie probably would work eventually, centos is harder to do. If not, I'll dance again around dhcp-for-everyone...
[14:36] <smoser> amarao, the cloud provider (ironic in this case) really needs to some how tell the system what the networking configuration is expected to be.
[14:40] <smoser> amarao, i'd be pretty interested in knowing how this "builder" script works
[14:40] <amarao> smoser: ... and it's a real pain... Ironic now even does not support multiple switches (physical networks).
[14:40] <smoser> http://paste.ubuntu.com/24195576/ <--
[14:41] <smoser> i'd suspect htat has a fair chance of being something that could be used.
[14:42] <amarao> cloud-image-utils: /usr/bin/mount-image-callback
[14:42] <smoser> ?
[14:43] <amarao> I've just searched what is 'mount-image-callback'
[14:43] <smoser> ah. yeah. its nice.  https://ubuntu-smoser.blogspot.com/2014/08/mount-image-callback-easily-modify.html?showComment=1453265690071
[14:44] <amarao> smoser, I have other question about cloud-init. If I boot instance with ConfigDrive and dhcp, it writes into interfaces.d/ that interface should be dhcp, not the ip from networking-data.json. Is this a bug, feature or  just coincidence?
[14:45] <smoser> "with configdrive and dhcp" ?
[14:45] <smoser> if cloud-init does not find networking information (such as networking-data.json) then it will render "fallback" networking config that would be the equivalent of "dhcp on eth0"
[14:45] <smoser> so.. .you could be hitting that
[14:45] <smoser>  /var/log/cloud-init.log will have info
[14:46] <amarao> I mean I boot instance with dhcp-enabled network and --config-drive=True. And it created file /etc/network/interfaces.d/50-cloud-init.cfg with content 'auto eno2  iface eno2 inet dhcp'
[14:47] <amarao> pplying network configuration from ds bringup=False: {'version': 1, 'config': [{'name': 'eno2', 'mac_address': '18:66:da:5f:07:f5', 'subnets': [{'type': 'dhcp4'}], 'type': 'physical', 'mtu': 1500}, {'address': '8.8.8.8', 'type': 'nameserver'}]}
[14:47] <amarao> 2017-03-17 12:14:39,022 - util.py[DEBUG]: Writing to /etc/network/interfaces.d/50-cloud-init.cfg - wb: [420] 408 bytes
[14:47] <amarao> 2017-03-17 12:14:39,022 - main.py[DEBUG]: [local] Exiting. datasource DataSourceConfigDrive [net,ver=2][source=/dev/sda2] not in local mode.
[14:47] <amarao> It sounds like ConfigDrive which created dhcp interface...
[14:48] <amarao> *dhcp settings for interface.
[15:03] <smoser> i'm confused.
[15:03] <smoser> it soulds like you cloud-init did what it should have.
[15:03] <smoser> no?
[15:03] <smoser> that ll looks like working to me
[15:03] <smoser> unless you're saying 'auto eno2  iface' is on one line
[15:12] <smoser> amarao, ^ ?
[15:13] <amarao> I just shorten it up.
[15:13] <amarao> I thought about it, it looks reasonable to me. If network is 'dhcp' type interfaces should be dhcp.
[15:13] <amarao> (My initial expectation was that if ConfigDrive is enabled, it always would be a static ip, but I was wrong).
[15:15] <smoser> ah. right. as you showed there, the network config provided (if you snow network-data.json it'd be good). but it certainly looks like network-data.json told cloud-init to dhcp on that nic.
[15:16] <amarao> network was '--enable-dhcp' type, it had worked fine (until I deleted it just now). But I'll try now to use ConfigDrive with static IPs (no dhcp). It's my actual goal and the best how it may work for us.
[15:17] <amarao>  smoser, btw, where is a bugtracker for cloud-init? I tried to find one and I failed.
[15:19] <rharper> https://bugs.launchpad.net/cloud-init
[15:19] <rharper> amarao: ^
[15:19] <amarao> Oh, thanks.
[16:06] <powersj> magicalChicken: around?
[16:33] <powersj> magicalChicken: nevermind, figured it out :)
[16:33] <paulmey> rangerpb, Odd_Bloke: I'm going to figure out if the hostname reported matters in any way
[16:34] <paulmey> I don't think it should, since it's all keyed off of the container ID
[16:34] <paulmey> the wire server knows which VM is talking to it and should attribute the status update accordingly
[16:35] <paulmey> (otherwise, it's time to file some bugs here...)
[16:37] <Odd_Bloke> paulmey: Thanks!
[16:50] <smoser> powersj, i dont understand
[16:50] <smoser> https://code.launchpad.net/~powersj/cloud-init/+git/cloud-init/+merge/319878
[16:50] <smoser> when i ran with the .py files input, it ran my tests.. ithought
[16:50] <powersj> smoser: double check because when I ran it wan exactly 0 tests for those two
[16:50] <smoser> PasswordListTest inherits from CloudTestCase
[16:50] <powersj> https://paste.ubuntu.com/24195907/
[16:50] <smoser> so why would you need
[16:50] <smoser>  TestPasswordList(base.PasswordListTest, base.CloudTestCase):
[16:50] <smoser> explicitly ?
[16:51] <powersj> I believe it has to do with where we are running nose from and how nose discovers tests
[16:51] <smoser> agreed on the 'base' filling up, if we do have that problem, we just move that to 'passwordtests.py' or something.
[16:52] <smoser> i dont understand.
[16:52] <smoser> why would it not think this needs testing:
[16:52] <smoser> http://paste.ubuntu.com/24196107/
[16:53] <powersj> I didn't try a pass hmm
[16:53] <smoser> that has 'Test' in its name, and extends (indirectly) from UnitTest.TestCase
[16:53] <smoser> so... i dont know why it would not liek
[17:01] <magicalChicken> smoser: discovery isn't done via the unittest loader directly
[17:01] <magicalChicken> smoser: because we have to be able to get the data and cloud-config into the testcase's attributes
[17:02] <magicalChicken> see tests/cloud_tests/testcases/__init__.py
[17:03] <magicalChicken> i agree that it would be better for just base.PasswordListTest to work, i can see if i can extend the way i detect inheritance from base.CloudTestCase to handle a test class indirectly inheriting from there
[17:03] <magicalChicken> i can't create instances there though, since that has to be done via the unittest loader, and it is a bit more difficult to do that on types
[17:05] <smoser> magicalChicken, i dont understand though.
[17:05] <smoser> i dont understand why powersj's' change made any difference
[17:06] <magicalChicken> because CloudTestCase needs to be a base for the individual test class
[17:07] <magicalChicken> the way it is currently written it doesn't recurse through base classes to check, so it doesn't realize that PasswordListTest inherits from CloudTestCase
[17:08] <magicalChicken> i can modify it to be able to detect that though, once i finish up debugging centos tests
[17:17] <smoser> hm.. where is that check ?
[17:17] <smoser> you didnt' just check isinstance ?
[17:17] <magicalChicken> it isn't possible to use isinstance there because its just the class type, not an instance
[17:17] <magicalChicken> its in tests/cloud_tests/testcases/__init__.py on line 23
[17:18] <smoser> ah
[17:20] <smoser> magicalChicken, http://stackoverflow.com/questions/1401661/list-all-base-classes-in-a-hierarchy-of-given-class
[17:20] <smoser> getmro ?
[17:21] <magicalChicken> smoser: nice, i didn't know inspect had that
[17:21] <magicalChicken> should be easy to switch over
[17:22] <magicalChicken> i can throw together a separate mp for that real quick
[17:30] <smoser> rharper, https://code.launchpad.net/~smoser/cloud-init/+git/cloud-init/+merge/320233
[17:30] <smoser> now has tests
[17:31] <smoser> https://code.launchpad.net/~smoser/cloud-init/+git/cloud-init/+merge/319943 i'd like your thoguths as if its ok to take that ... perhaps we should just open a bug to handle the _write_network path... i will do that
[17:31] <smoser> and then i hitnk that one is good
[17:31] <smoser> and  https://code.launchpad.net/~smoser/cloud-init/+git/cloud-init/+merge/320212 too
[17:34] <magicalChicken> smoser: i got the mp for switching to inspect.getmro() in if you want that in for the password list test
[17:34] <magicalChicken> https://code.launchpad.net/~wesley-wiedenmeier/cloud-init/+git/cloud-init/+merge/320234
[17:35] <smoser> you commit message is odd
[17:36] <smoser> in english sometimes we use a '.' to separate sentences. not only the '- '
[17:36] <smoser> :)
[17:36] <smoser> ie, your list there could just be a paragraph
[17:36] <magicalChicken> smoser: right :)
[17:36] <magicalChicken> i think almost all of the integration-testing commits are formatted like that
[17:37] <smoser> well, when you do a lot of things in a single commit or MP, it makes sometimes sense to list what you did
[17:37] <smoser> but when you do one thing , a list isnt necessary
[17:37] <magicalChicken> yeah, this is a 1 liner though
[17:37] <smoser> i'll pull ;)
[17:37] <magicalChicken> thanks
[17:41] <smoser> powersj, ^ now you should be able to simpllify your test like i suggested
[17:41] <powersj> smoser: ok will take a look. The getmro find is cool, never heard of that
[17:48] <powersj> smoser: updated
[17:53] <magicalChicken> powersj: have you looked into building rpms for integration-testing on centos?
[17:53] <powersj> magicalChicken: no I have not
[17:53] <magicalChicken> i think the only remaining test failures in teh distro-features branch are just because i only have a 0.7.5 rpm
[17:53] <magicalChicken> powersj: oh, ok
[17:54] <magicalChicken> i've tried to get rpmbuild working but there's something wrong with how i did the spec file
[18:00] <powersj> magicalChicken: did you see how brpm works?
[18:01] <magicalChicken> powersj: yeah, i'm basing my spec file off the template it uses, and the call to rpmbuild looks good
[18:01] <magicalChicken> its failing the install stage though becasue the default config files aren't where it expects
[18:08] <rharper> smoser: ok, reviewed both, approved second
[18:24] <smoser> rharper, ok. thanks. responded to second, will make some changes.
[18:24] <rharper> cool
[18:24] <smoser> er... to the one that needed fixing
[18:24] <rharper> right
[18:30] <smoser> rharper, https://code.launchpad.net/~smoser/cloud-init/+git/cloud-init/+merge/320212 <--
[18:30] <smoser> that is pretty simple.
[18:30] <smoser> other than being arguably not necessary, it seems safe
[18:31] <rharper> smoser: +1
[18:59] <smoser> rharper, updated https://code.launchpad.net/~smoser/cloud-init/+git/cloud-init/+merge/320233
[19:01] <rharper> k
[19:02] <rharper> smoser: so does lp not update the MR with the new diff?  I'm not seeing the new changes yet
[19:04]  * smoser adds --force
[19:04] <smoser> rharper, reload
[19:04] <rharper> y
[19:05] <rharper> smoser: missing the execption for none found
[19:05] <rharper> and the unittest of that
[19:07] <rharper> smoser: one other comment in MR;  we should use /etc/network/interfaces.d as it's owned by ifupdown package (where eni is not since it's volatile )
[19:07] <rharper> w.r.t verifying paths in eni.available
[19:10] <smoser> but we dont require /etc/network/interfaces.d
[19:10] <smoser> if its not there and the renderer shoudl be used, then it will work fine
[19:10] <rharper> true; but it's going to be present if ifupdown is installed
[19:10] <rharper> no
[19:10] <rharper> we will recreate the path
[19:10] <smoser> right.
[19:10] <rharper> but we expect ti to be there
[19:10] <smoser> which is fine.
[19:10] <rharper> the facthat we recreate it is someone bogus
[19:11] <rharper> somewhat
[19:11] <rharper> it's part of the package; we're using dir paths to avoid doing package lookups
[19:14] <smoser> i dont know. we dont need it to be there, and the fact that it is there does not give us any more information as to whether or not it should be used.
[19:14] <smoser> where as lack of /etc/network/interfaces indicates that at least currently, it will not work.
[19:14] <rharper> well it *should* be there if you have ifupdown installed
[19:15] <rharper> which image would we encounter if it's not there?;  its the same for the sysconfig paths; they might not be there (and maybe sysconfig render also does extra ensure dirs which we should have to)
[19:16] <rharper> in many cases we "fix up stuff" and others we "raise exceptions"; I can see this either way;  so I won't push any more;
[19:17] <smoser> http://paste.ubuntu.com/24196962/
[19:17] <smoser> directories owned by packages are wierd.
[19:17] <smoser> especially empty ones.
[19:17] <rharper> yeah
[19:17] <smoser> dpkg itself doesnt even care that i deleted it
[19:18] <rharper> well, dpkg likely has a bug
[19:18] <smoser> no. it really doesnt track directories
[19:18] <rharper> because if you query what owns the dir it tells you
[19:18] <smoser> its only there for cleanup
[19:18] <rharper> dpkg -S clearly does
[19:18] <smoser> when you removve it if the directory is empty it will clean it up
[19:18] <rharper> so, inconsistency/bug ..
[19:18] <smoser> multiple things can own a directory too
[19:18] <smoser> the same one and no conflicts
[19:18] <rharper> which path does dpkg -S return a list of multiple packages?
[19:19] <rharper> oh
[19:19] <rharper>  /etc
[19:19] <rharper> awsome
[19:19] <smoser> :)
[19:19] <smoser> yeah.
[19:19] <smoser> it just means "create on install, remove if empty on removal"
[19:19] <smoser> at least that is my experience.
[19:20] <rharper> well, then in general I'm not so sure we should be checking paths at all then
[19:20] <rharper> maybe in the sysconfig available we can check other binaries that present but not elsewhere
[19:20] <smoser> well, we're trying to check "is this the used network tool"
[19:20] <rharper> right
[19:20] <rharper> I don't think we have a good way to do that reliably
[19:20] <rharper> these are just guesses
[19:20] <smoser> the path i check in sysconfig *is* a binary
[19:21] <rharper> oh, yes we have some
[19:21] <smoser> etc/sysconfig/network-scripts/ifdown-eth
[19:21] <smoser> is effectively a binary.
[19:21] <rharper> I just meant we dont have a way to ask "OS, which networking configuration system are you using"
[19:21] <smoser> so... the goal here is to determine "is this thing the network tool for this system".
[19:21] <rharper> centos/fedora likely have both sysconfig and network-manager (much like we have in UC16)
[19:21] <smoser> right
[19:22] <rharper> or even sysconfig/networkd/network-manager and we won't really know
[19:22] <smoser> so i think over time we'll just improve this.
[19:22] <rharper> y
[19:22] <smoser> as it is right now, it does what it did before
[19:22] <smoser> unless you try to trick it
[19:23] <smoser> hm...
[19:23] <smoser> thinking of my desktop
[19:23] <smoser> it uses both ifupdown and network manager
[19:23] <smoser> (or at least it could)
[19:23] <smoser> wheeee!
[19:25] <rharper> yeah
[19:35] <smoser> rharper, so we dont write /etc/network/interfaces
[19:35] <smoser> right ?
[19:35] <smoser> currently, we expect it is there.
[19:36] <smoser> and that it has 'source /etc/network/interfaces.d/' in it
[19:38] <smoser> and bah. i had the other test case you asked fro locally
[19:38] <smoser> smoser git fail today
[19:50] <smoser> rharper, you're still working on https://code.launchpad.net/~raharper/cloud-init/+git/cloud-init/+merge/319259
[19:50] <smoser> ?
[19:53] <rharper> smoser: yes, waiting for your two changes to land in master and then I'll rebase
[19:53] <rharper> stepping out for 30 mins, have to go pickup the kids; then I'll finish up the rebase
[19:54] <smoser> https://code.launchpad.net/~smoser/cloud-init/+git/cloud-init/+merge/320233
[19:54] <smoser> rharper, ^ quick ...
[19:54] <rharper> y
[19:54] <smoser> can you click agree if you do ?
[19:54] <smoser> then i'll pull
[19:54] <smoser> if you dont thats fine too, but i thoguht we were in agreement at this point
[19:55] <rharper> yes
[19:55] <smoser> suck.
[19:56] <rharper> bbiab
[19:56] <smoser> go now read when you return on that link... i'll put some text there
[19:57] <smoser> rangerpb, around ?
[19:57] <smoser> in the case where you use NetworkManager to bring up networking
[20:37] <smoser> rharper, just pushed another commit on top of that branch... woudl like your feedback when you see it.
[20:56] <rharper> smoser: ok
[20:58] <rharper> smoser: so, I'm for (a) since it means we don't touch stages.py ;  that said, this is effectively the same as just having a hard-coded default in the distro
[20:59] <rharper> I had suggested that the distro class itself could set a default policy is none is found;
[21:00] <smoser> rharper, well i implemented something like a'
[21:00] <smoser> in  my commit
[21:00] <smoser> but with  more information
[21:09] <rharper> ok
[21:10] <rharper> I'm find with that;  we can drop the exception for hardcoded default in the distro if we wanted to later
[21:25] <paulmey> rangerpb, Odd_Bloke: it seems that on Azure, the intent is that the instance DNS name is equal to the hostname set on the VM
[21:26] <paulmey> the waagent publish_hostname functionality is proof of that
[21:27] <paulmey> so the "with temporary_hostname(...)" code is not necessary if the hostname has been set correctly already
[21:29] <paulmey> at least, that's how I interpret the intent of https://git.launchpad.net/cloud-init/tree/cloudinit/sources/DataSourceAzure.py#n77
[21:30] <paulmey> and its usage here: https://git.launchpad.net/cloud-init/tree/cloudinit/sources/DataSourceAzure.py#n120
[21:32] <Odd_Bloke> paulmey: When you say "correctly", you mean "set to the same as the DNS name", right?  This code was introduced because people sometimes want a hostname on an instance that is different to the hostname that Azure expects an instance to have.
[21:45] <paulmey> if it was ever the case that Azure cared about the hostname, that is no longer so
[21:46] <paulmey> Azure provides the hostname that people put in at VM creation time through the ovf file
[21:46] <paulmey> but people are free to change that
[21:47] <paulmey> the agent has code to detect a hostname change and bounce the interface to update DNS
[21:47] <paulmey> but that is just a convenience
=== rangerpb is now known as rangerpbzzzz