#cloud-init 2014-05-07
<harmw> hm, smoser on holiday?
<harlowja> possibly, he'll be at the openstack summit next week though (along with me)
<harlowja> so maybe he's just taking a brea
<harlowja> *break
#cloud-init 2015-05-05
<loth> Hey all, does "network-interfaces" work in RHEL variants or just debian?
<smoser> in what sense?
<smoser> cloud-init will read /etc/network/interfaces and write stuff to sysconfig style on rhel/suse
<smoser> but htere are race conditions.
<smoser> ie, you really have to have 'eth0' set up correctly
<smoser> i assume you're talking about openstack / config drive.
<Odd_Bloke> `mx: How are you installing pip?
<Odd_Bloke> smoser: Can you remind me: can data sources throw exceptions to mark themselves as inapplicable for an instance, or will that bring down cloud-init?
<harmw> man, Kolla is fun :)
<smoser> Odd_Bloke, return False.
<smoser> from .get_data
 * Odd_Bloke wonders if smoser has confused his IRC client for a Python interpreter.
<smoser> hm.. your irc client is not a python interpreter? how odd.
<Odd_Bloke>   File "smoser", line 1
<Odd_Bloke>     hm.. your irc client is not a python interpreter? how odd.
<Odd_Bloke>        ^
<Odd_Bloke> SyntaxError: invalid syntax
<kwadronaut> smoser: still using lice on ircii?
<kwadronaut> already rewritten in python3?
<smoser> del users[Odd_Bloke']
<smoser> doh
#cloud-init 2015-05-06
<Odd_Bloke> smoser: I can't remember where we said it would make sense to put the certificates that WALinuxAgentShim spits out on disk.  Can you remind me?
<smoser> htey're per-instance, right 
<smoser> i think we just leave them where they were right now (/var/lib/walinux/ or whatever)
<smoser> but i guess makes as much sense to move them to /var/lib/cloud/instance/data or something. 
<Odd_Bloke> smoser: Yeah, I'd prefer not to write them out to the walinuxagent path because we aren't holding ourselves to the same disk format (e.g. we aren't writing out some files that walinuxagent does, because we're just using them in-memory).
<Odd_Bloke> And not using a temporary directory makes life much easier, because then I don't have to care about clean-up.
<Odd_Bloke> (Or carrying the location of the temporary directory around)
<Odd_Bloke> smoser: Having said that, though, some of this happens before we have an instance-id; will /var/lib/cloud/instance even be in place during the data source run?
<smoser> you're right. it wouldnt be ther.e
<smoser> so what are you writing out ? i'm confused.
<Odd_Bloke> smoser: All of the certificate stuff is too involved to do in-memory, so we shell out to openssl; at the moment we store the files it operates on and produces in a temporary directory.
<Odd_Bloke> But it would be good to have them somewhere more permanent for (a) debugging/analysis, and (b) avoiding temporary file handling/cleanup in the code.
<Odd_Bloke> If there isn't a good place to put them, I can stick with the tmpdir approach.
<smoser> well, i htink that since you dont have a instance-dir yet, you dont have a good place for per-instance stuff. i tihnk tempdir seems the best path. 
<Odd_Bloke> Cool.
<Odd_Bloke> smoser: Can you remind me what the DHCP bounce in Azure is intended to achieve?  Is it to get the fabric to recognise the host?
<Odd_Bloke> smoser: (I'm trying to work out if I've replaced what it does with the WALinuxAgentShim work)
<smoser> Odd_Bloke, i think its to "publish" the hostname.
<smoser> harlowja, https://etherpad.mozilla.org/cloud-init-roadmap
<smoser> that was claudiopoppa and my work last week to try to get something down as targets
<tmclaugh[work]> Hi, is bootcmd run before networking is fully setup?
<tmclaugh[work]> Trying to ping a host in out environment before talking to Puppet
<smoser> tmclaugh[work], not guaranteed to have network up
<smoser> if you're using a local datasource
<smoser> if you have a network datasource you will have network
<smoser> (because thats how you found the datasource)
<harlowja> smoser cool
<harlowja> smoser i start to wonder how much of systemd is doing all this same stuff (configuring networks...)
 * harlowja doesn't really know, i just thought it started to have similar stuff
<harlowja> maybe we should rename this to cloud-init-systemF (F is after d)
<harlowja> it freakin has a 'systemd-timesyncd' woah, lol
<harlowja> https://wiki.archlinux.org/index.php/Systemd-networkd ( smoser ) ?
<harlowja> so i am starting to wonder if cloudinitd just tells systemd to do things... ?
<smoser> harlowja, that is 'networkd' which is part of systemd
<smoser> cloud-init will just kick networkd into submission
<smoser> harlowja, we're moving to networkd for ubuntu server in 15.10
<harlowja> smoser cool beans
<harlowja> ya, i guess everyone will be eventually
<harlowja> *all linux variants
<harlowja> although who knows maybe windows doing all that open source stuff it will also adopt systemd, lol
<harlowja> *microsoft doing all that open source stuff (not windows)
<smoser> :)
<smoser> its gonna be great.
<smoser> unicorns and rainbows everwhere.
<tmclaugh[work]> smoser: sorry, was in a meeting.
<tmclaugh[work]> This is an AWS host with te data attached to the magic URL
<smoser> yeah. then network should be up at that point
<smoser> all network interfaces desscribed as 'auto' in /etc/network/interfaces should be up
<harlowja> smoser unicorns, woot!
#cloud-init 2015-05-07
<Odd_Bloke> smoser: I'd like to split the walinuxagent stuff in to a separate file (with a view to perhaps making it a standalone library in the future); does that sound reasonable?  If so, where would be the best location for it in the tree?
<smoser> Odd_Bloke, well, there is a sources/helpers/openstack.py 
<smoser> seems similar ?
<Odd_Bloke> Yeah, that would probably make sense.
<Odd_Bloke> smoser: Apologies for MP-related email noise; I'm going to split walinuxagent stuff out to a helper package and then resubmit the MP.
<smoser> ok
#cloud-init 2015-05-08
<Odd_Bloke> smoser: https://code.launchpad.net/~daniel-thewatkins/cloud-init/walinux-wip/+merge/258644 is the merge for the Azure stuff.
<Odd_Bloke> I've re-introduced the original code path, so SRU'ing isn't HORRENDOUS.
#cloud-init 2016-05-09
<openstackgerrit> Sharat Sharma proposed openstack/cloud-init: Deprecated LOG.warn.  https://review.openstack.org/314042
<trodemaster_> Looking for advice on how to troubleshoot cloud-init failing to retrieve OpenStack metadata with a Ubuntu 16.04 instance. What is a good place to start my investigation?
<smoser> trodemaster_, config drive ?
<smoser> https://bugs.launchpad.net/cloud-init/+bug/1577982
<trodemaster_> I'm using the openstack datasource
<trodemaster_> will try that workaround to see if it helps tho. thx
<trodemaster_> Doesn't seem to be my issue...
<larsks> trodemaster_: a good place to start is to boot an image that has password login enabled so that you can log in and diagnose the metadata access.
<larsks> Although using a config drive ought to work around any issues with access to the network metadata service.
<trodemaster_> My image allows me to ssh in currently. I have even verified that I can curl down the metadata. http://169.254.169.254/openstack/latest/meta_data.json the odd part is cloud-init still is failing to see it.
<harlowja> smoser https://code.launchpad.net/~harlowja/cloud-init/cloud-init-net-refactor/+merge/293957
<harlowja> thoughts welcome
<harlowja> this gets me to a place where now i think i can add a redhat net renderer
<harlowja> xand then i'll find people that want to test it :-P
<rharper> harlowja: I read throw the merge late last week; it looks really good, I'll read again and add any comments.  On the next step, are you looking at a sysconfig renderer or networkd?
<harlowja> rharper the above cuts off more of the debian specific stuff into its own files
<rharper> ok, even more churn, cool
<harlowja> :)
<harlowja> rharper ummmm, not sure, rhel7 i think supports sysconfig, not sure about networkd
<harlowja> perhaps networkd, if its supported (and i learn about it, ha)
<rharper> ok, we're starting to look at networkd output
<rharper> so didn't want to duplicate it
<harlowja> i'm not totally sure if rhel7 has networkd stuffs
<rharper> hehe, it's likely there (you just need systemd-networkd binary)
<rharper> but wonder if it's tested
<harlowja> unsure
<harlowja> https://www.reddit.com/r/CentOS/comments/3a8rp8/not_in_centos7_systemdnetworkd/ lol
<rharper> ok, well, no cross over then; but with systemd convergence, I wonder how we'll handle that in net inside cloud-init ?
<rharper> do we have a distro common area?
<rharper> it's suddenly not so per-distro
<harlowja> for net stuff?
<rharper> yeah
<rharper> network_state -> networkd conf is likely non-distro specific
<harlowja> https://code.launchpad.net/~harlowja/cloud-init/cloud-init-net-refactor/+merge/293957 has cloudinit/net/__init__.py for that
<rharper> ok
<harlowja> and just cloudinit/net/
<harlowja> distro stuff ---> cloudinit/net/distros
<harlowja> at least thats what that proposal did
<rharper> y
<harlowja> mirrors closer to the cloudinit/distros
<harlowja> that change makes the net dir more like https://gist.github.com/harlowja/4824483bd5066899f429d0de9c6a1437
<harlowja> with common stuff in cloudinit/net/ or cloudinit/net/__init__.py
<rharper> looks nice
<harlowja> ya, mainly shuffle shuffle, lol
#cloud-init 2016-05-10
<harlowja> klibc might not be a good name though
<harlowja> perhaps just kernel
<harlowja> or cmdline ?
<rharper> hrm,  was klibc ever exposed other than the name of the parser ?
<harlowja> seems like stages.py uses it
<rharper> looks like it's a real package
<harlowja> ya, its really cmdline.py
<harlowja> should just name it that, lol
<rharper> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=715497
<harlowja> the main function it exposes is read_kernel_cmdline_config
<rharper> but maybe that's just ancient cruft
<rharper> yeah
<rharper> I'd be happy with cmdline, but smoser would know more history
<harlowja> idk what klibc is doing there, but there are like '_klibc_to_config_entry' and such in it
<harlowja> which i didn't understand, and therefore just picked klibc, lol
<harlowja> *didn't understand the reference to
<rharper> also, we need smoser to go head and import bzr branch into code.launchpad.net/curtin/+git
<harlowja> that's gonna support more than debian right ;)
<rharper> git repo, yeah, just git hosted at lp
<SpComb> I'm experimenting with systemd-nspawn, and trying to use the ubuntu cloud-iamges as systemd-nspawn containers. Wondering if there's any sane way to use cloud-init to configure them
<smoser> SpComb, you want to seed /var/lib/cloud/seed/nocloud/
<smoser> with a user-data and meta-data
<smoser> lxd does this (you should try lxd, it really is quite smooth)
<SpComb> smoser: thanks
<cpaelzer> smoser: if I put something in cloud_init like the doc/examples/cloud-config.txt: source: "ppa:smoser/ppa"
<cpaelzer> smoser: that should get translated into the right thing right?
<cpaelzer> smoser: e.g. what apt-add-repository would make from it, due to aa_repo_match matching and then calling it
<cpaelzer> right?
<smoser> cpaelzer, yeah. that will match the ADD_APT_REPO_MATCH
<smoser> and be passed to apt-add-repository
<smoser> err... add-apt-repository
<cpaelzer> smoser: hmm - it didn't (I started creating all kind of apt_source tests)
<cpaelzer> ok, just wanted to make sure it "should" will ping you again as soon as I have more data, a real question or a fix
<cpaelzer> smoser: FYI - you mail was a good starting point and I look into it - which is why I started creating apt_sources tests
<cpaelzer> smoser: I don't want to hack on the "key without sources" without any verification that the old works as it did before
<cpaelzer> smoser: is there any vmtest (planned) or is the unit test framework all we have atm?
<smoser> there is some vmtest that rharper started
<smoser> let me find
<cpaelzer> but still in a separate MP somewhere?
<smoser> https://code.launchpad.net/~raharper/+git/cloud-init-test/
<cpaelzer> smoser: thanks, not sure if I will use it, but worth a look
<smoser> cpaelzer, http://paste.ubuntu.com/16347019/
<smoser> that works for me wrt ppa source
<cpaelzer> smoser: oh it works now as well, I found that the matcher is by default not provided since I call add_source directly
<cpaelzer> smoser: fixed now
<cpaelzer> smoser: but that pastebin is a nice test example - I like that
<smoser> cpaelzer, so if you're looking at vmtest, we do want to get something better in place.
<smoser> generally speaking for test we have
<smoser> (or should have)
<smoser> a.) unit tests
<smoser> b.) datasource tests
<smoser> c.) system boot tests
<smoser> 'b' is a pain, requiring mock-like datasources (or testing on the real thing). so those can delay for sure.
<smoser> both b and c require an os image and an ability to patch in trunk cloud-init into it.
<smoser> although we'd want it to allow for other hypervisors, i'd think for most things i'd like to use lxd
<smoser> for 'c'
<smoser> for anything that was not environment specific (such as apt config)
<smoser> cpaelzer, sorry i missed your ping in server earlier
<cpaelzer> smoser: thank, thats a good overview to start with
<cpaelzer> smoser: and never mind about the lost ping, that delay was worth 4 working tests already :-)
<cpaelzer> smoser: whenever the day is over I'll link a bzr branch (no MP yet) just to check if I head in the right direction before doing that for more time
<smoser> you saw my comments in mp ?
<smoser> yeah, you did.
<harlowja> rharper looks like i'll need to add rhel6 support, so i think sysconfig stuff is still needed (vs just networkd)
<harlowja> rharper are u doing the networkd stuff currently?
<rharper> harlowja: ok, so wondering if we want to do the networking backends via the type (eni, sysconfig, networkd, network-manager) ?
<rharper> versus distro ?
<rharper> or I suppose the distro should import the backend writers
<rharper> since debian could support eni and networkd
<harlowja> i think distro class should decide that :-P
<rharper> y
<rharper> but we might move the backend writer out of the distro-class itself
<harlowja> ah
<harlowja> then ya, i guess u are right
<harlowja> maybe net/kind/eni.py and ...
<harlowja> seem to make sense?
<rharper> yeah
<harlowja> cool
<harlowja> i'll update the branch i have to do that
<smoser> kind ?
<smoser> definitely i think the distro object should know what it is going to render based on checking the system or config.
<harlowja> right, in https://code.launchpad.net/~harlowja/cloud-init/cloud-init-net-refactor/+merge/293957 i put in a _net_renderer in the distro
<harlowja> (at least the debian distro)
<harlowja> just think cloudinit/net/<kind> would be better named in that folder
<rharper> harlowja: sorry I missed part of your original question; re: networkd, I'm starting on  supporting network_config to write out networkd files (.link, .network, .netdev); so we'll have that as well
<harlowja> kk
<harlowja> seems like godaddy (where i'm at) still needs rhel6/centos6 soo i guess i'll have to do sysconfig
<harlowja> but if u doing networkd, that should i think work for newer versions of rhel7/centos7
<rharper> yeah
<cpaelzer> smoser: it gets late, but I think I'll gonna continue on the tests and then go for the "key without source"
<cpaelzer> smoser: if you want to do an early check and mail me some feedback over my night feel free to look at https://code.launchpad.net/~paelzer/cloud-init/test-apt-source/
<smoser> k
<larsks> smoser: have you heard of people seeing errors from growpart when running with LANG != en_US.utf8?
<smoser> larsks, it would seem plausible
<smoser> but current trunk does LANG=C anytime it invokes sfdisk
<larsks> trunk for cloud-utils?  or for cloud-init?
<smoser> trunk for cloud-utils
<larsks> Oooo, can we get a release? :)
<smoser> probably should, yeah.
<smoser> but if i were going to do that i'd like to know that it fixes your sisue first
<smoser> rather than releasing something and then finding out still broken
<larsks> I think that would almost certainly fix the issue, because the issue is clearly sfdisk returning localized text that doesn't parse correctly in response to --show-pt-geometry.
<larsks> But I will test.
<smoser> well, current trunk d oesnt use show-pt-geometry anymore either :)
<larsks> So many wins!
<smoser> revno 267 basically added support for sfdisk > 2.26
<smoser> so i'm kind of surprised youd only fail with different locale
<larsks> This is sfdisk 2.23.2 (rhel 7)
<smoser> ah. ok.
<harlowja> rharper  ok https://code.launchpad.net/~harlowja/cloud-init/cloud-init-net-refactor/+merge/293957 should have the new adjustments for folders/module names
<harlowja> once we can get that in, then i can start on the sysconfig stuffs
<smoser> harlowja, from cloudinit.net.renderers import eni
<harlowja> yup
<harlowja> lol
<smoser> renderers seems strange i think
<harlowja> they render network config -> blobs
<smoser> where does the code that reads eni go ?
<smoser> ie, cloudinit.net.renderers.eni renders eni
<smoser> but
<smoser> cloudinit.net.readers.eni reads it ?
<harlowja> better name?
<smoser> or
<harlowja> cloudinit.<widget>
<harlowja> lol
<smoser> cloudinit.net.netcfgsystems.eni has readers and writers for eni
<smoser> idont knwo
<harlowja> *cloudinit.net.kinds.eni ?
<smoser> hm.. i'm not being clear i think
<harlowja> be clear man
<harlowja> lol
<smoser> lets use 'widget' for 'eni' above
<harlowja> k
<smoser> cloudinit.net.renderers.<widget>.Renderer()
<smoser> and
<smoser> cloudinit.net.readers.<widget>.Reader()
<smoser> versus
<smoser> cloudinit.net.<widget>.Renderer()
<smoser> and
<smoser> cloudinit.net.<widget>.Reader()
<smoser> that make sense ?
<harlowja> seems to
<smoser> do you put readers together or <widgets> together
<smoser> is what i'm asking
<harlowja> i'm gonna go with widgets
<smoser> er.. readers/renderers together.
<smoser> k
<harlowja> ya, let's go with together
<harlowja> tweaking in progress
<harlowja> smoser would u be opposed to moving cloudinit/net --> cloudinit/distros/net ?
<harlowja> at least its in a similar module then
<smoser> hm.
<smoser> similar module ?
<smoser> i think i kind of want net/ standalone
<smoser> as that is the thing that is shared with curtin
<harlowja> net stuff being about distros :-P
<harlowja> and distros/ being where distro stuff is, lol
<harlowja> thats my only motivation for that
<smoser> yeah.
<harlowja> okie dokie, updated that merge with that
<harlowja> also another question, on the 0.7.x stuff, has anyone been ensuring the py2.6 stuff continues to work?
<harlowja> i'm thinking some of net stuff won't work on 2.6 (due to format() changes that afaik only work in 2.7)
#cloud-init 2016-05-11
<larsks> smoser: that patch totally fixed the problem (w/ growpart).
<chucky_z> hm, is there a 'correct' way to shim/bootstrap the hostname function?  i'd prefer to run my own little diy python script to set the hostname, but have it called through cloud-init
<larsks> chucky_z: you could use the write_file module to write the script to disk, and then run it via a runcmd. Or you could just deliver the script as your only user-data, making sure it starts with #!/usr/bin/python. Or you could bundle it up with a cloud-cfg file in a MIME archive and pass that as your user-data.
<cpaelzer> smoser: just FYI - really slow progress due to sick wife/kids and many external DPDK calls today - but the mock stuff worked fine
<smoser> :-(
<smoser> cpaelzer, yeah, and feel free to re-organize code for easier testing.
<smoser> larsks, https://launchpad.net/cloud-utils/trunk/0.28
<larsks> smoser: thanks!
<smoser> that was a long time coming. thank you for pushing
<harlowja> smoser rharper i'm also going to fix python2.6 in https://code.launchpad.net/~harlowja/cloud-init/cloud-init-net-refactor/+merge/293957 so expecct a few more changes
 * harlowja will also add a few more test cases to the net rendering pipeline
<harlowja> since it appears that 0.7.x at some point lost 2.6 support :-/
<harlowja> (and ya, i know some people still use rhel6)
<chucky_z> what user does cloud-init run as?  is that defined in the cloud.cfg?
<harlowja> root
<chucky_z> hm, ok
<chucky_z> i wrote a script to be run by runcmd, placed it into /etc/cloud/cloud.cfg.d/, but it doesn't appear to be doing anything (the script has no output, it's an alternate hostname setting)
<harlowja> ya, probably not the right place to put it
<chucky_z> hm, couldn't get the runcmd to do anything, but placing the actual script under /var/lib/cloud/scripts/per-boot/ worked. :)
<smoser> chucky_z, thats the right place to put it.
<smoser> (/var/lib...)
<chucky_z> if I understand correctly, a `runcmd` should go under /etc/cloud/cloud.cfg.d/ though?
<smoser> no.
<smoser> you could put a file like:
<smoser> /etc/cloud/cloud.cfg.d/my-runcommands.cfg
<smoser> with
<smoser> runcmd:
<smoser>  - [sh, '-c', 'echo HI MOM']
<smoser> but then if you provide user-data that has runcmd in it it will override that.
<harlowja> smoser what can we do about not breaking py26 for 0.7.x
<harlowja> pyserial seems to be dead on 26
<harlowja> and various other things in cloudinit
<smoser> hm.
<harlowja> :-P
<harlowja> i fixing a bunch
<smoser> has it broken recently ?
<harlowja> ya
<smoser> :-(
<harlowja> for a while i think, lol
<harlowja> anything using pyserial not work, lol
<smoser> well, anything using newer versions of pyserial.
<smoser> right?
<smoser> surely pyserial from rhel-of-years-ago works
<harlowja> ya, i think 3.0+
<harlowja> those seemed to remove py26
<harlowja> would be nice to have even basic travis testing on cloudinit
<harlowja> maybe i'll setup something that can at leaset run nightly
<smoser> we do haev a system that we can run some c-i on
<smoser> can you see https://server-team-jenkins.canonical.com/
<smoser> i thin kthat is public
<harlowja> no connecting
<harlowja> :-P
<smoser> hm..
<smoser> my route there goes all internal.
<smoser> :-(
<smoser> yeah, we should really get something setup
<harlowja> ya, i mean https://travis-ci.org/harlowja/cloud-init-1/ i can run if it will start up
<harlowja> using https://github.com/harlowja/cloud-init-1/blob/master/.travis.yml
<harlowja> which is the mirror of a mirror of bzr
<harlowja> lol
<harlowja> let's see if https://travis-ci.org/harlowja/cloud-init-1/builds/129542406 runs
<harlowja> at least i can force that hourly or something
<smoser> ok. so i want to get this going and get to git and such.
<harlowja> ya
<harlowja> how about that :-P
<smoser> i have a few bugs that i'm working on that need to be fixed in xenial
<smoser> so they're high priority
<harlowja> k
<harlowja> fixhttps://travis-ci.org/harlowja/cloud-init-1/jobs/129542407 is the pyserial junk
<harlowja> * https://travis-ci.org/harlowja/cloud-init-1/jobs/129542407
<smoser> and then after i get that in i want to look at the nwere datasource model thing that i started.
<harlowja> after we fix 2.6
<harlowja> lol
<smoser> well, yeah
<smoser> the big thing missing from datasources right now is the ability to find local information (such as a config drive)
<smoser> but not be "processed" (and have '#include http://' from user-data rendered) before networking is up.
<smoser> ie right now, for config drive you only get networking applied if your 'dsmode=local'
<smoser> but if you are dsmode=local, then you cant use '#include http'...
<harlowja> woot, https://travis-ci.org/harlowja/cloud-init-1/builds/129542406 worked
<smoser> so. that needs badly fixing.
<harlowja> except for 2.6
<harlowja> pypy even works
<harlowja> lol
<smoser> i like the little baby penguins there
<smoser> they're so cute
<harlowja> :-p
 * smoser has to go now
<smoser> later.
<harlowja> peace
<rharper> harlowja: pypy? nice;  I was going to give that run, some folks on single-core arm have said "python is slow" and wanted to see what the speed-up might be using pypy
<harlowja> well it runs at least, at passes tests
<harlowja> https://code.launchpad.net/~harlowja/cloud-init/cloud-init-net-refactor/+merge/293957 that should fix all the py26 stuff also
<harlowja> mainly http://bazaar.launchpad.net/~harlowja/cloud-init/cloud-init-net-refactor/revision/1229
<harlowja> probably can be refined, but ya, at least it works now
<harlowja> where works == passes tests
<rharper> right
<rharper> that's what I was going to test first; step one done =)
<harlowja> :-P
<rharper> heh, the pypy run was slower than the others
<harlowja> cool, wel there is my cloudinit changes for the day, back to openstack-land
<rharper> ta
#cloud-init 2016-05-12
<ccard> If I want to use the ca-certs module (as here: https://cloudinit.readthedocs.io/en/latest/topics/examples.html#configure-an-instances-trusted-ca-certificates), what do I need to add to /etc/cloud/cloud.cfg?
<ccard> I can see /usr/lib/python2.7/site-packages/cloudinit/config/cc_ca_certs.py, so do I add "ca_certs" to cloud_config_modules? Or "ca-certs"? Is the difference between "-" and "_" significant?
<cpaelzer> ccard: the config value should be behind ca-certs:
<cpaelzer> ccard: ca_cert_cfg = cfg['ca-certs'] - that line gets the "section" (if you want to call it that way - behind ca-cert
<cpaelzer> ccard: all following uses ca_cert_cfg to read subelements
<cpaelzer> ccard: http://cloudinit.readthedocs.io/en/latest/topics/examples.html#configure-an-instances-trusted-ca-certificates
<ccard> cpaelzer: thanks. What do I need in /etc/cloud/cloud.cfg in the cloud_config_modules section? "ca-certs" or "ca_certs"?
<cpaelzer> the former, as listed in the example link
<cpaelzer> ccard: ^^
<ccard> cpaelzer: I don't see anything in that link about /etc/cloud/cloud.cfg
<cpaelzer> ccard: right I just found the config syntax for it - not a particular statement about cloud.cfg
<cpaelzer> ccard: usually you put that as a submodule and include it from cloud.cfg
<cpaelzer> ccard: but IIRC you could add it directly there as well if you want
<cpaelzer> let me take a look
<ccard> Currently, the /etc/cloud/cloud.cfg I get by default doesn't have ca-certs module listed (similarly for the resolv_conf module). I have cloud-init-0.7.5-10.el7.centos.1.x86_64 on CentOS 7 which lays down /etc/cloud/cloud.cfg. The ca-certs module exists, but is not configured into cloud-init as far as I can see.
<cpaelzer> ccard: ah - now I get you what you want to put into cloud.cfg
<cpaelzer> ccard: looking at my 0.7.7~bzr1212-0ubuntu1 I see it listed in modules
<cpaelzer> ccard: http://paste.ubuntu.com/16373639/
<cpaelzer> ccard: I don't know if this is not yet fully exploited on your version or just disabled by default - sorry
<ccard> cpaelzer: so it should be "ca-certs" in the cloud_init_modules (not cloud_config_modules)?
<cpaelzer> ccard: that is what is in my more recent version, but it leaves my comfort zone to hard-confirm it for your case
<ccard> cpaelzer: ok, thanks for your help
<cpaelzer> ccard: I'll look in the repo and check when it was added there
<cpaelzer> ccard: maybe it sheds some more light
<ccard> cpaelzer: thanks
<cpaelzer> ccard: it was just adding it there (no moving) back in 2012 with the comment "Add ca-certs into the main config to run just before rsyslog."
<cpaelzer> ccard: but then the code handling that got merged along that - so I'd find it quite weird if you had the code but not this change in the config
<ccard> cpaelzer: probably a RedHat thing
<cpaelzer> ccard: you can find a bit of the devl history n just this in https://bugs.launchpad.net/cloud-init/+bug/915232
<ccard> cpaelzer: thanks
<cpaelzer> smoser: for the testing with mock I wonder if/how to access files usually deployed by the package itself
<cpaelzer> smoser: I think I got the concept of self.patchUtils and such to rewrite the basic file access methods
<cpaelzer> smoser: and that works fine for stuff that I write to stay in e.g. a tmp dir
<cpaelzer> smoser: but my tests now pass code that e.g. checks for /etc/cloud/templates/sources.list.ubuntu.tmpl
<cpaelzer> smoser: and this is not "there" in the test environment - no matter if I rewrite access or not
<cpaelzer> smoser: I wonder how those files - that would be provided by the package install - would get into the test environment
<cpaelzer> smoser: I didn't find a test that cared about that yet - is there one which I could use to learn from how to get those files in the test environment?
<cpaelzer> smoser: I might just mock around the clock to get it for the unittests, but I wonder if it could be done
<cpaelzer> smoser: would you expect urlparse to return for hostname on 'ftp.us.debian.org'?
<cpaelzer> I need to read more of the specs or write a small test app ...
<cpaelzer> smoser: it is so sad, I added all kind of nice stuff like self.patchOS(self.new_root) once I understood what it did
<cpaelzer> smoser: but later I understood it even more and removed oh so much
<cpaelzer> smoser: final changes look silly when I think how much I wrote to get there :-)
<cpaelzer> smoser: at least - nice learning experience
<smoser> cpaelzer, did you get all you needed ?
<cpaelzer> smoser: other than the theoretical question about /etc/cloud/templates/sources.list.ubuntu.tmpl above yes
<cpaelzer> smoser: and even that I got working via mocking, but I was eager to find out if it would be possible at all
<cpaelzer> smoser: I've sent you a MP for the cloud init part what you asked for
<cpaelzer> smoser: currently down in calls and soon in the same as you :-)
<cpaelzer> smoser: after that is family handling time, but in like 3 hours I'd be back
<cpaelzer> smoser: if you have any complex feedback til then we coudl discuss it - otherwise I'd go on on the curtin part of it tomorrow
<smoser> cpaelzer, just hit 'reply'
<smoser> or whateer that button was labeleed
<smoser> https://code.launchpad.net/~paelzer/cloud-init/test-apt-source/+merge/294521
<cpaelzer> smoser: thanks *reading*
<cpaelzer> smoser: ack to all, with some vague yes to the style things
<cpaelzer> smoser: I'll modify once everybody around is sleeping
<cpaelzer> smoser: I'm sitll on 50% Austin tz anyway
<cpaelzer> smoser: so you should have a new MP to look at over my night later on
<smoser> k.
<harlowja> smoser i'm also going to go through and fix up a bunch of flake8 issues
<harlowja> https://gist.github.com/harlowja/3ba219c41f1e5dd3cd596b4795f8abe8
<harlowja> nothing major, just some minor stuff
<harlowja> https://gist.github.com/harlowja/3ba219c41f1e5dd3cd596b4795f8abe8#file-gistfile1-txt-L119 is sorta major i guess though, lol
<harlowja> probably won't work in py3
<smoser> hmm
<smoser> harlowja,
<smoser> flake8	2.5.4-2
<smoser> that does not complain about it
<harlowja> odd
<smoser> what version do you have ?
<harlowja> 2.2.4
<harlowja> still shows it for me if i upgrade
<harlowja> cloudinit/sources/helpers/openstack.py:149:5: H236  Python 3.x incompatible __metaclass__, use six.add_metaclass()
<harlowja> cloudinit/sources/__init__.py:50:5: H236  Python 3.x incompatible __metaclass__, use six.add_metaclass()
<harlowja> that one also
<harlowja> i'll fix it up sir
<smoser> http://paste.ubuntu.com/16378958/
<harlowja> ya, i'm pretty sure u are just weird
<harlowja> lol
<harlowja> $ pip freeze | grep   "pep8\|pyflakes\|flake8\|pylint"
<harlowja> flake8==2.5.4
<harlowja> pep8==1.7.0
<harlowja> pyflakes==1.0.0
<harlowja> pylint==1.5.5
<harlowja> thats my stuffs
<harlowja> then
<harlowja> flake8 cloudinit/sources/helpers/openstack.py
<harlowja> cloudinit/sources/helpers/openstack.py:149:5: H236  Python 3.x incompatible __metaclass__, use six.add_metaclass()
<harlowja> cloudinit/sources/helpers/openstack.py:487:1: H401  docstring should not start with a space
<smoser> harlowja, that warning comes from pyflakes, right ?
<smoser> and mine is newer than yours
<smoser> and newer is always better
<smoser> always
<harlowja> lol
<smoser> rharper, (or harlowja ) there is no way to go from ENI to network-config, right ?
<smoser> i see parse_deb_config() but that returns some other 'ifaces' dictionary
<harlowja> i didn't see anything that does that parsing
<harlowja> just network-config -> network-state -> eni
<smoser> http://paste.ubuntu.com/16379781/
<smoser> so my current path of attack for all this network config stuff is to drop 'dsmode'
<harlowja> ya, i think thats this other thing
<harlowja> there are a few formats at play here in the net stuff :-P
<harlowja> network-config isn't the internally used format
<harlowja> its converted into something else
<harlowja> (for some reason)
<smoser> hm.. ok.
<harlowja> ya
<harlowja> https://code.launchpad.net/~harlowja/cloud-init/cloud-init-net-refactor has some examples/tests that i added for this
<harlowja> http://bazaar.launchpad.net/~harlowja/cloud-init/cloud-init-net-refactor/revision/1227 (one test)
<harlowja> but ya, smoser there is a internal format that i'm not sure why it was created :-P
<smoser> well, rharper did that. and i dont really care if theres an internal format as long as you can got fmt1 <-> Internal <-> fmt2
<smoser> and ideally losslessly
<harlowja> ya, i'm not sure its loseless
<smoser> right. well, /etc/network/interfaces as a format is lossy in and of itself.
<smoser> because it does not declare the mac or of the nic. just its name.
<smoser> so at least you have to read from the /sys and hope for the best state :)
<harlowja> http://bazaar.launchpad.net/~cloud-init-dev/cloud-init/trunk/view/head:/cloudinit/sources/DataSourceConfigDrive.py#L309
<harlowja> the converter ^
<harlowja> bazaar.launchpad.net/~harlowja/cloud-init/cloud-init-net-refactor/  i think helps here, so ya, merge it, lol
<harlowja> https://code.launchpad.net/~harlowja/cloud-init/cloud-init-flake8-fixups/+merge/294548 also
<smoser> harlowja, i'm generally ok with fixing up lint things (and pyflakes things)
<smoser> but its obnoxious when that is a never ending task, and you end up chasing your tail to work in all different versions
<smoser> for example, pyflakes for me is perfectly happy.
<smoser> but for you it is not
<harlowja> well some of these are somewhat basic issues
<smoser> yeah, but why does my pyflakes not care
<harlowja> __metaclass__ afaik is gone in py3 :-/
<smoser> when mine is >= to yours for all of pep8, flake8 and pyflakes
<harlowja> and stuff like class A: is different on py3 vs p2 where u need to do class A(object)
<smoser> well, sure. and that is all ok.
<smoser> but why does my system think its ok.
<smoser> and yours not
<smoser> i'm not ok randomly fixing crap like that
<harlowja> https://gist.github.com/harlowja/fb8a1c2c27ecf433daf71524f150bc18
<harlowja> i just installed all the same versions :-P
<harlowja> your system is weird, lol
<harlowja> ohhh i think i know
<harlowja> can u install hacking==0.10.2
<smoser> i'm using this thing called a distribution
<smoser> i get stuff from it.
<harlowja> :-P
<harlowja> ya, it should be packaged under some name
<harlowja> https://github.com/openstack-dev/hacking is the project
<smoser> wow
<smoser> that is quite helpful (/sarcasm)
<smoser> apt-get install python3-hacking and all of a sudden flake8 decides to act differently.
<harlowja> ya....
<harlowja> action at a distance :-P
<smoser> neither of these packages indicate interaction with one another.
<harlowja> ya, i know, i forgot about it
<harlowja> but they do :-/
<smoser> see the 'chasing your tail' comment above ?
<harlowja> but the issues its raising are still useful ;)
<smoser> so what do you do about this sort of thing.
<harlowja> https://code.launchpad.net/~harlowja/cloud-init/cloud-init-flake8-fixups/+merge/294548 (imho fixes a bunch that i think are useful)
<smoser> i really dont like it when random dude on the internet uploads a new python-<foo> package
<harlowja> lol
<smoser> and then my c-i (which is not present for cloud-init, but should be) starts to fail
<smoser> i dont find that terribly useful.
<harlowja> yes sir, u are from a distro company, i can tell :-P
<harlowja> u must work at canonical
<harlowja> lol
<smoser> if everything always got better, that'd be one thing.
<smoser> but i have evidence otherwise.
<smoser> https://bugs.launchpad.net/pyflakes/+bug/1560134
<smoser> on your python packages, what do you do ? do you pin versions of stuff in tox ?
<harlowja> yup
<smoser> or do you just love the daily activity of changing source code so you can fit joe-random-dude's daily gut feeling on what is the best way to write code.
<harlowja> as long as joe random dude == josh random dude
<harlowja> where josh random dude == me
<harlowja> lol
<smoser> alright. so lets pin versions then.
<harlowja> k
<smoser> for curtin i added a 'trusty' tox target
<smoser> as you can write code that is happy on today's version of "good" but not april 2014's version of good.
<harlowja> i trusty u
<harlowja> lol
<harlowja> ok in https://code.launchpad.net/~harlowja/cloud-init/cloud-init-flake8-fixups/+merge/294548  i froze the lint requirements
<smoser> i do like the alphabetical order on imports
<smoser> harlowja, i'll merge that if you read and offer thoughts on http://paste.ubuntu.com/16380605/
<harlowja> yes boss
<harlowja> smoser looks ok, i think i'd want each datasource to provide a setup_network (that most can just not implement) and cloud-init will call this on first boot (if there are multiple datasources that impl this that are active, we can i guess pick the first)
<harlowja> that will get rid of some of the weird networking crap in config drive
<smoser> harlowja, well, as it is right nwo in trunk the datasource may provide a network_config
<smoser> and if it does, then cloud-init (in stages.py) will aply networkign as described there.
<cpaelzer> smoser: did you know that long key fingerprints where broken?
<harlowja> oh ya, right
<cpaelzer> smoser: next MP will contain a fix but that was a good idea to test the long fingerprints
<harlowja> smoser  http://bazaar.launchpad.net/~cloud-init-dev/cloud-init/trunk/view/head:/cloudinit/sources/DataSourceConfigDrive.py#L114 still exists though :-
<cpaelzer> smoser: the embedded shell script lackes a few " and due to that it was broken for long fingerprints with spaces
<harlowja> :-/
<smoser> cpaelzer, :). how are they broken ?
<smoser> harlowja, yeah, that is yucky.
<smoser> thats why i was asking about converting network-interfaces into network-config
<smoser> as ideally if there was an interfaces style file there, then we'd just convert it to a network-config and use it there.
<cpaelzer> smoser: it is well hidden and just appears to not work, but at the root cause changing gpg --keyserver ${ks} --recv $k to use "${k}" does the job
<harlowja> smoser hmmmm
<harlowja> i mean, i can make a shitty converter
<smoser> :)
<harlowja> one already exists (but it doens't go to network-config)
<cpaelzer> smoser: I reorganized the code a bit to allow testing down to the last level so it is not only fixed but should be catched next time
<harlowja> smoser http://bazaar.launchpad.net/~cloud-init-dev/cloud-init/trunk/view/head:/cloudinit/distros/net_util.py
<harlowja> ^ shitty converter
<harlowja> u can just take the output format of that and turn it into network-config
<harlowja> or whatever format u want, (of the 3+ that exist in cloud-init to represent network stuff, lol)
<smoser> yeah :-(
<smoser> we really need to have one internal representation
<harlowja> yup
<smoser> i guess i'm ok with that being 'network state'
<harlowja> ya, that format isn't to well defined
<harlowja> i tried deciphering it, lol
<harlowja>  cause network state is really just a object with a version and a dict (the dict is the actual info)
<harlowja> http://bazaar.launchpad.net/~cloud-init-dev/cloud-init/trunk/view/head:/cloudinit/sources/DataSourceConfigDrive.py#L308 (network_config there seems to be the actual format)
<harlowja> and i sorta tried to figure out what network_config is, lol
<harlowja> because network_config seems to be the dict that network state actually uses
<harlowja> so ya, it'd be nice to well have that more well ummmm, defined, lol
<harlowja> cause http://bazaar.launchpad.net/~cloud-init-dev/cloud-init/trunk/view/head:/cloudinit/net/network_state.py#L72 sorta just sets some random attributes, hard to tell what the real format is :-P
<smoser> harlowja, curtin has the best examples of it.
<smoser> we do need some much more formal documentation on that.
<harlowja> def
<smoser> http://bazaar.launchpad.net/~curtin-dev/curtin/trunk/files/head:/examples/
<harlowja> yup yup
<harlowja> sooo i'd be ok with that being the internal cloud-init format
<harlowja> and then adjusting other places
<harlowja> and having a loseless(?) openstack -> that format converter
 * harlowja won't ask why the openstack format wasn't just used :-P
<harlowja> bb, food
<smoser> cpaelzer, hm.
<smoser> i'm looking at that export key thing. and it is crap.
<smoser> which is probably not a surprise to you :)
<smoser> but it does seem to work for long fingerprint also
<cpaelzer> with " it works for long
<cpaelzer> without bash might break it
<cpaelzer> and the gpg tool considers it a list of short id's
<smoser> http://paste.ubuntu.com/16381150/
<smoser> it works for me for long and short as is.
<cpaelzer> haha
<cpaelzer> smoser: wait for my example
<cpaelzer> smoser: use this as the long key
<cpaelzer> smoser: "B59D 5F15 97A5 04B7 E230  6DCA 0620 BBCF 0368 3F77"
<cpaelzer> smoser: which is how it is listed by some tools, so people filling the config file might copy and paste it with spaces
<cpaelzer> smoser: dpending on how things are connected it wither selects 5F15 as keyserver or tries to fetch 10 shortkeys with their ids
<cpaelzer> smoser: both wrong
<smoser> ah. yeah.
<smoser> so yeah, that shoudl be quoted for sure.
<smoser> its really crap that it has to recieve them
<smoser> it tries to clean up after itself, and delete the thing (and not delete it if it found it locally already).
<cpaelzer> smoser: I saw it
<cpaelzer> smoser: all kind of messy if things get interrupted
<cpaelzer> smoser: yet I didn't want to fix the whole world in one day
<cpaelzer> smoser: I updated the MP and the commit message
<smoser> well, its not really *too* messy.
<smoser> root's local .gpg will just know of that fingerprint
<smoser> its not really the end of the world
<cpaelzer> ah is that local - yeah it is just gpg and not apt-key
<cpaelzer> I'll call it EOD then
<harlowja> smoser what about extracting the curtin and net stuff into a curtin_net or something package?
<cpaelzer> smoser: is there a good way of running curtin e.g. vmtests bundled with that experimental cloud-init?
<harlowja> this would just have the format, the converters and renderers and that's about it
<cpaelzer> smoser: if there is please drop me a mail, so I can use it tomorrow
<harlowja> instead of being in cloudinit or being in curtin
<harlowja> (or make other fancy name besides curtin_net)
<harlowja> lol
<smoser> originally i intended to have curtin's net and block modules move externally to something else.
<smoser> but then rharper and i kind of decided that we would like for it to be in cloudd-init.
<harlowja> hmmm
<dcrouch> Is it possible to read mdata from smartos within cloud-init?
<smoser> dcrouch, what is mdata ?
<smoser> ah. i see.
<smoser> dcrouch, http://bazaar.launchpad.net/~smoser/cloud-init/trunk.joyent-cleanup/revision/1216
<dcrouch> smoser, Basically I can provide metadata to the server from smartos.  mdata is that metadata, for example.  https://dpaste.de/sDKS
<smoser> i started a re-work of the smartos datasource that has a much simpler to use client
<smoser> http://paste.ubuntu.com/16381487/
<dcrouch> I'm thinking maybe I can write a python module, pull that data, and have it loaded on firstboot for items such as root password.
<smoser> oh. well, the answer then is yes
<smoser> and cloud-init already has a datasource for smartos
<smoser> and it reads that stuff.
<smoser> you give cloud-init config and it does what you tell it
<dcrouch> I understand that, but when we create our images in SmartOS, I need a way to send data to the vms  for firstboot, so was looking how to get this for ubuntu.
<dcrouch> https://dpaste.de/TFYr
<smoser> dcrouch, that client is only in the branch i pointed you too above.
<smoser> dcrouch, you're the cloud ?
<smoser> ie, you're smartos ?
<dcrouch> Correct smoser!
<smoser> vendor-data
<smoser> thats what you want.
<smoser> thats what it was designed for basically.  vendor-data is user-data for the vendor
<smoser> look at DataSourceSmartOS and read the comments around 'vendor-data' there :)
<smoser> harlowja, you added 'igmore' of all those flake8 stuff
<smoser> H404,H405
<dcrouch> smoser, I've been looking up cloud-init for the last few hours and a few topics around there, I thought I recognized your name!    https://github.com/number5/cloud-init
<smoser> but why ?
<harlowja> smoser less things for me to fix in 1 merge, lol
<smoser> but they're all fixed
<harlowja> u can fix all the 404 and 405 ;)
<harlowja> oh
<harlowja> welllll then (makes up other reason)
<smoser> at least i just comment that line out
<smoser> and type 'tox -e pyflakes'
<smoser> and ENOERROR
<harlowja> hmmm, run flake8 not pyflakes
 * smoser shames fist at his feeble brain
<smoser> i confuse those two things all the time
<harlowja> https://gist.github.com/harlowja/32845acbd0301fc2132fbd9255bddd1d
<harlowja> 405 and 404
<harlowja> and i'm like screw that, its a dumb warning, lol
<smoser> i assumed you had added a tox
<harlowja> nah, i didn't want to do everything, gotta leave u some work to
<smoser> yeah. thanks.
<harlowja> i'm nice like that
<smoser> harlowja, so i'm gonna change pyflakes to flake8
<smoser> which i think is a strict superset of pyflakes
<smoser> right?
<smoser> and then i'm going to fix all the tests/ so that it wont complain about those either
<harlowja> cool
<harlowja> sound good to me
<harlowja> (yes afaik its a superset of)
<dcrouch> Thanks for your help smoser I think I'll be back still confused but need to take off for a bit.
#cloud-init 2016-05-13
<jfcastro> hi all! how can I add swap in a dedicated drive to instance with cloud-init?
<jfcastro> I know OpenStack do that and I'd like run the same
<cpaelzer> jfcastro: you already have some sort of disk in your system, but want cloud-init to make it being used as swap - is that the case?
<cpaelzer> jfcastro: https://github.com/number5/cloud-init/blob/master/doc/examples/cloud-config-disk-setup.txt
<cpaelzer> and one example using that e.g. https://wiki.ubuntu.com/AzureSwapPartitions
<cpaelzer> you'd have to know your disk name
<cpaelzer> jfcastro: untested - but it should/could be something like http://paste.ubuntu.com/16386532/
<jfcastro> cpaelzer: great! I'll try it and let you know ;)
<jfcastro> cpaelzer: thanks :)
<larsks> smoser: is python 2.6 the minimum version supported by cloud-init?
 * larsks hopes the answer is yes.
<dcrouch> How's it going this morning?
<dcrouch> smoser, Are you there?
<jgrimm> dcrouch, smoser is out (vacation) today
<harlowja> smoser not around, jeezsh
<dcrouch> Thanks jgrimm.
<jgrimm> np
<dcrouch> He briefly pointed me to a cloud-init script, I was wondering how from SmartOS to get root password set by my creation script to change the root password on a VM.  I was having trouble getting mdata values into a firstboot.
<dcrouch> jgrimm, ^
<gfidente> guys, I wanted to submit a small change and I am going through the contributor agreement form ... which canonical pm should I use?
<gfidente> harlowja ? :)
<gfidente> or should I rather checkout the openstack/cloud-init git and use git-review ?
<harlowja> gfidente i think u want to use scott moser as the project contact (if that's what u are asking)
<gfidente> harlowja, ah I put yout nick though
<gfidente> can I change it?
<harlowja> hehe, i don't work at canonical :-P
<harlowja> smoser though does, i'm not sure about changing it
<harlowja> smoser would know
<gfidente> doh!
<harlowja> :)
<gfidente> harlowja, btw, fwiw I think I managed to propose the changes
<gfidente> https://code.launchpad.net/~gfidente/cloud-init/try_fqdn_from_hosts/+merge/294680
<harlowja> cool
<gfidente> ack leaving now
<gfidente> have good weekend :)
<harlowja> woot
#cloud-init 2016-05-15
<Guest44353> Anyone up late and looking to lend me a hand, I have been fighting with this for 2 days and at this point I'm not getting any further. Cloud-init, cloud-config AWS EC2 using #include with a file:/// directive, using a multipart setup, so that I can grab/build my #cloud-config file and load it locally on the server, and then have the cloud-init take it and run with it.  I've gotten further with it, but as of now cloud-init never
<Guest44353>  finishes and thus I am locked out of the instance I'm trying to create.
<Guest44353> https://forums.aws.amazon.com/thread.jspa?messageID=720556&#720556 for any further information on what I've tried and where I am at
<Guest44353> Failed to start Initial cloud-init job, interesting that seems like something what was fixed in (LP: #1432758) yet I just hit it.. Guess i can break anything if I try hard enough.
<tmblue> bah
<tmblue> ahh CentOS 7  is running 0.7.5 this was fixed in 0.7.7,, I'll take a look at see what CentOS 7 has in their repo's, ahh 0.7.5  w0w, almost a year later..
<tmblue> okay maybe this one someone can answer, while I continue banging my head, is there a clean way to run cloud-init via the command line on an instance pointed at the multipart created file to see what it does? And then clean up after it and try it again
#cloud-init 2017-05-08
<smoser> rharper, or blackboxsw review of https://code.launchpad.net/~smoser/cloud-init/+git/cloud-init/+merge/323059 appreciated
<blackboxsw> looking now
<rharper> ack
<smoser> i'm looking at the i386 fail
<smoser> hm..
<smoser> that is very odd
<smoser> powersj, around ?
<smoser> whats the environment https://jenkins.ubuntu.com/server/job/cloud-init-ci/nodes=vm-i386/308/console
<powersj> smoser: I am
<powersj> i386 is a IS owned VM
<smoser> i can't reproduce that in a i386 container or in a i386 vm
<powersj> wow that is very interesting to see it fail only there hmm
<powersj> smoser: what type of lxd did you use? that is a trusty i386 VM. I'll try myself in a sec.
<smoser> powersj, i ran xenial i386 host is artsy
<smoser> and i tried server stack xenial i386 kvm
<powersj> smoser: `lxc launch ubuntu-daily:trusty/i386 t32` reproduced it after installing 'git python-tox'
<powersj> well, it failed, but different error, doh :\ nose.proxy.KeyError: 'datasource_list'
<smoser> powersj, what is 'git python-tox' ?
<smoser> oh. those two packages
<powersj> sorry.... apt-get install git python-tox
<powersj> yeah
<smoser> i thought you were using 'git' to install 'python tox'
<smoser> duh
<smoser> man. this little trip down trusty memory lane shows me how much improvment there was in apt
<blackboxsw> smoser: more comments on your branch. it took me a while to formulate some thoughts on it.
<smoser> k
<smoser> i am oging ot have to r un
<smoser> there is a shell bug/difference in trusty and xenial that my code is exposing
<smoser> horay
#cloud-init 2017-05-09
<utlemming> smoser: I see that https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1681531 was not included in the upload to cloud-init...any chance we can get that in?
<ubot5> Ubuntu bug 1681531 in cloud-init (Ubuntu) "DigitalOcean DS defines mutliple gateways via meta-data" [Medium,Confirmed]
<smoser> utlemming, its not in the sur'd version. it will get into trunk and sru'd next pass.
<smoser> oh
<smoser> there are unit tests on this. can you cange them to explicitly show this ?
<utlemming> sure
<raspado> i have a few instances where epehemeral storage is available depending on instance size, they are somehow auto attached as /dev/vdb but we use /dev/vdb, is there a method to prevent cloud-init from automounting ephemeral storage?
<raspado> we provision systems vis salt-cloud
<raspado> vis=via
<smoser> raspado, https://cloudinit.readthedocs.io/en/latest/topics/modules.html?highlight=regex#mounts
<smoser> and https://git.launchpad.net/cloud-init/tree/doc/examples/cloud-config.txt#n36
<smoser> i think what you're probably after is:
<smoser>  mounts:
<smoser>   - [ ephemeral0, null ]
<smoser> blackboxsw, https://code.launchpad.net/~smoser/cloud-init/+git/cloud-init/+merge/323059 is in a fairly good state now.
<smoser> rharper, see line 364 of merge there. that is the i386 failure.
<smoser> dash bug that is present only on i386 16.04.
<blackboxsw> checking
<rharper> smoser: interesting
<rharper> gnarly
<rharper> seems like a strange bug
<rharper> is it arbitrary (does it do if for other chars besides [  ?
<rharper> probably should file a bz and log it in the comments
<smoser> not all characters
<smoser> i can file a bug, but its not one i'm going to push on
<smoser> i386 only is the key "i dont care"
<smoser> rharper, oh wait. shoot. not 16.04. 14.04.
<rharper> smoser: heh, yeah; it's easy enough to workaround, worth documenting
<smoser> i was wrong. not i386 specific.
<smoser> just that our i386 test system is trusty
<smoser> rharper, bug https://bugs.launchpad.net/ubuntu/+source/dash/+bug/1689648
<ubot5> Ubuntu bug 1689648 in dash (Ubuntu Trusty) "removing open bracket ([) via ${var#[} fails does not work on i386." [Medium,Confirmed]
<rharper> smoser: cool
<smoser> (fixed bug subject)
<blackboxsw> smoser: approved https://code.launchpad.net/~smoser/cloud-init/+git/cloud-init/+merge/323059
#cloud-init 2017-05-10
<blackboxsw> thanks for the review smoser , i updated the description and added inline comments to https://code.launchpad.net/~chad.smith/cloud-init/+git/cloud-init/+merge/323819
<smoser> blackboxsw, ok. i'll grab that. was erhe a bug for that /
<blackboxsw> smoser: oops forgot to link it (or name the branch properly so that was autolinked
<blackboxsw> tying that there now
<blackboxsw> https://bugs.launchpad.net/cloud-init/+bug/1687485
<ubot5> Ubuntu bug 1687485 in cloud-init "sysconfig route object reference removed class attribute" [Medium,In progress]
<blackboxsw> done
<blackboxsw> smoser: do you know with launchpad git can we specify something like --fixes lp:bugnum when commiting like bzr did?
<nacc> blackboxsw: no it's not part of git itself
<nacc> blackboxsw: so you'd need to LP: # in the d/chagnelog
<nacc> blackboxsw: (I think that's all bzr did?)
<blackboxsw> nacc I recall w/ bzr being able to --fixes lp:<num> and merge proposals auto-linked. But yeah I was wonding if launchpad did some commit parsing or other 'magic' shortcuts for bug linking.   Ok I'll use LP# in commit messages. (which was a requirement that  forgot for cloud-init anyway)
 * blackboxsw changes my description and adds a commit message. thx nacc
<nacc> blackboxsw: yeah, so LP sees that for sure (in d/changelog). It also will link the bugs to a MP, I think.
<nacc> I forget if that's automatic or not
<nacc> blackboxsw: were you referring to the git ommit message or the d/changelog?
<blackboxsw> nacc I was referring to the git commit message
<blackboxsw> if we add git commit message containing LP:# will launchpad auto link?
<nacc> blackboxsw: I *think* it might
<nacc> blackboxsw: smoser would know for sure
<smoser> nacc, yeah, bzr had much more specific metadata. --fixes actually put a named field separate from the commit message that had that data.
<smoser> blackboxsw, if you push a branch for review that has
<smoser>  LP: #XXXXX
<nacc> smoser: right, it was more tightly integrated
<smoser> in the commit message (i think restricted to beginning of line)
<smoser> then it will link it
<smoser> it being launchpad
<smoser> and cloud-init's tools for genrating changelogs will read that out
<smoser> so yeah, if you're fixing a bug, as the last line in the commit message use LP: #XXXXX
<smoser> blackboxsw, i'm running an integration test on the freebsd branch right now. if that passes, i'll move to yours.
 * smoser is using this new fangled gnome thing
<smoser> without any notifications that someone said my name in an irc window on a nother desktop, /me is likely to be slower to respond to irc
<nacc> smoser: :) probablly there is a gnome-shell thing for that
<blackboxsw> ahh gnome shell :(
<nacc> i think that's what it's called, right?
<nacc> tbh, ive been running gnome ubuntu for a while, because i disliked unity :)
<smoser> rharper, https://code.launchpad.net/~raharper/cloud-init/+git/cloud-init/+merge/314539
<smoser> that could use a look .. seems to have gotten lost
<smoser> nacc, what is gnome ubuntu ?
<smoser> gnome 3 , right?
<nacc> i think so
<rharper> smoser: boo; yes, that should land
 * blackboxsw is walking through SRU bugs from the top http://pad.lv/1682160
<ubot5> Launchpad bug 1682160 in cloud-init (Ubuntu Yakkety) "update-grub-legacy-ec2 fails if no /etc/fstab causing install or upgrade fail" [Medium,Confirmed]
<blackboxsw> xenial only at the moment
<smoser> gaughen, launch me an amazon instance please.
<blackboxsw> smoser: to confirm, on xenial SRU we will walk through all the xenial cases today even though yakkety & zesty haven't been updloaded yet as seen it https://launchpad.net/ubuntu/+source/cloud-init.  We'll await steve's upload and go through Y & Z then right
 * blackboxsw moves on to https://bugs.launchpad.net/cloud-init/+bug/1685810 verfication now
<ubot5> Ubuntu bug 1685810 in cloud-init (Ubuntu Zesty) "nova-lxd needs to read 'product_name' in environment, not 'platform'" [Medium,Confirmed]
<rharper> smoser: I need to rebase that ntp fix
#cloud-init 2017-05-11
<blackboxsw> smoser: did you say zesty was ready for sru testing? or just that bits were uploaded
<blackboxsw> xc exec $name -- dpkg -l | grep cloud-init
<blackboxsw> ii  cloud-init                                 0.7.9-90-g61eb03fe-0ubuntu1
<blackboxsw> grabbing zesty proposed still shows 90 instead of 113
<smoser> blackboxsw, zesty, yakkety are in queue still.
<nacc> blackboxsw: maybe he meant x-p?
<smoser> yesterday i thoguht i had forgotten to upload
<nacc> blackboxsw: rmadison helps see that
<blackboxsw> +1 nacc /me uses rmadison from now on
<nacc> blackboxsw: also means less state to maintain on your system :)
<blackboxsw> or in my head
 * smoser thinks that those urls i provided are more useful than rmadison
<smoser> https://launchpad.net/ubuntu/+source/cloud-init
<smoser> as it shows you dates
<nacc> why do the dates matter?
<nacc> just wondering
<smoser> so you know how long its been in proposed. or how old (at a glance) the thing in -updates is
<smoser> plus the little twisties and the changelogs are useful.
<nacc> smoser: ah ok, but from (strictly) versioning perspective, you don't need that :)
<nacc> smoser: yes, i can see why that would be useful
<blackboxsw> smoser: do we need utlemming to sru validate and tag validation-done-xenial on digital ocean for xenial ? https://bugs.launchpad.net/cloud-init/+bug/1676908
<ubot5> Ubuntu bug 1676908 in cloud-init (Ubuntu Zesty) "DigitalOcean network improvements" [Medium,Fix committed]
<blackboxsw> or are we running through this validation?
<blackboxsw> I see yakkety and zesty just got accepted into proposed for SRU validation too. guess the rest of my day will be going through those too
<utlemming> done
#cloud-init 2017-05-12
<smoser> utlemming, could you on that bug also verify yakkety and zesty ?
<utlemming> smoser: done
<smoser> thanks
<smoser> blackboxsw, if you're wanting something to do before rharper comes around https://code.launchpad.net/~smoser/cloud-init/+git/cloud-init/+merge/323420
<smoser> id' like your input there
<blackboxsw> looking now. just SRU-ing have some interesting questions on nova-lxd creation from lxc image export .
<smoser> ok. if you want to chat, we coudl do that to wait also :)
<blackboxsw> I'm just hanging out in the standup channel
<blackboxsw> for whenever rharper and smoser join
<smoser> k
<rharper> smoser: in the standup now
<smoser> joiing
<smoser> 2 min
<rharper> it's now 3 minutes past ...
<rharper> =P
<blackboxsw> ack he hid that from comments so it's no longer public
<blackboxsw> just a heads up on that it was "released" to people who subscrived to the bug
<mikec_64> is it possible to prevent an ssh authorized key from being added to root?  I only want the key added to the normal user
<rharper> AFAICT no ssh keys are added to root; but we'd need to see the user-data
<rharper> ssh-import-id or other ssh key settings are done against the 'default' user;  in ubuntu images, this is the user ubuntu
<rharper> ubuntu user is also in the sudo group, so one can get root on the instance but it won't append ssh keys to the root user
<rharper> mikec_64: ^^
<smoser> mikec_64, well, cloud-init adds the keys to root, but does so with a command that says 'hey, log in with other user'
<smoser> end result is that you cannot log in as root with those keys.
<mikec_64> ahh the issue I am running into is that puppet does not like keys that have the exact same content & name
<mikec_64> I am changing my puppet setup to disallow root login and then just skip managing the root user
<rharper> smoser: huh, I didn't know that
<smoser> $ ssh root@10.5.0.12
<smoser> Warning: Permanently added '10.5.0.12' (ECDSA) to the list of known hosts.
<smoser> Please login as the user "ubuntu" rather than the user "root".
<smoser> Connection to 10.5.0.12 closed.
<smoser> http://paste.ubuntu.com/24562286/
<smoser> rharper, can you mark 'approved' on the azure mp ? https://code.launchpad.net/~smoser/cloud-init/+git/cloud-init/+merge/323420
<smoser> and give me links to anything you want me to look at right now
<rharper> smoser: I can. but one item I asked about was the extra os.path.realpaths()
<smoser> yeah... the callers will all have 'realpath' already resolved.
<rharper> ack
<blackboxsw> whew, finally down to the last xenial, yakkety zesty sru verification https://bugs.launchpad.net/cloud-init/+bug/1684869
<ubot5> Ubuntu bug 1684869 in cloud-init "growing root partition does not always work with root=PARTUUID=" [Medium,Confirmed]
<smoser> blackboxsw, \o/
<smoser> thank you!
<blackboxsw> smoser: so I'm on the last one
<blackboxsw> xenial of the above mentioned bug
<blackboxsw> aw=xenial-server-cloudimg-amd64-proposed.img
<blackboxsw> csmith@fringe:~$  ptuuid=$(sfdisk --part-uuid $raw 1)
<blackboxsw> sfdisk: xenial-server-cloudimg-amd64-proposed.img: no partition table found
<blackboxsw> sfdisk worked for both yakkety and zesty raws
<blackboxsw>  file $raw
<blackboxsw> xenial-server-cloudimg-amd64-proposed.img: QEMU QCOW Image (v3), has backing file (path xenial-server-cloudimg-amd64.raw), 2361393152 bytes
<rharper> v3 ?
<blackboxsw> strange as zesty is zesty-server-cloudimg-amd64.raw: DOS/MBR boot sector, extended partition table (last)
<blackboxsw> same w/ yakkety
<rharper> file says that everywhere , strange
<rharper> so, so you have a backed image
<blackboxsw> whoops
<blackboxsw> bah
<rharper> basically someone built a qcow file on top of the original
<rharper> for proposed, which makes sense
<blackboxsw> I grabbed xenial-server-cloudimg-amd64-proposed.img instead of xenial--server-cloudimg-amd64.raw
<rharper> ah
<rharper> there you go
<blackboxsw> PEBKAC
<rharper> it's Friday
<blackboxsw> not for loooooong ;)
<rharper> LOL
 * rharper checks watch
<rharper> hrm, looking a lot like beer-thirty
<blackboxsw> hmm yeak just confirming, same issue w/ the raw file
<blackboxsw> https://www.irccloud.com/pastebin/Xilq7ov2/
<blackboxsw> something xenial specific it seems
<blackboxsw> the xenial image doesn't have an extended partition table definition like the zesty and yakkety raw images
<rharper> hrm
<rharper> oh, that's because it's not GPT based
<rharper> yakkety and newer are unified (uefi + legacy)
<rharper> which requires GPT (uefi does)
<rharper> not sure why the zesty image showed msdos though
<rharper> blackboxsw: yeah, yak and zesty have GPT based partitions, xenial has ms/dos ;  I think that;s the difference
<rharper> blackboxsw: you may need to use blkid -o export on a kpartx mounted image file
<rharper> sudo kpartx -va path/to/image; (will print which mapper device) then you can sudo blkid -o export /dev/mapper/loopNp1
<rharper> it should print a PARTUUID= value
<blackboxsw> thanks rharper. til about kpartx hadn't used it before
<rharper> yeah, so -va (verbose add) and -vd (verbose delete) are most helpful
<rharper> especially with dealing with GPT images which have 2 partitions which you can't mount before your get to the rootfs
<rharper> it just reads pt , calculates offsets and auto configures a loop devivce with the offsets
<rharper> helps for LVM devices as well
<blackboxsw> ok yakkety and zesty are done. xenial is a bit locked up because I don't know the qemu foo to get and boot off the xenial partition
#cloud-init 2017-05-13
<smoser> if its qcow, then thats wrong. you didn't convert it to raw.
<smoser> yeah, sorry.
<smoser> well, for xenial... you woudl need to download the -uefi image
<smoser> sorry, blackboxsw
#cloud-init 2018-05-07
<jellycat1> hiya, is it possible to run cloud-init with a test yaml-file that I'm debugging on the server? I have a file (test.yaml) that is under /root and I'd like to run it the same way a userdata-script would be ran.
* blackboxsw changed the topic of #cloud-init to: Reviews: http://bit.ly/ci-reviews | Meeting minutes: https://goo.gl/mrHdaj | Next status meeting: Monday 5/14 16:00 UTC | cloud-init 18.2 released (03/28/2018)
<blackboxsw> https://bugs.launchpad.net/cloud-init/+bug/1769690
<ubot5> Ubuntu bug 1769690 in cloud-init "IBMCloud ds-identify detects NoCloud but cloud-init determines ConfigDrive " [Low,Confirmed]
<blackboxsw> unble to reproduce cloud-init clean reboot switch to NoCloud from ConfigDrive. may just be an Artful(unsupported by IBM images) thing
 * blackboxsw heads to wrap up bionic SRU
<paulmey> good morning! I was hoping we could get  https://code.launchpad.net/~paul-meyer/cloud-init/+git/cloud-init/+merge/344538 to a state where it can be merged... LMK what you want me to do.
<blackboxsw> paulmey: we can address this this week. rharper is out today (as he had  initial thoughts on this branch I'll defer to him).
<paulmey> ok, I'll try to ping tomorrow morning then, but feel free to remind him. :-) Thanks!
<blackboxsw> hrm just ran into this on bionic https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1769754
<ubot5> Ubuntu bug 1769754 in cloud-init (Ubuntu) "salt-minion: public/private keys not preserved in /etc/salt/pki" [Undecided,New]
<blackboxsw> can't reproduce it across clean reboots, but just fresh installs.
<blackboxsw> it was affecting our clean intregration test runs on bionic
<blackboxsw> https://jenkins.ubuntu.com/server/job/cloud-init-integration-proposed-b/8/consoleFull
<blackboxsw> cloud-init in that case claimed to have written the pub/priv keys into /etc/salt/pki/* but the directory has a modification timestamp later than when the write took place (and the files are no longer there()
<jocha> Hi,
<jocha> oops, accidentally sent that, pls ignore :)
#cloud-init 2018-05-08
<smoser> rharper: i'm going to land https://code.launchpad.net/~smoser/cloud-init/+git/cloud-init/+merge/344768 based on your lgtm.
<smoser> blackboxsw: ^
<rharper> smoser: ok
<blackboxsw> just put up an integration test fix for bionic https://code.launchpad.net/~chad.smith/cloud-init/+git/cloud-init/+merge/345256
<blackboxsw> fixes a couple of things I ran into which testing -proposed for the SRU.
<blackboxsw> hrm smoser/raharper, why would update-ca-certificates generate 3 symlinks in /etc/ssl/certs for a given user-data provided trusted certificate in xenial but only 1 in bionic? https://pastebin.ubuntu.com/p/b7DRPygpYr/
<blackboxsw> s/1 in bionic/2 in bionic/
<blackboxsw> same user-data trusted provided for xenial and bionic
 * blackboxsw was thinking of changing the integration test tests/cloud_tests/testcases/modules/ca_cert.(yaml|py) to instead validate that there is a symlink /etc/ssl/cert/cloud-init-ca-certs.pem -> /usr/share/ca-certificates/cloud-init-ca-certs.crt and >= 1 other link pointing to /etc/ssl/cert/cloud-init-ca-certs.pem
<blackboxsw> instead of just counting the number of files generated by update-ca-certs
<smoser> wow.
<smoser> hm..
 * blackboxsw is reading man pages at the moment trying to figure out what/why
<blackboxsw> and there is no diff in the cloud-init-ca-certs.crt file written on bionic vs xenial
<blackboxsw> hrm reminds me of this maybe https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1077020
<ubot5> Ubuntu bug 1077020 in cloud-init (Ubuntu Raring) "cloud-init ca-certs leaves a blank line in /etc/ca-certificates.conf" [High,Fix released]
<blackboxsw> I'm seeing a blank line in /etc/ca-certificates.conf right now on xenial and bionic
<blackboxsw> will see if removing it affects anything
<blackboxsw> removing the leading blank line in /etc/ca-certificates.conf has not affect on number of symlinks created in /etc/ssl/certs in bionic or xenial.
<smoser> blackboxsw: if i had to guess its this
<smoser>  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=895075
<ubot5> Debian bug 895075 in src:ca-certificates "ca-certificates: Please replace 'c_rehash' with 'openssl rehash'" [Normal,Fixed]
<blackboxsw> The "openssl rehash" command creates half that many symlinks (one per
<blackboxsw> certificate instead of two) because it uses only the newer hash.
<blackboxsw> ahhh ok
<smoser> git-ubuntu is awesome
<blackboxsw> so not a bug, but intended behavior
<blackboxsw> that is an excellent find
<smoser> http://paste.ubuntu.com/p/DbrQGvMZCD/
<blackboxsw> agreed, we should hire nacc :)
<blackboxsw> #toosoon
<blackboxsw> thanks for that smoser
<paulmey> rharper: around?
<rharper> paulmey: here
<rharper> sorry, I was out last week
<rharper> your branch needs a review ?
<paulmey> no problem... yes please:   https://code.launchpad.net/~paul-meyer/cloud-init/+git/cloud-init/+merge/344538
<paulmey> thanks in advance
<paulmey> Thanks rharper, I'll wait for you or smoser to respond to finalize those checks.
#cloud-init 2018-05-09
<mgerdts> rharper not sure if you saw I updated https://code.launchpad.net/~mgerdts/cloud-init/+git/cloud-init/+merge/344168 to address your feedback on April 25.  Anything else needed to get your +1?
<mgerdts> blackboxsw & smoser any more thoughts on SmartOS network reconfig on every boot?  https://code.launchpad.net/~mgerdts/cloud-init/+git/cloud-init/+merge/344168
<mgerdts> opps, wrong link
<blackboxsw> mgerdts: a heads up too, we have a bionic SRU queued with a number of your branches in bionic-proposed. if you get a chance to spin up a bionic instance on smartos could you comment on https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1767412
<ubot5> Ubuntu bug 1767412 in cloud-init (Ubuntu Bionic) "SRU cloud-init 18.2-27-g6ef92c98-0ubuntu1" [Medium,Fix committed]
<mgerdts> https://code.launchpad.net/~mgerdts/cloud-init/+git/cloud-init/+merge/343712
<mgerdts> sure, I can give it a whirl
<blackboxsw> mgerdts: rather spin up a bionic instance, add bionic-proposed via  something like echo deb http://archive.ubuntu.com/ubuntu bionic-proposed main | sudo tee /etc/apt/sources.list.d/proposed.list; apt-get update; apt-get install cloud-init   # should be cloud-init 18.2.2
<smoser> blackboxsw: i just added 'launch-softlayer --list-ibm-images'
<smoser> http://paste.ubuntu.com/p/YqjKGhnyyz/
<blackboxsw> thanks mgerdts will see if we can get you more eyes  on the branches.
<smoser> because 'slcli image list' was required sorting in your head by create date, and didnt show the guid.
<blackboxsw> mgerdts: yeah we have been in a bit of a spend on the recent SRU validation etc. but we're out of the validation tunnel on that now... so it's review catchup time
<mgerdts> That's why I wasn't nagging.  That all changes now.  :)
<blackboxsw> love it ;)
<rharper> mgerdts: lemme look, I was out last week
<mgerdts> thanks
<eshas>  I want to use the ubuntu cloud image for 18.04 on KVM ppc64le. I have done following:wget https://cloud-images.ubuntu.com/bionic/current/bionic-server-cloudimg-ppc64el.img
<eshas> <eshas> <eshas> qemu-img convert -O raw bionic-server-cloudimg-ppc64el.img bionic-server-cloudimg-ppc64el.raw
<eshas> <eshas> <eshas> how do I now create passwd, ssh to imag and use it then to boot?
<eshas> do I have to mount it?
<smoser> eshas: http://paste.ubuntu.com/p/z2nMVQThNY/
<smoser> you have to give a datasource... the above provides a nocloud datasource
<smoser> oops
<smoser> wrong paste
<smoser> http://paste.ubuntu.com/p/sPzywcCckC/
<smoser> maybe thatmakes more sense.
<eshas> oh i see
<eshas> but my issue is I have to create vm from the img on my private cloud
<eshas> can we use guestfish or something to put this file in ubuntu?
<eshas> maybe mount it, chroot,passwd?
<smoser> you have to create a vm from the image on your private cloud.
<smoser> what is the cloud ?
<smoser> if its openstack, then you just upload the image.
<blackboxsw> smoser: couple questions on https://code.launchpad.net/~smoser/cloud-init/+git/cloud-init/+merge/343738   and a suggestion on https://code.launchpad.net/~smoser/cloud-init/+git/cloud-init/+merge/343610
<blackboxsw> rharper: did you have a wip branch/spike for network hotplug functionality. I was specifically wondering if we had made any decisions related to a cloud-init boolean config option for allowing cloud-init to react to network/device hotplug events
<smoser> blackboxsw: i responded to both of those there..
<blackboxsw> thx smoser
<danMS> rharper: I was talking to paulmey about, https://code.launchpad.net/~paul-meyer/cloud-init/+git/cloud-init/+merge/344538 he mentioned there was some additional feedback from scott needed, just following up on this
<rharper> blackboxsw: I don't think I have a branch up; I have some local changes w.r.t the udev hook, so I can send you that
<blackboxsw> mgerdts: some comments on https://code.launchpad.net/~mgerdts/cloud-init/+git/cloud-init/+merge/343712 for you
<blackboxsw> I'll chat w/ smoser/rharper tomorrow about what we want to do here with nic hotplug vs reboot network maintenance
#cloud-init 2018-05-10
<mgerdts> thanks blackboxsw.  I'll try to get through all of your suggestions today or tomorrow.
<robjo> smoser: Q about ds-identify/cloud-init-generator
<smoser> ok.
<robjo> We've run into a case where ds-identify fails because blkid cannot be found
<smoser> as in not present ? or not in path
<robjo> blkid lives in /sbin, but it also lives there in Ubuntu
<smoser> cloud-init assumes that the system is set up to have a sane path
<robjo> now if I modify ds-identify to be /sbin/blkid then the error goes away
<smoser> isnt it just more reasonable to have PATH set up to have utilities in it than to have every tool hard code where it thinks the right place for that is ?
<robjo> but the generator run in the context, i.e. the environment of systemd, i.e. PID 1 and that context nothing is supposed to be assumed
<robjo> I agree with your reasoning but for some reason systemd early execution environment doesn't appear to be the same
<smoser> well you're suggesting i assume that blkid is /sbin/blkid
<smoser> aren't you?
<robjo> I do not know if we decided to fiddle with it or the Ubuntu systemd maintainers
<smoser> https://coreos.com/os/docs/latest/using-environment-variables-in-systemd-units.html
<robjo> no, where I am actually going with this is a question about he generator itself and why it should exist
<smoser> maybe htts not the right link.
<smoser> but surely some way you can change the PATH environment of PID1
<robjo> but this is not a unit file, it's the generator
<robjo> https://www.freedesktop.org/wiki/Software/systemd/Generators/
<smoser> yeah.
<smoser> https://www.freedesktop.org/software/systemd/man/systemd.environment-generator.html maybe ?
<smoser> i dont know how the path gets set on ubuntu.
<smoser> i'm not entirely opposed to adjusting PATH but it just seems like the wrong way to do  things.
<smoser> and i am pretty solidly opposed to cloud-init having to set PATH in other places.
<robjo> Well I can chase the PATH issue by asking our systemd maintainers and when I have a better understanding we can maybe revisit if needed
<robjo> but what I really want to do is drop the generator from my package all together
<robjo> based on me looking through the code ds-identify tries to do what each data source is doing already
<robjo> so why probe twice?
<robjo> if ds-identify doesn't run the Python code still finds the datasource and gets it's data
<smoser> correct. it is supposed to operate without ds-identify.
<smoser> the thing that it can't do without ds-identify is completely disable itself.
<smoser> ie, if ds-identify doesn't find anything then cloud-init.target will not be targetted.
<smoser> and no bottlenecks imposed as a result of that.
<smoser> and no python code run at all in boot
<smoser> ie, you can install cloud-init on your ubuntu desktop and its completely inert (other than the generator running).
<smoser> https://mail.python.org/pipermail/python-dev/2018-May/153296.html
<robjo> fair, but if I impose cloud-init should be used/installed and services enabled only in an environment where it is actually useful then the "check if I should run" becomes kind of unnecessary
<smoser> that is true. bu the value of ds-identify also comes from trimming the DataSource list.
<smoser> so less code runs in python too
<smoser> but more code in shell
<smoser> so...
<robjo> problem is if it fails the Python code, which in this environment then actually works, never gets a chance
<robjo> in a test where we set the full path ds-identify still failed, i.e. no data source was found
<smoser> yeah.
<smoser> i'm fine with simply PATH=$PATH:/sbin:/usr/sbin:/bin:/sbin
<smoser> but honestly you should chase having a sane environment
<robjo> but when forced in that environment, i.e. ds-identify returned true, then cloud-init found a datasource and configuration worked
<smoser> because i'm not the only person that assumes sane environment
<robjo> I will chase that, composing an e-mail this minute
<smoser> i'm pretty confident that ds-identify as it is riht now will improve boot speed
<robjo> but we run the risk of not configuring the system at all
<smoser> well, thats a bug. we can fix it. you can just hard code the PATH.
<smoser> when using software, you do run the risk of bugs.
<smoser> but suggesting you should not use software because of that is not really an option
<smoser> robjo: fyi
<smoser> $ sudo cat /proc/1/environ | tr '\0' ' '  ; echo
<smoser> HOME=/ init=/sbin/init recovery= TERM=linux drop_caps= BOOT_IMAGE=/boot/vmlinuz-4.15.0-20-generic PATH=/sbin:/usr/sbin:/bin:/usr/bin PWD=/ rootmnt=/root
<smoser> i'd be interested in seeing what you have there.
<smoser> interesting. but in a container:
<smoser> $ lxc exec x1 cat /proc/1/environ | tr '\0' ' '; echo
<smoser> container=lxc
<smoser> thats *it* no PATH there. i'm not sure what ds-identify has for path there. i'll check.
<smoser> even in that container environment i get
<smoser>  PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
<smoser> and... robjo seems like it comes from
<smoser> # strings /lib/systemd/systemd | grep PATH=
<smoser> PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
<robjo> cat /proc/1/environ | tr '\0' ' '  ; echo produces a very long list of things, weeding through it
<smoser> thats odd.
<robjo>  PATH=/sbin:/bin:/usr/sbin:/usr/bin
<smoser> in systemd:
<smoser>  src/basic/path-util.h
<robjo> which does make sense because in the images we build there is no issue with ds-identify or I would have found this a while ago
<smoser> #define DEFAULT_PATH_NORMAL "/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin"
<robjo> so that makes me think that the party complaining is also fiddling with stuff they shouldn't
<smoser> https://git.launchpad.net/ubuntu/+source/systemd/tree/src/basic/path-util.h#n31
<robjo> smoser: thanks for digging all of this up much appreciated
<smoser> upstream trunk much harder to read
<smoser> https://github.com/systemd/systemd/blob/master/src/basic/path-util.h
<smoser> blackboxsw: https://code.launchpad.net/~smoser/cloud-init/+git/cloud-init/+merge/343738
<smoser> updated
<blackboxsw> smoser: approved the above,  parting comment for us to chat about some standup
<blackboxsw> just confirmed this yaml.load issue in cloud-init for utf-8 https://bugs.launchpad.net/cloud-init/+bug/1768600 seems fairly signification for someone presenting their own runcmd info that could contain printable utf-8 chars.
<ubot5> Ubuntu bug 1768600 in cloud-init "UTF-8 support in User Data (text/x-shellscript) is broken" [Medium,Confirmed]
<smoser> :-(
 * blackboxsw is working up a quick unit test for robjo 
<blackboxsw> thx for the branches
<robjo> blackboxsw: thanks
<robjo> there didn't appear to be a distinct place where we test the config for stage handling
<robjo> and the tests that run through stages.py confused me :(
<blackboxsw> yeah robjo that stuff (init/stages/and cli main) are pains and not very testable. I started some of it in cloudinit/cmd/tests/test_main.py which I'm adding to now for your branch.
<blackboxsw> so it's hard to tell people they should add tests there because those tests and ugly/mock hells
<blackboxsw> yeah I want cloudinit/tests/test_stages.py, but again haven't yet done that overhaul to pull all tests from tests/unittests to the appropriate tests subdir next to each cloudinit module
<blackboxsw> it's going to be a long manual crank on that one
<dpb1> blackboxsw: for the metadata unification.. do we have the 6-10 fields that we want to name?
<dpb1> instance_id, etc
<blackboxsw> dpb1: currently we have only
<blackboxsw>  "v1": {
<blackboxsw>   "availability-zone": null,
<blackboxsw>   "cloud-name": "nocloud",
<blackboxsw>   "instance-id": "myb1",
<blackboxsw>   "local-hostname": "myb1",
<blackboxsw>   "region": null
<blackboxsw>  }
<dpb1> ok
<dpb1> thx
<dpb1> is that in a card somewhere?
<blackboxsw> I think we are missing probably around 5 fields from the initial cut I took. I'll draw up a doc and card (as I have to refresh my memory on the cloud-instance data we see nowadays
<blackboxsw> I only spiked in NYC and left it to undocumented as I initially hit some datasource generalization issues that'd have to be resolved first
<blackboxsw> dpb1: I did capture std instance-data on a few clouds here https://forum.snapcraft.io/t/feeding-cloud-init-data-to-snapd/3474/21   because as you know, if it's not on snapforums it doesn't exist ;)
<blackboxsw> I'll do a quick review of those to see what we can pull out of the 'ds' related keys provided by the datasources
 * blackboxsw was thinking instance.type, network related information as initial attributes
<blackboxsw> but there will be bit of work first to pull that content out of certain datasources , like OpenStack's network_data.json needs to be represented in our instance-data.json format
<dpb1> the snapcraft forum?
<dpb1> what
<dpb1> blackboxsw: your pastebin's there are meant to be your example of what *would* show up, right?
#cloud-init 2018-05-11
<Gael> Hi All!
<Gael> is there a command to update only security upgrade on a linux with cloud-init?
<dpb1> well, he didn't wait around long. :)
<caribou> Hello everyone, I'm investigating an issue where the cloud-init.service (bionic) fails to complete because it encounters /var/lib/cloud/instance being a directory instead of a symlink
<caribou> I only found LP: #1531880 that talks about a similar issue but it went silent
<ubot5> Launchpad bug 1531880 in cloud-init "Failed to start Initial cloud-init job (pre-networking)" [Undecided,New] https://launchpad.net/bugs/1531880
<caribou> looks to me like it could be a race condition as two instances off the same image on our infrastructure (Scaleway) do behave differently
<rharper> caribou: I've seen those every so often when rebooting before the cloud-init has completed running;  we;ve never been able to reproduce them
<caribou> well, I started two instances off the same image, one has the symlink & the other has a dir :-/ I'm starting a third one for a tie breaker
<caribou> I cannot call it reproducing it but I'm hiting it rather often, let me know if you want me to turn on some more debugging (cc_debug maybe))
<paulmey> smoser: I just read your comments on my NTFS mp
<smoser> yeh
<smoser> or backwards response 'hey'. which ever seems more approriate.
<paulmey> :-)
<paulmey> I like how you propose to always wipe NTFS and explain that there are better choices for filesystems
<smoser> on linux
<paulmey> sure, let's not speak of any other os...
<smoser> not that ntfs isnt a fine filesystem, but the only reason i can think to use ntfs on linux is dual boot
<smoser> or data recovery
<smoser> and ... dual boot on a cloud instance ?
<paulmey> ... yeah
<paulmey> but still, rharper seemed still pretty concerned with possible data on the NTFS partition...
 * paulmey checks what waagent does
<smoser> well, we're only doing this to the ephemeral disk
<smoser> right ?
<smoser> i think we safeguard that pretty well
<smoser> so the peole that we could potentially foobar...
<smoser> are the ones that somehow managed to use ntfs on that ephemeral disk (which cloud-init would have wiped if it could access it)
<smoser> so on that boot, cloud-init was able to mount the filesystem
<smoser> and then that person booted into a kernel (or os) that did not have ntfs
<smoser> all while ignoring the "do not put important data here" warning
<paulmey> https://github.com/Azure/WALinuxAgent/blob/fb7d6c51dac236538a8c9eb8e752159d5e3f54b8/azurelinuxagent/daemon/resourcedisk/default.py#L149
<smoser> *and* MS wipes that disk for them sometimes...
<paulmey> waagent doesn't care at all
<smoser> (wipes on a re-locate)
<smoser> so basically... if this issue comes up, i'll just say "i think your instance must have gotten re-located, and MS lost your data, not cloud-init"
<smoser> :)
<smoser> can i have your phone number to give the user in that case, paulmey ?
<paulmey> sure, I'll pm it
<smoser> :)
<smoser> can you think of some reasonable path that got a user to this stage ?
<rharper> paulmey: I just wanted smoser  to sign off on the approach as well given the effort we went through to make sure cloud-init didn't wipe user-data;
<smoser> i really really dont want to delet people's data
<paulmey> I understand... but their data should not be there in the first place, it's not your fault ?
<smoser> :) that was joking.
<smoser> how did they get the data there was more the question
<smoser> i think this policy seems sane:
<smoser> a.) if we can mount it, then check... dont reformat it if it has files
<paulmey> agreed
<smoser> b.) if we cannot mount it... then check a config variable, if that variable says not to delete, then dont.
<smoser> how did the user get into the 'b' case...
<smoser> the 'b' case where they *had* data on it.
<paulmey> Default when config is not there is to delete if we can't mount?
<smoser> i really think that is probably in the order of 7 people ever
<smoser> right. default the config to allow cloud-init to reformat ntfs filesystems on the ephemeral disk
<smoser> but we also want to make sure that this is *ONLY* the ephemeral disk that we might do this to
<paulmey> In the 4 years that I've done oncall here, I've never seen a complaint about data loss on the ephemeral drive...
<paulmey> My guess is that customer support just points to the docs and helps the customer go through the stages of grief
<smoser> https://siliconangle.com/blog/2011/08/01/third-largest-bitcoin-exchange-bitomat-lost-their-wallet-over-17000-bitcoins-missing/
 * smoser wants to avoid being the reason that that happened
<paulmey> it's very hard to protect people from aiming at their foot
<paulmey> but I appreciate the effort
<smoser> :)
<paulmey> I sign off on your policy, @rharper ?
<paulmey> btw, usually people end up in the b) case due to cloud-init not being able to format the disk in the first place. However, the issue is usually more that the fs is now NTFS instead of ext4...
<rharper> paulmey: smoser's additions sounds fine to me; but that is new space; also requires new cloud-init though I suppose they need that anyhow today
<paulmey> creating swap files or the docker directory on the ephemeral drive if it is NTFS is not going to work well...
<rharper> smoser: did you have a suggestion for the config namespace , what key should users add to say, don't nuke my ntfs drive even if you can't mount it ?
<paulmey> note that the code is in the DSAzure... so maybe a ds config?
<smoser> yeah, in the azure datasource is the rigth place it seems
<smoser> you'll have to be careful though to not just set it in the dsconfig in that  module.
<smoser> because if you do that, it ends up trumping config on disk
<smoser> we just need to make sure that if the user put it in /etc/cloud.cfg.d/ or in user-data, that they are respected.
<paulmey> ok, I'll try to make tests for that
<paulmey> specifically
<smoser> paulmey: and can we please me sure that we WARN iif the 'a' case found files on it
<smoser> WARNING: it looks like you're using NTFS on the ephemeral disk, to ensure that filesystem does not get wiped, set THIS_CONFIG_OPTION
<paulmey> will do
<paulmey> datasource.azure.never-destroy-ntfs ?
<paulmey> or datasource.Azure.never-destroy-ntfs (I need to look that up)
<smoser> underscores rather than -
<smoser> and lets qualify that with 'ephemeral' in some way
<paulmey> ok, datasource.Azure.never_destroy_ntfs_on_ephemeral_disk ?
<robjo> Need some help please, out of ideas about whet to try :( need the yaml to configure ntp
<smoser> robjo: ok.
<robjo> - ntp as entry under cloud_config_modules: enters cc_ntp.py
<robjo> but as soon as I add anything then things fall over
<robjo> I am thinking I should be able to do
<robjo> - ntp:
<smoser> pasetbin what you're giving it ?
<robjo> https://paste.ubuntu.com/p/58DdVk3wYB/
<smoser> its not under cloud_config_modules
<smoser> cloud_config_modules is just a list of modules that are to be run
<robjo> OK, so what should it look like?
<smoser> just put it in as
<smoser>  http://paste.ubuntu.com/p/52DgZBNcJh/
<smoser> http://cloudinit.readthedocs.io/en/latest/topics/modules.html#ntp
<smoser> the code blocks (Examples) might help as an example
<robjo> but shouldn't I see cc_ntp somewhere in the log?
<robjo> I even put a debug statement in handle (first line) and I am not getting it
<robjo> I am only getting the debug if I have -ntp under config modules
<robjo> but hen of course I cannot configure anything
<robjo> or maybe I am testing wrong, I tested with "cloud-init modules" and "cloud-init init" and for bothe cases I am not seeing the expected output in the log??
<smoser> robjo: well to most easily test,
<rharper> if you're running cloud-init from the command line to re-run modules, you likely want cloud-init --file mycloud.cfg --debug single --name cc_ntp --frequency always --report
<smoser>  cloud-init single --name=
<smoser> yeah that^
<rharper> where myconfig.cfg contains the config from smosers's paste
<smoser> but i'd  just put myconfig.cfg in /etc/cloud/cloud.cfg.d and not ptoher with --file
<rharper> otherwise, if you want to test how it's called during firstboot,  you can do: cloud-init clean --logs --reboot;
<robjo> thanks, testing
<paulmey> smoser: so should I still check for mount.ntfs? or is it safe enough to assume that if that existed on $PATH, mount would have found it?
<smoser> well, i think we just try to mount it
<smoser> with mount -t ntfs
<smoser> if that doenst work, then we consult that config option
<smoser> right ?
<paulmey> yeah I'm all for that
<robjo> OK, I cleared out /etc/cloud.cfg and set it to only contain what's in http://paste.ubuntu.com/p/52DgZBNcJh/
<robjo> then I ran cloud-init clean --logs --reboot
<robjo> and when the machine comes back there is no trace of cc_ntp running in the log file
<robjo> and  grep ubuntu /etc/ntp.conf comes back empty
<smoser> can you paste the log ? /var/log/cloud-init.log
<smoser> i suspect your changies to cloud_config_modules made it not ru
<robjo> well there is no cloud_config_modules section now, do I need both? i.e. -ntp in the modules section and the ntp config outside?
<smoser> cloud_config_modules: is just a list of modules
<smoser> not config of those mmnodules.
<smoser> if you took that out, then it wont run the ntp module
<robjo> yay, sorry for being so dumb about this, just goes to show how often I look/need to look at the config
<robjo>  I guess it would be good to have an ntp configuration example in the docs
<rharper> I'm pretty sure we do
<rharper> http://cloudinit.readthedocs.io/en/latest/topics/modules.html#ntp
<robjo> I looked, I promise and search fro ntp turned up empty on http://cloudinit.readthedocs.io/en/latest/topics/examples.html
<robjo> s/fro/for/
<rharper> yes, not added to examples. but examples under the module documentation
<rharper> we could add a message in the examples page to refer to module docs for further examples ?
<robjo> well the disconnect, and I was looking at the sources which basically is that example is the it is not obvious, at least it was not obvious to me that - ntp was needed under the cloud_config_modules and the actual configuration for the parameters was outside of the cloud_config_modules section
<robjo> which is why I poked around at first trying to shoehorn the ntp config itself into the cloud_config_modules section
<robjo> which obviously didn't work either
<rharper> so, the way I look at it, and we can clarify, is /etc/cloud configures cloud-init; and users configure the modules via user-data
<rharper> but I too struggled with the disconnect for a while as well
<rharper>  /etc being the system/distro config space, and user-data covers things the user would like to change, modify
<robjo> Well that's fair but there are cases where this kind of stuff is built into an image and then you end up in the situation I was just in
<robjo> of course I now learned my lesson and thanks for the help, but if it happens to me I bet I will not be the only one
<rharper> for sure
<robjo> others may just not necessarily know where to go for help
<rharper> do you have a suggestion for the docs page?
<robjo> so a short example cloud.cfg file that shows the key bits of this case may be helpful
<rharper> this case being ? system-wide ntp default configuration ?
<rharper> sorry, I missed the start of the convo
<robjo> yes
<rharper> yeah; that seems like a good add
<robjo> hmm doc/examples/ in the source tree has cloud-config-ntp.txt but that doesn't show up on http://cloudinit.readthedocs.io/en/latest/topics/examples.html
<robjo> but that looks to be an example about how to send the information as user-data
#cloud-init 2020-05-04
<meena> that seems like an interesting omissionâ¦
<Odd_Bloke> meena: What does?
<Odd_Bloke> LongLiveCHIEF: Can you confirm what version of netplan you had in that image (`dpkg -l netplan.io`)?
<LongLiveCHIEF> sure, one moment
<LongLiveCHIEF> 0.99-0ubuntu3 for arm64
<LongLiveCHIEF> q
<LongLiveCHIEF> q!
<LongLiveCHIEF> whoops
<Odd_Bloke> :)
<Odd_Bloke> OK, bummer, that's the latest version.
<Odd_Bloke> (So my hopes that this problem would be solved by someone else have been dashed. ;)
<LongLiveCHIEF> yeah... :sad:
<LongLiveCHIEF> there's still many hopes in that regard. That particular bucket of hope is bottomless
<LongLiveCHIEF> something interesting came up in #raspberrypi over the weekend about rfkill disabling wifi early on when wireless region wasn't set
<LongLiveCHIEF> in wpa
<LongLiveCHIEF> ...and it did get me thinking
<LongLiveCHIEF> is there a way to halt cloud-init and drop into a shell before a specific stage?  or to log output of a specific command after/before a stage?
<Odd_Bloke> LongLiveCHIEF: OK, I've confirmed that waveform, the Ubuntu Pi person, is still looking into the wifi issue.
<Odd_Bloke> I don't think we have a good way of doing something like that, no.
<LongLiveCHIEF> no worries, i have my ways
<LongLiveCHIEF> forward my info to the ubuntu pi person if he wants someone in the field to test and report.  my gh is longlivechief
<Odd_Bloke> blackboxsw: I think we can improve your force-push method to not need a tracking file: we already have all that information in git history.  I'm putting something together now.
<mutantturkey> hi guys. i am building a custom image with packer. this gets build on digitalocean, and then reused on digitalocean. what this means is the first timeit runs it gets information from cloud-init regarding networking information, but when i instantiate  the image on a new virutal server that original network information is no longer correct
<mutantturkey> the problem is that, when i create a new server with this image, the FIRST time it boots, it has the incorrect information for networking
<mutantturkey> however, i think this is because the networking information is inputted into /etc/network/interfaces.d/* AFTER network services are already running. So the first time, it'll not have a net conncetion, but correct values, and then subsequently it will work just fine
<mutantturkey> so i am looking for an idea on how to solve this. My one thought was to move /etc/init.d/network to a later sysvinit stage
<blackboxsw> +1 Odd_Bloke
<Odd_Bloke> mutantturkey: What distribution are these images for?  And how are you installing cloud-init?
<blackboxsw> mutantturkey: I'm not super familiar with packer builds. but do you have the opportunity to run 'cloud-init clean --logs' before shutting down that image and redeploying it?
<Odd_Bloke> blackboxsw: `clean` wouldn't remove network configuration, right?
<blackboxsw> Odd_Bloke: no but it would tell cloud-init to re-run network config on next boot (the first redeploy of that created image)
<blackboxsw> I was making an assumption that mutantturkey's guess on /etc/network/interfaces.d/* being written AFTER networking services are running is probably unlikely
<Odd_Bloke> cloud-init should detect that its a new instance without a `clean`, though, so doing that could mask a more general issue on DO.
<Odd_Bloke> If cloud-init isn't plumbed into the boot sequence correctly, it's plausible (and perhaps likely) that it would run after networking services.
<blackboxsw> good point. it *could* be a general issue with DO, but I was presuming it was an issue with how the image is being created with packer
<Odd_Bloke> (And if we're talking about SysV init, then this presumably isn't an Ubuntu image, where I would have higher confidence that cloud-init will get plumbed in correctly simply via installation.)
<blackboxsw> Odd_Bloke: that's a good though too. yeah I guess if the before=networking-target.online (or whatever it's called) wasn't present then right, we could be in that camp
<blackboxsw> or sysV init too right
<Odd_Bloke> Right, except we get no Before= in a SysV world. :p
<Odd_Bloke> blackboxsw: https://paste.ubuntu.com/p/kbC4XkHq3H/ is my iteration of the force-push proposal.
<blackboxsw> Odd_Bloke: yes excellent
<blackboxsw> Odd_Bloke: though we need to limit that globbing to just debian/patches/*cpick*
<Odd_Bloke> blackboxsw: When would we have any cherry-picks in the daily branch that we want to retain?
<Odd_Bloke> Oh, I suppose for non-devel releases?
<blackboxsw> Odd_Bloke: any release can have release-specific packaging, config disabling changs
<blackboxsw> and those debian/patches would not contain a *cpick* or fox-cpick prefix
<mutantturkey> blackboxsw: i do have that opportunity
<mutantturkey> would that fofce on next boot
<mutantturkey> thats perfect
<mutantturkey> this is sysvinit, this is debian buster with a bunch of custom stuff on top
<blackboxsw> like https://github.com/canonical/cloud-init/tree/ubuntu/xenial/debian/patches
<mutantturkey> i can do a rebuild will take an hour or two, dwill that clean thing work?
<blackboxsw> Odd_Bloke: ^
<blackboxsw> mutantturkey: the clean thing removes all semaphores that marked that networking was created in the first place.... but as Odd_Bloke mentoined, it might be masking some other pre-instance change that cloud-init tries to rely on when you are re-launching your created image
<mutantturkey> okay, then let me try that
<mutantturkey> again, sysvinit is more opaque so i dont really want to muck with it if possible :-)
<blackboxsw> mutantturkey: and ok on sysvinit, and Debian, so as Odd_Bloke mentioned the sysvinit dependency ordering may not have been created in your debian image properly to ensure cloud-init writes network before network is brough up by the system, without a strict startup dependency added, cloud-init *could* be writing the network config too late as you guessed
<mutantturkey> what does --logs do
<mutantturkey> wouldn't i want t o keep my logs
<blackboxsw> mutantturkey: --logs rms /var/log/cloud-init.log /var/log/cloud-init-output.log
<mutantturkey> alright im giving it a swing
<blackboxsw> which should allow you to distill what cloud-init does on 'first boot' during your first relaunch
<Odd_Bloke> blackboxsw: The presence of the semaphores isn't relevant if cloud-init isn't running at the right point in boot; we would expect the semaphore to be ignored for a new instance boot anyway.
<Odd_Bloke> mutantturkey: Installing cloud-init from the Debian archive?
<blackboxsw> Odd_Bloke: agreed, but it is useful to compare the last boot stage timestamp against the dmesg or journalctl logs
<blackboxsw> I was only thinking to avoid any previous boot logs from during the image creation process
<mutantturkey> Odd_Bloke: yes
<mutantturkey> okay, blackboxsw i will look at the logs. Clearing out the old config seems like it would be useful to force cloud init to redo its business.
<blackboxsw> Odd_Bloke: also I don't think we can individually just git log --online through all commits as we have had times where we needed to fixup interrelated cherrypicks and lack of a ordered set of commits across all cpick* patches would mean we can't back them out without conflicts partway through
<blackboxsw> actually oops. right git log debian/patche/*cpick* will order that for us properly anyway
<mutantturkey> that did not appear t owork, rebooting now
<mutantturkey> well now it's online but refusing ssh, i think something stuck let me try to reboot again
<Odd_Bloke> blackboxsw: Yep, that should take care of it.
<blackboxsw> Odd_Bloke: good, tested and looks good. I'm resolving your review comments now
<Odd_Bloke> Cool, thanks!
<blackboxsw> Odd_Bloke: I think I'm done https://github.com/canonical/uss-tableflip/pull/45
<Odd_Bloke> blackboxsw: Did you push?  I'm seeing a lot of unresolved comments.
<blackboxsw> hrm, maybe not. checking again and going through comments
<blackboxsw> I had missed about 5 comments Odd_Bloke pushed the changes
<blackboxsw> Goneri: +1 on your branch https://github.com/canonical/cloud-init/pull/305/files with a minor nit. Just needs that and a rebase against master and we are good to go
<Goneri> blackboxsw, done
 * blackboxsw just twiddles thumbs waiting on Travis thanks Goneri will land today
<Odd_Bloke> falcojr: Thanks for the CLA PR, as you can see, I've landed it. :)
<falcojr> cool, thanks
<Odd_Bloke> lucasmoura: Thanks for the CLA PR!
<mutantturkey> alright got sidetracked today but
<mutantturkey> first boot with cloud-init clean doesn't fix the problem
<mutantturkey> first boot i can verify has the correct *updated* configs
<mutantturkey> but it's not applied (i can see that via ifconfig)
<blackboxsw> Goneri: merged thanks !
<mutantturkey> restarting networking does fix theproblem
<blackboxsw> mutantturkey: so Odd_Bloke's suggestion that maybe the deb didn't wire the proper SysV init script dependencies in your image might be the issue there
<mutantturkey> yep
<mutantturkey> theoretically i think i understand how sysviinit works but
<mutantturkey> the goal is, networking should run after cloud init
<blackboxsw> we expect to have a 4 stages wired in the right order during startup something akin to this https://github.com/canonical/cloud-init/tree/master/sysvinit/debian
<mutantturkey> so those are all different init scripts in /etc/init.d right?
<mutantturkey> okay I have those files cool
<blackboxsw> mutantturkey: yep.
<mutantturkey> so during boot this should all go to syslog?
<blackboxsw> I was just checking an older release of cloud-init on trusty to confirm separate config files in /etc/init
<mutantturkey> yes i do have those
<Goneri> thanks blackboxsw :-)
<mutantturkey> okay blackboxsw we have a lead!
<mutantturkey> it appears none of these are configred
<blackboxsw> mutantturkey: guaranteed to go to /var/log/cloud-init.log not sure where debian typically logs cloud-init emitted logfiles besides the default
<mutantturkey> if i read rc*.d right, anything that starts with S means 'start"
<blackboxsw> s/besides/in addition to/
<mutantturkey> k means, kill at tha trun level
<mutantturkey> networking is in the rc.S runlevel
<mutantturkey> so looks like cloud-init's 4 things aren't gettng run at startp
<blackboxsw> that sounds like reasonable failure path ;)
<mutantturkey> though clearly something is running because cloud-init does LOG
<mutantturkey> ooff
<blackboxsw> mutantturkey: cat /run/cloud-init/status.json that'll tell you what stages did run (on newer cloud-init you can run "cloud-init analyze show")
<Odd_Bloke> blackboxsw: Note that trusty is upstart, not SysV.
<blackboxsw> oopsie, right-o though our collection of init scripts mentioned here https://github.com/canonical/cloud-init/tree/master/sysvinit/debian should be all-inclusive of what we expect to see on debian right
<mutantturkey> S12networking
<mutantturkey> that's so whack
<Odd_Bloke> blackboxsw: I wouldn't assume so (particularly as those haven't been touched in 7 years).
<mutantturkey> well that makes non sense
<mutantturkey> let me jump into #debian and seewhatup
<mutantturkey> blackboxsw: alright,here we go. it's at runelevel S, which is like single user mode, happens before evreything else
<mutantturkey> that's before _all_ the cloud service bits run
<mutantturkey> which well makes since to me because other services might try to bind to a specifc IP etc and fail if networking is not up
<mutantturkey> so, givne that, is there a move to make here
<mutantturkey> so i think "cloud-init writes config files, but doesnt run ifup or the like to configure networking after then config is changed'
<mutantturkey> bso my simple thought is another init file called /restart-networking-hack that runs on runelevel 6 that reruns ifup
#cloud-init 2020-05-05
<ausfestivus> afternoon. Anyone here able to assist with a cloud-init issue? I am unsure how best to go about isolating the root cause of the problem
<ausfestivus> ill describe the issue anyway and see if anyone wants to have a stab at it
<ausfestivus> Deploying an Ubuntu 18.04LTS VM on Azure.
<ausfestivus> Intermittently, cloud-init will fails with:
<ausfestivus> Fetched 18.7 MB in 6s (2935 kB/s)Reading package lists...E: Could not get lock /var/lib/dpkg/lock-frontend - open (11: Resource temporarily unavailable)E: Unable to acquire the dpkg frontend lock (/var/lib/dpkg/lock-frontend), is another process using it?
<ausfestivus> For some reason it appears that two `apt` commands are running
<ausfestivus> I am unsure why this is so
<ausfestivus> cloud-config simply says:
<ausfestivus> ```cloud-config simply says:
<ausfestivus> package_upgrade: truepackages:- jq- chrony- ipvsadm
<ausfestivus> apols for the formatting
<ausfestivus> package_upgrade: truepackages: (new line, list of packages in the correct format)
<ausfestivus> anyway, sometimes it works, sometimes it doesnt. Feels like a race condition to me in the sequencing of cloud-init
<ausfestivus> but im not an expert so figured it wouldnt hurt to seek some guidance here
<meena> Odd_Bloke: re, meena> that seems like an interesting omissionâ¦ â calling the thing that makes it work.
<Odd_Bloke> meena: Yeah, it only happens with wifi, which is the puzzling part.
<Odd_Bloke> ausfestivus: Thanks for the report!  For future reference, a pastebin service like https://paste.ubuntu.com/ makes it a lot easier to communicate multi-line files.  That does look like a race of some description; is this an official Ubuntu image in Azure?
<Odd_Bloke> (There have been races between cloud-init and unattended-updates in the past, but I believe those have been resolved.)
<blackboxsw> #startmeeting cloud-init status meeting
<meetingology> Meeting started Tue May  5 16:16:41 2020 UTC.  The chair is blackboxsw. Information about MeetBot at http://wiki.ubuntu.com/meetingology.
<meetingology> Available commands: action commands idea info link nick
<blackboxsw> good morning, afternoon and evening folks. Welcome to another cloud-init status meeting.
<blackboxsw> #chair Odd_Bloke smoser rharper
<meetingology> Current chairs: Odd_Bloke blackboxsw rharper smoser
<blackboxsw> our IRC channel topic carries the next planned status meeting for those that wish to participate. All are welcome to interject or drive converstation topics here
<blackboxsw> I'll set the next status meeting topic while we are thinking about it.
<blackboxsw> 2 weeks from today, same time 16:15 UTC.
* blackboxsw changed the topic of #cloud-init to: pull-requests https://git.io/JeVed | Meeting minutes: https://goo.gl/mrHdaj | Next status meeting May 19 16:15 UTC | 20.1 (Feb 18) | 20.2 (Apr 28) | https://bugs.launchpad.net/cloud-init/+filebug
<blackboxsw> May 19th it is.
<blackboxsw> Previous meeting minutes live over on github
<blackboxsw> #link https://cloud-init.github.io/
<blackboxsw> The topics we generally cover in this meeting are the following: Previous Actions, Recent Changes, In-progress Development, Community Charter, Upcoming Meetings, Office Hours (~30 mins).
<blackboxsw> #topic Previous Actions
<blackboxsw> Looks like no unresolved actions from last meeting
<blackboxsw> #topic Recent Changes
<blackboxsw> Below is a list of commits that have landed in tip of master: found via git log --since 2020-03-10
<blackboxsw> #link https://paste.ubuntu.com/p/YMb2Tw3tRD/
<blackboxsw> We've had a number of milestones since the last status meeting, Ubuntu Focal Fossa 20.04 was released on Apr 23, cloud-init upstream cut a release 20.2 as well
<blackboxsw> Additionally we have two new hires to the canonical ubuntu-server team that will be participating in cloud-init, curtin and ubuntu-advantage-tools projects
<blackboxsw> We are really excited to have some extra hands on cloud-init from lucasmoura and falcojr. So welcome gentlemen, glad to have the help.
<blackboxsw> They just started yesterday and are going through a bit of onboarding this week, but expect to see them around in cloud-init shortly. I believe they have both landed their first PRs to get added as a contributor to cloud-init.
<blackboxsw> #topic In-progress Development
<blackboxsw> #link https://github.com/canonical/cloud-init/pulls
<blackboxsw> ok active review queue is really getting well maintained now that we've adopted PR assignment. Thanks for helping is land branches quickly folks.
<blackboxsw> Generally upstream has set a couple of long-term goals for cloud-init in the next development cycle
<blackboxsw> - wrap up cloud-init daemon mode (to reduce boot time by loading python only once)
<blackboxsw> - OpenStack network hotplug handling from cloud-init
<blackboxsw> - Potentially a new LXD datasource for handling container deployments
<blackboxsw> - better json schema coverage for the remaining oncovered cloud config modules.
<blackboxsw> #topic Community Charter
<blackboxsw> We continue to categorize more bitesize bugs in cloud-init.
<blackboxsw> #link  https://bugs.launchpad.net/cloud-init/+bugs?field.tag=bitesize
<blackboxsw> These bugs are themed at doc updates and json schema improvements across all of cloud-init, but we continue to seed that bug tag with items which should be easy to drop in and make a lasting impact on cloud-init
<blackboxsw> All cloud-init contributors are encouraged to participate in any part of the cloud-init lifecycle, from bug filing, to fixing, to release testing and PR reviews. Thanks to everyone who continues to build the cloud-init community!
<blackboxsw> #topic Office hours (next ~30 mins)
<blackboxsw> During this stage we have a some focus time on cloud-init development and community support. Any questions, concerns, reviews or request for help/triage are most welcome. We should have a couple of upstream developers with eyes on this channel.
<blackboxsw> In the absence of discussion, we'll groom the active PR review queue and/or work additional cloud-init dev items.
<blackboxsw> community-notice: Ubuntu plans  to release cloud-init version 20.2 to Ubuntu's new development release 20.10 (Groovy Gorilla). We expect to start an Ubuntu StableReleaseUpdate into xenial, bionic, eoan and  focal within the next 2 weeks.
<blackboxsw> alrighty, think that about wraps today's status meeting. Happy Cinco De Mayo folks
<blackboxsw> #endmeeting
<meetingology> Meeting ended Tue May  5 17:34:01 2020 UTC.
<meetingology> Minutes:        http://ubottu.com/meetingology/logs/cloud-init/2020/cloud-init.2020-05-05-16.16.moin.txt
<meena> groovy gorillaâ¦ is a good name.
<ausfestivus> Morning @odd
<ausfestivus> Morning Odd_Bloke, yes its the default Azure 1804LTS image.
#cloud-init 2020-05-06
<AnhVoMSFT> Odd_Bloke I am running into this weird pylint error
<AnhVoMSFT> ************* Module cloudinit.tests.test_conftest
<AnhVoMSFT> cloudinit/tests/test_conftest.py:14: [E1120(no-value-for-parameter), TestDisableSubpUsage.test_typeerrors_on_incorrect_usage] No value for argument 'args' in function call
<AnhVoMSFT> it does not happen if I checkout to my local box and run tox, but somehow in our build server it's throwing this error. I've cross-checked the versions of the modules and they seem to match. Do you have any idea on top of your head why I might be seeing this?
<Odd_Bloke> Technically it's correct, we are intentionally calling the function without that necessary parameter.
<Odd_Bloke> But I don't know why we aren't seeing it consistently.
<Odd_Bloke> AnhVoMSFT: Does your build server not use tox?
<Odd_Bloke> ausfestivus: Hmm, interesting; what's the serial in /etc/cloud/build.info?
<AnhVoMSFT> Odd_Bloke it does use tox, which is why it has been puzzling me
<AnhVoMSFT> it runs the whole test in a xenial container (I don't think it would make a difference. I did try to run the whole thing in a xenial container but also did not reproduce the issue)
<Odd_Bloke> AnhVoMSFT: Could you paste the full tox log for a failing run?
<AnhVoMSFT> @Odd_Bloks https://pastebin.ubuntu.com/p/QMkhNtShjW/
<AnhVoMSFT> @Odd_Bloke https://pastebin.ubuntu.com/p/QMkhNtShjW/
<AnhVoMSFT> we're running "tox -e py3 -e xenial -e pycodestyle -e pyflakes -e pylint" in the build server but the very same command doesn't fail in my dev box
<lucasmoura> Hi everyone, I am working creating a schema for cc_apt_configure, similar to what we have in other config modules such as cc_ubuntu_drivers. However, I don know how to properly handle the description we already have. Right now, it describes the all of the parameters the config accepts
<lucasmoura> Should I add the entire text under the description key of the schema dict or should I break it down by property and just add an overall description for the description key ?
<rharper> lucasmoura: have you looked at some of the other modules with schemas?  cc_ntp.py  ;
<rharper> lucasmoura: I think you'll end up including much of the docs around the elements of the schema, and look at cc_runcmd.py, it pushed the examples into an 'examples'  parameter; and then we use get_schema_doc() to convert to docstring
<lucasmoura> okay, I will take look at them. Thanks rharper
<rharper> lucasmoura: and you can use tox -e docs to render the output to see how its looking,  checking https://cloudinit.readthedocs.io/en/latest/topics/modules.html#runcmd
<lucasmoura> cool, thanks again rharper :)
<Odd_Bloke> lucasmoura: Also `cloud-init devel schema -d cc_runcmd` will emit the documentation markup for cc_runcmd, which can be useful for iterating so you don't have to do a full doc run.
<Odd_Bloke> Is the job log on https://travis-ci.org/github/canonical/cloud-init/jobs/683892541 failing to load for anyone else, or is it just me?
<Odd_Bloke> (I forgot that restarting the job would wipe out the previous log (or lack thereof), oh well.)
<Odd_Bloke> OK, pushing a completely new commit also doesn't fix it, so I'm going to leave that for a while and assume we'll see a Travis outage notification before too long. :p
<Odd_Bloke> rharper: blackboxsw: lucasmoura: falcojr: smoser: I'm working on some more unit testing docs, and I'd like us to standardise the module-level constant we use in test modules for the prefix for the module under test (e.g. https://github.com/canonical/cloud-init/blob/master/cloudinit/sources/tests/test_oracle.py#L19).  https://paste.ubuntu.com/p/wBx3mcG5Fj/ is a rough list of the ones we use currently.  I'd
<Odd_Bloke> like to suggest we standardise on M_PATH in general, with an exception for DS_PATH in datasource tests.  What do you think?
<lucasmoura> Odd_Bloke, No problem for me
<rharper> Odd_Bloke: +1 on M_PATH ,  did we also standardize on the attribute name? m_<how verbose should this be?> m_util_subp?  m_config_cc_ntp_util_subp  ?
<blackboxsw> lucasmoura: good work on https://github.com/canonical/cloud-init/pull/348#pullrequestreview-406931356
<blackboxsw> I'm +1, awaiting CI
<blackboxsw> falcojr: that approach might also relate to your work on https://bugs.launchpad.net/cloud-init/+bug/1876414 too
<ubot5> Ubuntu bug 1876414 in cloud-init "testing: add unittest performing schema validation of example cloud-config in doc/ *.txt" [Undecided,Triaged]
<falcojr> what do you mean by approach?
<blackboxsw> falcojr: ohh I mean that if you are adding unit tests that involve json schema we probably need to use the @skipUnlessJsonSchema decorator
<blackboxsw> so unit tests will succeed on all distros. (some of which won't have Json schema)
<falcojr> ahh, gotcha. Yeah thanks for the heads up. I think that can remove my file filter
<Odd_Bloke> rharper: We do have the m_ prefix standardised (right above https://cloudinit.readthedocs.io/en/latest/topics/hacking.html#type-annotations).
<rharper> Odd_Bloke: excellent
<falcojr> why do we need an import check for jsonschema in our tests?
<falcojr> jsonschema is in requirements.txt...is there somewhere that tests run that doesn't install requirements.txt?
<Odd_Bloke> falcojr: The unit tests are run as part of the Ubuntu package builds (and hopefully other package builds) against the Python packages installed in the test system via debs.  xenial does not have the jsonschema dependency.
<Odd_Bloke> (At least xenial, I just know that one for sure because lucasmoura and I happened to look at that patch during our conversation yesterday. :)
<blackboxsw> falcojr: in cloud-init we have some dependencies that are considered optional runtime dependencies. If not present we have try/except ImportError blocks that handle graceful feature-disabling if the module isn't available
<falcojr> interesting...thanks!
<blackboxsw> the other python module which are not a hard/firm requirement are: cheetah (cloudinit/templater.py)  oauthlib.oauth1 (cloudinit/url_helper.py)  and I thought there was something else
<lucasmoura> Does anyone know if it is possible to share a property in a local jsonschema ? For apt_configure, primary and security have the same config variables, so I thing it is best to define them once and reuse them on both fields. I was taking a look at ref, but since it is a python module, I think the pointer does not work properly...
<blackboxsw> my fgrep-fu is not showing me the other "optional" runtime dependency
<Odd_Bloke> pyserial.
<Odd_Bloke> Jinja2 is also optional.
<blackboxsw> thanks Odd_Bloke right, forgot about jinja and lumped that in my head with jsonschema :/
<blackboxsw> Odd_Bloke: did we create a card or bug to better document cloudinit dependencies (hard vs 'soft')
<blackboxsw> I thought we just talked about this
<Odd_Bloke> blackboxsw: I have a post-it on my desk to do so, does that count? :p
<blackboxsw> yes, yes I can see that clearly from the nanny cam I just had installed at your house. #countit
<blackboxsw> merged https://github.com/canonical/cloud-init/pull/348 lucasmoura thanks!
<lucasmoura> blackboxsw, great :)
<blackboxsw> lucasmoura: I just manually added https://bugs.launchpad.net/cloud-init/+bug/1876412/comments/1 now that your branch merged and Fix Commited the bug https://bugs.launchpad.net/cloud-init/+bug/1876412/comments/1
<ubot5> Ubuntu bug 1876412 in cloud-init "testing: add unittest coverage for config module json schema examples" [Medium,Fix committed]
<lucasmoura> Thanks blackboxsw :)
<blackboxsw> at some point lucasmoura and falcojr we'd probably like to extend our github automation to maintain launchpad bugs automatically on our behalf (like a cron job in travis or github action)
<blackboxsw> just FYI so we don't have to manually maintain bugs in launchpad at some point
<lucasmoura> makes sense
<Odd_Bloke> I've opened myriad PRs today, BTW, I've been working through a backlog of papercuts.  Reviews much appreciated!
<falcojr> I get errors building pyyaml when running tox...any obvious answers?
<falcojr> bah, nevermind. My mental model of tox is broken. I thought it used its own virtualenvs for everything, but I get different results when running in a virtualenv
<Odd_Bloke> falcojr: I've just reviewed #355, thanks for the PR!  As I say in the PR, I think this test would work well as a parameterised test.  Would you like to setup some time tomorrow to pair on converting it?
#cloud-init 2020-05-07
<falcojr> I've done test parametrization before. I see tradeoffs both ways and could go either way for this. I usually think of parametrization for when you start accumulating very similar individual tests (e.g., test_x_less_than_0, test_x_greater_than_0, test_x_equal_0), and need an abstraction to reduce code duplication.  In this case, I would never think
<falcojr> to write "test_file_x", "test_file_y", "test_file_z", so to me I think of this as a single test...test all the examples. But like I said, I could go either way, so if there's a strong preference for paramterization, I can do that. Just let me know
<Odd_Bloke> falcojr: Interesting, I think I see it differently for a couple of reasons.  Firstly, I think, as-written, the for loop _is_ parameterising this test already: it's running an identical validation test with different parameters for each iteration of the for loop.  So for me that meets the "very similar individual tests" standard.  And secondly, if I'm making changes to our schema validation code or our
<Odd_Bloke> schemas, I would like to have a granular indication of which examples I've broken with my changes but the current test will fail on the first failure it finds.  You could update the current test to gather all errors before it fails the test, but that's effectively reimplementing a test runner in a way that's opaque to our actual test runner, so we may as well use the features it provides us.
<falcojr> Odd_Bloke makes sense, I'll parametrize it
<Odd_Bloke> falcojr: Thanks! :)
<Odd_Bloke> (I just misspelled schema as schma, and that's a fun word to say.)
<falcojr> https://vignette.wikia.nocookie.net/disney/images/6/6f/Mr._Smee_Profile.jpg
<Odd_Bloke> falcojr: Thanks for the update on the PR, I've pushed another couple of (minor) comments. :)
<Odd_Bloke> (Regrettably with schema spelled correctly.)
<blackboxsw> robjo: if you have a moment, do you have any concerns with switching the default localhost IP to 127.0.1.1 on suse in cloud-init, just like debian and ubuntu? chengcheng from vmware land would like to make that change in cloud-init https://github.com/canonical/cloud-init/pull/336
<blackboxsw> the branch looks sounds, and the IP address is accessible on a couple of opensuse containers I've launched but I wasn't certain if there are any specific concerns on OpenSUSE side that I should be cognizant of before reviewing and landing this branch
<robjo> blackboxsw: LGTM, commented on the PR
<blackboxsw> awesome robjo thanks for the quick turnaround here
#cloud-init 2020-05-08
<blackboxsw> Odd_Bloke: pushed a manual ubuntu/devel PR https://github.com/canonical/cloud-init/pull/339
<Odd_Bloke> blackboxsw: Thanks!  I'll review this with falcojr later today.
<Odd_Bloke> blackboxsw: I'll rereview the groovy upload on Monday; we've already seen a couple of issues, so I want to make sure I'm approaching it with fresh eyes.
<blackboxsw> understood Odd_Bloke have a good one whenever EOW is
<blackboxsw> #the issues of doing things manually
<blackboxsw> as it were
<Odd_Bloke> ^_^
<Odd_Bloke> falcojr: Just landed https://github.com/canonical/cloud-init/pull/355, congrats! \o/
<blackboxsw> lucasmoura: just finished review on https://github.com/canonical/cloud-init/pull/357
<blackboxsw> good work, we can chat Monday
<blackboxsw> nice falcojr !!
