#cloud-init 2014-01-20
<smoser> harlowja_away, around ?
<natorious> trying to get cloud-init running on Gentoo
<natorious> there appears to be a package in portage but installing it doesn't provide any init scripts
<natorious> would copying the rhel init scripts be all thats needed?  Anything else I might run into?
<pquerna> smoser: cla thing is recorded.
#cloud-init 2014-01-21
<smoser> pquerna, thanks.
<smoser> natorious, well its not much use without init :)
<smoser> i'd guess that the sysvinit scripts should be reasonably re-usable, but i don tknow how gentoo does boot order dependency resolutoin stuff.
<iliyas> How do we define multiple sections of a YUM repo file in YAML form ?
<harlowja> smoser just got baack
<harlowja> ya, as for gentoo, not quite sure about the boot order, the scripts though should work fine
<smoser> iliyas, mulitple sections ?
<smoser> harlowja, i think i say never mind now.
<smoser> oh... i dropped your 'sudo pip install'
<harlowja> its ok
<smoser> i would like targets of 'make pip-depends'
<smoser> or somethign like that 
<harlowja> or venvs?
<harlowja> there is always that
<iliyas> Yes, like [section-1].... [section-2]... in a single .repo file.
<smoser> yeah, i want pip-depends to work. in venvs
<smoser> or to be able to say 'make apt-depends'
<smoser> and apt-build-depends 
<harlowja> smoser hmmmm
<harlowja> what would apt-build-depends do, make the packages?
<harlowja> btw, another question smoser making this DatasourceOpenStack over the weekend, do we want to keep dataSourceConfigDrive?
<harlowja> since DatasourceOpenStack basically absorbs pretty much all of its functionality
<harlowja> + more
<smoser> harlowja, not make the packages
<smoser> just install them
<smoser> .PHONY same
<smoser> harlowja, i think we want datasourceconfigdrive
<smoser> yes, but it does share a *lot* of code with datasource openstack
<smoser> but at the moment the only way we configure thingson or off at is the sources/DataSourceXXX level
<smoser> that make sense ?
<smoser> and i was planning on trying to get to add vendordata ocnsumption to the datasourceconfigdrive and to the nocloud
<harlowja> k
<harlowja> i'm splitting shared functionality smoser off into helpers module anyway
<harlowja> but not much left in ConfigDrive after that split, lol
<smoser> yeah, and thats fine.
<harlowja> k
<smoser> but i think that its reasonable to say "i only want ocnfig drive"
<harlowja> sure
<smoser> or "i only want openstack metadata service".
<harlowja> or u want both
<smoser> yeah.
<harlowja> k, thats similar to what i am doing
#cloud-init 2014-01-22
<abk> would maintainers be interested to have varied linux/bsd distro compatible logic to configure system settings like network/pasword in an adapter fashion
<smoser> abk, we can configure network to some extent, and you can add users and set their password that works in linux. i'm not sure if it would work in bsd.
<abk> smoser, I'll be working on a binary reaching via cloud-init into instances taking care of all these base configuration on VMs which get pushed by Hypervisor during build
<abk> smoser, I thought if cloud-init can use it up... will instead write as a component of it instead
<smoser> abk, we can make cloud-init consume such data for sure.
<abk> smoser, distros supporting (RHEL,Fedora,CentOS,Debian,Ubuntu,Gentoo,Arch,OpenSuse,FreeBSD,Scientific) and all major version of these
<smoser> i'm not sure what you meant by "binary reaching via cloud-init".
<abk> smoser, I'm not very well-versed in cloud-init yet... but what I notice is I can get my service doing these tasks via any bootstrap script using cloud-init's userdata
<abk> smoser, but if it can be a part of cloud-init (as in if you folks and community is interested)... I'll instead put it somewhere where it's much easily usable by anyone desiring such feature
<smoser> ok. yeah, right. i would be interested in that, yeah.
<smoser> passing network settings in is currently kind of tricky/broken
<smoser> it should work except for the case of 'eth0' (or any other "auto" configured devices with information already in the instance)
<smoser> ie, ubuntu cloud images ship with 'auto eth0' (for dhcp).
<smoser> and changing that is not really functional
<smoser> because we don't bring *down* interfaces when we configure networking passed in.
<smoser> :w
<shardy> Hey guys, noticed the docs have been bumped to 0.7.5, but the latest tagged release is still 0.7.4
<shardy> is a new release imminent?
<shardy> smoser: That's a question directed at you I guess :)
<smoser> not imminent, but development is open.
<smoser> the rtd is keyed off of Changelog i guess ?
<harlowja> smoser i think the rtd is keyed off the version.py in cloudinit
<harlowja> not changelog afaik
<harlowja> http://bazaar.launchpad.net/~cloud-init-dev/cloud-init/trunk/view/head:/doc/rtd/conf.py#L41 
<harlowja> smoser yt, ok with merging https://code.launchpad.net/~harm-o/cloud-init/freebsd  ?
<harlowja> sean here is gonna start pushing the people in the release team for freebsd to start making openstack images i think
<harlowja> using that freebsd stuff (and any future changes)
<smoser> i hadn't really looked at that.
<smoser> i recently changed cc_growpart
<smoser> so i would have thoguht the merge thing would not like line 70 in that diff
<smoser> https://code.launchpad.net/~harm-o/cloud-init/freebsd/+merge/198130
<smoser> and i think that VERSION (line 701) is going to piss off someone who was here before with some other distro. 
<smoser> but ... ok. merge i guess.
<smoser> oh wait.
<smoser> one thing
<harlowja> harmw yt :-P
<harlowja> ^^
<smoser> never mind. harmo signed agreement. cool.
<utlemming> smoser, harlowja: has anyone confirmed if the disk paritioning code works with this mp? 
<harlowja> i havent
<harlowja> but my guess is its not 100% complete
<harlowja> thats why seanwbruno just arrived
<harlowja> hahaha
 * seanwbruno stops trolling from afar
<utlemming> harlowja: that is my guess
<harlowja> seanwbruno to fix it all!
<seanwbruno> pfft
<harlowja> haha
<harlowja> seanwbruno i think is gonna try to bug the freebsd people to make better partitioned images, then hook this in 
<harlowja> but he can explain i guess
<seanwbruno> dealing with $work horse shit at the moment, but tomorrow I'll get with the fbsd re team to put something out that looks like our franken-images at the office.
<harlowja> lol
<seanwbruno> I may way to scrape the fbsd cloudinit stuff into a port for others if that's not in the works already.
<harlowja> i don't know anyone else doing it
<seanwbruno> hrm, I wonder if a fbsd ports has a hook into launchpad yet.
<seanwbruno> let me parse some make files
<harlowja> parse those makes files, lol
<harlowja> *make files
<harlowja> harmw yt
<seanwbruno> well, my cursory "grep -ri launcpad" doesn't seem to indicate any kind of helper stuff.
<seanwbruno> is there a shortcut URL that would engrabinate a tgz/tar/whatever of a LP repo?
<harlowja> smoser ?
<harlowja> ^
<seanwbruno> not vital, just being lazy
<harlowja> probably is some way
<smoser> i dont think there is.
<seanwbruno> well, I can just checkout the tree and tgz it myself.
<seanwbruno> like I said, just being lazy
<smoser> you're saying wget http://some/url/lp:cloud-init > trunk.tar.gz
<smoser> right ?
<seanwbruno> smoser: aye
<harlowja> seanwbruno one think i beleive will need adjustment (especially for y! use-case) will be the config-drive usage, which i believe that branch doesn't fixup
<harlowja> *especially around network settings being written
<harlowja> basically the config-drive in openstack contains a network settings file, which cloud-init then translates into whatever version it understands for the current operating system
<harlowja> looking at that review
<harlowja> 407	+ def _write_network(self, settings):
<harlowja> 408	+ return
<harlowja> :)
 * harlowja not really sure how freebsd handles network configuration files and stuff
<seanwbruno> if you want static configs, we'll have to construct an entry for rc.conf or rc.conf.local (preferred) and splat it in there
<seanwbruno> I suspect, that most configs will want to be splatted in there.
<harlowja> k, thats probably not that bad
<harmw> i didn't implement setting up networking in rc.conf just yet iirc
<harlowja> ah, k, harmw  were u planning on, maybe that can be seanwbruno 'get wet' commit, lol
<seanwbruno> lol
<harlowja> *ok that probably wasn't a very good selection of words
<harlowja> whatever
<harmw> ;)
<seanwbruno> I smell a "print" command coming on.
<harmw> I wasn't planning on coding that tonight though
<harlowja> lol
<harlowja> tommorow night then?
<harlowja> :-p
<harmw> friday's more like it :p openstack shows networking stuff per ec2 api, right?
<harlowja> hmmm
<harmw> besides config-drive (which I dont use)
<harlowja> not exactly
<harmw> stuff like bla/local-ipv4
<harlowja> ah, i think for the ec2 usage, people mainly rely on dhcp
<harlowja> for config-drive its pretty different
<harmw> indeed it is, pretty much straightforward in that case
<harmw> perhaps i can parse the dhcp lease file and configure that to be static 
<harmw> to cope with scenarios where networking is not done through a metadata api
<harlowja> http://paste.ubuntu.com/6798907/ is whats in the config-drive
<harlowja> basically a ubuntu network file :-P
<harmw> yea, I noticed the rRH scripts rebuilding that blob to something RH understands :p
<harlowja> :)
<harlowja> ya, josh's custom parser
<harlowja> haha
<seanwbruno> I have some hackery somewhere to parse that things somewhere.
<harlowja> ya, the _write_network(self, settings): should get the parsed object
<harlowja> not the raw string (i think)
<seanwbruno> ooo
<seanwbruno> I even did it in /bin/sh
<seanwbruno> wow ... such code
<harlowja> ah, maybe not, http://bazaar.launchpad.net/~cloud-init-dev/cloud-init/trunk/view/head:/cloudinit/distros/rhel_util.py
<harlowja> thats josh parser
<seanwbruno> oh
<seanwbruno> so
<seanwbruno> that's another thing I wanted to ask
<seanwbruno> why on earth isn't all the network data in the meta.js file?
<seanwbruno> I was confused why I had to parse meta.js for a couple of config elements but all the network data had to come from some janky redhat file.
<harlowja> lol
<harlowja> legacy
<seanwbruno> gross
<harlowja> thats really all
<harlowja> *janky ubuntu file ;)
<harlowja> lol
<seanwbruno> I was so happy (for a moment) when I could just do json parsing from single command line invocations of python and then got super confused by the then parsing of compeltely seperate network config file
<harlowja> :)
<harlowja> openstack started off being much more ubuntu specific, so that piece has stuck
<seanwbruno> something like this was what I was going to put in a rc script somewhere.
<seanwbruno> http://bpaste.net/show/171009/
<harlowja> soemday https://fedorahosted.org/netcf/ might be used 
<seanwbruno> I'd have just voted to cram it into the meta.js object and be done with it.
<seanwbruno> but
<seanwbruno> whatever
<seanwbruno> also, hooray for outputting text with python only to then turn around and pass it to grep/awk
 * seanwbruno is a silly, silly man.
<smoser> they picked that /etc/network/interfaces file
<smoser> that was a bad decision
<smoser> but unfortunately, bad decisions mean legacy dependencies.
<smoser> and they cant change *that* file.
<smoser> they could provide it in a more sane format elsewhere though.
<smoser> (and probably should)
<harlowja> ya
<smoser> http://paste.ubuntu.com/6798955/
<harlowja> so thats why u see weird RHEL converter
<smoser> that make sense ^
<smoser> i'm gonna commit it. python parsing of requirements.txt and ChangeLog
<smoser> i tihnk we can assume core python
<harlowja> seems ok to me
<harlowja> seanwbruno steal the RH converter, it already translates ubuntu format to agnostic format
<harlowja> and then just write agnostic format out to freebsd format
<harlowja> it probab ly doesn't need tobe in a file called rhel_util
<smoser> read-version is 4 times slower after my python rewrite :)
<smoser> but oh well
<harlowja> goooo python!
<smoser> python3 is only twice as slow as python2 in this case.
<harlowja> :(
<harlowja> smoser another thing i was thinking about
<harlowja> to make cloud-init work in both 2 and 3
<harlowja> already done quite a bit of that in taskflow using the six module
<harlowja> probably not so bad to do it in cloud-init
<harlowja> then it will be 2 and 3 compat
<smoser> i'd like that.
<smoser> we dropped boto that is good
<smoser> the python-oauth is another woone that has to be replaced
<harlowja> kk
<harlowja> should be simple to do six stuff
<harlowja> now that i know how to use it pretty well
<harlowja> then u won't be blocking ubuntu move to py3
<harlowja> seanwbruno u didn't go through the CLA stuff yet right?
<harlowja> *ubuntu CLA
<harlowja> *not openstack CLA
<seanwbruno> harlowja: nah
<harlowja> k
<harlowja> seanwbruno smoser  i think https://code.launchpad.net/~harlowja/cloud-init/net-distro-util/+merge/202743 should make it more obvious that u can use the same function
<harlowja> harmw
<seanwbruno> totally
<smoser> i wont block ubuntu move to py3. but dont think we'll get that in in trusty.
<smoser> that'd have to happen "really soon now".
<smoser> i was kind of planning on it as 0.8.0
<harmw> harlowja: please extend the comments a little to describe what this agnostic format looks like 
<harmw> since now one needs to go over the source, and I'm way to lazy to do that :p
<harmw> otherwise, looks like a nice change
<harmw> and usable, ofc
<harlowja> harmw sure
<harlowja> will do
<harlowja> if i can remember, haha
<harmw> :)
<harlowja> smoser i don't think six stuff will take that long really
<harlowja> its pretty straightforward
<smoser> i think its a pita.
<smoser> i liked my ignorant magic handling of unicode
<smoser> or string.
<smoser> and open() and write(string_or_unicode) just working
<harlowja> lol
<harlowja> ya
<harlowja> its dumb, i agree
<harlowja> https://code.launchpad.net/~harlowja/cloud-init/net-distro-util/+merge/202743 harmw 
<harlowja> comments added 
<harmw> nice
<harmw> (though I'm missing a newline on L85 :p)
<harlowja> hmmm
<harlowja> k
<harmw> anyway, I think it's not that hard to have fbsd use this function to get the networking done - provided the image was booting with a config drive
<harlowja> agreed, it shouldn't be
<harmw> and if it wasn't booted using config-drive, it should figure out what to configure per what it got through dhcp
<harlowja> yup
<harmw> that'll have to wait 'till the weekend though :)
<harlowja> seanwbruno can do it to :-P
<harlowja> get his feet wet
<harlowja> either way
<harmw> ah, well in that case I'll o it right now :p
<harlowja> lol
<harmw> tomorrow, probably
<harlowja> all good
#cloud-init 2014-01-23
<harlowja> smoser so what should we replace cheetah with
<harlowja> mako seems to be a popular one
<harlowja> that has syntax similar (sorta) to cheetahs
<smoser> harlowja_away, good enough for me.
<smoser> i think i've said before, but what i'd like is for our "version 2 templates" to basically declare themselves as vesion 2
<smoser> and if not declared as version 2 
<smoser> then to render in some legacy support for version 1
<smoser> ie, we can do 'my $HOSTNAME'.replace("$HOSTNAME", hostname).
<harlowja> my $hostname, what is this perl :-P
<smoser> harlowja, you have a minute?
<defmacro> hello 
<defmacro> I'm working on getting cloud-init to run on virtualbox and docker so my setup is similar to ec2's cloud init
<defmacro> lots of documentation and source, hard to get something working
<smoser> defmacro, more info ?
<smoser> how are you trying ot get it to work? 
<defmacro> trying to make use of the nocloud and nocloudnet data source, to embed meta-data, user-data into the file-system
<defmacro> its used only on the first image in the build chain, to consistently set up ssh keys and ubuntu user
<defmacro> on an existing system, im experimenting by installing cloud-init in a virtualbox vagrant and trying to find how to run cloud init on the command line
<smoser> ok.
<defmacro> i just havent found a working example yet.  reading the source 
<smoser> there is an examle. in doc/example/seed
<defmacro> thank you very much
<smoser> i started work a while ago on 'ci-tool'. your use case was one of the reasons.
<smoser> http://bazaar.launchpad.net/~smoser/cloud-init/ci-tool/view/head:/ci-tool
<smoser> give that a whilr
<defmacro> i will.  feels good to talk to someone about cloud-init
<smoser> ./ci-tool seed -s nocloud user-data.txt meta-data.txt
<defmacro> what motivated me to use cloud-init everywhere was differences in how ec2 ubuntu was created from the rest of our environments
<smoser> well, we certainly hav the goal of making it usable everywhere.
<smoser> http://ubuntu-smoser.blogspot.com/2013/02/using-ubuntu-cloud-images-without-cloud.html
<smoser> that discusses how to do this with kvm and our images.
<smoser> (ie, outside of ec2 entirely)
<smoser> http://ubuntu-smoser.blogspot.com/2013/08/lxc-with-fast-cloning-via-overlayfs-and.html
<smoser> that one shows how to use this stuff in lxc
<defmacro> nice, will be useful when I start with docker
<defmacro> progress: as root, run "/usr/bin/cloud-init start-local" with seed files in /var/lib/cloud/seed/nocloud
<defmacro> your suggestions and strace =)
<smoser> hm..
<smoser> if not stat.S_ISBLK(statret.st_mode) and not stat.S_ISCHR(statret.st_mode):
<smoser> i would have thought those 2 were mutually exclusive
<smoser> (that was added to cloudinit/config/cc_resizefs.py in freebsd branch)
<smoser> the S_ISCHR
<smoser> er... wait. its saying that char devices are ok for block device. hm..
<smoser> defmacro, yeah, 'ci-tool run' was supposed to basically dothings you need to do.
<smoser> but basically, on ubuntu, you'll run
<smoser> err. wait. waht version is this ?
<defmacro> 12.04 precise
<smoser> that must be old
<smoser> hm..
<smoser> yeah, that is old. :)
<smoser> but it should work. the jobs are different.
<smoser> basically look in /etc/init/ for cloud*
<defmacro> saw those, the status is "stopped/waiting" 
<smoser> right. here let me get you a list of stuf fto run
<smoser> (launching a precise instance)
<defmacro> think im interested in cloud-init-local since that ends up running start-local
<smoser> do this
<smoser> sudo start cloud-init-local
<smoser> sudo start cloud-init
<smoser> sudo start cloud-config
<smoser> sudo start cloud-final
<smoser> defmacro, ^
<smoser> the goal is for me to be able to tell you: download 'ci-tool' and run 'ci-tool run'
<smoser> harlowja, ^
<smoser> can you tell me why i should not filter out character devices in bsd ?
<smoser> when looking for something to resize.
<defmacro> smoser: thanks, I'll learn how cloud-init works but using a supported tool is preferable as most of my coworkers do not want to be cloudinit experts
<smoser> right.
<smoser> harlowja, .... comon.
<harlowja> in #openstack-meeting, will be done shortly 
<harlowja> :-P
<harlowja> ma meeting, ha
<smoser> k.
<smoser> i just pushed up lp:~smoser/cloud-init/freebsd
<smoser> which is merge from trunk back into https://code.launchpad.net/~harm-o/cloud-init/freebsd/+merge/198130
<smoser> and a fix of a test
<harlowja> k, back, seanwbruno 'can you tell me why i should not filter out character devices in bsd ' :-P
<harlowja> from smoser ^^ ;)
<smoser> harlowja, do you have any reason that i shouldn't just merge that ?
<harlowja> i don't :-P
<smoser> seanwbruno, is harm@weites.com ?
<harmw> smoser: thats me
<harmw> harlowja: is that networkinterface stuff from yesterday in trunk?
<smoser> harmw, i just merged it.
<smoser> https://code.launchpad.net/~harm-o/cloud-init/freebsd/+merge/198130
<smoser> thats yours, right ?
<smoser> i'm fixing some things up and then will pull it into trunk.
<smoser> one question i had.
<smoser> why did you do this:
<smoser> -        if not stat.S_ISBLK(statret.st_mode):
<smoser> +        if not stat.S_ISBLK(statret.st_mode) and not stat.S_ISCHR(statret.st_mode):
<harmw> yep, ~harm-o thats me
<harmw> why did I do that.... better yet, why didn't I put up a comment explaining it
<harlowja> thx for merging smoser netstuff, should help
<harlowja> smoser started, https://code.launchpad.net/~harlowja/cloud-init/six-2-3-compat, stupid file encoding is the biggest pain, lol
<harlowja> pita, lol
<harlowja> bytes type, unicode type...
<harlowja> blah blah
<smoser> harlowja, yeah, thats what i said i hate.
<harlowja> thankfully we have load_file and write_file
<harlowja> so its somewhat contained
<harlowja> just annoying
<smoser> ok. bunch of stuf fmerged.
<harlowja> cool, progress!
<harlowja> seanwbruno so u should be able to pull from cloud-init master now instead of harmw branch
<smoser> harlowja, http://paste.ubuntu.com/6805336/
<smoser> maybe better...
<smoser> http://paste.ubuntu.com/6805338/
<smoser> user-data isn't guaranteed to be tthere
<harlowja> kk
<harlowja> fixing up
<smoser> great.
<harlowja> 5 minutes, will have fix
<harlowja> smoser  https://code.launchpad.net/~harlowja/cloud-init/not-found-userdata/+merge/202963
<defmacro> smoser: got basic cloud init in docker and virtualbox, thank you very much.
<defmacro> been bugging me that my initial images were all created with different scripts; now cloud-init provides some guarantees after it has run
#cloud-init 2014-01-24
<smoser> defmacro, well, for ubuntu is there any reason all your initial images can't start from cloud-images.ubuntu.com ?
<smoser> just like cloud-init running anywhere, the goal is for those to be very mallable.
<defmacro> i used to use the cloud images for virtualbox but they had a lot of additional pacakges
<defmacro> ive found ways to build virtualbox and docker from iso or apt media, i like being able to specify a minimal build with each layer providing guarantees
<defmacro> eventually on ec2 i'll build my own cloud images too.  would love to see how the official images are built
<smoser> harlowja, booo
<smoser> http://paste.ubuntu.com/6806101/
<harlowja> arg, wtf
<harlowja> thats' not supposed to be possible
<harlowja> evil
<harlowja> ohhh, my fault
<smoser> yeah.
<smoser> you didn't apass the UrlError
<harlowja> ya
<smoser> you passed the exception
<harlowja> who made this crap code, haha
<harlowja> lol
<smoser> it says something like 'Y!' at the top of the file.
<smoser> i blame them.
<smoser> oh well. i'll get upload to buntu tomorrow.
<smoser> got to run
<harlowja> lol
<harlowja> kk
<harlowja> uploading fix
<harlowja> smoser ok, used right exception this time
<defmacro> smoser: can cloud-init be upgraded on the ec2 images to the latest version?  since im customiing my images, i'd like to get the new config modules
<smoser> harmw, i htikn you left out a 'copyfile' method somewhere.
<smoser> defmacro, you could do that. but ubuntu stable release process does'nt really allow for ubuntu to do that.
<smoser> i'm not sure how well cloud-init would run on 12.04 at the moment really.
<smoser> due to some dependencies that have been picked up
<defmacro> 12.04 cloud-init doesn't even have write_files.  doh.
<smoser> defmacro, yeah. :-(
<harlowja> harmw smoser https://code.launchpad.net/~harlowja/cloud-init/freebsd-cleaning/+merge/203190 if u guys want to check that out
#cloud-init 2014-01-25
<smoser> harlowja, thanks. pulled.
<harlowja> np
<smoser> harlowja, if you wanted to *think* about some way where i could have a sane 'pylint' like functionality.
<smoser> in a stable form
<harlowja> :-/
<smoser> (not dependent upon my ubuntu version)
<harlowja> tell pylint folks to stop adding crazy checks, lol
<smoser> ie, maybe that is best done with virtualenv
<harlowja> ya, i think so 
<harlowja> not so hard to do that i think
<harlowja> tox.ini and such
<smoser> utlemming, still around ?
<smoser> http://paste.ubuntu.com/6811685/
<smoser> that means we only run 'file' inthe unreasonable "user *meant* /bin/bash, but couldn't be bothered to type it" case.
<harlowja> smoser another one, https://code.launchpad.net/~harlowja/cloud-init/freebsd-cleaning-part-duo/+merge/203196
<harlowja> found more things to fix :-P
<smoser> dude. i can't keep up with you.
<smoser> i'm trying to get around to DataSourceNoCloud having vendordata
<harlowja> lol
<harlowja> whenever u get some time, just cleaning that up
<smoser> i think its funny, that you don't like the 80 char line width
<smoser> but your comments (commit  messages) you limit to like 30
<harlowja> ya, idk, its weird
<harlowja> i seem to have a weird habit 
<harlowja> lol
<harlowja> not really sure why i do that :-P
<harlowja> thx smoser !
 * smoser happy for bsd support.
<smoser> kind of wonky
<smoser> but.. getting there.
<harlowja> ya
<smoser> hey, just so its on your mind..
<smoser> if you were planning on getting in a native openstack datasource
<smoser> (which i would really like)
<smoser> then feature freeze is Feb 20.
<harlowja> hmmm
<harlowja> https://code.launchpad.net/~harlowja/cloud-init/ds-openstack
<smoser> oh. i didn't know that.
<harlowja> i'll see how much farther to go
<harlowja> feb 20th, no problem i think
<smoser> sweet.
<smoser> my goal is to have a cloud-init cut right before then (0.7.5) 
<harlowja> k
<smoser> and then work non-features into 0.7.6 and cut that much closer to 14.04 releas.e
<harlowja> sure
<harlowja> makes sense
<harlowja> most of the current stuff i did last weekend was http://bazaar.launchpad.net/~harlowja/cloud-init/ds-openstack/files/head:/cloudinit/sources/helpers/
<harlowja> refactoring that stuffs
<smoser> harlowja, you still around ?
<harlowja> possibly, lol
<harlowja> why are u still around smoser :-P
<smoser> no idea.
<harlowja> ;)
<harlowja> ya, same here
<harlowja> ha
<smoser> whatdo you think about http://paste.ubuntu.com/6812057/
<smoser> basically moved read_file_or_url to url_helper
<smoser> and then made it raise  UrlError on file errors too.
<smoser> the reason for this...
<smoser> so i can use it for dir2dict (which is partially there)
<smoser> one thing that sucks about it...
<smoser> url_helper then can't use 'load_file'
<harlowja> ya, hmmm
<smoser> (due to recursive import)
<harlowja> without file_utils or some crap
<smoser> riht.
<smoser> (which wouldn't be a terrible idea really.. but yet another thing)
<smoser> alternatively, i could just make the dir2dict not use read_file_or_url :)
<smoser> and do that itself.
<smoser> the idea of dir2dict was something like:
<harlowja> read_file_or_url could still be in utils though right, and still have the urlerror stuff
<harlowja> if that function wasn't moved then most of the other stuff could still work right?
<smoser> something caused me to move that.
<harlowja> zombies!
<smoser> let me see
<harlowja> k
<harlowja> otherwise smoser  seems ok
<harlowja> does MAAS benefit from the ssl_details stuff?
<harlowja> i thought it like read some local files
 * harlowja probably confused
<harlowja> i guess combine yours with https://code.launchpad.net/~harlowja/cloud-init/ec2-ssl and then most everything will be passing ssl_details around
<smoser> http://paste.ubuntu.com/6812109/
<smoser> maas does use remote
<smoser> so could use https
<smoser> but does not.
<harlowja> kk
<harlowja> paste seems fine with me
#cloud-init 2014-01-26
<harmw> harlowja_away: those timeouts I got from neutron/nova are probably comming from my controller beeing utter crap
<harmw> keystone couldn't keep up on this old Atom 
<harmw> I've now moved it to something a little more powerfull, and things suddenly got better :)
#cloud-init 2015-01-19
<m01> JayF: Ok, I saw your pull request to rackspace' cloud-init, and noticed it said as TODO that you're planning on upstreaming it. That sounds all good then!
#cloud-init 2015-01-20
<smoser> harmw, dont know of a freiendly firewall webgui thing. other than dd-wrt or openwrt. you can probably get an openwrt that you could run in a vm.
<smoser> alexpilotti, around ?
<alexpilotti> hey sure
<harmw> alexpilotti: why don't you guys offer wgettable images :)
<alexpilotti> harmw: because of the licensing :-(
<harmw> (it was retoric)
<alexpilotti> user needs to accept the license first
<harmw> yea
<harmw> I figured
<alexpilotti> lol
<harmw> :)
<harmw> it just sucks having to dl 6GB and than upload that same 6GB again
<alexpilotti> if it were up to me, Iâd just put them in a torrent!
<harmw> still not very wget compatible :P
<alexpilotti> yeah, but a big bandwidth saver for us :-)
<harmw> hehe definately
<harmw> alexpilotti: +infinity for that reBot :>
<alexpilotti> harmw: :-)
<harmw> hm, don't you guys have mirrors? in NL?
<harmw> since ~400kb/sec isn't realy fast :p
<alexpilotti> we have a lot of bandwidth here (Romania) and usually downloads are fats in EU, but we definitely need to add mirrors oversees
<smoser> ok... i think we have to have a cloud-init 0.7 -> python3 day.
<smoser> who is in ... maybe do that friday ? or monday ? 
<harmw> ah, thank god I don't no shit about python(3) :)
<harlowja> didn't i already do that :-P
<harlowja> https://code.launchpad.net/~harlowja/cloud-init/py2-3/+merge/225240 ;)
<harlowja> what else is left for python3 ;)
<harmw> :>
<harlowja> *besides making sure i didn't screw up 225240  to much
<harlowja> lol
<harlowja> six six six six
<harlowja> six
<harlowja> lol
<j12t> How do I disable certain data sources? E.g. if I know the VM boots in VirtualBox with a config disk, how do I prevent it from accessing the Amazon URL?
<j12t> Actually nvm, there's a description here: https://wiki.archlinux.org/index.php/Cloud-init
#cloud-init 2015-01-21
<smoser> cmiN, and claudiupopa happy to have you all here.
<smoser> harlowja: around ?
<harlowja> yo
<harlowja> sup
<smoser> why would/should i like to use testr
<smoser> versus something else.
<harlowja> i personally would say don't, lol
<harlowja> i personally don't like it :-P
<harlowja> it does running tests in parallel better
<smoser> so lets say that you were suggesting something... what would you suggest ?
<harlowja> but its output imho suck
<smoser> just nose ?
<harlowja> ya, i still think its adeqaute; although pytest is supposedly nice also (although i haven't used it)
<harlowja> http://pytest.org/latest/ 
<harlowja> i just don't like testr and its creation of weirdly formatted files that are hard to undersetand
<harlowja> crap like http://logs.openstack.org/10/148810/1/check/gate-taskflow-python27/8b0c041/subunit_log.txt.gz
<harlowja> but maybe thats really more subunits fault; but testr seems to use it so i'll blame testr, lol
<harlowja> so imho testr brings in alot of other projects (which sorta sux)
<harlowja> testttools, subunit, testr...
<harlowja> i think nose though is sorta dying/not updated anymore
<harlowja> nm, thats a lie, ha
<smoser> harlowja: https://github.com/cloud-init/cloud-init
<smoser> fyi. initial stub directory tree.
<smoser> now to make something actually work . :)
<harlowja> woot
<harlowja> looks good to me, ship it
<larsks> Is that replacing the bzr repository at lp:cloud-init?
<harlowja> i thinks so
<larsks> Spiffy.
<harlowja> now i guess is the question of how do we want this to operate? will this be a daemon that is connected into systemd events (and modules get triggered on events?)
<harlowja> or will it retain the CLI activation?
<harlowja> (or both or other...)
<larsks> You mean, for a next-generation version of cloud-init?
<harlowja> ya
<harlowja> *since afaik thats what the above will become
<larsks> Huh.  I would argue for not linking it too tightly to systemd, so that it is easy to support it in other environment (other linux distros/freebsd/solaris/etc).
<larsks> Unless the goal is really to make it only-distributions-running-systemd sort of thing.
<harlowja> i hope not, but it would seem like for linux responding to events (network plugged, reset the network information, new-metadata-arrived or something...) would be an approach
<harlowja> guess it depends on where we want to go here :-P
<larsks> Sure. So we can design cloud-init to make that easy through systemd units that run various command lines.
<larsks> Things I want:
<larsks> - cache metadata from the cloud provider, and then provide a query interface
<larsks> - stop masking exceptions, which makes it really hard to debug things
<harlowja> sure, seems reasonable
<harlowja> larsks add stuff to https://etherpad.openstack.org/p/cloud-init-next if u want
<larsks> Ooo, shiny.
<harlowja> *if u haven't already
<larsks> Are the stackforge suggestions yours?
<harlowja> i don't think so, ha
<harlowja> but might be :-P
<larsks> Because that seems like a really good idea, too.
<harlowja> nah, spelling is to good to be mine
<harlowja> so def not mine, lol
<harlowja> btw, metadata is already cached locally
<harlowja> http://cloudinit.readthedocs.org/en/latest/topics/dir_layout.html 
<harlowja> the metadata should be pickled into 'datasource' there (which is the datasource object)
<harlowja> maybe not as visible as it could be though
<larsks> Yeah.  
<larsks> And picke is awful python-specific.
<larsks> Providing a cli for querying it might help, though.
<harlowja> sure
<harlowja> reminds me of https://code.launchpad.net/~harlowja/cloud-init/query-back-duo :-P
<harlowja> from back in the day, ha
<harlowja> or https://code.launchpad.net/~harlowja/cloud-init/query-tool-is-back ha
<harlowja> didn't know there was 2 of those, lol
<larsks> Nice.
<larsks> The cirros cloud-init stuff does provide a query tool, which is nifty.
<harlowja> cool
<harlowja> cubswin 
<harlowja> lol
<harlowja> blame smoser for that password, lol
#cloud-init 2015-01-22
 * barry waves
<smoser> hey barry . 
<barry> smoser: hi
<smoser> i was lloking at your continuaiton of harlowja's 2to3
<harlowja> barry thx for the work btw :)
<smoser> i agree that getting tox going is essential.
<barry> yw!  i am weird in that i find this kind of thing fun :)
<smoser> why did you use contextlib2 ?
<barry> smoser: for ExitStack(), which is available in py3 in the stdlib
<barry> i might be able to get rid of it if its a problem.  it really helps with managing complicate context managers
<barry> sometimes you can avoid it with strategically written addCleanups but it's trickier
<harlowja> is that just for testing?
<barry> yep
<harlowja> would https://github.com/openstack/oslo.db/blob/master/oslo_db/tests/utils.py#L24 suffice?
<barry> mostly to properly handle mock patching in the setUps
<harlowja> k
<barry> (or more technically, unpatching in the tear downs)
<harlowja> thinking if its just for testing we can just create something for py2
<harlowja> but if its just for testing, then it seems ok
<harlowja> less runtime deps :-P
<barry> yeah
<barry> btw, i think there may be problems with using super() in py2.6
<harlowja> how so?
<barry> super() only really works with new style classes but unittest.TestCase is an old style class in 2.6
<harlowja> ah
<harlowja> stupid old-style
<barry> stupid 2.6 :)
<harlowja> ya
<harlowja> lol
<smoser> barry: how would you normally get py26 on ubuntu-recent ?
 * barry was so happy when he killed that off
<barry> smoser: you don't
<barry> :)
<smoser> but you put 'py26' in the tox.ini file
<harlowja> barry ya, sadly some people run rhel6.x (yahoo right now still, moving to rhel7 sometime this year maybe, lol)
<barry> well, you can build it from source, but system virtualenv (which tox uses) doesn't work with it
<barry> harlowja: i can't tell you what a bane of my existence that's been ;)
<harlowja> :)
<harlowja> rhel6 or python2.6?
<harlowja> or both?
<harlowja> lol
<barry> smoser: right, my plan was to get it working for 2.6 and 3.4, then to bring up a vm to test 2.6
<barry> harlowja: yes, both :-D
<smoser> 2.7. yeah.
<barry> harlowja, smoser i looked carefully at test_cs_util.py and afaict, even the existing tests never really test anything other than CepkoMock.  they don't touch Cepko afaict
<harlowja> ah, cepko, no idea about that, runs away, lol
<barry> i basically skip the whole test class in my branch because of that
<barry> probably the whole test_cs_util.py file should just be deleted or completely rewritten
<barry> i can help y'all integrate coverage at some point if you want :)
<harlowja> coverage u say, lol
<barry> yeah, i know, crazy talk!
<harlowja> thats like how much your body is covered with clothes right
<harlowja> ha
<barry> harlowja: you know i work from home, right?
<harlowja> errrr
<harlowja> lol
<harlowja> so does smoser :-P
<barry> what is this "body covered with clothes" thing of which you speak?
<harlowja> true dat
<harlowja> lol
<barry> :)
<smoser> harlowja: is that why you were 'harwlow_at_home' earlier today ?
<harlowja> lol
<harlowja> quite possibly
<barry> i'm fairly sure i now understand how to translate mocker to mock, but there might be corner cases.  so my current task is to convert from mocker to unittest.mock and see if i can get the tests to pass
<harlowja> barry so future coverage and stuff, i'm not sure; depends on how we want to focus on https://etherpad.openstack.org/cloud-init-next and https://github.com/cloud-init/cloud-init (and the next hotness)
<harlowja> depends on how much we want to put 0.7.x on life-support
<harlowja> that decision is above my pay grade, ha
<barry> harlowja: yep. understood.  what i'd really suggest is to get the infrastructure in place to do tox+coverage from the start with any rewrite.  don't worry about getting 100% until you have some time to spend on it
<smoser> barry: so for the rest of my day, how can i help you on that ?
<barry> but knowing is better than not knowing
<barry> smoser: help with?  coverage?  the py3 port?
<smoser> barry: the tox is in place on cloud-init 2.0, and will make sure to add coverage.
 * harlowja not helping u guys get your clothes/coverage on
<smoser> from what you've seen on your stuff, where woudl you like me to jump in.
<barry> smoser: take a look at the system-image branch.  it's py3-only but should be largely translateable.  and i can help with any details.  http://bazaar.launchpad.net/~ubuntu-system-image/ubuntu-system-image/client/files
<smoser> while you admitted to finding 2to3 porting fun, i find it quite annoying.
<smoser> ?
<barry> smoser: it uses some wacky tox stuff because of the different testing environment requirements between the phone and snappy, but the basics are pretty easy
<barry> smoser: yeah.  if you look at the tox.ini and coverage.ini files in that branch, i think you can work out how to integrate coverage
<barry> smoser: oh, another thing to consider is switching to nose2 which is much better than nose and the future (nose being essentially eol'd for nose2)
<barry> smoser: in that case, look at unittest.cfg from that branch also
<barry> and http://bazaar.launchpad.net/~ubuntu-system-image/ubuntu-system-image/client/view/head:/systemimage/testing/nose.py
<barry> smoser: steal anything from there you want.  i cargo cult a lot of that stuff between all my projects.
<barry> smoser: a simpler, but similar example: https://www.gitorious.org/python-world/python-world/source/a4d9171d8e4a7815d75fd7f8f75bb38418b6c63c:
<barry> smoser, harlowja i'll ping y'all when i'm happy with the port.  any and all feedback welcome!  i only want to kill off py2 from the various images.
<harlowja> lol
<harlowja> cools
<smoser> barry: well, how can i help you?
<smoser> (thanks fo rhte suggestion of nose2)
<barry> smoser: right now, i think i'm okay.  if i get stuck or have questions, i'l ping you.  i want to have a branch ready for review by eow (maybe eod if i get lucky).
<barry> smoser: thanks!
<smoser> ok then. i'll get out of yoru way :)
<smoser> the other no-python-3 thing is oauth
<smoser> cheetah really is not needed.
<smoser> the tests my insist on it, but in running practice its only used if user needs it (which is unlikely)
<barry> smoser: oh, that would actually be helpful.  you should switch to oauthlib.  the api is different enough that it takes some thought, but oauthlib is py3 compatible and actually maintained for the last 6 years :)
<barry> (oauth being abandonware since 2009)
<smoser> barry: yes. i know about oathlib. 
<smoser> yeah. 
<barry> i saw the oauth imports, but promptly erased them :)
<barry> from my brain
<barry> i've done that port before, it's not too difficult but it's not entirely trivial
<harlowja> only for maas i think right?
<barry> harlowja: i can't answer that, since it would require me to actually understand the code :)
<smoser> right
 * harlowja pretty sure thats right, ha
<harlowja> why u no understand all the code yet, lol
<harlowja> ha
 * barry goes clicky clacky
<harlowja> fasterrrrr!
<harmw> harlowja: what do you guys use for storage in openstack deploymnts?
<harmw> (or you smoser)
<harlowja> harmw ah; so this is tricky area for yahoo
<harlowja> yahoo has a bunch of cloudy storage stuff that already exists and so block-storage isn't the top contendor for us
<harlowja> http://en.wikipedia.org/wiki/Yahoo_Sherpa is one such system
<harlowja> *closed-source
<harmw> oh ok
<harlowja> ceph is getting more adoption but most architects i think still prefer using the other stuff thats built if possible (which already works in mostly cloudy manner)
<harmw> other stuff like.. :)
<harlowja> hmmm, there are some other db-aas stuff that people built; so i think thats another one
<harmw> i want a 2 perhaps 3 node setup, just not settled on the storage part
<harlowja> block-storage though is more of a slow-up-and-coming thing
<harlowja> *since this existing stuff already exists
<harlowja> http://en.wikipedia.org/wiki/MObStor is another one harmw 
<harlowja> probably some other ones that are not really documented online (but are mentioned somewhere/somehow by leaks, lol)
<harmw> hehe
<harlowja> sherpa though i think is the thing that most people are getting directed to
<harlowja> *or that db-aas stuff; since alot of groups still need sql-like-stuff
<harmw> perhaps I'm just gonna use LVM here
<harlowja> http://en.wikipedia.org/wiki/Yahoo!_Query_Language is also recommended (its a query-as-a-service  in a way)
<harlowja> so anyways, different things :-P
<harmw> yup
<harmw> useless answers, again :P
<harmw> damn
<harlowja> :)
<harmw> im not even sure if I should do TripleO 
<harmw> it looks very cool
<harlowja> for our current vms (due to above mentioned exsting services) its mostly local-disk (and treat your vms as cattle, put needed data in sherpa or elsewhere...)
<harlowja> we'll get to ceph eventually and make this more accessible (but have to convince people that is needed over things like sherpa...)
<harlowja> ^ is part of the battle/pain, lol
<harmw> :)
#cloud-init 2015-01-23
<barry> smoser, harlowja well, mocker is gone.  py27 tests all pass.  low hanging py34 fixes pushed, but there are still lots of test failures, and oauth still exists.  i'm done for the night.  will try to return to it tomorrow, though i have some other things to do in the middle of the day.  g'nite and enjoy!
#cloud-init 2015-01-24
<gerard__> hello
<gerard__> i'm trying to run an EC2 user-data script that's failing on a Facter run
<gerard__> i am running as root... the script executes as desired in the shell
<gerard__> here is the error: http://pastebin.com/1bS849g5
<gerard__> is there a way to tell cloud-init to continue execution?
<gerard__> the user-data script is here: http://pastebin.com/kkcaiKwh
<gerard__> anybody home?
#cloud-init 2016-01-27
<waldi> moin
<pwiltsey> I have a use-case where I would like to configure a standard user-data config for "every" instance provisioned, but I would still like the tenants to be able to provide their own as needed.  This would conceptually be presenting the final user-data to the instance as being a concatenation of both our admin designated site user-data and the individual user-data.  Please direct me elsewhere if there is a better place to ask this question
<pwiltsey> .
#cloud-init 2016-01-29
<dacamp> Bash scripts in /var/lib/cloud/scripts/per-instance, put there during AMI creation, are expected to be run once per instance right?
<Guest65435> Hi There. Is there any way I can check any logs for failed cloud-config part in cloud VMs ?
<Guest65435> I have been using cloud-config since long now. But, when it works, I can see everything in cloud-init-output.log file.. but there is absolutely no log if some part in cloud-config section is wrong.
<Guest65435> Even the minute 'space' mistake leads to failure of complete cloud-config block.
<Guest65435> Can anyone please help?
<smatzek> the only thing I can think of that may help is to modify the logging level to DEBUG and make cloud-init re-run.  That may put something in the logs.
<Guest65435> ok. But is there anyway I can re-run my cloud-config template from within OpenStack VM?
<smatzek> This is what I normally do:  Delete the semaphore file for your module in the /var/lib/cloud/instance/sem/ directory (e.g., /var/lib/cloud/instance/sem/config_foo). Then run `/usr/bin/cloud-init modules --mode <init,config,final>` depending on what kind of module you are writing, to have cloud-init re-execute your module. Some versions of cloud-init allow you to run a single module at a time as well.
<smatzek> remoe cloudinit's data directory (/var/lib/cloud/data) and reboot.
<Guest65435> Ok. I will give it a try and share with group. Thanks a lot for the help.
#cloud-init 2017-01-23
<smoser> Ahrotahntee, you can't (unless you are using 'nocloud') provide metadata. the general line is that 'metadata' comes from the cloud provider, and userdata comes from the user.
<smoser> but then further, yeah, there is no way to easily reference those things generically from inside a config or environment or anything.
<Ahrotahntee> smoser: once the environment is up I have no problems (it's just a json object), I was just really hoping I could bake it into the config
<Ahrotahntee> oh well; I'll figure something else
<smoser> what is it that you ant to bake in ?
<smoser> i'm kinda confused on what your goal is..
<ajorg> Good morning. I just filed https://bugs.launchpad.net/cloud-init/+bug/1658734 but I'm happy to cook a patch for it if I can get a hint about how you'd prefer to see it resolved. At the very least what you'd like the config option to be called. I'm thinking a top-level list `dns_redirect_ips: []`, but if there's another top-level section it should live under
<ajorg> I'm happy to entertain that notion.
<ajorg> Also, apologies for not upstreaming more of our (AWS) patches yet.
 * ajorg makes some excuse about being "busy" or something.
<ajorg> smoser: looks like the feature was your work? https://git.launchpad.net/cloud-init/commit/cloudinit/util.py?id=1bb67be5
<smoser> ajorg, i dont think i unerstand what 'dns_redirect_ips' would do
<smoser> (the bug is well written, and shows you've done homework, thank you)
<ajorg> Would set the global _DNS_REDIRECT_IP (or otherwise get that into the method) to the provided list, so that we can set it to an empty list to disable the feature.
<ajorg> smoser: it would be a slightly opaque way to disable the feature, but it would also add the ability for users to set that list.
<smoser> hm..
<ajorg> exactly the initial reaction i thought i'd get, which is why i thought i'd ask before proposing a patch
<smoser> yeah, and it'd mean that a config  module or somethign woudl have to set the value of that variable
<smoser> (and then each time cloud-init ran it would have to set it too).
<smoser> ie, that code doesnt have easy access to the full config
<ajorg> a bit ugly, for sure. i wasn't sure what you had in mind when you added the global.
<smoser> well the global is really just to keep it from being re-done on per call
<smoser> so you should only see 3 queries to your dns server, rather than N*3 in
<ajorg> ah, right... duh
<smoser>  results = [x for x in mynames if is_resolvable(x)]
<smoser> hmm.
<smoser> id ont have a good s olution of the top of my head.
<smoser> multiple things use is_resolvable, and generally its nice to protect against stupid dns hijacking even though it should not really ever be used in a "real cloud"
<ajorg> totally agree, just someone ran into this IDS problem
<ajorg> I can patch it to just disable the feature, but I'd rather not, now that our repositories are open for anyone to use outside of EC2 (since we made a public docker container of Amazon Linux).
<smoser> ids ?
<ajorg> intrustion detection system
<ajorg> apparently some of them alarm on suspicious DNS queries
<ajorg> and these (or at least the random ones?) can get flagged as suspicious
<ajorg> smoser: shall i pass in the list, and use the global if the passed parameter is None?
<smoser> well, where woul dyou change the callers ?
<smoser> in ec2 you probably hit that code in cloudinit/config/cc_apt_configure.py and cloudinit/sources/DataSourceEc2.py
<ajorg> all of the callers should at least have access to on-disk config (except _is_resolvable_url, but it can also take that parameter and pass it on)
<ajorg> it's also hit when deciding if it can talk to the instance metadata service, sadly
<smoser> and cloudinit/sources/DataSourceOpenStack.py even
<ajorg> yup
<smoser> so here is what i dont like...
<smoser> ubuntu makes images available for download on cloud-images.ubuntu.com
<smoser> if someone downloads that and uploads a new ami from it it should work well
<smoser> but you're telling me unless we changed the default value to not do this searching, then your IDS would flag an instance from that image.
<smoser> but if the image is used on some non-cloud, it makes good sense to have that.
<smoser> the end result of all of that above is i dont like "fix this by disabling it in specific cases"
<ajorg> EC2 doesn't have an IDS that alarms at customers, but some customers have their own.
<ajorg> So I'm totally fine with leaving this on by default, but some customers will need to be able to disable it.
<ajorg> Right now the only way to disable it is to patch the sources.
<ajorg> I'd like to provide a way to disable it from the on-disk config, so we can tell specific customers how to do that (and document it, of course).
<smoser> ok. thats more acceptable.
<ajorg> cool. sorry it wasn't obvious that's what i wanted.
<smoser> so as it is right now, i think we hit that code even if we pass an ip address in
<smoser> right ?
<ajorg> yeah, that's true
<smoser> we could make is_resolvable not do this if it is an ip address.
<smoser> which would mean that ec2's search and openstack's search would not do it.
<smoser> the  mirror searches still would
<ajorg> but making it skip IPs would make cloud-config user-data effective at controlling it
<ajorg> do you want a disable_it config or a i_know_my_redirect_ips config?
<ajorg> i'm confident either would satisfy my needs
<smoser> i think disable it would be better really.
<ajorg> k, i'll take another look at the code and try to come up with a proposal
<ajorg> might be a while as i'm juggling a few things (as always)
<smoser> larsks, https://code.launchpad.net/~larsks/cloud-init/+git/cloud-init/+merge/315276
<smoser> you see that just by running 'nosetests' ?
<larsks> smoser: I did, yes.
<smoser> really odd that i've never seen it.
<smoser> tox just runs nosetests
<larsks> If you'd like, I can write up a reproducer and add that to the lp issue.
<smoser> other than in a virtual env, and with 'python -m nose' but i was under the impression those were the same, and in ubuntu build process we use nosetests too
<smoser> you think its more than just a ordering thing ?
<smoser> i really do suspect its an issue, i'm just kind of wondering why i've never see it.
<larsks> I'm not sure.  Let me see if I can reproduce somewhere other than on my F25 system.
<larsks> Might be a couple of days, but I will update the lp issue with the results.
<powersj> would be interesting to see your CLI and versions.... https://paste.ubuntu.com/23853943/
<larsks> Will do.
<smoser> larsks, is that python27 or python3 ?
<larsks> That was python3, I think.
<smoser> i think probably we should be httpretty.activate decorating the individual test methods in tests/unittests/test_datasource/test_gce.py
<smoser> like tests/unittests/test_datasource/test_openstack.py and tests/unittests/test_ec2_util.py:
<smoser> rather than the class like is done in tests/unittests/test_datasource/test_gce.py
<smoser> Odd_Bloke, do you have thougths on above ?
<smoser> much of the httpretty stuff is currently blame'ing to you (just thats why i'm asking... blame in a git way,  not 'blame' in a bad way)
<smoser> hm.. and as i look further, 33e1f251 which basically changes to activating on the class.
<smoser> yeah, thats what does it... looking at the http pretty code
<smoser>  https://github.com/gabrielfalcao/HTTPretty/blob/master/httpretty/core.py#L1169
<smoser> larsks, well,, looking at that httpretty code, it sure looks like its trying to decorate individual methods
<smoser> so i can't explain how ou'd see this.
#cloud-init 2017-01-24
<Odd_Bloke> smoser: Yeah, I can't really understand it.
<Odd_Bloke> I'm not sure why the failure would only appear once, either.
<Odd_Bloke> It's not the only test that uses custom data.
<smoser> larsks, i think that fedora 24 (and i'm guessing 25) has a newer httpretty than is released on pypi (0.8.14).
<smoser> is that plausible ?
<larsks> smoser: I don't think so. I was running from a virtualenv (there is no httpretty package installed on my host).
<smoser> well that is odd.
<larsks> smoser: I'm going to work on reproducing et al this afternoon.
<larsks> Maybe my computer is insane.
<smoser> well, i see code in fedora24 that shows this
<smoser> and it definitely acts differently than pypi version
<larsks> If I were to install the python-httpretty package, I get 0.8.14-1.20161011git70af1f8, so that may be newer than pypi.  But I don't have that installed locally.
<larsks> (This is in F25)
<smoser> larsks, i updated bug. and opened an httpretty issue
<aixtools> quick question: as I do not know enough about python.
<aixtools> what actually gets started by python by:
<aixtools> #!/opt/bin/python
<aixtools> # EASY-INSTALL-SCRIPT: 'cloud-init==0.7.5','cloud-init'
<aixtools> __requires__ = 'cloud-init==0.7.5'
<aixtools> __import__('pkg_resources').run_script('cloud-init==0.7.5', 'cloud-init')
<aixtools> sorry for the multi-line. thought I had cut it down to the last line
<larsks> aixtools: that runs cloudinit.cmd.main:main (possibly /usr/lib/python2.7/site-packages/cloudinit/cmd/main.py)
<aixtools> so, in the sources - main.py
<larsks> Right.
<larsks> Specifically, cloudinit/cmd/main.py
<aixtools> thx very much.
<aixtools> single-step I go...
<ssalevan> hey there!  i was wondering if i could ask a quick cloud-init question; if I have an ec2 datasource, is it possible to template out some of that information into a file using the write_files module?
<magicalChicken> ssalevan: write_files just writes out specified content, it doesn't have a template system afaik
<magicalChicken> ssalevan: there may be other ways to achieve that though, which parts of the config do you need written out?
<ssalevan> magicalChicken: right now i basically need to stick eth0's private IP into a JSON configuration file
<magicalChicken> ssalevan: I don't know of a good way to handle that that's currently built in, althought someone else may
<magicalChicken> One option would be to write a script that handles that and runs after the eni has been written
<larsks> ssalevan: for the *private* ip, seems like you could as easily parse the output of 'ip addr'.
<larsks> And do that in a runcmd script or something.
<ssalevan> ah, good point, could just rig up a bash session
<ssalevan> well hey thanks much for your time y'all, much appreciated
<ssalevan> i was wondering if i could trouble you for one last question: i've packed up my user-data into a base64-encoded YANL, but cloud-init is returning the following error:  __init__.py[WARNING]: Unhandled non-multipart (text/x-not-multipart) userdata: '---\npreserve_hostname: f...'
<ssalevan> i suspect this may be related to a MIME typing issue
<larsks> ssalevan: why are you providing a base64-encoded yaml?  Why not just pass in the unencoded yaml?
<larsks> Also, does your userdata start with a "#cloud-config" marker? It doesn't look like it from that output...
<ssalevan> larsks: so when i try and send up the raw YAML user-data as part of a call to Amazon's RunInstances call, it returns an error that it was unable to encode into base64.  t
<ssalevan> ahhh that's probably it
<larsks> ssalevan: interesting.  I suspect my second comment is more relevant, yeah.
<ssalevan> larsks: that was totally it.  thank you so much!
<larsks> Glad it worked!
<smoser> larsks, thanks for helping ssalevan
<larsks> smoser: sure!
#cloud-init 2017-01-25
<larsks> smoser: if you're around, what is the thought behind having DefaultDependencies=no in cloud-init.service?  It turns out this this is causing cloud-init to start before dbus on fedora, so things like setting the hostname fall over.  The fix may be an explicit dependency on dbus.(service|socket)...
<smoser> larsks, 1 minute.
<larsks> (the root cause is that DefaultDependencies=no means there is no implicit dependency on basic.target)
<smoser> more than on minute.
<smoser> ok
<smoser> larsks, yeah, so we had issues with that too, starting before dbus.
<larsks> If we removed DefaultDependencies=no it would in theory Just Work.
<larsks> ...unless there was a specific problem that was meant to solve.
<smoser> well, no. then cloud-init is not running early enough in order to block netoworking.
<larsks> Ah, I see.
<smoser> theres a series of bugs, probably referenced in commits.
<smoser> let me look
<larsks> So you think an explicit dependency on dbus.service is probably the way to go.
<smoser> and this is, agreed, really a pita
<smoser> i dont think that will actually work. let me see.
<smoser> larsks, there isa lot of information in git log systemd/
<smoser> https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1629797 is what had us adding the dbus.socket
<larsks> Indeed, I've had to look at several of those.
<smoser> it was resolved.
<larsks> Looking...
<smoser> we could ask pitti for advice...
<smoser> he's the one who holds most knowledge in his head about systemd and aided in this slew of bugs.
<smoser> pitti works for rh now
<larsks> So https://git.launchpad.net/cloud-init/commit/?id=6e45ffb21e9622780585b4fe15890f009ca8fa71 added Bfore=dbus.socket, but that appears to have been removed by your commit e568aec31051674901047ee577f6e229785cbfc3
<larsks> I will bug pitti for thoughts.
<smoser> ask him to join here, nice to have conversation logged if we do have irc conversation.
<smoser> larsks, so you're suggesting
<smoser>  http://paste.ubuntu.com/23864232/
<smoser> righ t?
<larsks> Or After=dbus.socket, maybe, but yeah.  I'm going to test that later today and see if it corrects out issue.
<larsks> s/out/our/
<larsks> Well, that doesn't work:
<larsks> Breaking ordering cycle by deleting job cloud-init.service/start
<smoser> yeah, i saw that quickly in a lxd container (well, for some reason  journalctl doesnt show the error... but cloud-init.service did not run)
<rharper> larsks: we switched dbus for sysinit.target
<larsks> rharper: yes, I spotted that.
<rharper> typically, you need to run after dbus.socket (which is required for networkd/timesyncd) but before sysinit.target
<rharper> larsks: which fedora release?
<smoser> larsks, what is the ordering cycle that you see ?
<smoser> can you paste journalctl ?
<larsks> The problem we have is that we have Before=sysinit.target, which means we run before dbus.service.  But adding After=dbus.service results in an ordering loop: http://chunk.io/f/b9c11198c8c14c6b84dccec25cd1f3cc
<larsks> This is F25 right now, using cloud-init 0.7.9.
<larsks> Note that those log entries are what we get after adding After=dbus.socket to cloud-init.service.
<larsks> I can produce logs for other scenarios if you would like.
<rharper> larsks: yes, that sounds familiar, it should be ok to run before dbus.service; just not before dbus.socket;   we had to split the  gap so-to-speak;  we also have a resolv service that does libnss before dbus.service is up (which then resolv takes over)
<larsks> rharper: the point is that with After=dbus.socket results in the ordering loop.
<smoser> right, and larsks needs to run after dbus.socket so that he can update the hostname on the system
<rharper> yeah, we'll need to detangle that
<smoser> because obviously calling a kernel api should go through a user space daemon witih a dbus socket
<rharper> and something else may need a 'DefaultDependencies=no'
<smoser> well i think its just that you cant be before sysinit.target and after dbus.socket
<larsks> Right.
<larsks> But I'm still not clear on why we need defaultdependencies=no.  We have explicit ordering on most of the network stuff now, I think.
<smoser> if you drop defaultdependencies=no, then you get defaultdependencies
<smoser> which include sysinit.target
<smoser> i think
<larsks> Yeeeeeees.
<rharper> it's because default adds more deps that do not allow the correct ordering for placing befor networking
<larsks> rharper: do you know exactly what the problem is?  Because there are now explicit dependencies on serveral network units.
<larsks> Are those insufficient?
<rharper> it's the additional deps that push things with default deps further up in the cycle
<larsks> What do we hit if we come after sysinit.target?  Is there a test case that demonstrates an actual problem?
<rharper> we cannot block networking
<smoser> we so need better integration test. :-(
<smoser> its coming.
<larsks> I understand the problem is "we cannot block networking", but why, and why are the explicit Before= deps not sufficient to permit us to block networking?
<rharper> cloud-init local needs to be able to write out a network config
<rharper> they are
<larsks> rharper: sure, but this isn't about cloud-init-local
<rharper> but defaultdeps bring in *MORE* deps
<larsks> This is cloud-init.service.
<larsks> There is no problem with cloud-init-local having defaultpdeps=no
<smoser> i thinkt hat the issue is probably thatAfter sysinit.target (which is added unless you are Defaultdependencies=no) will mean that we run After dbus.socket
<rharper> which runs right before networking is considered online
<smoser> which, on ubuntu, with resolved , means dns queries block until timeout
<smoser> because resolved wasnt up but the socket was
<larsks> Since it doesn't sound like there is any evidence that defaultdeps=no is necessary, I'd like to produce some so that we can actually test things. smoser, what is a scenario that requires that we "block networking"...something passing in a static network config?
<larsks> I would like to find something that will fail somewhere (fedora/ubuntu/whatever) if I remove the defaultdependencies line.
<smoser> it is necessary
<smoser> other wise you run After=sysinit.target
<smoser> which is After=dbus.socket
<larsks> This discussion has developed an ordering problem :).  I am just asking for some sort of scenario that would demostrate the problem you and rharper have described.
<rharper> openstack boot
<larsks> But a normal openstack boot doesn't require cloud-init to do *anything* w/r/t networking.
<rharper> when cloud-init.service runs it will attempt to poke at network based metadata services
<smoser> right
<rharper> it can and usually does
<larsks> So it needs to run *after* networking in that case.
<smoser> and it will attempt dns lookup on the gce .internal  name
<rharper> but before it's online
<smoser> and that blocks
<rharper> a cloud may provide network configuration via metadata services
<larsks> rharper: I think I just missed a distinction there.
<rharper> so all other units that need network, run after 'network-online.target' is reached
<larsks> Ah, I see.  So in that case, you expect cloud-init to...bring up interfaces manually first, in order to contact the metadata service?
<larsks> I mean, how do the interfaces come up in that situation to permit access to the network metadata service, if we're running before the system brings up networking?
<smoser> hey, i'm really sorry, but ih ave got to work on some other things .
<rharper> smoser: np
<larsks> Yeah sure.  I just want to understand the problem we're trying to solve with these dependency settings.
<larsks> I also have other things I need to work on :)
<rharper> larsks: we use the hosts network service (so ifupdown or netword) a fallback network config (typically dhcp on first nic) is done
<larsks> But aren't those going to depend on, e.g., networkmanager already running?
<rharper> right
<rharper> but not reaching the network-online.target
<rharper> it's really threading a needle
<rharper> cloud-init is expected to do things iwth the network which could affect network-based services (like sshd host key gen)
<larsks> Hmmmm.  But we already have Before=network-online.target, right?
<rharper> we don't want sshd to be running (it runs after network-online.target is reached)
<larsks> So even if we exclude default dependencies, we're still okay.
<larsks> We also have Before=sshd.service
<rharper> what we really need is a list of default deps that get added unless you add DD=no
<larsks> I am pretty sure that means sysinit.target and basic.target.  But I suppose you mean you'd like the transitive deps in that case?
<rharper> then we can walk each of those to see if they order themselves after network-online.target or something else that forces cloud-init.service to run later than we need
<rharper> right, DefaultDeps is larger than just those two right ?
<larsks> No.  From systemd.service: Unless DefaultDependencies= in the "[Unit]" is set to false, service units will implicitly have dependencies of type Requires= and After= on sysinit.target, a dependency of type After= on basic.target as well as dependencies of type Conflicts= and Before= on shutdown.target.
<larsks> What exactly is implied by those depends on a lot on how other services are ordered w/r/t to basic.target and sysinit.target
<rharper> right, so the default deps of sysinit.target and basic.target make cloud-init.service run too late
<larsks> Maaaybe.  I've noticed that between ubuntu and rhel/fedora there are substantial differences in service ordering.  And even between fedora and rhel, I think.
<rharper> very likely
<rharper> the list of units and ordering is massively fragile
<larsks> So we still don't have a clear test case that demonstrates an actual problem.  It sounds like you are suggesting that an openstack config that passes in an explicit network configuration should help demonstrate one?
<larsks> I can try putting that together later this week.
<rharper> you don't even need a network config
<rharper> just use the default metadata service (ie, not a configdrive)
<rharper> in our case, if you run systemctl list-dependencies sysinit.target
<rharper> honestly; we can try moving it back in as well and see what breaks
<rharper> in general, it's such a mess that it gets paged out of my memory once things work as expected
<larsks> Yeah, the thing is, running cloud-init *after* network-online.target will work just fine in that case (since it doesn't need to touch the network config).
<larsks> Since networking is up, it will have no problem contacting the metadata service.
<rharper> right
<larsks> I am trying to produce a failure :)
<larsks> Speaking of paging things out, I should get lunch before my next meeting and the meeting after that.  I've also pointed pitti at the problem, although he's got devconf going on right now and may not be able to look at things until next week or so.
<rharper> cool
<rharper> smoser:  https://code.launchpad.net/~raharper/cloud-init/+git/cloud-init/+merge/315633
#cloud-init 2017-01-26
<powersj> magicalChicken: emailed Paul about pylxd merge 211... he just merged it :)
<rharper> nice
<magicalChicken> powersj: awesome, thanks for getting that merged. I may put together a ppa to build pylxd directly from the repo to test
<powersj> ok we should probably test that it does actually fix things :)
<ranger81> what is the best way to execute a cloud config file in ubuntu after instance is booted? For example, CoreOS has coreos-clouinit tool.
<Odd_Bloke> ranger81: cloud-init runs in all Ubuntu cloud instances, so should Just Work (TM).  Are you seeing problems?
<ranger81> @Odd_Bloke I want to run this on a already booted/provisioned node stand-alone. For example, if you have a cloud-config.yml, in CoreOS, you can run /bin/coreos-cloudinit --from-file cloud-config.yml to add users, write files etc. In ubuntu, there is /usr/bin/cloud-init, but this does not work same ways as CoreOS.
<Odd_Bloke> ranger81: Ah, OK, I misunderstood the "after instance is booted" to mean "immediately after". :p
<Odd_Bloke> I'm not sure how you'd get cloud-init to do that, perhaps smoser can help.
<ranger81> @Odd_Bloke @smoser I am thinking I should write a yaml parser in python and then execute necessary commands to add ssh-users for this. I am not sure if that is the best approach.
<smoser> ranger81, cloud-init doesn't really have function to do that at the moment.
<smoser> it is admittedlyuseful/desireable.
<smoser> you an run individual config modules with a config
<smoser> cloud-init --file=your.cfg single --name=users_groups --frequency=always
<smoser> so that is similar, but you have to know which config moduels to run
<ranger81> @smoser that helps.
<ranger81> @smoser where can I find list of supported modules that I can use in standalone mode like this? example users_groups
<ranger81> smoser: did not tag you in previous messages
<rharper> ranger81: AFAIK, all of the config modules support that; http://cloudinit.readthedocs.io/en/latest/topics/modules.html
#cloud-init 2017-01-27
<aisrael> I've recently started having issues with cloud-init on an ubuntu-trusty cloud image, on lxd. The cloud-init.log (http://paste.ubuntu.com/23873799/) seems to indicate the error is related to importer.py not being able to import the module 'ubuntu'. Any thoughts on how to fix this?
<aisrael> And /usr/lib/python3/dist-packages/cloudinit/ doesn't exist in the image
<aisrael> ok, so trusty has cloudinit installed for python2.7
<aisrael> I think that lib is a non-issue. It gets properly imported later. It does seem like cloud-init isn't fully running, though
<aisrael> the config and final modules don't seem to be running. I'm running them manually and it's doing what I expect
<aisrael> smoser: ^ when you're in
<smoser> aisrael, your log shows cloud-init init-local running
<smoser> oh i see. hm.. config and final are not running there.
<smoser> sorry, read your ocomment wrong.
<smoser> aisrael, possibly you do not have rsyslog ? or its not running ?
<smoser> aisrael, fwiw, i just launched a bare container, and it ran fine.
<aisrael> smoser, Yeah, it works on another machine for me. Lemme check rsyslog
<aisrael> smoser, it's installed. Where cloud-init seems to stop is before starting the ssh service
<aisrael> smoser, launching trusty in lxd works as normal. doing a juju add-machine, the container comes up in lxd, gets an ip, but stops after that
<smoser> /etc/init/cloud-config.conf
<smoser>  start on (filesystem and started rsyslog)
<smoser> it seems like you're getting cloud-init's other jobs fine
<smoser> so either filesystem or rsyslog would seem to be not getting reached
<aisrael> interesting! I'll start debugging from there. thanks, smoser
#cloud-init 2018-01-22
<mazzy> Hi there. I
<mazzy> https://gist.github.com/mazzy89/340dae524474ca01d4e8aa1ee6472598
<mazzy> I have this use case. any suggestion?
<kholkina> Hi! Does cloud-init update vendor-data on instance reboot?
<mazzy> does cloud-init overwrite an existing file if the file is created in write_files?
<ajorg> ï¼¼ï¼Â´ï¼¯ï½ï¼ï¼
<rharper> nice one
<blackboxsw> mazzy: yes, write_files will overwrite pre-existing files with content provided in your write_files section
<mazzy> blackboxsw thank you
<smoser> o/
<blackboxsw> morning alll
<blackboxsw> ok I think it's time for our bi-weekly meeting. probably going to be a short one this week.
<ajorg> more time for office hours then?
<blackboxsw> #startmeeting Cloud-init bi-weekly status meeting
<meetingology> Meeting started Mon Jan 22 16:08:22 2018 UTC.  The chair is blackboxsw. Information about MeetBot at http://wiki.ubuntu.com/meetingology.
<meetingology> Available commands: action commands idea info link nick
<blackboxsw> certianly ajorg :) (on office hours)
<blackboxsw> Welcome to another episode of cloud-init bi-weekly status. We'll chat about about cloud-init updates and in progress work, and we'l drop into office hours for ongoing discussions/bug work etc.
<blackboxsw> #topic Recent changes
<blackboxsw> Just walking through git-log for what we have committed in the last couple of weeks, here's the brief summary
<blackboxsw> thx smoser
<blackboxsw>    - shorten the message in the exception per powersj feedback
<blackboxsw>     - Use the same botocore session so the patched changes stick.
<blackboxsw>     - fix bad use of %
<blackboxsw>     - Fix console_log, improve comments and raise PlatformError on.
<blackboxsw>     - tests: Fix EC2 Platform to return console output as bytes.
<blackboxsw>     - tests: remove zesty as supported OS to test [Joshua Powers]
<blackboxsw>     - Do not log warning on config files that represent None. (LP: #1742479)
<ubot5> Launchpad bug 1742479 in cloud-init (Ubuntu) "setting manual_cache_clean causes warning" [Medium,Fix released] https://launchpad.net/bugs/1742479
<blackboxsw>     - tests: Use git hash pip dependency format for pylxd.
<blackboxsw>     - tests: add integration requirements text file [Joshua Powers]
<blackboxsw>     - MAAS: add check_instance_id based off oauth tokens. (LP: #1712680)
<blackboxsw>     - tests: update apt sources list test [Joshua Powers]
<blackboxsw>     - tests: clean up image properties [Joshua Powers]
<blackboxsw>     - tests: rename test ssh keys to avoid appearance of leaking private keys.
<ubot5> Launchpad bug 1712680 in maas-images "cloud-init re-generates network config every reboot overwriting manual admin changes on CentOS." [Undecided,New] https://launchpad.net/bugs/1712680
<blackboxsw>       [Joshua Powers]
<blackboxsw>     - tests: Enable AWS EC2 Integration Testing [Joshua Powers]
<blackboxsw>     - cli: cloud-init clean handles symlinks (LP: #1741093)
<ubot5> Launchpad bug 1741093 in cloud-init "cloud-init clean traceback on instance dir symlink" [Low,Fix committed] https://launchpad.net/bugs/1741093
<ajorg> What's being patched in botocore?
<blackboxsw> So a number of changes went into integration test related work, separating out requirements files.
<blackboxsw> MAASDatasource now also has smarted cache handling based on oauth token renewal from the maas server
<blackboxsw> so botocore is used by integration tests only as a mechanism to talk to the instance under test... looking back at the specifics here
<blackboxsw> it might have just been shuffling out how and where we define the dependency
<smoser> blackboxsw: (my 'paste' to you was bad... http://paste.ubuntu.com/26438113/ is better, showing only those on master, not my local branch that was currently checked out )
<blackboxsw> heh, oopsie daisy let's paste again inline then
<blackboxsw>     - tests: remove zesty as supported OS to test [Joshua Powers]
<blackboxsw>     - Do not log warning on config files that represent None. (LP: #1742479)
<blackboxsw>     - tests: Use git hash pip dependency format for pylxd.
<blackboxsw>     - tests: add integration requirements text file [Joshua Powers]
<blackboxsw>     - MAAS: add check_instance_id based off oauth tokens. (LP: #1712680)
<blackboxsw>     - tests: update apt sources list test [Joshua Powers]
<blackboxsw>     - tests: clean up image properties [Joshua Powers]
<blackboxsw>     - tests: rename test ssh keys to avoid appearance of leaking private keys.
<blackboxsw>       [Joshua Powers]
<blackboxsw>     - tests: Enable AWS EC2 Integration Testing [Joshua Powers]
<blackboxsw>     - cli: cloud-init clean handles symlinks (LP: #1741093)
<ubot5> Launchpad bug 1742479 in cloud-init (Ubuntu) "setting manual_cache_clean causes warning" [Medium,Fix released] https://launchpad.net/bugs/1742479
<ubot5> Launchpad bug 1712680 in maas-images "cloud-init re-generates network config every reboot overwriting manual admin changes on CentOS." [Undecided,New] https://launchpad.net/bugs/1712680
<ubot5> Launchpad bug 1741093 in cloud-init "cloud-init clean traceback on instance dir symlink" [Low,Fix committed] https://launchpad.net/bugs/1741093
<blackboxsw> ok the real deal, that looks better
<blackboxsw> ahh ajorg that interim commit message on botocore was about integration tests caching the session information during testing so we don't recreate that session with every ssh connection to the instance
<blackboxsw> just a little time savings per review comments on powersj branch I believe
<ajorg> okay, so nothing that needs to get upstreamed to botocore?
<blackboxsw> I don't think so, powersj smoser I have vague recollection of someone filing an upstream botocore issue. did we have to do that for something else though?
<powersj> https://github.com/boto/botocore/issues/1351
<powersj> that was the issue smoser put in ^
<blackboxsw> nice recall powersj thanks.
<blackboxsw> #link https://github.com/boto/botocore/issues/1351
<smoser> ajorg: you can read that bug.  imo they have a data loss error, but not one that they can easily fix without causing failures in places that previously ran fine.
<ajorg> I'll ask them to re-open it.
<ajorg> At the very least they should answer your last.
<smoser> thanks.
<blackboxsw> Generally anything significant that we have landed (and any inprogress work) should be available at the following link.
<blackboxsw> #link https://trello.com/b/hFtWKUn3/daily-cloud-init-curtin
<blackboxsw> anything else we should note over the last couple weeks?
<blackboxsw> otherwise I'll switch to ongoing work topic
<blackboxsw> #topic In-progress Development
<blackboxsw> As you may have seen last week, we've gotten through a few passes and discussions around dojordan's branch to define pre-provisioning
<blackboxsw> #link https://code.launchpad.net/~dojordan/cloud-init/+git/cloud-init/+merge/334341
<blackboxsw> some of that discussion resulted in a new context manager: EphemeralDHCPv4 to support a sandboxed dhclient request on an instance.
<blackboxsw> this context manager affects Ec2 datasource a bit as it encapsulates all of the dhcp request -> EphemeralIPV4Network calls that Ec2 was doing
<blackboxsw> there may be a couple other datasources that follow suit with this type of sandboxed dhcp request in weeks to come
<ajorg> glad it turned out to be generally useful rather than only specifically to ec2
<blackboxsw> absolutely
<blackboxsw> Some other in-progress bits look like we might try focusing a bit more on chrony support and gettting robjo's branches some more eyes.
<blackboxsw> and some work on Ubuntu snappy support per the snappy and snap config modules.
<smoser> dojordan: i just put one comment on your mp. /me thanks dojordan again for his patience.
<blackboxsw> rharper: smoser powersj anything more in the immediate pipeline that I'm missing/
<blackboxsw> ?
<smoser> blackboxsw: we should get the EphemeralDHCP thingy into the digital ocean datasource also.
<rharper> blackboxsw: a reply to the network discussion on the list from the azure folks and robjo
<ajorg> I took another look at https://code.launchpad.net/~yeazelm/cloud-init/+git/cloud-init/+merge/331897 and saw that origin/master seems to be failing some of the integration tests too.
<ajorg> (at least for me, locally, on a 16.04 instance)
<blackboxsw> ahhh right forgot about all your work there rharper, thanks!
<smoser> ajorg: https://jenkins.ubuntu.com/server/view/cloud-init/job/cloud-init-ci-nightly/
<smoser> that is nigytly run of trunk
<blackboxsw> #link https://jenkins.ubuntu.com/server/view/cloud-init/job/cloud-init-ci-nightly/
<ajorg> I'll try blackholing IMDS on my instance. Could be that's interfering with something.
<smoser> it is red, but 218 (green) and 219 (red) used the same git has on trunk (5cc0b19b8).
<ajorg> I'll follow up during office hours
<smoser> can you give me example of your failures ? we had "disk full" errors recently on our jenkins, so that might be the cause of the issue for 291.
<smoser> s/291/219/
<blackboxsw> I don't remember seeing that traceback recently. w/ warning messages present in cloud-init
<smoser> powersj: ? can you explain lxc timeout failure at
<smoser>  https://jenkins.ubuntu.com/server/view/cloud-init/job/cloud-init-ci-nightly/219/consoleFull
<powersj> smoser: we discovered that our qemu-migration test was installing lxd from the archive and causing conflicts with the snap installed lxd
<powersj> I have a message to christian to prevent it, and I have already cleaned it up
<powersj> so new runs should pass
<ajorg> 2018-01-22 16:19:03,550 - tests.cloud_tests - WARNING - test case: modules/ssh_import_id failed TestSshImportId.test_no_stages_errors with: AssertionError: 1 != 0 : errors ['(\'ssh-import-id\', ProcessExecutionError("Unexpected error while running command.\\nCommand: [\'sudo\', \'-Hu\', \'ubuntu\', \'ssh-import-id\', \'gh:powersj\', \'lp:smoser\']\\nExit code: 1\\nReason: -\\nStdout: -\\nStderr: -",))'] were encountered in stage m
<smoser> hm.. well, that will hit launchpad.net over https
<smoser> cloud-init-output.log probaly has more info (should be collected)
<powersj> the actual error is:   File "/var/lib/jenkins/slaves/torkoal/workspace/cloud-init-ci-nightly/tests/cloud_tests/platforms/instances.py", line 142, in _wait_for_system
<powersj>     raise OSError('timeout: after {}s system not started'.format(time))
<powersj> it is because when the qemu tests installed lxd it didn't initialize lxd networking
<powersj> so no IP is received
<smoser> ajorg: would you have had outbound access to launchpad https ? if not, then that'd be expected failure.
<smoser> oh, and i guess 'gh:powersj' (github)
<ajorg> smoser: I'll check some things, but in short yes. Maybe lxc is being weird?
<smoser> i dont like our user names in that test though...
<powersj> smoser: we could use the bot instead
<ajorg> smoser: it's a public ec2 instance with no special outbound rules, and I can connect to public https sites from a normal session.
<blackboxsw> hrm, ok let's chat about what we can do to anonymize or drop that type of test data if we can
<blackboxsw> probably time to kick over to office hours
<blackboxsw> #topic Office Hours (next 30 minutes)
<smoser> powersj: well, i think i'd prefer some public key that we state "no one has the private key for this."
<smoser> obviously we could lie about that, but one would *expect* that you and I would gain access to the system using our public keys.
<smoser> it doens't make me feel a lot better that a bot could/can.
<ajorg> Is there a way to limit integration testing to a specific test?
<blackboxsw> Feel free to bring up any topic/bugs/branches/features you'd like discussion on. We can also continue our discussion on the ssh key imports in teting
<ajorg> (takes a long time to run the full suite)
<blackboxsw> ajorg: yes
<blackboxsw> (reverse-i-search)`cloud_t': python3 -m tests.cloud_tests run --os-name=artful --platform=nocloud-kvm --preserve-data --data-dir=../results --verbose -t modules/locale -t modules/set_password
<ajorg> thanks, that should help
<blackboxsw> ajorg: you can specify the test names (like modules/set_password) and modules/locale  in this test
<blackboxsw> yeah those are short ones I frequently test with
<smoser> http://paste.ubuntu.com/26438334/
<smoser> that is what i use. and yeah... we've discussed that integration test could be easier to run :)
<blackboxsw> #link http://paste.ubuntu.com/26438334/
<blackboxsw> nice 1
<blackboxsw> smoser: to have a public key we know nobody has a private key for would that mean we'd need a separate github account (or maybe just an additional key associated w/ our bot account in gh
 * blackboxsw checks github for authorizing multiple keys.
<blackboxsw> hrm, that wouldn't work as we need gh:ubuntu-server-bot   (one key) n/m
<ajorg> I've got meetings most of today, so I'll have to follow up later. thanks everyone!
<blackboxsw> thanks ajorg
<blackboxsw> so, bot account for the time being is better than powersj owning the testing world ;)
<blackboxsw> but I'm not too concerned about it as this are supposed to be throw away instances
<blackboxsw> but I'm not too concerned about it as there instances under test are supposed to be throw away instances
<blackboxsw> *these instances*.... anyway
<smoser> blackboxsw: right. it would require users on both those services .
<blackboxsw> alrighty. think we're at the close of office hours. Last call?
<blackboxsw> Thanks for your time and contributions to cloud-init folks!
<blackboxsw> #endmeeting
<meetingology> Meeting ended Mon Jan 22 17:16:43 2018 UTC.
<meetingology> Minutes:        http://ubottu.com/meetingology/logs/cloud-init/2018/cloud-init.2018-01-22-16.08.moin.txt
<rharper> blackboxsw: thanks
<blackboxsw> np, just posting the notes to cloud-init.github.io now
<smoser> https://hackmd.io/OwBgpgxgRlwIwFooBMBMAzBAWYECcCAHIbgtIXgGyEDMIElcEQA=
<smoser> blackboxsw, powersj rharper . i just put that together in order to go fresh system to functional "test my branch".
<smoser> mainly for ajorg's request of "does trunk work".
<blackboxsw> reading
<rharper> smoser: -t <release> is super fancy sauce
 * rharper has learned something new for tday 
<blackboxsw> is it worth folding a bit of that into readthedocs content for cloudinit? I'm not sure where to 'host' that info (as it's a good top-level view)
<blackboxsw> yet it references tools that aren't cloudinit proper
<powersj> smoser: why not use lxd via snap?
<powersj> that way those instructions are not tied to xenial
<smoser> well, i first tried not getting a new one.
<smoser> just using what was in the image.
<smoser> but something failed... a container didnt get an IP address.
<smoser> so i thought "ok, just get something newer".
<smoser> apt still seems easier and since we already reference other apt thhings, seems just easier to recommend apt
<smoser> and i honestly didnt know how apt-installed versus snap installed get a long
<smoser> rharper: you can also
<smoser>  apt-get install lxd/xenial-backports
<powersj> ok
<powersj> also someone could use tree_run to build their local tree and run the tests all in one
<smoser> yeah, i knew there was something for that.
<smoser> i'm fine to change that.
<smoser> but "how to build a deb" seems useful doc anyway. and as it is right now it already recommended installing all these deps
<smoser> so... might as well use them. rather than launching a container and putting them in there.
<rharper> smoser: also nifty
<smoser> along the way i find
<smoser>  http://paste.ubuntu.com/26438886/
<smoser> :-(
<powersj> goodness
<rharper> smoser: so, according to this: https://github.com/systemd/systemd/issues/2912  and just verifying this in bionic;  systemd-networkd (configured via cloud-init/netplan); on ip link set down, the networkd v4 dhcp client will re-acquire leases;  that's certainly new behavior w.r.t say xenial/ifupdown (confirming that now in a xenial image)
<rharper> s/set down/set down; set up/
<rharper> appears that dhclient does this just fine as well;
<smoser> rharper: ? you're saying that isc-dhcp does that ?
<smoser> powersj: ubuntu@ec2-18-218-147-181.us-east-2.compute.amazonaws.com
<smoser> there is failure there right now on ntp test.
<smoser> $ time ./tools/tox-venv citest python3 -m tests.cloud_tests run -v         --os-name=xenial         --preserve-data --data-dir=/tmp/results.short.d --test tests/cloud_tests/testcases/modules/ntp_servers.py
<smoser> i'm looking at it.
<rharper> smoser: yeah, what's in xenial appears to bring the interface back up.
<rharper> ah, but routing info isn't updated
<rharper> lemme compare that to networkd
<smoser> rharper: you're saying if i run:
<smoser>  ip link set eth0 down
<smoser> that something will magically bring it back up?
<smoser> i dont see that in a container here.
<rharper> no, that bouncing the link state will restore the connectivity
<rharper> the unplug (set down); and replug (set up) restores interface config (but not routing in isc-dhclient);  in networkd, I can see the networkd dhclient require a lease and apply it
<smoser> rharper: well, in isc-dhcp its not so much that it "restores interface config", its just that nothing removed that config. so putting it back up keeps it.
<smoser> but the routes get dropped and do not get restored.
<smoser> are you suggesting that 'link set down eth0' is the same thing as if the hypervisor pulled the cable ?
<rharper> yeah, just walking through the link state change so we can capture what does an does not work here w.r.t the need for something
<rharper> that's what the azure email is suggesting, that they can toggle the link state
<rharper> you can look at the code they posted which watches the interface oper/link state and , I think to work around the isc-dhcp client not updating the route-interface, lauches another dhclient instance
<rharper> yeah, under networkd; it does bring the route for the bounced interface back up;
 * smoser wishes ajorg would show up.
<dojordan> @smoser, I answered your comment. During the re-init of the EphemeralDHCPv4 context manger we do actually want to look for the fallback nic again. It shouldn't change names but if it does we would never find it if we only run find_fallback_nic once.
<smoser> dojordan: it wont change names. and you'd see different errors for sure if it did.
<smoser> i handt considered the nic getting renamed ... its a bug if it does get renamed under us
<smoser> but i had considered only another nic coming online
<smoser> look once... first nic is eth1
<smoser> look again, first nic is eth0
<rharper> smoser: once we've renamed it, the specific nic cannot get renamed by udev; it would have to be some other program ding that
<smoser> when do we rename ?
<dojordan> us being cloud init, or ubuntu?
<rharper> in local netconfig, apply_nic_names
<smoser> in the init (non network) no renaming has taken place.
<smoser> rharper: yeah, we're runnign before that here.
<dojordan> got it, so during local we can assume it wont change
<rharper> I think it happens before networking stage otherwise the network config can come up
<dojordan> ?*
<smoser> dojordan: in this case "us" == cloud-init.
<rharper> smoser: are we "paused" before stages calls apply_network_config() ?
<smoser> dojordan: we're kind of all sorts of foobarred if other things are changing nic names on is.
<smoser> at that point.
<smoser> the pause for IMDS (polling netwokr metadata)  is before we have rendered fallabck networking.
<dojordan> but what's the harm of looking for the fallback nic multiple times? It is up to the caller (of the context manager) to decide
<smoser> happening all in cloud-init.lcoal ("pre-network")
<smoser> dojordan: i just think it'd be harder to figure it out. and opens up a failure case.
<smoser> boot, dhcp on eth0, hit MD, poll a bit...
<smoser>  then get a 404
<smoser> dhcp accidently on 'anic0'
<dojordan> 404 won't call find_fallback_nic
<smoser> and then dead
<dojordan> or dhcp or anything
<smoser> i thought it was 404 that caused it to re-try dhcp
<dojordan> only non 200-299 / 400 or unhandled exception (timeout, socket error, etc)
<smoser> but whatever it is that causes that re-try dhcp. if the second time it goes off on amnother nic, then we're done.
<dojordan> nope, 404 means we hit the metadata server, but nothing is available for us yet
<dojordan> " if the second time it goes off on amnother nic, then we're done." - why
<smoser> i assumed that only one nic is connected to the network that has the MD on it.
<smoser> if all of them are, and a dhcp on any would be sufficient, then you're right.
<smoser> but it still is odd.
<smoser> to use one nic, and then use another the next time.
<dojordan> so question, if we unplug a nic and plug it back in from hyper-v, we would need to guarantee it will keep the iface name
<dojordan> otherwise i am fine with that change
<dojordan> err, assuming disconnect / connect doesnt change the name
<smoser> oh right. i'd forgot that you might do that.
<smoser> disconnect as in "pull the cable" ?
<smoser> or as in "pull the nic"
<smoser> pull the cable wont rename.
<smoser> pull the nic, maybe.
<smoser> dojordan: so... will all nics ever plugged into the system e able to reach the MD if they dhcp ?
<smoser> ie, is taht a feature of the platform ?
<dojordan> I will confirm with the team doing that work. don't want to assume yes but i think so
<smoser> dojordan: http://paste.ubuntu.com/26440131/
<smoser> what do you think about that ?
<smoser> if i *did* get some debug messages there, that'd clearly lindicate what nic we were using.
<dojordan> I like it. sounds good to me. I'll fix some indentation errors too
<smoser> :)
<dojordan> @smoser, pushed, running to lunch. Take a look when you get a chance
<smoser> https://code.launchpad.net/~smoser/cloud-init/+git/cloud-init/+merge/336458
<smoser> that took longer than it should have to diagnose.
<powersj> hmm ci isn't happy again
<dojordan> seems like some lxd issue
<powersj> I'm looking at it
<dojordan> thanks
<powersj> dojordan: run is looking better this time. sorry about that
<powersj> we had some lxd issues over the weekend where another project's tests messed with the config
<blackboxsw> hrm hitting timeouts while pulling packages in ec2 testing the ec2 ntp fix Failed to fetch http://us-east-2.ec2.archive.ubuntu.com/ubuntu/pool/main/n/ntp/sntp_4.2.8p10+dfsg-5ubuntu3.1_amd64.deb  504  Gateway Time-out [IP: 52.15.107.13 80]
<smoser> hey.
<smoser> to get this out of my buffer on a ec2 system
<smoser>  http://paste.ubuntu.com/26440452/
<smoser> pylxd returns string not bytes from execute.
<smoser> joy
<smoser> so i tried to have it collect systemd  journal, but can't.
<smoser> i'll file bug on pylxd tomorrow.
<smoser> we can work around by lxc cmdline as shown in that paste.
<dojordan> Thanks for restarting @powersj. @smoser, anything else, or can we ship it?
#cloud-init 2018-01-23
<ahasenack> what's the minimal cloud-init config to just specify the ssh public key for the default ubuntu user?
<ahasenack> system_info -> default_user -> ssh-import-id: foo?
<ahasenack> ok, found a way, just needed to specify user ubuntu again and override what I wanted
<smoser> ahasenack: you can just do:
<smoser> ssh_authorized_keys:
<smoser>  - ssh-rsa AAAA...H5qV7NZ mykey@host
<ahasenack> smoser: under "users->name: ubuntu", right?
<smoser> well you can put it there.
<smoser> but you dont need to.
<smoser> top level applies to default user
<ahasenack> ah, good to know
<ahasenack> does that work for "shell: /bin/bash" too?
<ahasenack> or that one has to be under a user
<smoser> no. that has to be in user
<ahasenack> ok
 * smoser didn't know that ahasenack was a elite shell user.
<smoser> zsh? or maybe he just loves the old school ksh
<ahasenack> what's yours, zsh?
<ahasenack> ksh!
<smoser> i jsut use bash.
<smoser> wow. ksh.
<ahasenack> I use bash too, that's what I'm setting it to
<smoser> i dont think i've ever seen someone not previously employed by ibm that  used ksh.
<smoser> rharper: on  my desktop i do not have /run/log/journal/
<smoser> what creates /run/log/journal/*/system.journal ?
<rharper> journald
<rharper> did you persist your systemd journal  ?
<rharper> smoser: you probably did, so it's /var/log/journal
<rharper> I did that on diglett which does not have a /run/log/journal, but /var/log/journal
<smoser> rharper: ok. so it will either go to /run/log/journal/<something>/ or /var/log/journal?
<rharper> yeah
<rharper>  /var/log/journal/<something>
<rharper> if you mkdir /var/log/journal and run a command that tells journald to use a persistent directory instead of /run
<dojordan> @smoser, are we good to land my MP?
<smoser> dojordan: yes. and i'd like to get that uplaoded to bionic sooner than later.
<dojordan> awesome! I assume you do the red button pressing?
<smoser> dojordan: yeah.
<smoser> i'll get uploaded today i hope.
<smoser> meged and uploaded.
<dojordan> great, thanks!
<smoser> blackboxsw: https://code.launchpad.net/~penick/cloud-init/+git/cloud-init/+merge/335286
<smoser> i can't think of a reason to not pull that
<blackboxsw> reviewing
<blackboxsw> oops missed that one
<blackboxsw> I recall reading it, just never committing to the review
<blackboxsw> ohh right no CLA, yeah I didn't have a concern with it. will officially  accept :)
<blackboxsw> approved
<blackboxsw> want me to land it?
<smoser> blackboxsw: sure
<blackboxsw> ^ == more testing of review-mps script
<smoser> powersj: can i easily run a jenkins ec2 on https://code.launchpad.net/~smoser/cloud-init/+git/cloud-init/+merge/336366
<smoser> works in my local gtest
<powersj> I only have jenkins jobs for ec2 on master
<blackboxsw> smoser: we have 4 approved branches now in cloud-init review queue. Can I land all of them?
<smoser> yeah.
<smoser> powersj: you think its enough for me to just run that branch ec2 once on a few tsets ?
<smoser> and then merge ?
<smoser> blackboxsw: please do land all those. yeah.
<powersj> smoser: that is fine by me
<smoser> blackboxsw: qa-scripts/launch-ec2
<smoser> quick review?
<smoser> http://paste.ubuntu.com/26446608/
<smoser> creates help  like: http://paste.ubuntu.com/26446617/
<blackboxsw> +1 smoser  yeah instead of invalid help text/ thx for the additional logging info on zone (was lacking that on my last deploy/test attempt)
<blackboxsw> land away. and land anything you like in there as you see it. I'll do the same. if we break something we can fix it up as we use it
<smoser> since there are ~95000 different types on ec2, i didn't put them all there.
<smoser> and didn't use choices (as is done in the softlayer one)
<blackboxsw> smoser: did the following branch close all four of those related gce bugs https://code.launchpad.net/~illfelder/cloud-init/+git/cloud-init/+merge/334777?
<blackboxsw> I'm trying to verify now
<blackboxsw> and oops commit message didn't contain the bug references
<smoser> blackboxsw: that commit message does need work.
<smoser> updating
<smoser> :-(
<smoser> i can update now
<blackboxsw> grr yeah
<blackboxsw> need a force push
<blackboxsw> saw that too late
<smoser> just reset --hard HEAD
<smoser> and force push now
<smoser> HEAD^
<blackboxsw> force pushed it out
<blackboxsw> will repush once commit message is fixed.
<smoser> blackboxsw: please read.
<blackboxsw> lgtm
<smoser> blackboxsw: i'll come back in in 3 or 4 hours
<smoser> and will upload to ubuntu whatever you have in trunk at that point
<smoser> feel free to grab https://code.launchpad.net/~smoser/cloud-init/+git/cloud-init/+merge/336497
<smoser> i'll just upload whateve ryou have in trunk
<smoser> https://code.launchpad.net/~smoser/cloud-init/+git/cloud-init/+merge/336366
<smoser> that one too
<smoser> and /me out
<smoser> later
<blackboxsw> smoser: will do, I'm fixing dojordan's commit message to reflect retries etc instead of infinite loops etc.
<dojordan> (thanks)
<blackboxsw> dojordan: does the updated commit message look ok https://code.launchpad.net/~dojordan/cloud-init/+git/cloud-init/+merge/334341 ?
<blackboxsw> just let me know if you have any changes (or not) and I'll merge away
<blackboxsw> dojordan: saw a join/logout drop IRC message
<blackboxsw>  dojordan: does the updated commit message look ok https://code.launchpad.net/~dojordan/cloud-init/+git/cloud-init/+merge/334341 ?
<blackboxsw> 3:49 PM just let me know if you have any changes (or not) and I'll merge away
<blackboxsw> New messages since you tabbed out
<dojordan_> was actually about to reply
<dojordan_> technically it is an infinite polling loop assuming we are getting 404s from IMDS, but we will only retry DHCP a max of 5 times
<dojordan_> technically a VM can be in this polling state for a long time (day or two)
<dojordan_> also @blackboxsw, what time zone are you in?
<blackboxsw> dojordan_: Mountain, still have an hour before I go poof.
<dojordan_> ah, that explains how 3:49 PM is in the future
<blackboxsw> thx for the correction, I had forgotten about the exception_cb  behavior
<blackboxsw> ok will revert that part but wanted to keep the reference to EphermeralDHCPv4 so we can look back easily on commit history when pushing this functionality to other clouds
<blackboxsw> s/clouds/datasources
<blackboxsw> dojordan_: updated one last time. https://code.launchpad.net/~dojordan/cloud-init/+git/cloud-init/+merge/334341
<dojordan_> lgtm
<blackboxsw> ok waiting on one last azure instance boot  on my side..... will merge in 10 mins
<blackboxsw> dojordan_: on bionic with your changeset. my azure machine doesn't come back up on reboot. I can run "sudo cloud-init clean --logs --reboot" with your deb installed. This reproduces a fresh-install test. It seems my instance doesn't come back up..... I'm trying to see what gives now as I thought all IMDS polling was based on present of a /var/lib/cloud/data/poll_imds file.
<blackboxsw> hrm, I know this was working on earlier commits within your branch.
<dojordan_> it shouldn't even create the file in the first place since the ovf_env.xml on the ISO doesn't contain that flag
<blackboxsw> and from my understanding you wouldn't even be providing the flag to turn that file on anyway....
<blackboxsw> ^ right
<dojordan_> exactly
<dojordan_> did you create the marker file?
<dojordan_> before rebooting?
<dojordan_> also do you have serial logs?
<blackboxsw> I hadn't in this case, it was a fresh install. but grabbing logs now
<blackboxsw> hrm I hadn't enabled boot diagnostics on this instance which I think captures serial log right? trying another deployment (without this branch) to make sure my "cloud-init  clean" on tip of master doesn't actually break Azure anyway
<dojordan_> it actually might
<dojordan_> because once we remove the ISO (after we report ready), how will the VM get the ovf_env
<dojordan_> also, if you can get me the deployment ID and subscription id I can grab the logs for you
<blackboxsw> ok just validated the released version of cloud-init in bionic can cloud-init clean --logs --reboot on azure and come back freshly installed.
<dojordan_> hrm
<blackboxsw> and tip of master works too 17.2-18-gd14fa1a2-1~bddeb
<blackboxsw> so 17.2-13-g6299e8d0-0ubuntu1 (published version) is good too.
<blackboxsw> will grab deployment id now
<blackboxsw> before I upgrade to your branch
<blackboxsw>   "id": "/subscriptions/12aad61c-6de4-4e53-a6c6-5aff52a83777/resourceGroups/srugrp10/providers/Microsoft.Compute/virtualMachines/my-b3",
<dojordan_> great
<dojordan_> I'll start diggiung
<blackboxsw> I'll also add your ssh account to my instance if you like
<dojordan_> i thought it didn't come back up
<blackboxsw> ssh ubuntu@40.70.56.77
<blackboxsw> dojordan_: I deployed a fresh vm
<dojordan_> ah
<blackboxsw> to test tip and published versions too
<blackboxsw> so I'm about to install a deb made from your branch on it
<blackboxsw> fell free to connect to my shared term with 'byobu' dojordan
<blackboxsw> feel free*
<blackboxsw> ok new cloud-init installed from your branch, no marker  file present
<blackboxsw> last cloud-init run worked fine
<dojordan_> @blackboxsw, not sure if i can type in your shared term but sounds good
<blackboxsw> ok so we're kicked for a fresh install now
<blackboxsw> s/install/cloud-init run/
<blackboxsw> what should happen is subsequent ssh connections to the same IP will present us with an ssh key error (key has changed on new cloud-init run)
<blackboxsw> this happens within about 30 seconds on my last two attempts (with tip and published version of cloud-init in bionic)
<dojordan_> i assume my ssh key wont be there, so my connection refused makes sense
<dojordan_> yours?
<dojordan_> yours?
<blackboxsw> correct. your's shouldn't exist again.... but I'm getting no response yet
<blackboxsw> from  ubuntu@40.70.56.77
<blackboxsw> though azure portal says it's up
 * blackboxsw checks the cli
<blackboxsw> ssh: connect to host 40.70.56.77 port 22: Connection timed out
<dojordan_> https://paste.ubuntu.com/26447610/ (logs from bionic3)
<blackboxsw> meh: az vm boot-diagnostics  get-boot-log --ids /subscriptions/12aad61c-6de4-4e53-a6c6-5aff52a83777/resourceGroups/SRUGRP10/providers/Microsoft.Compute/virtualMachines/my-b3
<blackboxsw> Please enable boot diagnostics.
#cloud-init 2018-01-24
<blackboxsw> hrm... ok seeing we get through cloud-init modules:config stages which means the datasource succeeded
<blackboxsw> hrm have to step away a bit. sorry for the moment dojordan_ will check it out
<blackboxsw> I'll have something on this later
<blackboxsw> sorry I should have tested this again this morning
<dojordan_> no worries
<dojordan_> one thing would be great if you could do, would be to change logging level so we can see more info on the serial port
 * blackboxsw clicks enable boot diagnostics logging in the UI and clicks reboot on this instance
<blackboxsw> and bailing for dinner
<dojordan_> same problem on artful
<blackboxsw> smoser: just pushed a merge proposal into bionic for today. I need a bit more time to triage what gives on Azure :/
<blackboxsw> https://code.launchpad.net/~chad.smith/cloud-init/+git/cloud-init/+merge/336513
<blackboxsw> ok I'm out for the night. gotta do the bedtime routine with the kiddos. more on azure first thing in my morning
<dojordan_> thanks for all the help, sounds good
<smoser> blackboxsw: fudge
<smoser> https://jenkins.ubuntu.com/server/job/cloud-init-ci/725/console
<smoser> :-(
 * smoser fail
<smoser> i'm fixing and pushing. http://paste.ubuntu.com/26448094/
<smoser> rharper, powersj blackboxsw if you're still around, to disagree or +1 that.
<rharper> looking
<smoser> running tox + centos build && git push upstream HEAD
<rharper> looks sane
<smoser> thakns
<rharper> btw, it's a royal pain to launch multi-subnet/ip instances via the console;  also it would be of great help if the ec2 docs would tell you what the format of the instance data is, for example local-ipv4s is a list of some sort of ipv4 addresses;  but is it comma separated, newline, space?  I can't find any examples with my google-fu so trying to get an instance up to check
<rharper> *finally*
<rharper> vpc is timeconsuming
<blackboxsw> hab
<blackboxsw> bah
<blackboxsw> resubmitting  the merge proposal
<blackboxsw> with a new snapshot from master
<rharper> ok, have crude ec2 network metadata to v1 config
 * rharper calls it a night
<blackboxsw> nice
<blackboxsw> ok new MP against bionic up. thanks for the fix smoser
<blackboxsw> https://code.launchpad.net/~chad.smith/cloud-init/+git/cloud-init/+merge/336514
<smoser> blackboxsw: on azure...
<smoser> you there?
<smoser> dojordan_: west coasters.
<smoser> (they stay up  late.. https://finance.yahoo.com/news/exclusive-fitbits-6-billion-nights-sleep-data-reveals-us-110058417.html )
<blackboxsw> here
<blackboxsw> :)
<blackboxsw> ok azure triage time
<dojordan_> here now @blackboxsw
<blackboxsw> good to know you come to work at a reasonable time like the rest of us :) I'm walking through failure path again, as smoser surmised it's likely the cdrom disappearing on us before I cloud-init clean --reboot.... so I'm adding logs etc now and going through that to confirm
 * blackboxsw wasn't sure yet why this seemed to work with tip  of master though too. 
<dojordan_> hmm, interesting idea. doesn't waagent copy the ovf_env.xml off of the cd ?
<dojordan_> FWIW we remove the CD as soon as we get a provisioning message
<dojordan_> question, shouldn't we be keeping around the ovf-file before rebooting?
<dojordan_> i think clean --reboot deletes it
<dojordan_> err, nvm, it lives in /var/lib/waagent/ovf-env.xml
<dojordan_> @blackboxsw, same problem on xenial
<smoser> dojordan_: i had asked blackboxsw to edit /etc/cloud/cloud.cfg.d/05_logging.cfg and change the console logging from WARN to DEBUG
<smoser> and then collect console log
<smoser> are you able to easily do that too ?
<dojordan_> yeah
<smoser> dojordan_: for boot diagnostics
<smoser> which storage account type do you need ?
 * blackboxsw is already mid reboot/test on  my bionic instance with debug console logs enabled, an azure storage account created and
<blackboxsw> boot logs enabled
<blackboxsw> ubuntu@40.70.46.88
<smoser> ssh-import-id smoser ?
<blackboxsw> checking boot logs now to make sure cloud-init reported correctly on this last clean boot
<blackboxsw> already done for dojordan and smoser
<blackboxsw> i'm in byobu term
<smoser> permission denied
<smoser> in
<blackboxsw> added agin
<blackboxsw> must've typod
<dojordan_> denied
<smoser> try again
<dojordan_> cool
<blackboxsw> ok let's see here..... cehcking azure cli now to make sure I could see boot logs
<blackboxsw> before rebooting
<dojordan_> worst case i can always get them :)
<blackboxsw>  az vm boot-diagnostics  get-boot-log --ids /subscriptions/12aad61c-6de4-4e53-a6c6-5aff52a83777/resourceGroups/SRUGRP10/providers/Microsoft.Compute/virtualMachines/my-b1
<blackboxsw> 'ascii' codec can't decode byte 0xe2 in position 40610: ordinal not in range(128)
<blackboxsw> hrm oops az cli
<blackboxsw> checking UI
<blackboxsw> serial log in UI is working for me
<blackboxsw> ok
<blackboxsw> old log
<blackboxsw> http:pastebin.ubuntu.com/26453160
<blackboxsw> http://pastebin.ubuntu.com/26453160
<smoser> blackboxsw: 'ordinal not in range'
<smoser> ?
<blackboxsw> yeah az cli cloudn't decode the boot logs on the machinie
<smoser> is that because az is trying to .decode() the console log ?
<blackboxsw> yeah
<smoser> :-(
<blackboxsw> so something to file against azure cli when I dig into it :/
<blackboxsw> but UI works
<dojordan_> ugh, ill make a bug report
<blackboxsw> thanks dojordan_
<blackboxsw> lemme get az cli version
<dojordan_> can you pastebin the ui logs?
<blackboxsw> http://paste.ubuntu.com/26453179/
<smoser> dojordan_: you're in good company. this week, we've hit.
<smoser>  https://github.com/lxc/pylxd/issues/268
<smoser> and
<smoser>  https://github.com/boto/botocore/issues/1351
<blackboxsw> dojordan_: ui logs is http://pastebin.ubuntu.com/26453160
<dojordan_> second boot?
<smoser> blackboxsw: yeah, go for it.
<blackboxsw> dojordan_: smoser 2nd rebooting now
<blackboxsw> ok
<blackboxsw> hrm any way to show in cli what power state is on node
<dojordan_> let me see
<blackboxsw> dojordan_: ok it's looping
<blackboxsw> just got logs smoser dojordan_
<blackboxsw> looping on reprovidsiondata
<blackboxsw> copying now
<blackboxsw> new boot log http://pastebin.ubuntu.com/26453225
<blackboxsw> I'm looking now
<blackboxsw> yeah it's looping on 404 from reprovisioning
<blackboxsw> so, something triggered that poll which shouldn't have
<dojordan_> DataSourceAzure.py[INFO]: Creating a marker file to poll imds
<dojordan_> yup
<smoser> well, that part seems like it is functioning as designed.
<blackboxsw> hahah
<blackboxsw> :)
<smoser> dojordan_: logging seems extremely verbose if you're expecting this to sit up for 24 hours before use
<dojordan_> but we won't log debug by default right?
<smoser> debug does go to log file, but not to console
<smoser> looks like < 1k/second. but that'd add up.
<smoser> but thats not the issue.
<smoser> why did we get into the imds
<blackboxsw> so cfg.PreprovisionedVm == True
<blackboxsw> something in _extract_preprovisioned_vm_setting returns True
<blackboxsw> we need to look over that ovf file again
<blackboxsw> I think
<dojordan_> my guess is the refactoring broke something. the weird thing is it should have been covered by ut
<blackboxsw> yeah I thought so too
<dojordan_> im re reading my code now and no idea...
<blackboxsw> I'm starting up a 2nd vm now and will run _extract_... on the doc
<dojordan_> smart
<dojordan_> we didnt see any of those debugs though...
<smoser> blackboxsw: smoser@52.151.23.91
<smoser> if you want
<smoser> take it
<blackboxsw> 40.79.65.171
<blackboxsw> as well
<blackboxsw> 40.79.65.161 rather
<blackboxsw> <ns1:PreprovisionedVm>false</ns1:PreprovisionedVm>
<blackboxsw> ok,,,, so that should've been interpreted as false
<dojordan_> oh no
<dojordan_> bool("false") is true
<blackboxsw> ahhahhha
<blackboxsw> ohhh right
<blackboxsw> didn't translate from string type
<dojordan_> ill push a fix
<dojordan_> thanks for all the help
<blackboxsw> cheers. gotta go pickup a kiddo from school
<blackboxsw> see ya in a bit
<dojordan_> @smoser, @blackboxsw, I pushed a fix, and added another UT that would have caught it. Testing now in azure.
<dojordan_> my thoughts on removing the verbose logging: maybe just log a byte every request of something. Also, do we have a log level that goes to the console by default?
<blackboxsw> dojordan_: warning level is configured to the console by default.
 * blackboxsw wonders about us adding a param in a subsequent branch to url_helper.readurl(quiet=(False|True) then callers handling retries outside of that could turn down the volume of logs
<blackboxsw>  testing your latest branch now too
<dojordan_> same here, *fingers crossed*
<dojordan_> i got permission denied using password auth but at least the ECSDA host key changed on me
<smoser> ssh auth shouldnt be affected. if you get there, it really should let you in
<smoser> nothing woudl have deleted your keys
<dojordan_> password would have been redacted in the ovf-env.xml, not sure what that changes
<blackboxsw> I know it's a nit, but changing the log message Start polling IMDS from debug -> warning feels like it really shouldn't be a warning level log
<blackboxsw> maybe I'm wrong (I know you are probably just trying to get it to show up in default console log configuration)
<dojordan_> right, im open to other options, but it would be nice to get to the console
<smoser> i can  understand wanting to see somethign on the console (for azure platofrm perspectivee)
<smoser> but itkind of stinks from the users' perspective.
<smoser> they have a right to expect WARN in the logs to mean "something went wrong"
<smoser> but here nothing in their control actually went wrong.
<dojordan_> true...
<dojordan_> im fine reverting it now that we found this bug
<smoser> yeah. i think that is best for now.
<blackboxsw> dojordan_: one more thing while you are in there.
<smoser> i have said many times i think python logging lacks level granularity
<smoser> and cloudd-init usage of what *is* there is bad.
<blackboxsw> there's a util.translate_bool that might be of use in checking that truthy value from ovf file
<smoser> it seems to me that this should qualify as INFO level
<smoser> and at some point maybe a concerted effort couldg et INFO to the console
<blackboxsw> btw smoser and dojordan_ success ubuntu@40.79.65.161
<dojordan_> sweet!
<dojordan_> what distro?
<blackboxsw> dojordan_: bionic, running through xenial now
<dojordan_> Y
<dojordan_> cool, I got back in on xenial too
<dojordan_> just pushed those two changes (correct log level, and util.translate_bool)
<blackboxsw> great, xenial looks good for me too.
<smoser> \o/
<blackboxsw> ok, I'll land this when ci completes it's vote dojordan_
<dojordan_> thanks!
<blackboxsw> thanks for "dotting the i's and crossing the t's"
<robjo> smoser: As touched on in previous discussion platform.linux_distribution() is deprecated in upstream Python and as of version 3.7 is expected to go away, in 3.6 on SUSE it returns an empty tuple, thus useless
<robjo> I take it in Ubuntu you guys patched Python
<robjo> anyway, I think we shoud make a decisison if we expand the dependencies to python-distro or if cloud-init gets it's own function to determine the distribution
<robjo> thoughts?
<robjo> https://github.com/nir0s/distro#distro---a-linux-os-platform-information-api
<smoser> hm.
<smoser> i think i'd just want to build my own.
<smoser> s/my/own/
<smoser> s/my/our/
<smoser> i dont want an external dependency for something as seemingly simple as "figure out if you are on ubuntu, suse, redhat, ...".
<smoser> :-(
<robjo> fair enough, something like this?
<robjo> if os.path.exists('/etc/os-release'):
<robjo>   use it and determine the distro
<robjo> else:
<robjo>   try:
<robjo>     platform.linux_distribution()
<robjo> except:
<robjo> ......
<robjo> Sound reasonable?
<smoser> yeah i guess. id 'also like to olet the packager easily just set it
<robjo> well that's the other option, just punt and make the person running setup set the distro then we save the code all together
<smoser> well, i thin i'd l ike it to do the right thing, but if the logic that is there doesnt "do the right thing", then let the packager set it.
<smoser> i want trunk to "just work" though
<robjo> OK, I'll see what I can come up with
<robjo> https://bugs.launchpad.net/cloud-init/+bug/1745235
<ubot5> Ubuntu bug 1745235 in cloud-init "distribution detection" [Undecided,New]
<dojordan_> @smoser and @blackboxsw, thank you for all your help landing this PR. When will the nightly azure images contain these changes?
<blackboxsw> heh, was going to ping you that I just landed it :)
<blackboxsw> should be in bionic tomorrow
<blackboxsw> I'm thinking we will probably SRU in February.... so xenial, artful would have it our next SRU
<dojordan_> bionic will work for me :)
<blackboxsw> dojordan_: oopsie, sorry I need to propose for merging into bionic
<blackboxsw> I'll put up another merge proposal tonight. we can probably land that tomorrow and it'll be published friday
<blackboxsw> just landing robjo's btrfs branch too
<dojordan_> gotcha. Is the bionic branch just a delayed mirror of master?
<blackboxsw> dojordan_: yeah the way we structure bionic publishing is just to mirror all content from master tip
<blackboxsw> for SRUs into xenial, zesty artful releases we take  a snapshot of tip as well and if some significant behavior change requires attention to retain backward compatibility we carry a small patch to retain behavior in xenial.
<blackboxsw> since bionic is not officially in feature freeze until March 2018, any change in behavior of cloud-init is given the go-ahead, so snapshots are easy https://wiki.ubuntu.com/BionicBeaver/ReleaseSchedule
<blackboxsw> SRUs into ubuntu series that are 'stable/released' require a bit more work on our end with testing/verification
<blackboxsw> https://wiki.ubuntu.com/CloudinitUpdates for our SRU process (TMI I know)
<dojordan_> got it, this explains a lot. (not TMI :) )
#cloud-init 2018-01-25
<smoser> blackboxsw: do you have an mp coming?
<blackboxsw> ahh yes, better late than never https://code.launchpad.net/~chad.smith/cloud-init/+git/cloud-init/+merge/336582
<blackboxsw> thx for landing it
<smoser> blackboxsw: or rharper
<smoser> pretty please
<smoser> https://code.launchpad.net/~smoser/cloud-init/+git/cloud-init/+merge/336498
<blackboxsw> yeah smoser feature creep wishlist for me on the hotplug stuff
<blackboxsw> looking
<smoser> blackboxsw: rharper approved so i'm merging.
<smoser> unless you object quick
<smoser> ;)
<blackboxsw> smoser: merging now
<blackboxsw> well awaiting tox and it'll land
<blackboxsw> landed
 * blackboxsw needs to writeup a cool whoami ubuntu contributor page like rharper/powersj have to see if I can get per-pkg commit writes for cloud-init curtin
<smoser> yes
<powersj> feel free to use mine as a template
<blackboxsw> cut-n-paste s/powersj/blackboxsw/g
<blackboxsw> .... and done
 * blackboxsw thinks claiming the work of others is frowned upon.
<blackboxsw> but yeah will base it off what you guys have
<powersj> :)
 * blackboxsw dumped a couple of branches up for review: https://code.launchpad.net/~chad.smith/cloud-init/+git/cloud-init/+merge/336635 and https://code.launchpad.net/~chad.smith/cloud-init/+git/cloud-init/+merge/336453
<blackboxsw> the first one is just docs on CLI subcommands
<blackboxsw> adding some cross-references to the pre-existing analyze stuff ryan added. But adding a bit of context on some of the cloud-init cmdline options as well.
<blackboxsw> dojordan, just saw cloud-init updates with your changes made it into azure
<blackboxsw> apt-cache policy cloud-init
<blackboxsw> cloud-init:
<blackboxsw>   Installed: 17.2-13-gf4b8fa6d-1~bddeb
<blackboxsw>   Candidate: 17.2-25-gc03bdd3d-0ubuntu1
<blackboxsw>   Version table:
<blackboxsw>      17.2-25-gc03bdd3d-0ubuntu1 500
<blackboxsw>         500 http://archive.ubuntu.com/ubuntu bionic/main amd64 Packages
<blackboxsw>  *** 17.2-13-gf4b8fa6d-1~bddeb 100
<blackboxsw>         100 /var/lib/dpkg/status
<blackboxsw> root@b5:~#
<blackboxsw> well into cloud image
<blackboxsw> well into cloud images. I mean. deploying azure to check
<blackboxsw> yep fresh azure instance is up with your changes... though I'm seeing a delta, like what I merged in from your branch was stale and didn't contain dojordan's last commit.
<blackboxsw> it's a minor change, but I'll proposed a trivial now and we can discuss how best to merge, publish that change
<blackboxsw> n/m I was on my own stale branch
<blackboxsw> powersj: for shame lgtm.com doesn't scrub testing directories. /me was wondering how all your contributions only got logged as 300 lines
<blackboxsw> https://lgtm.com/people/1801127304/project:1884170995/lang:python
<powersj> blackboxsw: heh I wondered the same thing
<powersj> I was like what happened to all my work?!
<blackboxsw> yeah definitely "It's not fair" â¢
<powersj> haha
 * blackboxsw sees if we can tweak settings as I'd like to have that review at least on cloud_tests directories
<powersj> looks like you could create a lgtm.yaml with what dirs it tests
<blackboxsw> https://lgtm.com/docs/lgtm/file-classification
<blackboxsw> yeah
<blackboxsw> yeah it'd probably be worth minimally a path_classifiers:\n test:\n  - exclude: tests/cloud_tests   lgtm.yaml
<blackboxsw> I'll put up a sample cloud-init mirror to see if it blows up anything
#cloud-init 2018-01-26
<bartuss7> Hello. I'm trying to inject dns to /etc/resolv.conf using userdata, but doesnt work. I'm using heat to inject resolv config. Here is my config: https://pastebin.com/dhW2SgZy
<chele> hi there, how can i disable dhcp and provide static network config?
<chele> i saw this bugs from last summer but not resolution so far https://bugs.launchpad.net/cloud-init/+bug/1633656
<ubot5> Ubuntu bug 1633656 in uvtool "Can't disable DHCP network config on xenial" [Undecided,New]
<smoser> bartuss7: any time someone pastes a pastebin.com, my eyes make me tell them 2 things
<smoser> a.) pastebinit (pacakge, installed in ubuntu by default) . uses http://paste.ubuntu.com .
<smoser> b.) my favorite pastebin (although i fear it wont last long) https://hastebin.com/
<smoser> now... done witih public service announcement, i'll look at what you have.
<smoser> bartuss7: a few things i suspect.
<smoser> a.) the 'resolv_conf' module isnt enabled by default. you'd have to add it to /etc/cloud/cloud.cfg (init_modules).
<smoser> b.) i dont know if heat will magically add the '#cloud-config' header or not
<smoser> but you have to have that or cloud-init will not pay attention to the content (it does  not assume that all data is always for it).
<smoser> c. in openstack... y ou can proably manaage your nameservers differentlky through network settings and it should all get through.
<smoser> chele: need some more data.
<smoser> are you using uvtool ?
<chele> smoser right
<chele> i think my college solved with user_data.cfg
<smoser> chele: so i assume that its just a missing feature.
<smoser> let me see if there is a way in uvtool to manage it via network-config
<chele> but according to the bug report it still tried dhcp and ...
<chele> right
<smoser> chele: http://paste.ubuntu.com/26464399/
<smoser> i'll update that bug with this
<chele> smoser right, so this doesn't fire dhcp req?
<smoser> correct. it gives the static configuration describec by that ENI file
<smoser> and should work 14.04 -> 18.04
<chele> right. ok so i guess bug might be fixed but nobody update the bug report...anyway thanks.
<smoser> chele: well this is not an ideal situation really.
<smoser> it will work. just not ideal. see the caveats i wrote there.
<smoser> hi might be wrong about 14.04
<chele> right.
<smoser> rharper blackboxsw powersj fyi, yesterday i turned on auto-expire of Incomplete bugs.
<smoser> which is why you might see some mail
<powersj> "some"
<powersj> ;) and yes got 40+ this morning
<smoser> rharper: https://code.launchpad.net/~smoser/cloud-init/+git/cloud-init/+merge/336630
<smoser> you want to finish-approve that ?
<rharper> smoser: looking
<rharper> smoser: approved; but generally I didn't understand why we wouldn't have the list of labels we recognize in one place (or at least one in python and one for ds-identify )
<smoser> rharper: it *is* in one place.
<smoser> only in ds-identify.
<rharper> ok
<smoser> powersj: https://code.launchpad.net/~smoser/cloud-init/+git/cloud-init/+merge/336722
<smoser> that i think would magically start working when lxd 3 lands in whaever snap channel we're using.
<powersj> smoser: thanks! where did you find the info about lxd 3.0?
<powersj> I can give it a shot in a bit too
<powersj> oh sorry now I see your comment in the bug
<smoser> yeah, ikind of would like to have the currrently-working path in place too
<smoser> i dropped the _setup_console_log bit before i knew that '--show-console-log' didn't actually work  :)
<blackboxsw> thanks for the reviews smoser rharper thanks for the good review on my doc branch, I think I addressed all comments and reworked a lot of the content and cross reference links.
#cloud-init 2018-01-28
<ybaumy> guys anyone here?
<ybaumy> i have a question about vcloud director 9 extensions and cloud-init
<ybaumy> would it be possible to write an own datasource for that
<ybaumy> and would it make sense
<ybaumy> best question.
#cloud-init 2020-01-20
<mkrai_> Hi cloud-init team. I am trying to deploy a node when an infiniband card with OpenStack. cloud-init fails complaining that the MAC address of the infiniband card is not know. OpenStack provides fake 6bytes MAC address in format mac[36:-14] + mac[51:].
<mkrai_> Can someone please help me?
<meena> mkrai_: hello good morning
<mkrai_> meena, Hi, good morning
<meena> n.b.: most cloud-init committers live somewhere across the north american continent. The help that i can provide is probably not going to be of the same quality.
<meena> mkrai_: can you show us the exact error message?
<mkrai_> It didn't log any error, but I debugged it and found the error https://github.com/canonical/cloud-init/blob/master/cloudinit/sources/helpers/openstack.py#L677
<mkrai_> meena, ^
<meena> mkrai_: that's very recent code, i *think* which version are you running?
<meena> nope, never mind, confusing it withâ¦ something else.
<mkrai_> meena, same error but I am running 18.5
<meena> oh, it actually is from there: https://github.com/canonical/cloud-init/pull/122
<meena> this is where the discussion happens: https://github.com/canonical/cloud-init/pull/122#pullrequestreview-339327984
<meena> mkrai_: do you, per chance, work with the author of that patch?
<meena> maybe you two should talk :P
<mkrai_> meena, I am trying to reach him ;)
<meena> from their av at Github it would be "her"
<meena> anyway, it seems madhuri-rai07 hit a similar problem, and decided to deal with it outside of cloud-init. The question whether the problem is OpenStack or Cloud-Init is hard to say without access to such (expensive?) hardwareâ¦
<mkrai_> meena, i am madhuri-rai07 ;) sorry i misunderstood
<meena> mkrai_: duuh, sorry ð
<meena> mkrai_: so, am i understanding you correctly, you've narrowed down the issue to: infiniband or, infiniband thru OpenStack?
<meena> or is the issue _also_ in Cloud-Init?
<Odd_Bloke> akik: Are you still looking for help with your default user question?
<akik> Odd_Bloke: yes, please
<akik> i had user section in my cloud-config but i removed it, and then i got that default centos account
<Odd_Bloke> akik: So I believe it is `users: - default` that is creating the default user (because generally people _do_ want a user created, even if they haven't explicitly specified it).  Are you looking to create _no_ users, or to create only the users you specify?
<akik> Odd_Bloke: i'd like cloud-init not to create users
<Odd_Bloke> akik: If you're passing user-data, then I believe `users: []` would do the trick.
<akik> Odd_Bloke: oh right, thanks
<Odd_Bloke> If you want to do it via /etc/cloud, then I think `users: []` in a /etc/cloud/cloud.cfg.d/ snippet would do it too (though I haven't tested that).
<akik> Odd_Bloke: what would i remove from /etc/cloud/cloud.cfg to do the same?
<akik> i see the users: there
<akik> oh ok cloud.cfg.d might be better
<Odd_Bloke> akik: I think removing the users stanza would do it, but I'd recommend using a snippet so you aren't manually editing a config file that a package installed.
<Odd_Bloke> (Because on Debian/Ubuntu at least, if you change that file then you'll be prompted to resolve conflicts any time that config file changes on upgrade.  The snippet doesn't have that issue.)
<akik> yes i'm using user-data via cloudsigma's api
<Odd_Bloke> OK, cool, then that's your best option. :)
<Odd_Bloke> rharper: https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1860046 is the RPi bug we were waiting for, FYI.
<ubot5> Ubuntu bug 1860046 in cloud-init (Ubuntu) "Race to mount seed device" [Undecided,New]
<meena> Odd_Bloke: hello, welcome back, have you considered refactoring cloudinit/net today?
<Odd_Bloke> meena: I haven't, and as I'm (a) catching up from Friday, and (b) all the US folks are on vacation, I probably won't today I'm afraid.
<meena> Odd_Bloke: no stressâ¦ just (daily) nagging.
<Odd_Bloke> :)
#cloud-init 2020-01-21
<Xat`> hello guys !
<Xat`> cloud-init erases /etc/ssh/ssh_host_*_key file when it starts
<Xat`> I don't want this behavior, how can I remove this ?
<meena> Xat`: hello
<meena> generally, it shouldn't erase, but (re)create them. and it should only recreate them if something really signifcant has changed about the server
<Xat`> meena: I have a 2 SFTP servers behind a load balancer. When sftp client are connecting to the loadbalancer endpoint, they are "forwarded" to one of the two servers. Because of that, sftp client spawns a security alert because ssh fingerprint has changed. This is why I tried to setup host keys from /etc/ssh/ directory.
<Xat`> But, cloud-init erases them in the 'init' phase
<meena> Xat`: ooookay. so, you might wanna disable that module
<Xat`> yeah :) Can I have a list of module or get doc related to specific module
<meena> https://github.com/canonical/cloud-init/blob/master/config/cloud.cfg.tmpl#L75
<meena> and then there's this: https://github.com/canonical/cloud-init/blob/master/config/cloud.cfg.tmpl#L85
<Xat`> I guess ssh-authkey-fingerprints could be good one
<meena> i dunno all of them, i keep ssh to a bare minimum
<meena> buuuuuuut now i'm wondering if i shouldn't be using cloud-init to roll out my git deploy key >_>
<Xat`> :)
<Odd_Bloke> Xat`: How are the SSH host keys getting generated on the host (if not by cloud-init at boot)?
<Xat`> Odd_Bloke: using an ansible role
<Xat`> I am using a lot of ansible stuff, but it seems that cloud-init could help me for some things
<Odd_Bloke> Xat`: OK, sounds like it is sensible to disable the SSH key behaviour then.  For _some_ reason, that specific part of the docs isn't rendering at the moment, here's an older version where it _is_ rendered: https://cloudinit.readthedocs.io/en/19.2/topics/modules.html#ssh
<Odd_Bloke> You probably want `ssh_deletekeys: False` in your user data.
<Xat`> I was not at all aware about it. But now I know I have to deal with it ;)
<Odd_Bloke> ^_^
<Xat`> Odd_Bloke: yes, I did it
<Xat`> in combination with ssh_genkeytypes: []
<Odd_Bloke> And did that address your issues, or are you still seeing some behaviour you don't want?
<Xat`> Odd_Bloke: my issue is now solved ;)
<Xat`> I have to set both
<Xat`> thank you guys Odd_Bloke & meena
<Odd_Bloke> Yeah, I was going to point at ssh_genkeytypes next. :)
<Odd_Bloke> Glad to hear it's resolved! :)
<Xat`> :)
<akik> Odd_Bloke: does a list of all the cloud-init tasks default exist somewhere?
<akik> default tasks
<Odd_Bloke> akik: Can you expand on what you mean by "tasks"?
<akik> Odd_Bloke: for example that default user creation
<akik> and that ssh_deletekeys
<Xat`> akik: I was actually looking for the same doc
<Xat`> but I used the code instead
<Odd_Bloke> akik: So there is some stuff that cloud-init does on a per-platform basis (e.g. it will mount a drive to read configuration for ConfigDrive, it will do some specific networking stuff on Azure, etc.) and everything else is contained in config modules which are documented at https://cloudinit.readthedocs.io/en/latest/topics/modules.html
<akik> i'd like cloud-init to be very clear on what it'll do by default
<akik> Odd_Bloke: which ones are ran by default?
<Odd_Bloke> Which modules run is entirely configurable per-system, so there isn't an explicit list that upstream can give you for your particular system.
<Odd_Bloke> But you can see the configuration template that upstream ship here: https://github.com/canonical/cloud-init/blob/master/config/cloud.cfg.tmpl
<akik> what's upstream in this case?
<akik> ubuntu?
<Odd_Bloke> No, cloud-init.
<Odd_Bloke> You can look at /etc/cloud/cloud.cfg to see what your system is configured to do.
<akik> for example i removed the user creation from my user-data, and got that default centos user. that was totally unexpected
<Odd_Bloke> Right, that's how the CentOS packages configure cloud-init.
<Odd_Bloke> (And almost all distros do the same, including Ubuntu.)
<akik> i don't remember if it added NOPASSWD: to sudo config
<akik> that shouldn't happen
<Odd_Bloke> How would you set the password in the default case that no user-data is passed?
<Odd_Bloke> blackboxsw: LMAO, GitHub just didn't attach my comments to the right lines at all.
<blackboxsw> yeah that was strange
<Odd_Bloke> blackboxsw: Search for "1min"
<blackboxsw> found it Odd_Bloke thanks. That system had a 1 min execution on the cmd ssh-import-id chad.smith :).   I'm reattempting a complex azure network run to see if it hit the same issue
<Odd_Bloke> OK, thanks!
<Odd_Bloke> blackboxsw: If you're looking for a break: https://github.com/canonical/cloud-init/pull/178
<blackboxsw> #startmeeting Cloud-init bi-weekly status
<meetingology> Meeting started Tue Jan 21 17:42:43 2020 UTC.  The chair is blackboxsw. Information about MeetBot at http://wiki.ubuntu.com/meetingology.
<meetingology> Available commands: action commands idea info link nick
<blackboxsw> At long last, and a bit late. Time for a brief cloud-init status meeting
<blackboxsw> Coud-init upstream uses this meeting as a platform for community updates, feature/bug discussions, and an opportunity to get some extra input on current development.
<blackboxsw> You can always find the next date and time of the cloud-init status meeting in the topic of this channel.
<blackboxsw> it also serves as a reminder to me that we need to start it as I find it's easy to forget the appointment if it isn't staring us in the face.
<blackboxsw> Let's set next meeting now
* blackboxsw changed the topic of #cloud-init to:   cloud-init pull-requests https://git.io/JeVed | Meeting minutes: https://goo.gl/mrHdaj | Next status meeting February 4 17:15 UTC | 19.4 (Dec 17) drops Py2.7 : origin/stable-19.4 | 20.1 (Feb 18) | https://bugs.launchpad.net/cloud-init/+filebug
<blackboxsw> our previous meeting minutes are recorded on our  github site
<blackboxsw> #link https://cloud-init.github.io/
<blackboxsw> the topics we cover in this meeting are the following: Previous Actions, Recent Changes, In-progress Development, Community Charter, Upcoming Meetings, Office Hours (~30 mins).
<blackboxsw> #topic Previous Actions
<blackboxsw> Previous  #ACTION bbsw seed initial community charter bitesize bugs   ... DONE.
<blackboxsw> 'bitesize' bugs for cloud-init can be found at the following link
<blackboxsw> #link bugs.launchpad.net/cloud-init/+bugs?field.tag=bitesize
<blackboxsw> These bugs should be easy to work in parallel as well as self-contained bits of work that any member of the community could approach as a small chunk of work
<blackboxsw> we moved from using trello board for tracking these tasks to using launchpad bugs as it eases the ability to search and grab ownership of the specific features/bugs
<blackboxsw> #topic Recent Changes
<blackboxsw> The following commits landed in tip of master: (found by git log --since 01/07/2020)
<blackboxsw>     - Add Rootbox & HyperOne to list of cloud in README (#176) [Adam Dobrawy]
<blackboxsw>     - docs: add proposed SRU testing procedure (#167)
<blackboxsw>     - util: rename get_architecture to get_dpkg_architecture (#173)
<blackboxsw>     - Ensure util.get_architecture() runs only once (#172)
<blackboxsw>     - Only use gpart if it is the BSD gpart (#131) [Conrad Hoffmann]
<blackboxsw>     - freebsd: remove superflu exception mapping (#166) [GonÃ©ri Le Bouder]
<blackboxsw>     - ssh_auth_key_fingerprints_disable test: fix capitalization (#165)
<blackboxsw>       [Paride Legovini]
<blackboxsw>     - util: move uptime's else branch into its own boottime function (#53)
<blackboxsw>       [Igor GaliÄ] (LP: #1853160)
<blackboxsw>     - workflows: add contributor license agreement checker (#155)
<blackboxsw>     - net: fix rendering of 'static6' in network config (#77) (LP: #1850988)
<blackboxsw>     - Make tests work with Python 3.8 (#139) [Conrad Hoffmann]
<blackboxsw>     - fixed minor bug with mkswap in cc_disk_setup.py (#143) [andreaf74]
<ubot5> Launchpad bug 1853160 in cloud-init "uptime code does not work on FreeBSD with python 3" [Medium,Fix committed] https://launchpad.net/bugs/1853160
<ubot5> Launchpad bug 1850988 in cloud-init "[Cloud-init 18.5][CentOS 7 on vSphere] Crash when configuring static dual-stack (IPv4 + IPv6) networking" [Medium,Fix committed] https://launchpad.net/bugs/1850988
<blackboxsw> Thanks Adam, Conrad, andreaf74, GonÃ©ri and meena for improving cloud-init.
<blackboxsw> #topic In-progress Development
<blackboxsw> FreeBSD, NetBSD improvements are under heavy development, thanks meena and Goneri for all the PRs put of in that regard.
<blackboxsw> Also robjo has started work on cleanup of sysconfig net rendering per https://github.com/canonical/cloud-init/pull/162 and a mailing list discussion
<blackboxsw> rharper is also midstream on "cloud-init run as a daemon" mode https://github.com/canonical/cloud-init/pull/48   which should improve cloud-init startup times by avoiding having to reload python 4 times for each cloud-init stage
<blackboxsw> Also in progress, upstream has started to SRU testing for cloud-init 19.4.33 into Ubuntu Xenial, Bionic and Eoan.
<blackboxsw> We expect to wrap up that testing this week for a publish of cloud-init 19.4.33 to those series
<blackboxsw> #topic Community Charter
<blackboxsw> As a note, any community member is welcome to participate in SRU testing of cloud-init if those changesets in the SRU affect your cloud platform or features.
<blackboxsw> We have added a guide for SRU testing on Ubuntu here
<tribaal> duly noted :)
<blackboxsw> #link https://cloudinit.readthedocs.io/en/latest/topics/debugging.html#manual-sru-verification-procedure
<blackboxsw> :)
<blackboxsw> ahh tribaal we should pull in your PR for manual testing of Exoscale too if you think it's ready https://github.com/cloud-init/ubuntu-sru/pull/64
<tribaal> it's not unfortunately :/
<blackboxsw> ahh, ok *good*, thought it was waiting on review
<blackboxsw> ok can table that for another SRU (which will be around Feb 14th likely)
<tribaal> no worries, happy to help test the current one anyway
<blackboxsw> community notice: we are targeting Feb 18th as our cutoff for upstream cloud-init version 20.1 (which will be SRU'd to Ubuntu Xenial, bionic and Eoan). If there are features  of bug fixes that you'd like to get into cloud-init 20.1 please raise them as PRs or discussion on the mailinglist or in channel
<blackboxsw> #topic Office Hours (next ~30 mins)
<blackboxsw> This time is spent on any cloud-init feature/bug/branch discussions. quetions or concerns and topics are welcome. In the absence of topics we'll groom the review queue.
<blackboxsw> I'm wrapping up some significant change suggestions the networking stuff for sysconfig on https://github.com/canonical/cloud-init/pull/162
<blackboxsw> I should have that review done in about an hour
<blackboxsw> I've added myself as the "assignee" to that PR to indicate it as priority for me
<blackboxsw> also, note in SRU testing  I've run into a repeated issue with cloud-init's ssh-import-id  taking 1 minute to import a single ssh pubkey on Azure bionic advanced networking vms. (2 nics + ipv6 + multiple IPs).  I'll be debugging this a bit today to make sure it is not a regression for this cloud-init SRU 19.4.33
<blackboxsw> if anyone has any feedback or issues associated with this cloud-init v 19.4.33 SRU, they can comment on the SRU bug or raise a new bug or comment in IRC
<blackboxsw> #link https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1859725
<ubot5> Ubuntu bug 1859725 in cloud-init (Ubuntu) "sru cloud-init (19.3.41 to 19.4.33) Xenial, Bionic and Eoan" [Undecided,New]
<blackboxsw> ok, that about wraps today's status meeting. We'll have the next one February 4th to chat again about getting features ready for 20.1
<blackboxsw> Thanks for tuning in.
<blackboxsw> #endmeeting
<meetingology> Meeting ended Tue Jan 21 18:55:32 2020 UTC.
<meetingology> Minutes:        http://ubottu.com/meetingology/logs/cloud-init/2020/cloud-init.2020-01-21-17.42.moin.txt
<meena> how do i keep missing these meetings
<blackboxsw> meena: it's ok, I nearly missed it too
<blackboxsw> hrm Azure advanced vm still seeing the same 1 min issue on ssh-import-id.
<blackboxsw> looks like the Azure vm with ipv6 is timing out on ipv6, then eventually falls back to ipv4. connect(3, {sa_family=AF_INET6, sin6_port=htons(443), inet_pton(AF_INET6, "2001:67c:1560:8003::8003", &sin6_addr), sin6_flowinfo=htonl(0), sin6_scope_id=0}, 28) = -1 ETIMEDOUT (Connection timed out)
<blackboxsw> I need to check initial ip config there  vs the config post cloud-init upgrade rendered netplan is the same both prior to upgrade and afterward, yet prior to upgrade doesn't have the ipv6timeout
<blackboxsw> probably a failure for me to create the right ipv6 config on the vm
<blackboxsw> Odd_Bloke: approved https://github.com/canonical/cloud-init/pull/178#pullrequestreview-346223273   though I think we need to track somewhere (maybe just a trello card on the SRU template board?  to remove python-six from depends in ubuntu(xenial|bionic|eoan) debian/control branches during next SRU.
<Odd_Bloke> blackboxsw: We're still a ways away from actually being rid of six, so it would be premature at this point.
<Odd_Bloke> But I'll add a task to work that out before we can consider it Done.
<meena> grep -wc six
<meena> > but we need to make sure we drop python-six as a package dependency from ubuntu/xenial|bionic|eoan debian/control files.
<meena> oy, i thought six was a builtin
<Odd_Bloke> Nope, but it is a single file drop-in, pretty much.
<Odd_Bloke> blackboxsw: If you need a break, more six removal: https://github.com/canonical/cloud-init/pull/179
<blackboxsw> yeah, I'm basically in azure cli ipv6 setup issues for manual sru testing so it's a 15 min downtime while awaiting the deployment run to discover that I misconfigured ipv6 routing network security groups
#cloud-init 2020-01-22
<blackboxsw> ok so the azure 1 min timeout during ssh-import-id in my SRU testing is really my fault, I'm definitely not setting up IPv6 properly per their preview feature. I'm going to try going through the full howto they've documented there verbatim to see if I can't get that ipv6 timeout to resolve https://github.com/MicrosoftDocs/azure-docs/blob/master/articles/virtual-network/virtual-network-ipv4-ipv6-dual-stack-cli.md.
<blackboxsw> This is *not* a regression in this SRU because the ipv6 timeout exists on the current released cloud-init too.
<mattia> hello everyone
<mattia> trying to understand cloud-init reasoning when writing 50-cloud-init.cfg
<mattia> for in interfaces.d
<blackboxsw> if a service honors a parts directory (like /etc/network/interfaces does via /etc/network/interfaces.d)  cloud-init wants to use the parts directory (/etc/network/interfaces.d in this case) because it allows cloud-init to avoid getting clobbered of something else writing custom config that cloud-init is unaware of.
<blackboxsw> the config parts directory also allows other programs or users to extend network configuration (maybe for NICs that cloud-init isn't in charge of)  in separate config files without having to be worried about cloud-init overwriting their separate config
<blackboxsw> if other vendors or platforms want to override specific config setup provided by cloud-init they would also have the ability to provide a /etc/network/intefarces.d/51-override-cloud-init.cfg if needed.
<blackboxsw> hope that helps (if I understood the question)
<mattia> good: that's what I was thinking :)
<mattia> now the real problem: I have a problem with debian images writing "static" entries to that file
<mattia> running openstack
<mattia> if I understood correctly cloud-init just writes down the JSON it gets from the datasource, correct?
<Xat`> hello guys, how can I use multiple userdata ?
<blackboxsw> Xat`: you can try adding multiple text/cloud-config mime parts: https://cloudinit.readthedocs.io/en/latest/topics/format.html#mime-multi-part-archive
<blackboxsw> or multiple include-file directives https://cloudinit.readthedocs.io/en/latest/topics/format.html#include-file
<blackboxsw> Odd_Bloke: I confirmed following the dual stack load balancer setup with cloud-init doesn't have the IPv6 timeout issue. https://paste.ubuntu.com/p/zVd3mhJbWc/
<Odd_Bloke> mattia: If the data source provides network configuration then cloud-init will use it, yes.
<Odd_Bloke> blackboxsw: OK, nice.  Gonna push up refreshed SRU validation logs?
<blackboxsw> so it's a problem with my manual setup of dual-stack on a vm in azure, not with cloud-init proper
<Xat`> blackboxsw: I could also use 'scripts/per-instance'
<blackboxsw> Odd_Bloke: I need to change up the manual test approach for azure advanced networking setup. I'm hoping to  avoid having to setup a load balancer and two vms in azure to test ipv6... but it might be unavoidable ://
<Xat`> executing scripts only at first boot is fine. "Any scripts in the ``scripts/per-boot`` directory on the datasource will be run
<Xat`> every time the system boots."
<Xat`> where is this directory located ?
<blackboxsw> Xat`: on first boot only, then use the scripts/per-instance directory
<blackboxsw> Xat`: generally it's in /var/lib/cloud/scripts/per-*
<Odd_Bloke> blackboxsw: Yeah, needing to set up a load balancer seems like overkill.  Would reaching out to an Azure person for assistance perhaps make sense?
<blackboxsw> there is a per-once directory too if you are creating your own image
<Xat`> alright !! nice
<mattia> Odd_Bloke, network information can be also obtained by the dhcp instead of the metadata server?
<mattia> we are very puzzled: we have this odd "static interface" only with Debian (ubuntu works fine) and only when started in tenants that share the network but do not own it
<mattia> i.e. all tenants except the admin one
<Odd_Bloke> mattia: So you'll want to think about this in two phases: cloud-init writes out networking configuration, and then the network provider (ifupdown/netplan/...) acts on the written configuration.
<Odd_Bloke> cloud-init could write out network configuration to DHCP on an interface (indeed, by default it will write out such configuration for the first interface), and then the second phase will configure the network device based on the DHCP response.
<Odd_Bloke> Or it could write out a static interface configuration, and then the second phase won't DHCP and so will just use the written configuration.
<Odd_Bloke> So DHCP isn't an _alternative_ to the cloud-init network configuration, it would be configured _by_ the cloud-init network configuration.
<Odd_Bloke> So there are a couple of obvious differences between Debian and Ubuntu that I would investigate: cloud-init version, and network provider.
<Odd_Bloke> What versions of cloud-init are you using across the two distros?
<Odd_Bloke> And examining /var/log/cloud-init.log might also give you some clues.
<mattia> I have this "stages.py[INFO]: Applying network configuration from ds bringup=True: {'version': 1, 'config': [{'type': 'physical', 'mtu': 1500, 'subnets': [{'type': 'static', ..."
<mattia> while on a VM started in the admin tenant I have this:
<blackboxsw> Odd_Bloke: yeah I've just sent an email to some Azure contacts about ipv6 setup for a single vm
<mattia> applying net config names for {'version': 1, 'config': [{'type': 'physical', 'mtu': 1500, 'subnets': [{'type': 'dhcp4'}],
<mattia> same image and same network, the only difference we can see is the tenant
<Odd_Bloke> mattia: What does `cloud-init query -a` on each one produce?
<Odd_Bloke> (I'm wondering if the cloud is simply presenting different network config.)
<usrdev> question - when using a no cloud image cloud image, what would cause the boot-up process to get stuck with standing up the network interface(s) ?
<usrdev> i noticed hitting enter on console, it proceeds to grab a DHCP assigned IP. but i do not know why i would need to wait or for this to happen.
<mattia> Odd_Bloke, 'query' does not seem to be a valid option on 18.3
<mattia> It does return a lot of information on 19.2 (Ubuntu)
<mattia> from I see on Ubuntu the network_json does not mention whether the configuration is static or dhcp
<mattia> *from what I see
<Odd_Bloke> mattia: Can you pastebin the network config?
<Odd_Bloke> (The JSON, I mean.)
<Odd_Bloke> usrdev: What distro (and version) are you running?
<usrdev> @Odd_Bloke: debian 10 | 18.3 (cloud-init)
<Odd_Bloke> usrdev: So I expect it's network-online.target that's blocking boot, and it will be doing that because there's a network interface that it is waiting for.
<usrdev> you'd be correct, watching it boot up that is exactly where it hangs up. this is, after it renames the interface from i believe ens18 to eth0, then stalls there for a bit and proceeds.
<usrdev> why would it be stalling?
<Odd_Bloke> usrdev: Can you pastebin `systemd-analyze critical-chain`?
<usrdev> https://www.irccloud.com/pastebin/2xAYWYid/
<Odd_Bloke> Hmm, I guess I was hoping something would jump out at me from that. :p
<Odd_Bloke> usrdev: Could you file a bug using the link in the topic and attach the tarball produced by `cloud-init collect-logs` to it?
<usrdev> Odd_Bloke: prior to doing so, let me ask this. i am using proxmox. and i am using the generic-cloud image of debian. that shouldn't be the issue right?
<Odd_Bloke> I don't have enough Debian cloud knowledge to answer that with confidence, I'm afraid.
<usrdev> i'll ask in their channel -- thanks for your help with this bit though! ;)
<Odd_Bloke> :)
<Odd_Bloke> Happy to help!
<Odd_Bloke> blackboxsw: https://github.com/canonical/cloud-init/pull/180 is the first of maybe two PRs to fix the doc builds.
<Odd_Bloke> This moves the configuration from the web interface into the repo.
<Odd_Bloke> I don't think it will _actually_ fix the missing docs, but I want to be sure that the base configuration is good before I try messing with it.
<Odd_Bloke> (I also don't know how I would test this anywhere but master, without a bunch of RTD setup hassle.)
<meena> Odd_Bloke: taking a break from removing six?
<Odd_Bloke> meena: Yeah, I was just doing that while long running tasks were happening.
<Odd_Bloke> It's a nice-to-have, but I don't think it will really gain us a huge amount in the short term.
<Odd_Bloke> requests still uses six, so we'll still be importing it at some point and it'll still be in the dependency tree.
<Odd_Bloke> But it does mean as other projects also drop support for Py2 and remove six, we'll eventually be rid of it.
<Odd_Bloke> blackboxsw: I haven't done Softlayer SRU verification before, I don't think.  How do I get credentials set up for launch-softlayer to work?  And what account do you use for your testing?
<blackboxsw> Odd_Bloke: I think I had to run 'slcli config setup'
<blackboxsw> Odd_Bloke: ultimately  I have a ~/.softlayer config file with
<blackboxsw> an api_key and SL163....
<blackboxsw> an api_key and username = SL163....
<blackboxsw> which is my personal canonical funded account
<Odd_Bloke> Cool, thanks!
<Odd_Bloke> blackboxsw: https://github.com/canonical/cloud-init/pull/180 is blocking me fixing the docs, FYI, so it would be good to get eyes on it today. :)
<blackboxsw> merged Odd_Bloke
<blackboxsw> I'm going through yet another iteration on minimal ipv6 azure
<Odd_Bloke> TFTM!
<Odd_Bloke> OK, well, that's completely broken doc builds.
<Odd_Bloke> Good times.
<Odd_Bloke> Oh, no, that's a temporary unrelated issue: https://stackoverflow.com/questions/59846065/read-the-docs-build-fails-with-cannot-import-name-packagefinder-from-pip-in
<Odd_Bloke> Thank goodness.
<blackboxsw> Odd_Bloke: approved gce sru test, https://github.com/cloud-init/ubuntu-sru/pull/81 minor additional PR put up for tooling
<Odd_Bloke> blackboxsw: And https://github.com/canonical/cloud-init/pull/181 is the actual doc fix, I think.
<Odd_Bloke> blackboxsw: Yep, I think I merged that tooling PR earlier. :)
<blackboxsw> Thanks Odd_Bloke for the fix. confirmed docs are working now
#cloud-init 2020-01-23
<Xat`> hello guys
<Xat`> how is scripts-per-instance determined ?
<Xat`> how cloud-init knows about the first boot ?
<powersj> Xat`, the instance-id is read, if that changes it is considered a new instance
<Xat`> powersj: I am testing with local instance on vbox, how this is implemented ?
<Xat`> On cloud provider, I guess instance-id is retrieve from instance metadata . How it works with vbox or vmware
<Xat`> wait a min, maybe cloud-init provides it
<Xat`> let me query the metadata url
<Xat`> ok no it does not
<Xat`> powersj: nvm, I gonna read about instance metadata with cloud-init ;)
<Xat`> I changed the value from /run/cloud-init/.instance-id , then did a reboot but the script in the scripts-per-instance has not been executed
<Odd_Bloke> blackboxsw: You have some changes requested on https://github.com/canonical/cloud-init/pull/70 if you want to take another look
<blackboxsw> Odd_Bloke: otubo. https://github.com/canonical/cloud-init/pull/70 looks good. was there a Launchpad bug related to this commit set?
<blackboxsw> I've approved  pull 70, just didn't squash merge yet incase we forgot to correlate to a launchpad (or redhat bug)
<blackboxsw> ahh yes there was
<blackboxsw> https://bugs.launchpad.net/cloud-init/+bug/1781781
<ubot5> Ubuntu bug 1781781 in curtin "/swap.img w/fallocate has holes" [Medium,Confirmed]
<blackboxsw> ok I'll tie that bug to the squashed commit message
<blackboxsw> ohh interesting Odd_Bloke paride, on an azure vm where I've config'd ipv6 and ipv4 on nic0  and only ipv4 on nic1. IMDS is showing/allocating ipv6 addresses to nic1.
<blackboxsw> cloud-init query ds.meta_data.imds.network | pastebinit
<blackboxsw> http://paste.ubuntu.com/p/T2CSCQTRVC/
<blackboxsw> I think we may have a minor issue t to file for clarity with azure folks.
<Odd_Bloke> Yeah, sounds like some clarification is necessary.
<akik> i expected a non-zero exit code if the events log says container die
<akik> uhh wrong channel
<cyberpear> any chance of passing the cloud-init config via `-fw_cfg` option of qemu? kind of like how Fedora CoreOS does its ignition config? `--qemu-commandline="-fw_cfg name=opt/com.coreos/config,file=/path/to/example.ign"` https://docs.fedoraproject.org/en-US/fedora-coreos/getting-started/#_launching_with_qemu
<Odd_Bloke> cyberpear: Using the firmware configuration like that isn't supported, so the two options I would suggest are using the kernel cmdline or a NoCloud metadata drive.  Both of those options are documented at https://cloudinit.readthedocs.io/en/latest/topics/datasources/nocloud.html#datasource-nocloud
<Odd_Bloke> cyberpear: (You can also file a feature request using the bug link in the topic, if you'd like. :)
<Odd_Bloke> blackboxsw: https://github.com/cloud-init/ubuntu-sru/pull/87 <-- for your review; in particular, review of the verification script before I start running it for all releases would be appreciated :)
<blackboxsw> Odd_Bloke: looks good. The testing you are doing there is probably a bit deeper than needed as we could have used `lxc exec test-$SERIES -- cloud-init devel net-convert --output-kind=netplan --directory /out.d --network-data=network.yaml --distro ubuntu` and validated the output results instead of having to setup an lxc and override configs.    Did you want to exercise the whole system instead, it is definitely
<blackboxsw> more thorough to setup lxc network on launch and your test is valid
<blackboxsw> comment and pointer added https://github.com/cloud-init/ubuntu-sru/pull/87 take what you will.
<ahosmanMSFT> Hi @blackboxsw it's been a while, I've been inbetween teams. I I noticed azurecloud integration has an issue with the function _wait_for_system(self, wait_for_cloud_init) in the base instance.py class. This function is called after the vm is booted and tries to run a script and ssh. When removing that function there are no ssh issue's, but for now it ssh'ing is 50/50. Can you help me look into this?
<blackboxsw> hi ahosmanMSFT.
<blackboxsw> is that failing due to timeout?
<ahosmanMSFT> Yes
<ahosmanMSFT> When I remove that function it's a 100% success
<blackboxsw> so on a test run that did fail you'd probably want to pass --preserve-instance and see if ssh connectivity came up sometime later after the default boot_timeout that you have set for azure which is 300 seconds.
<blackboxsw> on a test system that is retained (and exhibited the timeout failure) I'd be curious to see cloud-init analyze blame to see if cloud-init was spending an inordinate amount of time setting up
<ahosmanMSFT> I did some tests and ssh connective is available, I think it has to do with either the scripts or something else in that function
<blackboxsw> if cloud-init setup on Azure is < 30 seconds, then the issue is somehow that the initiall ssh connection to the vm is timing out without connect
<ahosmanMSFT> hmm I haven't run blame on the system
<ahosmanMSFT> I presume it it has nothing to do with ssh'ing it's self, but the wait  part because it ssh's immediately when that function is removed
<blackboxsw> ahosmanMSFT: also what that 'script' waits for is for a systemd enabled system to report either `systemctl is-system-running == 'running' or 'degraded'`
<blackboxsw> so checking `systemctl is-system-running` on the system will tell you what state it is in
<blackboxsw> ahosmanMSFT: and a `systemd-analyze blame` on the timedout system will also tell you where the boot process spent most of it's time
<blackboxsw> *its*
<ahosmanMSFT> Ok, I'll try that and let you know. Got a meeting soon though.
<Odd_Bloke> blackboxsw: https://github.com/canonical/cloud-init/pull/185 <-- very small CI fix/change
<Odd_Bloke> blackboxsw: And https://github.com/cloud-init/ubuntu-sru/pull/88
<ahosmanMSFT> Do cloud tests run every PR, I know they run every night @blackboxsw
<Odd_Bloke> We run a subset of the lxd tests for each PR.
<Odd_Bloke> But the full LXD test suite and the non-LXD test suites only run nightly.
<ahosmanMSFT> how about azure/ec2
<Odd_Bloke> As I said, the non-LXD test suites only run nightly. :)
<ahosmanMSFT> ok, that makes sense since those tests would consume more time
<blackboxsw> more time and more $$  spinning up instances on the clouds :)
<meena> Odd_Bloke: what about contextlib vs contextlib2?
<blackboxsw> ahosmanMSFT: did you know the azure instance type which exhibits byte-swapping behavior?
<blackboxsw> I'm trying to validate that your fix resolves the issue w/ incorrectly seeing 'new' instance-id across boots
<blackboxsw> as that fix is part of this SRU
<ahosmanMSFT> It was on all Azure gen2 VM's when switching nodes on azure
<blackboxsw> thanks ahosmanMSFT
<ahosmanMSFT> @blackboxsw I'm witnessing some weird behavior if azurcloud/image.py two different if statements one executes one doesn't they both have the same self._img_instance value of NONE, can you verify this. This is why images aren't launching on azurecloud integration tests. https://paste.ubuntu.com/p/VW8SH8QXsj/
<Odd_Bloke> meena: I haven't looked at it yet, but I assume it can go?
<blackboxsw> ahosmanMSFT: is self._img_instance the string "NONE" instead of the python value of None?
<blackboxsw> that would trigger one path to run, and the other not
<ahosmanMSFT> They both have the same value, you can see when itâs initialized in azure cloud/image.py.__init__
<blackboxsw> ahosmanMSFT: your             LOG.debug("self._img_instance: %s" % self._img_instance) is down below  self.platform.create_instance( and             self._img_instance.start(wait=True, wait_for_cloud_init=True)
<blackboxsw> so it's one of those two that isn't completing without error (which is why your logs don't show             LOG.debug("self._img_instance: %s" % self._img_instance)
<blackboxsw> so the logic paths are properly followed. just something bogus happening in the create_instance or instance.start() calls right
<blackboxsw> ahosmanMSFT: is there a specific cloud_test name that typically fails for you when things do fail?
<ahosmanMSFT> blackboxsw it doesnât fail individual tests, but when running multiple tests it fails to create clean image for the rest of tests due to it failing to creat a snapshot
<blackboxsw> ok will run a suite and see if I can get it to fail for me
<blackboxsw> won't be able to kick that off though until I'm done with current SRU verification on Azure specifically (as I don't want to collide w/ my manual test runs in the same account)
<blackboxsw> I just have one more manual SRU test to run (I had hit a configuration problem as I sent in email). But I *think* I've worked around it by creating a load balancer for the moment.
<ahosmanMSFT> blackboxsw: Thanks, Iâll keep hacking at it too
#cloud-init 2020-01-24
<otubo> blackboxsw: sorry for not responding in time, timezone differences :-( there's also a BZ related to this: https://bugzilla.redhat.com/show_bug.cgi?id=1772505
<ubot5> bugzilla.redhat.com bug 1772505 in cloud-init "swapon fails with "swapfile has holes" when created on a xfs filesystem by cloud-init" [High,Assigned]
<otubo> blackboxsw: just in case you want to attach that to the commit message as well
<rharper> Odd_Bloke: thanks
<Odd_Bloke> rharper: I'm not sure for what, but you're welcome. ;)
<blackboxsw> ahosmanMSFT: note that I'm not seeing byteswapping behavior on gen2 Standard_B1s from dmi data. The reason being that I think walinuxagent package is writing out a proper /sys/devices/virtual/dmi/id/product_uuid file with the right byte ordering.
<blackboxsw> ahosmanMSFT: I *think* a walinuxagent fix may have been introduced as a workaround for this byte swap issue I think?
<blackboxsw> or maybe I need a different vm --size that does exhibit the problem.
<blackboxsw> when I check dmi data file it has correct byte ordering
<ahosmanMSFT> blackboxsw, maybe, I haven't checked waagent/cloud-init in a bit. FYI I'll be switching from provisioning soon.
<ahosmanMSFT> let me get you a repro
<blackboxsw> Odd_Bloke: https://github.com/cloud-init/ubuntu-sru/pull/89/files is my SRU test for azure byte-swapping behavior. Though currently I haven't found a reproducing instance type
<blackboxsw> thanks ahosmanMSFT
<Odd_Bloke> blackboxsw: Shouldn't that be in the [Test Case] section of the SRU template?
<ahosmanMSFT> blackboxsw: So this will take a little bit to set up. We'll need to get two 1.65 TIP nodes, then upgrade one to 1.8. The two nodes would be part of a single availability set that we can pin a VM to. We'd exclude the 1.8 node to force the VM to be deployed to the 1.65. Then un-exclude the 1.8 node, kill the 1.65 node to force service healing to move the VM to the 1.8 node
<Odd_Bloke> (We had also talked about forcing an incorrect UUID for testing, which might be the best route if you can't find a reproducing instance type.)
<Odd_Bloke> ahosmanMSFT: What's "TIP" here?
<ahosmanMSFT> Testing In Prod
<Odd_Bloke> Aha, thanks. :)
<ahosmanMSFT> Here's the full convo I had with support
<ahosmanMSFT> https://www.irccloud.com/pastebin/j4ASsCWL/convo
<ahosmanMSFT> The UUID is changed in Azure backend
<Odd_Bloke> Right, OK.
<blackboxsw> roger. yeah ok that may be a bit more involved than I can reproduce easily via az commands. so I'll just trigger fake uuid swap and ensure it works
<blackboxsw> easy enough for me to manipulate what is cached in cloud-init datasource to a swapped value
<blackboxsw> ok have an appt, back in a bit
<blackboxsw> thanks
<ahosmanMSFT> No worries, support tested it and I verified there results
<meena> https://github.com/canonical/cloud-init/pull/161 when will be the right time to merge this?
<Odd_Bloke> meena: Oh, I've been meaning to comment there.  Because you weren't the original author, we need them to sign off on the CLA.
<Odd_Bloke> *If you're thinking that that's extremely annoying, then we are in agreement.)
