#cloud-init 2014-01-27
<smoser> fun bug
<smoser> https://bugs.launchpad.net/cloud-init/+bug/1273255
<natorious> Is there an easy way to disable modules via config on unsupported distro's?
<natorious> ex grug_dpkg on gentoo
<smoser> natorious, yes. you can disable modules. but there is no way to automatically do it based on the distro.
<natorious> hmm, was trying to avoid redefining cloud_config_modules: in the config
<smoser> you should be able to do that.
<smoser> for certain you can do it in /etc/cloud/cloud.cfg
<smoser> almost certain that you can do it via user-data also
<natorious> so distros like redhat would have the same default config as ubuntu and would try loading grub_dpkg too.  Was trying to clean up stack traces in the logs on a default install
<smoser> natorious, right. at the moment there is no way to really easily no redefine those.
<natorious> k, should have a gentoo pr in shortly.  Just finishing a few things.
<natorious> was going to look at adding Arch too
<smoser> natorious, i'd be open to having config modules declare support also.
<natorious> right on.  I'll see what makes sense
<harlowja> smoser u see the venv stuff?
<harlowja> https://code.launchpad.net/~harlowja/cloud-init/tox-venvs
<smoser> harlowja, no. i'll take a look.
<smoser> thanks.
<harlowja> k, np, no more need to install all packages in your root system
<harlowja> for testing or for lint checks
<harlowja> harmw if u need some neutron advice/help, i can bug mark (the neutron ptl) we recently hired him @ yahoo
#cloud-init 2014-01-28
<kwadronaut> hmmm first time i noticed Module ssh-import-id is verified on ['ubuntu'] distros but not on debian distro. It may or may not work correctly.
<kwadronaut> but i never noticed any problems with that.
<kwadronaut> (as in: happy user)
<smoser> kwadronaut, right. i suspect its fine.
<smoser> that one is fairly well known to work, as failures are quite obvious: I CANT SSH IN!
<kwadronaut> (-:
<harlowja> smoser yt
<harlowja> so far this is what i got
<harlowja> http://bazaar.launchpad.net/~harlowja/cloud-init/ds-openstack/view/head:/cloudinit/sources/DataSourceOpenStack.py
<harlowja> input appreciated, need to do a little more shared/common refactoring
<smoser> here now.
<smoser> wooth. i'll take a look.
<smoser> thanks harlowja 
<harlowja> np
<smoser> harlowja, is there vendor data support ?
<harlowja> ya
<smoser> sweet
<harlowja> smoser does the config-drive have vendor data, was analyzing the nova code, didn't see it
<smoser> it should have vendor data.
<harlowja> k
<harlowja> i'll work on refactoring some more of the common stuff today/tommorow, but let me know if i missed anything major
<smoser> harlowja, vendordata should be there.
<smoser>  etc/nova/nova.conf.sample
<harlowja> k
<smoser>  nova/api/metadata/base.py
<smoser> should get into the config drive or the metadata service > HAVANA
<smoser>  >= HAVANA
<harlowja> kk
<harlowja> will make sure its read in the configdrive code
<harlowja> gotta share more of that code
<harlowja> they are basically reading the same stuff :-P
<smoser> harlowja, thanks.
<harlowja> np
<iliyas> I want to add a DNS A record for an instance at boot. Our DNS is managed at UltraDNS. Any pointers how to go about with it ?
<harlowja> iliyas u should just be able to add a script to do that
<harlowja> http://cloudinit.readthedocs.org/en/latest/topics/examples.html#run-commands-on-first-boot 
<harlowja> thats one example
<harlowja> or http://cloudinit.readthedocs.org/en/latest/topics/format.html#user-data-script
<iliyas> harlowja: Thanks. If I want to use the 2nd approach (user-data-script) where should be the script place ?
<iliyas> placed*
<harlowja> depends on the cloud u are running in :)
<harlowja> openstack, ec2?
<harlowja> other
<iliyas> CloudStack
<harlowja> hmmm, k, i'm not so sure about that one then
<harlowja> but typically there is some way to pass in a user-data file
<harlowja> so u'd pass it in via that mechanism
<harlowja> cloudstack documentation should tell u how i would think
<iliyas> I used the 1st approach (run-commands-on-first-boot) to setup the hostname by querying the metadata URL wherein I placed the script on the VM filesystem (/scripts/update_hostname.sh)
<smoser> iliyas, so pretty much anything you can do by modifying the image prior to boot, you can do via user-data in cloud-init.
<harlowja> *as long as its a relatively recent version of cloud-init
<smoser> well, pretty much anything supported boothooks
<smoser> so you can drop a file down inside.
<smoser> but CloudStack support came more recently i think. 
<iliyas> Yes smoser. CloudStack support has been added recently.
<dgarstang1> Anyone awake? :) 
<dgarstang1> I have such bad luck with cloud-init. Is there any reason stuff in /etc/cloud/cloud.cfg.d would be totaly ignored?
<harlowja> dgarstang1 depends, could be many reasons, do u have log files that u can share?
<dgarstang1> harlowja: Here ya go... http://pastebin.com/aAfJY1az
<dgarstang1> not much to it
<harlowja> hmmm, how about /var/log/cloud-init.log
<dgarstang1> I'm expecting to see the final message. The first two lines of the pastebin are from /var/log/cloud-init.log
<harlowja> do u have the rest of /var/log/cloud-init.log?
<dgarstang1> harlowja: Sure. Is anything before the last reboot relevant?
<harlowja> could be
<dgarstang1> kk, here http://pastebin.com/YReDs9Ps
<harlowja> dgarstang1 how cloud-init works is that not all modules will be ran repeatly (Every boot)
<dgarstang1> harlowja: not even final_message ?
<dgarstang1> Also, I'm on Google Compute 
<harlowja> k, on google compute might not be so helpful, never used that myself
<harlowja> *especially if they modified cloud-init
<harlowja> so the final-message should always come out
<dgarstang1> I know cloud-init doesn't have a data source for GCE, but it wasn't clear before I grabbed the one referred to by http://comments.gmane.org/gmane.linux.debian.cloud/965 that if it was failing to run anything was because it was on GCE, or for some other reason
<harlowja> ya, logs not showing to much
<dgarstang1> harlowja: They seldom do
<harlowja> if u turn on debug logging then they will show lots more :-P
<dgarstang1> the ec2 errors certainly went away
<dgarstang1> how?
<harlowja> oh, nm
<harlowja> u already on debug level, lol
<dgarstang1> I changed the Data Source to NoData, but as I said, it still wasn't doing anything. is that because GCE breaks it, or for some other reason? 
<harlowja> unsure, it almost looks like they aren't running all the cloud-init stages
<dgarstang1> i don't need the GCE functionality really. So, if setting the datasource to NoData would at least let scripts run, that's fine
<harlowja> all i see is 'start' and 'start-local' running
<dgarstang1> harlowja: and this is with debug log. See my frustration?
<harlowja> ya, how cloud-init is installed in the GCE images though cloud-init wouldn't be aware of
<harlowja> what images are those?
<dgarstang1> harlowja: custom made with packer
<harlowja> oh, then i have no idea :-P
<harlowja> it appears like the install of cloud-init isn't right
<dgarstang1> harlowja: what makes you say that?
<harlowja> logs aren't showing more than start and start-local running
<harlowja> typically these are the stages 
<harlowja> http://bazaar.launchpad.net/~cloud-init-dev/cloud-init/trunk/files/head:/sysvinit/redhat/
<dgarstang1> harlowja: just a package... 0.6.3-0ubuntu1.9
<dgarstang1> Argh
<harlowja> ya, ubuntu uses upstart, so it could be not configured/using the right ocnfig files
<harlowja> *config
<harlowja> http://bazaar.launchpad.net/~cloud-init-dev/cloud-init/trunk/files/head:/upstart/
<harlowja> smoser might be able to help with those
<dgarstang1> harlowja: it's starting on boot obviously cuz it's logging stuff
<harlowja> ya, 1 stage is running
<harlowja> but not the 'config' stage or the 'final' stage
<harlowja> so something seems off
<dgarstang1> is good? http://pastebin.com/2cJ0hiVJ
<harlowja> ya, but thats not connected to the upstart system
<harlowja> different config
<dgarstang1> http://i.imgur.com/A9tp2w7.jpg
<dgarstang1> hm
<harlowja> ha
<dgarstang1> i suppose I could post a link to a y u no meme, but meh
<harlowja> but then u could have that meme for all software ;)
<dgarstang1> cloud-init is especially frustrating
<dgarstang1> not so good logging, not so good docs
 * harlowja improvements welcome :)
<smoser> dgarstang1, its ubuntu, right?
<dgarstang1> smoser: yep
 * dgarstang1 takes a deep breath
<smoser> that pastebin is odd.
<smoser> cloud-init was being run over and over again
<dgarstang1> smoser: maybe cuz it was exiting !0 ?
<dgarstang1> This is on GCE... Would using GCE with NoDataSource work or just outright barf?
<harlowja> GCE, use openstack ;)
<smoser> it should work.
<harlowja> *j/k
<dgarstang1> harlowja: que?
<harlowja> nm
<dgarstang1> *squinty eye*
<dgarstang1> we have ... contractual obligations. :)
<smoser> you installed an ubuntu package ?
<dgarstang1> smoser: for cloud-init? Yah... for precise. 0.6.3-0ubuntu1.9
<dgarstang1> smoser: Tried to get the one from debian experimental as it apparetly has gce support, but it didn't want to install on precise
<smoser> dgarstang1, is rsyslog installed?
<dgarstang1> Yep
<dgarstang1> I just restarted a new instance of the same image. I'm not sure if a better approach is to use no data source, or to use the patched GCE one
<smoser> ok. looking at this paste http://pastebin.com/YReDs9Ps
<smoser> you know that for it to find the nocloud datasource, you have to populate /var/lib/cloud, right?
<smoser> i think that the behavior you're seeing is what you got on 0.6.3 when there was no datasoruce found.
<smoser> there was no 'none' datasource, so the subsequent portions wouldn't end up running.
<dgarstang1> one sec
<smoser> http://bazaar.launchpad.net/~cloud-init-dev/cloud-init/trunk/files/934/doc/examples/seed
<smoser> read that. 
<smoser> or you may be able to use 'ci-tool' 
<smoser> http://bazaar.launchpad.net/~smoser/cloud-init/ci-tool/view/head:/ci-tool
<smoser> which basically can write a /var/lib/cloud/data/seed dir for you.
<dgarstang1> i have to populate /var/lib/cloud ?
<smoser> "NoCloud" is a datasource, but it has to have data (metadata and userdata).  the "no cloud" part is just that its prvided by you.
<dgarstang1> smoser: maybe I should try the GCE patch then?
<smoser> well, newer cloud-init will probably have dependency issues on 12.04.
<dgarstang1> This is it... http://pastebin.com/GjDWFGMj
<dgarstang1> no, just drop that file in...
<smoser> thats not terribly likely to work/
<dgarstang1> Oh
<smoser> if it was written for newer cloud-init
<dgarstang1> ok, back to no data source then
<smoser> then it wont "just work" on 12.04's version
<smoser> probably would'nt be too hard to port it to 0.6.3.
<dgarstang1> populate /var/lib/cloud... looking for docs...
<smoser> but i pointed at the docs above.
<dgarstang1> one sec
<dgarstang1> is http://bazaar.launchpad.net/~smoser/cloud-init/ci-tool/view/head:/ci-tool the only way to populate /var/lib/cloud? 
<smoser> no. you can do it by hand. its very easy. 
<dgarstang1> doc? :)
<dgarstang1> http://cloudinit.readthedocs.org/en/latest/topics/dir_layout.html ?
<smoser> http://bazaar.launchpad.net/~cloud-init-dev/cloud-init/trunk/files/934/doc/examples/seed
<dgarstang1> oic
<dgarstang1> do I need user-data ?
<dgarstang1> Actually I have a /var/lib/cloud with stuff in it already http://pastebin.com/BChLFcjt
<smoser> sudo sh -c 'd=/var/lib/cloud/seed/nocloud-net/; mkdir -p $d; echo "instance-id: i-abcdefg" > $d/meta-data; printf "%s\n%s\n" "#!/bin/sh" "echo hi mom" > $d/user-data'"#!/bin/sh"; 
<smoser> bah. the '!
<smoser> sudo sh -c 'd=/var/lib/cloud/seed/nocloud-net/; mkdir -p $d; echo "instance-id: i-abcdefg" > $d/meta-data; printf "%s\n%s\n" "#!/bin/sh" "echo hi mom" > $d/user-data"#!/bin/sh"; 
<dgarstang1> so, if I have stuff in /var/lib/cloud already, I'd say thats' not the issue?
<smoser> no. you aren't finding a datasource.
<smoser> because there *is not a datasource*
<smoser> and i'm showing you how to make one.
<dgarstang1> not following context.... this isnt amazon. There is no user-data or instance-id
<dgarstang1> modifying...
<smoser> you're giving it one.
<dgarstang1> smoser: they don't contextually exist in gce.
<smoser> i really don't understand what you're wanting.
<smoser> http://pastebin.com/GjDWFGMj
<smoser> clearly *does* have a instance-id
<smoser> (at least the metadata service has something labeled 'instance-id')
<smoser> but thats not even improtant here.
<smoser> if you're wanting to run cloud-init, then you need to have it find a datasource
<smoser> and you can create a directory in /var/lib/cloud/... that it will see as a datasource
<dgarstang1> smoser: Can I just create an empty /var/lib/cloud/nocloud-net?
<smoser> there was something there before you put it there?
<smoser> you can rm -Rf /var/lib/cloud if you want
<dgarstang1> smoser: yes. http://pastebin.com/BChLFcjt
<smoser> it will all be put back on boot
<smoser> that all was created by cloud-init
<smoser> the *seed* is not crated by cloud-init
<smoser> it is created by you
<dgarstang1> k
<dgarstang1> I created /var/lib/cloud/seed/nocloud-net, changed the data source to datasource_list: [ NoCloud ] ...
<dgarstang1> added a final_message... rebooted... it's not running it
<dgarstang1> Did not find data source. searched classes: ['DataSourceNoCloudNet']
<dgarstang1> I don't know why it even mentions DataSourceNoCloudNet. I certainly didn't specify it
<dgarstang1> yay. running
<smoser> ok. for what its worth, i just pushed a couple small changes to ci-tool.
<smoser> and now:
<smoser>  sudo ./ci-tool reset --full
<smoser>  sudo ./ci-tool seed
<smoser> will populate the datasource and remove other state that might have been present.
<dgarstang1> smoser: seems I can get away with the directory and some dummy data. I need to keep it simple as packer is running this and I don't want to have to store, and push out an entire script
#cloud-init 2014-01-29
<dgarstang1> Has scripts been removed from cloud-init ?
<harlowja> dgarstang1 can u describe that more, not sure how to answer that question :)
<kwadronaut> opinions? should i generate a new hostid for popcorn for each virtual machine?
<kwadronaut> popcon, not popcorn of course.
<smoser> kwadronaut, that same question came up in another package recently.
<smoser> i really kind of think you should.
<kwadronaut> i'm thinking i agree. and i wonder if cloud-init should bother. i think it'd be straightforward but unsure if that could be a default debian tpl
<kwadronaut> s/could/should
<smoser> kwadronaut, maybe cloud-init should just put "intsance-id" into some standard place
<smoser> and then things like popcon could just say:
<smoser> [ -f /run/cloud-init/instance-id ] && HOSTID=$(cat /run/cloud-init/instance-id)$(WHATEVER_ELSE)
<kwadronaut> cloud-init isn't the only player. but you're right that it could also be approached from the other side
<kwadronaut> do you remember the other package with same/similar question?
<dgarstang1> Has scripts been removed from cloud-init ?
<smoser> kwadronaut, pollinate was the other thing
<smoser> dgarstang1, what do yo umean ?
<dgarstang1> smoser: Lemme find an example. one sec
<dgarstang1> smoser: http://pastebin.com/Rf6YBu5L ... i just realised what's really going on here is a YAML anchor... but 'scripts' isn't a valid directive for cloud-init, so I assume it just ignores it
<dgarstang1> and I'm pretty sure I can't put the scripts in one .d file, and the runcmd in another as yaml anchors in python aren't supported across multiple documents
<smoser> ah. 
<smoser> yeah, thats probalyb correct
<dgarstang1> oki.
<dgarstang1> should work if both are in the same file tho? still assuming cloud-init just ignores 'scripts:'... it always did in previous versions. :)
<smoser> right. it does just ignore that.
<dgarstang1> it's a lot easier to write it that way than eg: - [ ls, -l, / ]
<smoser> yep.
<smoser> dgarstang1, 
<smoser> http://paste.ubuntu.com/6839095/
<smoser> that is my default user-data
<dgarstang1> most of that's gonna go in chef land. :)
<smoser> yeah, which is perfectly good.
<dgarstang1> :)
<smoser> i was just pointing at it as an example of the anchor use
<dgarstang1> but I assume 'sm_misc:' is the same dealio as 'scripts:' ?
<smoser> yeah.
<smoser> name it __anchorforyaml if you want
<dgarstang1> kk
<dgarstang1> ugh. not having much luck with scripts. i can't even tell if it's running. how can I tell?
<smoser> dgarstang1, version ?
<smoser> the yaml thing shoudl work. 
<smoser> it populates /var/lib/cloud/instance/scripts/
<smoser> in the 'config' run i think.
<smoser> and then runs them in the final
<dgarstang1> smoser: I think the issue is that when a script fails to run, there's totally no idea why, and no output from the script
<smoser> dgarstang1, it goes to /dev/console on ubuntu
<smoser> but you can (and probalby should) change the output of cloud-init via 'output:' config
<smoser> to go to /var/log/cloud-init-output.log as in my paste above
<smoser> so that scripts run by it will have stdout and stderr tee'd to that file.
<dgarstang1> smoser: kk. That'd be useful, thanks
<smoser> (that is now the default behavior in 0.7.5)
<dgarstang1> never quite got that to work before. I'll try again
<dgarstang1> wouldn't output have to go EARLY in the config?
<smoser> well, not really.
<smoser> it reads all config and then acts on it.
<dgarstang1> oki
<dgarstang1> tanx
<smoser> there are some things that are tricky to get into the config via user-data. (ie, they kind of have to be there alredy)
<smoser> such as datasource settings (like what url to look at, or what datasources to search for)
<smoser> those are just kinda hard to pass in via a datasource :)
<harlowja> smoser back to why need config-drive question
<harlowja> http://bazaar.launchpad.net/~harlowja/cloud-init/ds-openstack/view/head:/cloudinit/sources/helpers/openstack.py#L302
<harlowja> basically that code there just switches loading based on finding config drive or reading from metadata
<harlowja> so this new DSOpenstack can search for config drive in local mode
<harlowja> and also search for metadata service in net mode
<harlowja> so thats part of why we could just remove DSConfigDrive
<harlowja> since really they are the same data :-P
<smoser> just pushed to trunk vendor-data support into nocloud
<smoser> ah. yeah, i see.
<smoser> i didnt understand your question before.
<harlowja> np
<smoser> it'd be nice to somehow support the explicitly configured DataSourceConfigDrive
<harlowja> dont run DSOpenstack in net mode :-/
<smoser> right. but i'm saying upgrade.
<smoser> or old configs
<harlowja> ah
<harlowja> sure
<harlowja> there aren't to many unique configs that are special, so it should be possible
<smoser> harlowja, mainly i was ust saying the list of datasources to search into
<smoser> someone would have had 'ConfigDrive'
<smoser> and your patch woudl then no longer work.
<harlowja> right
<harlowja> np to solve that
#cloud-init 2014-01-31
<zenloop> Does anyone here have experience building amis from scratch?
<yacoco> I'm trying to write custom handler for cloud-init, in order to boot images on my machine without using EC2
<yacoco> This is the best article I got my hands on: http://foss-boss.blogspot.com/2011/01/advanced-cloud-init-custom-handlers.html
<yacoco> but the script listed there is no more available in the repo
<yacoco> Is there a new/better way to achieve that and most importantly is it documented somewhere?
<yacoco> anyone?
<zenloop> Hey guys, can anyone tell me how cloud-init works with the init system?  When I install it I do not see cloud-init in /etc/init.d.
<harlowja> zenloop depending on the system u are using (upstart, sysvinit, systemd) u'll need to take the corresponding scripts
<harlowja> zenloop since u mentioned upstart, http://bazaar.launchpad.net/~cloud-init-dev/cloud-init/trunk/files/head:/upstart/
<harlowja> the others are in http://bazaar.launchpad.net/~cloud-init-dev/cloud-init/trunk/files (systemd, sysviinit)
<harmw> harlowja: any news from your Y! colleague on putting cloud-init in fbsd ports?
<harlowja> harmw talked with him a little this week, still getting sucked into mail stuff apparently, so hasn't had the time yet
<harmw> yea, read something regarding hackers
<harmw> but fair enough :)
<harlowja> harmw ssl i think
<harlowja> not sure what the current stuff/issues are though
<harmw> bah, ssl
<harmw> what on earth is wrong with plaintext
<harlowja> nsa
<harlowja> lol
<harlowja> nuff said
<harlowja> ha
<harmw> it's not that UPS encrypts my packages before sending them
<harmw> :p
<harlowja> i'll ping him on monday to see where's he's at, seems away on IM right now
<harlowja> maybe he'll be freed up
<harmw> yea sure, np
<dgarstang1> Question... stuff in /var/lib/cloud/seed/nocloud-net/meta-data .... how does cloud init scripts access it?
<harlowja> dgarstang1 what do u mean?
<harlowja> which type of init scripts
<dgarstang1> harlowja: If I have foo: bar in /var/lib/cloud/seed/nocloud-net/meta-data, how do I get that in a cloud-init script?
<harlowja> is it a bash script?
<dgarstang1> harlowja: no, in cloud init
<harlowja> just read it i guess?
<harlowja> where in cloud-init i guess is the question
<dgarstang1> in runcmd or bootcm
<dgarstang1> bootcmd
<dgarstang1> i'm guessing I cant
<dgarstang1> so, I fail to see the point of it to cloudinit
<harlowja> those just run shell scripts, so just read it in, cat '/var/lib/cloud/seed/nocloud-net/meta-data'
<dgarstang1> i was hoping it was a little more magic than that
<harlowja> bootcmd and runcmd just run basic scripts
<dgarstang1> harlowja: yah so I wanted to use the value in meta-data to set the host name
<harlowja> a cloud-init script should already be doing that
<harlowja> *cloud-init plugin
<dgarstang1> harlowja: not on google compute it's not
<harlowja> ah, k, idk what they did to there metadata then
<dgarstang1> dont think that ever worked for us in ec2 either
<dgarstang1> didn't know that even existed. docs are bad
<harlowja> http://bazaar.launchpad.net/~cloud-init-dev/cloud-init/trunk/view/head:/cloudinit/config/cc_set_hostname.py 
<dgarstang1> harlowja: in any case, doesn't work in gce, so can't use
<harlowja> hmmm, u are building images though right + your own cloud-init, so why can't a new script then be made that does work?
<harlowja> just patch cc_set_hostname.py if u really want i guess
<dgarstang1> i had it in a cloud init script but supposedly that wasn't the best way, it was suggested I should be depositing it in /var/lib/cloud.
<dgarstang1> harlowja: there is no data source for gce
<harlowja> k, hmmm, odd
<dgarstang1> and then reading it from the meta data file. But, if I do that I have to read it again anyway, so it's pointless
<dgarstang1> so, I might as well just keep as it is, ie put a curl in the cloud init script to read it from the gce metadata server
<harlowja> ah, so gce does have a metadata server
<dgarstang1> yep
<harlowja> seems like then it could have a datasource
<harlowja> wanna make one ;)
<dgarstang1> http://cloudinit.readthedocs.org/en/latest/topics/datasources.html .... nope
<dgarstang1> nah not me
<harlowja> durn
<dgarstang1> theres a patch kicking around somewhere to add it, but it won't work with the current version of cloud init, and the newer version of cloud init that has it won't install on ubuntu precise
<harlowja> hmmm, ya, then i guess it will have to be sorta hacky like this without that
<harlowja> tell GCE people to submit the patch in cloud-init, lo
<harlowja> damn google folks
 * harlowja works at yahoo, lol
<dgarstang1> harlowja: it is in cloud-init, latest version, which has dependancies on packages that aren't available in 12.04 ubuntu
<harlowja> interersting, there is GCE datasource in cloud-init?
<dgarstang1> harlowja: latest version, yes... it's in debian experimental
<harlowja> interesting, wonder where it is, don't see it @ http://bazaar.launchpad.net/~cloud-init-dev/cloud-init/trunk/files/head:/cloudinit/sources/
<harlowja> weird, http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=725384
<harlowja> 'We're currently discussing how this code might be submitted upstream, the
<harlowja> discussions might take a while.'
<harlowja> smoser have u seen that :-/ odd
<dgarstang1> harlowja: I saw something where someone said it had been added to debian experimental
<harlowja> ya
<harlowja> wonder where it went after that
<harlowja> dgarstang1 another way around it, since u are building your own images, is to just update the missing 12.04 dependency
 * harlowja not sure which dependency it is though
<dgarstang1> harlowja: except I could not get the cloud init from experimental to install on 12,04
<harlowja> how about from source?
<dgarstang1> oh, i forget the details... i do remember it was nasty tho
<harlowja> python setup.py install?
<dgarstang1> harlowja: the package from debian experimental, had some dependancies on packages available in raring or something
<dgarstang1> yuck
<harlowja> if u are already building your own images, hopefully not so yucky, not ideal i agree
<dgarstang1> wouldn't have to if google provided ubuntu images. grrr.... or canonical maybe
<harlowja> if u know what the dependency was it might actually be invalid (if its not a datasource u are going to use)
<dgarstang1> mebbe
<harlowja> there are certain dependencies that are datasource specific (like pyserial)
<harlowja> but uaren't using that anyway
<dgarstang1> for now, no data source seems to work ok. 
<harlowja> the distros of course though have to include them all, since they don't know who will use it
<harlowja> k
#cloud-init 2014-02-01
<dgarstang1> hey how does that hostname thing work?
<harlowja> so usually datasources provide metadata and read it in
<harlowja> and all these modules get activated, they get passed the data from config and metadata and all that
<harlowja> and then they just use it to do whatever the module wants to do
<harlowja> in this case it calls into a distro specific object (since setting the hostname is distro dependent) and sets it
<dgarstang1> harlowja: so.... it doesn't actually set the hostname?
<harlowja> the module has access to this distrobution specific object, it asks that object to set the hostname
<dgarstang1> cuz... the hostname format is a highly specific thing isn't it? 
<harlowja> not the hostname format
<harlowja> the way to set it seems to be
<harlowja> different in freebsd, ubuntu, rhel
<harlowja> rhel has a /etc/syconfig file
<harlowja> ubuntu has a different one
<dgarstang1> lemme try a different angle... where does it get the source of the hostname?
<harlowja> from the datasource
<harlowja> http://bazaar.launchpad.net/~cloud-init-dev/cloud-init/trunk/view/head:/cloudinit/sources/__init__.py#L164
<harlowja> the datasource gets it from some location
<harlowja> *datasource specific
<harlowja> which u would think in the GCE datasource would be there metadata server
<dgarstang1> yes, but where in the data source? what key?
<harlowja> see above function
<harlowja> basically datasources when they fetch there data populate self.metadata
<dgarstang1> 'local-hostname' ?
<dgarstang1> is this stuff documented somewhere?
<dgarstang1> how would I have known it's local-hostname and not hostname?
<dgarstang1> man I am confused
<dgarstang1> http://cloudinit.readthedocs.org/en/latest/topics/modules.html .... nothing. No modules.
<dgarstang1> for that matter, if GCE is in the latest version of cloudinit, where is it documented? There's no mention of it at http://cloudinit.readthedocs.org/en/latest/topics/datasources.html
<harlowja> dgarstang1 its not in any cloud-init i know about, seems to have been a debian specific patch
<harlowja> so its not in the upstream cloud-init, so wouldn't be on cloudinit.readthedocs.org
<dgarstang1> harlowja: ok, how about docs on the set_hostname module?
<harlowja> probably not as good as it could be
<dgarstang1> http://cloudinit.readthedocs.org/en/latest/topics/datasources.html#ec2 ... 'Metadata is accessible via the following URL:'... how's that relevant? 
<dgarstang1> isn't cloud-init supposed to abstract that so I can't see it and don't care?
<dgarstang1> I'd really liketo know how the set_hostname module works, like what key in the metadata it reas
<harlowja> python is pretty readible, so http://bazaar.launchpad.net/~cloud-init-dev/cloud-init/trunk/view/head:/cloudinit/sources/__init__.py#L164 sorta describes the whole process
<dgarstang1> ah the old read the code reply. :)
<dgarstang1> code always lacks context
<dgarstang1> like, if I am reading the code for cloudinit __init__, why does it have a get_hostname function there? wouldn't that be in the get_hostname module? Doesn't that mean it's in a different python file somewhere else?
<harlowja> dgarstang1 not really, there is a baseclass for datasources in __init__
<dgarstang1> so maybe I need to read this source file, but ... wait... there's a module called update_hostname, which isn't here
<harlowja> the function is in this baseclass
<harlowja> right, modules != datasources
<dgarstang1> harlowja: so where's the code for set_hostname?
<harlowja> it isn't in 1 place, it begins its life in the update_hostname module
<dgarstang1> in that case, docs would be nice. :)
<harlowja> sure, i'd much appreciate them also, but not enough time in the day :)
<dgarstang1> or, we'll just keep doing what we are doing and hacking it, not fully using the features of cloud init, and reading the hostname from the metadata ourselves and setting it in a runcmd section
<harlowja> sure, or feel free to keep on asking questions and we can provide answers, and presto a doc that u can then submit ;)
<dgarstang1> harlowja: well, I dunno
<harlowja> i understand how this is not ideal, but it is what it is
<dgarstang1> I'd ask what metadata the hostname module uses, but I don't even know if that's specific to the data source, or a common attribute for all
<harlowja> prior to before i created http://cloudinit.readthedocs.org  it wasn't any better, but a collection of small improvements in the end makes it better for everyone :)
<harlowja> dgarstang1 its specific to a datasource
<harlowja> since different datasource retrieve it differently
<dgarstang1> ok
<harlowja> so this then involves the question of what is the GCE thing doing (which i haven't seen the code for, since it never seems to have appeared upstream?)
<dgarstang1> So, ec2 ds doesn't even have a set_hostname http://bazaar.launchpad.net/~cloud-init-dev/cloud-init/trunk/view/head:/cloudinit/sources/DataSourceEc2.py
<harlowja> dgarstang1 right, thats what inheritence is for
<dgarstang1> in fact, it's got almost nothing
<harlowja> base class usually provide most of the functionality
<dgarstang1> ic
<harlowja> most datasources just provide def get_data(self):
<harlowja> which is there special way of reading 
<harlowja> *which is the thing that varies
<dgarstang1> Ok, so there's no set_hostname in DataSource either... http://bazaar.launchpad.net/~cloud-init-dev/cloud-init/trunk/view/head:/cloudinit/sources/__init__.py
<harlowja> ah, my fault, thought u mean get_hostname
<harlowja> right, so datasources provide the data that other parts of cloud-init use
<harlowja> so it wouldn't make sense for a datasource to set anything
<dgarstang1> well, the default cloud_init_modules has set_hostname, amongst oters
<harlowja> yes, modules (one of those is set_hostname) != datasourcs
<dgarstang1> it doesnt make sense for a data source to set anything? who does?
<dgarstang1> the set_hostname module? where's the code for that?
<harlowja> http://bazaar.launchpad.net/~cloud-init-dev/cloud-init/trunk/view/head:/cloudinit/config/cc_set_hostname.py
<dgarstang1> well that doesn't tell me what metadata it wants to use.
<dgarstang1> ugh
<harlowja> util.get_hostname_fqdn 
<dgarstang1> still not seeing it, sorry
<harlowja> which itself will eventually call into the datasource get_hostname
<harlowja> so set_hostname calls first util.get_hostname_fqdn which eventually calls into datasource get_hostname (the base class)
<harlowja> so that tells u where it comes from
<harlowja> the base class then looks in a few places
<harlowja> http://bazaar.launchpad.net/~cloud-init-dev/cloud-init/trunk/view/head:/cloudinit/sources/__init__.py#L164
<harlowja> lhost = self.metadata['local-hostname']
<harlowja> line 186
<harlowja> then that module asks the distrobution specific object to set the hostname to this value
<harlowja> which will then do whatever distribution specific thing to set the hostname
<harlowja>  self.metadata is populated by however the datasource fetches its data (which in your case would be whatever the gce datasource is doing)
<dgarstang1> kk, thanks
<harlowja> np
<harlowja> so in the end it becomes a question what is the GCE datasource doing :)
<harlowja> and since i'm not sure where that code is, hard to know :-P
#cloud-init 2014-02-02
<Cyis> anyone using bootcmd options on Ubuntu 12.04 LTS? 
<Cyis> I've been using cloud-init on 12.04 LTS for several years now but trying to add a bootcmd to retrieve a script and then execute it once per instance but it seems to be blowing up and everything else is executing fine for me
<Cyis> https://gist.github.com/jbouse/674e129ffb3c2cc87279 is my latest attempt if anyone has any insite
<Cyis> hmm... think I might have it
#cloud-init 2015-01-26
<barry> smoser, harlowja https://code.launchpad.net/~barry/cloud-init/py2-3/+merge/247239/comments/612536
<barry> smoser, harlowja we have py3 support
<harlowja> woot
<harlowja> time to party like its 1999
<harlowja> h
<harlowja> *ha
 * barry fires up the prince
<smoser> barry, awesome. theres a couple other mps that i have to pull in
<smoser> but we'll hope for a vivid uploda tommorrow 
<smoser> and thakn you
<barry> smoser: oh yeah, i shoudl probably do a merge from trunk too
<smoser> please. :)
<harmw> new version out soon smoser ?
<smoser> harmw, maybe.
<smoser> you're wanting one for freebsd ?
<harmw> yup
<harmw> since then I'm able to push out a new port
<harmw> with the latest fixe
<smoser> k
<barry> man, the patchOS stuff really wreaks havoc with things
<harlowja> lol
 * harlowja i take the blame :-P
<barry> ;)  maybe i fixed it tho
<barry> you'll have to get out of the habit of using self.makeDir() :)
<barry> smoser, harlowja trunk merged
<harlowja> cool
<barry> i'll work on py26 now, but i'm ascairt
<harlowja> thx barry :)
<harlowja> py26 sorta important for some of us (for a litt;e while longer)
#cloud-init 2015-01-27
<barry> harlowja: when's the last time the test suite was actually run on py26? ;)
<harlowja> hmmm, whenever i ran it, lol
<barry> yeah, i think you'd be surprised.  but hey, i think i can get it working for you
<harlowja> if u want me to; thats fine also
<barry> (essentially, lots are not py26 compatible right now)
<barry> harlowja: let me see how far i can get
<harlowja> k
<harlowja> hmmm, lots not?
<harlowja> intersting
<barry> e.g. '...{}...'.format(blah)
<harlowja> ah, ya
<harlowja> don't use that, ha
<barry> right.  it's all over the place.  easy fix
<harlowja> kk
<barry> probably just harder getting a working 2.6 env ;)
<harlowja> :
<harlowja> :)
<harlowja> compile 2.6 shove it somewhere?
<harlowja> make alt-install i think usually works
<harlowja> or is it altinstall, can't remember
<harlowja> thats what i'd do
<barry> yep, but then i had to create a 2.7 virtualenv, install the upstream virtualenv in that, and then create *another* virtualenv w/2.6.  ubuntu's virtualenv doesn't work with 2.6 even altinstalled
<barry> which i suppose isn't surprising given how long ago ubuntu even supported 2.6
<harlowja> ya; probably i'd then tell the made python2.6 to execute https://bootstrap.pypa.io/get-pip.py and then get 2.6 virtualenv and then go from there
<harlowja> but whatever works for u
<barry> yep
<smoser> hm.. wrt 2.6, barry i saw (and it "seemed to work") http://askubuntu.com/questions/125342/how-can-i-install-python-2-6-on-12-04
<smoser> the 'deadsnakes' ppa has 2.3 -> 3.4 
<m01> m01
<m01> oops
<barry> smoser: i guess harlowja isn't online atm.  my porting branch is done.  let me know if there's anything else you need from me.  i'd love to get it landed!
<smoser> barry, di you port oauth ?
<smoser> and THANK YOU!.
<barry> smoser: i did indeed :)
<smoser> rock.star.
<barry> :)
<harlowja> barry added some review comments on that big-one
<barry> harlowja: looking
<harlowja> alright, bb, heading over to vmware for nova-mid-cycle meetup stuffs
<harlowja> ok backs
<harlowja> barry thx; looks pretty good to me
<barry> harlowja: \o/
<harlowja> lets see if anyone else wants to look it over :-P
<barry> maybe smoser?
<harlowja> ya, likely, ha
#cloud-init 2015-01-28
<smoser> barry, i'll take a look, yeah.
<smoser> the one uqestion i have is the packaging really. 
<smoser> my feeling at this point is kind of "throw it in vivid" after minor test.
<barry> smoser: agreed.  switch the cli over to py3 and you should be good.  let me know if you want help withthat
<smoser> claudiupopa, reading your pull request
<smoser> https://github.com/cloud-init/cloud-init/pull/1/files
<smoser> Odd_Bloke, thank you for your review!
#cloud-init 2015-01-30
<jlkinsel> hey guys - trying to bring up a ubuntu 14.04 ec instance...I'm putting "repo_upgrade: all" as part of my cloud-config userdata, but looks like apt-get upgrade isn't running...any thoughts as to what I'm missing?
<jlkinsel> I can see repo_update running, and then puppet getting installed, but no upgrade
<smoser> jlkinsel, package_update: and package_upgrade ?
<smoser> not 'repo_update'
<jlkinsel> OH. Must have been looking at something out-of-date...
<jlkinsel> that did it. Thanks!
#cloud-init 2016-02-01
<drosenbloom> How do you manually trigger cloud-init to run again without a reboot?
<kse> drosenbloom: How about `rm -rf /var/lib/cloud && for stage in init-local init config final ; do service cloud-${stage} start; done`
<drosenbloom> kse: I actually want to modify the userdata and have it re-run that userdata. Is that possible?
<drosenbloom> kse: I.E. I want to have the first cloud-init download a new #cloud-config file and process that as a second cloud-init.
<kse> drosenbloom: i think that due to the cloud platform
<drosenbloom> anyone know what this error means? cloud-init[2207]: util.py[WARNING]: Failed to shellify [... scrubbed...] into file /var/lib/cloud/instances/i-225e39f8/scripts/runcmd
<drosenbloom> I'm wondering if it has to do with one of the lines of my CF containing sed 's/"//g'
<drosenbloom> erm...  userdata, not cf
<smoser> drosenbloom, hm..
<smoser> i've not seen it.
<smoser> for sure its not impossible, but i've put just about everything into runcmds.
#cloud-init 2016-02-02
<mallu0987> hello.. anyone here?
<mallu0987> nobody?!!
<mallu0987> anyone here?
<kse> hello there mallu0987
<mallu0987> kse: I'm trying to grow root partition. I added growpart:
<mallu0987>   mode: auto
<mallu0987>   devices: ['/']
<mallu0987>   ignore_growroot_disabled: false
<mallu0987>   resize_rootfs: True
<mallu0987> in cloud.cfg
<mallu0987> restarted the instance then took an AMI
<mallu0987> any instance that is created via the AMI is not getting resized
<mallu0987> but it will resize after I reboot the instance
<kse> mallu0987 : Is there `/etc/growroot-disabled"` ?
<mallu0987> anyone here?
<minfrin> Hi all. Is there a mechanism by which cloud-init can patch itself early on during the boot process?
<minfrin> The problem I am trying to solve is that https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1523921 remains broken on Ubuntu 14.04, and I am trying to work around it somehow.
#cloud-init 2016-02-03
<smoser> Odd_Blok1, is that you ?
#cloud-init 2016-02-04
<harlowja> smoser if u get some time, can u jump on #openstack-infra so u can ack the resync with git :)
<harlowja> then git forever
<harlowja> lol
<smoser> harlowja, shoot.
<smoser> i'm actually in need of taking someting to trunk. https://code.launchpad.net/~rcj/cloud-init/lp1540965/+merge/285097
<smoser> it sucks so much... i really owe you this.
<harlowja> k
<harlowja> merge it then resync my git
<harlowja> and then we ask :-P
<harlowja> in tandium
<harlowja> lol
<harlowja> *tandem
<smoser> harlowja, refresh my memory
<smoser> lets say i wanted to go ahead and ACK this
<smoser> but then i want another commit in bzr..
<smoser> i can just take it, and then also commit it to git
<smoser> right ?
<smoser> and also ... i think i'll end up with git master hosted on launchpad.
<smoser> harlowja, ^
<harlowja> smoser u can do that, if u can get the openstack-infra on 0.7.x to work
<harlowja> its still got issues
<harlowja> and i was gonna wait till we sync-for-last-time to fix them
<harlowja> lol
<harlowja> smoser u can run https://gist.github.com/harlowja/e62c4d69bcd5d2a0d4bd on the bzr stuff
<harlowja> and put that up on github
<harlowja> and then ask infra to sync
<harlowja> thats all i was gonna do
<harlowja> *sync from your github repo u (or i) publish
#cloud-init 2016-02-06
<openstackgerrit> Merged openstack/cloud-init: Put py34 first in the env order of tox  https://review.openstack.org/266753
#cloud-init 2017-01-31
<smoser> harlowja, around ?
<harlowja> yo
<smoser> i've something like this
<smoser> http://paste.ubuntu.com/23896896/
<smoser> which is clearly lame compared to what harlowja would come up with
<smoser> but i want to be able to get the values() of this "enum" like thing
<harlowja> just use the enum module?
<smoser> that would be the easiest thing.. but if i can avoid the depends... and still work python2.6 i'd like to
<harlowja> hmmm
<harlowja> then i guess yours is sorta sneaky for that
<harlowja> seems ok, due to 2.6 and desires to minimize depends
<smoser> well, the pain was that i wanted to then check if a user provided string was a valed entry
<smoser> basicaly, if it were a dict, i wanted to:
<smoser>  if foo in thatthing.keys()
<harlowja> not work?
<smoser> well, no. because keys() isn't hooked up to anyting
<harlowja> ah, right
<harlowja> one sec
<smoser> harlowja, just when you thought i could not get any more ghetto
<smoser> http://paste.ubuntu.com/23897038/
<harlowja> ya, closer to where i was going to go, ha
<harlowja> http://paste.openstack.org/show/596960/ smoser
<harlowja> is what i got
<harlowja> may be good enough for u, may not be, ha
<harlowja> not sure why __contains__ wouldn't work (but it didn't, ha)
<smoser> yeah, thanks.
 * smoser turns to pumpkin
<smoser> later
<smoser> thank you!
<harlowja> peace
<burgerk> Hi, question ...  using cloud-init in Ubuntu 16.10, is it a requirement now that the datasource with network be available at all times and not just at first boot for network setup ?   It appears that if I remove the datasource and reboot the VM, I lose static network settings
<rharper> burgerk: I think you may need to use the manual_cache_clean: True setting to indicate that you want to re-use the existing instance data;  can you clarify what you mean by losing static network settings?  was that part of your user-data?
<rharper> https://bugs.launchpad.net/cloud-init/+bug/1596013  has more details
<burgerk> if I remove the datasource and then reboot the VM, the static IP of the VM is no longer set
<burgerk> information that would typically go in the interfaces file that now goes in /etc/network/interfaces.d/50-cloud-init.cfg
<burgerk> rharper: being able to snapshot the instance is important, so I don't want to have to manually clean the cache
<rharper> burgerk: does the bug above capture your issue (other than not wanting to use manual-cache-clean)?  50-cloud-init.cfg is auto-generated, so I'm unsure of how you're getting static network configuration into it without using cloud-init network: config  ?
<rharper> smoser: which reminds me, I think we need to import some network config documentation from curtin; I'm not seeing it in the cloud-init RTD
<burgerk> rharper: yes that does appear to be the same issue.  Here is my scenario, on initial boot, datasource exists ( ConfigDrive ) and set the static network information as expected for first boot.   At some later point, the config drive is removed and the VM is rebooted.  When the VM reboots that network information from the first boot is now gone and it attempts to connect as DHCP
<burgerk> cloud-init-0.7.8-1-g3705bb5
<smoser> rharper, yes, we probably should pull it over.
<smoser> burgerk, what is the datasource you're using ?
<burgerk> ConfigDrive
<smoser> on openstack ?
<burgerk> yes
<smoser> you should not depend on the metadata service on subsequent boots there.
<smoser> wait... maybe...
<smoser> let me see.
<smoser> you should be ok... if your system's uuid (in dmi data) matches your instance id
<smoser> as it does on openstack provided vms
<rharper> smoser: IIUC, the use-case is to snapshot that and move to new instance
<smoser> https://git.launchpad.net/cloud-init/tree/cloudinit/sources/DataSourceConfigDrive.py#n137
<smoser> well, then its a new instance!
<smoser> and it should go get new network data
<smoser> other wise you'd alway have the same static ip address everywhere.
<burgerk> things work fine on first boot, network info is rewritten.
<burgerk> the problem is if config drive is removed and there is no datasource.  The network config file is cleared and the information to repopulate is gone
<burgerk> I did not expect interfaces.d/50-cloud-init.cfg to be cleared on every reboot
<burgerk> smoser, is that the expected behavior?  to rewrite networking on every boot, not just first boot now? ( previously using cloud-init 0.7.7 )
<smoser> it should rename devices, but should not re-render that file
<smoser> https://git.launchpad.net/cloud-init/tree/cloudinit/stages.py#n621
<smoser> you should take that "not a new instance. network config is not applied"
<smoser> burgerk, can you do me a favor
<smoser> a.) boot an instance with disk attached
<smoser>   mkdir orig-boot; mv /var/log/cloud-init* orig-boot/ ; cp /run/cloud-init -a orig-boot/
<smoser> b.) detach disk, reboot
<smoser> c.) re-do copy logs like in 'a' but to second-boot
<burgerk> ok
<smoser> burgerk, this is actually  openstack ?
<smoser> or your local usage of config drive
<burgerk> straight openstack
<smoser> rharper, https://code.launchpad.net/~smoser/cloud-init/+git/cloud-init/+merge/316033
<rharper> smoser: lol @ Genuine
<smoser> and https://code.launchpad.net/~smoser/cloud-init/+git/cloud-init/+merge/315832
<burgerk> smoser, I collected the logs you requested, but in the process, I think I may have found what is causing this issue.
<burgerk> https://git.launchpad.net/cloud-init/tree/cloudinit/stages.py#n243
<burgerk> wouldn't deleting that file make it appear to be first boot again after the reboot?
#cloud-init 2017-02-01
<smoser> burgerk, it tries loading it from cache before that
<smoser> rharper, struggling with http://paste.ubuntu.com/23906228/
<rharper> smoser: looking
<rharper> smoser: we've discussed that ds-identify may need to parse the on-disk cloud-config;  that would certainly handle the config in one-place issue;  it could be triggered only in the maybe paths (only check config if we're not sure); we may need a different not_found_behavior (disabled would be fully disabled and require detect to not result with any maybe answers?)
<smoser> right now we dont really pay attention to ds_maybe
<smoser> rharper, the issue really is just that right now the only way to read the cloud-inti configuration is with python-yaml.
<smoser> and wanting to avoid that dearly
<rharper> right, the python part
<rharper> is grepping for a setting a reasonable replacement for extracting a single setting?
<rharper> for example, we could check if we have a not_found_behavior: <string> in /etc/cloud/*  recursively
<smoser> https://git.launchpad.net/~smoser/cloud-init/tree/tools/ds-identify?h=feature/ds-identify
<smoser> see check_config
<smoser> and its usage in dscheck_maas
<rharper> yeah
<rharper> that's roughly it
<rharper> with that in place, on maybe, check if there's an overriding setting on what to for not_found_behaviors;  on EC2 lookalike, it hits maybe , reads in-image config for not_found_behavior:  and uses that if found, else uses the default (which is disabled).
<rharper> possibly need to handle the in-image setting vs. the user-data setting (ie, user-data should take precedence over in-image data IIUC)
#cloud-init 2017-02-02
<bob_cheesey> morning all - I've been having some issues setting the hostname on debian jessie using 0.7.6 (and 0.7.7) - is there somewhere I can raise issues like this? I'm not sure whether it's a bug or my implementation
<bob_cheesey> well clearly this isn't the place to ask!
<rharper> bob_cheesey: it's mostly quiet here except during US Central hours;  ask away and we usually get back to you if your still in-channel ;  you can report bugs here: https://bugs.launchpad.net/cloud-init
 * rharper has to take kiddos to school, bbiab 
<bob_cheesey> rharper: ah thanks, that's useful to know!
<bob_cheesey> i'll try again later
<smoser> rharper, http://paste.ubuntu.com/23911739/
<magicalChicken> bob_cheesey: are you getting a timeout from hostnamectl in cc_set_hostname?
<magicalChicken> I've had similar issues on centos but haven't had time to debug
<burgerk> smoser, sorry I was out of the office yesterday...  to followup on the issue I was having with rebooting without the ConfigDrive attached.   I captured the logs you requested.   I believe this is likely the section of logs of interest.  http://paste.ubuntu.com/23912850/
<burgerk> I can attach a tar of all the logs, just tell me where
<smoser> burgerk, yeah... where is this running ?
<smoser> what os are you on ?
<smoser> and what openstack ?
<smoser> xen, isnt it.
<burgerk> Ubuntu 16.04.1
<burgerk> or host hardware ?
<smoser> your guest is 16.04
<burgerk> yes
<smoser> do you  know what openstack version is under you ?
<burgerk> Newton ... or do you want a specific driver #
<smoser> burgerk, is it xen ?
<burgerk> ppc64le
<smoser> rharper, ^
<smoser> wow.
<rharper> \o/
<smoser> this very thing rharper and i were wondering about
<smoser> :)
<rharper> virsh dumpxml need
<smoser> burgerk, can you do that ^ ? can you get at the host at all ?
<rharper> smoser: IIRC ppc64le has a uuid out in the device tree sys path
<smoser> so in your guest, can you do this, burgerk
<smoser>  sudo grep . -r /sys/firmware/devicetree/ | grep -v Binary
<smoser>  sudo grep . -r /sys/firmware/devicetree/ | grep -v Binary | pastebinit
<rharper>  /sys/firmware/devicetree/base/vm,uuid
<rharper>  but yeah, a full collection will be super useful
<smoser> that is crazy helpful, burgerk
<burgerk> http://paste.ubuntu.com/23912946/
<smoser> booo
<burgerk> not much there
<smoser> can just
<smoser>  cat /sys/firmware/devicetree/base/vm,uuid
<smoser> shows no file ?
<smoser> (ie,m wondered if grep -r didn't follow a symlink maybe)
<burgerk> yes
<burgerk> no such file
<burgerk> contents of /sys/firmware/devicetree/base  http://paste.ubuntu.com/23912964/
<smoser>  ibm,partition-uuid ?
<smoser> and artition-name
<smoser> anything in those ?
<smoser> is this kvm ?
<smoser> or is it powervm
<smoser> oh. wait. i dont knwo if there is ppc64el powervm
<smoser> and system-id
<smoser> theres just binary stuff in there ?
<burgerk> powervm
<burgerk> ibm,partition-uuid 7ab415a2-30e7-482f-8806-e9ec4197b7ba
<smoser> that by chance match the uuid ?
<smoser> from the openstack c onfig drive?
<burgerk> instance -> /var/lib/cloud/instances/fab415a2-30e7-482f-8806-e9ec4197b7ba
<burgerk> same except 1st character
<rharper> eww
<burgerk> I don't have config drive anymore, removed to repeat test
<rharper> that looks bugy
<smoser> wow
<smoser> that would be a massive coincidence
<smoser> :)
<rharper> https://review.openstack.org/#/c/200879/
<rharper> but doesn't show where it would appear
<smoser> burgerk, so why didnt our 'grep ." above show us that file ?
<burgerk> powervm
<burgerk> sorry bad paste
<rharper> https://github.com/openstack/nova-powervm/blob/master/nova_powervm/virt/powervm/vm.py#L310
<burgerk> so that covert method is changing the system UUID byte 0, bit 0 to 0
<rharper> eww
<rharper> certainly then the OpenStack instance UUID ought to match the UUID inside the vm
<rharper> even if they need to drop a bit to avoid collisions (or for whatever reason)
<rharper> nova list $UUID should match inside the instance ; I would think
<burgerk> I believe the converted UUID is being sent as system UUID when the VM is created and the config drive contains the original openstack UUID
<rharper> but your instance symlink says otherwise
<rharper> vs. the device-tree value which is created by the hypervisor
<burgerk> instance symlink matches config drive value
<rharper> but not the vm id
<rharper> which is what the hypervisor got
<rharper>  ibm,partition-uuid ;  maybe that's by design
<burgerk> yes I believe it is some sort of requirement that the system UUID bit 0 be 0
<rharper> what we were hoping for was something that indicated this was an openstack instance;  on KVM and Xen, for example the SystemVendor is set to Openstack
<rharper> that's mostly for the network-facing metadata service; config-drives indicate their presence via filesystem attributes;  however; IIRC, your issue was that you removed the configdrive, which also set the UUID, then when cloud-init runs a second time somewhere else, its looking for a datasource, it's going to search the system for a uuid to see if that matches existing instance directories
<burgerk> yes that appears to be the issue
<rharper> that seems to have gone awry in that we're poking for DMI data (which we won't see on power); also, even if we did look at the partition,uuid, we'd need to apply a 1 to bit-0 of byte-0 to match if we're on powervm
 * rharper will bbiab, kiddo pick up time
<rharper> burgerk: in your situation, did you set manual_cache_clean: True ? ISTR something (or someone) not wanting to set that; though for configdrive it's required if you expect it to boot with the same instance data;  if you do have that set, and it's failing (due to the search for dmi data on power) then definitely file a bug, https://bugs.launchpad.net/cloud-init
<burgerk> The drawback of that was that I can't just snapshot the VM and deploy that image then, right ?
<burgerk> there would be manual steps before snapshoting?
<rharper> I think smoser pointed out that if you snapshot and boot somewhere else it _is_ a new instance; so you shouldn't deploy the snapshot without re-running cloud init
<rharper> you don't want nodes with the same ip, the same sshd host keys, etc
<burgerk> right, I want cloud-init to run again if it is a new instance, i.e. new config drive and new UUID on it
<burgerk> what I don't want is to have to manually delete something before I snapshot
<rharper> how are you deploying your snapshot? with openstack still, so nova boot points to an existing snapshot image?
<burgerk> yes, snapshot the current VM with openstack, then nova boot pointing to that snapshot
<rharper> IIUC, when you boot the snapshot again, cloud-init will run again, as it needs to since you're on a new instance;  but I'm guessing there is something that you don't want to run again as you're on this snapshot?
<burgerk> I will give that a value a try and see what happens
<smoser> rharper is right, it should all "just work"
<burgerk> smoser, after snapshot and deploy of the snapshot, it is not writing network info from the config drive on first boot using manual_cache_cleanup: True
<smoser> burgerk, i'm confused.
<smoser> why are you setting manual_cache_cleanup=True ?
<smoser> (and its manual_cache_clean (no "up").
<smoser> i thoguht your problem before was that cloud-init *was* re-writing network configuration
<rharper> smoser: my fault
<burgerk> rharper suggested using that property to fix the situation for removing the config drive
<rharper> smoser: when using a config drive, and then removing it, we have to use that , right?
<rharper> it sounds like in manual_cache_clean mode, we don't re-render network-config?  but generate fall-back config (dhcp on first interface)
<rharper> burgerk: in general the static network config is going to break if someone else also boots that static network config in the same tenant network
<smoser> manual cache clean should basically mean that cloud-init always re-uses the stale data in /var/lib/cloud/instance/
<smoser> and thus, the second time or any time after (even after snapshotting and re-deploying) it boots will think it is not first boot
<smoser> basically its *supposed* to just never go looking for a datasource again
<smoser> as long as there is one in /var/lib/cloud/instance/
<rharper> right; how does that intersect network config
<burgerk> ok, that was my understanding of the property and why I didn't want to use it ...   I need something like use datasource if it exists, otherwise stale data in /var/lib/cloud/instance/  :)
<rharper> I've not seen the config-drive, but apparently it's including some static eni configuration which gets written to /etc/network/interfaces.d/50-cloud-init.cfg
<burgerk> correct
<smoser> burgerk, well, that i think is the behavior you'd get on intel
<smoser> in a vm on openstack.
<rharper> if we set manual_cache,  it appears that we're still doing fallback networking (re-writing the 50-cloud-init.cfg file) but not with the network info which should be embedded in the instance.obj right?
<smoser> because on intel, cloud-init comes up and checks the product uuid and says "oh, its the same as the one in /ar/lib/cloud/instance. no need to look again".
<smoser> i think.
<rharper> burgerk: is it possible to share your user-data/meta-data files in your config-drive ?? (or a variant of it) ?
<smoser> it shouldnt do that
<rharper> but burgerk is not using the same instance
<rharper> snapshot to cinder, nova boot -from-snapshot
<smoser> for sure its possible it is,b ut it shoudl only render networkign on first instance boot
<rharper> it *is* a new instance
<rharper> but we're saying, use stale data (on purpose)
<burgerk> with the property set to true it is using stale data, not fallback data
<burgerk> rharper, here is network config drive files https://paste.ubuntu.com/23913828/
<rharper> burgerk: thanks, I'll recreate; I suspect you're still going to have issues with using the snapshot with stale-data; but if we say to use stale-data, then it shouldn't wipe the network config
<burgerk> correct it appears to be using stale-data on all boots ( including first boot )
<burgerk> rharper, smoser  I will also see if something can be done on the powervm side to get matching UUIDs for system UUID and ConfigDrive UUID value
<rharper> ok
<rharper> if you asking, we're very interested in getting the Openstack Nova string into the devicetree output so we can detect that we're Openstack on ppc64le platforms
<burgerk> ok
<rharper> or, somewhere else if devicetree isn't possible
#cloud-init 2017-02-03
<burgerk> rharper, smoser  I was able to get both the System UUID and UUID in ConfigDrive to match.  But I am still seeing the same behavior.
<smoser> hm..
<burgerk> hmm looks like the /var/lib/cloud/instance directory is not linked to any directory in /var/lib/cloud/instances
<smoser> ok. i'm really sorry, lots of discussion over the past few weeks or so , can you describe what you're doing and the prob lem you're seeing ?
<smoser> i just can't hold the context...
<smoser> maybe best, just open a bug
<smoser> ubuntu-bug cloud-init
<smoser> and then describe it there ?
<burgerk> removing the config drive and rebooting
<burgerk> sure, can do
<smoser> burgerk, i really appreciate your patience
<burgerk> just quick question on the /var/lib/cloud/instance link ... where does that happen?  That seems to have gotten broken in my tinkering :)
<burgerk> smoser ...  https://bugs.launchpad.net/cloud-init/+bug/1661679   Thanks for your help
<c0by> Hi, is there support for FreeBSD somewhere or do I need to write it?
<smoser> c0by, there is some freebsd support
<smoser> there is some in trunk,and someone trying to improve it for azure .
<smoser> https://code.launchpad.net/~redriver/cloud-init/+git/cloud-init/+merge/314895
<c0by> Thanks I'll take a look at it
#cloud-init 2017-02-04
<smoser> rharper, generators run multiple times in boot
<smoser> not really happy about htat.
<smoser> but, i guess for now i'll just let it be.
#cloud-init 2018-01-29
<smoser> ybaumy: i'm not sure how vcloud works, but if it didn't fit into the ovf datasource, then yes that would seem like the right path
* blackboxsw changed the topic of #cloud-init to: Reviews: http://bit.ly/ci-reviews | Meeting minutes: https://goo.gl/mrHdaj | Next status meeting: Monday 2/5 16:00 UTC | cloud-init 17.2 released (Dec 14, 2017)
<dojordan> Hey all, quick question. Any idea why the latest 18.04-DAILY-LTS Azure image is from 1/24/18?
<smoser> dojordan: dailies of stable releases build ~ twice weekly I believe. (and then, only when necessary)
<smoser> and i see updates as 2018-01-22, not 24.
<smoser> on azure.
<smoser> 20180126 is the newest cloud images has.
<smoser> so... in summary
<smoser>  * 20180126 is the newest on cloud-images.  I suspect that is just the ~ twice weekly artifact.
<smoser>  * azure has 20180122. I'm not sure why that is not at 0126
<smoser>  * i'm not sure why/where dojordan is seeing 0124
<dojordan> https://pastebin.com/TWWQ1cMc
<dojordan> 18.04.201801240
<smoser> dojordan: pastebinit (cli... uses paste.ubuntu.com or hastebin)
<dojordan> https://paste.ubuntu.com/26485306/ -thats better
<smoser> https://paste.ubuntu.com/26485311/
<smoser> dojordan:  i have no idea what 'version' is there. but our cloud-images.ubuntu.com produces the data that my paste queried
<smoser> (it is entirely possible that it is wrong)
<smoser> :-(
<dojordan> :( I'll just boot it and check the version...
<smoser> oh. heres an explanaiton though...
<smoser> you have a 0122
<smoser> so i suspect that the stream data is just out of date
<smoser> which ... sucks.
<dojordan> can you run image-status on bionic?
<dojordan> I see 1/26 daily xenial but not 1/26 daily bionic
<smoser> http://paste.ubuntu.com/26485341/
<smoser> fyi, image-status is https://github.com/smoser/talk-simplestreams
<smoser> (see bin)
<smoser> and i have to go agfk for 10 minutes or so. i've pinged internally on why out of date.
<smoser> and i'll let you know.
<dojordan> great many thanks
<smoser> dojordan: ah. sorry. i thought you were asking about xenial
<smoser> so much of my info above is wrong.
<dojordan> is the schedule different for bionic?
<smoser> dojordan: bionic (the ubuntu development release) will almost *actual* daily
<smoser> but unfortunately often times errors occur and things lag behind.
<smoser> such as there being 5 days out of date on bionic :-(
<smoser> dojordan: so ... bionic is just out of date a bit. there were some build failures. it will eventually catch up.
<smoser> xenial stream data *does* appear out of date with what is published on azure.
<smoser> powersj: https://code.launchpad.net/~smoser/cloud-init/+git/cloud-init/+merge/336722
<smoser> did you run some new lxd ?
<smoser> i suspect that woudl basically lose logs right now until liblxc3.0
<powersj> smoser: umm
<powersj> I tried it using the snap lxd on my local system, but I am not aware of any newer than 2.2x lxd
<smoser> did you get console logs ?
<powersj> I know I saw the log message, let me run again with the keep flag
<powersj> smoser: NotImplementedError:LXD Driver version not 3.x+ (2.1.1)
<powersj> as expected
<smoser> right.
#cloud-init 2018-01-31
<mcb30> Hello!  I'm trying to debug how cloud-init handles network configuration in OpenStack.
<mcb30> I see it correctly fetch the metadata from http://169.254.169.254/openstack/latest/network_data.json
<mcb30> I have traced this as far as cloudinit.sources.DataSourceOpenStack.get_data()
<mcb30> which then seems to simply throw away whatever was retrieved in results['networkdata']
<mcb30> This fits with the fact that the log file shows "Applying network configuration from fallback ..."
<mcb30> The end result is that cloud-init is totally ignoring whatever network configuration data is provided via the OpenStack metadata server
<mcb30> Does anyone have any suggestions?
<smoser> mcb30: currently cloud-init does not read network metadata from openstack datasource.
<smoser> only from config drive.
<smoser> we have a path forward to get there.
<smoser> but doesnt do it right now.
<smoser> so suggestion is "use config drive"
<smoser> which i realize is less than wonderful.
<mcb30> smoser: ok, thanks for saving me a few more hours of debugging :)
<mcb30> So, is using a config drive the only way to get IPv6-enabled instances?
<mcb30> (other than manually editing the generated ifcfg-eth0 file)
<smoser> mcb30: yes, ant the moment.
<smoser> its not a lot of work to make network metadata service work.
<smoser> but just not there now
<mcb30> smoser: can we help (either with a patch or some funding)?
<smoser> mcb30: patches are for sure welcome.
<smoser> and /me wishes he had a 'buy me a coffee or an ember coffee mug"
<mcb30> Next problem (no longer a flaw in cloud-init): the network_data.json file that OpenStack creates on the config drive is missing the IPv6 configuration anyway :(
<mcb30> The universe is determined not to let me get IPv6 working, but I shall defeat it
<blackboxsw> word on the street mcb30 is that I'll be working on the openstack network config shortly :) (like this week)
<mcb30> blackboxsw: awesome!
<dpb1> I too would now like an ember coffee mug, thx smoser
<dojordan> hey @smoser, any update on the lack of daily builds in azure? Is there someone I can follow up with about this?
<smoser> dojordan: i'll push a bit.
<smoser> dojordan: its in progress is all i can say.
<blackboxsw> mcb30: if you get a chance, it'd be helpful if you have a more complex example of network_data.json that you were concerned wasn't working...    I'm working out an approach here, but wanted to make sure I handle your use case too.
<blackboxsw> mcb30: wget http://169.254.169.254/openstack/latest/network_data.json -O - 2> /dev/null | json_pp | pastebinit    # that'd do it for me
<blackboxsw> the initial image I'm playing with has only a single nic & ip
<blackboxsw> but I'll be adding more simplistic examples of  multi-nic/ multi-ip vms
<rharper> blackboxsw: I have a large collection on network_data.json examples, many of them are already encoded in the cloud-init network unittests
<blackboxsw> oops, /me looks
<blackboxsw> rharper: yeah my initial network_data.json doesn't really surface any ip infromation beyond DNS and # of macs
<blackboxsw> http://paste.ubuntu.com/26497259/
<rharper> blackboxsw: look at say tests/unittests/test_net.py
<rharper> the OS_SAMPLES
<blackboxsw> it really looks like we might need to query using openstack or nova client libs to get the rest of the related info if presented with limited information like my openstack/network_data.json presents
<rharper> why do you think that?
<rharper> there's not a lot of config, it's links (devices), networks (ip and route), and dns
<rharper> that's all there is, the links can be physical device, or various virtual devices (bridges, bonds, etc)
<blackboxsw> my paste doesn't contain IP info https://paste.ubuntu.com/26497259/
<blackboxsw> or I'm being dense
<rharper> no, it's dhcp onlly
<rharper> look at the datasource/openstack/helpers to see how we parse that
<rharper> blackboxsw: also you can feed network_data.json into cloud-init/tools/net-convert
<blackboxsw> yeah, I guess I expected I'd see public IP associations that I made for the instance as well.
<rharper> for the openstack stuff, we're already  fully working AFAIK, what we're missing is the bring-up-an-interface-to-dhcp portion
<rharper> and then, a fetch of the network_data.json since currenlty we only invoke the helper when we find a network_data.json in the configdrive part
 * blackboxsw also wants to persist that data in instance-data.json for openstack
<rharper> right, so, when get_data() runs, it needs to also crawl the 'network_data.json' value and keep that in the instance-data.json
<rharper> +1 on the idea
<mgerdts> I just did 'make rpm; rpm -Uvh cloud-init...rpm' and rebooted.  On reboot, it really wants to get metadata from http://169.254.169.254/2009-04-04, then from another IP address (the host of my VM).  I'm having troubles finding the magic to turn that off.
<smoser> mgerdts: well, it       is looking for a datasource. do you have one ?
<smoser> are you running on a cloud ?
<mgerdts> Running on SmartOS
<mgerdts> so I'm interested in the SmartOS data source, but not the others
<smoser> you can configure it tonlyi search the smartos datasource.
<mgerdts> In /etc/cloud/cloud.cfg, disable-ec2-metadata is present, the same place it is on an ubuntu 14.10 VM
<smoser> but it will only end up hitting the network when it has failed to find smartos.
<mgerdts> ok, that could explain it.  I'm getting a stack trace when it tries to get sdc:resolvers, as that's not configured in the host.
<smoser> at least normally... 169.254 is ec2,and the other is i suspect CloudStack.  both of which should run after smartos by default.
<smoser> yeah. then that is the problem. hm..
<smoser> mgerdts: can you file a bug and provide the metadata you see there ?
<mgerdts> seems as though DNS should be an optional part of network configuration - probably missing an exception handler
<mgerdts> sure, will do.
<mgerdts> FWIW, I'm happy to work on this a bit.  I'm working on bringing bhyve to smartos and investigating whether cloud-init would be the easiest way to configure networking on the various other distros.  Our ubuntu images already use it.
<blackboxsw> +1. many hands make light work
<smoser> mgerdts: yeah, it really should be pretty easy.
<mgerdts> https://bugs.launchpad.net/cloud-init/+bug/1746605
<ubot5> Ubuntu bug 1746605 in cloud-init "stack trace when sdc:* not defined" [Undecided,New]
<mgerdts> Thanks for the help smoser.  Will work up a fix and be back later.
<blackboxsw> rharper: thx for the test tips for OS references. otherwise I would've spent all day trying to setup and reproduce different configs
<blackboxsw> ok things looking reasonable to set this up and move the OpenStackdatasource to Local stage.
#cloud-init 2018-02-01
<mcb30> blackboxsw: https://slexy.org/view/s21hGF2TPF - it's just a single NIC dual-stack setup with stateful DHCPv6
<kholkina> Hi all! Can someone explain why do we check it in this line and then in line 182? https://github.com/cloud-init/cloud-init/blob/master/cloudinit/ssh_util.py#L178
<kholkina> looks like in line 182 'k' should be checked
<smoser> kholkina: reading.
<smoser> kholkina: you would appear to be correct. i'd seem you could expose that pretty easily exposed in a unit test
<smoser> well, it doesnt test your issue
<smoser>  but http://paste.ubuntu.com/26500979/
<smoser> adds a test of that. and i guess to expose your bug, we just need to make the 'new_entry' invalid.
<smoser> http://paste.ubuntu.com/26500992/
<smoser> and there is a unit test showing your issue, kholkina
<blackboxsw> mcb30: thanks!
 * blackboxsw sets up vpn * vmware on my desktop
<blackboxsw> oops
<mgerdts> smoser - I think I've tracked down my problem to being a form of PEBKAC.  That being said, there's a reasonable case for protecting against this failure mode (as well as the case where the metadata server goes to lunch in middle of a request) that doesn't involve a ton of code.  I'd like to get your opinion on this.
<mgerdts> https://bugs.launchpad.net/cloud-init/+bug/1746605
<ubot5> Ubuntu bug 1746605 in cloud-init "stack trace when sdc:* not defined" [Undecided,New]
<smoser> mgerdts: login prompt
<smoser> right ?
<smoser> login is running on that console and writing as cloud-init is
<mgerdts> no, a mdata-get command running at the same time as cloud-init
<mgerdts> rm /usr/sbin/mdata-get; reboot; problem fixed!
<mgerdts> since pretty much anything can connect to the port and mess up the conversation, a retry or two may be useful.
<mgerdts> That would also provide some resilience in case the metadata server in the host is bounced while cloud-init is in the middle of a transaction.
 * mgerdts wishing we had a transport that was aware of multiple sessions
<rharper> mgerdts: you mention a race with other mdata-get users ... what else would be running in parallel with cloud-init that early ?  does mdata-get write a lock file somewhere that cloud-init could check for?  does mdata-get or the scripts themselves do any retry?  that may still result in some sort of  storm of clobbering each other then requiring some sort of back-off (or both sides failing)
<mgerdts> We could follow the advice at tldp.org for locking serial ports in mdata-{get,put,...} and cloud-init.  That would be a good thing.  It doesn't prevent some other random.process from opening the serial port and producing or consuming data.
<mgerdts> Options 2 + 3 would be the most robust.
<rharper> cloud-init's use of the serial port is pretty limited , just early boot;  it's somewhat surprising that any other user of the serial is active at that time
<mgerdts> Right now I'm trying track down what else on the system is using the metadata port.
<rharper> I do think your suggestion (2 +3) is a reasonable approach though;  but maybe pushing the parallel usage issue somewhere else, only to come back once those users add their retry and locking
<rharper> there are various serial multiplexors; conserver and the like;  maybe something infront of the raw serial device can help serialize access
<smoser> mgerdts: yeah.. we can add retry.
<smoser> and we can add advisory locking too, and put a change in mdata-get to do the same.
<mgerdts> I don't think that trying to add a multiplexer is the solution, as there's no session information attached to each byte that goes across the connection.  For now, the best solution seems to be a lock along with a retry.
<mgerdts> There's been some discussion of supporting vsockets.  If we get that in place, it would be great to transition the SmartOS metadata service over to that.
<rharper> +1 on vsockets
<smoser> mgerdts: well we use a socket in the container solution
<smoser> right ?
<mgerdts> yep
<mgerdts> We just don't have a way to pass a socket all the way into a VM yet.
<smoser> right.
<mgerdts> https://github.com/joyent/mdata-client/issues/11
#cloud-init 2018-02-02
<powersj> smoser: I don't have permissions, so can you re-add the cloud-init-committers to the following merge https://code.launchpad.net/~tlashchova/cloud-init/+git/cloud-init/+merge/337003
<Flurg> I'm trying to bring up a second interface in my user-data (#cloud-config) and it's not working. The second interface never gets configured. Ubunut 16.04 with CI 17.1 running on Openstack. Config is here: https://hastebin.com/awapojisew.hs   Other parts of config work AOK
<Flurg> In  /etc/network/interfaces.d/50-cloud-init.cfg I get the same config if I don't use the pasted code.
<powersj> Flurg: I think you need to provide more details like the subnet info, gateway, etc. Take a look at http://cloudinit.readthedocs.io/en/latest/topics/network-config-format-v1.html#subnet-ip
<Flurg> Cheers, I'll give it a go :)
<blackboxsw> bionic sync MP is up smoser https://code.launchpad.net/~chad.smith/cloud-init/+git/cloud-init/+merge/337088
<blackboxsw> after that merges, I was going to setup the SRU xenial/artful to snapshot from ubuntu/devel right? or should I  sync from master on artful/xenial. I forgot that step
<smoser> blackboxsw: sorry... di dyou havea bug ?for the sru?
<smoser> powersj: cloud-init-dev ?
<powersj> smoser: yeah that :)
<powersj> comes up as "cloud-init commiters" once you add it
<blackboxsw> smoser: mid-filing that now.
<smoser> blackboxsw: uploaded to bilonic.
<blackboxsw> thx smoser. touching up the sru bug
<blackboxsw> log2dch etc
<dpb1> bilbonic
<smoser> bilonic chronic
<blackboxsw> https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1747059 iswhat we'llwork on
<ubot5> Ubuntu bug 1747059 in cloud-init (Ubuntu) "sru cloud-init (17.1.46-g7acc9e86-0ubuntu1) update to 17.2.30-gf7deaf15-0ubuntu1" [Undecided,New]
<smoser> blackboxsw: wow. that is a big one :)
<blackboxsw> (artful) https://code.launchpad.net/~chad.smith/cloud-init/+git/cloud-init/+merge/337097 and (xenial) https://code.launchpad.net/~chad.smith/cloud-init/+git/cloud-init/+merge/337098
<blackboxsw> ok, just put together the upload rights document https://wiki.ubuntu.com/ChadSmith/DeveloperPerPackageUploadApplication
<blackboxsw> maybe next SRU I can do the uploads directly
<smoser> blackboxsw: had one fix in your xenial branch
<smoser> http://paste.ubuntu.com/26509461/
<smoser> other wise the build complains
<smoser>  http://paste.ubuntu.com/26509465/
<blackboxsw> smoser: ok, that didn't hit artful right?
<blackboxsw> yeah doesn't look like it
<smoser> right.
<smoser> because artful didn't have those patches
#cloud-init 2020-01-27
<blackboxsw> Odd_Bloke: heya, s your only SRU verification topic left OpenSTack? https://trello.com/c/PLfwx4v5/25-sru-manual-openstack-validation
<Odd_Bloke> blackboxsw: That and the mkswap one, I think.
<meena> i got the wrong guy https://github.com/canonical/cloud-init/pull/161#issuecomment-578538874
<blackboxsw> hrm, well at least that person is honest :).
<meena> hmmmmmmmmmmmm
<meena> i could submit a patch to freebsd, which fixes the current situation with the patch not applying cleanly, but that would only get us half the hunks
<meena> https://github.com/canonical/cloud-init/pull/161#issuecomment-578920473 he has a point
 * meena blames Odd_Bloke 
<Odd_Bloke> Like I said, I'm not happy about it either.
<Odd_Bloke> But that's the guidance we have from our legal folks.
<wyoung> Legal...
<meena> "guidance" may not be the right â¦ or, correct word in this case
<meena> ah, that doesn't translate well
<meena> my head is all languaged up with Rust and Denglish here
<meena> Odd_Bloke: i ight just close that pr then
<Odd_Bloke> meena: Leave it for now, I want to take another crack at it internally.
<Odd_Bloke> There may be something we can do for trivial cases like this, we've only asked in more general terms before.
<meena> *nod
<blackboxsw> Odd_Bloke: looks like we're done with proposing our SRU tasks (I just put up two prs too) . I think the only thing we are waiting on is cdo-qa results for xenial
<Odd_Bloke> blackboxsw: I'm still working on one of the validation scripts.
<blackboxsw> I'll verify your Openstack logs and start attaching results to the bug
<blackboxsw> Odd_Bloke: +1
<blackboxsw> I think we can stilll attach the cloud verification logs in the interim.
<Odd_Bloke> blackboxsw: Just one type on https://github.com/cloud-init/ubuntu-sru/pull/94
<Odd_Bloke> >.<
<Odd_Bloke> one _typo_
<ahosmanMSFT> Hi @blackboxsw
<ahosmanMSFT> Were you able to take a look at those cloud-test issue?
<ahosmanMSFT> ssh'ing issue, most likely due to something in wait_for_cloud_init function and the inconsistency of the property self._img_instance in image.py
#cloud-init 2020-01-28
<Odd_Bloke> meena: What _is_ the Python 3 on your distro called?
<meena> Odd_Bloke: python3.7 on FreeBSD 12.1-RELEASE
<meena> and python3 on this Ubuntu 18.04 laptop
<Odd_Bloke> meena: https://www.python.org/dev/peps/pep-0394/ <-- sounds like the FreeBSD Python maintainers need to read this ;)
<meena> Odd_Bloke: i agree.
<Odd_Bloke> And paride and I did discuss this briefly in a video meeting; if anyone has unusual requirements (like that), then they can do some symlink/PATH futzing.
<meena> yah
<meena> but i did forward that question to #bsdports let's see what they have to say
<Odd_Bloke> paride: Do you want to split out to a separate PR the commit that smoser mentioned is unrelated?
<paride> Odd_Bloke, yes (he is right)
<smoser> drop the change. its unrelated and its the same, no?
<smoser> [ -n "$var" ] == [ ! -z "$var" ]
<smoser> no?
<Odd_Bloke> The commit message mentioned it fixing a shellcheck warning.
<Odd_Bloke> But paride has listened to us too quickly, so I can't see that commit any longer. :p
<Odd_Bloke> Oh no, it's in the PR description too.
<paride> Odd_Bloke, updated that too
<Odd_Bloke> "This is a stylistic issue that does not affect correctness." <-- in the red corner, smoser; in the blue corner, paride
<Odd_Bloke> ;)
<smoser> honestly i think the change made it less readable.
<paride> :P
<smoser> oh. no. your change *does*  make it more readable.
<paride> I was indeed asking why
<paride> well we're keeping the change I think, just putting it in a separate PR
<Odd_Bloke> smoser: I'm +1 on the PR as-is, but don't want to merge it under you if you're still reviewing, so let me know once you're done with it. :)
<smoser> i am done reviewing. i dont really care.
<paride> meena, anyway the 'python2' and 'python3' pyexe strings did get some special treatment in run-container: https://github.com/canonical/cloud-init/blob/master/tools/run-container#L278
<paride> so I'm not sure it would have worked on systems where the python interpreter is not called in one of those ways (I didn't check)
<meena> paride: yah, i'm just debating with FreeBSD maintainers why they don't provide a python3 binary by default, and we're running in circles of misunderstandingsâ¦
<meena> paride: anyway, i'm fairly certain those tools won't run on FreeBSD, so there's no need to concern yourself with my comments, but i did just learn something, so, that's good? i guess??
<meena> can anyone give me an estimate on when one of y'all will be able to comment on robjo's network refactoring proposal? i'd like to plan my "free" time
<smoser> cloud-init needs support for fw_cfg .
<smoser> probaly extend nocloud
<smoser>  http://www.contrib.andrew.cmu.edu/~somlo/QEMU_fw_cfg/
<rharper> Odd_Bloke: blackboxsw: using new-upstream-snapshot -v --update-patches-only on ubuntu/xenial  shows the failure; I think have to "hand apply" which ends up being comparing the current version of the file, to the version from before 19.1 where we added the new client;  this is a manual process unfortunately;
<rharper> smoser: parsing fw_cfg values?
<smoser> that link makes it seem like with qemu_fw_cfg module
<smoser>   /sys/firmware/qemu-fw-cfg/by_name/opt/GuestInfo/raw
<smoser> the  kernel does it
<rharper> as a datasource then
<rharper> DataSourceQemuFwCfg
<rharper> or into NoCloud ? I guess as you suggested
<smoser> i'd just extend NoCloud. if by_name/cloud-init/meta-data
<rharper> worth thinking on;  I don't think we've dicussed much the idea of multiple datasources being present
<rharper> and which one should win
<smoser> well, nocloud already does merge from different sources
<smoser> but ... probably beter for the provider to just give one.
<rharper> is fw_cfg cross arch ?
<rharper> looks like x86 and arm only, no ?
<rharper> Odd_Bloke: blackboxsw: are you OK with me pushing a new-upstream-snapshot -v --update-patches-only update to ubuntu/xenial  and ubuntu/bionic to fix the daily ppa builds ?
<rharper> do you want me to push the fix to branch for review  ?
<Odd_Bloke> Might be worth pushing it somewhere for review, ISTR we ended up having to do some branch surgery last time.
<rharper> ok
<Odd_Bloke> I can't remember _why_, but maybe I will if I look at the branch before it's pushed. ;)
<blackboxsw> +1 on the new-upstream-snapshot as review so that we have a record for future to remind us of the action taken
<rharper> http://paste.ubuntu.com/p/Nn2qXkdsNC/
<rharper> is what the xenial update will look like, but I'll put up the branch in a minute
<Odd_Bloke> That looks good to me (though I haven't tested if it actually fixes builds, I'm trusting you to do that :p).
<rharper> Odd_Bloke: yes, I
<rharper> I'm going to write down the steps I'm doing (and likely will want to add a tag to the commit right before we modified the ubuntu_advantage config module since that's the source to which we want to revert
<smoser> rharper: well, current kernels for ubuntu have qemu_fw_cfg module in arm64, i386 and x86_64. not for ppc64le or armhf.
<smoser> current (5.3.0-26)
<smoser> i'm not sure why ppc64el and armhf missing
<rharper> smoser: IIUC, its a guest firmware issue
<rharper> so SLOF and whatever is used on s390x would need to support it
<smoser> maybe
<smoser> https://cateee.net/lkddb/web-lkddb/FW_CFG_SYSFS.html
<rharper> qemu will put it at a know ram location, and the firmware is supposed to update/read/modify with details from the machine that qemu constructs via commandline configuration
<rharper> sysfs could read it I suppose without firmware help
<rharper> https://github.com/coreos/ignition/pull/905
<Odd_Bloke> We did have someone in here asking for it the other day.
<Odd_Bloke> blackboxsw: https://github.com/cloud-init/ubuntu-sru/pull/96 is my last SRU verification.
<blackboxsw> thanks Odd_Bloke and it looks like I need to review my results. thx for review
<Odd_Bloke> Of course. :)
<blackboxsw> Odd_Bloke: pushed https://github.com/cloud-init/ubuntu-sru/pull/92
<blackboxsw> Odd_Bloke: minor nit on linking to the SRU README.md and please land https://github.com/cloud-init/ubuntu-sru/pull/96#pullrequestreview-349606965
<blackboxsw> robjo: so sorry, I forgot to click submit on the pending review comments https://github.com/canonical/cloud-init/pull/162 that I put in last week. added them now for your thoughts
<blackboxsw> I just realized they were still in "Pending"
<robjo> OK, thanks will take a look
<meena> rharper: i can't believe i was right about the use-case
<rharper> meena: ?
<meena> rharper: IBM / EBCDIC.
<meena> https://github.com/canonical/cloud-init/pull/187#issuecomment-578116993
<rharper> meena: hehe indeed
<meena> rharper: i can't believe we're finally getting EBCDIC in the cloud
<rharper> I think SoftLayer may have s390x available, and certainly openstack has been trying;
<rharper> this use-case is more for the s390x ubuntu installer which is leveraging cloud-init for first-time environmental setups to make installing on  an s390x, a lot less like installing on s390x =)
<rharper> Odd_Bloke: blackboxsw: ok, finally sorted out the PRs for fixing daily PPA (without a new upstream snapshot), https://github.com/canonical/cloud-init/pull/196 https://github.com/canonical/cloud-init/pull/197
<robjo> blackboxsw: tag you're it
<blackboxsw> robjo: thanks, I think you have minor conflicts against tip of master (that Odd_Bloke character landed some dropping py2.7 stuff :) )
<robjo> blackboxsw: fixed
<blackboxsw> thanks
#cloud-init 2020-01-29
<hipolito> Hi!, cloud-init writes permanent interface rules in udev. Is there a way to disable it? So the system uses the systemd predictable interface names instead of eth*
<meena> hipolito: yeah, there's a settingâ¦ lemme look that up
<hipolito> thanks meena
<meena> hipolito: never mind, i have *nod* idea.
<meena> nod? no.
<meena> i just looked it up in the code, there doesn't seem to be a switch
<meena> and here i thought it was just not (badly?) documented.
<meena> i don't even know how you would override that in the user-configâ¦
<meena> you wouldn't
<hipolito> meena: well I guess I have to live with that
<hipolito> meena: thanks a lot!
<meena> hipolito: thought this was an answer from someone in ##rust trying to help me lolol
<hipolito> meena: that I didn't understand, I guess I missed something
<amansi26> Hi.. I have a query for cloud-init v19.1 . I am trying to install. Initially it came to disable status . Then I ran cloud-init clean and cloud-init init . So now the status is in running state. But when I do capture and deploy a new VM, the deployed VM get assigned with the base VM IP.
<amansi26> I check /etc/network/interface it has the base VM IP. but /etc/network/interfaces.d/50-cloud-init.cfg file has correct IP. How can I make the IP up?   I am using ubuntu 16.04 with ConfigDrive datasource
<amansi26> Deployed VM status is disabled
<amansi26> And it says http://paste.openstack.org/show/788920/ on running cloud-init init
<Odd_Bloke> rharper: blackboxsw: If I could get a review of https://github.com/canonical/cloud-init/pull/199 sooner rather than later, that'd be good.
<Odd_Bloke> We have contributions that need CLA signatures; having a working link is somewhat important for that. Â¬.Â¬
<meena> i hope the CLA checker emails those PRs to your legal department
<smoser> https://github.com/canonical/cloud-init/pull/128
<smoser> i can land that... but whatam i supposed to push
<smoser> oh. squash and merge is the only option.
<Odd_Bloke> smoser: I can land it with a +1 from you, I think, sorry I didn't think to ping you!  But, yeah, squash and merge is The Button.
<smoser> oh fudge
<smoser> "CLA not signed"
<smoser> well, the label says that, but he has signed it.
<Odd_Bloke> smoser: I think we have the link between GitHub and Launchpad, but not the actual signature on the LP account.
<Odd_Bloke> But maybe I'm misremembering.
<Odd_Bloke> Will check in a bit.
<rharper> blackboxsw: ok, I've updated my two PRs for ubuntu/xenial and ubuntu/bionic using the new-upstream-snapshot as we discussed and leaving the debian/changelog entry as UNRELEASED;
<blackboxsw> +1 rharper checking now
<rharper> blackboxsw: and I'm not sure about the merge ;  I don't think we want to squash merge for release branches, right ?
<blackboxsw> rharper: +1 no squash merge for those
<blackboxsw> we want the separate debian/changelog commits so we can (in theory) apply the functional patches to a separate ubuntu/<release>
<blackboxsw> though that doesn't truly make sense for this case
<blackboxsw> as we patched the series-specific debian/patches/X
<blackboxsw> ahh right rharper, and we don't want to collapse the separate  merge commits pulled in from new-upstream-snapshot either
<blackboxsw> now that I see the PR
<blackboxsw> rharper: so, I'd have expected the debian/changelog post the new-upstream-snapshot to contain all the commits listed in the single squashed debian/changelog entry, but I still only see your original debian/changelog individual entry https://github.com/canonical/cloud-init/blob/5ff6b663d75b02ff6d8ff0b824488d99a876ae00/debian/changelog
<rharper> hrm
<rharper> I just ran new-upstream-snapshot
<rharper> so why would changelog not be correct ?
<blackboxsw> I'll paste a diff or what I get after new-upstream-snapshot
<blackboxsw> hrm, checking
<rharper> it looks to be there to me
<rharper> lemme look at github files
<blackboxsw> UI github might be stale
<blackboxsw> I'm refreshing git on cmdline to be sur
<blackboxsw> or *fetch*ing rather
<rharper> strange
<rharper> I see that was well
<rharper> but locally it's modified
<rharper> that's messed up
<blackboxsw> ahh you didn't push to your rharper-github-origin maybe?
<rharper> I force pushed to my github branch
<blackboxsw> ok fetching again
<rharper> I see what you're seeing on the UI
<rharper> but my local repo shows correct debian/changelog with all entries
<blackboxsw> oops I was diffing my bionic vs your xenial too :)
<rharper> no
<rharper> I see the problem
<blackboxsw> https://paste.ubuntu.com/p/6YD39PkyYj/ yeah still a problem
<rharper> I think I forgot the local commit steps
<blackboxsw> right right
<rharper> thanks, lemme do those
 * rharper starts over 
<rharper> yeah, it complains about no SRU bug number, so I think it doesn't do the normal commit it would
<blackboxsw> ahh when I dch -i added by entry, I incorrectly forgot to add the ~18.04 series designator so =I didn't get the SRU_BUG prompt. .... ok I have the steps working on my side rharper ( and I don't think we need/or want to fully run new-upstream-snapshot)
<rharper> almost there
<rharper> I've fixed up my xenial branch
<rharper> just about done with bionic
<blackboxsw> pasting what I did: (using your branch as reference)
<rharper> mostly not committing the debian/changelog change the SRU bug ref being not added (which I think in this case don't want to put anything in there yet)
<blackboxsw> rharper: https://pastebin.ubuntu.com/p/nywt73xSVp/ is what I did
<blackboxsw> rharper: that is a good alternative to allow us to avoid adding the SRU_BUG_NUMBER_HERE if we know we are not yet releaseing
<rharper> blackboxsw: yeah, i;ve updated bionic now as well
<rharper> oh, I see
<rharper> instead of the new-upstream-snapshot  use the refresh patches only path
<rharper> will that update the changelog correctly ?
<blackboxsw> though if you truly performed the new-upstream-snapshot and pulled in the upstream commits, then we would want those commits in the debian/changelog as the don't get found and collated again
<rharper> right, that's what I was thinking
<rharper> so, I suspect we just have to deal with the SRU bug noise in this exceptional path
<rharper> it only triggers if an upstream commit modifies files that are patched in the release branch
<blackboxsw> rharper: yes --update-patches-only left me with a single dch entry about 'refreshing patches' once I applied your fix to the debian/patches/ua...tip file
<rharper> yeah, I think what I did now is the right thing
<rharper> and this is the missing commit you wanted, https://github.com/canonical/cloud-init/pull/196/commits/a444f4d4fbb7b24627bf86166724edeedd491e8d
<blackboxsw> +1 rharper works for me. so do we have a work item for new-upstream-snapshot to 'ignore SRU_BUG_NUMBER_HERE' that we need to do then?
<blackboxsw> since we aren't yet releasing in SRU
<rharper> blackboxsw: maybe
<rharper> once we land these two PRs, and new upstream commits, we can test/verify what new-upstream-snapshot does in that case
<rharper> I suspect that its OK to have SRU_BUG in changelog as long as the top clog entry is still UNRELEASED
<blackboxsw> otherwise we could have used just new-upstream-snapshot --update-patches-only route with a manual fix to debian/patches/ubuntu-avantage*tip
<rharper> well, I think we said we want to keep debian/changelog up-to-date with state of the branch, so
<blackboxsw> we can either way: 1: only run new-upstream-snapshot --update-patches-only (and manually fix the debian/patch as you did in your original diff) and leave the branch alone at that point     OR
<rharper> blackboxsw: stand-up hangout real quick ?
<blackboxsw> 2. perform the full new-upstream-snapshot and manually patch the debian/patch/debian/patches/ubuntu-advantage-revert-tip.patch  and make sure the upstream commits that got add are all present in debian/changelog and we leave it in UNRELEASED state
<blackboxsw> yeah definitely
<blackboxsw> was thinking the same
<blackboxsw> rharper: https://github.com/canonical/cloud-init/pull/197 and https://github.com/canonical/cloud-init/pull/196 are approved if you wanted to git push origin/ubuntu/xenial  from your fix branches
<blackboxsw> rharper: we avoid squash merge in the github UI at the moment so I think we'd have to do this commandline
<blackboxsw> *on the command line*
<rharper> blackboxsw: yes, I can push to origin I think
#cloud-init 2020-01-30
<boolman> hey, cloud-init runs to early for me. is there any way to delay it?
<Odd_Bloke> boolman: Could you expand on the problem you're trying to solve?
<boolman> Odd_Bloke: yeah sure, I have no issues at all running cloud-init for example on openstack vms. however, Im trying to get it to work on vmware, and I believe vmware is really slow to set the network configuration. so cloud-init is already done before it gets network access
<boolman> so this is installed on my vm template: https://github.com/vmware/cloud-init-vmware-guestinfo which allows me to send userdata and metadata to the vm during deploy ( terraform in my case )
<Odd_Bloke> boolman: OK, that's useful information.  What specifically is failing?  (cloud-init _could_ happily use the guestinfo without networking, I think, so I'm guessing that there's userdata or somesuch that is breaking?)
<boolman> I've disable networking through cloud-init, network: { config: disabled }
<boolman> what is failing is basically everything that requires network, so apt_update, packages: [], bootcomd: [ ping -c 1 8.8.8.8 ]
<Odd_Bloke> OK, and what distro/version is this, and how did you install cloud-init?
<boolman> ubuntu bionic, apt-get install cloud-init
<Odd_Bloke> Most Ubuntu cloud images already have cloud-init installed; how are you creating your image?
<boolman> this was built from an cd iso
<boolman> dont think I can run cloud images on vmware
<Odd_Bloke> http://cloud-images.ubuntu.com/releases/bionic/release/ has a variety of images (including a VMDK and an OVA), so you might want to consider using those (if changing the image source is an option).
<Odd_Bloke> How is networking being configured if not by cloud-init?
<boolman> https://www.terraform.io/docs/providers/vsphere/r/virtual_machine.html#cloning-and-customization-example
<boolman> the network_interface {} block
<Odd_Bloke> boolman: Hm, OK, I'm not familiar with that.  Does that actually generate network configuration inside the guest, or is it just configuring the devices that will be presented to the guest?
<boolman> yes it works, just not during the cloud-init's lifetime
<Odd_Bloke> Do you know how it writes out its network configuration?  Ubuntu's boot has systemd-networkd-wait-online.service, which waits for networking before proceeding, and the network-dependent parts of cloud-init run after that.
<Odd_Bloke> So I would expect it to work regardless, but perhaps the network is configured after that point?
<Odd_Bloke> boolman: Do you have files in /etc/netplan/... ?
<blackboxsw> rharper: minor doc suggestions on https://github.com/CanonicalLtd/uss-tableflip/pull/31 I put up https://github.com/CanonicalLtd/uss-tableflip/pull/32  as well
<rharper> thanks
<boolman> my vm boots and network is fine.
<wyoung> Nice work
<blackboxsw> ahosmanMSFT: sorry, I'm finally poking at Azure CI tests now not seeing the timeout error so far. will give it a few runs and see if I can see it.
<ahosmanMSFT> blackboxsw: Thanks, when issue was running multiple tests at once the issue occurs due to self._img_instance having different values in images.py on azurecloud platform. Also ssh time out issues due to wait_for_cloud_init function.
<blackboxsw> ahosmanMSFT: you mean at once (in parallel) or serially running through the whole test suite?
<blackboxsw> I'm guessing serially running the whole suite right
<ahosmanMSFT> yes
<blackboxsw> ok thx. will give it a couple runs
<ahosmanMSFT> Those issues occur at the same time, I was able to debug and find them seperately
<ahosmanMSFT> but the ssh one only effects time out
<ahosmanMSFT> the other issue (self._img_instance not updating) effects image building, so no snapshots
#cloud-init 2020-01-31
<sdhd-sascha> Hi, on 20.04. cloud-init didn't configure ipv4. The devices was created from netplan config. And local ipv6 was applied. Any idea (where to look)?
<meena> sdhd-sascha: the log is always a good first start
<sdhd-sascha> meena: here:
<sdhd-sascha> https://www.irccloud.com/pastebin/LrzArrzg/
<sdhd-sascha> https://www.irccloud.com/pastebin/YuR5RFai/
<sdhd-sascha> Should i look deeper, or is there some other way in the future to go ?
 * sdhd-sascha afk - hope to understand, later
<Odd_Bloke> sdhd-sascha: If you could file a bug describing what you're doing and what you expect to see, that would be best.  Make sure to run `cloud-init collect-logs` on an affected instance and attach the tarball it produces to the bug. :)
<sdhd-sascha> Hey, Odd_bloke... you know i can read clear code...  (today i do nothing.)  what does your stomarch say ? should i look or leave it ?
<Odd_Bloke> sdhd-sascha: I'm not sure I understand the question. :)
<sdhd-sascha> Odd_Bloke: I'm not sure, if i should ask, or learn alone
<Odd_Bloke> sdhd-sascha: I think you should ask!  Filing a bug is an easy way for us to keep all the information about an issue in one place, which we can then discuss further here.
<sdhd-sascha> Odd_Bloke: did you mean, i didn't see something ? it's no my favorite... i thought - i ask, maybe there is group, and of this group someone, answer... (sorry, if i ask something stupid) ... and ... and .... really sorry ... (hmm... should i ask again ? ) [Can i do failuare again ... ]
<sdhd-sascha> Odd_Bloke: yes, you said that ;-) i will inspect and do that ;-)
<sdhd-sascha> Odd_Bloke: in my last company it was often, that the supporters, used teamviewer ...
<sdhd-sascha> Odd_Bloke: sorry, (sometimes my live and past) ...
<sdhd-sascha> thank you
<sdhd-sascha> until now, i"m with you ;-) (until now, not sure, who you are... because. didn't have time to stalk ;-))
<meena> Odd_Bloke: how are your negotiations with legal going?
<Odd_Bloke> meena: Argh, thanks for the reminder, I'll send an email now.
<meena> Odd_Bloke: speaking of emailâ¦ remember that thread from me and robjo ?
<meena> anyone? ;P
<Odd_Bloke> meena: Yeah, we've had people at internal planning sprints, so we've been short-handed for the past ~couple of weeks.  We'll hopefully get back to more regular service next week. :p
<meena> aye
#cloud-init 2020-02-01
<sieve> Hello - anyone in today?
<sieve> I am trying to understand how cloud-init is triggered - I notice that when cloud-init has been triggered on a machine it is quite hard to get it to run on next boot
<meena> i could've answered that
#cloud-init 2020-02-02
<blackboxsw> we should add that one to the FAQ page .https://cloudinit.readthedocs.io/en/latest/topics/faq.html
