[13:25] <sinanp> I am new to cloud-init, I launched a VM with the default cloud.cfg. It look likes it added a swap entry to fstab, but can't find in the config which line that does. Any suggestions?
[16:07] <smoser> sinanp, ec2?
[16:07] <smoser> if ther eis a swap device provided to it from the metadata service, it will make use of the swap space . some instances provide that.
[16:08] <smoser> cloud-init *can* create and use a swap file, but wont do that by default.
[16:31] <cetex> So, i've tried figuring out how people solve cloud-init on-premise
[16:32] <cetex> with pxe-booted (ramdisk only) instances
[16:32] <cetex> Can't find any good solution for this scenario, but i'm thinking i could easily implement the magic 169.254.169.254 magic ip.
[16:33] <cetex> so, will cloud-init just try to ask for that ip? or does it figure out it's on ec2 before even asking?
[17:15] <smoser> cetex: earlier versions of cloud-init will just look for that eventually.
[17:15] <smoser> newer versions require some identification of the platform beore they'll go polling there.
[17:16] <smoser> but you can tell it to look there (or another IP address) if you're configuring it
[17:27] <cetex> smoser: how would i do that? tell it to go to some url, or assune ec2?
[17:32] <smoser> you can modify the image ?
[17:36] <smoser> cetex: well, if you're building your own images and they're mostly static, then the easiest thing to do is put data in /var/lib/cloud/nocloud/
[17:37] <smoser> if you want it to use a web service that would provide custom information to each node, then you could mimic ec2. but i  might suggest instead doing "nocloud" and a "seed"
[17:38] <smoser> http://cloudinit.readthedocs.io/en/latest/topics/datasources/nocloud.html
[17:39] <smoser> and then some  more example of nocloud http://bit.ly/ci-ubuntu-netconfig
[17:43] <smoser> blackboxsw, powersj so. i'm thinking about the nocloud integration, and thinking how nice the c-i is witih that pretty pipeline thingy
[17:44] <smoser> but i can't bring myself to write and duplicate a bunch of 'stages' since i found jenkins job builder that can make jobs out of re-usable parts much more nicer.
[17:44] <powersj> smoser: yeah the syntax of jjb for the pipeline sucks
[17:44] <smoser> where do i read about variable substituion and such for pipelines
[17:44] <smoser> does jjb have some support for pipelines ?
[17:45] <powersj> yes see the cloud-init-ci.yaml
[17:45] <powersj> that's why I require a specific version of jenkins-jobs
[17:45] <powersj> i.e. the one that supports pipelines
[17:45] <smoser> hm.. thinking. i thoguht that was basically just blobs to jjb
[17:46] <powersj> here is the doc on pipelines themselves: https://jenkins.io/doc/book/pipeline/
[17:46] <powersj> and here is the doc for jjb pipelines: https://docs.openstack.org/infra/jenkins-job-builder/project_pipeline.html
[17:48] <smoser> ah.
[17:48] <smoser> ok. the {{ that make sense.
[17:48] <smoser> fun
[17:49] <blackboxsw> yeah that link is the only documentation I'd looked at for pipelines https://jenkins.io/doc/book/pipeline/ as basics
[17:49] <blackboxsw> I can dig up another example of pipelines from livepatch I think.. lemme check
[17:50] <blackboxsw> hmm nope https://github.com/CanonicalLtd/livepatch-client/blob/master/Jenkinsfile
[17:51] <smoser> blackboxsw: i just didn't realize how i'd gert variable substitution on a per-job (or per-THING) basis
[17:51] <smoser> but the jjb gives me that at least somehow.
[17:51] <smoser> ie, i'm going to have 3 jobs each that differ in only the name of the release.
[17:52] <smoser> and coudlnt bring myself to duplicate big pipeline blobs to get that difference
[18:04] <cetex> smoser: if i'm building my own images through ansible (which we're doing) i can easily just write ansible-stuff for it.
[18:05] <cetex> smoser: but if i'm building my own images through ansible, and then want the hosts which boot from them to download a user-data script and run it on boot to adapt the image for the host?
[18:05] <cetex> for example, to setup consul to join the local consul-cluster, nomad as well, maybe grab credentials to use to authenticate to s3 and stuff.
[18:05] <cetex> but still being on premise.
[18:06] <smoser> yeah. so that should be doable via /var/lib/cloud/seed . the noclodu source is what i'd recommend.
[18:06] <cetex> I've done it with dhcp-options earlier, but there's too many assumptions in there.
[18:06] <cetex> i'd like cloud-init to be given a url where it can find everything of this
[18:06] <cetex> and then have cloud-init download and run it.
[18:07] <smoser> so you'll assume "dhcp on the first interface" for network configuration
[18:07] <smoser> right?
[18:07] <blackboxsw> could we just define a function  that script that the pipeline could call w/ a list? like this? http://pastebin.ubuntu.com/25919298/
[18:07] <cetex> we provision the network config through ansible, it's hard-coded into the image
[18:08] <cetex> and i'd like to not touch that usually.
[18:09] <smoser> cetex: sure. i guess . you can provision the network howeve ryou want as long as it comes up i guess. i dont understand how you'd re-use an image with specific network info other than dhcp built in
[18:10] <cetex> well, everything is dhcp
[18:10] <cetex> and everything has interface 1 & 2 bonded into lacp
[18:10] <cetex> so, that's it.
[18:12] <smoser> ok.
[18:12] <smoser> so 2 things
[18:12] <smoser>  https://git.launchpad.net/cloud-init/tree/doc/examples/cloud-config-datasources.txt
[18:13] <smoser> see the 'NoCloud' section there.
[18:13] <smoser> i'm suggesting that you put a file like this (with just the NoCloud) section and a 'seedfrom' url with whatever you want there.
[18:13] <smoser> and then for networking, you'll have to tell cloud-init not to configure networking
[18:13] <smoser> or you could declare to cloud-init the networkign that you wanted. but since you're already doing that i figure let that be as it is.
[18:14] <smoser> to disable networking configuration in clodu-init put in
[18:14] <smoser>  /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg
[18:14] <smoser> network: {config: disabled}
[18:19] <blackboxsw> or pipelines related even something like http://pastebin.ubuntu.com/25919350/
[18:20] <smoser> cetex: http://paste.ubuntu.com/25919368/
[18:21] <smoser> blackboxsw: can you hangout a minute ? and explain to me ?
[18:22] <blackboxsw> yes let's powersj feel free to join if you like meetings too
[18:22] <blackboxsw> :)
[18:22] <cetex> smoser: alright. cool :D
[18:23] <cetex> smoser: so, could i make cloud-init pick-up additional network-configuration as well even though i don't want cloud-init to do initial network-config?
[18:23] <cetex> Ideally i'm thinking it would be best if cloud-init just ran the user-data script though. then we could solve * there.
[18:24] <cetex> I mean, just add a "bond0.xxxx" interface where xxxx is a vlan tag and do dhcp/static ip on it
[18:48] <smoser> cetex: cloud-init doesn't currently really "hotplug" network stuff.
[18:48] <smoser> that is on the roadmap but right now it is just first boot only.
[18:50] <smoser> cetex: oh. and you're pxe booting too arent you
[18:50] <smoser> this is kind of easier then.
[18:50] <smoser> you can put seed on the kernel command line
[21:22] <robjo> could someone take a quick look at config/cc_update_etc_hosts please?
[21:23] <robjo> the doc string says when manage_etc_hosts is set to local host then 127.0.1.1 fqdn hostname will be added to the hosts file
[21:24] <robjo> however, if the distro implementation does not overwrite _get_localhost_ip() then the IP is really 127.0.0.1
[21:24] <robjo> is that a typo or is the distro implementation expected to overwrite _get_localhost_ip() ?
[21:28] <robjo> smoser: are you around ^^^^
[21:28] <nacc> robjo: i think smoser is afk right now
[21:29] <robjo> blackboxsw: see above, thoughts?
[21:33] <blackboxsw> robjo: checking ... (muxing w/ a meeting right now)
[21:40] <blackboxsw> robjo: correct assessment by you
[21:40] <robjo> I'll fix the typo
[21:40] <blackboxsw> looks like debian (and thereforce ubuntu distro subclass) do update get_localhost_ip to  127.0.1.1
[21:41] <blackboxsw> but centos,rhel,suse don't
[21:42] <blackboxsw> robjo: sorry, so ubuntu/debian is 127.0.1.1 rhel,centos,suse,freebsd use 127.0.0.1
[21:43]  * blackboxsw wonders how we really *want* this to behave on all distros (I'd like to have same behavior on all distros if it makes sense)
[21:46] <blackboxsw> if you are updating the text robjo, I'll make sure we have a talk prior to landing the merge proposal to make sure behavior is what we expect/document on all distros  (if there are differences)
[21:46] <robjo> For now I updated the doc, merge request comming
[21:46] <blackboxsw> +1 th
[21:46] <blackboxsw> +1 thx
[21:47] <robjo> blackboxsw: https://code.launchpad.net/~rjschwei/cloud-init/+git/cloud-init/+merge/333418
[21:47] <robjo> also include fix for the suse hosts template expansion bug which is why I stumbled across this to begin with ;)
[21:56] <blackboxsw> robjo: will have a review for that by tomorrow. thx
[22:01] <blackboxsw> btw robjo we also have an issue on ubuntu in this space (I don't like the behavior if both fqdn & hostname are both provided) so we might have a follow-up that properly handles fqdn and hostname behavior shortly thereafter. will make sure to ping you on it for review/thoughts
[22:02] <robjo> thanks, there's a test now, well for sles anyway :)