=== worth is now known as mushtar [15:43] Hey, we're having an issue where our puppet section is failing to install Puppet from our repo. [15:43] One person here feels it's possibly because networking isn't fully up... [15:44] Isn't it safe to say that cloud-init will be running after networking is operable? [15:44] does anyone see anything wrong with this configuration: http://pastie.org/8523144 [16:02] What is the difference between "- UserName" and "- name: UserName === ctracey|away is now known as ctracey [17:20] tmclaugh[work], ubuntu ? [17:21] smoser: CentOS [17:21] does cloud-init perform any networking service restart? [17:21] it really depends on the datasource, but for ubuntu all interfaces defined in /etc/network/interfaces are guaranteed to be up before packages will be installed. [17:21] tmclaugh[work], why would it do a restart ? [17:22] smoser: I don't know. Just ruling it out. I'm 99% certain that networking is initialized and fully operational before cloud-init starts and that it's not causing the network connection to blip [17:22] to backup a few steps, out puppet package installation periodically fails. [17:22] So someone proposed, "let's move the puppet installation to further down in the cloud-init order" [17:23] Chocobo is gone [17:23] but http://paste.ubuntu.com/6510271/ is the eanswer to his question [17:23] basically, he provided broken yaml. [17:23] He wants to move it from cloud_config_modules to cloud_final_modules [17:24] tmclaugh[work], do you have multiple interfaces ? [17:24] he's claiming that maybe by delaying the install Networking will be working. Which makes no sense to me. [17:24] nope, signle interface [17:24] i can't speak definitevely on the init scripts for centos [17:24] The host should have successfully DHCPed before cloud-init starts. [17:24] but for ubuntu, yes. your statement above is correct [17:24] what is the datasource you're using ? [17:24] (openstack or ec2 ?) [17:25] and I'm 99% sure this is the case with CentOS [17:25] ec2 [17:26] i suspect that if it were not the case on ec2, you'd not be the first to report this issue. [17:28] Good, time for another argument with this person. :) [19:17] Is there a way to test cloud configurations? I am having a real problem with "users:" [19:19] Chocobo, http://paste.ubuntu.com/6510271/ [19:19] running that will expose your problem [19:19] you had invalid yaml [19:21] smoser: Thanks... also if I move "vmuser" to the first entry in users, I should be able to eliminate the "user: vmuser" line correct? [19:23] 'user' affects the entry in user that is marked 'default: True'. [19:23] i think. [19:23] wait [19:23] ignore that last statement [19:24] from doc/examples/cloud-config-user-groups.txt: [19:24] # users[0] (the first user in users) overrides the user directive. [19:24] so yeah: [19:24] users: [19:24] - name: vmuser [19:25] smoser: thanks, I will give that a shot. [19:26] Chocobo, note, unfortutely this bit of code has been error prone :-( [19:26] smoser: the "user:" creation is error prone? [19:26] well...w ait. [19:27] the thing that is error prone is the inclusion of 'user:' into 'users' [19:27] if you only use 'users' [19:27] you should be ok [19:28] ok, that is alright... and it is ok to list a user that already exists (root for example) [20:01] error prone u say smoser, impossible, ha [20:01] Chocobo, its ok to list a user that exists [20:01] but it wont be modified [20:02] ie, its gecos wont be changed. [20:02] (or groups) [20:25] smoser: How aout locking an account? [20:25] i think that is only applied on creation [21:04] smoser: ok, thanks. === ctracey is now known as ctracey|away