#cloud-init 2013-09-05
<kwadronaut> so, I read the docs: https://cloudinit.readthedocs.org/en/latest/topics/modules.html and think i still have some questions ;-)
<smoser> kwadronaut, you can ask htem here.
<kwadronaut> smoser: cheers. First question is: how can I contribute to that specific page?
<smoser> its managed from code.
<smoser> so you can write doc and make bzr merge request.
<kwadronaut> oh bzr. i forgot that.
<kwadronaut> which module would (re)generate ssh server keys?
<kwadronaut> (I'm using the Debian packages)
<smoser> 'ssh' does that.
<smoser> cloudinit/config/cc_ssh.py
<kwadronaut> thanks
<kwadronaut> hmmm i am missing the right way to have it only run once (use case: take a snapshot, boot that, don't get a new ssh-key)
<smoser> kwadronaut, it should only run once.
<smoser> by default
<kwadronaut> in that case, i'll compare what i changed half a year ago with the defaults.
<smoser> so the way that is handled is that the default is 'PER_INSTANCE'.
<smoser> the module can define *its* defualt, by defining 'frequency' in it. (cc_ssh does not do that). the values expected are one of
<smoser> PER_INSTANCE = "once-per-instance"
<smoser> PER_ALWAYS = "always"
<smoser> PER_ONCE = "once"
<smoser> and cloud-config can define a overriding value.
<smoser> see example of 'cloud_config_modules' in doc/examples/cloud-config.txt
<kwadronaut> ah, but instances get a new instance-id here if you snapshot and fire up the snapshot
<kwadronaut> thanks, i'm reading
<kwadronaut> that document both has [ cloud-init-per, once, mymkfs, mkfs, /dev/vdb ] and [ apt-update-upgrade, always ]
<kwadronaut> i guess 1 way would be less confusing
<smoser> kwadronaut, well, cloud-init-per is just a generic command.
<smoser> that you can can put into /usr/local/bin/ scripts or whatever
<smoser> and it will run the command provided according to that frequency.
<smoser> it may not actually be necessary in that case any more.
<smoser> but at one point bootcmd's didn't work for frequency
<smoser> oh. yeah. you do need it there.
<smoser> because 'bootcmd' module does run 'per_always'
<smoser> but if you only want a command to run once or per-isntance, then that command has to control itself.
<smoser> kwadronaut, ^ did that make sense ?
<kwadronaut> i guess so, i was getting some food and will have a closer look today or tomorrow.
#cloud-init 2013-09-06
<PedroAlvarez> Hi! How can I know if cloud-init is installed on my OS?
<PedroAlvarez> btw,. smoser, I hacked the setup script to support an older grep version.
<PedroAlvarez> The grep commands on the script are using perl regular expressions
<kwadronaut> PedroAlvarez: which OS are you using?
<PedroAlvarez> kwadronaut: custom core linux distro
<kwadronaut> i don't know that one, i'd say use your package manager and see if it's installed, have a look in /etc/cloud* /var/log/cloud* do a find for CloudConfig on your filesystem.
<PedroAlvarez> kwadronaut: Sorry, you miss understood me, Is not a distro.
<PedroAlvarez> It wasn't installed. Now I have it working in my OS, time to solve dependencies! :) thanks!
<smoser> PedroAlvarez, so 'tools/read-dependencies' wsa giving you grief? if you have a suitable replacement for that grep, that is fine.
<PedroAlvarez> smoser: the grep commands in  'tools/read-dependencies' works fine without the '-P' option.
<PedroAlvarez> smoser: but I had to change the 'tools/read-version' grep's regular expression, using '[0-9][0-9]*' instead '\d+'.
<smoser> PedroAlvarez, does this work for you: http://paste.ubuntu.com/6070291/
<PedroAlvarez> smoser: I did this and it worked: http://paste.ubuntu.com/6070304/
<smoser> http://paste.ubuntu.com/6070306/
<smoser> can you try that diff, pedro ?
<smoser> PedroAlvarez, 
<smoser> or i could do them both with sed. does your sed have '-n' ?
<smoser> VERSION=$(sed -n '/^[0-9]\+[.][0-9]\+[.][0-9]\+:/ { s/://; p; :a;n; ba}' "$CHNG_LOG")
<PedroAlvarez> sorry smoser: I cannot send you diff now.
<PedroAlvarez> I used this and worked fine
<PedroAlvarez> VERSION=$(grep "[0-9][0-9]*.[0-9][0-9]*.[0-9][0-9]*:" "$CHNG_LOG"  | cut -f1 -d ":" | head -n 1)
<smoser> well, if youcould tell me if this works, i'd appreciate it.
<smoser> http://paste.ubuntu.com/6070331/
<smoser> i suspect it does
<smoser> sed -n is nothing new.
<PedroAlvarez> -n	Suppress automatic printing of pattern space
<PedroAlvarez> supported here ;)
<smoser> right.
<smoser> it was supported on aix in 1999, so i figure its pretty safe.
<PedroAlvarez> smoser: I will tell you later if it work, thanks for helping
<PedroAlvarez> s/work/works/
<smoser> http://paste.ubuntu.com/6071174/
<smoser> harlowja, ^ is a "shell parser" 
<smoser>  http://paste.ubuntu.com/6071190/
<smoser> and there it runs with 'bash -r'
<smoser> https://gist.github.com/smoser/6466708
<harlowja> holy crap
<harlowja> your shell foo is better than mine, ha
#cloud-init 2014-09-01
<harmw> smoser`: you thre
#cloud-init 2014-09-02
<nvucinic> hi guys, is there any way to find out what can i call in post in phone-home  ?
<harmw> what do you mean? just put in an url and it'll GET (or HEAD) that, perhaps even POST :)
<harmw> yea, I think it supports POST as well - you should just look in the src though, to make sure
<nvucinic> yeah, it supports post, i got the data
<nvucinic> my question was this
<nvucinic> example: http://bazaar.launchpad.net/~cloud-init-dev/cloud-init/trunk/view/891/doc/examples/cloud-config-phone-home.txt
<nvucinic> what can i get except pub_keys and instance id ?
<harmw> ah, you mean which items are available to post
<harmw> or: keys
<harmw> well, you could just look at L9 :P
<harmw> post: all
<harmw> just to get an idea of all available stuff, have it post everything it knows
<nvucinic> let's try all :)
<harmw> :)
<nvucinic> not much, id, hostname and keys
<harmw> well, if you need more you could fiddle in some bash script in user-data
<harmw> a little adventurous, but fun :)
<smoser> nvucinic, yeah, i think there isn't much else. i'm open to adding things.
<nvucinic> smoser: yeah, i looked at script now :) 
<harmw> smoser: PING
<smoser> harmw, whats up?
<harmw> uhm, let me think for just a minute...
<harmw> hm hm, what was it know...
<harmw> :p
<harmw> take a look at the fixes from last week and merge, pretty please :)
<smoser> did you get the tests to pass on linux ?
<harmw> harlowja fixed them
<smoser> sweet
<smoser> i will merge then. thanks.
<harmw> awesome
<harmw> and version bump to a shiny new .tar.gz , so I can submit my fbsd port as well
<smoser> you really need that, eh?
<harmw> if possible, yes
<nvucinic> smoser: is there any way where i can check  what can i get from cloud.get ?
<harmw> even 0.7.5.1 is good enough, ofcourse
<nvucinic> like hostname, instance id ... 
<smoser> harmw, ok. we'll get something this week.
<smoser> nvucinic, let me look.
<harmw> nice!
<nvucinic> smoser: thx :)
<smoser> nvucinic, http://bazaar.launchpad.net/~cloud-init-dev/cloud-init/trunk/view/971/cloudinit/config/cc_phone_home.py
<smoser> unfortunately, it looks like there isnt a lot. 
<smoser> looks like the url can have 'INSTANCE_ID' replaced in it.
<smoser> and the things youi can post are listed at POST_LIST_ALL
<nvucinic> smoser: yeah i replaced instance_id 
<nvucinic> smoser: i see that hosname is defined here all_keys['hostname'] = cloud.get_hostname()
<nvucinic> so cloud.get_hostname is how you get hostname 
<nvucinic> cloud.get_instance_id is how you get instance id
<nvucinic> is there cloud.get_xxx with list of things that i can get  ?
<harmw> probably not that hard to add some stuff to the cloud object
<nvucinic> harmw: yeah, but what else can you get with cloud.get 
<harmw> its not cloud.get_BLA
<harmw> its get_hostname()
<harmw> or get_bla()
<harmw> functions inside the cloud object (?)
<harmw> so look inside for whatever functions are there to call :)
<nvucinic> harmw: great, where can i get list of functions that i can use?: )
<harmw> hehe, browsing the sourcode would be a great place to start
<harmw> I don't think this is listed on readthedocs
<nvucinic> also if you look at http://bazaar.launchpad.net/~cloud-init-dev/cloud-init/trunk/view/971/cloudinit/config/cc_phone_home.py
<nvucinic> it's defined as cloud.get_hostname
<harmw> def handle(name, cfg, cloud, log, args):
<harmw> there's cloud
<harmw> so you kinda just want to lookup what/where cc_phone_home is called from
<harmw> well handle(), that is
<smoser> harmw, nvucinic the cloud object is terribly not well defined. 
<smoser> cloudinit/cloud.py
<nvucinic> yes, i can see that :)
<smoser> nvucinic, so look in ther eand you can see.
<smoser> and you can get cloud.datasource also
<nvucinic> smoser: great, ty
<smoser> which likely has more (not terribly well defined) information.
<smoser> we want to get those settled down to a reasonable strucutre that we can assume is available on all clouds
<nvucinic> smoser: i would like to have ip adress as argument in phone-home script 
<smoser> nvucinic, you can probably get at it.
<smoser> is this ec2, nvucinic  ?
<nvucinic> smoser: no it's that god awful setup with NoCloud 
<smoser> nvucinic, hten its not there. sorry.
<nvucinic> smoser: so custom script would be the right way? 
<smoser> yeah. 
<smoser> you can do a part-handler, or a '#!' 
<smoser> just run some code that reads 'ip' output (or does it in python)
<nvucinic> yeah
<smoser> harmw, would you mind opening a bug for "here is one unresolved issue regarding path resolving of modules (?), which is why there is one DataSource explicitly enabled in the configuration file (and working/being used)."
<smoser> harmw, merged. please test it.
<harmw> smoser: sure thing
<harmw> and thanks :)
<JayF> harlowja: thanks for the comment, I'm going to pick up work on that again today or tomorrow :)
<harlowja> kk
<harlowja> cool
<harlowja> btw, guys something scott and i just threw together, https://etherpad.openstack.org/p/cloud-init-next
<harlowja> comments welcome
<harlowja> additions welcome...
<harlowja> harlowja JayF  ^
<harlowja> harmw i mean
<harlowja> ha
<harmw> harlowja: looks fine to me, though I don't have any higher level additions to share
<harlowja> k
<harmw> well, Windows would be nice ofcourse
<harlowja> windows
<harlowja> argggg
<harlowja> lol
<harmw> like merging some stuff from cloudbase
<harlowja> ya, that one, tried that before :-/
<harlowja> i'm not so looking forward to that
<harmw> hehe
<harmw> smoser: just filed that bug
<smoser> thanks harmw 
<harmw> ok, lets see if the trunk still works :)
<harmw> smoser/harlowja, anyone of you using Designate btw?
<harlowja> not me
<harmw> oh ok
<smoser> not me
<smoser> harmw, bug number ?
<harmw> https://bugs.launchpad.net/cloud-init/+bug/1364580 
<harlowja> hmmm, odd
<harlowja> can we get a log from that happening harmw ?
<JayF> harlowja: is 'work with coreos on their go clone' useful input ;)
<harlowja> that sounds right up there with the windows clone
<harlowja> lol
<JayF> harlowja: I'm 80% kidding, but I did put a note in there about making it easy to vendor your own versions of cloud-init (which go would do)
<harlowja> what does mean 'vendor your own versions'?
<JayF> so right now
<JayF> For Rackspace OnMetal
<JayF> every single one of our images
<JayF> we package and deploy a custom cloud-init
<harlowja> yup, same here
<harlowja> *although not that custom, like 1 patch
<harlowja> or 2
<JayF> This is kind of a pain in the ass because you have to 'lock' the rpm/yum version in place
<JayF> which may break ON dist-upgrade or may just BREAK dist-upgrade
<harlowja> ok ,don't do that lock stuff then ;)
<harlowja> use the vendor provided one ;)
 * harlowja which is what we at y! are trying to get to (using the fedora one)
<JayF> Vendor provided one doesn't support a huge stack of what we're doing
<harlowja> isn't that just getting the code upstream that does that ? :-P
<JayF> (which is why I'm here helping upstream our support, so we get out of this... but you and  I both know if it goes upstream now I'm still packaging my own for 5+ yrs)
<harlowja> hopefully more like 2 years
<harlowja> haha
<harlowja> ;)
<JayF> It's not :(
 * JayF is also working on kernel version support for CentOS 6.5, which is Old Software(tm)
<harlowja> overall yes though i know, avoid the fork hell at all possible
<JayF> I'd say model that into upstream
<harlowja> 6.5 isn't that old, thats brand new
<harlowja> we have 5.8 images lol
<JayF> cloud-init should assume that a lot of vendors will be packaging cloud-init and make it easier
<harlowja> sure, so then what part not easy?
<JayF> harlowja: Yeah, it doesn't seem bad, but even a few years with an older kernel makes huge perf differences.
<JayF> Python generally doesn't make it easy :)
<JayF> right now, like I said, we're just building a new RPM for a distro and 'lock'ing it there
<harlowja> so more of what u are getting at is the go statically linking model?
<JayF> but some supported 'omnibus' style install (like opscode uses for chef w/the ruby "omnibus" stuff)
<JayF> I'm getting at I want to be able to deploy and run a 'tarball' or single file or something very isolated of cloud-init
<harlowja> right, the same as statically linking
<JayF> well except statically linking is an implementation of my requirement :)
<harlowja> sure sure
<JayF> I'm specifically not saying statically link it because I know that's mostly a nonstarter
<harlowja> so then if we remove more of dependencies in http://bazaar.launchpad.net/~cloud-init-dev/cloud-init/trunk/view/head:/requirements.txt 
<harlowja> what about that?
<JayF> think about it more this way:
<JayF> as a vendor providing a cloud server
<JayF> *service
<JayF> we need to be able to iterate quickly on cloud-init just like we can on our cloud
<JayF> packaging is somewhat of a difficulty there currently, among a bucket of other things :)
<harlowja> sure
<harlowja> believe me i know, lol
<harlowja> but it still feels like a hammer looking for a nail
<JayF> the other thing is maybe a philisophical shift: we want a mechanism to update a *booted* system
<JayF> i.e. I attach some kind of 'cloud storage' volume, update the metadata service to reflect that, and my cloud init data source sees that, and mounts the volume
<harlowja> ya, smoser  has thoughts about that as well afaik
<JayF> our use case gets more interesting because we want cloud-init (and other software) to do a lot of the tasks relegated today to a hypervisor
<JayF> because hypervisors are for people who want to do things easy :P (just kidding, although it feels that way sometimes :D)
<harlowja> what about helping build out something like https://github.com/cloudcadre/giftwrap
<harlowja> https://github.com/cloudcadre/giftwrap#giftwrap
<smoser> hm.. on a call, will look above later
<harlowja> JayF afaik the above does something like what u want
<harlowja> https://github.com/cloudcadre/giftwrap#how-it-works
<harlowja> so thats why i wonder if its more of a problem thats outside cloud-inits scope
<JayF> harlowja: IMO the problem is more on the other side
<harlowja> how so?
<JayF> harlowja: I build the package, install it in my default image, customer upgrades, gets a 'newer' version of cloud-init that doesn't have my patches, and cloud-init re-runs and does $unexpected_things because it doesn't support our data source
<JayF> or if you do a package manager 'hold' in the distro, you restrict the customer from upgrading entire classes of packages
<JayF> I don't know how to solve this problem, tbh, but I think something along the lines of chef-omnibus packages have to be the way
<harlowja> hmmm, ok, sounds like u need smarter customers ;)
<harlowja> problem solved!
<harlowja> ha
<JayF> because then I never install distro cloud-init in my images, I install cloud-init-omnibus which puts everything in /opt/cloud-init/ and depends on nothing outside that dir (except maybe libc) to run
<JayF> harlowja: Our entire spiel at Rackspace is Managed [cloud|server|etc]... my job is to help write software to enable that.
<JayF> harlowja: which means I'm the smarter customer :)
<harlowja> :)
<harlowja> i just start to wonder if there is something wrong though, like amazon afaik doesn't need to do this, yahoo has so far gotten along just fine without this kind of isolation thing, so is it really a problem that we have to resolve by isolating all of cloud-init (and its own version of python and dependencies) to say /opt/cloud-init
<JayF> I'd venture to say I'm feeling this pain right now
<JayF> because we're doing /new things/
<JayF> nobody before us, afaik, has run a public, software-operated, bare metal API-driven provisioning system
<harlowja> sure sure
<JayF> We're using network configs that are different (vlans on top of bonding)
<JayF> on top of all that :)
<harlowja> ontop of nicira? 
<harlowja> ;)
<JayF> fwiw our first major cloud-init change was to stop excluding disk partitions from consideration when looking for configdrives
<JayF> harlowja: today, no actually :( $vendor_reasons
<harlowja> ya, i know about some of that i think ;)
<JayF> We
<JayF> We've blogged about some of it in various places
<harlowja> ya, i just start to wonder if this is really a good way to go down
<harlowja> all of yahoo typically gets installed in /home/y/ and that really has not turned out so well over the years
<JayF> hah :)
<harlowja> to much packages that forget to get managed that someone forked to adjust to fit into /home/y...
<JayF> have you seen/used omnibus installed chef?
<harlowja> not personally, some other people are
<JayF> https://github.com/opscode/omnibus
<JayF> as a pattern I don't think this is bad
<JayF> kinda an uglier fork of the container pattern, really
<JayF> just ship a package, with all it's deps shoved into a dir away from the rest of the os
<harlowja> ya, i'm not sure what yahoo is replacing it with (something chef afaik) 
<JayF> it's ugly I'm sure when you get to the level of installing entire sub-operating systems in ~y/
<harlowja> yup
<JayF> but your configuration system (be it chef, cloud-init, whatever) being able to install and run regardless of what OS deps are installed
<JayF> could be a valuable thing
<JayF> again sorta goes to the world view of a tool like cloud-init being 'out of band' similar to a hypervisor... even though obviously it's not :)
<harlowja> ya, i'd be +2 to cloud-init in the kernel
<harlowja> like kvm 
<harlowja> lol
<harlowja> i'm sure linus would be fine with that
<JayF> HAH
<JayF> but you get the general worldview I'm looking with?
<harlowja> ya
<harlowja> i do
<harlowja> although i still have mixed feelings about it, knowing past experiences :-P
<harmw> harlowja: you broke my fbsd code!
<JayF> the ability to configure the image to utilize $cool_things in my cloud means I need to be able to update cloud-init rapidly as I build $cool_things
<harlowja> harmw i might have, ha, who knows
<harmw> my branch was working, but trunk now doesn't
<harlowja> JayF ya, sure, thats just a slipper slope of becoming your own distro ;)
<harlowja> harmw i blame smoser 
<harlowja> lol
<harmw> :P
<JayF> and while I don't expect that long-term to be a 'fork' as it is right now... I do expect to continue to want to run pretty close to 'master' cloud-init ... especially when talking about versions shipped in old (>1y old) distros
<JayF> harlowja: heh, we'd not be A distro... we'd be a fork of /every/ distro which is why I'm talking to you guys upstream trying to solve the problem in a better way for everyone than just me doing something on my own
<harlowja> isn't that called the 'JayF distro' (with description being a ' a fork of /every/ distro')
<harlowja> lol
<JayF> hah
<JayF> It's called coroes
<harlowja> but better!
<JayF> *coreos
<harlowja> lol
<harlowja> jayfos
<JayF> and all my 'forks' are containers
<JayF> dude if I had my own distro
<JayF> it'd be called Old OS
 * JayF runs oldos.org
<harlowja> lol
<harlowja> nice
<harmw> btw harlowja I put an example in that bugrport
<harlowja> harmw that log looks fine :-/
<harlowja> 'Using distro class <class 'cloudinit.distros.freebsd.Distro'' ?
<harlowja> looks like its trying the openstack one
<harmw> 2014-09-02 19:47:06,862 - importer.py[DEBUG]: Failed at attempted import of 'freebsd' due to: No module named freebsd
<harmw> 2014-09-02 19:47:06,892 - stages.py[DEBUG]: Using distro class <class 'cloudinit.distros.freebsd.Distro'>
<harlowja> ya, look at the line after that
<harlowja> its basically logging teh attempts
<harlowja> ya, perhaps i should shutup that log
<harmw> i posted another one
<harmw> nah wait, let me post one with specifying the datasource in cloud.cfg
<harmw> Ill do that later on
<harlowja> kk
<harlowja> i'm gonna shutup that log that says failed imports
<harlowja> to confusing
<harlowja> u aren't the first to say wtf it failed importing
<harlowja> when it really didnt, ha
<harmw> yea, Ill try and find out why the F fbsd is failing on me right now with trunk code
<harlowja> kk
<harlowja> JayF anyways, lets see what smoser thinks, he's from more of the world of distro-land than i am
<harlowja> yahoo i know is trying to move forward with stuff like docker and all, so i can see how it might all work out 
<JayF>  I am trying to move forward with stuff like docker and all :) 
<JayF> but I have to support whatever reasonable patterns my customer wants
<JayF> s/customer wants/customers want/
<harlowja> ya, although sometimes customer not doing the right thinkg ;)
<harlowja> *thing
<JayF> that's where the 'reasonable' part comes in :)
<harlowja> ;)
<smoser> harmw, i'm being asked for cirros 0.3.3 with mtu fix.
<harmw> don't we have that already?
<harmw> the fix, that is
<harmw> or is that to a pending merge?
<smoser> i forget. i thought maybe i had it with other changes. let me look if we can easily do a 0.3.3 
<smoser> that has it.
<harmw> there is some code from me (?) in LP to adress this
<harmw> udhcpc wrapper stuff
<harmw> smoser: https://bugs.launchpad.net/cirros/+bug/1301958
<smoser> right
<smoser> +## currently disabled as it depends on busybox and buildroot
<smoser> +## version numbers (in the patch paths).
<smoser> +## note, that without this the cirros-udhcpc is inert, but unoffensive
<smoser> that was why it was non-trivial
<harmw> ahyes, you had to upgrade buildroot first
<harmw> hmgrr, setting the hostname is broken in my fbsd code... it doesn't set what it got from metadata, but instead re-uses `hostname`, or something
<harmw> ah, so datasource.get_hostname() is returning that
<harmw> bingo: why is it entering this... if self.metadata or 'local-hostname' not in self.metadata:
<smoser> later all. i have to run.
<gholms> o/
<harmw> harlowja: http://bazaar.launchpad.net/~cloud-init-dev/cloud-init/trunk/revision/1000.1.1/cloudinit/sources/__init__.py
<harmw> I believe that has brutally broken the setting of hostnames
<harmw> atleasy in my current testing of the fbsd module
<harmw> since I just confirmed to have a perfectly fine hostname (host.bla.tld) inside self.metadata['local-hostname']
<harmw> so please revert that smoser or harlowja :)
<harlowja> ya, seems like it could
<harmw> JayF: you broke it :p
<harlowja> harmw lets see what JayF thinks, i wonder if that was just a mistake
<harmw> I'm guessing thats a yes :)
<harlowja> me to
<JayF> wait what
<harmw> oh well, it's always nice to gte the oppertunaty to dive in to the inner workings of c-i :P
<harlowja> ;)
<JayF> oh man I have a handful of changes like that :(
<harmw> lets hope your hands are small, shall we :P
<JayF> Ooooh, I see how this one changes the logic
<harlowja> pretty sure its 'if not self.metadata or 'local-hostname' not in self.metadata: '
<harlowja> or supposed to be ^
<JayF> pep8 screams about that
<harlowja> odd
<harmw> the old line was fine though, just reverted it locally and *everything* just works now :)
<JayF> harmw: make pep8 will fail though, I presume :(
 * JayF might be too used to being able to trust unit tests
<harmw> don't know, I don't have alle the test tools in this instance to verify
<harlowja> let me try
<harlowja> harmw JayF https://code.launchpad.net/~harlowja/cloud-init/fixer-up/+merge/233126 
<harlowja> also https://code.launchpad.net/~harlowja/cloud-init/better-errors/+merge/233125
<harlowja> seems like pep8 doesn't complain about 233126
<harlowja> and retains the same old logic
<JayF> gimme one sec, fixing a network issue
<JayF> should we also write a check to catch this instance?
<JayF> s/check/test/
<harlowja> probably
<JayF> if you say pep8 works, then +1 to the change
<harmw> harlowja: 126 is spot on
<harlowja> ya, (cloud-init)harlowja@getlookcrowd[0]:~/dev/os/cloud-init $ pep8 cloudinit/sources/__init__.py 
<harlowja> (cloud-init)harlowja@getlookcrowd[0]:~/dev/os/cloud-init $ 
<harlowja> no errors/complaints
<harmw> god, and this only took 2 precious hours of my tonight-time..
<JayF> harmw: :( I'm sorry man
<harmw> and you should!
<harmw> :p
<harmw> nah, I've seen worse
<harmw> harlowja: you're merging this? or do you need permission from the supreme uber godlike master wizard?
<harlowja> harmw i can merge, although i'll just let smoser to,  where'd he go
<harlowja> i usually just delegate to him ha
<harmw> :>
<harlowja> :)
<harmw> well, other than this the fbsd code works btw. Having it set the hostname and adding a user+ssh key wrks just fine
<harlowja> cool
<JayF> I can't pull this right now, merge it if you think it's right
<JayF> sorry :( dealing with local network stuff 
<harlowja> ya, i'll let smoser pull it in unless its so critical can't wait
<harlowja> then i'll try to remember the merge stuff, haha
<JayF> harmw: we were just talking around here the otehr day about how neat it'd be to have fbsd support :)
<JayF> harmw: (here=rackspace onmetal)
#cloud-init 2014-09-03
<harmw> JayF: cool :)
<harmw> onmetal.. so that means the ironic (sub)project, right?
<harmw> i've been wanting to check that out, someday :)
<harlowja_at_home> harmw, i believe onmetal is the rackspace product that uses ironic (probably +- some other rackspace glue)
<harlowja_at_home> but i might be wrong to ,haha
<harmw> haha
<harmw> but yes, I think youre right :)
<harmw> isn't it a bit late for you btw?
<JayF> harmw: yeah, myself and many others on my team are active in Openstack Ironic :)
<JayF> and we don't have that much other rackspace glue there... just lots of patches/features that are pending merge upstream
<harmw> JayF: cool
<harmw> smoser: PING
<smoser> harmw, hey.
<harmw> ah great
<harmw> we need you to merge something :P
<harmw> (since, why else would we need you)
<smoser> exactly
<harmw> smoser: https://code.launchpad.net/~harlowja/cloud-init/fixer-up/+merge/233126
<harmw> that one
<smoser> harmw, done.
<smoser> sorry.
<smoser> :-(
<harmw> haha np
<harmw> and thanks
<harmw> I'm working on 2 fixes btw, hopefully you can add those as well
<harmw> smoser: https://code.launchpad.net/~harmw/cloud-init/freebsd-fixes/+merge/233247
<smoser> harmw, so does that acutally work ?
<smoser> writing to that sudoers path ?
<harmw> yup
<smoser> does it work as in sudo reads it ?
<harmw> yes
<smoser> this all feels like slackware
<harmw> welcome to fbsd :P
<smoser> and reminds me of a simpler time in 1998.
<harmw> ah yes, 1998... reminds me of highschool :>
<RaginBajin> smoser I've been working on the changes you recommened to me in https://code.launchpad.net/~josephbajin/cloud-init/freebsd-configdrive/+merge/231214
<RaginBajin> and I got one of this fixed, but I honestly have no idea how to fix the second
<smoser> RaginBajin, ok. i can maybe help in 30 minutes or so.
<smoser> sorry, in a call now
<RaginBajin> Take your time.. I've been super busy with some other stuff lately, which is why I have disappeared for a little 
<smoser> RaginBajin, maybe you didn't push ?
<RaginBajin> yeah let me do that one. 
<smoser> last commit is shown as 2014-08-18
<RaginBajin> ok just pushed the update I made
<harlowja> hiren_ yt
<RaginBajin> it removes the lazy mode for umount
<harlowja> hiren_ the freebsd stuff afaik merged, so if u wanted to try it out maybe harmw can give some basic instructions?
<harlowja> oh, smoser also https://code.launchpad.net/~harlowja/cloud-init/better-errors 
<harlowja> more log cleanup
<smoser> harlowja, danke
<harlowja> np
<harlowja> that one was noisy and confusing
<harlowja> so fixed it, lol
<hiren_> harlowja: ah, let me get to it later today or tomorrow
<hiren_> thanks
<harlowja> np
<RaginBajin> smoser, I'm going to hop back on later or tomorrow. I got to run here in a few.  We can talk about my changes then. too much work not enough time
<harmw> smoser: think you can merge that last bit as well?
<smoser> harmw, will ead in a bit. sorry
<harmw> ah great, nice :)
<harmw> smoser: merge.. ;)
<smoser> harmw, i'm sory. time just goes away.
<harmw> hehe yea i know :)
<harmw> don't we all have that damn problem
<harlowja> not me, ha
#cloud-init 2014-09-04
<mhroncok> smoser: hi, got a minute?
<smoser> mhroncok, whats up?
<mhroncok> smoser: I wan to talk with you about cloud-init and Python 3
<mhroncok> smoser: cloud-init is the last thing in Fedora cloud stack, that doesn't support Python 3
<mhroncok> smoser: and we would like to make it happen
<mhroncok> how can we help?
<smoser> its on a list, and it should have been done alrady.
<smoser> i'm open to patches for that. we've done some work in that direction (dropping boto and cheetah recently)
<mhroncok> there are several relevant issues opened, but it seems nothing is happening, so we we would be happy to help with patches - however we are not sure what should we focus on first
<mhroncok> BTW boto now supports Python 3
<mhroncok> I've seen this: https://code.launchpad.net/~harlowja/cloud-init/changeable-templates/+merge/208994
<mhroncok> so now it should only be about cloud-init itself?
<smoser> i didn't know about boto and python3, thats good. yeah, it should be only cloud-init itself.
<mhroncok> is there any branch for python 3 porting or stuff liek tyhat, or we should just start with trunk?
<mhroncok> s/liek tyhat/like that/
<smoser> trunk. 
<smoser> harlowja_away, may have taken some further look at it.
<mhroncok> smoser: ok, thanks for info
<smoser> i think it makes sense to get to python3 support in cloud-init.
<smoser> there is some discussion about doing a cloud-init 2.0, which would start with python3 as the starting point.
<smoser> and probably not bother with python2 support
<mhroncok> smoser: is there a way to send patches, but don  not sign CCA?
<smoser> i'm sorry, there is not. 
<smoser> contributors agreement are required i many projects.
<mhroncok> I'm not even sure I can sign that, will consult my boss :)
<jfontan> hi
<jfontan> I am doing some modifications to a cloud init datasource
<jfontan> but I am unable to get the error
<jfontan> I only get a warning saying "Getting data from <clas...
<jfontan> I only get a warning saying "Getting data from <clas...> failed
<jfontan> is there any way I can see the errors?
<smoser> jfontan, maybe /var/log/cloud-init.log has an error ?
<jfontan> nope, that is the only error
<jfontan> I've added a traceback print to may copy of cloud-init
<jfontan> in find_source
<jfontan> may=my
<smoser> jfontan, you should get something else along side that error.
<jfontan> it only said it failed
<jfontan> it was an error in the code
<jfontan> but the exception blod just printed that it could not get the data
<jfontan> block
<jfontan> here
<jfontan> http://bazaar.launchpad.net/~cloud-init-dev/cloud-init/trunk/view/head:/cloudinit/sources/__init__.py#L255
<smoser> harmw, what do you need me to merge ?
<smoser> jfontan, yeah, but it should log a stack trace
<jfontan> it didn't for me
<smoser> can you pastebinit ?
<smoser> the whole log ?
<jfontan> I'll have to create the image again
<jfontan> as I don't have the error in the code anymore and it has the trace print in. I'll check if I have an old vm
<jfontan> smoser, https://gist.github.com/jfontan/bcf18f262cd06252ff1a#file-gistfile1-txt-L13
<jfontan> it only says that it failed but no stacktrace
<jfontan> I'm using trunk
<smoser> so the error you see there is the one you added ?
<smoser> the stack trace 
<harlowja> smoser did i hear python3
<harlowja> lol
<jfontan> nope, I took out the strack trace printing code
<jfontan> the error is in OpenNebula Data source
<jfontan> and just tells it failed
<jfontan> no stacktrace
<smoser> hm.. that is odd. i dont know why. 
<jfontan> there is an stacktrace for openstack but that's something I'm not working on
<smoser> yeah, and that is wrong. 
<smoser> you're using turnk her e?
<jfontan> yes
<smoser> harlowja, you see that ^ . 
<smoser> that should probably not be a fail
<harlowja> whats the trace?
<smoser> but rather a "no datasource here, move along"
<smoser> https://gist.githubusercontent.com/jfontan/bcf18f262cd06252ff1a/raw/960d80f5263ebbe909ab786ef1ece8bc5d04cda6/gistfile1.txt
<harlowja> smoser hmmm, will fix
<jfontan> it's a failure. I mistyped a variable
<smoser> and any idea why we wouldnt get a log
<smoser> of that failure there.
<smoser> for the 'DataSourceOpenNebula' line
<jfontan> it could be the code in data source
<jfontan> maybe it's catching all exceptions
<smoser> well, it is.
<jfontan> I'll take a look
<smoser> but then it calls 
<smoser>  util.logexc(LOG, "Getting data from %s failed", cls)
<jfontan> so that logexc should print the trace, isn't it?
<smoser> yeah.
<jfontan> I have to go
<jfontan> good luck
<harlowja> smoser https://code.launchpad.net/~harlowja/cloud-init/mini-os-fixes/+merge/233399
<harlowja> mhroncok also https://code.launchpad.net/~harlowja/cloud-init/py2-3 for your py3 messages
<harlowja> thats the branch that imho will enable mixed py2/py3 mode
<harlowja> which will be required for older distros that aren't all py3 yet
<mhroncok> harlowja: great, thanks
<harlowja> i did some basic testing from what i remember with py3 and pretty sure i nailed most of the issues down
<mhroncok> BTW harlowja smoser, cannot I just give you my patches as Public domain?
<harlowja> mhroncok smoser  probably knows better than i all that stuff, i never got into the legal stuff :-P
<smoser> mhroncok, i dont think so.
<mhroncok> ok, waiting to hear from our legal :D
<smoser> harlowja, i don think you fixed https://gist.githubusercontent.com/jfontan/bcf18f262cd06252ff1a/raw/960d80f5263ebbe909ab786ef1ece8bc5d04cda6/gistfile1.txt
<smoser> in mini-os
<smoser> mini-os-fixes
<harlowja> k, maybe i misunderstand ?
<smoser> so in that log
<smoser> hm..
<smoser> oldd.
<harlowja> 'openstack.py[ERROR]: Failed reading mandatory path /tmp/tmpX2lt9o/openstack/latest/meta_data.json' ?
<harlowja> thats now demoted to debug
<smoser> i have to look at this more. i didn't hitnk he had a config drive there.
<smoser> oh i see.
<smoser> so that would be debug, but then there is / should be no ERROR 
<harlowja> _fetch_available_versions() takes exactly 1 argument (2 given) also should be fixed
<smoser> agreed there.
<smoser> i thought what had happend there was that there was no config drive
<smoser> and that should result in the DSs' _get_data() returnning False
<smoser> with only debug messages
<harlowja> sure, i just think the differeniation between searching for get_data that will work and actually using a get_data that then fails isn't clear
<harlowja> thats probably part of it
<harlowja> maybe should be refactored to find_data (which then only outputs debug messages) and get_data (which actually outputs errors)
<harlowja> sepearting the non-failure find process from the actual problems get_data 
<harlowja> there sorta munged together at this point 
<smoser> well, _get_data returns True on "I've found"
<smoser> and False on "nope"
<harlowja> right, but say it had a finding method, this one would return True/False, then it had a read method that would read from the previous location found (if it was) and would log errors and such
<harlowja> the find method would be expected to never log errors and such
<harlowja> but the read method could (instead of what we currently do is make everything debug, since we are doing both find and read in the same method)
<smoser> i agree, it can be better.
<smoser> harlowja, can you fix that though ?
<harlowja> hehe, what i'm supposed to fix? 
<harlowja> lol
<smoser> it needs to be debug only on "not found"
<smoser> and ideally not stack trace :)
<harlowja> right, https://code.launchpad.net/~harlowja/cloud-init/mini-os-fixes/+merge/233399 switches those to debug ?
<harlowja> with no stack-trace
<harlowja> but i might still be confused, lol
<harlowja> oh, i think i see one more
<harlowja> ok, think i got them (reuploaded)
<smoser> how did it do no stacktrace
<harlowja> except openstack.NonReadable:
<harlowja>             return False
<harlowja> probably that
<harlowja> except openstack.NonReadable:
<harlowja>             return False
<harlowja>         except (openstack.BrokenMetadata, IOError) as e:
<harlowja>             LOG.debug("Broken metadata address %s: %s",
<harlowja>                       self.metadata_address, e)
<harlowja>             return False
<harlowja> shall that be changed?
<harlowja> or similar in 'DataSourceConfigDrive'
<harmw> smoser: https://code.launchpad.net/~harmw/cloud-init/freebsd-fixes
<harmw> https://code.launchpad.net/~harmw/cloud-init/freebsd-fixes/+merge/233247 
<smoser> harmw, tried to build the cirros with patched busybox
<smoser> but busubox didn't get patched
<smoser> not sure why
<harmw> sorry man, this time it's me beeing way to busy :)
<smoser> harmw, no worries.
<smoser> it seems like an easy fix
<smoser> http://paste.ubuntu.com/8253590/
<harmw> hm, that makefile change... can't recall i needed that
<smoser> no
<smoser> you didn't
<smoser> that was debug
#cloud-init 2014-09-05
<harmw> smoser: I'd hardly call that a fix :p
<harmw> smoser: think you can merge those last bits regarding freebsd?
<harmw> hiren_: ping
<smoser> harlowja_away, http://paste.ubuntu.com/8260489/
<smoser> digital ocean has user-data now, and the ec2_utils.MetadataMaterializer is able to crawl it.
<smoser> and utlemming they add vendor-data
<smoser> :)
<harmw> smoser: you worked out something about cirros?
<smoser> harmw, either you or i broke htat script
<smoser> and possiby i
<smoser> but i thin kwe might be good now. 
<smoser> and i'm thinking about putting that into trunk.
<harmw> ok, cool
<harmw> well my branch certainly compiles :p
<smoser> some openstack-qa people were asking for mtu
<smoser> so i was going to try to get that in as 0.3.3
<harmw> nice 
<harmw> I think ill be able to testdrive something tonight
<hiren_> harmw: hey!
<harlowja> smoser thats good right? (the digitial ocean stuff)
<smoser> harlowja, yeah. really good. 
<harlowja> woot
<smoser> really nice that it worked.
<harlowja> who wrote that awesome metadata stuff
<harlowja> oh i know
<harlowja> hahaha
<smoser> the one thing that was weird
<smoser> _decode_leaf_blob
<smoser> it returns a list of blob.splitlines()
<smoser> which is kind of odd.
<smoser> as in this case, using it got vendor-data and user-data as an array
<harlowja> ya, i wonder why i did that, ha
<harlowja> my guess is boto does that
<harlowja> so i do that
<smoser> well, it was really for metadata only
<smoser> which, in amazon, any leafs might be lists.. i'm not even sure if there are any leafs with newlines in them.
<harlowja> https://github.com/boto/boto/blob/2.15.0/boto/utils.py#L278
<harlowja> sorry 281 there
<smoser> right, but no ton leafs.
<smoser> oh. hm..
<smoser> maybe it makes sense there.
<smoser> i dont know.
<harlowja> want to change that?
<smoser> but since 'user-data' and 'vendor-data' are relaly just blobs in that MD
<smoser> we dont want them interpreted in this case
<smoser> have to see i guess.
<harlowja> kk
<smoser> maye just make it a method you can pass in 
<smoser> to render your own leafs
<smoser> or you could subclass it too
<harlowja> who would be subclassing it?
<smoser> well, in this case i would :)
<smoser> for the digital-ocean reader
<smoser> harmw, http://bazaar.launchpad.net/~cirros-dev/cirros/trunk/revision/317
<smoser> that gets your cirros-udchpc stuff functional in trunk.
<harlowja> smoser do u want to try the boto reader, and see what it returns just to double check?
<smoser> functional in that it had some bugs that i' not sure were your fault or mine (quite possibly my changes). and also actually enables patching of buildroot's busybox so we use it.
<smoser> sure
<harlowja> otherwise sure, i can make it more pluggble
<smoser> wow.
<smoser> i didn't realize the boto one was like it was
<harlowja> ?
<smoser> doing the json.load 
<smoser> i thought you had added that.
<harlowja> never
<harlowja> ha
<smoser> line 278 htere is kind of wierd
<smoser> if it starts with { , then its *obviously* json :)
<harlowja> lol
<harlowja> of course!
<harlowja> thats why i put maybe_json_object
<harlowja> cause maybe it is, haha
<harlowja> smoser https://code.launchpad.net/~harlowja/cloud-init/customized-leaf-decoder/+merge/233565
<harlowja> have fun :-
<harlowja> :-P
<smoser> mixed leaf decoder
<smoser> i like the name
<harlowja> :)
<harlowja> another thing we can do with the doc cleanup/make betterness is start to use https://pypi.python.org/pypi/doc8 (which i helped create/am the main person making); its getting sucked into most openstack tox.ini files for sanity checks on docs
<harmw> smoser: I hope my buildservice picks up that cirros change ;)
<harmw> you planning a new release ?
<smoser> harmw, yeah, building something as 0.3.3~pre1 right now.
<smoser> and then if that looks sane, which i think it does from my test builds, then we just call 0.3.3
<harmw> cool
<harmw> dont forget th fbsd stuff ;)
<smoser> yeah. i know.
<smoser> harmw, looking
<smoser> harmw, what about the config drive stuff that Rajun.. was doing
<smoser> is that important ?
<smoser> i think probably, for config drive at least
<harmw> yea, but I'm afraid I haven't looked at it
<harmw> so I don't realy have an opinion on it
<harmw> let me build an update pkg for fbsd first, and then I'll think something of it :)
<smoser> harmw, done.
<harmw> ah nice
<harmw> smoser: that stuff from Ragin looks fairly ok
<harmw> old functionality is still in place, and I'm asuming he tested if it works on fbsd
<alexpilotti> smoser: morning!
<smoser> alexpilotti, its not morning
<smoser> but ok
<smoser> :O)
<alexpilotti> smoser: what do you think about having -z in nc, on cirros? :-) 
<alexpilotti> smoser: In tempest we need to test security groups, checking if a given port is open, cross-tenant 
<alexpilotti> smoser: aka cirros -> cirros
<smoser> is it something you can just turn on ?
<alexpilotti> smoser: we need to update nc in the cirros image
<alexpilotti> smoser: I mean, we can go with workarounds of course
<alexpilotti> sbut if you can easily update it, it would be nice
<smoser> no. sorry.
<smoser> was a question as to if it *can* be turned on in cirros
<alexpilotti> not really
<smoser> do you know if turning on NC_110_COMPAT will do it ?
<smoser> alexpilotti, http://git.busybox.net/busybox/tree/networking/nc.c
<smoser> it seems like that might do it.
<alexpilotti> smoser: as in uploading the file and compiling it in place during the test?
<smoser> well, no. i have to enable it.
<smoser> but i'm wondering if that would be sufficient for you
<alexpilotti> ah ok perfect
<alexpilotti> yep, it looks very ok
<alexpilotti> in what cirros version do you think you could get it in?
<smoser> well, hopefully i could just turn that on for 0.3.3
<smoser> which i was hoping would be "real soon now"
<smoser> harmw, 0.3.3~pre1 is there now
<smoser> i'll plan on trying a build with alexpilloti's request
<smoser> and if that seems to not completely crash 'nc', then i guess we'll just call that 0.3.3
<alexpilotti> smoser: tx! :-)
#cloud-init 2014-09-06
<harmw> smoser: ok
<harmw> but if you're into muddling with busybox, adding in some ipv6 tools would be very helpfull as well
#cloud-init 2015-08-31
<openstackgerrit> Claudiu Popa proposed stackforge/cloud-init: Add an API for loading a data source  https://review.openstack.org/209520
<Seth_Kar_> Hey all, can anyone assist me with debugging chef on CentOS 7? I've already figured out to turn off SELinux, but if I run cloud-init --debug single -n chef it doesn't give any information. If I reboot I just get an error saying the cc_chef python module failed
<Seth_Kar_> Is there any way to increase this verbosity during the reboot, or a way to properly re-run cloud-init after I have a shell?
<smoser> Seth_Kar_, you likely have something in /var/log/cloud-init.log
<smoser> look for WARN
<smoser> if you do not, then edit /etc/cloud/cloud.cfg.d/05_logging.cfg and comment out the line ' - [ *log_base, *log_syslog ]'
<smoser> you should also have output in /var/log/cloud-init-output.log
<Seth_Kar_> smoser: I have the following WARN errors
<Seth_Kar_> Aug 31 17:16:35 localhost cloud-init: 2015-08-31 17:16:35,047 - cloud-init[WARNING]: Stdout, stderr changing to (| tee -a /var/log/cloud-init-output.log, | tee -a /var/log/cloud-init-output.log)
<Seth_Kar_> Aug 31 17:16:35 localhost cloud-init: Cloud-init v. 0.7.5 running 'modules:config' at Mon, 31 Aug 2015 15:16:35 +0000. Up 6.15 seconds.
<Seth_Kar_> Aug 31 17:16:35 localhost cloud-init: 2015-08-31 17:16:35,509 - util.py[WARNING]: Running chef (<module 'cloudinit.config.cc_chef' from '/usr/lib/python2.7/site-packages/cloudinit/config/cc_chef.pyc'>) failed
<Seth_Kar_> smoser: The same error is in /var/log/cloud-init-output.log
<Seth_Kar_> Is there a way to manually run the chef recipe with additional debugging?
<smoser> there should be some message about what failed, or a stack trace or something.
<smoser> 'run the chef recipe' ?
<Seth_Kar_> There is no message, it just says failed
<Seth_Kar_> The running chef error is the only error I get
<Seth_Kar_> Can I call the python script from the shell to debug?
<smoser> as you did, 'single -n chef'
<smoser> it really should have a sack trace or some thing .
<smoser> can you pastebin the cloud-init.log and cloud-init-output.log ?
<smoser> i realize you might potentially have sensitve infor ther
<harlowja_at_home> i also have messed with the chef stuff at one point, so let me know to :)
<harlowja_at_home> but usually its always smoser fault
<harlowja_at_home> lol
<openstackgerrit> Merged stackforge/cloud-init: Add an API for loading a data source  https://review.openstack.org/209520
<smoser> claudiupopa, ^ that merged, please do add the 'version=' thing.
<claudiupopa> thanks!
<Seth_Kar_> smoser: harlowja_at_home: https://gist.github.com/Seth-Karlo/266ecc9d5618f0b5b9cf
<harlowja_at_home> hmmm
<harlowja_at_home> any idea whats in '/var/log/cloud-init-output.log'?
<Seth_Kar_> If I run it on CentOS 6 I get a different error
<Seth_Kar_> Sure, hang on
<smoser> and /var/log/cloud-init.log .
<smoser> what you did above makes perfect sense that it *should* show stuff.
<smoser> but... get /var/log/cloud-init.log
<Seth_Kar_> Only two lines in /var/log/cloud-init-output.log
<Seth_Kar_> 2015-08-31 17:59:53,589 - cloud-init[DEBUG]: Logging being reset, this logger may no longer be active shortly
<harlowja_at_home> hmmm
<Seth_Kar_> Cloud-init v. 0.7.5 running 'single' at Mon, 31 Aug 2015 15:59:53 +0000. Up 2603.45 seconds.
<Seth_Kar_> No change to /var/log/cloud-init.log
<harlowja_at_home> bb, irc meeting
<Seth_Kar_> Np
<harlowja> k, back
<smoser> Odd_Bloke, you have a minute ?
<smoser> i'm trying to get my changes for reporting that i've most recently have in curtin into c loud-init (so you can be happy and they'll be synced).
<natorious> are you guys doing weekly or bi-weekly openstack meetings for this proj?
<smoser> natorious, we have a weekly meeting at 14:00:00 UTC
<smoser> in this channel.
<natorious> smoser: ty sir.  Added to cal
<natorious> which day though lol?
<smoser> oh silly me
<smoser> wednesday
<natorious> there is another linux dev from rax that will be helping out too.  I'll pass this info along :)
<jlambert121> i'm working on setting cloud-init up on a centos7 AWS image.  i'm trying to figure out how to disable the default centos yum repos (we have internal mirrors).  i can add/configure new repos without problem, but i can't seem to get [base] "enabled: false" set
<jlambert121> if someone has an example link/insight it would be greatly appreciated
<gamename> hi guys.  I'm trying to figure out what "disable-ec2-metadata" does.  Should I take that out if I want to use metadata?
<smoser> gamename, it defaults to false
<smoser> all that does is run the config module
<smoser> the config module, if it sees 'disable_ec2_metadata: true'
<smoser> then it will null-route the metadata service
<smoser> that way if you had sensitive data there, no one could see it without rooting system first.
<smoser> http://bazaar.launchpad.net/~cloud-init-dev/cloud-init/trunk/view/head:/doc/examples/cloud-config.txt#L249
<smoser> jlambert121, maybe harlowja can say. i have to run, sorry.
<jlambert121> smoser: thanks.  i've been banging on this all day without luck.  trying to get a bootcmd of 'rm -f /etc/yum.repos.d/*' to work right now, but it's an ugly hack
<jlambert121> harlowja: if you have any other thoughts that'd be appreciated
<gamename> smoser: Thanks!
<gamename> smoser: "package_update"  defaults to "true". Correct?
<harlowja> jlambert121 smoser ya, pretty sure that should disable the route stuffs
<jlambert121> harlowja: i was trying to figure out how to modify the default yum repos on an image - thoughts?
<harlowja> i think https://github.com/stackforge/cloud-init/blob/0.7.x/doc/examples/cloud-config-yum-repo.txt#L2 can be used to overwrite existing ones, but haven't tried it in a while
<harlowja> or u can use the write files approach to write out new files
<harlowja> https://github.com/stackforge/cloud-init/blob/0.7.x/doc/examples/cloud-config-write-files.txt (for example)
<jlambert121> harlowja: writing new ones works great with the yum plugin, but i can't seem to modify existing ones with it
<harlowja> hmmm
<harlowja> ya i guess https://github.com/stackforge/cloud-init/blob/0.7.x/cloudinit/config/cc_yum_add_repo.py#L74 is preventing that
<jlambert121> on centos there are 4 repos defined in a CentOS-Base.repo file which seems to be confusing it
<jlambert121> [base] is one of the repos - if i set up a repo named base with cloud-init it'll create a base.repo file, not modify the existing one (which doesn't seem like bad behavior), but i somehow need to get rid of the old [base] repo then
<jlambert121> i was just going to try adding a 'rm -f /etc/yum.repos.d/*.repo' to the bootcmd and see if i could hack it up that way, but doesn't "feel" quite right
<harlowja> ya, it's probably better to do something else, more native, but i'd just remove the specific repo files u know u want to overwrite for now
<harlowja> the code  @ https://github.com/stackforge/cloud-init/blob/0.7.x/cloudinit/config/cc_yum_add_repo.py#L71 should probably allow overwrite
<harlowja> vs not
<jlambert121> yeah, if repo_id is found, just modify the repo_config for that id
<jlambert121> that was the behavior i expected anyway
<harlowja> ya, when i created that (think it was me) probably was just being conservative
<jlambert121> want me to open a GH issue for it? (it's beyond me to change)
<harlowja> https://bugs.launchpad.net/cloud-init/ instead, GH issues will get automatically closed
<harlowja> GH is just a mirror
<jlambert121> ahh, ok - i'll do that.  thanks for the help
<harlowja> jlambert121 its never beyond u to change it ;)
<harlowja> never accept defeat, ha
<jlambert121> harlowja: very true as i tell others with projects i ask for PRs on.  I should state it as: in the near future i'm not going to have time to learn python and make this change, but some day :)
<harlowja> ;)
<harlowja> so like the day after tommorow then?
<harlowja> ha
<jlambert121> yeah, something like that
<harlowja> :)
<jlambert121> after my 4 "number one priorities" at $dayjob get done and 6 number ones at $home :)
<gamename> hi guys.  How do I check what the default of "package_update" would be?
<harlowja> check /etc/cloud/cloud.cfg
<harlowja> https://github.com/stackforge/cloud-init/blob/0.7.x/cloudinit/config/cc_package_update_upgrade_install.py#L51 is all the keys that module uses
<harlowja> so if there is an entry for those keys in there, thats the default
<harlowja> jlambert121 well u need to sleep less then, more doing #number ones
<harlowja> although don't to many number #2(s); if u do that alot u may want to see a doctor
<gamename> harlowja: entry in where?
<harlowja> the config file in the VM @ /etc/cloud/cloud.cfg
<harlowja> thats typically where that stuff is stored
<gamename> harlowja: So, if there is a mention of a value in /etc/cloud/cloud.cfg, then that is the default?  Wouldn't that mean that /etc/cloud/cloud.cfg is not a config file at all, but a kind of key/value template file?
<gamename> confused.
<harlowja> depends on what u typically call a config file
<harlowja> to me a config file is things with settings that affect how some program runs
<harlowja> if thats key/values, binary, digits, if they affect how a program is ran, its config
<gamename> harlowja: So, what if there is no mention of a key in /etc/cloud/cloud.cfg? What then?  Does it take a default value then?
<harlowja> right, so then it starts merging 'configuration' together
<harlowja> to form a final config that will be used
<gamename> harlowja: Merge the contents of /etc/cloud/cloud.cfg and what else?
<harlowja> soooo first its https://github.com/stackforge/cloud-init/blob/0.7.x/cloudinit/settings.py#L29
<harlowja> then /etc/cloud/cloud.cfg  merges into that
<harlowja> then things in /etc/cloud/cloud.cfg.d i think
<harlowja> then userdata and metadata get merged in
<harlowja> oh https://github.com/stackforge/cloud-init/blob/0.7.x/cloudinit/helpers.py#L258
<harlowja> i think thats the list, from what i remember
<gamename> harlowja: ok.  So, how is the default for a given value, in this case "package_update", determined?  If that key isn't mentioned in /etc/cloud/cloud.cfg where is the default set?
<harlowja> the code that those config then can set a default if it so wants to
<harlowja> https://github.com/stackforge/cloud-init/blob/0.7.x/cloudinit/config/cc_package_update_upgrade_install.py#L51
<harlowja> thats the code, anything touching 'cfg' variable name there is extracting stuff
<harlowja> *extracting stuff from the merged config
<gamename> harlowja: So, you're saying the only time there is a value for a key is when it is specifically set?
<harlowja> or the code that uses that key decided to set some default if it doesn't find a key
<harlowja> ie 'pkglist = util.get_cfg_option_list(cfg, 'packages', [])'
<harlowja> that sets it to a empty list if its not found
<harlowja> now u may say this could be done via another way, but ya, thats the current way
<gamename> harlowja: ok.  How can I tell if "package_update" ever gets a value set for it?
<harlowja> i think u can activate the debug module
<harlowja> https://github.com/stackforge/cloud-init/blob/0.7.x/cloudinit/config/cc_debug.py will dump out the end cfg
<harlowja> if your version of cloud-init has that module
<gamename> harlowja: ok. So I have to turn on debug to tell what a default value is. Got it.
<harlowja> well and u have to look at the code for what it does when values aren't found in that config
<gamename> harlowja: Debug may not supply the answer?
<harlowja> nope
<harlowja> debug will show u the initial config
<harlowja> that is given to each module, then u look at the code
<gamename> harlowja: Doesn't sound like its worth the time.  Nevermind.
<harlowja> ok
<gamename> smoser: Do I really need to run debug and scan the code just to find out the default of a keyword? wow...
<harlowja> there are multiple config sources, so its not just as simple as u would want it
#cloud-init 2015-09-01
<openstackgerrit> Claudiu Popa proposed stackforge/cloud-init: Add a version filtering strategy  https://review.openstack.org/219220
<Odd_Bloke> smoser: https://code.launchpad.net/~daniel-thewatkins/cloud-init/fix_mount_cb_symlink/+merge/269789 is a pretty important fix for a regression I introduced on Azure.
<Odd_Bloke> smoser: If you have time to review, merge and release for wily, I'm going to start backporting it.
<smoser> booo
<smoser> Odd_Bloke, is there a bug number ?
<Odd_Bloke> smoser: https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1490796
<smoser> merged, pushed
<Odd_Bloke> smoser: Thanks!
<harlowja> claudiupopa smoser  Odd_Bloke  thoughts on having the version always be a http://epydoc.sourceforge.net/stdlib/distutils.version.StrictVersion-class.html object, I think thats doable right?
<harlowja> thought of that when looking at https://review.openstack.org/219220
<harlowja> vs just a string
<claudiupopa> Totally doable and probably better.
<harlowja> claudiupopa also, do u know if the other claudiu asked u about https://review.openstack.org/#/c/209193/ (which now might be a new pypi library)? could be used by cloud-init to avoid recreating the same stuff
<harlowja> claudi b. :-P
<harlowja> *claudiub
<claudiupopa> No, never heard of that until now. ;-)
<harlowja> durn
<harlowja> can u poke/ask
<claudiupopa> But seems hyperv related?
<harlowja> not all of it, https://github.com/cloudbase/os-windows seems mixed
<harlowja> 'Library contains Windows / Hyper-V code commonly used in the OpenStack projects: nova, cinder, networking-hyperv. The library can be used in any other OpenStack projects where it is needed.' ...
<harlowja> maybe could be used in cloud-init to
<harlowja> some of the stuff would seem common
<harlowja> *stuff in https://github.com/cloudbase/os-windows/tree/master/os_windows/utils
<claudiupopa> Looking right now.
<harlowja> k
<claudiupopa> Yeah, at a first glance, it doesn't look very useful for us, I mean it seems more like an abstraction layer for HyperV. :-/
<harlowja> kk, buttt maybe it could be something useful, if its meant to be a common windows stuff library?
<harlowja> if claudiu b. will accept code :-P
<claudiupopa> Weeell, if it's not a new Windows API layer that doesn't suck, then it's not useful. :D
<harlowja> lol
<harlowja> u can add more suck
<harlowja> ?
<claudiupopa> As in if you can make it worse?
<harlowja> well that will make it more useful then right, according to your defintion :-P
<harlowja> more suck == more useful, lol
<harlowja> or maybe to many 'not' in the above, ha
#cloud-init 2015-09-02
<holger> hi all
<holger> i have a config drive with a network_info.json
<holger> but does not work
<holger> how do i reference this file ?
<Odd_Bloke> claudiupopa: smoser: smatzek: harlowja: Meeting?
<smoser> claudiupopa, is not available.
<smoser> Odd_Bloke, yeah.
<smatzek> yeah
<Odd_Bloke> Here, I presume?
<smoser> yeah.
<smoser> ok. lets start.
<smoser> http://bit.ly/cloudinit-reviews-public
<smoser> claudiupopa, had the only review open
<smoser> i can respond there on the review
<smoser> i'll try to justify what i was thinking, and see if i can teas a response / thought from odd_bloke
<smoser> so my feeling was that if i'm loading a datasource, i quite likely am passing it some variables . rather than just NewDataSource()
<smoser> ie: NewDataSource(datasource_config=config, os=)
<smoser> and if we ever change that signature, then i'd like to have given the thing returning classes the ability to say "well i can only do version 1 signature"
<smoser> we could definitely just change that from arguments to the class's __init__ to a 'set_config' or something
<smoser> but it seems that they are more properly in the __init__
<smoser> s/are more properly/fit more properly/
<smoser> where as claudiupopa's solution woudl then have all the classes instantiated (for all possible versions) and then have to deal some other way with providing each class the datasource_config value
<smoser> or the instance get that data somehow
<smoser> thoughts ?
<Odd_Bloke> I'm just reminding myself how the loading works. :)
<Odd_Bloke> smoser: So it depends a little what we mean by "version", I think.
<Odd_Bloke> If we're talking about different internal-to-cloud-init versions of the DataSource implementation, then I think we can do either claudiupopa's way or your way.
<smoser> right.
<smoser> the point of the 'version' flag was to allow out-of-tree things
<smoser> (which is also the point of the dyanmic loading :)
<Odd_Bloke> Version will have to be an attribute on the class of DataSource.
<Odd_Bloke> And then DataSourceLoader could just do 'for data_source in data_sources: if data_source.version == 1: <instantiate one way> elif data_source.version == 2: <instantiate another> else: <throw hands in air>'
<Odd_Bloke> (Where on line 97, at the moment, it just does 'data_sources = (data_source() for data_source in data_sources)')
<smoser> Odd_Bloke, yeah, i hadnt thought of that.
<smoser> any other thoughts? because other wise, i think either way is fine
<Odd_Bloke> And we'd still have to do something like this, because the contract of module_providing_a_source.data_sources won't necessarily be static.
<smoser> you think ?
<Odd_Bloke> Well, if we're talking about instantiating data sources differently, then the thing which instantiates them might need different information with which to instantiate them.
<smatzek> I like Odd_Bloke's idea.  I think it handles smoser's concern and allows claudiupopa's code to be unchanged, right?
<Odd_Bloke> For now it wouldn't need to be changed, yeah.
<smoser> i suppose..
<smoser> then is ther ea sane way that we an do something reasonably smart now
<smoser> so that we can avoid
<smoser> if hasattr(class, 'data_sources_v1'):
<smoser>   data_sources_v1()
<smoser> elif hasattr(class, 'data_sources_v2'):
<smoser>   data_sources_v2(name1=value)
<smoser> or just live with that.
<Odd_Bloke> Well, we'd do:
<Odd_Bloke> if cls.version == '1':
<Odd_Bloke>   cls()
<Odd_Bloke> elif cls.version == '2':
<Odd_Bloke>   cls(name1=value)
<smoser> right.
<smoser> but then you said that 'data_sources' might be versioned
<smoser> need to be versioned
<Odd_Bloke> I don't think it will need to be if it's just returning classes.
<Odd_Bloke> It was when it was potentially going to be instantiating them that it would need more info.
<Odd_Bloke> If all else fails, we can do:
<Odd_Bloke> module_version = getattr(mod, 'version', 1)
<Odd_Bloke> if module_version == 1:
<Odd_Bloke>   datasources()
<Odd_Bloke> elif module_version == 2:
<Odd_Bloke>   datasources(name1=value)
<Odd_Bloke> We can expect DataSources to have attributes, because they should inherit from an abstract class.
<Odd_Bloke> But the beauty of a dynamic language is that we can defer that until later.
<smoser> oh. i read code wrong.
<smoser> yeah.
<smoser> ol.
<smoser> so i'm ok wi think with what is there.
<smoser> Odd_Bloke, you ahve anything else ?
<Odd_Bloke> I do not.
<smoser> i still have some reporter/webhook changes to get back into 2
<smoser> smatzek, ?
<smoser> anyting from you?
<smatzek> I don't have anything else.
<Odd_Bloke> Meeting ends?
<smoser> meeting ends.
<Odd_Bloke> Thanks everyone. :)
<Odd_Bloke> smoser: If you have time to cut a new wily release, that's be much appreciated; we're just about ready to push up the SRUs for that fix.
<smoser> k
<Odd_Bloke> And the SRU team get fussy if they aren't actual backports. ;)
<openstackgerrit> Merged stackforge/cloud-init: Add a version filtering strategy  https://review.openstack.org/219220
<natorious> weekly meeting anyone?
<smoser> zz_natorious, Wed, 14:00:00 +0000
<smoser> UTC 14:00
<natorious> smoser: yep, missed the UTC part for some reason.  There is another dev from Rackspace, Ben Roble, who's been approved to work on the project as well.
<smoser> what timezone are you?
<natorious> I'm CST and he's EST
<smoser> the zzz confused me
<smoser> er.. zz
<natorious> yeah, thats znc doing its thing.  /me looks into how disable
<smoser> ah
<natorious> I'm gonna go thru the review backlog just to familiar myself w/ master a bit.  We have some req's from different product segments which I'll hold of on adding blueprints on till then.
<natorious> with this being dual license, would Ben need to sign the Canonical license agreement?
<natorious> or just the Openstack dev agreement?
<smoser> natorious, canonical license agreement.
<smoser> openstack dev agreement has nothing to do with it
<smoser> (which is admittedly confusing due to using stackforge)
#cloud-init 2015-09-03
<Seth_Karlo> Hey all, I'm having an odd issue. Does Cloud-Init usually run as the root user or a sub-user?
<Seth_Karlo> I'm strace-ing a run and I see it downloading the chef omnibus installer into /tmp/ with permissions 0700, but then getting a permission denied on the script a second later and failing
<Odd_Bloke> Seth_Karlo: Hmm, that is strange; does the file end up with the expected permissions?
<Seth_Karlo> File is deleted before I can take a look at it
<Seth_Karlo> This is what I see: [pid 11304] execve("/tmp/tmpfpIQua/chef-omnibus-install", ["/tmp/tmpfpIQua/chef-omnibus-install"], [/* 21 vars */]) = -1 EACCES (Permission denied)
<Odd_Bloke> Seth_Karlo: What version of cloud-init are you using (and on what distro)?
<Seth_Karlo> cloud-init 0.7.5 on CentOS 7.103
<Odd_Bloke> Seth_Karlo: So the code that is running is in cloudinit/config/cc_chef.py; if you add a sleep at around line 114 wherever that file is installed, then you'll have some time to check the file looks sensible.
<Seth_Karlo> Odd_Bloke: Understood, testing now
<Odd_Bloke> Seth_Karlo: "import time; time.sleep(N)", if you aren't a Python person. :)
<Seth_Karlo> Odd_Bloke: Perfect, thanks!
<Seth_Karlo> Odd_Bloke: Is N in seconds or ms?
<Odd_Bloke> Seth_Karlo: Seconds.
<Seth_Karlo> Odd_Bloke: Seemed to completely ignore it at line 114 in /usr/lib/python2.7/site-packages/cloudinit/config/cc_chef.py
<Odd_Bloke> Seth_Karlo: Can you pastebin your modified bit of the file?
<Seth_Karlo> Odd_Bloke: https://gist.github.com/Seth-Karlo/96e129c004e63d5cc331
<Odd_Bloke> Seth_Karlo: Ah, put it a line up.
<Odd_Bloke> Seth_Karlo: util.subp is what's running the file.
<Seth_Karlo> Odd_Bloke: In between the util. ones?
<Odd_Bloke> Seth_Karlo: Yep.
<Seth_Karlo> Done, testing now :)
<Seth_Karlo> Odd_Bloke: Aaaaaah, I see the issue!
<Seth_Karlo> Odd_Bloke: My /tmp is mounted noexec!
<Seth_Karlo> Odd_Bloke: Now working, thank you very very much for your help. Kudos and my gratitude
<Odd_Bloke> Seth_Karlo: I'm always happy to help when it turns out there isn't a bug for me to fix. ;)
<Seth_Karlo> Odd_Bloke: Haha, I'll let you know if I find more! :P
<Odd_Bloke> :D
<openstackgerrit> Claudiu Popa proposed stackforge/cloud-init: Add a draft spec for the parallel discovery of data sources  https://review.openstack.org/220095
<openstackgerrit> Claudiu Popa proposed stackforge/cloud-init: Add a draft spec for the parallel discovery of data sources  https://review.openstack.org/220095
<Odd_Bloke> claudiupopa: I think you might have done an incomplete naming change in the "FacadaParallelSearch" example in that spec.
<Odd_Bloke> claudiupopa: (Also Facada is a typo :p)
<claudiupopa> Oh, yep. :p
<smoser> claudiupopa, are you going to tokyo ?
<smoser> for openstack su mmit ?
<claudiupopa> Nope.
<smoser> Odd_Bloke, didnt you do something wrt testing bin/cloud-init in 0.7 ?
<Odd_Bloke> smoser: I did, yeah. Why do you ask?
<smoser> where is it ?
<Odd_Bloke> smoser: http://bazaar.launchpad.net/~cloud-init-dev/cloud-init/trunk/view/head:/tests/unittests/test_cli.py
<smoser> thanks
<Odd_Bloke> :)
<smoser> Odd_Bloke, do you happen to know...
<smoser> http://paste.ubuntu.com/12263593/
<smoser> probably easier to read
<smoser>  http://paste.ubuntu.com/12263608/
<Odd_Bloke> smoser: In a meeting right now, will look in a bit. :)
<j^2> hey smoser i sent you a response :D
<smoser> j^2, thnks
<j^2> we can sync later today?
<smoser> sure. ping me here is fine
<j^2> perfect
<smoser> where'd you send rsponse ?
<Odd_Bloke> smoser: Given that those are all in the HTTP request, I would assume that they can all be logged.
<Odd_Bloke> Because the NSA has them anyway. :p
<Odd_Bloke> But I don't know that for sure.
<smoser> thats what i thought too, Odd_Bloke
<smoser> they're its supposed to work over http/ untrusted.
<smoser> so you'd think it'd bad if there was secrets there
<Odd_Bloke> Yeah.
<smoser> j^2, stuff for cloud-init 0.7.X is still on launchpad
<smoser> so your review was at the correct place
<j^2> ah, which is the one that shipped âin generalâ now-a-days?
<Odd_Bloke> j^2: 0.7.x is still shipped in general, 2.0 is still in early development.
<j^2> Odd_Bloke: ah cool, then iâll keep with 0.7.0 then
<j^2> thanks
<harlowja> smoser whatever happened to enabling the launchpad + git stuff
<harlowja> is that possible still?
<smoser> harlowja, yes. still possible.
<harlowja> +2 :)
<harlowja> can u press a button somewhere to make that happen ;)
<harlowja> ye-olde button
<smoser> the button i'd rather push is 'make harlowja work enough on cloud-init 2.0 that he stops caring about 0.7'
<smoser> do you have one of those buttons?
<harlowja> smoser ya, mainly this is for the y! CI system, that still pulls from 0.7, but really only knows how to interface with git :-P
<harlowja> it doesn't quite know bzr, and nobody seems willing to add bzr support :-P
<harlowja> claudiupopa in regard to https://review.openstack.org/#/c/220095/ let me know if u have any questions on how this got pulled off in taskflow (the parallel running based on dependencies ...)
<harlowja> because its awfully similar i think, ha
<claudiupopa> So they're similar?
 * harlowja makes an example, but yes
<claudiupopa> Looking right now in the link.
<harlowja> k
<harlowja> claudiupopa http://paste.openstack.org/show/444643/
<harlowja> output from running that
<harlowja> http://paste.openstack.org/show/444646/
<harlowja> soooo it does something like u want i think, ha
<harlowja> and it can run in parallel as well :-P
<harlowja> u can run that by just cloning https://github.com/openstack/taskflow and making a venv and installing its requirements, then running it locally...
<claudiupopa> Nicee, why don't we use it for cloud-init v2 then?
<harlowja> could be done :-P
<harlowja> i am top maintainer/creator of that lib, so maybe we could, ha
<harlowja> but depends on others thoughts, ha
<harlowja> bb
<claudiupopa> The capabilities are represented by default_provides?
<harlowja> claudiupopa correct, or they could be
<harlowja> just something to think about, taskflow might be to big of a dependency, idk
<Odd_Bloke> smoser: So my HTTP friend tells me that in theory we should be able to store all the OAuth info in the log, but that assumes a good OAuth server implementation.
<Odd_Bloke> smoser: So we're probably better off not logging it.
#cloud-init 2015-09-04
<Odd_Bloke> claudiupopa: harlowja: I like the look of taskflow, but there are a couple of problems: (a) it isn't packaged for Python 3 in Debian/Ubuntu, and (b) it pulls in a lot of dependencies that I don't think we'll use (e.g. MySQL/PostgreSQL drivers, Zookeeper library).
<Odd_Bloke> claudiupopa: harlowja: smoser: So it looks like there are a few hurdles to getting a python3-taskflow building, but they probably aren't insurmountable for 16.04.
<Odd_Bloke> But I don't really want to try and get it sorted unless we are actually going to use taskflow. :p
<Odd_Bloke> I expect that we could also convert quite a few of those dependencies to Recommends/Suggests.
<smoser> Odd_Bloke, one thing to do is just file a bug
<smoser> and tell openstack team.
<smoser> they have to solve it at some point.
<Odd_Bloke> smoser: Ah, true.
<Odd_Bloke> smoser: Will they have to solve it for/by 16.04, do you know?
<smoser> not really, but i filed a ton of "no python3" and they did get fixed.
<Odd_Bloke> (It turns out there's also some pain with building both python-taskflow and python3-taskflow at the same time, python{,3}-networkx conflict with one another)
<smoser> https://bugs.launchpad.net/ubuntu/+source/python-novaclient/+bug/1319145
<smoser> Odd_Bloke,  you can even just file in debian :)
<Odd_Bloke> smoser: I've filed https://bugs.launchpad.net/ubuntu/+source/python-taskflow/+bug/1492267
<Odd_Bloke> Can I file a Debian bug and link them somehow?
<smoser> you can, yeah.
<smoser> use 'reportbug' to file debian bug
<smoser> and then you can link it in launchpad
<Odd_Bloke> Done.
<smoser> Odd_Bloke, question..
<smoser> do you knwo if i can specify a bzr repository to tox
<smoser> i want to use simplestreams in a tox, but dont want to push to pypi
<Odd_Bloke> smoser: You mean as a requirement to install?
<smoser> as a 'deps', yeah
<Odd_Bloke> You can do it with pip via https://pip.pypa.io/en/latest/reference/pip_install.html#bazaar
<Odd_Bloke> So you should be able to get tox to do it.
<openstackgerrit> Daniel Watkins proposed stackforge/cloud-init: Configure basic logging, and make it possible to log to console.  https://review.openstack.org/220536
<openstackgerrit> Daniel Watkins proposed stackforge/cloud-init: Use a single source for version information.  https://review.openstack.org/220543
<smoser> Odd_Bloke, you can. i did, its nice.
<smoser> http://paste.ubuntu.com/12273678/
<Odd_Bloke> :)
<Odd_Bloke> harlowja: I'm playing around with TaskFlow; I was wondering if you have any recommendations for handing objects around as results/arguments.
<Odd_Bloke> harlowja: I've just switched to the dir/files storage implementation, and it can't serialise a DataSource to disk (unsurprisingly).
<Odd_Bloke> harlowja: OK, maybe a more general question: I want to be able to do things in discrete runs of cloud-init (e.g. run it once to configure networking, once to find a data source, and once to do configuration).
<Odd_Bloke> harlowja: So I figured that I could do this by re-using a logbook (and maybe a flow, but I haven't managed to get that far yet).
<Odd_Bloke> harlowja: But DirBackend.get_connection().get_logbooks() consistently returns no items.
<Odd_Bloke> harlowja: There are loads of logbooks stored on disk, but it only looks for them if they are links.
<Odd_Bloke> harlowja: Am I hitting a bug in my understanding, or a bug in taskflow? :p
<harlowja> Odd_Bloke yo yo
<Odd_Bloke> harlowja: o/
<harlowja> \o
<harlowja> ha
<harlowja> so did u get the handing objects around working?
<Odd_Bloke> harlowja: Nah, I moved on to trying to get all the different bits working together.
<Odd_Bloke> Because if I can't get the different runs to see the same data, then it doesn't matter what I can store. :p
<harlowja> so let's see here
<harlowja> dr.josh on the case
<harlowja> ha
<Odd_Bloke> harlowja: I think this might be a legit bug; books are always written as directories, but _get_children will only ever return links.
<harlowja> ya, it might be
<harlowja> legit bug ftw
<harlowja> ha
<harlowja> i don't think many people have been using the dir backend, most afaik have use the sql one
<harlowja> or the zookeeper one
<harlowja> btw, as for dependencies, most are actually optional, depending on what u use
<harlowja> i should probably reorganize them now that better optional dependency support exists in pip
<Odd_Bloke> harlowja: Yeah, I figured they would be.
<Odd_Bloke> So hopefully it's mostly just shifting them from Depends to Suggests.
<harlowja> ya
<harlowja> i think pbr only recently got support for this, so thats part of it
<harlowja> * support for https://www.python.org/dev/peps/pep-0426/#extras-optional-dependencies
<harlowja> *thats part of why
<Odd_Bloke> Well, let me switch to using sqlite for now.
<harlowja> k
<harlowja> but now u guys know my other project :-P
<harlowja> ha
<harlowja> ok, https://bugs.launchpad.net/taskflow/+bug/1492392 opened for optional deps
<harlowja> http://paste.openstack.org/show/445602/ another example Odd_Bloke
<harlowja> that one dumps out the in-memory backend
<Odd_Bloke> harlowja: So I'm trying to work out how I should do this resuming stuff.
<Odd_Bloke> harlowja: Should I be building the entire cloud-init flow up front, and then different commands can do different parts of it?
<Odd_Bloke> Or can the commands just build their own, smaller flows which can be extended/resumed by later commands.
<harlowja> i've seen people do both
<harlowja> building up-front allows for more parallelsim
<harlowja> building smaller ones and executing them allows for less
<harlowja> building up front gets complicated if u need to do conditionals, this kind of programming model (the one taskflow has, typically called dataflow-like) does require some brain twisting, since its basically ahead-of-time defintion of all the things :-P
<harlowja> so i'd start out simple (which seems to be what most people do)
<harlowja> Odd_Bloke here is an example that uses a prior runs data
<harlowja> http://paste.openstack.org/show/445605/
<harlowja> output @ http://paste.openstack.org/show/445608/
<harlowja> ^ will avoid recomputation
<Odd_Bloke> Aha, I think I'm missing the models.FlowDetail part.
<Odd_Bloke> I was trying to do something messy with logbooks.
<harlowja> ya, that might be part of it, the bug probably is still legit though
<Odd_Bloke> harlowja: taskflow.exceptions.NotFound: No flow details found with uuid '6c1a3f09-8a58-426f-bffb-8262680fcb67'
<Odd_Bloke> harlowja: Using sqlite on the first run with it added in.
<harlowja> ya, k, the memory backend is sorta different in that case, so u have to do a little more for other backends
<harlowja> basically https://github.com/openstack/taskflow/blob/master/taskflow/examples/resume_from_backend.py#L106 (those 5 lines)
<harlowja> the in-memory stuff sorta automatically saves the provided flow detail when a backend is not provided (because its an in-memory one, and the default)
<Odd_Bloke> harlowja: OK, so I'm persisting and fetching the same flow_detail now.
<harlowja> k
<Odd_Bloke> harlowja: What I have ATM is two Flows A and B.  A produces 'data_source' and B requires 'data_source'.  I'm running A on one invocation of cloud-init (i.e. e = engines.load(A, ...); ...; e.run()) and B on the second.
<harlowja> k
<Odd_Bloke> harlowja: But B always fails because 'no other entity produces said requirements'.
<roychri> Im trying to find how to access my ec2 metadata (specifically the private_ipv4) so I can use it in bootcmd, runcmd or write_files. Any pointers?
<harlowja> Odd_Bloke can u pastebin the code u have?
<harlowja> Odd_Bloke https://bugs.launchpad.net/taskflow/+bug/1492403 also (for the dir stuff); fixing that right now
<openstackgerrit> Daniel Watkins proposed stackforge/cloud-init: [WIP] TaskFlow for running shell commands  https://review.openstack.org/220593
<harlowja> is that the pastebin ;)
<Odd_Bloke> Yep. :p
<harlowja> :)
<harlowja> Odd_Bloke can u also try turning log level 5 on, that will show the symbol lookup resolution
 * harlowja aka the 'trace' log level
<harlowja> the lookup loggin should show u why / what is being searched for and found
<Odd_Bloke> "2015-09-04 18:26:14,869 [Level 5] taskflow.storage: Looking for 'data_source' <= 'data_source' for atom named: cloudinit.flows.get_config_flow.<locals>.PlaceHolderTask"
<harlowja> (yes i know thats a non-standard log level, but the some openstack people complained about it being to noisy, ha)
<Odd_Bloke> harlowja: So if you look at flows.py, all works fine but doing the two separately doesn't.
<Odd_Bloke> Which makes sense.
<Odd_Bloke> But I don't know how I should go about doing those two separately.
<harlowja> can u insert the search flow (Even if it already finished) into the config_flow
<harlowja> i'm pretty sure that it needs to know the names of providers, so if u don't insert it, it doesn't know about the other prior tasks that already saved stuff
<harlowja> so u could either add dummy tasks, or just insert the search flow
<Odd_Bloke> OK, that did work.
<Odd_Bloke> But that makes inserting earlier steps tricky.
<Odd_Bloke> So I'm wondering if I should actually just be building the whole flow up-front, and using a targeted graph thingie just to execute up to where I want?
<harlowja> that could work to
<harlowja> most of the advanced users use the graph stuff, its more powerful imho
<Odd_Bloke> Or maybe it's just the way I'm defining things that makes it seem messy doing it this way..
<harlowja> i think the graph stuff would make it better, then running up to a point
<Odd_Bloke> Cool, I'll try that.
<openstackgerrit> Daniel Watkins proposed stackforge/cloud-init: [WIP] TaskFlow for running shell commands  https://review.openstack.org/220593
<Odd_Bloke> That's the fixed version of what I have now.
<harlowja> basically the argument providers aren't persisted, aka, what each task provides, so without those being inserted, the lookup mechanism goes 'idk where that is' for later tasks that want to use it
<Odd_Bloke> Right, that makes sense.
<harlowja> now maybe those should be saved
<harlowja> not especially hard, just isn't right now
<Odd_Bloke> I'd assumed that they were shoved in to the same global dict as the stuff you give as store={...}.
<Odd_Bloke> But I think we'll want to transition to the graph stuff anyway.
<Odd_Bloke> So I'll try that.
<Odd_Bloke> And if it's too hard then you can fix the library to do whatever I want it to do. ;)
<harlowja> nah, during the compile() step the whole tasks are validated against who provides what (by name) so its a little more complicated :-P
<harlowja> :(
<harlowja> haha
<harlowja> http://docs.openstack.org/developer/taskflow/engines.html#scoping is basically the 'lookup algo'
<harlowja> http://docs.openstack.org/developer/taskflow/engines.html#taskflow.engines.action_engine.scopes.ScopeWalker.__iter__ (the meat of it)
<harlowja> Odd_Bloke as long as other openstack projects aren't affected by those changes then i guess i can change it for u :-P
<harlowja> ha
<Odd_Bloke> Nah, they can work around us.
<harlowja> openstack/other projects (rackspace uses this for http://www.rackspace.com/cloud/big-data afaik)
<harlowja> lol
<Odd_Bloke> See if their instances will boot if cloud-init breaks. ;)
<harlowja> :-P
<harlowja> have u figured out the parallel stuff yet btw?
<Odd_Bloke> "the parallel stuff"?
<harlowja> https://github.com/openstack/taskflow/blob/master/taskflow/examples/hello_world.py#L82
<harlowja> executing non-dependent tasks at the same time
<Odd_Bloke> Oh, not yet.
<harlowja> k
<harlowja> np
<harlowja> thats step 1.5 of the 4 step taskflow program
<Odd_Bloke> Everything's been one big linear flow up until now, so it wouldn't have made a difference anyway, right?
<harlowja> lol
<harlowja> right, it wouldn't have
<Odd_Bloke> Phew.
<Odd_Bloke> I understood something. :p
<harlowja> ya, linear stuff not so paralleizable
<harlowja> *where not so == not at all, lol
<Odd_Bloke> harlowja: So how should I target this execution?
<Odd_Bloke> I can't just say "until data_source is set", right?
<harlowja> nah, u have to set the node to run 'up to'
<harlowja> https://github.com/openstack/taskflow/blob/master/taskflow/patterns/graph_flow.py#L314
<harlowja> so set_target(config_task_obj)
<harlowja> or whatever
<Odd_Bloke> harlowja: It works. \o/
<harlowja> woot
<harlowja> damn, amazing shit
<harlowja> ha
<Odd_Bloke> Who wrote this?
<Odd_Bloke> They must be amazing!
<harlowja> mostly me :-P
<harlowja> ha
<Odd_Bloke> Oh...
<Odd_Bloke> Never mind.
<Odd_Bloke> ;)
<harlowja> :-P
<harlowja> and thats just part 1 of its awesomeness
<harlowja> lol
<openstackgerrit> Daniel Watkins proposed stackforge/cloud-init: [WIP] TaskFlow for running shell commands  https://review.openstack.org/220593
<harlowja> stuff that won't be likely used by cloud-init, but is used by others http://docs.openstack.org/developer/taskflow/jobs.html
<harlowja> once u have resumption, now imagine tying a job to a set of tasks, and having that job be placed somewhere for others to work on
<harlowja> and if those job 'workers' crash the job gets resumed by others that then try to finish it...
<harlowja> annnnd magic
<harlowja> ha
<harlowja> Odd_Bloke https://docs.google.com/presentation/d/1EZoY4FE2SDjfCqMCgBRrwo7ovHF4vYZFGKjjvFvWHIE/
<harlowja> that might be useful now that u have seen some of it, ha
<harlowja> (a talk i did with the hp folks)
<Odd_Bloke> harlowja: That demo sucked.
<Odd_Bloke> But the rest of the slideshow was helpful.
<harlowja> lol
<harlowja> https://github.com/openstack/taskflow/blob/master/taskflow/examples/99_bottles.py#L39 :-P
<harlowja> ^ the demo, ha
<harlowja> DIY
<harlowja> lol
<harlowja> DIY demo
<roychri> Im trying to find how to access my ec2 metadata (specifically the private_ipv4) so I can use it in bootcmd, runcmd or write_files. Any pointers?
<Odd_Bloke> roychri: You could hit the EC2 metadata server yourself.
<roychri> using curl?
<roychri> that will work in runcmd, but write_files ?
<Odd_Bloke> roychri: I don't know that you can do it in write_files.
<Odd_Bloke> roychri: Though you can, of course, write out files with your runcmd.
<roychri> ok, I thought the metadata could be available thru some variables of some kind...
<Odd_Bloke> roychri: You're right, let me dig up the docs on what's available.
<roychri> I skimmed thru the datasources docs, I couldn't find anything there...
<Odd_Bloke> roychri: Actually, looking at it, you can't do substitution with write_files.
<Odd_Bloke> cc_final_message lets you do some substitution.
<roychri> Maybe I should just use #!/bin/bash instead of #cloud-config
<Odd_Bloke> roychri: You can send multi-part cloud-config over.
<Odd_Bloke> roychri: Which would let you have the best of both worlds.
<roychri> Im not there yet :)
<roychri> I'll get my first instance to work, then I'll look at multipart.
<openstackgerrit> Daniel Watkins proposed stackforge/cloud-init: [WIP] TaskFlow for running shell commands  https://review.openstack.org/220593
<Odd_Bloke> harlowja: Could you do a sanity check of ^ before I spend any time firming it up with tests/logging/etc.?
<harlowja> odd is 'PlaceHolderTask' going to stay?
<harlowja> Odd_Bloke ^
<harlowja> otherwise seems like a good start to me
<Odd_Bloke> harlowja: That represents "all the configuration", so I'll probably move that out to a separate module to be a start for that.
<harlowja> k
<Odd_Bloke> harlowja: How do you feel about the 'select an arbitrary UUID' approach to identifying flows?
<harlowja> unsure, mixed feelings :-P
<harlowja> i prefer useful names :-/
<Odd_Bloke> harlowja: They require a UUID, though.
<harlowja> for the flow detail storage part, ya
<Odd_Bloke> Yeah, that's the bit I meant.
<harlowja> so i guess arbitrary UUID is fine then, its really used to reconnect with later runs (if the same names are used)
<Odd_Bloke> harlowja: Actually, UUIDs aren't just random, I might be able to do something more sensible.
<Odd_Bloke> s/aren't just/don't have to be/
<Odd_Bloke> Blargh, they always have a part which is a UUID.
<Odd_Bloke> In [37]: uuid.UUID(bytes=b'cloudinitiscool!')
<Odd_Bloke> Out[37]: UUID('636c6f75-6469-6e69-7469-73636f6f6c21')
<harlowja> lol
<harlowja> so there is really no check that u are providing a uuid, btw, u can probably  just provide 'cloudinitiscool!' as flow detail uuid arg
<Odd_Bloke> Oh, cool.
<harlowja> not saying thats the best, but perhaps this could be tweaked in taskflow, lol
<harlowja> to be named 'ident' or something instead
<harlowja> vs uuid, lol
<harlowja> but bygones be bygones, ha
<Odd_Bloke> Until that happens, I'll probably keep it as a UUID.
<Odd_Bloke> Because who knows if you'll end up going in the other direction and enforcing UUIDs? :p
<harlowja> :-/
<harlowja> ha
<harlowja> ok, https://review.openstack.org/#/c/220607/ fixes the get_logbooks for dir(s)
<harlowja> thx for finding that Odd_Bloke
<Odd_Bloke> harlowja: No worries, thanks for fixing it. :)
<harlowja> sureee
<harlowja> btw
<harlowja> uuid.uuid5(uuid.NAMESPACE_URL, "https://launchpad.net/cloud-init")
<harlowja> that seems to always create
<harlowja> UUID('bbd9656b-aed9-5912-9702-7ddde940f8f6')
<harlowja> so that could be your uuid :-P
<Odd_Bloke> Oh, nice.
<harlowja> (pick other url as u want, ha)
<Odd_Bloke> I hadn't seen that there were hardcoded namespaces you could use.
<roychri> Why does runcmd have two formats (string and array)? In what use case I should use one over the other?
<harlowja> Odd_Bloke and someone from yahoo is taking over https://bugs.launchpad.net/taskflow/+bug/1492392 so that hopefully will get done soon to
<harlowja> (the splitting the optional/non-optional taskflow deps up)
<Odd_Bloke> Ah, yeah, that would make sorting it out in packaging downstream a lot easier.
<Odd_Bloke> harlowja: Thanks!
<harlowja> ya
<harlowja> np
<harlowja> smoser u been keeping track of all of this?? ;)
<harlowja> shit about to get cray cray
<harlowja> lol
<harlowja> ha
<smoser> been keeping track of nothing
<harlowja> lol
<harlowja> woot
<harlowja> Odd_Bloke also #openstack-state-management channel if u ever don't find me for questions :-P
<harlowja> someone else in there might know to, ha
#cloud-init 2016-09-06
<x58> Morning all... trying to get the latest cloud-init (0.7.7) on CentOS 7 to write out ifcfg-eth0/eth1 based upon ConfigDrive, however it seems to be using the fallback source.
<x58> Is this not currently implemented?
<x58> Nevermind, it is implemented. Just need a release that fixes https://bugs.launchpad.net/cloud-init/+bug/1610784
#cloud-init 2016-09-07
<smoser> harlowja, around ?
<smoser> looking at cloudinit/distros/rhel.py i realize i think we have multiple paths doing the same thing now.
<smoser> actually, i think _write_network is probably never called now.
<smoser> except for very explicit dsmode=pass on openstack config drive.
<smoser> larsks, ping
<smoser> https://code.launchpad.net/~bregeer-ctl/cloud-init/+git/cloud-init/+merge/305058
<smoser> i'd appreciate your eyes on that.
<smoser> and rangerpb also
<larsks> smoser: taking a look...
<x58> smoser: This better? :P
<smoser> x58, sure. and x58 i just asked larsks to review your mp also
<x58> Cheers :-)
<harlowja> smoser  what up
<harlowja> yes, we have multiple paths for networking :-/
<smoser> i think the one there is dead now.
<harlowja> sweet
<harlowja> dead code removal ftw
<smoser> as in never used.
<harlowja> as in deaded?
<harlowja> not alive?
<harlowja> dead as a doorknob
<smoser> except for oepnstack case where user feeds 'dsmode=pass'
<smoser> which actually doesnt work that well anyway
<harlowja> ya, i bet, never tried that way
<x58> Sorry gents, thanks for the review, but I can't in good conscience allow Canonical to take my code and potentially relicense it under a different license.
<smoser> rharper, https://code.launchpad.net/~smoser/cloud-init/+git/cloud-init/+merge/305137
<smoser> if you want to read that quick... seems simple. probably necessary for curtin too
<smoser> actually not necessary for curtin
 * smoser updates bug
#cloud-init 2016-09-08
<smoser> rharper, cpaelzer you convinced me that the copy was odd
<smoser> https://code.launchpad.net/~smoser/cloud-init/+git/cloud-init/+merge/305137
<smoser> i had originally added it to avoid updating the original if there were no "old" keys ... so i wouldnt delete things in 'needtoconvert' loop
<smoser> but since we modify the input in other places, the right thing would be to either change it wholesale (including in convert_to_v3_apt_format).
<smoser> so, just going to drop the copy
<cpaelzer> ok
<cpaelzer> that is what discussions are for
<cpaelzer> are your tests still good with that?
<cpaelzer> smoser: ^^
<cpaelzer> or did you have to modify them
<smoser> cpaelzer, tests dont care.
<smoser> and wrt your comment about my copy in the test... i had done that to avoid typing the same thing twice.
<smoser> to be safe from the function i called changing the data that i passed in.
<smoser> ie, avoiding this bad test:
<smoser> def foo(mydict):
<smoser>    mydict['a'] = '1'
<smoser>   return mydict
<cpaelzer> got it
<cpaelzer> copy and make sure it (still) is the same
<smoser> m = {'1': 2}
<smoser> foo(m)
<smoser> self.assertEqual(m, foo(m))
<smoser> or whatever.
<smoser> right.
<smoser> the behavior of calling a function and it modifying a dictionary and returning that dictionary is odd.
<smoser> but for now, oh well.
<cpaelzer> I still lack some python style badges - this is one that I have to still internalize
<rharper> smoser: heh
#cloud-init 2016-09-09
<prometheanfire>  In fact, if you really want no tests packages at all, youâll need something like this:
<prometheanfire> find_packages(exclude=["*.tests", "*.tests.*", "tests.*", "tests"])
<prometheanfire> smoser: ^
<prometheanfire> smoser: found out why we have that
<prometheanfire> though we already have     packages=setuptools.find_packages(exclude=['tests.*', 'tests']),
<prometheanfire> so.. meh
#cloud-init 2017-09-04
<kraig> Hello, I'm not sure if this is the right place to ask but I'll go ahead anyways. I'm having a bit of trouble with cloud-init on Debian 9.1 (DigitalOcean is my VPS provider). As part of my configuration file, I wish to install multiple packages. One of them requires that I add a new source and import a key from a keyserver. Naturally, cloud-init will create the list and attempt to import the key before attempting to install the pac
<kraig> The problem is that Debian 9.1 doesn't have dirmngr installed, which is required to import a key from a keyserver. The import will fail and all packages installation will fail.
<kraig> Is there a way to make it install dirmngr before attempting to import a key?
<thnee> I added ssh_keys: with a rsa_private: and rsa_public:, yet there are no SSH keys in sight on the machine. Whats up with that?
<thnee> ssh_authorized_keys on the other hand works well
<thnee> oh wait, the keys end up in /etc/ssh/
<thnee> so these are host keys, not user keys?
<thnee> should have been a lot clearer in documentation
#cloud-init 2017-09-05
<smoser> thnee, thats a fair point.  for your info, though, you should be hesitant of anything that asks you for a private key.
<larsks> back from a week of vacation...does https://code.launchpad.net/~larsks/cloud-init/+git/cloud-init/+merge/329661 need anything more, or is it good to go?
<smoser> hey all, just a reminder, we have a status/discussion meeting in ~ 2 hours (Tue, 05 Sep 2017 16:30:00 +0000).
<smoser> we will discuss
<smoser> some of the things listed at https://lists.launchpad.net/cloud-init/msg00094.html
<smoser> blackboxsw, cloudinit/net/dhcp.py
<smoser> i think dhcp_discovery should take the interface back down if it brought it up
<smoser> shouldnt it ?
<smoser> ie, it has a side affect of leaving the 'ip link set dev <interface> up'
<smoser> and EphemeralIPv4Network may have that too ?
<blackboxsw> larsks: hi there welcome back, I had forgotten about the vacation, I'll back my branch donw
<blackboxsw> larsks: hi there welcome back, I had forgotten about the vacation, I'll back my branch down
<smoser> hey.
<smoser> this is time for meeting now.
<powersj> \o/
<smoser> anyone else here for this ?
<smoser> larsks,  no ajorgens, robjo ?
<robjo> sorry chasing an urgent issue, not really here
<smoser> no worries.
<smoser> for this meeting, i'll just run through
<smoser>  https://public.etherpad-mozilla.org/p/cloud-init-meeting
<smoser> # Recent Changes / Highlights
<smoser>  *     integration of robjo's opensuse items
<smoser>  *     summit results posted to mailing list https://lists.launchpad.net/cloud-init/msg00094.html
<smoser> #     In Progress Development / Highlights
<smoser>     Trello Board: [https://trello.com/b/hFtWKUn3/daily-cloud-init-curtin]
<smoser>     Bugs: https://bugs.launchpad.net/cloud-init
<smoser>     Opensuse builds: https://build.opensuse.org/package/show/Cloud:Tools:Next/cloud-init
<smoser> that pasted poorly
<blackboxsw> #startmeeting cloud-init status update
<blackboxsw> :)
<smoser> we also have a SRU in progress. information at https://people.canonical.com/~ubuntu-archive/pending-sru.html
<smoser> ... blackboxsw  do we have the both ere now ?
<smoser> sorry.
<blackboxsw> yeah meetingology is here now :)
<larsks> smoser: sorry, lunch, here now :)
<smoser> ok. well, for next time i guess blackboxsw
<smoser> put some info on bot meetingology at https://public.etherpad-mozilla.org/p/cloud-init-meeting ?
<smoser> # topic: open Discussion
<smoser> The biggest followup item really was to discuss release items such as frequency and version numbers.  'Proposal: Roll over to 1.0.0' in the post is generally accepted by myself and others.  So I think that we will probably move to 1.0.0
<blackboxsw> sure will do
<blackboxsw> strange that it's not here anymore. will get that up for next meeting
<smoser> i think that targetting 3 month release cycles seems sane.
<larsks> +1 on that.
<powersj> sweet
<powersj> smoser: https://code.launchpad.net/~powersj/cloud-init/+git/cloud-init/+merge/327646 can that get a review? ;)
<powersj> pretty please
<smoser> the 3 month ish release cycles im' more sold on. as semantic versioning is kind of hard for me to find a obvious mapping.
<smoser> because
<blackboxsw> heh, yep powersj smoser and I both said it'd be on our radar for today
<smoser> a.) we generally try to be backwards compatible always
<smoser> b.) we don't really offer/support python api (but rather just config module input and such)
<smoser> c.) "major feature" on one platform is not necessarily anything to another platform (datasource)
<larsks> smoser: I'm certainly not a stickler for semantic versioning, just for rational versioning that communicates somehow that magnitude of changes between releases.
<smoser>    even the addition of a new datasource... which is clearly a big deal (we added Scaleway) means nothing for others.
<smoser> larsks, it is still hard...
<rharper> smoser: generally discussing the roadmap, what we expect to land in the upcoming release should I think bring about any discussion needed about "major" version bumps and what not
<larsks> Sure.  I guess an alternative, with a regular release cadence, is ubuntu-style month/year based versioning.
<smoser> it certainly seems to me that unless you intend to service the right-most digit of X.Y.Z (or X.Y) then it has no value.
<rharper> some downstreams may be interested in just that
<larsks> I guess.  I mean, I would argue that if a release consistents pretty much exclusively of bug fixes, that's a .Z release, and if a release introduces new data sources or major internal changes, that's a .Y, and if the behavior changes significantly, that's a .X.
<smoser> ie, at this point i do not have intention of upstream maintaining a 1.0 branch to 1.0.1 and 1.0.2 ... (or 1.0.1.1 ... )
<blackboxsw> so a major.minor bump then based on release cadence ++ an eye to major changes might be of interest
<dpb1> smoser: then perhaps a YY.MM scheme might be better
<dpb1> since it more closely matches the release scheme
<smoser> yeah.
<rharper> I think the majority of our "major" features are known within a 6 months timeframe (even 3 months)
<rharper> so, whatever the numbers are, discussing the features/roadmap here will make folks interested in the numbers aware of what they mean
<smoser> i think that i like the idea of time based release numbers
<smoser> and documenting what changes/features/function are in each
<larsks> That seems fair.
<smoser> hm..
 * smoser just can't bring himself to type high version numbers
<rharper> 17.09 is just around the corner
<rharper> 0.7.9 -> 17.09?  mostly the same numbers, just reordered
<smoser> yeah.. i noticed that too.
<larsks> Ha :)
<dpb1> numerology, fantastic
<smoser> and arguably so is 7.9
<rharper> the stars are alined
<rharper> aligned
<smoser> (dropping 2010 years)
<dpb1> all hail the 17.09
<rharper> yeah, 17.9 would work
<rharper> 17.9 -> 17.12 -> 18.3 -> 18.6 etc ?  or do we want the extra zero for comfort ?
<smoser> well, the other option is openstack based.
<smoser> they dont mark months
<smoser> just releases in that year
<smoser> 17.1 and 17.2
<dpb1> I like that
<larsks> Yes, but then you'll endup with people spawning cloud-init sub-projects with names like "Zarkon" and "Farfnagle".
<blackboxsw> hah
<smoser> larsks, this is a good point.
<blackboxsw> (can we call that a "feature" :) )
<dpb1> larsks: may it never be!
<dpb1> smoser: so
 * larsks has the branch name for his next patch.
<smoser> it feels to me like i'd keep 17.XX including the zero
<rharper> larsks: those are great names!
<dpb1> one thing we had in previous projects
<dpb1> is the month would change out while qualling the release
<larsks> dpb1: "qualling"?
<dpb1> then we were like "should we keep it .06 or .07"
<dpb1> qualing
<dpb1> or quailing
<smoser> because Ubuntu 17.10 having cloud-init 17.1 (which was released in the 9th month of 2017) is confusing.
<dpb1> doing QA/bug fixing
<larsks> Ah, got it.
<powersj> smoser: does that mean SRUs to xenial will have 16.04 and a 17.09 in the version?
<rharper> powersj: yeah it would
<powersj> :\
<dpb1> yup
<smoser> powersj, numbers mean nothing
<powersj> then use 1.0.0 ;)
<rharper> except to those who think they do
<dpb1> I thought we just established they mean everything and we should hail them
<rharper> however, only for 18.04;  16.04 will forever have 0.7.X.16.04.  ... even if it's cloud-init 17.12 or whatever
<smoser> rharper, no
<smoser> if we new-upstream-snapshot back to 16.04 it will get a new upstream version
<smoser> and that is perfectly fine
<rharper> ok, so it'll look strange no matter what
<smoser> dpb1, you mentioned concern that "qualing" could change the month
<rharper> smoser: so on new-upstream release in say xenial, would we ever have a ~16.04.x value?
<dpb1> just that it happened often for us
<smoser> rharper, well it gets a 16.04.1 value, but that is only to make it < the package version in another ubuntu release.
<dpb1> we would start mid september, name the release 17.09, then come october, we would be done and go "oops, now we need to rename to 17.10"
<smoser> (that is the only reason those exist... to account for upgrades xenial -> yakkety -> zesty -> aa ... )
<rharper> we wouldn't rename a release
<dpb1> in the end it didn't matter, as you mentioned, but it bugged us
<dpb1> yes
<dpb1> I think in our case, we don't name it till we ship it, that's fine
<smoser> it does kind of get named.
<smoser> at some point you change cloudinit/version.py
<dpb1> smoser: it's why I said I liked the "17.1, 17.2" scheme
<smoser> i dont know.
<dpb1> but, it's minor
<dpb1> and in the end it didn't really matter
<dpb1> was more of a programmer brain thing
<smoser> dpb1, my only issue with that is confusion with ubuntu
<smoser> similar but different
<dpb1> yes
<dpb1> well, making it different helps
<dpb1> with powersj's concern
<rharper> but not different enough (for ubuntu folks)
<dpb1> 16.04...17.1
<rharper> but maybe that's just our problem
<dpb1> you get used to it, but ya, it can be slightly confusing.
<smoser> ok.. .so ignoring that
<dpb1> openstack has the same issue, so it's at least not crazy
<smoser> lets target a release say on 21 of Sept
<smoser> as a stick in the mud
<smoser> and that would be called either 17.9 or 17.1
<dpb1> week before rally
<dpb1> fyi
<smoser> that seem sane ?
<dpb1> +1
<rharper> +1
<rharper> though not sure how we resolve the .9 or .1 part
<dpb1> wise sage once told me if there truly is no best choice, coin flip
<larsks> rharper: flip a coin + documentation, I guess.
<blackboxsw> release sounds good , we can get heads together at the rally if we need to work out SRU issues
<rharper> larsks: hehe
<dpb1> actually, there is a better one
<dpb1> you coin flip
<smoser> https://www.google.com/search?client=ubuntu&hs=VJz&channel=fs&q=flip+a+coin&stick=H4sIAAAAAAAAAHvEaMct8PLHPWEp00lrTl5j1OcSyylKS0wuyS-qtHIrzUvKrwjOzC3ISRUS5WIpqSxIFeLl4pbiTM7PzItPy8ks4AEAyHBN80EAAAA
<dpb1> then, if you are dissapointed, you choose the opposite
<rharper> lol
<smoser> other htan ubuntu tie in... i really prefer using only the year.
<smoser> ie... 17.1 -> 17.2 independent of the month
<dpb1> it's my preference still
<dpb1> (slight)
<powersj> I like without the month as well
<blackboxsw> I'm all for either, I'd like to avoid where the month ends up being incorrect because of release slip due to testing etc
<rharper> I like the month, feels like a forcing function since the version is fixed but I don't care that much, and it would make the version different than the ubuntu numbers
<smoser> ok. so i'm ready to be done with this. so heres what i propose
<blackboxsw> ... though I realize this discussion walking fairly close to bikeshed territory. I'm up for whatever folks think is sane
<smoser>  * i pretend that i flipped a coin and it came up in favor of my preference (no minor version linked to month)
<smoser>  * i write to mailing list with that as the plan and suggesting the target release date of 17.1 on the 21.
<smoser>  * ask for anyone who would *strongly* oppose to say so
<smoser> objections ?
<larsks> Sounds good to me.
<smoser> alright.
<smoser> so i'm gonna call this meeting "done" for now. and office hours for the next 30 minutes or so.
<smoser> (although i'm going to step out for 5)
<smoser> objections before i step out ?
<rharper> +1 smoser
<blackboxsw> none here
<blackboxsw> larsks: I just landed your move tests/unittests/helpers -> cloudinit/tests branch. thank you for the attention there https://code.launchpad.net/~larsks/cloud-init/+git/cloud-init/+merge/329661
<larsks> blackboxsw: awesome, thanks!
<larsks> On a completely different topic: is there somewhere in launchpad a link to https://launchpad.net/cloud-init/+activereviews? I can never find it when I want it and end up googling the answer.
<blackboxsw> larsks: https://code.launchpad.net/cloud-init/+activereviews
<blackboxsw> is what I review daily.
<larsks> That...is the same thing I just pasted. I mean, is there a link somewhere ("show all active reviews") that goes there?
<powersj> here: https://code.launchpad.net/~cloud-init-dev/cloud-init/+git/cloud-init/+ref/master click on "20 branches"
<blackboxsw> heh. oops
<larsks> powersj: Ah, thanks!
<powersj> it includes work in progress, but gets you that same list
<powersj> larsks: also sent you mail last week, if you wouldn't mind looking for it sometime after catching up would be much appreciated
<larsks> powersj: yah, catching up on oodles of email today :)
<powersj> I'm sure :)
<powersj> no rush
<blackboxsw> harlowja: I noticed your irc client joined mid meeting, figured I'd touch base on this in case you were watching.  I was touching cc_resizefs and saw something that appears to us like vestigial config option "resize_rootfs_tmp"  the only thing the module does with this is ensure_dir to create the directory "/run" if it doesn't exist.
<harlowja> hallo
<harlowja> will look in a sec blackboxsw (in standup)
<blackboxsw> +1: hiya harlowja.  I was going to drop the resize_rootfs_tmp if you didn't think it had any meaning anymore
<blackboxsw> http://cloudinit.readthedocs.io/en/latest/topics/modules.html#resizefs
<blackboxsw> a review point  for smoser I think. I'm good w/ sankar's https://code.launchpad.net/~sankaraditya/cloud-init/+git/cloud-init/+merge/319866 for OVF.  I *think* it's in state to land but wanted to make sure you were good w/ the rewriting of the broken /etc/network/interfaces which adds back the "include /etc/network/interfaces.d" that he's doing there.
<smoser> blackboxsw, also see topic
<smoser>  http://bit.ly/ci-reviews
<blackboxsw> meh, I keep using the bzr review url without realizing it. force of habit
<blackboxsw> for shame
<blackboxsw> smoser: I pinged in #meetingology channel to try to get that bot added again for us. it dropped out on Aug15th I think looking at IRC logs
 * blackboxsw has to run an errand, back in ~20 mins
<powersj> smoser: https://bugs.launchpad.net/cloud-init/+bug/1715095 another good bug report worth a comment
<ubot5`> Ubuntu bug 1715095 in cloud-init "network is only configured on first boot" [Undecided,New]
<blackboxsw> yay!
<blackboxsw> #startmeeting  cloud-init status meeting
<meetingology> Meeting started Tue Sep  5 21:56:34 2017 UTC.  The chair is blackboxsw. Information about MeetBot at http://wiki.ubuntu.com/meetingology.
<meetingology> Available commands: action commands idea info link nick
<blackboxsw> #subtopic valuable subthread
<blackboxsw> #link https://cloud-init.io
<blackboxsw> #endmeeting
<meetingology> Meeting ended Tue Sep  5 21:57:47 2017 UTC.
<meetingology> Minutes:        http://ubottu.com/meetingology/logs/cloud-init/2017/cloud-init.2017-09-05-21.56.moin.txt
<blackboxsw> this concludes a test broadcast
<dpb1> hi meetingology!
<blackboxsw> I wasn't sure why it left us. but wanted to make sure we queued up one meeting so it didn't detach due to idle time or something
<dpb1> hrmph
<dpb1> blackboxsw: how did you get it back in?
<blackboxsw> I talked to jose in #meetingology channel on freenode
<dpb1> blackboxsw: did he say why it left?
<dpb1> does he just not like us?
<blackboxsw> it just involved him (as admin) running       meetingology: join #cloud-init
<dpb1> two separate "he"s there
<blackboxsw> no but I'll ask to be sure
#cloud-init 2017-09-06
<redcavalier> Hi, I've updated my cloud-init to 0.7.9 on centos 7 with a centos 7 package I found there : https://buildlogs.centos.org/c7-extras/cloud-init/20170705233059/0.7.9-3.el7.centos.x86_64/
<redcavalier> I've been testing the new version and I'm getting a strange error regarding utf8 encoding when my test VM starts
<redcavalier> Essentially I get AttributeError: 'dict' object has no attribute encode . Is that version of cloud-init currently compatible with openstack?
<blackboxsw> redcavalier: could you file a bug, I know we have builds using copr build service https://copr.fedorainfracloud.org/coprs/g/cloud-init/el-testing/builds/
<blackboxsw> 0.7.9.3 per your version feels stale compared to 	0.7.9+224.g681baff-1 in our copr build service
<blackboxsw> if you hit this issue again on the newer centos build, I'd be curious to see /var/log/cloud-init.log from the affected system
<blackboxsw> https://bugs.launchpad.net/cloud-init/+filebug if needed
<redcavalier> blackboxsw, thx, I was under the impression that copr only had recent fedora builds. I'll try that build and come back if I still get an error
<redcavalier> a shame that the official centos repo's versions are downright ancient.
<blackboxsw> per earlier meetingology discussion:   4:12 PM J<â¢jose> it should stick. we had an issue and I had to kill all the meetingology instances, that's why it got out
<blackboxsw> yeah, though it's hard to get every distro to update on the same schedule :)
<redcavalier> blackboxsw, still got the error, here's the full trace of it : https://pastebin.com/tmv7asfL
<blackboxsw> hrm I guess what content was in vendordata_raw from your openstack instance. might have to dig into this a bit more, could you file a bug redcavalier (I'm end of day today) include the following if you could http://pastebin.ubuntu.com/25475835/
<redcavalier> sure no problem
<blackboxsw> I know you are centos && openstack and our latest copr build. but the  rest would be good contxt
<blackboxsw> cheers
<redcavalier> thx
<larstobiweb> I am trying to get cloud-init to interpolate $local-ipv4, $local_ipv4, $private-ipv4 or $private_ipv4, but none of them work. I am booting CentOS 7 with cloud-init 0.7.9 on CloudStack. "curl -s http://10.30.5.1/latest/meta-data/local-ipv4" from within the VM shows the IP address that I want.
<larstobiweb> I also couln't locate the place in the docs where this is described.
<larstobiweb> Can anybody help me find out how I can get cloud-init to interpolate the local ipv4 address in the cloud-config?
<blackboxsw> smoser:EphemeralIPv4Network does already             self.cleanup_cmds.append(
<blackboxsw>                 ['ip', '-family', 'inet', 'link', 'set', 'dev', self.interface,
<blackboxsw>                  'down'])
<blackboxsw> that should be run via subp on __exit__ from EphemeralIPv4Network
<blackboxsw>                 ['ip', '-family', 'inet', 'addr', 'del', cidr, 'dev', self.interface] too
<blackboxsw> If we are seeing devices left "up" maybe cloud-init saw them up in the first place, and would have logged Skip ephemeral network setup, %s already has address %s
<smoser> blackboxsw, well, i think i see a few issues.
<smoser> maybe_perform_dhcp_discovery() sets link up but never sets it down
<smoser> (and that state would be inherited by EphemeralIPv4Network)
<smoser> and then i *think* EphemeralIPv4Network unconditionally will take it down
<blackboxsw> ahhh right, right on maybe_dhcp_discovery
<blackboxsw> hmm so, in that case I'd expect to see Skip ephemeral network setup, %s already has address %s in our ec2 logs always
<blackboxsw> and ephemeralIPv4 will leave an "up" interface up if it specifically didn't set it up
<blackboxsw> so that logic interaction between maybe_dhcp_discovery and Ephemeral needs a fix
<smoser> blackboxsw, i just launched an instance. i'll import you to poke around in a minute
<blackboxsw> same
<smoser> ubuntu@13.58.109.199
<blackboxsw> ahh thanks
<blackboxsw> 2017-09-06 16:01:03,490 - util.py[DEBUG]: Running command ['ip', '-family', 'inet', 'link', 'set', 'dev', 'eth0', 'down'] with allowed return codes [0] (shell=False, capture=True)
<blackboxsw> looks like we tore it down smoser
<smoser> blackboxsw, wrt this breaking some-old-openstack
<smoser> theory: non-intel fell down the "fallback to ec2" path because of non-intel
<smoser> then we end up trying the new api endpoint
<smoser> which probably doesnt exist (that i can verify)
<smoser> we should actually be able to force this failure path on server stack
<smoser> or  get close
<blackboxsw> ahh you mean we somehow die on ec2 inspecting 2016-09-02 version
<blackboxsw> agreed, we can try that route. or I wonder about  our test httpretty regiester_mock_metaserver
<blackboxsw> hmm, server stack would be the easiest route for a real openstack env. I'm looking over DataSourceOpenStack to see what it does w/ network setup
<blackboxsw> smoser done w/ ubuntu@13.58.109.199 thanks. I'll play w/ other instances
<blackboxsw> shall I shut it down?
<smoser> blackboxsw, i'll kill it. thanks.
<asthasr> Hi! Just a quick question. I am trying to make custom AMIs using Packer. I would like every machine that I spin up with this custom AMI to execute a cloud-init script once (to pull configuration). What is the most robust way to make this happen?
<blackboxsw> asthasr: when you say once, do you mean once per boot, or once per instance? Maybe you are talking about something like this? https://cloudinit.readthedocs.io/en/latest/topics/modules.html#scripts-per-once
<blackboxsw> you can install your own scripts in an ami which run every time the machine instance id changes, or per-boot etc.
<asthasr> Ok, cool.
<asthasr> When do "per-instance" scripts run? Is that after the first boot of an instance with a new ID?
<asthasr> i.e. I make the AMI, put something in per-instance, and then if I build a new machine based on that, it'll run?
<asthasr> (I saw this list before but the difference between per-once and per-instance was not clear to me.)
<smoser> asthasr, yes.
<smoser> per-once will run once ever (marker files are written with no specific instance data)
<blackboxsw> correct, new intance-id is generated each time the AMI is "built/deployed"
<blackboxsw> correct, new instance-id is generated each time the AMI is "built/deployed" for per-instance
<smoser> per-instance will run once per instance-id (marker files contain instance-id in their path)
<smoser> per-always will run every boot
<smoser> instances are things which are created from images.
<smoser> ami == amazon machine image
 * asthasr nods.
<smoser> so each thing you launch from athis ami that you built is a unique instance
<asthasr> yeah. My desired workflow is: create a "template" server, run packer to make an ami, then use terraform to spin up instances based on that ami, which (upon booting) run ansible to configure themselves
<asthasr> so per-instance sounds right.
<rharper> blackboxsw: did you have  a branch which added a subcommand to crawl/dump metadata (like openstack) ?
<smoser> asthasr, the only thing i'd suggest is not bothering to build your own images.
<smoser> but rather to either
<smoser> a.) use unmodified "Official" Ubuntu images
<smoser> b.) download images from cloud-images.ubuntu.com as a starting point and make your modifications and upload.
<asthasr> Certainly, I intend to use an official Ubuntu 16.04 and just make some basic configuration changes to it
<smoser> "packer to make an ami"
<smoser> i'm saying skip that
<asthasr> but why? It seems like if I want to rebuild a machine it's quicker to have an image that has all the prereqs and such on it beforehand
<blackboxsw> rharper: that branch I haven't put together yet (it's a followup to https://code.launchpad.net/~chad.smith/cloud-init/+git/cloud-init/+merge/330115 )
<blackboxsw> wanted to land the prerequisite first
<rharper> cool
<blackboxsw> rharper: shameless plug for a review on that branch :)
<rharper> I think I've given you one, no ?
<blackboxsw> refresh says no comments on this branch
<rharper> noo! I must have closed the tab before submit
<rharper> ok, I'll re-review
<smoser> oh. asthasr i guess i didnt understand how packer worked.
<smoser> i always asumed it built the image "from scratch".
<blackboxsw> bah, hopefully launchpad saved the unsaved comments
<rharper> blackboxsw: man, I even updated the commit message and had comments; so strange
<smoser> rharper, how did you get status from systemd-resolved?
<asthasr> smoser: No, you just spin up a box and then configure it how you want and then it takes that box and makes a new image from it
<asthasr> smoser: So, it can be based on whatever base AMI you want :)
<rharper> systmed-resolved --status (but only on artful IIRC)
<rharper> systemd-resolved --status
<rharper> err, drop the d; systemd-resolve --status
<rharper> smoser: ^
<smoser> yeah. i see. thanks.
<dhill_> hey guys
<dhill_> what could make cloud-init truncate /var/log/messages?
<dhill_> I looked at the code and didn't find anything...
<rharper> cloud-init doesn't touch /var/log/messages ;  it owns /var/log/cloud-init.log and /var/log/cloud-init-output.log
<rharper> cloud-init will use syslog;  so maybe a local config that triggered logrotate ?
<rharper> do you have messages.1 ?
<dhill_> rharper, nope... and that's what I was expecting to hear from you :)
<dhill_> rharper, I looked at the code and nothing mentionned /var/log/messages from close or far
<rharper> right, and what about possible rotated files?  do you know how (or if) logrotate is configured on your instance ?
<blackboxsw> powersj: additional comments on https://code.launchpad.net/~powersj/cloud-init/+git/cloud-init/+merge/327646
<powersj> blackboxsw: getting the command line for your failures would be very helpful
<powersj> common theme from the reviews I've seen is how the lxd backend returns return codes and kvm does not
<powersj> that's the reason for the "0"
<blackboxsw> I'm with you on the 0 being returned from execute() just feels strange from within mount_image_callback
#cloud-init 2017-09-07
<Be-El> hi
<Be-El> we are planning to provide a shared filesystem in our cloud, and the information how to mount is should be stored in the vendor data. but we want users to have more control over it, e.g. enable/disable mounting
<Be-El> is there a simple way to do this, or does it require an extension to cloud init itself?
<smoser> Be-El, who is "we" are you the cloud provider or the user? and what is the cloud ?
<smoser> if cloud-init gets storage configuration that says to mount things, it will write those things into /etc/fstab.
<smoser> user-data can be used to override any vendor-data provided.
<Be-El> 'we' are a group of several cloud providers working together and trying to provide a similar service to our users
<Be-El> the details for each site (e.g. filesystem, host names / ip address of fileservers) may and will vary
<Be-El> the cloud instances are all based on openstack, and using the package and mount modules works so far
<smoser> so if the user wants to override the data you've provided they can provide 'mounts: []'
<smoser> that should work, then they'll get none. user-data wins over vendor-data.
<Be-El> but I want to restrict the functionality to certain images (afaik there's no image metadata that can be accessed by cloudinit) and allow the user to disable it
<smoser> so you want the vendor-data to only appear to certain images ? is that what you're saying ?
<Be-El> that would be my preferred solution
<smoser> well, when i originally added vendor-data support on openstack i  did so in a way that you could implement a python class on the host.
<smoser> that class was given the instance-id and told to give vendor-data
<smoser> the default class just  read from the /etc/.../vendor_data.json
<smoser> (this is from memory)
<smoser> but then at some point openstack started ripping out things like that. so that extensible functionality might be gone now
<Be-El> I'm currently thinking about a helper script whose execution is triggered by runcmd in vendor-data
<Be-El> and the script checks for the existence of some touched file (-> user data) and skips the mount operation
<Be-El> script arguments will define the mount options etc.
<Be-El> doable, simple design, but feels wrong
<smoser> well, if you want to provide different vendor-data to different instances based on some criteria, that was originally supported.
<smoser> and i think that is what "would be [your] preferred solution".
<smoser> so honestly that is what i would go for.
<smoser> it looks like current openstack trunk has some mechanism to run a vendor-data service and have nova client plug into that.
<smoser> i'm just looking at git logs
<Be-El> the clouds are all based on the newton release, and openstack version upgrades are not that easy... ;-)
<dpb1> heh
<Be-El> there's a vendordata_driver option, but it is marked as deprecated
<smoser> well. 1f53bfcc7998f63f130a2cedaf15b41a4506c568
<smoser> is a good commit message
<smoser> https://review.openstack.org/gitweb?p=openstack/nova.git;a=commitdiff;h=1f53bfcc7998f63f130a2cedaf15b41a4506c568
<smoser> "It is intended that this fix be backported to newton as well."
<Be-El> newton also has a mechanism for using external rest services instead of a simple file
<Be-El> not as easy as just providing the python class, but i'll have a closer look at it. thx for the hints
<Be-El> does cloud-init already use vendor-data.json and vendor-data2.json?
<smoser> does not read vendor-data2.json only vendor-data.json
<smoser> what is interesting to me is that they coudl have  used the existing class functionality to implement the remote rest api stuff
<smoser> and thus kept backward compatibility a
<smoser> oh well
<smoser> but i guess they wanted to be more strict on the extensibility portion
<Be-El> and backwards compatibility, data merging....
<smoser> blackboxsw, rharper i'm working on bug 1715128
<ubot5`> bug 1715128 in cloud-init (Ubuntu) "Crashes in convert_ec2_metadata_network_config on ScalingStack bos01 (ppc64el)" [Critical,Confirmed] https://launchpad.net/bugs/1715128
<smoser> Be-El, are you poking fun at me!
<smoser> (its entirely acceptable)
<Be-El> i'm german, we don't know how to have fun
<rharper> smoser: yeah; two things  1) we certainly should check that we have 'network' in the metadata dictionary safely  2) EC2Local runs before OpenStack datasource;  that's generally a problem if local datasources are positively identified
<rharper> for Azure, we confirm UUID;  and I thought that EC2 in Artful was in strict mode, which should have forced the UUID check, no ?
<smoser> rharper, well, yeah.
<rharper> oh, right
<rharper> well, even on non-intel, the system has a UUID, so unless they rolled unluckily and got ec2* for their UUID
<smoser> https://code.launchpad.net/~smoser/cloud-init/+git/cloud-init/+merge/330361
<smoser> rharper, systems only have uuid (from dmi) on intel
<smoser> not sure what you were meaning
<rharper> on intel, yes via dmi;  in ppc64 though, they do set a uuid value from the hypervisor; they just don't send any product or other DMI related values (and it's not under the dmi path in sys)
<rharper> that info won't identify it as OpenStack, but it can be used to check that it's not EC2 (which I think is the path you're taking w.r.t EC2Local);
<rharper> as other platforms run in Local mode and hit network; I think we need to require the positive ID to run the local variant
<smoser> well.. due to clones it can't identify "not ec2"
<smoser> we could be more strict yes. but we are not, so that it generally still works but give the warning, so we can fix things later (on non-intel).
<smoser> on intel, cloud-init would have disabled completely
<rharper> do the clones report ec2 in UUID ? I didn't think any of them actually did that  vs. just subclassing EC2 and providing something else to identify themselves
<smoser> unknown clones is the concern.
<smoser> as they do not identify themselves at all and rely upon the old default behavior of falling back to ec2
<rharper> ec2 in network mode though
<smoser> if you said "uuid doesnt start with ec2, so exit", then they'd get no warning
<powersj> smoser: rharper: can one of you respond to https://bugs.launchpad.net/cloud-init/+bug/1711963 Reporter is asking how to get vendor and user data working together.
<ubot5`> Ubuntu bug 1711963 in cloud-init "unable to merge vendor-data and user-data" [Undecided,Incomplete]
<smoser> this is wierd
<smoser> 2017-09-07 06:03:25,838 - stages.py[INFO]: Skipping modules ['runcmd'] because they are not verified on distro 'ubuntu'.  To run anyway, add them to 'unverified_modules' in config.
<rharper> whoa
<rharper> smoser: where's that from ?
<smoser> that was in the log on https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1715128
<ubot5`> Ubuntu bug 1715128 in cloud-init (Ubuntu) "Crashes in convert_ec2_metadata_network_config on ScalingStack bos01 (ppc64el)" [Critical,Confirmed]
<rharper> powersj: on that one maybe smoser;  by my read there isn't anyway to "merge" keys from vendor data into user-data;  it's an override situation only ; ie, if you set the same key in user-data; that's all you get;  smoser do you expect that we could support a case where user-data wants to inspect/inherit vendor-data values ?
<powersj> rharper: thx for looking - that's what I thought and tried to say in my response, so hopefully having someone else convey it
<smoser> well it merges in some way.
<rharper> powersj: I think you did; the submitter is right that "merging" config isn't clear about which sorts of configs get merged (and which dont)
<smoser> it certainly *should* use the full merge support
<rharper> I think the request is to merge conflicting keys between user-data and vendor-data; which I've always understand that to not be mergable w.r.t combining keys
<rharper> that is, how would a user override vendor-data if it's always merged together ?
<smoser> user-data always "wins".
<rharper> right
<rharper> in this case, I think the submitter wants to modify that
<smoser> rharper, what is wierd in 'Skipping' above is that later in log
<smoser> 2017-09-07 03:06:10,312 - helpers.py[DEBUG]: Running config-runcmd using lock (<FileLock using file '/var/lib/cloud/instances/06c0123d-0393-44c7-87f5-3fb4734ffdd2/sem/config_runcmd'>)
<rharper> smoser: I can't find any record of that "unverified" string in cloud-init ; where is that coming from ?
<rharper> smoser: this is a proposed migration, right? so maybe it's being upgraded and rebooted ?
<rharper> so same instance but different behavior due to reboot and upgrade ?
<smoser> cloudinit/stages.py
<smoser>         if skipped:
<smoser>             LOG.info("Skipping modules %s because they are not verified "
<smoser>                      "on distro '%s'.  To run anyway, add them to "
<smoser>                      "'unverified_modules' in config.", skipped, d_name)
<smoser> i really can't come up with anything on that other than if they've added a cc_runcmd somewhere.
<smoser> i dont know
<rharper> commit cc9762a2d737ead386ffb9f067adc5e543224560
<rharper> Author: Chad Smith <chad.smith@canonical.com>
<rharper> Date:   Tue Aug 22 20:06:20 2017 -0600
<rharper>     schema cli: Add schema subcommand to cloud-init cli and cc_runcmd schema
<rharper> that added the 'distros' tag to the module; possible they're on older artful image, booted, upgraded cloud-init, rebooted
<rharper> and we don't handle that ?
<blackboxsw> reading backlog context now
<rharper> smoser: AFAICT this is a separate issue (unrelated to ec2 local on non-intel)
<rharper> we can file a separate bug for that I think
<blackboxsw> whoa, so if I add a distros attr to the module it requires some level of validation
<blackboxsw> ok looking at what we are doing there w/ the skip
<blackboxsw> strange as the module documentation claimed "all" was supported
<blackboxsw> (I think I also added a distros attr to cc_bootcmd too)
<blackboxsw> in a recent branch
<smoser> blackboxsw, yeah, i didn't understand how 'all' was working
<smoser> but it sure seems to be. otherwise runcmd would log that error everywhere.
<blackboxsw> yeah looks like we extrapolate mod.distros as worked_distros and check against the actual distro name.  ok, so we need to expand 'all' to all known cloud init distros or define  DISTROS_ALL = None
<blackboxsw> just filed #1715690 I'll get a branch together and I'm adding a unit test to https://code.launchpad.net/~smoser/cloud-init/+git/cloud-init/+merge/330361
<blackboxsw> https://bugs.launchpad.net/cloud-init/+bug/1715690 rather
<ubot5`> Ubuntu bug 1715690 in cloud-init "Defining distros = 'all' in a module for documentation results in a module skip as 'all' doesn't match distro 'x'" [High,New]
<smoser> ah. ok. so your chagne is new.
<smoser> that is good. understood now.
<blackboxsw> smoser: yeah and it affects the existing bootcmd branch too.
<blackboxsw> too bad we do discovery on distro modules, I was thinking it would be nice to have a get_all_distro_names() method, but that'd be expensive as I need to find_modules and collect all the names
<blackboxsw> maybe that's an okay expense as we do it only once in stages
<smoser> blackboxsw, i *think* runcmd is straight up busted then, right?
<smoser> as in an integration test of:
<smoser> runcmd:
<smoser>  - [touch, /run/foobar]
<smoser> would show that failure
<smoser> right?
<blackboxsw> yeah it'll skip it because it defines distros 'all' which doens't match actualy distro name
<blackboxsw> yeah I'll add an integration test
<smoser> blackboxsw, thanks.
<smoser> blackboxsw, so... on my networkign thing in ec2local
<smoser> i was saying i wanted to raise NotImplemented
<blackboxsw> I like the branch, wanted a tiny unit test but yeah
<smoser> but returning None is the same from the consumer's perspective
<smoser> ie, if that property (its a @property) is None
<smoser> then it is ignored
<blackboxsw> true, you mean from network_config
<blackboxsw> ?
<smoser> so returning None on that (and logging HEY THIS IS BUSTED)
<smoser> yes, network_config
<smoser> so if we lgged fail on that and returned None (as it did not actually have it) then we'd be better off
<smoser> but the issue with returning None is that it caches based on None
<blackboxsw> yes so network_config property in base could be smarter about 'network' KeyError and return None there
<smoser> hm.. let me show you what i was thinking
<rharper> smoser: where is the network-config cache check ?
<blackboxsw> was wondering about this http://pastebin.ubuntu.com/25484907/
<blackboxsw> rharper: line 287 of DataSourceEc2.py  if self._network_config is None
<rharper> certainly checking post convert if the value is still none would be valid
<rharper> but I guess I'm not getting the smoser is suggesting;   I think it's reasonable for the EC2 local ds to crawl metadata, not find the 'network' key and raise NotImplemented;  in stages, the _find_network_config would need a try: except NotImplemented and can log the NotImplemetnted exception (which ec2 could report that the metadata didn't have the 'network' key needed)
<rharper> s/the smoser/what smoser;
<smoser> http://paste.ubuntu.com/25484930/
<smoser> blackboxsw, ^
<smoser> None versus _unset ... not sure how you really are to do that.
<smoser> but still want to cache the None result as work was done.
<blackboxsw> smoser: in landscape we did UNSET = objecT()
<blackboxsw> smoser: in landscape we did UNSET = object()
<blackboxsw> but yeah I get it
<blackboxsw> smoser: per rharper's comment, returning a None here on when we have an invalid datasource doesn't really cause cloudinit/stages.py to balk on the datasource, it proceeds with fallback nic right?
<rharper> stages only cares if you have the attribute and assumes the network-config attr is valid
<rharper> I think we still need a way to tell stages that the network-config may not be valid
<blackboxsw> right so it feels maybe like our best approach is for get_data() to return false then right?
<blackboxsw> ocessingrso we don't even get into the network_config p
<blackboxsw> so we don't even get into the network_config processing
<rharper> well; whether or not we identify a datasource, and whether a datasource has network-config support are separate things that both need addressing
<rharper> the latter has a bug w.r.t a datasource claiming it has network-config support (which may not be valid) and stages assuming the presence of the attribute as an indication that the configuration in the attr is valid;
<blackboxsw> doesn't testing the return value None from datasource.network_config tell us whether the config is valid or not?
<blackboxsw> in the case of None, we know there is no helpful valid content provided by the datasource so it can be ignored in that case
<rharper> yes, you're right
<rharper> I see that now in find_network_config
<blackboxsw> yeah per even the default dscfg = ('ds', None)
<rharper> that works nicely with the attempted consuming of network metadata in smoser paste
<blackboxsw> to clarify for me: so if our ec2 local datasource is running in an openstack environment, get_data will still 'work' because it's a lookalike metadata service. but network_config would in this case not define network_config info. Won't the datasourceEc2Local still "match?
<blackboxsw> it'll just use fallback nic in this case
<rharper> which is what we'd want for look-a-likes which may not implement network metadata
<smoser> blackboxsw, i'd seen object() before too
<blackboxsw> I guess so, I wasn't sure if we'd want cloud-init to limp along using a sub-optimal datasource.
<smoser> but i was afraid of that across un-pickling
<blackboxsw> smoser: fair point. /me can't wait to remove pickling
<blackboxsw> .... and break things in the process
<smoser> it shouldl return None
<smoser> network_config attr of None
<smoser> means "this datasource has no network config"
<smoser> which is what the base class has
<blackboxsw> yeah I think rharper and I are on the same page w/ that
<smoser> and is what Ec2 had before it started to have that
<smoser> then stages does the right thing
<smoser> right
<smoser> yeah. ok.
<smoser> blackboxsw, so i'll commit the _unset thing ?
<smoser> unless you have a better idea
<blackboxsw> so in a situation where Ec2 is run  against openstack. get_data still 'works' and network_config returns None so LocalEc2 will still get detected or are you also leaving in the get_data check on Platform.AWS?
<rharper> Ec2Local shouldn't run under non-intel openstack; https://code.launchpad.net/~smoser/cloud-init/+git/cloud-init/+merge/330361 I think covers that;
<smoser> blackboxsw, yes. still leaqving the local check for platform.aws
<blackboxsw> smoser: +1 on adding your pastebin to the existing patch, I only think network_md should be mandatory param to the convert_ function. and the change to accept network_md will probably affect unit tests http://pastebin.ubuntu.com/25485096/
<smoser> blackboxsw, right. i'll change it to take mandatory
<smoser> and i have updated the test.
<smoser> blackboxsw, https://code.launchpad.net/~smoser/cloud-init/+git/cloud-init/+merge/330361
<smoser> updated
<blackboxsw> grabbing
<smoser> blackboxsw, i'm just going to grag stangatori's branch
<smoser> sound fine ? just merge
<blackboxsw> smoser: +1 on that
<blackboxsw> we can sort long-term cards for consolidation of comon 'imc' logic into cloud-init's net functions in subsequent cycles
<smoser> blackboxsw, https://code.launchpad.net/~smoser/cloud-init/+git/cloud-init/+merge/330242
<smoser> can you quick OK that ? i addressed your feedback.
<smoser> approve and mark approved
<blackboxsw> smoser: approved
<smoser> rharper, https://code.launchpad.net/~smoser/cloud-init/+git/cloud-init/+merge/329811
<smoser> can you just mark 'approved' ? you 'Need Fixing'd and then approved in words, but not in changing your status
<dpb1> smoser: so... #1711963.  legit bug?
<smoser> at very least a bug on doc
<dpb1> smoser: ya, the doc could use an example
<blackboxsw> smoser:  comments added here https://code.launchpad.net/~smoser/cloud-init/+git/cloud-init/+merge/330361 +1 with the unit test
<blackboxsw> smoser: left it as approved assuming the changeset passes CI (I tested locally w/ tox -e py27(
<smoser> blackboxsw, i'll grab your test.
<smoser> thanks
<smoser> blackboxsw, di dyou have a merge request that you wanted me to look at ?
<smoser> for https://bugs.launchpad.net/cloud-init/+bug/1715690 i thought.
<ubot5`> Ubuntu bug 1715690 in cloud-init "Defining distros = 'all' in a module for documentation results in a module skip as 'all' doesn't match distro 'x'" [High,New]
<blackboxsw> smoser: will put one up. I was sidetracked fiddling w/ unittests
<blackboxsw> I need about 20 mins
<blackboxsw> smoser: WDYT about a get_all_distros method in distros/__init__.py which calls importer.find_modules and returns a list of all discovered distro names supported
<blackboxsw> we'd only have to call that function once at  line 823  of cloudinit.stages
<blackboxsw> I'll draw up a sample diff
<blackboxsw> w/out unit tests for feedback
<rharper> smoser: done
<blackboxsw> side note, found a logic bug in stages
<blackboxsw> so for all modules we call distros.Distro.expand_osfamily
<blackboxsw> and we call expand_osfamilies(mod.osfamilies) and that'd raise a ValueError on undefined osfamilies. But an environment might have actually provided a pluggable Distro, which isn't tracked by expand_osfamilies. So they wouldn't actually be able to make use of that module
<blackboxsw> it's a corner case that impacts only non-std Distros which aren't already included in cloud-init/distros/OSFAMILIES
 * blackboxsw really dislikes the magic of def fixup_module(mod, def_freq=PER_INSTANCE):
<smoser> backwards compatibility
<smoser> and originally crappy smoser code
<smoser> make for crappy code
<blackboxsw> as it magically sets module attributes distros, osfamilies, frequency (due to the sideeffects & operations in stages.py)
<blackboxsw> hahaa
<blackboxsw> I'd much rather explicitly see osfamilies = [], distros = [], osfamilies = []  in all cc_*py . Then, at least it's more explicit in the module things that a module should care about defining
<blackboxsw> but yeah, not sure how that computes w/ backward compatibility
<blackboxsw> ok, for real, let me get a branch together.
<smoser> blackboxsw, ...
<smoser> if a:
<smoser>   print("this is fine")
<smoser> elif b:
<smoser>    print('this is also fine")
<smoser> else:
<smoser>    # i want to assert something here in a unit test...
<smoser> what do i use .. ?
<smoser> ah. maybe just raise assertionError
<blackboxsw> or just assert(something)
<blackboxsw> and it'll cause that assertion error to be raised in unit tests
<blackboxsw> I'm not sure that's what you meant
<smoser> well, i just want the test to FAIL
<smoser> i think
<smoser>  raise AssertionError("neither a nor b was true.")
<blackboxsw> I have seen that in unit tests before. it'll work
<smoser> rharper, commented https://code.launchpad.net/~smoser/cloud-init/+git/cloud-init/+merge/330361
<smoser> please read.
<smoser> basically.. .if we ds.network_config raises an exception, then cloud-init will generally fail. and such a failure will likely result in us seeing it.
<smoser> i'm not entirelsy opposed to having convert_ec2_metadata_network_config try better to check and raise ValueError and then catching that one error and returning None and logging WARNING.
<blackboxsw> smoser: rharper a lot of our modules document that they are supported on distros: all. Do we want module docs to represent the actual distro names, or would 'all' suffice
<blackboxsw> now that I have a get_all_distros function we could make docs specify: ['ubuntu', 'gentoo', 'freebsd', 'debian', 'fedora', 'centos', 'sles', 'rhel', 'arch', 'opensuse']
<blackboxsw> or just leave it at "distros: all" which could account for 3rd party distro modules added in another env
<blackboxsw> "it" being documentation on rtd
<smoser> blackboxsw, i think 'all' should suffice
<smoser> it means all distros supported by cloud-init
<smoser> no ?
<blackboxsw> yes on all distros supported by cloud-init.  And agreed, the generic 'all' feels better and doesn't preclude 3rd party distro addons if there were any
<blackboxsw> strange is we already have an integration test which exercises runcmd.
<blackboxsw> thrying to find out why that's not failing
<smoser> hm.
<rharper> blackboxsw: alternatively can we match any module if supported is 'all' ?
<rharper> that would avoid a list expansion
<blackboxsw> rharper: smoser just pushed functional https://code.launchpad.net/~chad.smith/cloud-init/+git/cloud-init/+ref/config-modules-allow-distros-all
<blackboxsw> it shows what I was thinking, I'm adding unit tests now
<blackboxsw> https://git.launchpad.net/~chad.smith/cloud-init/commit/?id=34297260006768be70904cecd2d66b2b5d97d2c4
<blackboxsw> yeah rharper that agrees with your suggestion
<blackboxsw> kindof
<blackboxsw> actually it doesn't. heh. it expands if 'all' is listed
<blackboxsw> lemme see if we can avoid it
<blackboxsw> hah, maybe I'm reading this wrong, that Skipped log is only a log, it looks like we still actually run the module
<blackboxsw> stages.run_section doesn't do anything with the skipped modules it finds
<blackboxsw> it still blindly calls _run_modules(mostly_mods)
<blackboxsw> it doesn't pop the module off or anything
<smoser> blackboxsw, that would explain integration test passing
<smoser> and lowers the severity of this bug :)
<blackboxsw> yep indeed
<blackboxsw> :)
<blackboxsw> I was searching the logs of that bug you referenced to see if I can find a successfully ran runcmd too
<smoser> rharper, what are you looking for on convert_ec2_...
<rharper> it return None if it's not equivalent to fallback (ie, we have  a subnet)
<rharper> we should either have  a subnet with dhcp, or  a subnet with a static ip
<rharper> otherwise, it's a busted network configuration
<blackboxsw> on the flip side of the "skipping " not really skipping, it also looks like forcing doesn't actually force the module to run either
<rharper> blackboxsw: =/
<blackboxsw> running unverified_modules: %s   is just a log and has no bearing on whether the module is run
<smoser> http://paste.ubuntu.com/25485882/ <--
<smoser> that has better validity checking.
<smoser> i'll get one more check
<blackboxsw> man that's a lot of bulletproofing smoser
<blackboxsw> feels like it's leaning toward overkill, and that we would actually run into that ValueError or TypeError issue if we try to use the object as a dict
<blackboxsw> >>> a ='non-dict'
<blackboxsw> >>> a['interfaces']
<blackboxsw> Traceback (most recent call last):
<blackboxsw>   File "<stdin>", line 1, in <module>
<blackboxsw> TypeError: string indices must be integers, not str
<blackboxsw> >>>
<rharper> I'm much more worried about the values and keys in the dictionary
<blackboxsw> why check isinstance dict everywhere and not just try to use the object and handle typeerrors instead
<rharper> mac address may be mixed case,  we might not have public-ipvX key;  any case where we get back a network-config that doesn't apply dhcp or a static ip is going to result in uncaught badness; in which case it would be better to report busted ec2 network config and use fallback
<rharper> note, this is for a  ec2-clone path
<blackboxsw> heh, validated the case from the Skipping runcmd logs, I see it also runniing that runcmd log (and why our integration tests still pass)
<blackboxsw> 2017-09-07 06:03:26,068 - stages.py[DEBUG]: Running module runcmd (<module 'cloudinit.config.cc_runcmd' from '/usr/lib/python3/dist-packages/cloudinit/config/cc_runcmd.py'>) with frequency once-per-instance
<blackboxsw> updating the bug
<smoser> blackboxsw, well, the individual checking gets you better error messages. is the only reason for that.
<smoser> and KeyError being more vague
<smoser> rharper, i dont necessarily agree that "better to report busted ec2 network config and use fallback"
<smoser> because "reporting" means no one ever sees a problem because you "fixed" it for them.
<rharper> that's fair
<smoser> where as failing badly means you see errors
<rharper> but see the bugs about non-intel identifying themselves in openstack for why to log and move forward
<smoser> http://paste.ubuntu.com/25485922/
<rharper> and the bug we're fixing today that's "cloud-init" fault in artful on non-intel
<smoser> rharper, wel... if we logged and moved forward there.
<smoser> we'd have just kicked the can well down the path
<smoser> and never known about the fact that these instances were now using the "mostly functional" ec2 datasource when it owuld have been better to use the openstack one
<rharper> I know; there's no good answer if we're not going to go and fix it ourselves
<smoser> which was the original design goal
<rharper> the busted network config (And using fallback) can have a banner just like ds-identify did
<smoser> well, one way or another we need to have this fixed today.   the fix that is there irght now will solve the bug
<smoser> and my today is running short
<blackboxsw> https://bugs.launchpad.net/cloud-init/+bug/1715738 filed
<ubot5`> Ubuntu bug 1715738 in cloud-init "Cloud config modules are not skipped based on distro support" [Undecided,New]
<rharper> I'm fine with a follow up
<blackboxsw> I'm+1 on your approach either way. will review what you have again smoser. I was just throwing peanuts at the testing if isdict, but not a true concern
<rharper> if I work on this: https://bugs.launchpad.net/cloud-init/+bug/1708255
<ubot5`> Ubuntu bug 1708255 in cloud-init "empty or invalid network config dictionaries are not handled well" [Undecided,New]
<rharper> that'll help
<smoser> ok.
<smoser> i'm going to add a unit test that trips the ValueError
<smoser> and then push with that patch most recent above.
<smoser> man though.
<smoser> that really would just kick the can and we wouldnt even know about this problem
<smoser> so maybe i convince myself to just leave it as it is
<asthasr> Good afternoon! Another question. I have put a script in /etc/cloud/scripts/per-boot (the pre-existing directory) while building an AMI. After standing up an EC2 instance based on this AMI, that script does not seem to run. Is there some config I have to set to make it happen?
<smoser> asthasr,  /var/lib/cloud/scripts/per-boot
<asthasr> oh.
<asthasr> what's the /etc one for?
<smoser> the same thing as /etc/i/dont/know/why/you/have/that/directory
<smoser> :)
<asthasr> oh, sorry, i misspoke. I'm actually putting them in /var/lib/cloud/scripts/per-instance. Long day :p
<smoser> asthasr, the module 'scripts_per_instance' should run those
<smoser> i'll do a quick test
<asthasr> my workflow is to use packer.io, which templates that script in, and then gives me an AMI. I then use terraform to build an instance based on that AMI
<smoser> rharper, :-(
<smoser> $ lxc init ubuntu-daily:xenial x2
<smoser> Creating x2
<asthasr> my expectation would've been that the script runs and I see the resulting test file when I log into the new instance
<smoser> $ mount-image-callback lxd:x2 mchroot /bin/bash
<smoser> lxd:x2: no rootfs in /var/lib/lxd/containers/x2/rootfs. Not a container?
<rharper> smoser: whoa
<rharper> =(
<smoser> i think the path now doesn't get created until 'start
<rharper> boo
<rharper> issue time
<rharper> hrm, working for me on xenial
<rharper> smoser: what lxd do you have ?
<rharper> I'm on 2.0.10-0ubuntu1~16.04.2
<smoser> $ dpkg-query --show lxd
<smoser> lxd	2.17-0ubuntu2
<smoser> i noticed it a while ago
<smoser> i'll file an issue, but i dont have high hopes
<rharper> well, it's pretty critical to our integration testing on lxd no ?
<asthasr> well, I'm dumb. It needs to be u+x or it won't run.
<asthasr> :)
<rharper> asthasr: was there any log about it not being u+x ?
<rharper> I think scripts-per are executed via cloud-init invoking subprocess on 'runparts'
<rharper> run-parts;  hopefully we caught some error there
<asthasr> rharper: not that I see.
<asthasr> saw, I should say; I didn't spot any errors. Unfortunately I already killed the instance.
<rharper> if you recreate, would be good to get the cloud-init.log (and cloud-init-output.log) and file an issue; it'd be helpful to see an error in the logs for something like that I think
<smoser> https://github.com/lxc/lxd/issues/3784
<asthasr> rharper: Understood. Will try tomorrow.
<smoser> rharper, we have a runparts function. does not use the utility
<smoser> it does not log anything on non-executables
<rharper> indeed
<smoser> uploaded ubuntu/0.7.9-267-g922c3c5c-0ubuntu1
<blackboxsw> smoser: are we SRUing that?
#cloud-init 2017-09-08
<smoser> blackboxsw, we will. none of those are terribly important. the ppc64 breakage isn't present in the SRU'd version.
<smoser> i dont think
<smoser> blackboxsw, i should have noticed / thought of this before, but by doing the json schema doc
<smoser> we lose
<smoser>  python3
<smoser>  >> from cloudinit.config import cc_bootcmd
<smoser>  >> help(bootcmd)
<smoser> er... help(cc_bootcmd)
<smoser> right ?
<blackboxsw> hrm right smoser
<blackboxsw> sorry was in another window
<blackboxsw> good thought, I bet we can fix that
<blackboxsw> yeah I can fix that.  smoser WDYT? http://paste.ubuntu.com/25491373/
<smoser> blackboxsw, http://paste.ubuntu.com/25491366/
<smoser> that was mine
<blackboxsw> haha
<smoser> yours prettier
<blackboxsw> yeah we already have get_schema_doc. no need for a 2nd function :)
<blackboxsw> I can fold that into the cc_bootcmd/resizefs branch (and fix runcmd/ntp as well)
<smoser> get_schema_doc modifies schema
<blackboxsw> ahh true, could deepcopy
<smoser> the other issue with your solutin there is it is slow. i think
<smoser> i think we then hit usage of yaml on import of cc_bootcmd
<smoser> so i dont know.
<blackboxsw> lemme see how yours outputs
<smoser> not anywhere near as nice.
<smoser> and i'd have used yorus if i had know of that
<blackboxsw> right, but at least it's something (because I'd like to trim the module docstr to a single line of text in all modules w/ jsonschema)
 * blackboxsw really wonders how much 'support' we need to worry about for help() callers in python shell
<blackboxsw> I'd be inclined to use your markup to meet the need if it arises (but avoid the cost of templating etc on module load)
<smoser> blackboxsw,
<smoser>         yaml_string = yaml.dump(property_dict.get('enum')).strip()
<smoser>         property_type = yaml_string[1:-1].replace(', ', '/')
<smoser> is there a reason not :
<smoser>  property_type = '/'.join(property_dict['enum']) ?
<blackboxsw> smoser: for docs I wanted the actual strings rendered to match what we expect users to write in a yaml file
<blackboxsw> 'true/false' instead of True/False
<smoser> ah. that does make sense.
<blackboxsw> but doesn't yaml accept both?
<blackboxsw> Regexp:
<blackboxsw>  y|Y|yes|Yes|YES|n|N|no|No|NO
<blackboxsw> |true|True|TRUE|false|False|FALSE
<blackboxsw> |on|On|ON|off|Off|OFF
<blackboxsw> meh, so maybe it doesn't matter http://yaml.org/type/bool.html
<blackboxsw> heh not fully supported
<blackboxsw> http://pastebin.ubuntu.com/25491483/
<blackboxsw> some of the regexps don't seem to match. better to be safe/strict
<smoser>  http://paste.ubuntu.com/25491485/
<blackboxsw> +1 simple and efficient
<blackboxsw> I'll add that smoser
<blackboxsw> better not to spec cycles on yaml.load if all we want is a simple dict lookuo
<blackboxsw> better not to spec cycles on yaml.load if all we want is a simple dict lookup
<smoser> blackboxsw, name 'ymap' as "_YAML_AS_STRING" or something and put it at top of that
<blackboxsw> yeah w/ a oneline comment explaining the intent
<blackboxsw> will do
<smoser> then, we're fairly close to not even importing yaml
<smoser> except on checking
<blackboxsw> could separate that to a different module
<blackboxsw> hrm, also in some of the other doc generation we have yaml.dump calls
<blackboxsw> like rendering schema['examples']
<smoser> i think that was the only other one
<smoser> right?
<smoser> blackboxsw, ^
<smoser> i'm not sure why wer'e using yaml to dump the examples, which are already formatted strings
<smoser> oh. i see.
<blackboxsw> sorry was running an errand.
<blackboxsw> smoser: yeah I had allowed for either md formatted strings or python dict objects
<blackboxsw> probably something that we don't really have to support and we could drop the yaml.dumps stuff
<blackboxsw> I had thought we might want to leverage examples automated  unittests, and having a examples in dict format already provided  would make it easy to pass into some automated handle tests.
<blackboxsw> but, we could just as easily have the unit tests yaml.load(example_content_string)
<blackboxsw> if we every go down that route in unittests
<blackboxsw> s/every/ever/
<smoser> http://paste.ubuntu.com/25491809/
<blackboxsw> I'm glad you agree :) and did the work
<blackboxsw> thanks
<smoser> hardest part was making flake8 happy
<blackboxsw> I like it
<smoser> and then we're not far from having yaml only necessary at all in the schema path when validating a cloud-config
<smoser> specifically *not* when validating a dictonary
<smoser> (i realize we have yaml everywhere, so not a big deal)
<blackboxsw> I'm not even sure we need the         else:
<blackboxsw>             example_content = '\n'.join([e + "\n" for e in example])
<blackboxsw> as all examples will now be an instance of string
<blackboxsw> still good to avoid dependency if we don't really need it
<smoser> yeah
<powersj> blackboxsw: rharper thanks for comments, uploaded new version
<smoser> powersj, of kvm ?
<powersj> smoser: yes
<powersj> smoser: thanks for the explanation re: arrays
<blackboxsw> smoser: pushed your changes into https://code.launchpad.net/~chad.smith/cloud-init/+git/cloud-init/+merge/330243 + added the __doc__ fixes and an Examples SPACER for documentation where modules have > 1 example
<blackboxsw> onto powersj branch
<blackboxsw> powersj: have you pushed this to latest? https://code.launchpad.net/~powersj/cloud-init/+git/cloud-init/+merge/327646
<blackboxsw> you mentioned uploaded new version, but I don't see new commites
<blackboxsw> you mentioned uploaded new version, but I don't see new commits
 * blackboxsw tries a git fetch
<smoser> blackboxsw, he ammended / --force i think
<smoser> i think
<powersj> yeah trying to keep it down to a single commit
<blackboxsw> +1
<blackboxsw> thx
<powersj> sorry.... if you wanted to see the diff
<blackboxsw> nah, just "broken" process for me when looking at a review I've commented on is seeing whether commits have come in afterward
<blackboxsw> I need to figure out a better process for finding updates on branches
<blackboxsw> how do you guys normally determine whether a branch you've reviewed has been updated? Just git fetch on the cmdline and watch whether a branch you care about updates?
<blackboxsw> also, as you mentioned powersj,  having actual commits of the diffs related to review comments speeds up the re-review because I can see what changed and if some comment was missed or interpreted a different way without hunting for the places where comments were made.
<powersj> yeah...
<blackboxsw> but, review 'speed' is not an issue when we leave a branch of yours floating in the breeze for weeks ;)
<blackboxsw> https://www.youtube.com/watch?v=bcYppAs6ZdI
<powersj> lol
<blackboxsw> powersj: approved https://code.launchpad.net/~powersj/cloud-init/+git/cloud-init/+merge/327646 thanks man
<powersj> blackboxsw: thx, if you do find a run that dies or has issues, please let me know :)
<blackboxsw> powersj: will run it again right now
<blackboxsw> what cmdline did you want?
<blackboxsw> the test run I called or the ssh connect from paramiko that is failing
<blackboxsw> 3 successes in a row on your latest branch
<smoser> powersj, i'm ok with allowing image.execute to take a string or an array
<smoser> and splitting it if it is a string
<powersj> smoser: ok do you want me to go back and revert places where I changed arrays to strings?
<powersj> blackboxsw: thanks for the re-test
<smoser> powersj, just commented there.
<smoser> wont your changes *break* lxd ?
<smoser> ah. you changed that one to take a string
<powersj> right and then res = self.pylxd_container.execute(['/bin/bash', '-c'] + [command]
<powersj> tested both backends ;) don't want any regressions
<smoser> http://paste.ubuntu.com/25492439/
<smoser> i'll propose that for merge really quick
<smoser> powersj, https://code.launchpad.net/~smoser/cloud-init/+git/cloud-init/+merge/330459
<powersj> smoser: +1'ed
<powersj> thank for that
<powersj> thank you for that rather
<blackboxsw> rharper: adapted util.json_loads to handle unserializable content, just pushed 95c1151..c000917
<blackboxsw> thanks for the review, https://code.launchpad.net/~chad.smith/cloud-init/+git/cloud-init/+merge/330115 is done
<rharper> blackboxsw: nice!
<rharper>  and no instance-data.json is written.  ?
<rharper> still true?
<rharper> in descr of commit
<rharper> on MP
<blackboxsw> ahh not true
<rharper> IIUC, we won't throw TypeErrors anymore?
<blackboxsw> lrharper: so, I'm pretty certain that no TypeErrors should be raised now during json_loads. But, I did leave the except TypeError: in get_data() just in case there is something I wasn't aware of. I didn't want some datasources to start raising TypeError exceptions on the json_loads call
<blackboxsw> but generally the json.loads(default=our_default_handling_functor)  should catch everything unknown to json
<rharper> ok
<blackboxsw> I'mchanging the commit msg for this to represent that
<rharper> hrm, I'm still confused
<rharper> we're parsing metadata ; then we want to dump the metadata which may have unserializble objects
<rharper> we don't have an json to load before we dump; so we still have a path where the metadata might have something we cant serialize
<rharper> no?
<rharper> what would be needed is for json_dumps() to replace the unserializable ojbect with some replacement string indicating error or something like that ?
<rharper> that may not be possible; however, we could pre-filter the metadata dictionary for content types that aren't json encodable (which is similar to the load IIUC)
<blackboxsw> correct rharper, I added json_serialize_default() which returns the string 'Warning: redacted unserializable type {0}'  for any unserializable keys/values
<rharper> blackboxsw: I think you confused me with the json_loads;  in dumps you set default=json_serialize_default, which looks like what I was suggested (replaces with string)
<rharper> nice
<blackboxsw> ahh sorry loads... my bad
<rharper> sorry for the confusion
<blackboxsw> I meant dumps.  Sorry for using the wrong words ;)
<rharper> excellent; that's really cool
<blackboxsw> so again , I *think* that should handle all cases of unserializable content, but I left the try/except ValueError & log.warning message in place just in case we run into some other unforseen issue
<blackboxsw> except TypeError rather
<rharper> yep
<smoser> powersj, i responded in that kvm merge
<smoser> i have to run now... we can just order thes a bit different, and som elittle things i mentioned in line.
<powersj> smoser: ok thanks
<powersj> really appreciate it
<blackboxsw> powersj: do you recall where #cloud-init irc logs are archived? I thought there was an IRC archive url somewhere which had historical #cloud-init logs
<blackboxsw> I wanted to reference them in the meetingology meeting minutes from last meeting
<powersj> blackboxsw: https://irclogs.ubuntu.com/2017/09/
<blackboxsw> that'd be it
<blackboxsw> thanks
#cloud-init 2019-09-02
<tribaal> blackboxsw: there's a small issue for me when enabling -proposed
<tribaal> but I don't know if I'm holding it wrong
<tribaal> when enabling proposed in sources.list and upgrading to the SRU'd version in e.g. bionic, the list of available datasources in /etc/cloud/cloud-.cfg.d/90_dpkg.cfg is not updated
<tribaal> (I expected it to update)
<tribaal> so basically the list stays the same and the Exoscale datasource is not part of the available list
<tribaal> (and therefore, it fails)
<tribaal> running dpkg-reconfigure solves the problem, but I'm not sure how things are expected to behave there
<tribaal> I now think I'm holding it wrong, but it'd be nice to have a confirmation when y'all have time :)
#cloud-init 2019-09-03
<smoser> tribaal: on upgrade, that config file wont get re-written. on fresh install it will.
<smoser> i'm pretty sure thats thecase at least.
<smoser> so if you purged the package and then installed it, you should get the "fresh install" feel.
<smoser> which is what will happen for new image builds
<smoser> well... not a purge, but they actually *are* fresh installs
<rharper> smoser: tribaal: thanks for the info; I was thinking that;  generally we wouldn't want an upgrade to migrate existing users to a new datasource;  but users could opt-in via the dpkg reconfigure;
<smoser> i think what we'd really want to get to is no datasource_list int he packaging by default
<smoser> and cloud-init just do the right thing
<tribaal> yes, I guess trying / discovering datasources would make sense
<rharper> smoser: right;  can you think of a blocker here ?
<smoser> and then if the user *did* configure the list, then the would have effectively opted out of new datasources in ugprades which makes sense.
<rharper> smoser: ideally it's empty; unless a user (or program) wrote a "local" override
<smoser> rharper: i can't think of a blocker.
<tribaal> one think that could be an isuue is for cases were ordering matters - for example if we maintain cloudstack compat and the cloudstack datasource is first to report "found". but that's not a blocker.
<smoser> you just have to consider how upgrades work and such. and have the packaging do the right thing there.
<tribaal> or say clouds migrating away from EC2 compatibility (which I assume exists)
<smoser> tribaal: those points aren't reasons to drop datasource_list from the package i dont think.
<smoser> they're valid things that we have to consider (and we have had bugs where the same instance swithced datasources on reboot)
<tribaal> true
<rharper> mmm, ibmcloud
<smoser> but having "one more thing" (the packaging) holding that list is just a pita
<smoser> dry - don't repeat yourself
<smoser> cloud-init (thanks smoser) likes to have you repeat yourself ;)
<rharper> smoser: I think we could drop it; ds-identify already provides the "default" list if nothing is present
<rharper> would be worth experimenting with
<smoser> yeah. i agree.
<smoser> and event hen... i'd like to get rid of *that* list somehow.
<smoser> but at least that isnt end-user configurable
<rharper> hrm, yes;  and we still find them  anyhow rather than just accepting the names
<rharper> blackboxsw: did we have general sru testing steps/language somewhere?  or did we say we wanted to write that down to point folks at it ?
<blackboxsw> rharper: we don't but we said we wanted to create those docs.  I thought I added a trello card to todo soon, but I don't see it
<blackboxsw> adding one now
<rharper> ok
<blackboxsw> https://trello.com/c/96vCbWgJ/1129-document-sru-manual-upgrade-testing-steps-for-cloud-init-for-the-community
<rharper> thx
<rharper> blackboxsw: was the bug verification script card updated with the 8 bugs for this SRU ?
<blackboxsw> rharper: sorry, done https://trello.com/c/WzfgsM2l/9-write-verfication-scripts-in-ubuntu-sru-repository
<blackboxsw> might still need pruning
<blackboxsw> but just grabbed via git diff ubuntu/xenial..HEAD | log2dch --trello | grep pad.lv (for bug-related lines)
 * blackboxsw has an errand. back in ~20
<rharper> ok
<blackboxsw> back
<chillysurfer> i'm adding some code for a merge request to cloud-init, and i'm making the (abbreviated) call to cloudinit.log.getLogger().debug('my message here'), but in my testing that doesn't actually log to /var/log/cloud-init.log. am i doing something wrong? i see debug log messages in cloud-init.log so i think the level is fine
<blackboxsw> hrm rharper I'm seeing strange behavior  trying to launch softlayer vms. The default user in cloud.cfg is ubuntu, yet that user is not being created. no tracebacks, and I see that the platform is also providing vendordata to reset root's password via a #!/bin/bash\necho 'root:$6$rounds=5000$5d6<redacted>' | chpasswd -e"
<rharper> blackboxsw: eww
<rharper> blackboxsw: let's collect-logs and look there
<blackboxsw> this is OS-Code/Live
<rharper> also check previous softlayer sru results ?
<blackboxsw> rharper: yeah, will do on that
<rharper> chillysurfer: deploying a newly installed patch, unittesting ?  can you provide more details on how you're testing ?
<blackboxsw> chillysurfer: if you are actually talking about grabbing logs from unit tests, you'll need to set with_logs = True in the unit test
<blackboxsw> then you can check self.logs.getvalue() in the unit tests
<chillysurfer> rharper blackboxsw sorry i should've clarified. the code is written and i've generated a deb and testing it on a vm right now. not unit testing, actually running cloud-init through systemd
<chillysurfer> i don't even really see where we wire up logging to /var/log/cloud-init.log. i see the def_log_file but i don't see us addHandler on it
<rharper> chillysurfer: typically the module that logs will have something like:  from cloudinit import log as logging;  LOG = logging.getLogger(__name__)  ;
<rharper> chillysurfer: the connection happens via /etc/cloud/cloud.cfg.d/05_logging.cfg
<blackboxsw> chillysurfer: wiring logging comes config from /etc/cloud/cloud.cfg.d/05_logging.cfg
<chillysurfer> rharper: yep that's exactly what i did (except i didn't pass in __name__)
<blackboxsw> I lose :)
<chillysurfer> rharper: ah nice :)
<chillysurfer> in that case i should be logging
<chillysurfer> really strange i'm not
<chillysurfer> no need to flush or anything right?
<rharper> no
<rharper> so either the path isn't being taken
<rharper> or something else isn't quite right;  do you have a diff of your changes you can share ?
<chillysurfer> rharper: i don't have a diff at the moment. here's all i'm doing:
<chillysurfer> from cloudinit import log as logging; _LOG = logging.getLogger(); _LOG.debug('hello world')
<rharper> how is this module called ?
<chillysurfer> rharper: i wired it up from cloudinit.cmd.main
<rharper> cloud-init runs through cloudinit/cmd/main.py which will run through cloudinit/stages.py:Init() object which runs a sequence of "stages";
<blackboxsw> rharper: looks like softlayer leaves around the /var/lib/cloud/seed/nocloud-net/user-data  which contains user: root definition, which overrides typical cloud-init behavior . That seed file is left over from earlier networklayer boot stages I think https://pastebin.ubuntu.com/p/SMWQvcZMhY/
<chillysurfer> rharper: yep that's what i did. i added an arg, and then imported and run the action
<rharper> chillysurfer: so depending on how early you are, logging may not be initialized;
<rharper> if you're calling LOG. before setUpBasicLogging() in main is called
<rharper> then you won't see that;  early main.py has it's own logging
<rharper> which then gets replayed after setUpBasicLogging is called;  but previous calls to LOG before setup won't show up
<chillysurfer> ahhhh wait yeah i see that we have `if args.debug: logging.setupBasiclLogging()`
<rharper> yep
<rharper> which will write to stderr
<rharper> without config
<rharper> but with the 05... it should show up in /var/log/cloud-init.log (but not in journalctl )
<chillysurfer> rharper: oh so you're saying it should show up in cloud-init.log?
<chillysurfer> even before setupBasicLogging?
<rharper> no
<chillysurfer> oh sorry got confused
<chillysurfer> so you say this is expected that i'm seeing now logged messages
<chillysurfer> *no
<chillysurfer> *no logged messages
<rharper> depending on where you are inserting your LOGs, it's possible.
<Petaris> Is there anything special I need to do when using write_files with content that includes "#" in it?
<chillysurfer> ah ok makes sense. i'll play around with this. thanks, rharper!
<rharper> main.py has it's own logging functions before it gets to parsing /etc/cloud/* for log setup;  which eventually get's configured to write to /var/log/cloud-init.log;
<blackboxsw> Petaris: you might want to base64 encode the content to avoid getting interpreted as yaml comments
<blackboxsw> Petaris: https://cloudinit.readthedocs.io/en/latest/topics/examples.html#writing-out-arbitrary-files
<blackboxsw> rharper: per softlayer, this root behavior is there regardless of the current SRU. I'll spend some time trying to debug and file a separate bug  if needed
<blackboxsw> it's happening on 19.1.1 on softlayer before the actual upgrade to 19.2.24
<rharper> blackboxsw: hrm  I forget if softlayer has multiple datasources ...
<rharper> that really smells wrong to me
<rharper> I thought they were configdrive, not a nocloud
<blackboxsw> rharper: agreed. I'll try the other 'flavors'
<rharper> that seems like a metadata bug
<blackboxsw> rharper: it does smell like metadata bug (or cloud-init not cleaning up earlier boot configs)
<blackboxsw> since SL has multiple boot 'configurations
<rharper> blackboxsw: right, there are like two stages
<rharper> blackboxsw: but the seed file seems wrong, Ds is IBMCloud right ?
<rharper> for softlayer ?
<rharper> https://bugs.launchpad.net/cloud-init/+bug/1673637
<ubot5> Launchpad bug 1673637 in cloud-init "cloud-init - Hosts in softlayer receiving warning" [High,Fix released]
<rharper> blackboxsw: looks like it has some backgound
<Petaris> blackboxsw, Thanks for the link.  I figured there would be need to either encode or escape them
<rharper> https://paste.ubuntu.com/p/TK2ht5Vd8T/
<rharper> Petaris: you don't need to encode for passing along # if you use the | marker in yaml , it will preserve the it as a string
<blackboxsw> thx for the extra option rharper
<Petaris> rharper, ok, cool
<Petaris> Thanks
<rharper> sure
<blackboxsw> rharper: per SL, yes datasource is DataSourceIBMCloud [OS-Code/Live /dev/xvdh]
<blackboxsw> will RTD on softlayer behavior again
 * blackboxsw needs to swap that back into memory
<faa> hello i'm FreeBSD tester and simple patch creator ;)
<rharper> hiya
<smoser> blackboxsw: what did you think was wrong ?
<smoser> with ibmcloud
<blackboxsw> smoser: the instances are coming up with root as the default user, instead of ubuntu (which is still configured default in /etc/cloud/cloud.cfg).
<blackboxsw> smoser: and there is a v.l.c/seed/nocloud-net left around on the booted instance that is overriding user: root etc which is why my default ubuntu user isn't being set *I think*
<smoser> blackboxsw: xenial or bionic
<smoser> ?
<blackboxsw> xenial: my expectation  was that I'd have an ubuntu user set up.
<blackboxsw> but no ubuntu user, it's only trying to create root. root@SRU-worked-ibmcloud:~# grep User /var/log/cloud-init.log
<blackboxsw> 2019-09-03 16:57:52,405 - __init__.py[INFO]: User root already exists, skipping.
<blackboxsw> 2019-09-03 18:56:11,903 - __init__.py[INFO]: User root already exists, skipping
 * blackboxsw tries bionic too
<smoser> unless something has changed, the cloud team builds those images in some odd way.
<blackboxsw> smoser: yeah I was double checking cpc
<smoser> ibmcloud datasource ends up never being used.
<smoser> i think if you poke around in /etc/cloud/ you'll see.
<blackboxsw> smoser: looks like bionic works
<smoser> and /etc/fstab and such
<smoser> it is really bad
<blackboxsw> just xenial falls over
<smoser> and we decided not to fix it there.
<smoser> or at least that it could happen later.
<blackboxsw> so bionic is good (and has no /v/l/c/seed/nocloud-net config) root@SRU-worked-ibmcloud:~# egrep -r 'Adding|User' /var/log/cloud-init.log
<blackboxsw> 2019-09-03 19:06:53,113 - __init__.py[DEBUG]: Adding user ubuntu
<smoser> blackboxsw: iirc there is some udev hook that mounts the config disk to /var/lib/cloud/seed/nocloud
<blackboxsw> ahh checking hooks
<blackboxsw> thanks
<smoser> i wrote all this down somewhere i thikn
<smoser> probalb y  a google doc
<blackboxsw> yeah /me was looking through transition google docs atm
<blackboxsw> thank you scott
<blackboxsw> and hackmd to cover our bases :)
<smoser> https://hackmd.io/HQ4Brp_RTNyFPfopxtDFFw
<smoser> is all i could find on hackmd
<smoser> which mostly just points to / mirrors the datasource doc
<smoser> (in DataSourceIBMCloud)
<blackboxsw> https://hackmd.io/HQ4Brp_RTNyFPfopxtDFFw :)
<blackboxsw> yep just found it
<smoser> whcih only discusses how cloud-init works, not how you could modify an image with a bunch of changes so that cloud-init would be tricked
<smoser> https://bugs.launchpad.net/cloud-init/+bug/1766401
<ubot5> Launchpad bug 1766401 in cloud-images "full config file wiped after apt-upgrade issued" [Undecided,New]
<smoser> https://git.launchpad.net/cloud-init/commit/cloud-init/sources?id=11172924a48a47
<blackboxsw> ahh smoser ok, yet it seems on xenial we don't have all the magic we need to continue using the old datasource, as IBMCloud is being detected still
<blackboxsw> ok I can file a bug on that and get it resolved
 * blackboxsw tries to remember if we had a followup to try to activate IBMCloud ds on xenial.
<smoser> hm..
<smoser>  https://git.launchpad.net/cloud-init/commit/cloud-init/sources?id=11172924a48a47a7231d19d9cefe628dfddda8bf
<smoser> looks broken
<smoser> Diffstat shows 0 files changed
<smoser> :-(
<blackboxsw> ok xenial I do see the following though datasource_list: [ IBMCloud ] in etc/cloud/cloud.cfg.d/99_networklayer_common.cfg
<smoser> well, that'd be a change
<blackboxsw> yeah because I don't think that was set originally
<blackboxsw> it may have been migrated back from bionic
<smoser> yeah.
<smoser> blackboxsw: so do you see two sets of logs ?
<smoser> cloud-init logs / runs
<smoser> can i ssh in?
<blackboxsw> smoser: ok, there was a separate salesforce case requesting this change on xenial it seems. the shift from configdrive -> IBMCloud was requested by IBM on xenial
<blackboxsw> and they desire root user there it seems.
<smoser> because inconsistency makes sure people stay employed
<smoser> so it is working as desired?
<smoser> s/desired/"desired"/
<blackboxsw> smoser: you can login if you like root@75.126.158.109
<rharper> *sigh*
<blackboxsw> "desired" for the moment, but I think we need to circle back w/ IBM/CPC on this
<Odd_Bloke> My understanding is that root should be the default for all instances, so the ubuntu user may be an accident.
<blackboxsw> Odd_Bloke: though I do wonder what the compelling need is to drop the ubuntu user altogether. I'm trying to get the background there on why that's a good thing to have the special case.
<Odd_Bloke> Well, if the ubuntu user isn't cloud-init's default then it's going to have surprising behaviour compared to other places.
<blackboxsw> though even in the Datasource itself IBM bakes in       {"cloud-init":"#!/bin/bash\necho 'root:$6$<snip>' | chpasswd -e"}
<Odd_Bloke> Whereas if it doesn't exist at all, then people won't expect it to behave in any particular way.
<blackboxsw> so we were already doing some funkiness for root user in IBM
<smoser> wlel, generally speaking this looks like it is functioning as designed.
<smoser> cpc could drop the hard coded datasource_list there. and i'd guess also the 'resize_rootfs' business
<blackboxsw> smoser: yeah, I'm trying to shift back to the original datasource_list: [ConfigDrive, NoCloud]  to check on Xenial creating ubuntu user.
 * blackboxsw needs to rebooit
<blackboxsw> thx
<smoser> so we would have to backport the ibmcloud packaging bits.
<smoser> need abe6bcdfacdf2f6745e3acf5c76b332380b9c493 and 4f7bdee8cc37e0f36df888fbd79f0e68d6429431 back to xenial
<blackboxsw> smoser: right, agreed, to enable IBM appropriately on new instances
<blackboxsw> yeah, so looking like this particular case is IBM-desired root-only login on xenial. bionic++ looks like it will have ubuntu & root useres.
<blackboxsw> users* even
<smoser> i think that probably that is the way it has always been on xenial
<smoser> and bionic changed to be more like ubuntu "standard"
<smoser> so from that perspectrive... yeah, you want to keep the old behavior
<rharper> blackboxsw: yay for no regression, and let's document that expection in the sru manual template , ?
<smoser> oh. i forgot. xenial is reporting only still for ds-identify
<blackboxsw> ok added https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1842510
<ubot5> Launchpad bug 1842510 in cloud-init (Ubuntu) "Xenial: Enable IBMCloud in default datasource_list template" [Undecided,Triaged]
<smoser> blackboxsw: i'd say that is 'fix released' in cloud-init (Ubuntu)
<smoser> not triaged
<blackboxsw> still probably need to add IBMCloud to datasource_list config template even though image magic specifies an overried
<blackboxsw> smoser: +1
<blackboxsw> added confirmed to the xenial task
<blackboxsw> ok /me gets back to softlayer SRU verification now :)
<blackboxsw> hrm, probably about time for us to fix our rtd content generation.
<blackboxsw> :/
<blackboxsw> it seems we are still out of date.
<blackboxsw> hrm github integrations seem successful
<blackboxsw> last success 5 days ago, during our last commit
<blackboxsw> yet cc_set_passwords documentation still seems out of date w/ tip
<blackboxsw> there, fixed RTD for the moment. now why did I have to manually loging to readthedocs.io and click the build button. that should have been triggered automatically on doc updates
<rharper> blackboxsw: yeah, it's not quite working, I have a script that we could cron
<rharper> I think the challenge is the github mirror, I'm not sure it picks up new branches/commits;  I know when we create new tags, those are missing as well
#cloud-init 2019-09-04
<mruffell> Hi cloud-init team, I opened https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1842562
<ubot5> Launchpad bug 1842562 in cloud-init (Ubuntu Eoan) "AWS: Add udev rule to set Instance Store device IO timeouts" [Medium,In progress]
<mruffell> You can ping me, or ddstreet if you have any questions. I hope cloud-init is the right place for it
<mruffell> Theres still some debate going on in the SF case, but I think cloud-init is the best place
<Mechanismus> ok idgi, I'm trying to use {{ v1.local-hostname }} within my cloud-config.txt
<Mechanismus> but when I do I get unicode rendering errors
<Odd_Bloke> Mechanismus: What version of cloud-init are you using?  Where do you see the errors?
<Mechanismus> version: /usr/bin/cloud-init 19.1-1-gbaa47854-0ubuntu1~18.04.1
<Mechanismus> errors when I run `cloud-init query --list-keys`
<Mechanismus> UnicodeDecodeError: 'utf-8' codec can't decode byte 0x8b in position 1: invalid start byte
<Odd_Bloke> Mechanismus: Oh, that's not good!  Could you file a bug at https://bugs.launchpad.net/cloud-init/+filebug and attach the tarball that `cloud-init collect-logs` generates, please?
<Mechanismus> eh... I'll have to desensitize the file
<Mechanismus> ...after I find it
<Mechanismus> it's being generated via terraform and supplied to an azure vm in user data
<Odd_Bloke> Find it?  `cloud-init collect-logs` gathers all the data we would need, so you shouldn't need to go find anything. :)
<Mechanismus> oh
<Mechanismus> I thought you meant the gzip that was provided to the vm at launch
<Odd_Bloke> :)
<Mechanismus> actually I have to redeploy the VM to get logs with specifically this situation
<Mechanismus> that'll take a minute
<Odd_Bloke> rharper: blackboxsw: We don't have a template for Oracle yet; which other template would you suggest basing it on?
<rharper> Odd_Bloke: the openstack one ?
<rharper> at least for now, it's mostly Openstack API right ?
<rharper> until we switch datasources ?
<rharper> it's been a while since I use the cli
<rharper> something else might fit better
<Odd_Bloke> I think I'll just launch instances using the web interface.  (I don't believe Oracle's user-facing API is OpenStack-compatible.)
<Odd_Bloke> So I guess I was really asking which one is most recently updated?
<Odd_Bloke> Looks like Openstack probably is the best one.
<blackboxsw> morning, yeah I
<blackboxsw> morning, yeah I'd agree on basing the manual verification script on openstack or azure since you'll probably be calling oracle's api instead of a launch-oracle.py script as we don't have that yet
<Mechanismus> Odd_Bloke: ok so it looks like Azure's part of the cloud config is running, but my custom bits fail to merge in and I still get the error with cloud-init query
<Mechanismus> Is there anything I can look at in the logs for something I might be doing wrong before I actually open a bug?
<Odd_Bloke> Mechanismus: It's hard to know, because I don't really understand the problem you're seeing.  Honestly, a bug would make this a lot easier to work through.  Is there a particular reason you don't want to file one?
<Mechanismus> Odd_Bloke: not really except that if it's a bug then the turnaround time to get this working is arbitrary and I'm trying to get this working today
<Mechanismus> I'm about to try an alternative approach in generating my cloud config in terraform though which would let me work around this for now
<Odd_Bloke> I mean, the same people who would help you in IRC are telling you to file a bug, so I'm not sure why you think the turnaround would be any different. ;)
<Odd_Bloke> blackboxsw: I'm actually not going to document exactly how to launch an Oracle instance; the UI makes it fairly easy to work out, and I don't want us to have out-of-date docs when they change things.  I _will_ document the one thing that caught me out (remembering to add your SSH key).
<Mechanismus> I mean that if it's a matter of I'm trying to do something unsupported then I can fix that.  If the fact that the UnicodeDecodeError shouldn't happen even when I'm being dumb constitutes a bug then I get that, but getting the _machine_ working is kind of my top priority right now
<blackboxsw> Odd_Bloke: thanks, makes sense
<blackboxsw> that's all I was really hoping, was if it was a complicated instance launch in any manner
<Odd_Bloke> Mechanismus: Well, we can always close out a bug Invalid if it turns out that you are doing something unsupported, but we would never expect to see a traceback.
<Odd_Bloke> So I expect there is a valid bug, even if it's "we should message better when we see bad input" or whatever.
<Odd_Bloke> And a bug gives us a place to attach logs etc. and have discussion to that won't get lost in IRC backlog.
<blackboxsw> we can reflect the bug lnk in channel here too to improve response time on resolution
<blackboxsw> UnicodeDecodeError rings a bell when handling some of the cloud metadata in the past. but we probably can/should address that in cloud-init proper if it's causing your general cloud-init query --all to fail.
<Mechanismus> Odd_Bloke: I fully agree with you and will be happy to look into it once I fix the issue I was working on when I ran into this
 * blackboxsw just realized I'm waay out of date on this discussion. I'll read the origin of this conversation to catch up
<blackboxsw> Mechanismus: couple things you can/should try    to test whether your given jinja query syntax is valid, on a booted vm you can run:    cloud-init query --format "{{ v1.local-hostname }}"  to see if it's an accessible template variable.
<blackboxsw> Mechanismus: specifically for our v1 standardized metadata,    I *think* you needed {{v1.local_hostname }} instead of {{ v1.local-hostname}}   as the hyphen gets interpreted as subtraction
<blackboxsw> on my system:      cloud-init query --format "{{v1.local-hostname}}"
<blackboxsw> WARNING: Ignoring jinja template for query commandline: Undefined jinja variable: "local-hostname". Jinja tried subtraction. Perhaps you meant "local_hostname"
<Mechanismus> blackboxsw: Good point, v1.local-hostname is in instance-data.json but doesn't work with the query.  However, v1.local_hostname works, though that's exactly what I have in cloud-config on this machine with the errors
<blackboxsw> also Mechanismus    inside the template, you can use python as a workaround... so if you could do something like {{ v1.local_hostname.decode('utf-8') }}
<blackboxsw> or {{ v1.keys() }} to see available subkeys under v1
<blackboxsw> Mechanismus: you could also check cloud-init query userdata  (which would provide your cloud-config yaml)  and you'd be able to process that content for your hostname: <myhost> or fqdn: declarations
<blackboxsw> but that's a bigger lift :/
<smoser> if i had to guess..
<smoser>  0dc3a77f41f4544e4cb5a41637af7693410d4cdf
<smoser> would fix Mechanismus
<smoser> although that should not occur with pyhon 3
<blackboxsw> hrm, though I thought he was on v. 19.1.1 and that commitish was in ~18.5
<smoser> oh. you're right. i just loked at the date
<smoser> and assumed the april commit didnt get into 19.1
<blackboxsw> yeah true initially.
<blackboxsw> I mean, yes I thought so too initially
<blackboxsw> heh interesting on Azure for my SRU test
<smoser> https://bugs.launchpad.net/cloud-init/+bug/1801364 is related, but not really.
<ubot5> Launchpad bug 1801364 in cloud-init "persisting OpenStack metadata fails" [Undecided,Confirmed]
<blackboxsw> ubuntu@my-e1:~$ sudo cloud-init query userdata
<blackboxsw> ../sethostname.yaml
<smoser> i'm assuming he is not python 2
<blackboxsw> I expected the metadata service to actually report the user-data, not the file name I used when launching the instance
<smoser> are you sure you have userdata ?
<smoser> and not just the name of a file ?
<blackboxsw> checking my azcli launch command
<smoser> to my knowledge 'az' takes only a custom-data blob in --custom-data
<smoser> not a reference to a file
<blackboxsw> ahh interesting, I specified a nonexistent file on --custom-data
<blackboxsw> if file does exist I think it gets populated properly.. .checking our latest SRU run
<Odd_Bloke> Yeah, my shell history strongly suggests you can pass a file to --custom-data.
<blackboxsw> smoser: https://github.com/cloud-init/ubuntu-sru/blob/master/manual/azure-sru-19.2.21.txt
<blackboxsw> yeah if the file does exist (sethostname.yaml in that example ^) it works and sets SRU-worked-<cloud>
<blackboxsw> but if file doesn't exist, azure just provides the string to the vm
<blackboxsw> and doesn't error (because it's 'flexible' in allowing blob or file)
<Odd_Bloke> gcloud has --metadata-from-file distinct from --metadata, which I prefer, I think.
<blackboxsw> +1 Odd_Bloke, yeah explicit intent/failures
<smoser> the other better path is @filename
<smoser> like curl does
<blackboxsw> true
 * blackboxsw tries that @<file> w/ azcli to see if it'll fail on file absent 
<blackboxsw> or even succeed on file presence
<blackboxsw> ok failure when providing --custom-data @<file>
<blackboxsw> Deployment failed. Correlation ID: 91ddbf3f-e296-4ea4-aab7-2189c314fe66. {
<blackboxsw>   "error": {
<blackboxsw>     "code": "PropertyChangeNotAllowed",
<blackboxsw>     "message": "Changing property 'customData' is not allowed.",
<blackboxsw>     "target": "customData"
<blackboxsw>   }
<blackboxsw> }
<blackboxsw> :)
<blackboxsw> well, we missed cloud-init status meeting Monday due to US holiday. We'll shift it to next Monday, and I'll send an email to the list
* blackboxsw changed the topic of #cloud-init to: Reviews: http://bit.ly/ci-reviews | Meeting minutes: https://goo.gl/mrHdaj | Next status meeting Sept 9 16:15 UTC | cloud-init v 19.2 (07/17) | https://bugs.launchpad.net/cloud-init/+filebug
 * Odd_Bloke is going to look at SRU verification for https://bugs.launchpad.net/cloud-init/+bug/1812857
<ubot5> Launchpad bug 1812857 in cloud-init "RuntimeError: duplicate mac found! both 'ens4' and 'bond0' have mac '9c:XX:XX:46:5d:91'" [Medium,Fix released]
<blackboxsw> Odd_Bloke: good deal, reviewing oracle run now. I just pushed https://github.com/cloud-init/ubuntu-sru/pull/44 with correct mtu v1 and v2 inputs (which fixed the diffs of v2 output so it is now limited to just dict ordering diffs)
<blackboxsw> Odd_Bloke: I can't remember w/ Oracle. Upon reboot upgraded cloud-init changed from detecting DataSourceOpenStackLocal to detecting DataSourceOpenStack (net). I realize it's the same datasource, but was a bit surprised that it switched to !Local detection
 * blackboxsw tries to see if we have that same transition for Ec2Local -> Ec2
<blackboxsw> it may be worth peeking at 'Crawl of metadata service" in cloud-init.log post the clean reboot to see why we cloud-init balks on OpenStackLocal post upgrade
<blackboxsw> maybe there was an ephemeral dhcp response issue there?
<Odd_Bloke> Looking.
<rharper> blackboxsw: on your  pull request with the netplan v2 bits;  shouldn't you pull the mtu values from the devices in the verification ?
<blackboxsw> rharper: btw, you were right that netplan raises a warning about missing definitions for the bond_interfaces
<rharper> yeah
<rharper> so for verification there, I'd read the MTU values on the bond and member interfaces pre-upgrade (v1) and post-upgrade (v2)
<rharper> it's fine to hard code the paths in the test since we're constructing the config (and interface names);
<blackboxsw> sure rharper agreed, I can grep -B 2 -i mtu     and we'll see the interfaces in most cases
<rharper> I'm grabbing, bug #1806701
<ubot5> bug 1806701 in cloud-init "cloud-init may hang OS boot process due to grep for the entire ISO file when it is attached" [Medium,Fix released] https://launchpad.net/bugs/1806701
<rharper> blackboxsw: you can read /sys/class/net/<iface>/mtu
<rharper> if you're not playing with ipv6 mtu
<blackboxsw> rharper: that would be if a created a vm with that config and applied. I didn't do that, I was just running net-convert in the test
<rharper> ah
<rharper> ok
<rharper> I saw NoCloud
<rharper> so was thinking you were doing a VM
<blackboxsw> right, only because I did check on an lxc with -proposed enabled
<blackboxsw> to make sure our -proposed bits had the logic
<blackboxsw> instead of just testing ti
<blackboxsw> tip
<rharper> pok
<rharper> that's fine actually since it's about the netconfig generated
<Odd_Bloke> OK, so there is a change in behaviour, and I think it's to do with network configuration; digging in more now.
<Odd_Bloke> (When I said there weren't new tracebacks at stand-up, I was mistaken.)
<Odd_Bloke> OK, I think the issue is coming from the classless static route support we now have for ephemeral DHCP.
<Odd_Bloke> And if the interface already has an address, we handle failing to set it gracefully, but we will still attempt to apply the routes to it.
<Odd_Bloke> And that fails, causing the DS to not be considered.
<Odd_Bloke> Good catch, Chad.
<Odd_Bloke> OK, I've got a fairly small patch which seems correct to me.  I'll propose it and we can discuss it.
<rharper> Odd_Bloke: ah, yes, we really should have a net_is_up check in the oracle/openstack ds
<rharper> in that, if networking is up, no need to bring up ephemeral DHCP
<rharper> that said, it can't hurt to be more defensive in Ephemeral DHCP as well
<Odd_Bloke> rharper: blackboxsw: https://code.launchpad.net/~daniel-thewatkins/cloud-init/+git/cloud-init/+merge/372289 <-- what do you think of that?
<blackboxsw> Odd_Bloke: ahh good deal. hrm. ok, so we caught a potential regression then. Sure, let's review what you've got when available and we'll get that in
<blackboxsw> reading now.
<rharper> Odd_Bloke: left a comment, not quite sure what to do;  to me, if we called EphemeralDHCP, then I really expect it to do a DHCP not skip the dhcp + setup if the interface already has an IP ... ;  should we raise and exception instead?  and for Oracle/OpenStack, (or any user of EphemeralDHCP) we should check net.is_up(self.fallback_interface) before using the EphemeralDHCP
<Odd_Bloke> Having to check net.is_up before using it leads to slightly awkward code like get_metadata_from_imds in DataSourceAzure.py; if net.is_up(): do_thing() else: with EphemeralDHCP: do_thing()
<Odd_Bloke> But I agree that there's no point getting the lease when we're going to throw it away immediately without using any of it.
<blackboxsw> rharper: Odd_Bloke, probably fair to think about things that way, though existing behavior is to bail on all other setup if the interfaces already has an IP, regardless of Odd_Bloke's fix
<blackboxsw> and Odd_Bloke agree it is awkward to have every call side is_net_up() or EphemeralDCHP. it'd be nice to have that failsafe logic within EphermeralDCHP contextmgr.. maybe we could have a EphemeralDHCP(force=True) if we really want to force a dhclient run on an interface even if it already has config
<Odd_Bloke> In fact, I think get_metadata_from_imds is wrong because of this; it will report errors differently depending on whether or not an ephemeral lease was needed.
<Odd_Bloke> (Not a big deal, but this is why avoiding having to spell out do_thing() twice is good.)
<blackboxsw> Odd_Bloke: do we have the traceback you saw on Oracle somewhere
<Odd_Bloke> You mean you can't see it in my terminal?
<blackboxsw> Odd_Bloke: no, I'm just sniffing your browser traffic to your banks
<rharper> lol
<Odd_Bloke> There we go: https://paste.ubuntu.com/p/jt8hNMJjKb/
<blackboxsw> thanks man
<Odd_Bloke> Oh, OK, you could just have sniffed that URL then.
<Odd_Bloke> But I'll make it easier for you.
<Odd_Bloke> Yeah, so I think my fix is probably too far down the stack.
 * blackboxsw wonders really if we should be checking the same failure condition we already are for ['ip', '-family', 'inet', 'addr', 'add', cidr, 'broadcast',
 * blackboxsw                  self.broadcast, 'dev', self.interface],
 * blackboxsw    The 'File exists' in stderr
<blackboxsw> as in we can try all setup commands and only queue cleanup for the commands which succeed
<Odd_Bloke> We should perhaps do that, but I don't think that's the root of the problem here.
<blackboxsw> and ignore the setup commands for routes or addrs that already exist
<Odd_Bloke> We should be able to know that we don't need to do DHCP at all here.
<blackboxsw> Odd_Bloke: agreed there too
<Odd_Bloke> FWIW, we already do have support for not-DHCP'ing in the context manager, if we pass in a connectivity_url.
<Odd_Bloke> So the context manager already doesn't _always_ DHCP.
<blackboxsw> hrm, as in we could pass connectivity_url=self.metadata_address to EphemeralDHCPv4 maybe?
<blackboxsw> hrm no that wouldn't work, doesn't get setuntil you _crawl_metadata
<Odd_Bloke> We could refactor that though, I think.  Regardless, connectivity_url is broken because it doesn't consider 403s to be an indication that you have connectivity.
<Odd_Bloke> (Which you obviously do, to get any sort of response!)
<rharper> do IMDS return 403s ?   would you want your connitivity url to do that ?
<Odd_Bloke> 403 indicates connectivity.
<Odd_Bloke> (Perhaps the argument is named incorrectly. :p)
<Odd_Bloke> And yes, on Oracle, `curl http://169.254.169.254` gives a 403.
<rharper> *sigh*
<rharper> =)
<Odd_Bloke> The same thing would happen on Google, too, at least; they expect a specific header in their requests.
<Odd_Bloke> And connectivity_url doesn't allow specifying anything other than the URL string, obvs.
<Odd_Bloke> Looks like nothing has ever used connectivity_url, so it wouldn't be super-surprising for there to be wrinkles with it, actually.
<Odd_Bloke> I guess, to step back for a minute, is it worth fixing the OpenStack DS for Oracle when we're about to switch over to their dedicated DS?
<blackboxsw> Odd_Bloke: I guess I'm still trying to understand why the network is up and configured already in local timeframe after a reboot
<rharper> blackboxsw: iscsi
<blackboxsw> ahh ahh
<blackboxsw> Odd_Bloke: rharper.  I *think* it probably makes sense for this to go with Odd_Bloke's branch to avoid the time cost of !detecting OpenstackLocal. As that issue could potentially affect other private openstack clouds using iscsci root or providing network config on the kernel cmdline wouldn't it?
<Odd_Bloke> Well, my branch is really too far down the stack.
<Odd_Bloke> There, if we've been given routes then we should be applying them regardless.
<Odd_Bloke> The change should be at least one frame further up, so that we don't even DHCP if we already have networking.
<rharper> first, is this a regression on Oracle, or has it been this way ?  ie, do we need to apply fix and respin the SRU ?
<Odd_Bloke> This is a regression
<rharper> related to the rfc3442 stuff ?
<Odd_Bloke> Yep.
<rharper> I guess I don't understand why if we never when down this path before
<Odd_Bloke> Because we try to apply routes that already exist and don't handle that erroring.
<rharper> but previously we didnt ?  are we really DHCP'ing again on top of iscsi root ?
<rharper> how does that even work ?
<rharper> where did the lease response come from ?
<Odd_Bloke> We ephemerally DHCP, and then in EphemeralIPv4Network._bringup_device the first util.subp call fails.  That failure is handled gracefully and, before, was the last thing that __enter__ did.
<Odd_Bloke> However, __enter__ now unconditionally continues on to apply the routes that the DHCP response included, and that's what fails.
<rharper> I see
<Odd_Bloke> And that failure means that DataSourceOpenStackLocal doesn't find metadata, so we fall through to DataSourceOpenStack later on.
<Odd_Bloke> (Which just uses the networking that the system already has, of course.)
<rharper> well, we set try dhcp to false for non-local
<rharper> in the datasource
<Odd_Bloke> Right.
<rharper> we really shouldn't DHCP if network is up
<Odd_Bloke> Yeah, agreed.
<rharper> so we have new errors in local ,but I don't think anything functional fails;
<blackboxsw> rharper: right, we still ultimately detect ini-network DataSourceOpenstack, just a time cost of failing @ init-local timeframe
<blackboxsw> and seeing more traces
<rharper> well, I wonder if non-iscsi we'd see a network-config failure
<rharper> in the iscsi case, we already use iscsi network-config instead of ds network-config
<rharper> if local failed to render network-config, then we write out fallback I think, then at net time, we can crawl, all is well;
<Odd_Bloke> blackboxsw: What's the time cost in your view, OOI?
<Odd_Bloke> AFAICT, the time taken by the network traffic dominates, and we have to pay that cost in either route.
<Odd_Bloke> But I may be missing another consequence.
<Odd_Bloke> (I didn't notice the two different data sources, so I'm clearly not on my top game today, lol)
<blackboxsw> Odd_Bloke: not big, certainly subsecond cost. lemme it looked like it as  +00.09700s
<Odd_Bloke> OK, cool, just making sure I wasn't missing something else.
<Odd_Bloke> https://bugs.launchpad.net/cloud-init/+bug/1842752 <-- the bug we just discussed me filing
<ubot5> Launchpad bug 1842752 in cloud-init "Additional traceback in logs when using DataSourceOpenStackLocal on Oracle" [Low,Triaged]
<blackboxsw> thanks Odd_Bloke
<Odd_Bloke> The traceback does appear on upgrade.
<rharper> what do we want to do about verifying https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1833192
<ubot5> Launchpad bug 1833192 in cloud-init (Ubuntu) "VMware: post custom script isn't run correctly" [Undecided,Fix released]
<Odd_Bloke> rharper: Could we just comment on the bug asking for help?
<Odd_Bloke> And maybe reach out to what VMWare contacts we do have?
<rharper> we can ping them directly
<rharper> I'll send an email
<blackboxsw> rharper: Odd_Bloke so I can validate that cloud-init behaves as expected, for bug #1840080 in the SRU
<ubot5> bug 1840080 in cloud-init (Ubuntu) "cloud-init cc_ubuntu_drivers does not set up /etc/default/linux-modules-nvidia" [High,Fix released] https://launchpad.net/bugs/1840080
<rharper> \o/
<blackboxsw> it emits proper debconf-set-selections, yet ubuntu-drivers-common doesn't actually install linux-modules-nvidia packages
<blackboxsw> so, not really sure what we should do on this front. I *think* that behavior of cloud-init is correct, but we have yet to see the plumbing from ubuntu-drivers-common
<powersj> blackboxsw, hit him up early tomorrow and ask; for now move on
<blackboxsw> yeah nothing else remains to move on to, waiting on CDO QA review, validation of ubuntu-drivers behavior, on aws GPU eoan instance, and I think Odd_Bloke is working the last remaining bug: #1812857
<ubot5> bug 1812857 in cloud-init "RuntimeError: duplicate mac found! both 'ens4' and 'bond0' have mac '9c:XX:XX:46:5d:91'" [Medium,Fix released] https://launchpad.net/bugs/1812857
<blackboxsw> powersj: I'll publish to copr el-testing. But, I think the rest of validation is grabbed/blocked or done.
<blackboxsw> so, we can touch base tomorrow to see if there is anything else of note that would require SRU-regen
<powersj> sounds good
#cloud-init 2019-09-05
<otubo> I'm gonna leave this question here and leave for lunch because I know it might take some time for someone to pick it up and answer: On this bug https://bugzilla.redhat.com/show_bug.cgi?id=1593010 the systemd-generator and the ds-identify read correctly that the second boot doesn't have any DataSource and, from the logs, they disable cloud-init. But still, on the second boot, the network configuration gets
<ubot5> bugzilla.redhat.com bug 1593010 in cloud-init "cloud-init network configuration does not persist reboot [RHEL 7.8]" [High,New]
<otubo> reset to dhcp.
<otubo> If anyone has any hint on this, I'll be glad to thank personally on cloud-init summit :-) And now I'm off to lunch, be back soon.
<otubo> perhaps rharper ^
<dunz0r> Is there some way I could get cloud-init to "ask" me for the hostname? Doing a template for a vmware-cluster.
<nvz> dunz0r: :)
<nvz> guess you beat me here
<nvz> dunz0r: thanks for mentioning this, I think this could be quite useful at some point I think I may hang out here and get familiarized with the project
<dunz0r> Yeah. This seems really useful to what I'm trying to do, especially since I don't have to reinvent the wheel, like I was planning on first.
<nvz> would've been my natural reaction
<nvz> this is a really nice looking project
<nvz> I just can't believe it doesnt appear they've thought of making it have interactivity
<nvz> Windows has for a long time had that thing where you do an OEM install and on the first run it asks you all those questions
<nvz> so you can have the system installed but still allow the user to set their timezone, username, update preferences, etc..
<dunz0r> I can see why there's no interactivity, it isn't supposed to. This is for largescale deployments. Serious stuff
<nvz> I'm fairly capable in python and this does interest me even though I dont have the kind of need for it right now like you seem to
<nvz> I had always wandered about being able to configure linux systems like that to be able to have initial config done by the user and it looks like I could easily build that on top of this
<nvz> like I just reinstalled debian on my cousin's laptop cause the m.2 ssd died and I had to install to his sata hdd he was using for /home.. and I'd have much rather sent it back to him so it booted up asking him for his user/password/fingerprints, etc..
<nvz> rather than having to set what I could and leave a README on his desktop explaining the rest
<nvz> and if I ever start doing more serious stuff with VMs this could really be useful there too
<dunz0r> nvz: My dream here at work is having ALL configuration in salt-stack and essentially never touch the machines, but that's waaay ahead in the future :)
<nvz> Ah, I'd never heard of salt-stack I thought you were referring to the salt minion thing in cloud-init
<nvz> I've heard of ansible, puppet, chef, but these things are news to me
<nvz> what amazes me about this cloud-init is like python itself, its well documented and I immediately felt comfortable with it just glancing over the site
<nvz> it all just makes sense
<nvz> these sorts of things can often be so cumbersome they're not really useful
<dunz0r> nvz: Salt-minion is part of saltstack :)
<dunz0r> Saltstack is the whole shebang
<nvz> hmm.. I should probably familiarize with these things they're bound to come of use at some point.. saltstack, ansible, puppet, chef, vagrant, cloud-init
<nvz> terraform
<nvz> hmm.. see now this damn saltstack has one of them fancy websites that tells you a whole lot of nothing
<Odd_Bloke> dunz0r: Are you asking for a tool that will help you generate cloud-config?  Or some sort of interactivity in the boot process?
<nvz> I glanced about 90 seconds at the cloud-init site and I could probably use it like I been doing it for months.. I glance at the saltstack page and I'm still not even sure wth it is
<nvz> Odd_Bloke: that was the general idea, they want to clone vms and be able to supply things on the first boot
<dunz0r> Odd_Bloke: Interactivity in the boot-process. The machines aren't on AWS or something like that, so no way to input a config-file
<dunz0r> nvz: Saltstacks frontpage is awful, yeah. https://docs.saltstack.com/en/latest/ is what you want :)
<Odd_Bloke> dunz0r: Where are these machines?
<dunz0r> Odd_Bloke: In a VMWare cluster.
<nvz> dunz0r: they make it sound like something commercial.. is it something you have to buy?
<Odd_Bloke> Interactivity during boot isn't something that would be generally useful (because most launches that involve cloud-init generally aren't accessible to the user at all until SSH is up).
<dunz0r> nvz: No, but they have an "enterprise" version. But I've never felt limited by the foss-version.
<dunz0r> Odd_Bloke: Well, I've got console access.
<nvz> Odd_Bloke: that is a good point
<Odd_Bloke> Sure, some places you will have it, but that's not generally true.
<dunz0r> Odd_Bloke: Today we create VMs from a template, set hostname/ip/regenerate ssh-host-keys/etc via the console, and that's a hassle
<dunz0r> Odd_Bloke: Well, not generally no. But in my particular use case it is
<nvz> Odd_Bloke: however I don't know of anything that is like this that could offer that OEM installed OS kinda feel and this seems to be ready to build that kinda thing on top of
<dunz0r> I think I'll write something that gets input from the user during boot and then uses cloud-init to do the actual setup.
<dunz0r> "user" generally being me or my colleagues
<nvz> Odd_Bloke: my idea, and mind you I just heard about this project, and glanced breifly at the site.. but is it possible to just ship a cloud-config, then have the bit that allows you to run commands at boot hook something to basically interactively make vendor data?
<Odd_Bloke> You could also look at generating a config drive from the input, and attaching that to the instances.
<nvz> on the first boot that is
<Odd_Bloke> I think the tricky part would be getting input from the console; cloud-init just runs as a daemon and outputs to the console via syslog.
<dunz0r> Odd_Bloke: My plan is to write a bash script that interactively asks for hostname and IP, and then generate a cloud.cfg from that info and a base template
<dunz0r> and THEN use cloud-init via the script to "setup" the machine
<nvz> they have things that you can use to have an auto-login getty and such
<nvz> you could have the base config set that up then get input and supply that input as vendor data overriding any config as supplied by the user
<Odd_Bloke> So vendor-data doesn't override user-data, intentionally; the user should always be in control of their instances, regardless of what their vendor wants the configuration to be.
<Odd_Bloke> dunz0r: You may want to consider having your script generate a config drive: https://askubuntu.com/a/867958
<Odd_Bloke> Then you can attach that to the VM as you launch it, and cloud-init should find the configuration from it without intervention during boot.
<nvz> I didn't even read about user data.. when I glanced it over I saw the main cloud-config then I seen the bit about vendor data that it says overrides cloud-config
<Odd_Bloke> So cloud-config is really a format; it's YAML with a "#cloud-config" header so cloud-init knows that it's intended to be treated as cloud-config.
<Odd_Bloke> Both user-data and vendor-data can specify cloud-config.
<nvz> yeah I noticed that much.. and I'm a fan of yaml.. when I first heard of it I avoided even looking at it because I thought it was another damn markup language.. years later when I finally looked it over I felt stupid :P
<nvz> turns out its not Yet Another Markup Language, its YAML Ain't Markup Language
<dunz0r> Wait what:O
<Odd_Bloke> dunz0r: Actually, looking at https://git.launchpad.net/cloud-init/tree/doc/sources/ovf might give you a better way of generating the ISO containing user-data.
<Odd_Bloke> (I haven't played with VMWare much, so I don't know exactly how to do this, I'm afraid.)
<dunz0r> Odd_Bloke: Generating an OVF would be a lot more work than what I have in mind, but I appreciate the input :)
<Odd_Bloke> OK, I'll be interested to see what you come up with! :)
<smoser> i dont' know how the answer at https://askubuntu.com/questions/867946/cloud-init-and-ova/867958#867958 would work
<smoser> admittedly i dont understand lots of things about vmware.  but that does not look like it'd work.
<smoser> i would expect, though to be able to launch a vm on vmware that had an attached cdrom with a NoCloud datasource on it.
<smoser> you can build such a datasource easily with cloud-localds
<smoser> http://atom-lab-3.insieme.local:5880/pijaserami
<smoser> err... sorry
<smoser> http://paste.ubuntu.com/p/K9CcHyTd2V/
<smoser> strike two
<smoser> http://paste.ubuntu.com/p/3GyHXxB2CW/
<smoser> there.
<smoser> stupid finger memory for internal hastebin
<otubo> if systemd-generator and/or ds-identify disabled cloud-init, it means totally disable or it still runs some things? I'm setting a network configuration with cloud-init, but when I reboot (both scripts identify that there's no datasource any more) and state as disabled
<otubo> but the network configuration is reset to dhcp instead of the initial configuration which was static
<Odd_Bloke> rharper: blackboxsw: I'm looking at validating a network configuration bug (https://bugs.launchpad.net/cloud-init/+bug/1812857) and I'd really appreciate some guidance as to how best to synthesise a networking environment for testing.
<ubot5> Launchpad bug 1812857 in cloud-init "RuntimeError: duplicate mac found! both 'ens4' and 'bond0' have mac '9c:XX:XX:46:5d:91'" [Medium,Fix released]
<Odd_Bloke> otubo: I would expect that they wouldn't run at all, but /var/log/cloud-init.log would tell you the truth of that.
<otubo> Odd_Bloke: I can see the pretty network configuration box with ascii art on /var/log/messages, setting everything back to dhcp
<otubo> Odd_Bloke: and I can also see the logs in /run/cloud/ saying no datasource was found the cloud-init will be disabled
<otubo> I'm a bit puzzled.
<otubo> Odd_Bloke: I can also see this weird message on the logs, but I'm not sure if this is *causeing* the issue or if it is a *consequence* of the issue, or even not related:
<otubo> https://pastebin.com/3NFJkwcK
<smoser> otubo: if you have the generator enabled correctly
<smoser> then cloud-init will not run *at all* if there is no datasource (or it is disabled)
<smoser> otubo: cat /run/cloud-init/ds-identify.log
<smoser> and /run/cloud-init/cloud-init-generator.log
<otubo> smoser: both of them report as disabled, but I'm gonna paste here, sometimes I'm just missing something.
<smoser> otubo: i suspect you have the services enabled.
<smoser> the other services.
<otubo> smoser: https://pastebin.com/LtdzQG1D
<smoser> is suspect you have your units (cloud-init.service, cloud-init-local.service, cloud-final.service, cloud-config.service) enabled.
<smoser> i suspect they are 'WantedBy=multi-user.target'
<smoser> when they should be WantedBy=cloud-init.target
<otubo> let me check that
<smoser> the generator only handles enabling or disabling that target
<otubo> smoser: bulls eye
<otubo> https://pastebin.com/9PwbF6es
<smoser> otubo: as upstream we'd love to have the generator enabled in rhel packaging
<otubo> smoser: I'll send a patch soon, once I confirm this is the root cause :-)
<otubo> smoser: thanks a lot for the help!
<rharper> Odd_Bloke: yeah, I think launching an lxc with a network-config that has bond0 over eth0, should show that .
<Odd_Bloke> rharper: Yeah, I got that working eventually but NoCloud doesn't seem to trigger the error.
<Odd_Bloke> I can reproduce the error if I poke the appropriate function in a Python shell, but that seems like cheating. :p
<rharper> hrm,  it's somewhat related to the speed at which bond0 picksup the mac of the member
<rharper> IIRC
 * rharper re-reads the bug
<rharper> Odd_Bloke: alternatively, you could boot with the bond0 + eth0 setup; cloud-init clean;  cloud-init init --local
<rharper> that should trigger cloud-init seeing bond0 and eth0 with same mac
<rharper> that way you don't have to rely on boot timing
<Odd_Bloke> Oh, it's because the error is in openstack's convert_net_json.
<Odd_Bloke> Well, it's further down, but that's where the traceback comes from.
<rharper> yeah, they had an ironic deployment
<Odd_Bloke> And NoCloud just passes my network config through verbatim, rather than having to convert it from OpenStack's format.
<rharper> yes, I guess it's a matter of having get_interfaces() list called
<Odd_Bloke> I (think I) reproduced in a KVM, but then couldn't get into it (presumably because cloud-init failed before setting my password or SSH keys?).
<rharper> so either fallback networking, or some other network_config path which triggers that;  and I still think best to clean and then run cloud-init init --local
<rharper> you can backdoor the image
<rharper> with root passwd first
<Odd_Bloke> Right, yeah.  Can you remind me how to do that?
<rharper> yeah, I use  sudo mount-image-callback --system-mounts bionic-server-cloudimg-amd64.img -- chroot _MOUNTPOINT_ /bin/bash
<rharper> then passwd
<Odd_Bloke> Thanks!
<Odd_Bloke> rharper: Oh, right, but this is still going to boot with NoCloud.  Do we have a good way of mimicking ConfigDrive locally?
<smoser> Odd_Bloke: easier than that is
<smoser>  https://gist.github.com/smoser/8c65b8771d5ab1d99c44c285323dfff6/
<smoser> well, only slightly easier. but it makes sure that you can get in.
<smoser> if you just ran 'passwd' and cloud-init got borked, you'd have no ssh host keys
<smoser> but wrt config drive.. you can just craft one. easiest way to do it would probably be to just mount an existing and then change things you want.  i think we possibly had a tool to make them at one point. but not sure where.
<Odd_Bloke> Yeah, I do have console access so password is sufficient for this particular case, thankfully.
<Odd_Bloke> Cool, I'll go find an example one for me to poke at.
<Odd_Bloke> Thanks for the advice!
<Odd_Bloke> OK, so I have a configdrive ISO now; how do I need to invoke kvm/QEMU to have it found properly?
<Odd_Bloke> Oh, my ConfigDrive is invalid.
<Odd_Bloke> That sounds like a problem for post-lunch Dan to deal with.
<smoser> Odd_Bloke: use xkvm. and use '--disk=foo.img'
<Odd_Bloke> smoser: Do you have a sample config drive I could take and modify?  This tool I found is actually creating a NoCloud source despite having "config_drive" in its name.
<smoser> that is odd in deed.
<smoser> Odd_Bloke: what i'd do is launch a serverStack instance with '--config-drive=1' on the openstack cli
<smoser> and then dd to get the disk.
<smoser> there are probably some examples attached to bugs though
<smoser> Odd_Bloke: https://bugs.launchpad.net/cloud-init/+bug/1671927
<ubot5> Launchpad bug 1671927 in cloud-init "init local crash - unknown subnet type 'loopback'" [Medium,Fix released]
<smoser> attachment 'sr0.gz' there is at least a start.
<smoser> sorry, 'config-drive' is the name of the attachment
<Odd_Bloke> Thank you!
<Odd_Bloke> Oh right, except now I need to somehow write OpenStack network config language to reproduce this.
<Odd_Bloke> rharper: You thought we might be able to reproduce this (https://bugs.launchpad.net/cloud-init/+bug/1812857) in a booted instance at stand-up.  Did our conversation change that, when we realised it was ConfigDrive-specific?
<ubot5> Launchpad bug 1812857 in cloud-init "RuntimeError: duplicate mac found! both 'ens4' and 'bond0' have mac '9c:XX:XX:46:5d:91'" [Medium,Fix released]
<Odd_Bloke> Because I really don't want to have to work out how to construct correct OpenStack network_data.json by hand.
<rharper> it's not config drive specific; it can happen on any path in cloud-init which requires us to use net.get_interfaces()
<rharper> I don't think we need to, really; I think just bringing up bond0/eth0, and then python3 -c 'from cloudinit import net;  print(net.get_interfaces())'  and ensure that bond0 isn't in the list
<Odd_Bloke> Are we happy for me to reproduce it in a Python shell then?
<rharper> I'm fine with that;
<Odd_Bloke> OK, cool, I'm good with that.
<rharper> I think it reasonable to show the net config, verify that eth0 and bond0 have the same mac, that cloudinit.net.is_bond() returns true on bond0 , false on eth0; and then that bond0 doesn't show up in get_interfaces();
<rharper> before/after upgrade should show that we do get bond0 in the list and it raises duplicate exception, post-upgrade we don't get the exception and bond0 isn't in the list;
<Odd_Bloke> OK, cool, I'll continue with my lxd container setup I started on before thinking I might be able to reproduce the exact bug.
<Odd_Bloke> Thanks!
<smoser> Odd_Bloke: what you need to do is write a renderer for Openstack networking ocnfig in cloud-init
<smoser> and then you could just use net-convert
<Odd_Bloke> Trivial!
<rharper> we already have that
<rharper> smoser: Odd_Bloke:  net-convert  has a json input
<rharper> which is effectively the openstack format
<rharper> --kind json
<blackboxsw> ok copr build for CentOS7 is updated for the cloud-init version which is currently undergoing SRU validation in ubuntu: 19.2.~385 https://copr.fedorainfracloud.org/coprs/g/cloud-init/el-testing/
<smoser> thats input
<smoser> he needed output
<rharper> ?
<rharper> ah, right
<rharper> I have input (aka output) that includes bonds and macs like Ironic
<rharper> but even that's more complicated than just verifying that net.get_interfaces() skips bonds
<Odd_Bloke> Yep, I'll proceed with this.
<blackboxsw> rharper: are we waiting on bionic and disco for https://github.com/cloud-init/ubuntu-sru/pull/45/files?
<rharper> ugh, right
<rharper> lemme do that
<rharper> blackboxsw: thanks
<blackboxsw> no worries
<blackboxsw> pending cloud-init SRU 19.2.24 publish isn't until Tuesday next week anyway. so still time :)
<rharper> but I had forgotten, so thanks
<Odd_Bloke> OK, I have a test case, but it doesn't work on xenial because the bond never gets created because: /etc/network/if-pre-up.d/ifenslave: 37: /etc/network/if-pre-up.d/ifenslave: cannot create /sys/class/net/bonding_masters: Permission denied
<Odd_Bloke> Ugh, pretty sure this is a problem because I'm in a container; the owner is different outside of a container.
<rharper> modprobe bonding IIRC
<rharper> on the host
<rharper> IIRC
<rharper> Odd_Bloke: ^
<rharper> container bonding is PITA
<Odd_Bloke> Nah, it doesn't work even in a privileged container with the module loaded; "read-only filesystem".
<Odd_Bloke> I think I'm going to need to do the xenial test in a VM.
<Odd_Bloke> Which is fine, because we've established that using NoCloud is fine.
<rharper> https://github.com/cloud-init/ubuntu-sru/pull/45
<rharper> blackboxsw: updated
#cloud-init 2019-09-06
<Goneri> could you take a look at https://code.launchpad.net/~goneri/cloud-init/+git/cloud-init/+merge/368507 and https://code.launchpad.net/~goneri/cloud-init/+git/cloud-init/+merge/365641
<faa> i'm test this FreeBSD 12 vm all work perfect
<faa> if require repo, for install pkg ping me
<Goneri> I've some prebuilt images here: http://bsd-cloud-image.org/
<Goneri> this should simplify the testing
<blackboxsw> Odd_Bloke: powersj rharper: https://code.launchpad.net/~chad.smith/cloud-init/+git/cloud-init/+merge/372432 WDYT?
#cloud-init 2020-08-31
<Raito_Bezarius> Hello, I'm trying to understand if cloud-init supports update_etc_hosts for NixOS
<Raito_Bezarius> https://github.com/canonical/cloud-init/pull/561 I have made this
<Odd_Bloke> Hello everyone, I'm back from my two weeks of vacation. o/
<Odd_Bloke> I'm catching up on scrollback and as we're introducing more and more development tools into cloud-init, I wonder if we should consider splitting the Ubuntu package into two: one for the actual "init" functionality, and one that people can install on dev machines (to get schema validation, MIME archive creation, etc.) without cloud-init (potentially) running on boot.
<Odd_Bloke> (Potentially this could be implemented by just moving the systemd units to a separate package; we probably don't want to try splitting the source tree in packaging.)
<smoser> i have 2 thoughts.
<smoser> a.) with the generator, if you don't want cloud-init to run, touch /etc/cloud/cloud-init.disabled
<smoser> b.) right the only tool i think that is in cloud-init that isn't really to be run on a system that *does* use cloud-init  during boot is 'make-mime'
<rharper> maybe net-convert
<smoser> maybe... that is a dev tool though.
<smoser> the obviousl thing that i'd think to add would be the `cloud-localds` functionality from cloud-utils
<rharper> yeah, the schema stuff is in the middle ground as well
<smoser> but doing *that* would mean dependencies
<smoser> which i wouldn't want a package to pick up (mkiso)
<rharper> smoser: right
<smoser> i can see the value of schema on non-running system for sure.
<Odd_Bloke> The `analyze` subcommands can take an input file, so they could also be used on a non-running system.
<smoser> but the
<smoser> s/but the//
<Odd_Bloke> I think we can categorise our commands as: functional (init etc.), on-instance utilities (collect-logs, query, clean, etc.), power-user development (at least schema, make-mime, perhaps analyse and others; localds would fit here, I think), developer (net-convert, render? (I don't know what render does))
<Odd_Bloke> As I said, I don't think splitting up our code tree in packaging is worthwhile, but we could feasibly have (names not intended as suggestions for actual package names): cloud-init-library, cloud-init-systemd-services, and then cloud-init-power-users-install-me which would depend on cloud-init-library and packages which are only required for {power-user,developer} subcommands.
<Odd_Bloke> Which would give us a way of installing mkiso on systems where people are opting into having the full functionality available, without bloating the dependency set of the packages that get installed on every system (-library and -systemd-services).
<rharper> Odd_Bloke: render lets users expand/test jinja templated files
<smoser> Odd_Bloke:the issue is that if you dn't split up the code tree, then cloud-init-library has to have the mkiso dependency
<smoser> or its just broken, waiting for someone to try to use the library and fail
<Odd_Bloke> I think it would be reasonable to exit with "`cloud-init localds` requires `mkisofs` to be installed" or similar; it's an interactive command so people can respond to that.
<Odd_Bloke> But I agree that it's not ideal.
<ananke> hmm, this makes no sense, but so far all the symptoms agree: 'cloud-init status --wait' claims that 'status: done', but tail'ing cloud-init-output.log still shows final modules still running (package installs/updates specifically). was there ever a bug related to this?
<blackboxsw> ananke: https://bugs.launchpad.net/cloud-init/+bug/1890528 ?
<ubot5> Ubuntu bug 1890528 in cloud-init "cloud-init status --wait returns before cloud-final has finished executing" [High,Triaged]
<ananke> thank you, I'll check. this may be it.
<blackboxsw> ananke: was cloud-init stats --long an error condition too?
<ananke> This is on kali, absed on debian: cloud-init/now 20.1-2 all [installed,upgradable to: 20.2-2]
<blackboxsw> that would exit early
<ananke> blackboxsw: nope, no errors
<ananke> I've been trying to figure out for the past hour why our packer configuration is failing on kali 2020.2, while it worked on kali 2020.1, and I was seeing some odd race conditions in the output logs
<ananke> we use cloud-init status --wait before proceeding to next steps, and that seemed to first exit when there were problems with bootcmd, but even after removing everything and no errors, I still see it claiming it's done, while modules are still running
<blackboxsw> ananke: after "removing everything" do you mean running "sudo cloud-init clean"?
<blackboxsw> if a "clean" is not performed, some artifacts will exist on the system that would trick cloud-init status into thinking it is done
<ananke> blackboxsw: no, I mean after removing anything in our packer config that pertains to early stages/etc
<ananke> we pass a cloud-init config via user-data, and we then tell packer to wait until cloud-init status --wait exits
<blackboxsw> ananke: so, cloud-init status --wait looks at /run/cloud-init/status.json
<ananke> k, I'll redo the process and see what's in that file
<blackboxsw> If each  key(stage) if it sees start and finished times for each stage, then it assumes that cloud-init is complete
<blackboxsw> yeah check that and /run/cloud-init/result.json contents
<ananke> here's a sample output, after I ssh to the system that's being provisioned: https://dpaste.com/3DT6BTAEW
<ananke> so modules-final is not done, yet claims it is?
<Odd_Bloke> ananke: Hmm, what is it that's performing those downloads?
<Odd_Bloke> Is that just cloud-config, or have you passed in a script or similar?
<ananke> Odd_Bloke: just cloud-config
<Odd_Bloke> ananke: Could we see a full cloud-init.log?
<ananke> sure, do hold
<Odd_Bloke> https://www.youtube.com/watch?v=6g4dkBF5anU
<ananke> Odd_Bloke: : http://sprunge.us/KExsDJ
<ananke> so this part is still not finished: 2020-08-31 18:34:20,861 - util.py[DEBUG]: apt-install [apt-get --option=Dpkg::Options::=--force-confold --option=Dpkg::options::=--force-unsafe-io --assume-yes --quiet install fio time xrdp xorgxrdp aptitude elinks gedit htop leafpad nano nmap vim] took 131.844 seconds
<ananke> which is populated via the 'packages:' directive
<Odd_Bloke> ananke: It looks like "cloud-init mode 'modules' took" appears 4 times in the log; I believe we would only expect to see it twice: one for each of `--mode config` and `--mode final`.
<ananke> ohh, damn, I think you just nailed the issue. in packer as a workaround we had to kick off 'cloud-init --mode=config' and 'cloud-init --mode=final' manually, and I never took that out
<Odd_Bloke> That'd do it!
<ananke> crap, I'm so sorry
<blackboxsw> nice Odd_Bloke
<ananke> Here's the offending code:
<ananke>                 "cloud-init modules --mode=config; echo cloud-init module config error code is $?",
<ananke>                 "cloud-init modules --mode=final; echo cloud-init module final error code is $?",
<ananke>                 "/usr/bin/cloud-init status --wait; echo cloud-init status error code is $?",
<ananke> It's interesting to see what the consequence is though
<blackboxsw> +1 generally cloud-init doesn't prescribe machines invoking each stage directly as part of the boot process because of cloud-init uses systemd service/unit ordering to ensure the start of each stage after the appropriate stage in system boot.
<blackboxsw> ...and if cloud-init every added boot stages images which only called into specific cloud-init boot stages might miss the introduction of a new cloud-init boot or configuration  stage  ( which *may* actually happen this year per https://bugs.launchpad.net/cloud-init/+bug/1892851)
<ubot5> Ubuntu bug 1892851 in cloud-init "Staged boot, to fix integration of systemd generators" [Undecided,Confirmed]
<blackboxsw> but I get that it is a good option while developing a new system to call into those stages directly
<ananke> yeah, we had to put those workarounds due to broken Kali AMI
<blackboxsw> roger. if you find there is something that makes sense to upstream, I'm sure we'd love to help get that support in
<blackboxsw> into master
<ananke> I can't imagine this would be a common issue, but I wonder if putting some locking/semaphore checking makes sense.
<ananke> funny enough, I did remove these commands from packer earlier this morning, but then put them back because things were still breaking. so while I fixed the other things (I had to enable/start cloud-init-local.service and cloud-config.service), I never bothered to go back to this section
<blackboxsw> ananke: each config module has it's own semaphore based on whether the module should be run per-boot, per-once, per-instance or per-always
<blackboxsw> so as a whole, locking the entire boot stage doesn't quite work because some components within that stage want to be run always
<ananke> on an unrelated (or semi-related) note, I need to figure out if there's a way to tail cloud-init's log _while_ waiting for cloud-init status --wait to finish
<blackboxsw> tail -f /var/log/cloud-init.log?
<blackboxsw> :) from a fok
<blackboxsw> frok
<blackboxsw> fork even
<blackboxsw> :)
<ananke> blackboxsw: that would work, but I'd have to kill it after cloud-init status --wait exits
<ananke> otherwise that entire thing would hang and packer would never finish that stage
<ananke> On error conditions I can dump the logs to stdout, which for us means packer sends them to gitlab CICD console and we can inspect them that way. However, it would be nice to view them real time, and see what's happening with the system as we wait ~20-30 mins for various cloud-init stages to finish
<blackboxsw> ugh
#cloud-init 2020-09-01
<viks____> hi,  how to upgrade the cloud-init in the image when creating a fresh instance.. i want this to happen before cloud-init user data being run..
<meena> viks____: by building a fresh image with an upgraded cloud-init
<viks____> meena: thanks... but is there any other way like say if a user uploads an image to my image repo, i want to make sure that a required version of cloud-init say 19.3 is present when an instance is created out of it
<meena> you could possibly add scripts to vendor-data far far either check the version and error out, or very hackishly try to update cloud-init. however, vendor-data can be overwritten by user-dataâ¦ so, if your horrible hackishly scripts don't work, your users will circumvent them
<viks____> meena: ok.. thnx
<Odd_Bloke> viks____: If you want cloud-init upgraded before cloud-init runs, then you can't use cloud-init to do it.  And if you don't have a way of modifying the image before it launches (either to upgrade cloud-init, or to add some pre-cloud-init systemd unit that attempts something similar on boot), then I don't think there is a good way of doing it.
<Odd_Bloke> viks____: What is it that drives the minimum requirement?
<viks____> Odd_Bloke: Ok.. thanks.. actually i was trying to inject root password via cloud-init for debian9 i.e. http://cdimage.debian.org/cdimage/openstack/current-9/debian-9-openstack-amd64.qcow2  for my local test openstack cluster. it seems the above image has old cloud-init and it seems that is the reason cloud-init is not able to set root password given via user-data.
<viks____> so in case if any user tries to upload the image from the above link and tries to create instance, root password injection will not work via cloud init. So i wanted to know if there is any standard way this can be upgraded to a give cloud init version
<viks____> i even tried to install manually by cloning cloud-init repo in the instance created from the above link(debian9), but installation is not successful. Also i do not find any pip packages or any prebuilt  package for debian 9
<Odd_Bloke> viks____: Hmm, that sounds like something that I would expect to work even on an older version of cloud-init.  What does your user-data look like?
<viks____> https://www.irccloud.com/pastebin/2k5X0RpZ/
<viks____> which works fine on debian10 based instance
<viks____> Also i see the discussion abt the version issue here: https://forum.proxmox.com/threads/change-password-cloud-init-does-not-work.46118/
<Odd_Bloke> viks____: Hmm, I _would_ expect that to work on an older version of cloud-init.  Could you pastebin /var/log/cloud-init.log from a failing instance (if you have some other way of gaining access)?
<riccardom> Ciao, I'm new to the technology, and trying to understand. I see that cloud-init is strongly bound to systemd
<riccardom> Is the implementation dependant on systemd?
<viks____> Odd_Bloke: here it is: http://paste.openstack.org/show/797330/.. i do not see any error in this
<viks____> i'm facing this only in debian9. most of other distributions and their versions it works fine
<Odd_Bloke> riccardom: cloud-init is involved in setting things up during the boot process (generally in four different stages: https://cloudinit.readthedocs.io/en/latest/topics/boot.html), so it has to be well-integrated with the init system.  However, it doesn't have to be systemd: we have upstart scripts in the upstream tree, and I believe Alpine uses OpenRC.
<Odd_Bloke> One caveat: the "Generator" stage in that link is systemd-only, as it relies on systemd's generator functionality (which allows us to enable/disable services at boot time, so cloud-init won't run when it isn't needed).
<Odd_Bloke> viks____: From that log, it looks like cc_set_passwords never runs.  Can you paste /etc/cloud/cloud.cfg, please?
<viks____> Odd_Bloke:  here it is -> http://paste.openstack.org/show/797331/
<Odd_Bloke> viks____: Hmm, it is in there.  Looking back at the log, it appears to be truncated, is that really the full file?
<viks____> yes
<viks____> wait.. it seems to be getting trucated..
<viks____> here is the remaining part -> http://paste.openstack.org/show/797334/
<Odd_Bloke> viks____: Hmm, looks like it has worked.  Can you confirm for me how you're testing that it hasn't worked?  (Does the password work locally but not via SSH, for example?)
<viks____> i try to login via console on openstack horizon dashboard which fails... not ssh... i also cross verified the encrypted password in userdata with the password in shadow file which are not same
<Odd_Bloke> viks____: What user are you trying to login as?
<Odd_Bloke> Because your cloud.cfg has things configured such that the default user will be `ubuntu` (so I would expect the password to be set on `ubuntu`, not on `root`).
<viks____> Odd_Bloke: Oh i see... let me try changing that in the image and create an instance.. will let you know..
<viks____> Odd_Bloke:  but we are setting it for root right as in userdata file... also even in debian10, i see debian as default user in cloud.cfg:
<viks____> https://www.irccloud.com/pastebin/AcL0ZSuT/
<viks____> but root password works there
<viks____> it seems cloud.cfg got changed when i tried to upgrade the version manually in instance... in original image it's indeed debian: http://paste.openstack.org/show/797342/
<viks____> also on the debian 9 instance:
<viks____> https://www.irccloud.com/pastebin/JSdKixBo/
<viks____> whereas on debian10 instance:
<viks____> https://www.irccloud.com/pastebin/GW6ivhw5/
<meena> Good grief
<apatt> Hello everyone :-)  Hoping someone can tell me if what I want to do is possible.
<apatt> I'm trying to create a linux image that works across multiple server vendors. I've got a base cloud-init setup working great that uses the NoCloud provider and pulls a config from a web server. That all works great.
<Odd_Bloke> viks____: Hmm, I'm not 100% sure we've seen a good test with Debian 9 if you'd tried to fix the instance yourself before capturing logs etc.; would you be able to spin up a clean one and recapture stuff?  (If it's easier, you can push the tarball that `cloud-init collect-logs` generates.)
<apatt> However, when I push my linux image to another server that has different network interface names that doesn't work so well since my netplan configuration is in the user-data file out on the network.
<apatt> So I was curious if its possible to have a local user-data file that gets the network up and then have it pull the user-data information from the network share to finish up customization
<apatt> I hate baking everything into the image since I have to respin the image just to change simple things
<Odd_Bloke> apatt: netplan supports matching interfaces; would using that allow you to share your network configuration across servers?
<Odd_Bloke> Or are the network configurations for each instance very different?
<apatt> it does, but if the netplan information is in the user-data located on the network.... so if the target server has different network interface names the network does not come up at boot so we can't reach the network to tell us what our network configuration should be ;-)
<Odd_Bloke> apatt: Are you using DHCP?
<apatt> YEs
<apatt> write_files:- path: /etc/netplan/50-cloud-init.yaml  content: |    network:     version: 2     ethernets:       id0:         match:           name: eno1*         dhcp4: trueruncmd:- netplan --debug apply
<apatt> well that didn't format so well
<Odd_Bloke> I got the gist. :)
<Odd_Bloke> (But in future multiline stuff would be better in a pastebin like https://paste.ubuntu.com/ :)
<Odd_Bloke> apatt: So I would expect that cloud-init should be able to perform DHCP and reach your NoCloud endpoint without you providing any network configuration, either in the image or via user-data.
<apatt> At least on Ubuntu it doesn't seem to work that way
<apatt> unless I'm just horribly ignorant of how netplan deals with new interface names
<Folamh> Hi I've come across an issue with an issue with cc_package_update_upgrade_install.py on arch distributions. It passes "upgrade" to arch.py which would create the command "pacman -Sy --quiet --noconfirm upgrade" which should actually be "pacman -Syu --quiet --noconfirm" or "pacman -Sy --quiet --noconfirm -u". What should I do to get this addressed?
<blackboxsw> Folamh: probably file a bug https://bugs.launchpad.net/cloud-init/+filebug with details
<Folamh> (y)
<blackboxsw> and new contributions via pushing a PR up to https://github.com/canonical/cloud-init/ also encouraged
<Odd_Bloke> apatt: Apologies, NoCloud doesn't actually behave in the way I was thinking of; it's datasource-specific.
<apatt> It's not the end of the world if that just isn't possible, it just means I put some basic network information into a local user-data seed and then do everything else with Ansible once the host is up and on the network.
<apatt> and give up on using a user-data config from a http share
<Odd_Bloke> apatt: How are you specifying where to seed from?
<apatt> Odd_Bloke specifying a NoCloud datasource cloud.cfg
<apatt> Odd_Bloke what I may end up doing is writing out a netplan config that brings up the local adapters by matching everything (en*) and then pulling in the new netplan information once it boots. That would elongate the boot however, since Linux is going to try and bring up all six ethernet adapters I have in my servers. Only two of them are plugged in
<apatt> so we pause quite a while.
<apatt> Not sure if that would get me into any timeout issues
<Odd_Bloke> apatt: Would you be able to gather logs from an instance which doesn't have local netplan configuration but does have your cloud.cfg?  I'd like to see what's going on.
<Odd_Bloke> (A pastebin of cloud-init.log would be a good starting point. :)
<apatt> Odd_Bloke I'm fairly confident that the issue is that my user-data contains this text: https://paste.ubuntu.com/p/xhVXVDbZPZ/
<apatt> but before running cloud-init the local machine only has this https://paste.ubuntu.com/p/Dxg6n9pqzH/
<smoser> apatt: write_files attempting to write that is not really going to work.
<smoser> by the time cloud-init writes files, networking is already up based on what it declared. and then... runcmd of 'netplan --debug apply', maybe that would do what you wanted.
<smoser> but, yuck.
<apatt> smoser I agree it's not optimal, but best I could come up with. All ears if you have a better alternative.
<smoser> apatt: what i think you want to do is provide network config in the nocloud seed (i suspect that is what you mean by nocloud data)
<apatt> correct
<smoser> https://asciinema.org/a/145772
<smoser> https://asciinema.org/a/145772
<apatt> smoser thanks, will take a look.
<smoser> i think it would work to #include a url from the user-data you provided.
<smoser> or maybe use seed-from
<smoser> but i'm not sure if that would work or not.
<smoser> if you just #include the userdata, then you're going to have to hard-code the instance-id
<smoser> and then its always going to be the same instance
<apatt> Since I'm using bare metal servers I'm not sure that is going to work for me since it requires using a disk image attached to the VM.
<apatt> After talking to you and Odd_Bloke I think I have an idea of how to make it work though
<Odd_Bloke> apatt: Let us know how you get on! :)
<Odd_Bloke> smoser: So as I'm working through these manual_cache_clean docs, my initial feeling is that exposing "trust" and "check" as values for a new configuration option would be a good step forward.  This would allow us to introduce other modes; the first that occurs to me is, say, "check_failsafe" which would behave as "check" does _unless_ we fail to determine the current instance ID, in which case it behaves
<Odd_Bloke> as "trust" does.  I think this would be a best effort solution to bug 1885527; if there's an IMDS outage then you can't launch new instances, but your existing instances aren't trampled (and when there isn't an IMDS outage, you can launch instances from captured images; "trust" would prohibit this).
<ubot5> bug 1885527 in cloud-init (Ubuntu) "cloud-init regenerating ssh-keys" [Undecided,Incomplete] https://launchpad.net/bugs/1885527
<Odd_Bloke> I don't think that's a short-term thing at all, I'm more curious as to what you think of it as an idea.
<Odd_Bloke> (s/you can't launch/you won't successfully launch/)
<smoser> Odd_Bloke:i'm not sure i understand.
<smoser> yeah, i dont think you ever really want what you're after.
<smoser> either
<smoser> a.) trust the cache completely (manual_cache_clean=true)
<smoser> b.) check it.
<smoser> doing
<smoser> c.) check it, but if that check failed, then use it.
<smoser> b.) was 'check it, and if it is good use it'
<smoser> i dont know. i think it generally does work correctly as it is.
<smoser> (if it in fact works the way i described it is supposed to)
<smoser> if you wanted to change something, then the easiest thing to change, and probably the least surprising to the end user (or at least the flurry of end-users that have come along recently) is to always trust the cache.
<smoser> and just throw away the "rebundle without clean" use case.
<smoser> and just document that if the user wants to take a snapshot, they have to run 'cloud-init clean'
