#cloud-init 2013-10-28
<iwi> hi there, any ideas why cloud-init doesn't resize / on OEL. cloud-init and cloud-utils are installed from EPEL, resize_rootfs is set to true, and resizefs is specified under cloud_init_modules section
<iwi> OEL 6.4, cloud-init is 0.6.3-0.12.bzr532
<smoser> iwi, it could be https://bugs.launchpad.net/ubuntu/+source/cloud-utils/+bug/1244662
<smoser> but i've never seen that bug.
#cloud-init 2013-10-29
<harlowja> smoser on linkedin it asked me the question 'Do u know if scott moser is good with RHEL'
<harlowja> i was like, should i click this or not, haha
<harlowja> *should i click yes/no
<harlowja> haha
<smoser> i did spend 9 months once working on RHEL.
<smoser> i have code in RHEL 5 and probably RHEl 6
<smoser> :)
<harlowja> nice
<smoser> the good thing about RHEL is you can do something, and then 10 years later you can say
<smoser> "i have code in the latest RHEL release"
<smoser> :)
<kwadronaut> lol
<kwadronaut> typo's in manuals are also an easy one to get in a lot of software projects ;-)
<harlowja> hahaha
<harlowja> more like 20 years
 * harlowja sad that i have to use RHEL
<harlowja> haha
#cloud-init 2013-10-31
<systest> Anyone have a pointer to a doc describing what the arguments to cloud-init do?  specifically, what section of the config us parsed when "init --local" is used?
<kwadronaut> systest: http://cloudinit.readthedocs.org/en/latest/ 
<kwadronaut> no-cloud datasource iirc
<kwadronaut> i hope now you have enough reading materials until someone else pops by in irc to better help you ;-)
<systest> thanks. I've seen those docs, just missed that section.  I'll check it out now.
#cloud-init 2013-11-01
<Dr_Memory> so once upon a time, I had a multipart mime cloudinit script in ec2 userdata that worked just fine on both lucid and precise: http://pastebin.com/8WPmCmAQ
<Dr_Memory> on saucy, however, it appears to do... nothing.
<Dr_Memory> the log output on saucy: http://pastebin.com/PY2jeRSk
<Dr_Memory> the text/cloud-init section of the mime blob does not seem to have been written out anywhere under /var/lib/cloud, which I'm guessing is the problem?  But it's unclear to me why.
<Dr_Memory> any pointers, even if to the relevant sections of TFM, would be appreciated. :)
 * Dr_Memory drops a pin :)
<kwadronaut> sssht! in the changelog i see one -maybe- relevant piece touched between precise and saucy, might want to have a closer look at https://bugs.launchpad.net/cloud-init/+bug/1065116
<kwadronaut> this channel isn't very active, btw, patience helps. or a bug, mail, ..
<Dr_Memory> kwadronaut: thanks.  I realized after pin-dropping that most ppl here were on the plus side of GMT, so I will be patient. :)
<Dr_Memory> (also not sure 1065116 is relevant on first blush -- I don't see a KeyError anywhere in cloud-init.log)
<kwadronaut> I took that pin and threw it in a haystack. but you're probably right, wrong guess of me.
<harlowja> also i think that smoser and i will be travelling soon to, so it might get even more quiet
<harlowja> Dr_Memory i'd be useful to know whats in /var/lib/cloud/instances/i-fa2e879e/user-data.txt
<harlowja> if u want to share
<Dr_Memory> harlowja: just a sec
<harlowja> the debug logs look ok, just as u said, not seeing any mime writing really
<harlowja> or much other file writing
<harlowja> which seems off
<smoser> Dr_Memory, it doen't look terribly unreasonable.
<Dr_Memory> harlowja: just a sec
<Dr_Memory> http://pastebin.com/WwDY5MTZ
<Dr_Memory> (I've been fiddling a bit and this is a new instance from the last one I tried, but the behavior has been the same.
<Dr_Memory> )
<smoser> user-data.txt.i
<Dr_Memory> (possibly of note: there is no newline at the end of the last mime header there?)
<Dr_Memory> ls: cannot access /var/lib/cloud/instance/user-data.txt.i: No such file or directory
<smoser> Dr_Memory, /var/log/cloud-init.klog
<smoser> s/klog/log
<harlowja> ya, the full contents of that log file should give us the dirty details
<harlowja> *or not so dirty
<Dr_Memory> just a sec :)
<Dr_Memory> the log: http://pastebin.com/BTjQw2Vg
<Dr_Memory> or rather, that's the log from the last reboot -- if you like I can spawn a new instance and get a clean log
<Dr_Memory> I tried, in desperation, putting the "cloud_final_modules:" stanza into /etc/cloud/cloud.cfg.d/99_final.cfg (and then rm -rf /var/lib/cloud; reboot), which is why you see it referenced in the logs there.
<utlemming> smoser: just pinged you privately
<harlowja> np dr. a clean instance log might be the best i think
<Dr_Memory> harlowja: figured.  on moment, por favor :)
<Dr_Memory> (cloudformation is thinking... thinking... thinking...)
<harlowja> more thinkin
<Dr_Memory> (AWS gears grind slowly, but they grind exceedingly... slow.)
<Dr_Memory> okay, virgin log: http://pastebin.com/FrpZp8ir
<Dr_Memory> user-data.txt still the same.  user-data.txt.i still nonexistent.
<harlowja> damn, who put all this merging logs, hahaha
<harlowja> :-/
<harlowja> like it seems to be doing stuff
<harlowja> is https://org.blank.bootstrap.s3.amazonaws.co ok?
<harlowja> not sure what thats supposed to return for u
<Dr_Memory> yeah, I can manually grab that URL with curl/wget
<Dr_Memory> it returns a #!/bin/sh file
<harlowja> k
 * harlowja scanning codes
<Dr_Memory> like so: 
<Dr_Memory> http://pastebin.com/kififAdN
<harlowja> sure
<Dr_Memory> huh.  I wonder if some library got more strict about certificate alt name validation between precise and saucy?
<Dr_Memory> although there's nothing in the cloudinit log to suggest that fetching that url failed
<harlowja> ya
<harlowja> it seems to have worked, although it didn't write out the right file
<harlowja> what does 'ls /var/lib/cloud/instance/' show?
<harlowja> or 'find  /var/lib/cloud/instance/'
<Dr_Memory> holy shit
<Dr_Memory> I just s/https/http/
<Dr_Memory> ...and it worked
<harlowja> hmmmm
<Dr_Memory> *facepalm*
<harlowja> if u also try #include-once this will write out a file
<harlowja> that file writing should showup in the log
<harlowja> just #include just loads it into memory
<harlowja> *no log
<Dr_Memory> ah, interesting
<harlowja> although ssh/not ssh is odd
<harlowja> *https/not https
<harlowja> (brainfart)
<Dr_Memory> well, S3 signed urls are kinda special
<Dr_Memory> they end up being https://bucketname.s3.amazonaws.com/
<harlowja> hmmm
<Dr_Memory> and if your bucketname has dots in it: https://bucket.name.s3.amazonaws.com/
<Dr_Memory> which doesn't match their wildcard cert
<harlowja> hehe, u out of my area of expertise :-P openstack doesn't have these ;)
<Dr_Memory> is this worth a bug report?
<harlowja> smoser what do u think
<Dr_Memory> arguably "don't provide https include urls to sites that don't provide a correct certificate" is a "doctor it hurts when I do this" issue 
<harlowja> it does seem like odd behavior
<Dr_Memory> but the logging could definitely have been better in this case :(
<harlowja> def
<Dr_Memory> and the behavior is, if not a regression, certainly a change
<harlowja> ya, we switched to using the requests library, which is more strict about this stuff
<harlowja> although i would have expected some log to
<harlowja> i'd be fine with a bug, but smoser might think otherwise
<harlowja> http://www.python-requests.org/en/latest/
<smoser> what was the issue there ?
<smoser> you effectively had an invalid cert ?
<Dr_Memory> smoser: not 100% sure, but when I changed the #include url from https://org.blank.bootstrap.s3.amazon.com/ to http:// suddenly everything just worked.
<Dr_Memory> and yes: amazon has a wildcard cert for *.s3.amazonaws.com but wildcard certs AFAIK can't cover sub-subdomains.
<smoser> the can i think
<smoser> it'd seem like possibly a bug in python-requests
<smoser> or possibly its doing the right thing
<smoser> i'm not sure.
<Dr_Memory> yeah
<Dr_Memory> if nothing else, I feel like the log should have told us a bit more about what was going on
#cloud-init 2014-10-27
<andrewhsu> smoser: i hear cloud-init is being migrated to github. is this so? iâd love for that to happen. :)
<harlowja> andrewhsu https://github.com/cloud-init/ is the start, i'm not sure the current delay though, smoser  hopefully knows ;)
<andrewhsu> i have stuff iâd like to send as pull request. i know git but iâm not familiar with bzr.
<andrewhsu> (iâd prefer git)
<smoser> andrewhsu bzr isn't terribly difficult. 
<smoser> sometime in the not-too-distant fugure we'll have some plan for taking requests on github i thikn
<smoser> that may or may not be "source code is hosted in git".
<andrewhsu> how can i help?
<andrewhsu> i work with josh harlow at yahoo
<harlowja> :-P
<andrewhsu> for better or for worse
<harlowja> ha
<harlowja> *worse!
<hiren_> +1 
<hiren_> hah
<hiren_> hey andrewhsu!
<andrewhsu> wassup
<hiren_> not sure how happy harlowja is after inviting us in this chan now :D
<harlowja> ha
<hiren_> harmw: I see not action on https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194295 - want me to poke marino? 
<hiren_> (wanted to ask you before I go and do that)
<smoser> i do !
<smoser> :)
<hiren_> heh
<hiren_> k
<smoser> hiren_, can you confirm my understanding that there are no "official cloud" images for freebsd ?
<hiren_> smoser: So, freebsd release eng team is working closely with a bunch of "cloud" folks and are working on creting *official* images.
<hiren_> whatever we have is not tagged official right now.
<hiren_> aws, microsoft and couple more I think.
<harmw> hiren_: go ahead :)
<harmw> ah, he's not online though
<andrewhsu> smoser: is the desire to move everything to github or have a read-only github mirror of launchpad? or a sync back and forth so changes could be submitted to either launchpad or github?
<hiren_> harmw: yeah, I'll see if I can get someone else to pick it up. 
<smoser> fwiw, 5 years ago, i used only git, and other than being 5 years since daily use, i mostly prefer it to bzr.
<smoser> bzr does do merges better.  you dont have to keep  squashing commits 
<smoser> rather you can commit commit commit on your branch, and then when you merge have a single commit and the commit/commit/commit are still readable 
<smoser> hiren_, so what would I / we need to do from a cloud-init perspective if we wanted cloud-init in the images ?
<smoser> and would there ever be a downloadable image like ubuntu's or fedora's ? 
<smoser> ie, what i'd get at http://fedoraproject.org/en/get-fedora#clouds
<harmw> probably poke someone from the designated workgroup
<smoser> http://cloud-images.ubuntu.com/
<harmw> to add the ci pkg to it
<harmw> official images would probably go live on cloud.freebsd.org or somthing :p
<harmw> hiren_: enlighten us :p
<harlowja> andrewhsu https://etherpad.openstack.org/cloud-init-next 
<harlowja> please add to there :)
<harlowja> andrewhsu https://etherpad.openstack.org/cloud-init-next
<harmw> https://svnweb.freebsd.org/ports?view=revision&revision=371603
<hiren_> harmw: woho! good stuff. 
<hiren_> smoser: harmw : wrt cloud images, let me talk to the RE folks and get you some sensible answer. (rather than random bullshit that I make up ;))
<harmw> :>
<harmw> do thy gather somewhere public?
<harmw> if so I'll be happy do talk to them myself
<smoser> hiren_, if we insisted that people in this channel did not spout random $*#% then we'd not allow harlowja here.
<harmw> :>
<hiren_> hah
<hiren_> harmw: not really
<hiren_> so we do pushout something like tihs right now: ftp://ftp.freebsd.org/pub/FreeBSD/releases/VM-IMAGES/10.1-RC3/amd64/Latest/FreeBSD-10.1-RC3-amd64.qcow2.xz
<smoser> is that linked anywhere ?
<harmw> ah yea, I remember having seen that before
<smoser> other than ftp://ftp.freebsd.org/pub/FreeBSD/releases/VM-IMAGES/10.1-RC3/amd64/Latest/
<smoser> :)
<hiren_> linked?
<hiren_> smoser: you want freebsd project to explicitly say we support cloud-init? 
<harmw> hiren_: those images need to be respun with c-i :)
<hiren_> yes.
<hiren_> harmw: true. 
<smoser> right.
<smoser> thats what i want.
<harmw> +1 on that, yes
<hiren_> so, what exacly we wnat in the "respin" ?
<hiren_> install the port... and..?
<harmw> and nothing
<harmw> :)
<hiren_> hah
<hiren_> okay
<smoser> i suspect that there is work necessary in cloud-init to make more stuff work and better.
<smoser> for sure. and i'm ok with that.
<harmw> for sure
<smoser> i'm saying from a cloud-init upstream project perspective, i'd like to have cloud-init in "official freebsd images" (and official images of any OS that we can).
<hiren_> so, for now, if we just install the port we just committed and get the qcow2, that'd be enough?
<harmw> but the current stuff can handle configdrive, ssh and sudo, growing disks, so the basics are covered
<smoser> that will help me in my diabolical scheme to acheive world domination.
<hiren_> heh.
<harmw> hiren_: important little detail
<harmw> c-i must be manually enabled in /etc/rc.conf
<harmw> else it won't run on boot 
<hiren_> harmw: the port install doesn't do that, right?
<harmw> nop
<harmw> should it do that?
<hiren_> harmw: can you please list down exact things evenif they are just : 1) install the port 2) enable rc.conf
<harmw> given its nature, perhaps it should though...
<hiren_> hum, we dont do that.
<harmw> nah thought so
<harmw> hence I didn't make it do that
<hiren_> after installing the service via port, users have to enable them.
<hiren_> so thats okay
<hiren_> expected.
<hiren_> harmw: cool.
<harmw> step1: install port, step2: enable in /etc/rc.conf
<harmw> smoser: there is a thread on openstack-dev regarding support for/on freebsd compute nodes
<harmw> maybe someone should let those guys know the instance part is covered now as well :)
<harmw> alright, time to head back to my recently upgraded Juno-cloud to fix networking - like, again
<hiren_> I am talking to the superawesome RE guy from FreeBSD to integrate this stuff and comeup with a openstack cloud image on official freebsd page.
<harlowja> random bs; what u say, lol
<harlowja> ha
<hiren_> dude. I do that all the time. So easy with carefully selected buzzwords.
<harlowja> :-P
<smoser> cloud!
<harlowja> lol
<harlowja> smoser plan for world domination being discovered
<harlowja> not so secret anymore
<harmw> harlowja: you do realize your kinda like Pinky now, right
<harlowja> :(
<harlowja> u pinky
<harlowja> lol
<harmw> :p
<smoser> i have 2 pinkies!
<harlowja> http://www.wearyourbeer.com/images/Pinky_Brain_To_Do_List_Gray_Shirt.jpg :-P
<harlowja> i guess i should get that shirt, haha
#cloud-init 2014-10-28
<j12t> There seems to be a update_etc_hosts. How does it work? Can't find a description in the docs... I'd like to add a line to that file.
<harlowja> j12t i'm working on some docs of all that stuff, its the start @ https://code.launchpad.net/~harlowja/cloud-init/start-module-docs
<harlowja> additions welcome
<j12t> My python is basically non-existent ... do I see this correctly that I cannot actually add an arbitrary line to /etc/hosts via update_etc_hosts?
<j12t> The only thing I can do is get a template file filled in, with current hostname and fqdn?
<j12t> harlowja: my problem is that I don't really understand how it works!
<harlowja> hmmm
<j12t> I did write down something that may or may not have any place in the docs: http://indieboxproject.org/blog/2014/10/virtualbox-and-cloud-init/
<harlowja> update_etc_hosts is python code, so its not likely so easy to just add arbitrary lines to things, unless that python code understands how to honor whatever u want it to write
<harlowja> http://bazaar.launchpad.net/~cloud-init-dev/cloud-init/trunk/view/head:/cloudinit/config/cc_update_etc_hosts.py#L29 is the code that is doing this
<harlowja> its nothing so special
<harlowja> time to learn python ;)
<j12t> I know!
#cloud-init 2014-10-29
<smoser> JayF, bah to you
<smoser> -    if not cfg or not 'output' in cfg:
<smoser> +    if cfg or 'output' not in cfg:
<smoser> and bah to me for not seeing that.
<JayF>  I tried to find more places that was effed after the first thing with fbsd
<JayF> must have missed that one
<JayF> bah to me
<smoser> so the fallout is utopic instances right now do not have /var/log/cloud-init-output.log 
<smoser> sorry for sounding rude above.
<harlowja> bah to u!
<harlowja> lol
<harlowja> bah humbug
<harlowja> ha
<smoser> filed and fixed at bug https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1387340
<harlowja> cool, i might have to pull that one down
<harlowja> lets see if people notice, i think we are adjusting the logging anyway so might not matter
<harlowja> smoser ok if i merge https://code.launchpad.net/~harlowja/cloud-init/start-module-docs ?
<harlowja> or u want to (if u don't have enough time i can )
<harlowja> then i can rebuild the readthedocs page (or trigger it to happen)
<smoser> i think you cannot do that harlowja . i had thought you had commit access.
<smoser> harlowja, how do i  make doc ?
<harlowja> u killed commit access, ahhh, haha
<harlowja> readthedocs.org; i think u have acceess to press the rebuild button
<harlowja> its not so dynamic from bzr
<harlowja> from git i believe they can trigger automatically
<harlowja> let me see if i can trigger
<harlowja> k, seemed like it worked http://cloudinit.readthedocs.org/en/latest/topics/modules.html active
<harlowja> smoser ^
<harlowja> hmmm, although didn't work all the way, will figure out; seems to have lost some of the docs, lol
<harlowja> not sucking in the ones from the modules itself
<smoser> :)
<smoser> harlowja, how do you make doc locally?
<harlowja> magic!
<harlowja> get into `cloud-init/doc/rtd`
<harlowja> sphinx-build . $output_dir
<harlowja> where outputdir will be the output
<harlowja> folder and such with the html
<harlowja> arg, ya, https://readthedocs.org/builds/cloudinit/1810005/  
<harlowja> seems like it needs the requirements installed, and that killed the code inclusion
<harlowja> lets see if i can fix that without a patch
#cloud-init 2014-10-30
<harlowja> hmmm, seems not, lol
<harlowja> it needs to be able to run setup.py install in a virtualenv (which for us is currently non-standard, using datafiles which it can't write...)
<harlowja> fixing that
<harlowja> https://code.launchpad.net/~harlowja/cloud-init/setup-virtualenv-installable/+merge/240069 should do the trick (this allows readthedocs to make a virtualenv which won't be missing the requirements it needs to build the full docs)
<dmick> hi all; this may be a dumbfaq, but I'm having real trouble finding it: is there a way to, preferably with a kernel boot arg, stop cloud-init from running on boot so that I can observe state before it runs, and run its phases by hand?
<gchristensen> Hi, I'm looking to have an upstart job run after cloud init has finished. it seems there have been numerous events to "start on stopped ____" over time. I'm running Ubuntu 14.04, anyone know what event I should be watching for? 
<Wumpus42> I'm using cloud-init 0.7.4 in a centos 6.5 image I made for a Icehouse cloud we've setup to mess around with. I can get cloud-init to execute shell scripts in the user_data, but I can't get the #cloud-config to work. I don't get any errors, the actions just dont happen. Is there something I have to turn on in the image cloud-init config to have it act on the cloud-config userdata items?
<harlowja> Wumpus42 do u have an example yaml u are sending, or any cloud-init logs?
<harlowja> dmick there isn't a kernel arg afaik that stops cloud-init from doing things
<harlowja> smoser when u leaving for paris?
<smoser> harlowja, saturday night.
<harlowja> cool
<harlowja> sat morning for me 
<smoser> arrive sunday. 
<smoser> are you speaking ?
<smoser> sunday i'm paying wrokingon talk 
<smoser> as i am right now too
<smoser> no reason in being ready early
<harlowja> speaking, no direct speaking, a few summit sessions; but those aren't really speaking :-P
<harlowja> no like presenations i mean
<harlowja> u?
<Wumpus42> yes. i will get an example
<harlowja> Wumpus42 cool
<harlowja> that will help diagnois whats happening
<harlowja> smoser are u gonna talk about cloud-init or something, lol
<smoser> containers
<smoser> http://www.openstack.org/vote-paris/Presentation/ecure-containers-in-openstack-using-lxc-and-user-namespaces
<harlowja> ah
<harlowja> cool
<harlowja> i'll try to be there!
<hiren_> smoser: looks like an interesting talk. Would these be recorded?
<harlowja> hiren_ they typically are
<harlowja> the design summit sessions (which are developers blabbering at each other aren't recorded)
<harlowja> ^ thankfully those aren't recorded, haha
<hiren_> hah yeah
<hiren_> you do not want the world to see your yelling... I get that part.
<harlowja> ;)
<hiren_> and dev only sessions are hardly civilized anyways. ;-)
<smoser> hiren_, yeah, it will be
<Wumpus42_> Here's my simple #cloud-config
<Wumpus42_> #cloud-config
<Wumpus42_> package_upgrade: true
<Wumpus42_> power_state:
<Wumpus42_>   delay: "now"
<Wumpus42_>   mode: reboot
<Wumpus42_>   message: "Bye Bye"
<Wumpus42_>   timeout: 30
<Wumpus42_> I'm new to irc, is there a better way to paste that?
<hiren_> smoser: cool.
<harlowja> Wumpus42_ using paste.ubuntu.com would be cool
<harlowja> easier to see if its off there
<Wumpus42_> I've also tried manage-resolv-conf: true
<Wumpus42_> resolv_conf:
<Wumpus42_> ...
<Wumpus42_> ok. let me try that
<harlowja> k
<harlowja> Wumpus42_ the other thing that would be useful are the cloud-init logs
<harlowja> to see why it isn't processing those
<harlowja> typically at /var/log/cloud-init.log 
<Wumpus42_> like this? http://paste.ubuntu.com/8749657/
<harlowja> ya
<harlowja> so that looks fine
<Wumpus42_> I'll get the log. 
<harlowja> cool
<Wumpus42_> gimme a few
<harlowja> np
<Wumpus42_> i can't irc from work comp, gotta keep switching back and forth. i've got a mtg in 5mins so it might be a few mins 'til i can respond
<harlowja> k
<harlowja> np
<harlowja> take your time
<Wumpus42_> wow. mtg going long :(  Here's the logfile http://paste.ubuntu.com/8750424/
<Wumpus42_> The cloud-init was installed in the image and left with it's defaults... except I changed the user to cloud-user
<harlowja> sure
<harlowja> can u show whats in '/var/lib/cloud/instances/i-000002dd/user-data.txt.i ' 
<harlowja> also '/etc/cloud/cloud.cfg '
<harlowja> both of those would be helpful
<Wumpus42_> ok will get those too
<Wumpus42_> here's /etc/cloud/cloud.cfg http://paste.ubuntu.com/8750761/
<Wumpus42_> here's user-data.txt.i http://paste.ubuntu.com/8750782/
<dmick> harlowja: is there an easy way to boot up a pristine image but not execute the normal cloud-init path before starting a shell?  (Maybe the easiest would be to supply a user script that just starts a shell, assuming I can make that happen first?)
<dmick> (and maybe I can figure out how to fuse that into the yaml coming from the NoData ISO source by using the cc: kernel cmdline arg?)
<dmick> (or am I talking crazy?)
<harlowja> dmick it really highly depends on what image this is, most of the time cloud-init is in the init system (systemd, upstart, sysvinit) so u can't easily bypass that without causing further services to not start
<harlowja> Wumpus42_ ok, so that looks all ok, doesn't seem off or anything
<dmick> how do you typically debug?  logs?
<harlowja> ya
<harlowja> logs, console, other
<dmick> need to figure out why I'm getting almost no logging.
<harlowja> Wumpus42 the thing i do notice is that u are using 'power_state' which isn't in the cloud_final_modules module list thats in that image
<harlowja> so it won't do anything if no module is there to use it
<harlowja> that would likely be the cause
<harlowja> same with the resolve_conf module; not also listed in the 3 module sections (cloud_init_modules, cloud_config_modules, cloud_final_modules)
<harlowja> if a module isn't listed there, passing configuration in that uses the module won't do much
<harlowja> *since there is nothing that gets activated that uses the config in the first place
<Wumpus42_> ah. ok. i was going by the readthedocs information of cloud-init
<Wumpus42_> whish is v0.7.7 (which is odd since 0.7.6 is the latest code .tar.gz file availqable)
<Wumpus42_> i'll make sure the modules we're trying to use are in the cloud.cfg list?
<Wumpus42_> is there a way to tell what modules are available... what _could_ be in the list?
<Wumpus42_> would trying to use a non-implemented module cause the whole #cloud-config to fail?
<Wumpus42_> did you find an error in the log that I missed?
<harlowja> Wumpus42_ no, no error, just knowing how these things work mainly :-P
<harlowja> http://cloudinit.readthedocs.org/en/latest/topics/modules.html is being updated (slowly, it will have a more extensive description and such soon)
<harlowja> contributions welcome
<Wumpus42_> as soon as I know what I'm doing, I'll contribute. I'm still learning :)
<harlowja> kk
<Wumpus42_> thank you for your help. I'll make sure the modules I'm trying to use are enabled/available.
<Wumpus42_> maybe I'll upgrade to 0.7.6
<harlowja> Wumpus42_ sure
<harlowja> reminds me, smoser  u ok with https://code.launchpad.net/~harlowja/cloud-init/setup-virtualenv-installable/+merge/240069 if u get some time, i'll try the readthedocs build after that (hopefully then it can read the code correctly since the review makes cloud-init virtualenv installable without problems)
<smoser> harlowja, yeah. 
<smoser> harlowja, i'm planning on a "fresh start" for cloud-init-2
<harlowja> lol
<harlowja> hmmm
<smoser> and using virtual env correctly.
<harlowja> at least keep the modules ;)
<harlowja> and some other stuff, ha
<smoser> will try to keep modules
<smoser> and do them backwards compat
<smoser> but will probably have a 'handle_v2' 
<smoser> and definitely want to do DataSource searching better :)
<harlowja> an idea, instead of having module lists, probe all modules, with a probe() function on the module, and let the module decide if it should run or not (instead of having static lists)
<smoser> harlowja, yeah, but order is hard.
<smoser> the list allows me to list the order.
<harlowja> have probe return a number to :-P
<smoser> like sysvinit is easy to understand, so is this :)
<smoser> rather than declaring "wants"
<smoser> or "start on"
<harlowja> :)
<harlowja> ok, fair enough, at least a validate(conf) method though
<harlowja> ok, added more ideas to https://etherpad.openstack.org/p/cloud-init-next
<smoser> definitely validate(conf)
<smoser> and ability to run that external to cloud-init running.
<harlowja> ya
#cloud-init 2014-10-31
<Wulf> Hi
<smoser> bye bye all, see some of you in paris.
<harmw> have fun :)
<Wumpus42_> how can I tell what modules are available to put into /etc/cloud/cloud.cfg and into what section they go?
<harlowja> until http://cloudinit.readthedocs.org/en/latest/topics/modules.html is filled out better the source code tells u
<harlowja> and the examples 
<harlowja> http://bazaar.launchpad.net/~cloud-init-dev/cloud-init/trunk/files/head:/doc/
<harlowja> Wumpus42_ ^
<Wumpus42_> I found the cc_* files in the 0.7.4 source .tar.gz file, but wasn't sure how it was decided which section then went in, or what their name was. Some were obvious with the .get call
<Wumpus42_> I'll read through the source more closely.
<Wumpus42_> It looked like the /etc/cloud/cloud.cfg that comes by default in the 0.7.4 package didn't have all the modules listed. so I started looking around.
<Wumpus42_> thank you :)
 * gholms wishes he could go  :(
<harlowja> Wumpus42_ what rh shipped with 0.7.4 is likely a subset of what actually can be ran (i'm not sure why they selected certain modules over other modules)
#cloud-init 2014-11-02
<harlowja> smoser u make it?
<smoser> i'm in the paris.
<smoser> hyatt.
<smoser> you?
<harlowja> ya, same hotel
<harlowja> tired as heck though, so probably gonna go take a nap, lol
<harlowja> damn long flight :-P
 * smoser came direct from detroit
<harlowja> lucky u, ha
<smoser> there are advantages to living in a hub.
<smoser> slept probably 5 hours of 8 hour plane ride. feeling tired enough to hopefully sleep tonight.
<harlowja> woot
<harlowja> alright, bbl, maybe meetup later or something
#cloud-init 2015-10-26
<niluje> Is there a reason why cloud-init doesn't have a test_requires in its setup.py?
<smoser> niluje, not a good one. i'm a python-tools neophyte
<niluje> smoser: you are the one who packaged cloud-init?
<niluje> smoser: https://github.com/brmzkw/dyntftpd/blob/master/setup.py
<niluje> I have a basic setup.py here
<smoser> niluje, we use tox, and tox reads requirements and test-requirements
<niluje> tests_require is a nice to have, so you can run "pip install -e ." to install the packaages in editable mode
<niluje> oh
<smoser> so theres probably just some overlap in functionality
<niluje> ok great, I didn't see the tox.ini, only the Makefile and I tried to run nosetests manually
<niluje> I guess make test should install and run nose then
<smoser> niluje, its kind of in both places...
<smoser> i have 2 different thing si need to support
<smoser> a.) running and installing with ubuntu packaging (system python dependencies)
<smoser> b.) testing without installing those packages (tox)
<niluje> ok
<niluje> then adding tests_require in the setup.py seems to be a good idea :p
<natorious> smoser: been looking at cloudbase-init for reference.  Their using wmi and win32api both which are not part of stdlib.  It'd be nice to get everything working using ctypes.windll or similar
<smoser> yeah, agree.
<smoser> want as much as possible to be stdlib
<natorious> did a bit more refactoring and I think moving away from network interfaces content can be better accomplished by using a sources helper to convert that into a similar network json format.  As in data source network_config should always return the same type and structure.  If static networking is moving towards network json, for backwards compat, it should convert an interfaces content file to network json to return
<natorious> I'm gonna dive into the windows partition label detection and hopefully get something decent soon
<alexpilotti_> natorious: what is the reason why you want to avoid pywin32?
<natorious> alexpilotti: if were trying to make things as close to stdlib as possible, might as well not start w/ dependencies
<natorious> alexpilotti_: ^^
<alexpilotti_> natorious: and for networks, we are already working on the new json format, thatâs independent from pywin32 as we use ctypes for all networking stuff
<alexpilotti_> WMI wont depend on pywin32 for long
<alexpilotti_> weâre rewriting that module to avoid any COM usage
<alexpilotti_> most modern APIs dont use Win32, but WMI
<alexpilotti_> for example storage management is no entirely based on WMI, while previously was based on COM
<natorious> alexpilotti_: right.  The networking bit is for linux as much as windows.  How the datasources should handle returning either or but return the same type consistently
<alexpilotti_> there should be an abstraction, with a clear interface
<alexpilotti_> thatâs what we are doing for most stuff in cloud-init V2
<alexpilotti_> btw smoser: howâs work going on V2?
<natorious> im at a point of needing to detect configdrive partitions for v2 via datasource
<natorious> and would like to attempt using stdlib before the alternatives
<natorious> fwiw
<natorious> bbiab
<akostadinov1> Hello, I was wondering how to make cloud-init restart machine after package upgrade?
<akostadinov1> it is usually required to restart so updates take effect. Like e.g. kernel upgrades/
<akostadinov1> otherwise package upgrade is of limited help
<akostadinov1> is there any switch to request that?
<smoser> akostadinov1, in ubuntu it shoudl generally work.
<smoser> probably not supported in rpm based
<smoser> http://bazaar.launchpad.net/~cloud-init-dev/cloud-init/trunk/view/head:/doc/examples/cloud-config.txt#L16
<akostadinov1> smoser: too bad :/ running on RPM
#cloud-init 2015-10-27
 * niluje is adding some unittests for the scaleway datasource
<niluje> am I the only one who want to die when dealing with bzr?
<niluje> :(
<smoser> niluje, its not that bad. but the plan is to drop it.
<smoser> it does take a different thought process.
<niluje> smoser: if you want to take a look: https://code.launchpad.net/~castets-j/cloud-init/scaleway-unittests
<niluje> edouardb (https://code.launchpad.net/~edouardb/cloud-init/scaleway-datasource) will update its merge/pull request (whatever it is called on launchpad) tomorrow
<niluje> I tried to improve the scaleway's datasource and I added unit tests
<niluje> wow ok you can actually make a merge request from the interface, here it is: https://code.launchpad.net/~castets-j/cloud-init/scaleway-unittests/+merge/275929
<smoser> thanks
#cloud-init 2015-10-28
<openstackgerrit> Nate House proposed openstack/cloud-init: [WIP] Refactoring and addressing review comments  https://review.openstack.org/239807
<openstackgerrit> Nate House proposed openstack/cloud-init: [WIP] Adds ConfigDrive datasource.  https://review.openstack.org/234857
<openstackgerrit> Nate House proposed openstack/cloud-init: [WIP] Adds ConfigDrive datasource.  Throwing this out there for some initial feedback.  https://review.openstack.org/234857
<mwak> Hey smoser
<mwak> I just updated the PR, everything should be ok.
<smoser> mwak, will take a look. thanks.
<smoser> mwak, link ?
<niluje> smoser: https://code.launchpad.net/~edouardb/cloud-init/scaleway-datasource/+merge/274861
<natorious> I'd updated that config drive mounter decorator which should be somewhat working and looked into making similar for windows using ctypes
<natorious> with it being alot more lines than just single calls using ctypes.windll.kernel32, it might make more sense to move it into the osys.windows.OSUtil path
<natorious> but then as written, it might make more sense to have linux share a base.OSUtils of their own and have each linux distro inherit from that linuxbase.OSUtils
<natorious> still digging though
<natorious> I'd looked at moving over the util.subp method too and think its needing to be cleaned up a bit
<Odd_Bloke> natorious: I would suggest writing a new subp that does precisely what you need it to do, rather than porting over a bunch of parameters which we aren't using anywhere.
<natorious> Odd_Bloke: think so too.  Last week someone had mentioned pull it from 0.7 but it seems better to pull ideas from
<elro> Is cloud-init responsible for bringing up network interfaces on Ubuntu running on ec2? The Wily images are not currently working on c4 instances as the network interface does not come up. More info in this thread: https://forums.aws.amazon.com/thread.jspa?messageID=682962
<smoser> elro, cloud-init does not bring them up
<smoser> they come up as part of normal boot due to /etc/network/interfaces
<smoser> thank you for reporting, i'll forward along.
<elro> smoser: I reported it as https://bugs.launchpad.net/ubuntu/+bug/1510345 but was not sure which package to associate it with
<smoser> i'll triage. thank you.
<smoser> pllease feel free to ping me if you ever see something like that
<smoser> also utlemming or rcj would be good if i'm not listening
<elro> thanks
<elro> Looks like https://bugs.launchpad.net/cloud-init/+bug/1449318 is still a problem on 15.10. When the runcmd errors the power-state-change does not take effect and the instance is not powered off.
#cloud-init 2016-11-01
<NuxRo> hi guys, I am trying to move configuration from scripts to cloud-init, in this case creating a swap file. Could anyone tell me what is wrong with my config file? https://paste.fedoraproject.org/467184/99307814/raw/
<NuxRo> because no swap is produced
<NuxRo> cloud-init 0.7.8-1-g3705bb5-0ubuntu1~16.04.3
<smoser> NuxRo, that "works for me" here. in a quick test.
<smoser> NuxRo, can you pastebin /var/log/cloud-init.log ?
<NuxRo> smoser: sure, https://paste.fedoraproject.org/467252/47800466/raw/
<smoser> hm.
<smoser> that seems sparse.
<smoser> cat you run:
<smoser>  sudo cloud-init single --name=mounts --frequency=always
<smoser> and paste that again ?
<NuxRo> smoser: there you go https://paste.fedoraproject.org/467255/4929147/raw/
<NuxRo> it complains about data source, but I do have it defined https://paste.fedoraproject.org/467257/14780050/raw/
<smoser> NuxRo, well, it didnt find one... normally it'd find one and cache it to /var/lib/cloud/instance/
<smoser> i have to run now. i can poke a bit later, where is this running ?
<NuxRo> some cloudstack cloud in germany, can't disclose
<NuxRo> thanks for the help
<NuxRo> smoser: found the problem, pebkac as usual, template was generated on kvm, but booted on xen, NIC device naming got messed up. biosdevname=0 net.ifnames=0 to the rescue
<NuxRo> once network correctly goes up, cloud-init functions as expected
<smoser> NuxRo, hm..
<smoser> cloud-init should be resilient to that.
<NuxRo> well, clearly it's not, the VM had a working interface through which it could get to the datasource
<NuxRo> this is ubuntu 16.04 with stock cloud-init
<smoser> perhaps the instance id did not change while the network devices did
<ThiagoCMC> Guys, how to tell cloud-init, on an Ubuntu 16.04 instance, to ignore the eth1/eth2/eth3/etc, and only configure eth0?
<ThiagoCMC> At my Heat template, the eth0 network have dhcp, and eth1 doesn't but, cloud-init goes there and add a static IP for eth1!!! I want it to just ignore it but, how?
<smoser> ThiagoCMC, this is openstack config drive i guess ?
<ThiagoCMC> yes
<smoser> You should be able to modify /etc/network/interfaces.d/50-cloud-init.cfg to your liking after the instance is up.
<smoser> and it should not be broken
<smoser> that is only written currently once per instance
<ThiagoCMC> That's what I'm doing but, I would prefer to avoid that... So, there is no way to tell cloud-init to ignore that in first place?
<smoser> ThiagoCMC, not right now there is not.
<smoser> would you file a bug and describe your use case ?
<ThiagoCMC> Sure!
<ThiagoCMC> Here: https://launchpad.net/cloud-init ?
<smoser> yeah
<smoser> ThiagoCMC, this is someething i'm aware needs a policy, but i'm not sure on what the policy should be.
<smoser> its kind of tricky...
<ThiagoCMC> Ok, no problem, I'll fill a bug report, with details about this problem. Also publishing the Heat templates that I'm using, to simplify the reproduction.
<ThiagoCMC> Thanks smoser!
<NuxRo> If I wanted to override lock_passwd for default user, would a 99_unlock.cfg with this content suffice? https://paste.fedoraproject.org/467493/21945147/raw/
<harlowja> smoser https://review.openstack.org/#/c/389324/ :-P
<harlowja> u still in
<harlowja> ha
<smoser> \o/
<smoser> i'm still important!
<harlowja> :-P
<NuxRo> well, that doesn't look like it did it, user still locked
<smoser> NuxRo, http://paste.ubuntu.com/23412812/
<NuxRo> cheers, was hoping I could get away with fewer lines than that :)
<NuxRo> since default user is already defined in cloud.cfg, thought maybe just mentioning "default_user" would have been enough
<robjo> smoser: Another topic, net/sysconfig/py is specific to RHEL, during implementation was there thought given about how this could/would be generalized or is this up to me to take it apart and put it back together in a different way?
#cloud-init 2016-11-02
<jeblair> smoser: hi! is the openstack/cloud-init repo defunct?
<smoser> "on hold [indefinitely]".
<jeblair> smoser: ok.  that's fine (of course).  i noticed it has some changes open in gerrit.  i wonder if performing some or all of the steps in http://docs.openstack.org/infra/manual/drivers.html#retiring-a-project might be appropriate (particularly, updating README with current information, and marking the project read-only)?  that would help users who stumble upon it know the situation.  and of course the git repo will remain around ...
<jeblair> ... indefinitely and can always be reactivated.
<smoser> yeah. i thimnk we swhould probably do that.
<jeblair> smoser: ok.  i'm happy to write the infrastructure changes, if you want to make the changes to the repo content itself (eg README, etc)?
<smoser> ok. i can do that.
<jeblair> remote:   https://review.openstack.org/392902 End gating for cloud-init
<jeblair> remote:   https://review.openstack.org/392903 DNM: Retire cloud-init
<jeblair> smoser: ^
<harlowja> thx jeblair
<openstackgerrit> Scott Moser proposed openstack/cloud-init: README.rst: mention that cloud-init focus is on v1 branch.  https://review.openstack.org/392911
<smoser> jeblair, https://review.openstack.org/#/c/392911/
<jeblair> smoser: cool, you should be able to approve that now (the tests have been removed)
<smoser> which ?
#cloud-init 2016-11-03
<powersj> smoser: trying to build cloud-init all of a sudden I am getting errors: https://jenkins.ubuntu.com/server/job/cloud-init-integration/17/console
<rharper> powersj: didn't you proposed the added coverage report =)
<powersj> yes lol
<powersj> so adding "coverage" to test-requirements.txt is the issue
<powersj> that is what pypi calls the package and curtin does the same thing
<rharper> wonder if it just needs to be versioned?
<powersj> I tried adding "coverage=4.2" and got same error
<rharper> hrm
<rharper> can you repro off of jenkins ?
<powersj> let me see. I'll try that after this next session
<rharper> powersj: I can repro local
<powersj> rharper: ah! thank you :)
<rharper> insane
<rharper> powersj: I think we need to add the same package to the requirements.txt and map it to the python-package in archive
<rharper> powersj: found a fix
<rharper> http://paste.ubuntu.com/23420677/ powersj
* smoser changed the topic of #cloud-init to: cloud-init 0.7.8 released 2016-09-12. 0.7.9 open. reviews: https://code.launchpad.net/~cloud-init-dev/cloud-init/+git/cloud-init/+ref/master/+activereviews | fly the W
<smoser> powersj, looking
<smoser> powersj, hm
<smoser> oh, yeah. the package build will use it, forgot about that. need to add a build dep
<smoser> rharper, is right. i'll grab that quick
<rharper> smoser: morning!
<smoser> hey
<smoser> rharper, coverage was already in test-requirements though
<rharper> smoser: yeah, but not in my branch, sorry
<smoser> http://paste.ubuntu.com/23420684/ should work
<smoser> adding it to "standard named packages"
<rharper> smoser: sure, didn't reallize it's standard (which makes sense)
<smoser> as "standard" is 'coverage' pypy package makes python-coverage and python3-coverage
<rharper> right
<smoser> so as this is, we dont need that in the package buidl dependency
<smoser> as Makefile test does not run coverage.
<smoser> for now i think we leave that as it is.
<smoser> and just add the coverage to the list. it'll get installed in bddeb but not used.
<rharper> y
<powersj> rharper: thank you!
<smoser> powersj, fixed in trunk now.
<powersj> smoser: confirmed working now. Thank you!
<smoser> harlowja, does this  make sense to you: https://code.launchpad.net/~bbaude/cloud-init/+git/cloud-init/+merge/309478
<tlonoy> hi all, I'm wondering if there is docs presents on how to modify and test cloud-init before submitting code. I've seen this page (https://cloudinit.readthedocs.io/en/latest/topics/hacking.html) but it doesn't goes into great details
<tlonoy> e.g. there doesn't seem to be a test-suite to run
<smoser> https://git.launchpad.net/cloud-init/tree/HACKING.rst
<smoser> dont know why readthedocs is out of date. i will update it.
<smoser> ie, i just merged that
<smoser> tlonoy, reload https://cloudinit.readthedocs.io/en/latest/topics/hacking.html
<harlowja> brb, gotta restart
<harlowja> will check out in a few smoser
<smoser> harlowja, ok.
<smoser> had some review commetns for you in a couple mp yesterday to
<harlowja> yuppers
<harlowja> smoser  https://code.launchpad.net/~bbaude/cloud-init/+git/cloud-init/+merge/309478 seems ok to me, i guess such a ordering is needed?
<harlowja> weird software be weird, lol
#cloud-init 2016-11-04
<tlonoy> smoser, thanks for the info
<tlonoy> so how do I got about testing my change ? there doesn't seem to be a unit test for cc_set_password
<tlonoy> i tried to change copy my new cc_set_password.py file to a working installation, and did a "python -O -m compileall" on the file.
<tlonoy> but when I run cloud-init --debug single --name set-passwords, i get stages.py[WARNING]: Could not find module named cc_set_passwords
<tlonoy> smoser, thanks again for the input yesterday. Submitted my first merge prop, I don't know if you are the one to review it, but let me know if there is anything I1ve done wrong
<harlowja> smoser so i hear cubswin:)
<harlowja> ha
<harlowja> u predicted it man
<harlowja> lol
<smoser> indeed.
<smoser> harlowja, https://git.launchpad.net/cirros/commit/?id=9a7c371ef329cf78f256d0a5a8f475d9c57f5477
<harlowja> lol
<harlowja> damn u changed it, mannnnn
<harlowja> lol
#cloud-init 2017-10-30
<blackboxsw> ok cloud-init fans, time to kick off the meeting
<powersj> \o/
<blackboxsw> #startmeeting cloud-init bi-weekly status
<meetingology> Meeting started Mon Oct 30 16:03:09 2017 UTC.  The chair is blackboxsw. Information about MeetBot at http://wiki.ubuntu.com/meetingology.
<meetingology> Available commands: action commands idea info link nick
<blackboxsw> #meetingtopic In Progress Development
<blackboxsw> So, the last couple weeks have been fairly busy with Ubuntu an SRU  processs for Xenial, Zesty and the new Artful release
<blackboxsw> our SRU process bug captures most of that work
<blackboxsw> #LINK https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1721847
<ubot5> Ubuntu bug 1721847 in cloud-init (Ubuntu Zesty) "sru cloud-init 2017-10-06 (17.1-18-gd4f70470-0ubuntu1)" [Medium,Fix committed]
<blackboxsw> our teams uncovered at least one bug  during verification testing
<blackboxsw> LINK https://bugs.launchpad.net/cloud-init/+bug/1725067
<ubot5> Ubuntu bug 1725067 in cloud-init (Ubuntu Artful) "cloud-init resizefs fails when booting with root=PARTUUID=" [Medium,Fix committed]
<blackboxsw> The former bug we have now resolved. This SRU will not be published until we resolve one other bug for EC2-specfic environments to ensure we retain behavior to always bring up dhcp4 on the primary nic
<blackboxsw> I don't think we have created a bug for the ec2 issue yet (it affects artful only) instances with only private ipv4 addresses allocated will not have dhcp4 config'd for that instance
<blackboxsw> We'll link a bug for the above today
<blackboxsw> other work on cloud-init... paste coming
<blackboxsw> * Fix systemd mount target due to busy device or already mounted (LP: #1718287)
<blackboxsw> * Fix simpleteable object as output string (LP: #1722566)
<blackboxsw> * Fix netplan bridge stp boolean (LP: #1721157)
<blackboxsw> * Fix cc_ntp to allow empty configuration "ntp:". Fix ntp integration test to provide valid empty ntp config (LP: 1724951)
<blackboxsw> * Fixed cc_lxd to allow for missing bridge definitions in lxd cloud-config
<blackboxsw> * Dropped fastestmirror plugin for CentOS tests
<blackboxsw> * Numerous test and CI stability improvements
<ubot5> Launchpad bug 1718287 in cloud-init "systemd mount targets fail due to device busy or already mounted" [High,Fix committed] https://launchpad.net/bugs/1718287
<ubot5> Launchpad bug 1722566 in cloud-init "ci-info: <cloudinit.simpletable.SimpleTable object at 0x7fa98d222748>" [Medium,Fix committed] https://launchpad.net/bugs/1722566
<ubot5> Launchpad bug 1721157 in cloud-init "netplan render drops bridge_stp setting" [High,Fix committed] https://launchpad.net/bugs/1721157
<ubot5> Launchpad bug 1724951 in cloud-init "Ntp schema definition permits empty ntp cloud-config, but code disallows" [Medium,In progress] https://launchpad.net/bugs/1724951
<blackboxsw> Also we got a couple of gentoo commits from ckonstanski  to Use "rc-service" rather than "service".  Thanks again
<rharper> \o/
<ckonstanski> You're welcome, though those were just tiny toy commits to get me indocrinated into the launchpad process. Getting NTP tests to work in gentoo will be more significant.
<blackboxsw> ckonstanski: testing always is time-consuming, but totally worth it.  We are still trying build our unit test coverage up so we don't get suprises on different platforms/clouds when sparsely tested modules run. Thanks again
<blackboxsw> oops sorry about the meetingtopic for the above ... that should have been the following
<blackboxsw> #meetingtopic Recent Changes
<blackboxsw> anything else for recent changes that have landed rharper powersj or others?
<powersj> nope
<rharper> blackboxsw: not yet
<blackboxsw> ok then let's move to next topic
<blackboxsw> #meetingstatus In Progress Development
<blackboxsw> for real.
<blackboxsw> ok so we are wrapping up that one Ec2 bug that was raised by Sargun on friday (which affects Artful)
<blackboxsw> When we have that branch in place, we can kick our final validation of the cloud-init 17.1 updates to Xenial Zesty and Artful.
<blackboxsw> I know smoser just uploaded cloud-init to the newly opened Bionic release as well
<blackboxsw> We will be hitting the review queue a bit this week to wrap up content that we want landed once master is open for more dyna
<blackboxsw> We will be hitting the review queue a bit this week to wrap up content that we want landed once master is open for more significant changesets
<blackboxsw> we've been a little risk averse during the SRU release process
<blackboxsw> As always please watch our trello board for progress on anything we are working
<blackboxsw> LINK https://trello.com/b/hFtWKUn3/daily-cloud-init-curtin
<powersj> need that #
<blackboxsw> #LINK https://trello.com/b/hFtWKUn3/daily-cloud-init-curtin
<blackboxsw> ahh thanks oops
<robjo> speaking of reviews thanks for the help so far blackboxsw , now that my schedule should be a bit less crazy I'd like to get back to https://code.launchpad.net/~rjschwei/cloud-init/+git/cloud-init/+ref/addZyppRepos
<blackboxsw> Our focus as well for the upcoming work in cloud-init is to increase continuous integration coverage and tooling around cloud-init to make sure we can keep delivering stability across releases
<robjo> since I cannotreproduce the issue the bot has locally and I don't really understand the problem some more help is needed
<blackboxsw> ahh hiya robjo
<powersj> that looks merged
<blackboxsw> robjo: good to hear, we'll watch for updates.
<powersj> smoser went and fixed the flake8 issues
<blackboxsw> robjo: do you mean another branch?
<robjo> blackboxsw: no, that branch, but bot  thinks " Needs Fixing ", I just don't get why
<blackboxsw> yeah per robjo's work cloud-init folks can also configure zypper repos . We landed it Sept 21st. (So it's in cloud-init 17.1)
<blackboxsw> commit cc1475d07b9d0727012634ee9c7a914d67b051f5
<blackboxsw> Author: Robert Schweikert <rjschwei@suse.com>
<blackboxsw> Date:   Thu Sep 21 11:58:28 2017 -0400
<robjo> Oh, so it did get merged, missed that, never mind
<blackboxsw> as powersj mentioned, I think it was a flake8 CI test issue, so we just fixed the minor issue and landed it as it wasn't a significant content change
<powersj> cloudinit/config/cc_zypper_add_repo.py:15:1: H306: imports not in alphabetical order (cloudinit.util, cloudinit.config.schema.get_schema_doc)
<robjo> much appreciated, still a bit concerning that the flake8 issue did not show up locally :(
<blackboxsw> thx powersj
<powersj> is correct way https://paste.ubuntu.com/25852643/
<robjo> SO flake8 has serious issue with the definition of alpha order :(
<blackboxsw> ;)
<blackboxsw> ok anything else for "In Progress Development"  if not we'll transition to the next topic
<blackboxsw> #meetingtopic Open Discussion / Office Hours (30 mins)
<blackboxsw> ok we'll hang out in channel  if anyone has topics, bugs or features they want to discuss or need some feedback on
<blackboxsw> and as always thanks for contributions folks. It's really great to work on a project where there is so much interest and investment
<smoser> blackboxsw: hey. i'm back now. did you open a bug?
<smoser> i can do so now if you have not.
<blackboxsw> smoser: I haven't done that yet, was just working out the fix
<blackboxsw> please do, then we can link it here
<smoser> ok. i'll do so. and i realized a comment you were making about artful.
<smoser> that we could go leave artful configuring all nics it saw.
<blackboxsw> right, because we allow change of behavior in artful right?
<smoser> as that isn't necessarily "broken" behavior.
<smoser> yeah. i didnt understand that when you said it.
<blackboxsw> ahh, I get you. Right, just that the new behavior of configuring all nics is acceptable as new behavior, but not for Xenial. It's just that artful is slightly busted for local-only ipv4
<smoser> i think it might be easiest both in terms of fixing and in terms of keeping things in our head if we just keep the same behavior everywhere for now.
<smoser> that is... make artful act like xenial in only configuring one nic
<smoser> blackboxsw: actually i dont think there is any reason why we shoudlnt just use bug 1728152
<ubot5> bug 1728152 in cloud-init "IPv4 and IPv6 Dual Stack Does Not work when instance is not assigned public IPv4 address" [High,In progress] https://launchpad.net/bugs/1728152
<smoser> unless you disagree
<blackboxsw> +1 smoser
<blackboxsw> lets use that bug
<blackboxsw> #LINK https://launchpad.net/bugs/1728152
<ubot5> Ubuntu bug 1728152 in cloud-init "EC2 IPv4 and IPv6 Dual Stack Does Not work when instance is not assigned public IPv4 address" [High,In progress]
<blackboxsw> ok looks like we are good for the status meeting
<blackboxsw> thanks for joining all. see you in two weeks
<blackboxsw> #endmeeting
<meetingology> Meeting ended Mon Oct 30 17:00:30 2017 UTC.
<meetingology> Minutes:        http://ubottu.com/meetingology/logs/cloud-init/2017/cloud-init.2017-10-30-16.03.moin.txt
<powersj> blackboxsw: thx
<smoser> blackboxsw: i'm writing sru template there.
<smoser> pushed . blackboxsw https://github.com/cloud-init/ubuntu-sru/blob/master/bugs/lp-1728152.txt
<blackboxsw> thx smoser
<powersj> smoser: https://code.launchpad.net/~powersj/cloud-init/+git/cloud-init/+merge/331736
<powersj> blackboxsw: ^
<powersj> think that is now ready... now with new and improved sudo ;)
<smoser> is the diff up to date ?
<smoser> yeah, it is. ok. i'm reviewing / looking at that now
<blackboxsw> ok just pushed up a WIP diff for ec2 b6e0d54c171ad3a801ef0aab2e8f30bd5a8f0daf  @ https://code.launchpad.net/~chad.smith/cloud-init/+git/cloud-init/+merge/332954
<blackboxsw> I'm adding a couple of extra unit tests
<smoser> powersj: ok.. http://paste.ubuntu.com/25853561/
<smoser> that really should work to execute stuff as root.
<smoser> but it doesnt. and i'm not sure why. i get wierd failures when i change.
<powersj> smoser: right that is what I did on Friday
<powersj> I didn't dig into what was the issue though
<blackboxsw> b2064bf6eeb2a96d50051ed4e0203e3c7dcb5a44  is the winner for https://code.launchpad.net/~chad.smith/cloud-init/+git/cloud-init/+merge/332954. I'm done w/ updates for the SRU ec2 issue.
<blackboxsw> smoser: rharper comments welcome when you have cycles https://code.launchpad.net/~chad.smith/cloud-init/+git/cloud-init/+merge/332954  description updated too
 * blackboxsw heads to launch-ec2 tool 
<blackboxsw> need to put that up for quick review/test
<rharper> k
<blackboxsw> powersj: rharper smoser  just pushed sample launch-ec2 script I'm running locally https://github.com/cloud-init/qa-scripts/blob/master/scripts/launch-ec2
<blackboxsw> I'll keep posting updates to it as I refine it
<smoser> powersj: ok. i understand why the obvious fix was not working.
<smoser> http://paste.ubuntu.com/25854027/
<smoser> is one solution, powersj
<smoser> the IOError was in run_script trying to push to a file that was root owned (as a result of the mktemp)
<smoser> the push was still not happening as root
<smoser> this works, but could be better.
<smoser> http://paste.ubuntu.com/25854037/ <-- is better in that it drops the 'sudo' form the 'run-script' path as its not needed because execute has it.
<powersj> smoser: thx will take a look
#cloud-init 2017-10-31
<smoser> blackboxsw: rharper and i both picked on your non-usage of net.find_fallback_nic in the 'if' portion of
<smoser> https://code.launchpad.net/~chad.smith/cloud-init/+git/cloud-init/+merge/332954
<smoser> other than that nit, i generally dont have any issues.
<smoser> just seems silly to call maybe_perform_dhcp_discovery() with no interface, only to let it select the interface and then read it.
<smoser> as opposed to just caling net.find_fallback_nic and passing that to maybe_perform...
<powersj> smoser: blackboxsw: here's the nocloud-kvm fix with smoser's fix: https://code.launchpad.net/~powersj/cloud-init/+git/cloud-init/+merge/331736
<smoser> powersj: you have to stop thinking i can write code
<smoser> nothing increments _tmp_count there.
<blackboxsw> powersj: added a couple hilights & DOC comments to the done lane for cloud-init
<smoser> better tmpfile function:
<powersj> smoser: haha
<smoser>     def tmpfile(self):
<smoser>         path = "/tmp/%s-%04d" % (type(self).__name__, self._tmp_count)
<powersj> blackboxsw: thx
<smoser>         self._tmp_count += 1
<smoser>         return path
<blackboxsw> thanks smoser rharper for the review comments. I just pushed the fix for https://code.launchpad.net/~chad.smith/cloud-init/+git/cloud-init/+merge/332954
<smoser> powersj: i'm torn now... i think you can probably largely drop a bunch of your delta on that mp
<powersj> smoser: yeah... I need to go back and review again
<smoser> if you want to focus on other things, i can attempt a minimal fix.
<powersj> I don't think it would take too long, I can back out the changes and re-run things, but my focus would be more on minimizing the delta and not on re-implementing things
<smoser> powersj: right.
<smoser> thats fine.
<powersj> smoser: looking through the delta, I actually think most of it will stay. The majority is $home or /tmp --> /var/tmp and then some user related changes
<powersj> I do add the "default" user back in to a few places
<smoser> powersj: well, yeah, but you dont need the /root to /var/tmp/ changes
<smoser> definitely dont want /tmp thought
<powersj> hmm
<powersj> agreed with no /tmp, understand that now
<powersj>  /var/tmp/ seems like a more generic location anyway over using /root, but if we are expecting to do everything as root anyway I guess it doesn't matter?
<smoser> blackboxsw: aroudn ?
<blackboxsw> smoser: yep
<smoser> you want to merge your thing ? then you can do 4 SRU merge requests if you want.
<blackboxsw> ok will do
<smoser> b, a, z, x :)
<blackboxsw> smoser: strange I was waiting on ci
<blackboxsw> which I don't think ran after my brancch
<powersj> blackboxsw: master is off, if you enable it, it should go
<powersj> I'm at Dr so can't logon easily
<blackboxsw>  no worries powersj happy dentist ;)
<blackboxsw> ok master is back up and jobs running again
<blackboxsw> sorry I should have looked sooner
<blackboxsw> I kicked a rebuild, we should have results in 15 mins
<blackboxsw> smoser: merged eb292c1
<blackboxsw> starting to cut branches
<smoser> blackboxsw: thanks.
<blackboxsw> smoser: devel MR is up for review https://code.launchpad.net/~chad.smith/cloud-init/+git/cloud-init/+merge/333047
<blackboxsw> https://code.launchpad.net/~chad.smith/cloud-init/+git/cloud-init/+merge/333048
<blackboxsw> just rebased artful as I forgot 17.10.1
<blackboxsw> https://code.launchpad.net/~chad.smith/cloud-init/+git/cloud-init/+merge/333050
<blackboxsw> https://code.launchpad.net/~chad.smith/cloud-init/+git/cloud-init/+merge/333051
<blackboxsw> ok that's it , devel + b,a,z,x
 * blackboxsw spins up one more ec2 instance on this to be sure
<smoser> blackboxsw: you left the gentoo bug number in the changelog
<smoser> was that by design ?
<smoser> just uploaded bionic
<blackboxsw> smoser: I had left them in there as I wasn't sure whether we were going to separate SRU template on the bugs. Ahh gentoo right, didn't need to as it didn't affect ubuntu
<blackboxsw> want to quick hangout to see if I should repush?
<smoser> blackboxsw: i'm fine to do it myself
<smoser> http://paste.ubuntu.com/25860935/
<smoser> opposed ?
<smoser> (i grabbed his name from launchpad)
<smoser> rather htan the name in the commit message
<blackboxsw> +1  yes good
<blackboxsw> thanks smoser, just saw the "    update changelog to remove Gentoo bug number and add name" revs
<smoser> i didnt' catch it on bionic
<smoser> oh well
<smoser> i was kind of surprised, but cherry-pick worked
<smoser> git cherry-pick <ubuntu-xenial hash that i did manually>
<smoser> i thoguht it'd complain about the context (given that the version and changelog stuff around it differs)
<smoser> but worked.
<blackboxsw> nice. Just validated master again on EC2 stock network. Going to try to spin up an instance with local-only ipv4
<smoser> blackboxsw: your thoughts would be appreciated on
<smoser> https://code.launchpad.net/~smoser/cloud-init/+git/cloud-init/+merge/332958
<smoser> and
<smoser> https://code.launchpad.net/~smoser/cloud-init/+git/cloud-init/+merge/333059
<blackboxsw> looking
<smoser> powersj and rharper ^ you too on those
<rharper> k
<blackboxsw> smoser: did this mean that AliYun wouldn't be matched? https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1728186
<ubot5> Ubuntu bug 1728186 in cloud-init (Ubuntu) "AliYun datasource has wrong case in config" [Medium,Confirmed]
<blackboxsw> and the datasource wouldn't be found/attempted
<smoser> yeah. :-(
<smoser> you get a warning in /run/ds-identify.log
<blackboxsw> umm so why didn't we hear about it
<blackboxsw> ahh
<smoser> if you manually configure it
<smoser> and spell it right it will work
<blackboxsw> ahh that too. ok
<smoser> but by default package instllation is busted.
<blackboxsw> so images in AliYun could have manually config'd it
<smoser> i suspect so.
<smoser> we should add to ci
<smoser> integration test
<smoser> a check for WARN in the ds-identify logs too
<smoser> like i did for /var/log/cloud-init.log
<blackboxsw> approved https://code.launchpad.net/~smoser/cloud-init/+git/cloud-init/+merge/332958
<blackboxsw> updated description for typo
<smoser> merged. missed your spellingfix. sorry.
 * smoser is hallowout
<blackboxsw> smoser: don't worry I'll give you a hard time about it after I eat some candy
<msaikia_> https://code.launchpad.net/~msaikia/cloud-init/+git/cloud-init/+merge/330105/+index?ss=1
<msaikia_> Hi, can anyone please take a look at this review request?
<blackboxsw> good deal msaikia_ thanks for retouching that.
<blackboxsw> I'll look at it tomorrow
<msaikia_> Thanks..:)
#cloud-init 2017-11-01
<smoser> powersj, rharper, blackboxsw
<smoser> https://code.launchpad.net/~smoser/cloud-init/+git/cloud-init/+merge/333059
<smoser> that is updated with a reasoable commit message.
<smoser> i successfuilly ran on diglet
<smoser>  rm -Rf results.lxd.d/; time tox-venv citest python3 -m tests.cloud_tests run --platform=lxd --os-name=xenial --preserve-data --data-dir=results.lxd.d --verbose 2>&1 | tee results.lxd.log
<powersj> let me go play with it in a bit
<smoser> and am trying nocloud now
<smoser> (i had run  most of it but ctrl-c'd for some little things)
<rharper> smoser: reading
<smoser> powersj: at this point i think the nocloud-kvm still dumps disks into the results.d/
<smoser> yeah. need to have it clean those up. other wise more disk full
<smoser> rharper: thanks!
<smoser> responded
<rharper> np
<smoser> and one push just now ithink that covers it.
<dmsimard> smoser, harlowja: is there a changelog for cirros versions ? Just noticed we had been using 0.3.4 and noticed 0.3.5 was a thing
<smoser> hm..
<smoser> itw was used.
<smoser> dmsimard: and 0.4.0 is a thing
<dmsimard> smoser: looks "pre" in http://download.cirros-cloud.net/
<dmsimard> so I'll stick to non-pre for now :p
<smoser> https://git.launchpad.net/~smoser/cirros/tree/ChangeLog?h=feature/mkcacert-bash
<smoser> well, 0.4.0 is good .
<dmsimard> smoser: that changelog is good but also missing 0.3.5 :)
<smoser> it jsut requires re-build and sign
<smoser> hmn.. it sure is missing 0.3.5
<smoser> http://paste.ubuntu.com/25867302/
<smoser> dmsimard: ^
<smoser> rharper: bah. description and rcs are used in some places.. not sure what i shoudl do .
<dmsimard> smoser: would be cool to have a changelog file in, say, http://download.cirros-cloud.net/0.3.5/
<dmsimard> just a suggestion :)
<dmsimard> thanks for your help
<dmsimard> just didn't want to blindly update :D
<smoser> well, yeah. i guess so.
<smoser> dmsimard: ii'd really be appreciative of feedback youo had on 0.4.0
<smoser> i really do expect to just release taht with a re-build
<smoser> just when i get around to it.
<smoser> the one gotcha there is password change
<smoser> cubswin:) -> gocubsgo
<rharper> smoser: when do you expect cirros to support systemd
<smoser> it  might jsut skip it.
<smoser> dmsimard: fyi, there is '#cirros'
<smoser> its where the coolest kids hang out
<dmsimard> smoser: didn't know, I just come here when I need to talk about cirros or cloud-init :p
<dmsimard> thanks
<rharper> of course I was already in #cirros
<smoser> dangit rharper why'd you have to catch the issue with execute and rcs= and description
<smoser> i thought nothing was using that.
<rharper> heh, what about the property !?!  I updated my query there;  do you always want it to start each time?
<smoser> well, there was / is code that tries to only start once
<smoser> in tests/cloud_tests/instances/lxd.py 's start
<smoser> but that ocde is kind of buggy, and it explains something i had seen.
<smoser> i think i'll add description back in and drop the 'rcs='
<smoser> fudge
#cloud-init 2017-11-02
<smoser> rharper, powersj i'm running "full" run of lxc and nocloud against my current https://code.launchpad.net/~smoser/cloud-init/+git/cloud-init/+merge/333059
<rharper> nice
<smoser> hmm.
<smoser> i tihnk that launchpad got hosed on that
<smoser> it doesn't knwo of any of muh newer pushes
<smoser> oh wait.
<smoser> stale page
<smoser> and look at this:
<smoser>  21 files changed, 319 insertions(+), 327 deletions(-)
<bdx> hello
<bdx> are there any examples out there of network interface configuration for the nocloud datasource
<bdx> ?
<bdx> for example, does network device configuration get its own file, network-config?
<bdx> or do I add it in with the meta-data with a top level header "network:"
<bdx> few discrepancies it would be nice to clear up
<bdx> oh .. nm
<bdx> just found it
<bdx> in the docs :P
<dpb1> :)
<smoser> bdx: network-config
<smoser> and no top level 'network' key (since that is implied as ait is in 'network-config')
<bdx> smoser: yeah ... I think I'm hitting a possible bug see line 3 http://paste.ubuntu.com/25875749/
<bdx> I think I'm setting it correctly
<bdx> I'm doing as you (and the docs) say
<bdx> and it seems to be taking it, but like, not taking it
<bdx> network-config < http://paste.ubuntu.com/25875757/
<bdx> possibly there is something I need to do to make the network-config run after the creation of the device...
<bdx> possibly I need to use version 2
<bdx> ahh, I think I see whats going on
<bdx> I need to target an existing mac address
<bdx> cloud-init isn't creating a new device, its configuring an existing device
<bdx> oh, yea!
<bdx> the key thing was that I had to create the vm with a defined mac address ANDd have attached a config drive with network-config with the same mac address I used when creating the vm
<bdx> yeah, nm
<bdx> still didn't work
<bdx> so, whats I did find
<bdx> is that when I made the mac address of the vm match the mac address in the network-config, I get a clean cloud-init log
<bdx> http://paste.ubuntu.com/25875903/
<bdx> so cloud-init is finding the device now
<bdx> it seems
<bdx> it still isn't getting configured though
#cloud-init 2017-11-03
<rharper> bdx: if you can pastebin /var/log/cloud-init.log we can see what's going on;
<bdx> rharper: https://bugs.launchpad.net/cloud-init/+bug/1729715
<ubot5> Ubuntu bug 1729715 in cloud-init "nocloud datasource network-config not working" [Undecided,New]
<smoser> rharper: in netwokr config v1, i think that we can't rename an interface without knowing the mac. is that right ?
<rharper> smoser: correct
<smoser> https://git.launchpad.net/~smoser/cloud-init/commit/?h=feature/json-socket-server
<smoser> thats my json server
<smoser> see that commit message for how to use.
<Sargun> Can you write templates in write_files?
<blackboxsw> not sure what you mean Sargun, you can write any file content  you want. if you wrote templates in write_files I'd guess you'd be processing templates  in your runcmd config.
<blackboxsw> the files written by the write_files is a list with a single file declared per list item.
<bdx> @rharper, @smoser does static interface network-config for nocloud work for you guys?
<rharper> bdx: working; I replied, you need network-config in separate file, and drop the top 'network' key
<bdx> rharper: that is awesome!
<bdx> I just got it to work
<rharper> ]o/
<bdx> many thanks
<rharper> what happened to my arm!?
<rharper> \o/
<rharper> there we go
<bdx> :)
<rharper> np, sorry it wasn't clear from the docs
<bdx> its cool, its pretty clear, there are just a few gotchas
<bdx> like you *must* use the network-config file
<bdx> which I did
<bdx> geh
<rharper> I've filed https://bugs.launchpad.net/cloud-init/+bug/1708255
<ubot5> Ubuntu bug 1708255 in cloud-init "empty or invalid network config dictionaries are not handled well" [Undecided,New]
 * bdx beats his own head
<rharper> which should have made it obvious that it got a config but was unhappy with it
<rharper> now just to allocate time toward that one
<bdx> ha - right
<bdx> thanks all the same
<rharper> np
<rharper> I may repurpose your bug into updating the docs around NoCloud's use of network-config since that part wasn't clear
<bdx> that would be great
<Sargun> blackboxsw: I have a file I want to write in write_files, but I want to substitute instance_id into the config files in some places. Is there an easy way to do this?
<smoser> Sargun: no. :-(
<smoser> but https://trello.com/c/AYaCdQyT
<smoser> that is the trello card that i descried what i'd want.
<smoser> powersj: what am i doing wrong
<smoser> Sargun: i'd be interested in your thoughts on that.
<powersj> smoser: not sure yet, I was just finishing lunch let me dig in
<powersj> smoser: hmm now it is working, but super slow... 20 seconds for each pull.
<powersj> https://paste.ubuntu.com/25881348/
<powersj> are you seeing similar results?
<smoser> for each pull ?
<smoser> what is pull
<powersj> sorry each cmd run
<smoser> no..
<smoser> 2017-11-03 18:53:28,938 - tests.cloud_tests - DEBUG - running collect script: result.json
<smoser> 2017-11-03 18:53:28,938 - tests.cloud_tests - DEBUG - Executing "collect: result.json"
<smoser> 2017-11-03 18:53:29,321 - tests.cloud_tests - DEBUG - running collect script: status.json
<smoser> 2017-11-03 18:53:29,322 - tests.cloud_tests - DEBUG - Executing "collect: status.json"
<powersj> hmm
<smoser> powersj: i have a thoguht that it could be sudo and dns related possibly.
<smoser> or it could be paramiko related.
<smoser> maybe the wway we are sending stdin now is not rigiht
<smoser> (we were not sending before)
<smoser> powersj: can you try
<smoser>  http://paste.ubuntu.com/25881453/
<smoser> that re-uses the connected ssh client
<blackboxsw> smoser: powersj I'm seeing successes on nocloud-kvm (artful)
<blackboxsw> will pull in your paste too
<powersj> blackboxsw: Are you seeing timings like smoser, which are quick?
<powersj> smoser: still getting 20-second delays between each collect... that definitely feels like something is timing out somewhere along the path.
<powersj> I'll pastebin shortly
<blackboxsw> lemme, check timestamps on that powersj
<powersj> https://paste.ubuntu.com/25881623/
<blackboxsw> meh powersj yeah 20 second delays between collect calls
<blackboxsw> http://pastebin.ubuntu.com/25881628/
 * powersj goes and find's smoser's venv cmd
<smoser> powersj: ./tools/tox-venv
<smoser> blackboxsw: where are you running that ?
 * blackboxsw hasn't tried smoser I'm running that on artful desktop at home.
<smoser> oh. i thought you said you had.
<blackboxsw> tox -e citest -- run --verbose --os-name xenial --deb cloud-init_17.1-46-g8a49e051-1~bddeb_all.deb --data-dir ~/collection --preserve-data --platform=nocloud-kvm --test=tests/cloud_tests/testcases/modules/final_message.py
<powersj> smoser: still having issues: https://paste.ubuntu.com/25881674/
<blackboxsw> smoser: sorry about the last couple comments,  I had tried running artful with the following commandline  I see various successes there, but I'm seeing the 20 second gap between each collect
<blackboxsw> and that 20 second gap persists even across your re-use ssh patch
<smoser> could one of you letl me in somewhere ?
<smoser> so i can run. i'm kind of out of ideas.
<blackboxsw> smoser: yeah adding you
<blackboxsw> gotta open up my router one min
<smoser> blackboxsw: hm.. ok . i ran here and i see it. (locally on artful desktoip) rather than on diglett.
<blackboxsw> smoser: ok. I've got creds for you if needed
<powersj> Running on torkoal seems fine
<smoser> it hangs on
<smoser>             rc = channel.recv_exit_status()
<blackboxsw> should we be checking exit_status_ready ?
<blackboxsw> not going to help
<blackboxsw> I looped in a pdb session
<blackboxsw> http://pastebin.ubuntu.com/25881811/
<blackboxsw> it also is false for about 20 seconds
<blackboxsw> then true
<blackboxsw> which presumably is when the exit status becomes available to paramiko
<smoser> blackboxsw: yeah, iwas looking at that too.
<smoser> the examples of paramiko and sending data are not a lot.
<smoser> just tried here doing a channel.shutdown(2)
<smoser> http://docs.paramiko.org/en/2.3/api/channel.html
<smoser> rather than shutdown_write()
<smoser> and taht didnt help
<smoser> blackboxsw: dropping remvoes the hang.
<smoser> self.ssh(["sudo", "cat", "/etc/cloud/build.info"])
<smoser>  ^^ slow ---- vv faster
<smoser> self.ssh(["cat", "/etc/cloud/build.info"])
<smoser> ok.
<smoser> well... not paramiko fault
<smoser> this hangs similarly
<smoser> ssh ubuntu@localhost -p 37425 -i results.nocloud-kvm.d/id_rsa "cat /etc/passwd"
<smoser> i really, really hate that feature in sudo
<blackboxsw> geez right, it's sudo trying to hit resolve or something for the hostname?
<rharper> yeah
<rharper> you need the hostname in /etc/hosts or sudo barfs;
<blackboxsw> so we could set the hostname in /etc/hosts
<blackboxsw> yeah
<rharper> or, set NOPASSWD in sudoers
<smoser> ?
<smoser> we do have nopassword for that user
<rharper> ah, right, I guess it still does the lookup
<rharper> looks like ALL would work
<blackboxsw> ok in ip tools world (no netstat) how do I check what open ports I'm listening too
<blackboxsw> I'm so used to netstat -ln
<smoser> its such a non-feature
<smoser> https://superuser.com/questions/429790/sudo-command-trying-to-search-for-hostname
<smoser> that describes what it is and what is doing it.
<rharper> hey, you want to share your sudoers file across your entire company
<rharper> it needs to know which host it's on
<blackboxsw> ss -l
<smoser> im' not sure why, but
<smoser>  'time host ubuntu'
<smoser> that returns in 1 second on my system (where this is slow)
<smoser> and 0.014 seconds on diglett
<blackboxsw> dns search order?
<smoser> which i think is basically the source of why it works fast on diglett
<rharper> what does host -v show ?
<rharper> that walks the dns search list here
<rharper> with vpn, it rns through all of those domains in the list
<rharper> all those domains have to say no before your caching nameserver can give up and let /etc/hosts respond IIUC
<rharper> wow, localhost even has to do that with the "host" command
<blackboxsw> so on artful I'm talking to systemd/resolved, what's diglett running again?
<rharper> artful
<blackboxsw> hmm ok
<smoser> diglet is bionic
<rharper> oh, when did we upgrade ?
<smoser> https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1728616
<ubot5> Ubuntu bug 1728616 in apt (Ubuntu) "using 'devel' in sources.list causes apt-get update to fail" [Undecided,Opinion]
<smoser> looks like i did on 2017-10-30
<smoser> :)
<rharper> heh
<smoser> we really should fix sudo
<smoser> to not do a dns lookup if it doesnt need to
<rharper> the claim is that it wants to, ifyou set the section to (ALL) for the hostname it won't do that
<smoser> it doesnt claim that.
<rharper> https://bugs.launchpad.net/ubuntu/+source/sudo/+bug/32906
<ubot5> Ubuntu bug 32906 in sudo (Ubuntu Hardy) "sudo fails if it cannot resolve the local hostname and no MTA is installed" [High,Fix released]
<smoser> well, it doesnt fail
<smoser> â¦yeah, sudo, itâs all very clever until someone loses an eye!
<smoser> i like that :)
<rharper> now, it appears are are using (ALL); so now I'm confused
<rharper> https://www.sudo.ws/repos/sudo/rev/1e10105ade5b
<rharper> fun stuff
<rharper> sudo + PAM
<smoser> well, acouple of options here.
<smoser> a.) cloud-init can be set to write the  hostname to /etc/hosts
<smoser> b.) we can just eat this once when we first run a command
<smoser> but even then, 20 seconds is suck
<smoser> c.) maybe this is sufficient, for nocloud we can just modify it pre-boot
<smoser> also in these scenario..
<smoser> we can be trickly.
<smoser> for nocloud-kvm, if i add an 'ubuntu' to the *hosts* /etc/hosts
<smoser> then qemu dns -> host resolv -> that entry
<smoser> and magic fast
<smoser> 127.0.0.1   localhost ubuntu
<blackboxsw> yeah I think I don't want to eat that 20 second cost even on setup
<blackboxsw> that makes every test that much more costly
<smoser> with that in place, on diglett
<blackboxsw> I like being trickly
<smoser> http://paste.ubuntu.com/25882159/
<blackboxsw> looks much better
<smoser> ~ 0.06
<blackboxsw> instead of 0.014 right?
<smoser> oh. no. instead of something like a half a second it hink
<blackboxsw> Ohh I was thinking you were talking time host ubuntu ... and 0.014 seconds on diglett
<rharper> I'm +1 for writing ubuntu into hosts
<rharper> oh, heh, I forgot we had something like this for m-i-c
<blackboxsw> yeah, I think that's warranted given we know sudo's shortfall w.r.t. hostname lookup
#cloud-init 2017-11-05
<phatypus> Does anyone know why runcmd does not run until i reboot my vagrant vm?  I'm running CentOS 7.4.1708 and cloud-init version 0.7.9, release 9.el7.centos.2.
<phatypus> my user-data file is very basic, with a simple echo to file in the runcmd
<phatypus> maybe i misunderstand it's purpose, but i expected it to run at some point during the first boot when cloud-init was doing it's thing (like adding new users etc.)
