#cloud-init 2013-10-16
<ctracey> hey guys, ltns
<ctracey> i think i will have 2 small changes to push shortly
<ctracey> before i push the bigger of the 2, just curious if folks ever have issues with package_command from within cloud-init
<ctracey> from time to time on RHEL we had issues with yum just failing...no clear reason why
<harlowja> hmmmm, yum is just problematic in general
<harlowja> *imho its a pile of crap, ha
<harlowja> what errors do u see ctracey 
<ctracey> hey, i wouldnt disagree
<ctracey> well, we dont see errors only bc capture=False
<harlowja> hmmm
<ctracey> so, my change is simply to allow for debugging package_command
<ctracey> just wondering if anyone else had encountered it
<harlowja> i haven't
<harlowja> but i haven't used that feature to much
<ctracey> basically I would propose system_info: debug_package_command: true
<harlowja> seems to make sense
<ctracey> to you can at least grab the output as necessary
<harlowja> yahoo has a whole other way to install stuff (like juju in a way)
<ctracey> ah, interesting
<harlowja> but ya, i think debug package command makes sense
<ctracey> the other issue we ran into was a 2.7 vs 2.6 thing
<ctracey> buried in the AzureDataSource
<harlowja> ah, blame smoser for that one, ha
<harlowja> :-P
<ctracey> (yes, we are on an ancient python release)
<ctracey> :)
<ctracey> its a simple fix
<ctracey> ill get them in tonight most likely
<harlowja> cool
<harlowja> sounds great
<ctracey> harlowja: you going to HK?
<harlowja> sure am
<ctracey> niiiice
<ctracey> i'll see ya there then :)
<harlowja> cool
<smoser> ctracey, yeah. i'm sorry about that.
<smoser> but wrt debug_package_command
<smoser> that output shoudl be caught by 
<smoser> output: {all: '| tee -a /var/log/cloud-init-output.log'}
<smoser> is it not?
#cloud-init 2013-10-17
<smoser> i use that everywhere, and see 'apt-get' output to that file.
<smoser> and also, you *should* get it on the ec2 console
<harlowja> *or openstack console
<smoser> right.
<smoser> there is a bug for the python2.7 thing
<harlowja> 2.7 to new and hot
<harlowja> ha
<smoser> ctracey, feel free to fix https://bugs.launchpad.net/cloud-init/+bug/1232175
<smoser> i released 0.7.3. and there was one thing that needed fixing
<smoser> whihc is now fixed in trunk
<smoser> i'd take your 2.6 fix also, and then release 0.7.4
<smoser> i *would* do 0.7.3.1, but i dont want to deal with any fallout of the additional dot
<harlowja> to many dots!
<harlowja> :)
<harlowja> btw, smoser  taskflow 0.1 coming out tommorow
<harlowja> u excited??
<harlowja> ha
 * smoser googles
<smoser> awesome.
<harlowja> ha
<harlowja> https://wiki.openstack.org/wiki/TaskFlow
<harlowja> https://github.com/stackforge/taskflow
<harlowja> and yes it even mostly works, ha
<harlowja> ^^ why i haven't been so active in cloudinit
<smoser> harlowja is one smart dude
<harlowja> ha
<harlowja> nah
<harlowja> its just something openstack (imho) really really needs
<harlowja> cause right now u stop nova-compute (the thing that manages the vms) to upgrade that code, and u lose who knows what that its actively doing
<harlowja> what i call the poo cleanup crew
<harlowja> so taskflow tracks enough of that state itself that it can just resume from where it left off :-P
<harlowja> no poo cleanup crew required
<harlowja> and its also going to hopefully be the core of https://wiki.openstack.org/wiki/Mistral (TBD)
<harlowja> *and in my dream world, it will be at the core of the rest of the projects
<harlowja> cinder is already starting to use it, nova soon i hope
<smoser> but what will happen to the poo cleaner uppers ?
<smoser> will they find new jobs ?
<smoser> what about their healthcare?
<harlowja> ha
<harlowja> no obamacare for poo cleaners
<harlowja> *do we still have a government in the US
 * harlowja checking news, ha
<harlowja> seems like we don't, US gov people need to have there heads checked
<harlowja> those people so crazy
#cloud-init 2013-10-18
<tmclaugh[work]> hi, i see that runcmd runs ar an "rc.local like" level.  Is there any way to run commands before other modules?
<tmclaugh[work]> We're having some issues with yum repos and that's causing our puppet installation to fail.
<tmclaugh[work]> we tried adding a 'yum makecache' before the installation of puppet as a precaution but it doesn't help since the command is executed after the attempt to install puppet.
<smoser> well, tmclaugh didn't stick around long enough
<Chocobo> Hi.  So I am having a small problem with persistent network naming rules and I think I need to delete the persistent net name rules in /etc/udev/rules.d/.  I am thinking about creating a per-instance script to do that.  Is there a better way?
<smoser> Chocobo, what is your hypervisor?
<smoser> because persistent naming network rules should work correctly.
<smoser> they basically turn off for known MAC that are virtual
<smoser> by mac-id allocation
<Chocobo> smoser: kvm
<smoser> on debian or ubuntu the default mac addrs should not get perisstent rules created.
<smoser> unless youre creating macs yourself and not doing it correctly
<smoser> s/creating macs /creating mac addresses/
<Chocobo> smoser: Ahh, I am using it to make a CentOS image.
<smoser> hm..
<smoser> i think udev has that function uptream
<smoser> probably just too old there.
<smoser> or maybe locally patched in ubuntu or debian
<Chocobo> I already have the official ubuntu image.  I should check and see how it is done.   I don't see anything in /lib/udev/rules.d/75-persistent-net-generator.rules that looks like it would match the virtual nic's MAC
<Chocobo> I acutally don't mind having persisting nic names per instance (vm's can have multiple nics)
<smoser> Chocobo, it works right
<smoser> mostly.
<smoser> ie, virtio bus will do the right thing generally.
<smoser> you can get crazy and mess it up with plug unplug and such
<smoser> but generlly it enumerates them in a consistent way
<smoser> Chocobo, some related bugs with info
<smoser> https://blueprints.launchpad.net/ubuntu/+spec/t-cloud-server-cloud-images
<smoser> shoot
<smoser> paste fail
<smoser> https://bugs.launchpad.net/ubuntu/+source/udev/+bug/719418
<Chocobo> So this rule: ENV{MATCHADDR}=="?[2367abef]:*", ENV{MATCHADDR}="" <--- that would match something like fa:16:3e:c1:c0:12  correct?
<Chocobo> How strange.  CentOS has the same rule but it still writes the rule out.
<smoser> Chocobo, i dont know.
<smoser> ctracey, is there some reason why you'd not want 'tee' ?
<smoser> https://bugs.launchpad.net/cloud-init/+bug/1241701
<smoser> as in
<smoser> output: {all: '| tee -a /var/log/cloud-init-output.log'}
<smoser> the package command being logged makes quite reaosnable sense
<smoser> but is thre a reason that capturing output generically is insufficient ?
#cloud-init 2014-10-13
<harlowja> harmw if u get a sec can u look over https://code.launchpad.net/~harlowja/cloud-init/test-fixups/+merge/238042 
<harlowja> should fix a reported bug + some tests that fail on me
<harmw> harlowja: no can do
<harlowja> lol
<harmw> I only got minuts 
<harlowja> np
<harmw> no seconds
<harlowja> are u gonna die?
<harlowja> :(
<harlowja> no dying
<harmw> lol
<harlowja> poof
<harlowja> lol
 * harmw left #cloud-init
<harmw> watchin' netflix on Fedora with Chrome, woohoo
<gholms> At least it's a step in the right direction.
<harmw> harlowja: that test 'll fail if this instance has no vtnet0 device, right?
<harlowja> ya
<harlowja> but due to the mocking it always looks like it has one :-P
<harmw> ah, ofc
<harmw> there, I think my cloud works on CentOS7 now :)
<harmw> icehouse, ceph, openvswitch+gre, all up&running
<harmw> to bad dnsmasq still can't process ipv6 stuff, thus not giving out adresses 
<harmw> eventhough that should've been fixed a while ago
<harlowja> woot
<harlowja> u can now join the league of openstackers
<harlowja> u have passed!
<harlowja> welcome to the elite
<harlowja> clap clap
<harlowja> ha
<harmw> harlowja: how :P
<harlowja> u got the basics installed and working, u deserve a vacation, ha
#cloud-init 2014-10-14
<nvucinic> smoser`: you around ? 
<nvucinic> i found some workaround with my password problem, it's working ok if i set password in user-data with password: mypassword 
<nvucinic> but still, problem is that when i have my templete with preset password that after cloud init runs i cannot login with that password from template
<smoser`> nvucinic, here now.
<smoser`> that is odd.
<nvucinic> smoser: well i managed to solve the problem by removing -users -default 
<devicenull> how can I convince cloud-init to change the root password?
<devicenull> I tried adding a user with the name of 'root', but that seems to be getting ignored (I suspect because it already exists)
<Wulf> devicenull: I don't know. But why do you want to use passwords instead of ssh keys?
<devicenull> because that's what our customers want
<Wulf> oh :(
<devicenull> I think I got it, though it's less then ideal.  I created a per-once script that sets it via chpasswd
<Wulf> devicenull: http://www.blog.sandro-mathys.ch/2013/07/setting-user-password-when-launching.html ?
<devicenull> hmm
<devicenull> interesting, I'll have to try it
<Wulf> devicenull: check the docs in doc/examples/cloud-config.txt.
<devicenull> I've been looking at http://cloudinit.readthedocs.org/en/latest/topics/examples.html
<devicenull> looks like the ones in the source tree have different examples, interesting
<JayF> devicenull: afaik there's no native support for setting pw on root
#cloud-init 2014-10-15
<flozano> any idea?
<flozano> any hint about how to debug the issue?
<smoser> flozano, example of the multipart?
<flozano> I found the issue - it seems if the name of the attachment contains â/âs, itâs not properly executed
<flozano> I made a clean-up and now it seems fime
<flozano> *fine
<smoser> if the filename has a '/' ?. thats possible. run-parts gets called on the directory, and wouldnt recurse.
<flozano> maybe itâd be good if cloud-init would clean-up these attachment names
<lauris> hi, have a problem with puppet module
<lauris> Oct 15 16:22:45 ip-10-0-110-91 cloud-init: 2014-10-15 16:22:45,280 - util.py[WARNING]: Running puppet (<module 'cloudinit.config.cc_puppet' from '/usr/lib/python2.7/site-packages/cloudinit/config/cc_puppet.pyc'>) failed
<JayF> harlowja_away: https://review.openstack.org/#/c/99235 relevant to your interests
<JayF> smoser: https://review.openstack.org/#/c/99235 possibly also relevant to you (ironic-spec for support for configdrive)
<JayF> lauris: hey, if you look in /run/cloud-init/ you should have two json files which might have more information about the failure
<smoser> lauris, there is probably a stack trace somewhere or information in /var/log/cloud-init-output.log
<smoser> flozano, i'm not opposed to that. file a bug if you'd like. its not a unreasonable request.
<lauris> JayF, there's no such folder /run/cloud-init
<lauris> smoser, this is the only information I get from the log: http://pastie.org/9650295
<lauris> not much of the details why it fails
<smoser> you'll need console log i think. not sure what that is that i'm seeing output of.
<smoser> in 0.7.2 command output (such as yum install) probably went to /dev/console.
<smoser> so ec2-get-console-output might have it.
<lauris> i can check the journal
<lauris> i think it went there
<lauris> no additional information there
<smoser> i really do not understand how pip can be so prevelant.
<smoser> and i even less understand how openstack c-i can rely upon it.
<smoser> i see pip-timeout related failures in at least 1/3 devstack startups.
<JayF> Openstack-infra runs a mirror
<smoser> what garbage. i even looked at doing that, and *that* timed out over and over again.
<smoser> but at least that indicates i was going down the right path.
<smoser> :)
<JayF> I mean, ask in -infra
<JayF> I bet they'd be willing to tell you how they do theirs (or point you at code)
<smoser> lauris, https://tickets.puppetlabs.com/si/jira.issueviews:issue-html/MODULES-1315/MODULES-1315.html maybe ?
<smoser> JayF, oh, there is a general "pip mirror" code
<JayF> I think they use something like bandersnatch?
<JayF> b/c it used to be they'd only mirror requirements and requirements requirements
<lauris> smoser, can't see how it is related?
<lauris> it is cloud-init who fails
<smoser> http://aboutsimon.com/2012/02/24/create-a-local-pypi-mirror/ thats what i looked at. seemed reasonable
<lauris> if I start puppet agent manually it works fine
<JayF> but now they do the whole thing to support stackforge folks who are outside global-req
<smoser> lauris, no. cloud-init registers failure of something else
<smoser> that printed out to stderr: 
<smoser> Failed to issue method call: No such file or directory
<lauris> so? that doesn't tell much about the problem
<smoser> theres probably a fuller stacktrace in your log. and it is possible that cloud-init ran 'systemctl' , and that caused it. but i'm not sure.
<lauris> if I run systemctl manually it works fine, both enable and start
<harlowja> JayF thx, i'll forward that to some folks
<JayF> harlowja: make sure to look at the referenced nova spec as well
<JayF> harlowja: since this touches the virt driver
<harlowja> yup yup
<lauris> smoser, I checked console log as well, same information as i cloud-init.log
<harlowja> btw, smoser and i updated https://etherpad.openstack.org/p/cloud-init-next with more goodies
<harlowja> JayF harmw ^ 
<lauris> smoser, it's fedora, by the way
<harlowja> smoser https://code.launchpad.net/~harlowja/cloud-init/no-prettytable/+merge/238491 let me know what u think :-P
<harlowja> example @ http://paste.ubuntu.com/8566656/
#cloud-init 2014-10-17
<ancoron_z> Hello everyone. I have a small question about errors during cloud-init execution
<ancoron_z> is it possible to have them reported using OpenStack events or messages?
<smoser> ancoron_z, you could have somethign to that.
<smoser> recent cloud-init writes /run/cloud-init files
<smoser> that you could read and pass back/post somewhere.
<smoser> but there isn't a place to report back to in openstack
<ancoron_z> smoser: I was digging through the code a bit and found the notion of a "PublishErrorsHandler" and a fallback to some OSLO-related handler: https://github.com/stackforge/cloudbase-init/blob/master/cloudbaseinit/openstack/common/log.py#L503
<ancoron_z> I just didn't find any documentation what this actually means or is supposed to do
<JayF> That's not cloud-init.
<JayF> That's something else.
<ancoron_z> Ah, sorry. Yes, I see.
<JayF> No problem, just letting you know you're probably in the wrong place.
<JayF> That's also a pretty new project as well, I'm curious how much of cloud-init's functionality they've dup'd already
<ancoron_z> Yes, I'm trying my first steps with it currently.
<JayF> If you're interested in cloud-init, it's hosted in launchpad, and has packages for most distributions
<ancoron_z> yes, I found it already - looking at trunk branch currently
<JayF> And generally either cloud-init or nova-agent is used by most folks to configure cloud instances on boot for Openstack.
<JayF> I think cloudbase-init is just trying to generally add competition to that space; I know nothing other than the openstack-dev email about it.
<ancoron_z> My first use case is support for Windows - for whatever cloud use-case (??? I wouldn't have one...)
<alexpilotti> JayF: cloudbase-init is not trying to add competition
<alexpilotti> JayF: we simply started the project to support Windows in OpenStack and other clouds
<JayF> alexpilotti: aha, awesome :)
<alexpilotti> JayF: and weâd happy to merge with cloud-init under the proper conditions
<JayF> alexpilotti: in that case, I'm sure one day I'll be using your stuff too, haha
<alexpilotti> heh
<JayF> alexpilotti: I work on Openstack Ironic w/Rackspace. We use cloud-init extensively for our stuff (which is all linux-images atm)
<alexpilotti> JayF: nice, I know that the HP folks are working on Ironinc on the Windows side (using cloudbase-init)
<alexpilotti> JayF: we also started to work with Ironic, itâs (ahem ironically) the only major bare metal deployment prject we didnât contribute to
<JayF> Spiffy, like I said, knowing it's focused on windows means I'll likely end up chatting and working with you as well at one point :)
<alexpilotti> JayF: as we ported Ubuntu MaaS and Crowbar to Hyper-V/Windows
<JayF> Ah, I don't know things about Crowbar
<JayF> I mean, we wrote a dpeloy driver for ironic, we're pretty embedded into that, haha
<alexpilotti> JayF: SUSE is using it, we did the port with them more than 1 year ago
<JayF> nice
<alexpilotti> but considering that Crowbar as a project is getting nowhere
<alexpilotti> the remaining alternatives are Ironic and MaaS
<alexpilotti> we just finished the latter, so uitâd be time to start helping out on Ironic as well :-)
<JayF> I mean, I have trouble finding affection for MaaS
<alexpilotti> câmon is a nice tool
<JayF> since it's very limited scope and was basically developed to integrate with Openstack ... and all that dev work went into something Canonical specific instead of Ironic :(
<alexpilotti> well, competition helps IMO
<alexpilotti> anyway, weâd like to do some more work for WIndows on Ironic
<JayF> Well right now I'd think your likely best bet is the agent driver that we've written
<JayF> since it's the only one that support whole disk imagers
<JayF> *images
<alexpilotti> k
<JayF> I mean, pretty much it just puts a glance image onto a disk
<alexpilotti> is it on stackforge?
<JayF> it's in ironic proper
<JayF> just the agent deploy driver
<alexpilotti> cool
<JayF> (the other one is called pxe and utilizes iscsi, but atm doesn't support anything but pxe booting forever)
<alexpilotti> that should make things transparent, like curtin for MaaS
<JayF> if you had an image that would run windows on your hardware
<JayF> I'd imagine Ironic would and could deploy it today
<JayF> using the agent driver
<alexpilotti> once the image boots and cloud-init  /cloudbase-init or whatever else starts
<alexpilotti> you just offer standard Nova metadata via HTTP?
<JayF> If your cloud is setup to expose a metadata service
<JayF> Ironic is like a hypervisor in the ecosystem
<JayF> Nova-compute has a driver which talks to the Ironic-API to provision nodes
<alexpilotti> cool, I was expecting that
<JayF> not much differently than it would, say, talk to a xenapi
<alexpilotti> yep, Iâm aware of the driver
<alexpilotti> the only thing I didnât check yet, if there are changes in the metadata model
<JayF> I mean, not at all
<JayF> we're using a downstream patch at Rackspace to support ConfigDrive
<alexpilotti> perfect
<JayF> but that's actively being upstreamed
<JayF> and we're open about what/how we run even if it's not in Ironic proper yet
<alexpilotti> another dummy question, what lights out options does ironic support?
<JayF> feel free to idle in #openstack-ironic and ask questions :)
<alexpilotti> I mean IPMI, ATM, etc
<JayF> alexpilotti: lights out?
<JayF> alexpilotti: ah
<JayF> alexpilotti: we call those currently "Management" or "Power" drivers
<JayF> there's two for IPMI (one shells to ipmitool; this is what we run, one uses a native ipmi python library)
<JayF> one for iLO that supports doing the deploy via virtual media instead of pxe (as well as just talking BMC to the iLO)
<JayF> one for DRAC, one for iBoot, one for SNMP-driven PDUs
<JayF> that's what I can think of off the top of my head
<JayF> oh yeah, the AMD seamicro boxes too, they have a management driver
<alexpilotti> ah ok, so no ATM?
<JayF> ATM?
<alexpilotti> the one that comes with Intel vPro
<JayF> I don't know? Apparently not, then?
<alexpilotti> AMT, sorry
<JayF> Yeah, I haven't heard of it
<JayF> but like I said, we use agent_ipmitool driver
<JayF> so that's what I know the most about :)
<alexpilotti> http://en.wikipedia.org/wiki/Intel_Active_Management_Technology
<alexpilotti> let me switch to the ironic channel :-)
<ancoron_z> Isn't AMT related to WS-MAN?
<ancoron_z> Oh yes, found it again: https://software.intel.com/en-us/articles/ws-management-and-intel-active-management-technology-a-primer
<ancoron_z> sometimes, it would really be nice if all would colaborate on a standard...
<smoser> hey harlowja 
<smoser> tell me how youou'd do this.
<harlowja> smoser sup
<smoser> i need to edit a file in /etc/
<smoser> as the nova user
<smoser> and lock it while editing is taking place
<smoser> and that file owned by root
<smoser> one idea is a util program that does that. and put that program in /etc/nova/rootwrap.d/
<smoser> but i want to know how the master would do it.
<harlowja> lol
<harlowja> lock it from whom?
<smoser> advisory locking
<smoser> as in it can only ever exist in a correct state, and when i'm editing it, then 2 processes editing it need to not collide.
<smoser> hm.
<smoser> thats assuming (i was) that nova compute is multi-threded
<smoser> but now i think i'm wrong on that.
<harlowja> nah, u are right, it is
<smoser> so maybe i dont need the locking per say.
<harlowja> its eventlet multi-threaded, which for all reasoning is 'multi-threaded'
<harlowja> so i think u need to make a rootwrap.d program (to get around the nova user problem)
<harlowja> and then have that program use https://github.com/openstack/oslo-incubator/blob/master/openstack/common/lockutils.py#L55 
<harlowja> (or similar)
<harlowja> to avoid collisions
<smoser> yeah. i didn't know of os.common.lockutils
<smoser> was just oging to use python lockfile (which is probaly what that uses)
<smoser> hm..
<harlowja> not really 
<harlowja> python lockfile sorta not so good
<harlowja> ^ is better
<smoser> nice.
<harlowja> 'Since the lock is always held on a file
<harlowja> descriptor rather than outside of the process, the lock gets dropped
<harlowja> automatically if the process crashes, even if __exit__ is not executed.'
<harlowja> python lockfile (this is being taken over by openstack btw) is getting better
<harlowja> *see https://review.openstack.org/#/c/122253/ 
<harlowja> for that takeover
<harlowja> which is still failing jenkins, arg
<smoser> ok. 
<harlowja> so there u go
<harlowja> :-P
<smoser> i'm pretty sure i could trick some program already in rootwrap.d to do what i wanted.
<harlowja> likely
<smoser> hopefully later today i'll forget that i opened /etc/nova/rootwrap.d/
<harlowja> hahahahha
<harlowja> i avoid looking there
<harlowja> *scary*
<smoser> kill_shellinaboxd: KillFilter, root, /usr/local/bin/shellinaboxd, -15, -TERM
<harlowja> :-/
<smoser> that one sounds good. :)
<smoser> but 'dd', 'cp', all sorts of stuff that can do arbitrary things.
<harlowja> yup
<harlowja> thats why i avoid looking there
<harlowja> i don't want to cry
 * harlowja still wishes the openstack community would just make sudo better
<harlowja> but that never seemed to happen
<harlowja> or do something else, lol
<smoser> well, sudo or not. if you have arbitrary code execution of nova user. you ahve root.
<harlowja> sure
<smoser> so in a sense, you can just make it easier and run as root :)
<harlowja> :)
<smoser> so is there some way to do this wrapper thing other than like above ?
<harlowja> run as root?
<harlowja> lol
<harlowja> then just do it in nova code (with a lock there)
<smoser> no. i meant, is the 'kill_shellinaboxd' the type of thing.
<harlowja> write to tempfile, run as root to copy it (do this in a locked block)
<smoser> i just add a command to my program and then have to deal with knowing the path to my program
<smoser> thats the pita part of it.
<harlowja> write from nova -> tempfile, use rootwrap + cp, lol
<smoser> yeah, but rootwrap wont get me atomic updates.
<smoser> er.. cp wouldnt .
<smoser> anyway, thanks for your help.
<harlowja> how so, wrap the code in nova that is doing this in a lock
<harlowja> with lock:
<harlowja>    get tempfile
<harlowja>   do stuff
<harlowja>     call cp with rootwrap
<smoser> right. but that wouldnt be atomic.
<smoser> i need os.rename
<harlowja> isn't mv the same (use mv instead of copy?)
<JayF> smoser: you should consider nova compute as multithreaded
<JayF> smoser: because many clustered hypervisors (like Ironic/VMWare) can have multiple nova computes
<JayF> smoser: even though it sounds like you have to do that anyway
<harlowja> well anything, even using eventlet is still conceptually multi-threaded
<harlowja> eventlet doesn't take that part away, it just hides it a little
<harlowja> eventlet == temptress imho 
<harlowja> tempts u into a pit that u can't get back out of
<harlowja> durn systemd, lol
<harlowja> https://code.launchpad.net/~harlowja/cloud-init/fixed-rhel7-test/+merge/238766
<harlowja> guess i'm the first one to run tests no rhel7, lol 
<harlowja> *on rhel7
<JayF> I mean, I don't know about running tests
<JayF> we sure as hell use cloud-init on centos7 though
<harlowja> ya, before building an rpm i have a little piece of bash script that runs the tests and such (then applies a few internal patches)
<harlowja> and just got asked to build a custom one for rhel7 (instead of using the epel one)
<harlowja> JayF how are u building cloud-init (using the epel one)? wondering cause using the buildin way of using tools/brpm  required some tweaks for rhel7
<harlowja> *for rhel77
<gholms> harlowja: What if you just copypaste Fedora's spec file?
<harlowja> nearly, i fixed it all up enough to get this to work
<harlowja> using some parts of the fedora one
<harlowja> https://code.launchpad.net/~harlowja/cloud-init/rpm-spec-fixups and others i'll push up
<harlowja> https://code.launchpad.net/~harlowja/cloud-init/fixed-rhel7
<harlowja> gholms check those out, trying to make it work in the easiest manner
<JayF> harlowja: you can reproduce our build using  https://github.com/racker/cloud-init-docker-build
<harlowja> git clone https://github.com/jayofdoom/cloud-init-fedora-pkg
<harlowja> :-/
<harlowja> questionable, lol
<JayF> haha
<JayF> those are all moved to /racker/
<JayF> so sorry if the pointers are outta date a little
<harlowja> hehe
<harlowja> ideally u should be able to checkout cloudinit; run make rpm
<JayF> but all our builds come from that docker stuff
<JayF> Well we absolutely can't because we have our downstream patch still
<harlowja> or if u have patches run packages/brpm -p $patch1 -p $patch2
<JayF> but I agree with the general gist of what you say
<JayF> I just like using docker buiilders like that because you can build on any machine that has docker
<JayF> you're welcome to use that, fork it, etc
<JayF> I'm going to go back to not looking at a computer screen and hoping it nukes the headache
<harlowja> thx, although cloud-init building of rpms should work (instead of not) :-P
<JayF> gl and if you have specific questions not sure I can answer them because all my knowledge is in those scripts and I recovered the space in my brain :P
<harlowja> np
<JayF> but feel free to ask anyway :P
<harlowja> i have a similar script, although it doesn't use docker, trying to rid myself of any patches (which are similar to the ones there in that repo)
<harlowja>  https://code.launchpad.net/~harlowja/cloud-init/rpm-spec-fixups ...
<JayF> yeah I'm not 100% sure I didn't initially make those cloud-init-{distro}-pkg repos, only have maintained them
<JayF> but I'd suspect they all started from a shipped upstream rpm and then we made changes
<JayF> but yeah, good luck and the work is appreciated :)
 * JayF &
<harlowja> http://bazaar.launchpad.net/~cloud-init-dev/cloud-init/trunk/files/head:/packages/ :-P
<harlowja> u should use that, ha
#cloud-init 2015-10-13
<ndonegan> Having interesting issues with Cloud-init/boto and Contrail.
<ndonegan> The fault is definitely with Contrail as it's returning a 502 "encapsulated" in a 200.
<ndonegan> So suddenly boto starts doing requests for "http://169.254.169.254//2009-04-04/meta-data/block-device-mapping/HTTP/1.1%20502%20Bad%20Gateway etc as it's a bit dumb.
<ndonegan> The problem is that cloud-init still seems to consider this a good run against the Ec2 source, and doesn't fall through to a "None" data source which provides a userdata_raw for phonehome saying things as are screwed up.
<ndonegan> Getting Contrail to fix their side, but would be nice to have some way of flagging this in the future.
<ndonegan> Would extending the Ec2 source so that you can specify that X set of fields have to be populuted be a way forward?
#cloud-init 2015-10-14
<natorious> morning
<Odd_Bloke> o/
<Odd_Bloke> smoser: claudiupopa: harmw: harlowja: Around?
<smoser> hey!
<smoser> so.. i'm sprinting right now, so had kind of expected no meeting today, and kind of said that last week.
<smoser> that said... i'm here. whats up Odd_Bloke
<Odd_Bloke> Oh, I must have missed the "no meeting" last week.
<Odd_Bloke> *the "no meeting" comment
<smoser> how goes life, Odd_Bloke
<Odd_Bloke> Life is pretty good, thanks.
<Odd_Bloke> The work that we were aiming to land for wily has been pushed to the start of the x cycle, so I should be able to get back to devoting time to cloud-init 2.0. \o/
<smoser> hey, good.
<smoser> so then.
<Odd_Bloke> So I'll revisit that taskflow change this week.
<smoser> we have lots of work to do :)
<smoser> i looked at deps on taskflow...
<smoser> very many
<Odd_Bloke> We discussed that before, harlowja says that a lot of those are only needed for specific functionality.
<Odd_Bloke> So could be changed to Recommends/Suggests (albeit with some work to ensure that they were only imported when needed).
<natorious> I'd figured no one would be here too :)
<smoser> alright. thats the biggest thing though.
<smoser> is just dependencies.
<smoser> i talked with someone last night who was lamenting the io that bringing up cloud-init on boot does.
<smoser> and having a huge stack of dependencies isn't going to help that.
<natorious> could have used some taskflow f/ configdrive for sure
<smoser> so i really have a goal of keeping the list of non-standard-library very small.
<Odd_Bloke> If we're worried about IO/startup time, why are we (still) using Python? :p
<smoser> thats a fair point.
<Odd_Bloke> Also, compared to a single call out to the network, I doubt I/O is actually that big a deal.
<Odd_Bloke> (Unless we're talking about I/O on a "hard drive" that's actually over the network, which shouldn't be the case for anything cloud-init is running from)
<openstackgerrit> Nate House proposed stackforge/cloud-init: [WIP] Adds ConfigDrive datasource.  Throwing this out there for some initial feedback.  https://review.openstack.org/234805
<natorious> \o/
<smoser> Odd_Bloke, well, this particular user was suggesting that just bringing up cloud-init was a significant cost.
<smoser> but yeah, i told him too that there are likely other reasons (some of them designed) that we are slowing down boot.
<smoser> ie, cloud-init is enforcing bottlenecks in boot by design so that it can allow user to insert actions at those points.
<natorious> it could have been like one of the devs from the go fork CoreOS uses trolling
<natorious> smoser: I hadn't added any tests for that ^^ yet.  Looking to see how far off base I'd ventured beforehand
<Odd_Bloke> This is a difficult conversation to have without benchmarks.
<smoser> it is indeed.
<smoser> i do want to have benchmarks.
<Odd_Bloke> Or, indeed, targets for those benchmarks.
<smoser> yeah.
<Odd_Bloke> And, to some extent, we run in to a features vs. speed problem.
<Odd_Bloke> smoser: Unrelatedly, is looking for system_info/default_user/name in ssh-keygen -f "/home/daniel/.ssh/known_hosts" -R 130.211.103.50
<Odd_Bloke> FFS.
<Odd_Bloke> smoser: Unrelatedly, is looking for system_info/default_user/name in /etc/cloud/cloud.cfg a safe way for third-party software to determine the default username?
<Odd_Bloke> smoser: Or is there a better cloud-init-provided place to look?
<openstackgerrit> Nate House proposed stackforge/cloud-init: [WIP] Adds ConfigDrive datasource.  Throwing this out there for some initial feedback.  https://review.openstack.org/234857
<smoser> harlowja, in cloud-init 0.7.x what is the command to generate the rtd stuff ?
<smoser> ie, if we want to render that outside of readthedocs
<Diplomat> Hello! I have a quick question. Does anyone know how to set that password "adminPass" that OpenStack generates as root password?
#cloud-init 2015-10-15
<geomyidae_> So, what does everyone do for when they need to lay down lots of configuration files?
<geomyidae_> The upstart mimetype is nice, until you want to have configuration files read by those upstart scripts, and now all of the sudden you're on your own for getting them on to the Filesystem.
<geomyidae_> I assume I'm not the only one with this problem - but the options I have inside of cloud-init seems rather limited (write_files and concat all of my config into my cloudconfig.yaml) or (wrap each config file in a shell script that installs them, then add those scripts in my multipart file) or (something cleaner?)
<geomyidae_> lol
<geomyidae_> The handle_type method must be like:
<geomyidae_> def handle_part
<geomyidae_> cool.
#cloud-init 2015-10-16
<mattymo> how can I define a value as "undefined" in a cloud-init template. For example, a puppet config line should not be specified in puppet.conf
<nsv> hello ! how can i start N copies of the same script and keep their count (restart) if they die ?
<nsv> from user-space, i guess, not root
<mattymo> nsv, use supervisor?
<nsv> http://supervisord.org ? oh, thanks, it fell out of my head - was looking at runit
#cloud-init 2015-10-17
<openstackgerrit> Jeremy Stanley proposed openstack/cloud-init: Update .gitreview for new namespace  https://review.openstack.org/236289
#cloud-init 2016-10-17
<amitprakash> Hi, would it be possible to use cloud-init to populate specific conf.d files?
<amitprakash> Hi, would it be possible to use cloud-init to populate specific conf.d files?
<jrwren> amitprakash: i don't know what that means. There is a write_files module which can write any file on the system.
<amitprakash> jrwren, aight thanks :)
<amitprakash> jrwren, what if I want to pass things link nproc to write_files ?
<amitprakash> specifically, I wish to specify number of cpus, ram available etc
<jrwren> I don't understand that. If you write it to a file, it will work.
<amitprakash> jrwren, let me rephrase, in the content section for write_files, how do I generate such values on the fly?
<amitprakash> Because from what I am reading content can contain static strings
<jrwren> You do not, out of the box.
<jrwren> I have, in the past, made my own template system to generate the cloud config and launch instances.
<amitprakash> jrwren, any documentation against how I can do the same?
<amitprakash> Or if you can share your work instead?
<jrwren> amitprakash: the work i did was not opensource, but it was only python Template strings.
<amitprakash> aight, thanks. I'll google around for similar approaches :)
<rharper> amitprakash: you can always write a shell script to do what you want, (fetch nprocs and write out your conf files) and then inject the script via write-files and call it via runcmd
<rharper> smoser: when you get a change, I'd like to discuss https://bugs.launchpad.net/cloud-init/+bug/1619423 re: Ubuntu-core
<smoser> rharper, yeah.
<rharper> *chance*
 * rharper drinks more coffee
<smoser> rharper, https://hangouts.google.com/hangouts/_/canonical.com/hangout-smoser
<rharper> k
<smoser> http://paste.ubuntu.com/23338848/
<smoser> http://paste.ubuntu.com/23338850/
<smoser> http://paste.ubuntu.com/23338852/
#cloud-init 2016-10-18
<rharper> smoser: what do you think about adding a cmdline check in cloud-init for net-ifnames=0 ?  I just encountered an issue on a rpi2 16.04 image; the release kernel didn't pass net.ifnames=0;  I dist-upgraded and the new 4.4 kernel did; cloud-init wrote out the 50-cloud-init.cfg interfaces file with an enxXXX ... I wonder if we could detect that situation and re-run network configuration
 * rharper glares at the rpi2 firmware which switched that on users 
<smoser> rharper, i don tknow what would have added net.ifnames=0
<smoser> that is odd
<smoser> in a dist-upgrade
<smoser> almost seems like something was broken to not have passed it before
<rharper> smoser: oh, they did on purpose
<rharper> default boot parameters for the platform
<rharper> that's a separate bug
<rharper> they were dealing with naming issues with usb'based adapters and systemd for a bit; so likely explains the change but really shouldn't have changed;
<rharper> but wondering in general if we should/could detect that transition
<smoser> rharper, i htink we never got to this...
<smoser> one path would be that on first instance boot, cloud-init writes what the names are
<smoser> and then ever after insists that they are what it thinks they should be
<rharper> smoser: right
<smoser> we do this if we have a datasource, we rename on every boot
<rharper> hrm, I Have a nocloud-net datasource
<rharper> but not with a net config included
<smoser> right
<rharper> so this is fallback only
<smoser> right. so there, it doesnt have any memory
<rharper> I see
<smoser> but i guess, yeah, it should
<rharper> we could write it out
<rharper> in the instance dir
<smoser> yeah.
<rharper> ok
<rharper> I'll play with that
<smoser> i think this area is going to get sticky.. with respect to how different datasources add and remove nics and what not.
<rharper> hotadd/remove, ... yeah
<smoser> and cold-add/remove too
<smoser> :)
<rharper> we should carve out some time for discussion on nic hotplug/unplug this cycle
<rharper> sure
<rharper> and netplan
<rharper> =)
<prometheanfire> smoser: anything I need to do for https://code.launchpad.net/~prometheanfire/cloud-init/+git/cloud-init/+merge/307969
<smoser> prometheanfire, you have good patience
<smoser> thank you
<prometheanfire> :D
<smoser> prometheanfire, merged. and pushed.
<prometheanfire> thanks :D
<prometheanfire> when is the next release? (just curious)
<smoser> i dont know. theres a couple things i need to get in. there isnt a lot of stuff since 0.7.8 really.
<prometheanfire> np, just curious, I already am applying that patch iirc
<prometheanfire> so no rush
<smoser> utlemming, https://code.launchpad.net/~utlemming/cloud-init/+git/cloud-init-1/+merge/307391
<smoser> pretty sure you needto add a Choices entry
<smoser> please test and run 'dpkg-reconfigure' to verify function
<utlemming> smoser: ack will get that to you today
<utlemming> smoser: update the branch and confirmed it works, also rebased it on the latest ubuntu/devel
<utlemming> s/update/updated
<smoser> utlemming, ok. fwiw, i think i'd rebase -i rather than merge.
<smoser> but i can do that all the sam.e
<utlemming> I sort of like to keep the history, but yeah
<harlowja> smoser u getting chopped
<harlowja> https://review.openstack.org/#/c/388170/1/reference/projects.yaml
<harlowja> oh noes
<harlowja> shall i say don't chop sscott
<harlowja> ?
<harlowja> never chop scott!
<harlowja> lol
<smoser> oh. :-(
<smoser> oh well.
 * harlowja will have to start the 'never chop scott' campagin
<harlowja> never chop scott!
<harlowja> never chop scott!
<harlowja> lol
#cloud-init 2016-10-19
<mdorman_> running into an issue on EL7 where the network generate_fallback_config process where reading the /sys/class/net/eth0/carrier and /dormant generate an IOError (Invalid Argument) if the NIC isnât up yet.  I think we have a fix just by catching the IOError exception and passing.  Iâm looking through bugs to see if anything is there for this already, but not coming up with anything.  does this sound familiar to anybody?  If no
<mdorman_> Iâll report a new bug.
<mdorman_> i think the better way to do this ( https://git.launchpad.net/cloud-init/tree/cloudinit/net/__init__.py#n139 ) is check the nicâs operstate first, and then only if itâs up check the carrier and dormant.   iâll send in a review
<rharper> mdorman_: I belive that one is known; lemme find the bug and the MR that addresses that
<rharper> https://code.launchpad.net/~harlowja/cloud-init/+git/cloud-init/+merge/305882   handles this; IIRC
 * rharper checks the channel logs
<mdorman_> thanks iâll check it out
<rharper> https://bugs.launchpad.net/cloud-init/+bug/1625766
<rharper> someone from Arch saw this
<rharper> I updated the bug description and summary to match
 * rharper links the MR to the bug as well 
 * rharper pokes harlowja and smoser for review tomorrow 
<mdorman_> cool
<harlowja> i fixed that?
<harlowja> hahaha
<harlowja> mdorman_ maybe fixed :-P
<harlowja> someone needs to merge all that stuff, lol
<mdorman_> yeah me and jim have it merged locally and are testing it.  then i will comment on the LP review with results
<harlowja> kk
<mdorman_> so far itâs looking good
<nrezinorn> that part looks great :p
<harlowja> greatttt
<harlowja> lol
<mdorman_> https://code.launchpad.net/~harlowja/cloud-init/+git/cloud-init/+merge/305882 i think we can confidently say is good
<nrezinorn> harlowja: rpm builds happily from what we can see, plan on doing roll ups for merge tomorrow .  i had a Q about the requirements.txt tho, where we dont need 2 lines in the rpm build - should i make and apply a .patch to build the RPM or is there another way to handle?
<harlowja> i did its
<harlowja> lol
<harlowja> smoser so in https://code.launchpad.net/~harlowja/cloud-init/+git/cloud-init/+merge/308304
<harlowja> if people still have cheetah installed, and there templates say to use cheetah explicitly
<harlowja> then it will still continue using cheetah
<harlowja> the default though does change
<harlowja> from
<harlowja> -            LOG.debug("Using Cheetah as the renderer for unknown template.")
<harlowja> - return ('cheetah', cheetah_render, text)
<harlowja> to jinja
<harlowja> this maybe should cause a 0.8.0 version, id
<harlowja> *idk
#cloud-init 2016-10-20
<NerdyBiker> morning all o/
<NerdyBiker> I'm having an issue when using the cloud-init chef functionality on a box that already has chef installed on it. Cloud init appears to be doing nothing, doesnt change the client.rb or the firstboot.json :S Is there an issue using it on a box with chef already installed? (cloud-init 0.7.5)
<NerdyBiker> actually it appears that the force_install isn't taking hold either. Testing this on a Centos7 machine.
<rharper> NerdyBiker: not that I know of, can you file a bug in launchpad and provide some user-data and possibly the cloud-init.log from a failed run ?
<smoser> NerdyBiker, there were recent-ish fixes in that area
<mdorman_> so weâve been testing with the following patches the last couple days (under RHEL7) and theyâre working well, and are interested in getting these merged soonish so we can get off our fork.  what can we do to help move these forward and make that happen?
<mdorman_> https://code.launchpad.net/~harlowja/cloud-init/+git/cloud-init/+merge/305882
<mdorman_> https://code.launchpad.net/~nrezinorn/cloud-init/+git/cloud-init/+merge/306562
<rharper> mdorman_: thanks for the feedback and testing on those
<rharper> smoser: is on a merge mission today
<rharper> so hopefully soon
<smoser> powersj, magicalChicken
<smoser> while ! lxc exec "$name" -- [ -f /run/cloud-init/result.json ]; do sleep 1; done
<mdorman_> rharper:  cool thanks.  please ping me or nrezinorn if we can do anything to help
<smoser> nrezinorn, ok. i'll take alook
<smoser> i have one of nrezinorn's others.
<smoser> sorry mdorman_
<mdorman_> cool
<powersj> smoser: I did have another question, do you use root to run bddeb?
<smoser> bddeb shoudl run as non-root
<smoser> i think
<rharper> powersj: smoser: right; you don't need root
<powersj> without it I got permission errors on some files in /etc/cloud/*
<rharper> after installing ?
<rharper> not following
<powersj> while building, let me pastebin
<rharper> k
<rharper> it's basically doing a debuild -us -uc (after creating tarball of the git repo in a tempdir)
<powersj> https://paste.ubuntu.com/23354559/
<powersj> (although it is apparently all on one line lol)
<rharper> powersj: what does git status show ?
<powersj> clean
<powersj> On branch master
<rharper> somethings not right, the maas-99 is only present on images that have been deployed via maas
<powersj> Your branch is up-to-date with 'origin/master'.
<powersj> nothing to commit, working directory clean
<rharper> maybe something in ENV
<rharper> for example, you'll not find the maas.cfg file in cloud-init/config/
<powersj> rharper: ah so this is on torkoal our baremetal slave, where we want to run ci integration
<rharper> but it's mentioned in the output
<rharper> I wonder if we have a leak in importing config
<rharper> nTraceback (most recent call last):\n  File "/tmp/tmpvkejmell/cloud-init-0.7.8-19-g7ae2011/tests/unittests/test_data.py", line 375, in test_unhandl
<rharper> powersj: looks like unittest isn't mocking path
<rharper> when it attempts to read config
<rharper> powersj: can you file a bug ?
<powersj> rharper: sure!
<powersj> LP# 1635350
<smoser> harlowja, ping
<smoser> http://paste.ubuntu.com/23354699
<smoser> those are on top of your sys-io-errors ... thoughts ?
<harlowja> smoser seems ok with me
<smoser> i commented on the merge
<smoser> just hit submit
<smoser> are you able to test those easiliy-ish ?
<harlowja> mdorman and nrezinorn are in a better place to test it in a fully image
<harlowja> but i can do basic stuff
<harlowja> (they are in part the image builders/owners)
<harlowja> @godaddy
<mdorman> so what exactly is the question?
<harlowja> mdorman nothing yet, will get back to u :)
<mdorman> kk
<smoser> mdorman, ok. so for the first one, i put a comment ther... it'd be nice to test my changes.
<smoser> and commented on the second one also.
<smoser> i could put toether a suggested diff if you want.
<mdorman> yeah that would be helpful.  iâm hoping to work on these this afternoon
#cloud-init 2016-10-21
<nrezinorn> what populates netcfg ? it seems to be a merger of what a system has configured already and what cloud-init has in its datasource.  running into an issue where its trying to parse 'loopback' and fails to set up eth0
<nrezinorn> temp fixed by adding an extra elif  line to handle the subnet_type == 'loopback', and that works so far.  the issue after that is that the default gateway is not being set in the ifcfg-eth0 file
<nrezinorn> any ideas on where to look / how to fix it "proper"
<smoser> nrezinorn, its quite possible it doesnt "clean" the old state out well.
<smoser> that code path can be largely unit tested i think.
<smoser> to let you play more quickly
<mdorman> âcan be largely unit testedâ meaning the tests donât exist at this point?
<mdorman> what we did as a quick fix was just added a conditional for subnet_type == âloopbackâ with a pass here:  https://git.launchpad.net/cloud-init/tree/cloudinit/net/sysconfig.py#n222   although iâm not totally clear why cloud-init is (re)configuring the lo interface in the first place.
<mdorman> so not clear to me if what we did to fix this is appropriate or not
<mdorman> didnât have a chance to look at it any further today but can probably pick back up next week
<smoser> mdorman, no.. is tested, just meaning you can modify the unit tests to do it.
<mdorman> gottcha
* barjavel.freenode.net 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
#cloud-init 2017-10-16
<smoser> #curtin
<blackboxsw> Hey folks, think it's about time for cloud-init meeting
<blackboxsw> #startmeeting Cloud-init bi-weekly status
<meetingology> Meeting started Mon Oct 16 16:06:51 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 Recent Changes
<blackboxsw> Ok last couple of weeks for our team were
<blackboxsw> Ok last couple of weeks for our team were
<blackboxsw> Ok last couple of weeks for our team were 'impacted' by a couple of work conferences for planning next release of cloud-init/curtin etc.
<rharper> o/
<blackboxsw> so things felt a bit slow. but folks have still made some good progress.
<blackboxsw> Some changes that have landed in master:
<blackboxsw> Robert Schweikert: suse cloud-config module to add zypper repos and zypp config
<blackboxsw> Robert Schweikert: Allow cloud-init.final stage to spawn infinite processes
<blackboxsw> Andrew Jorgensen: Remove prettytable dependency
<blackboxsw> Fix dhcp parsing in Artful of networkd leases for CloudStack and Azure
<blackboxsw> Updated packaging copyright file (LP: #1718681)
<ubot5> Launchpad bug 1718681 in cloud-init "Package copyright file omits Apache 2 license" [High,Fix committed] https://launchpad.net/bugs/1718681
<smoser> o/
<blackboxsw> thanks a lot for the contributions on that front folks. There have been a couple of work items that fell out of our conferences related to Ubuntu artful and systemd/networkd support so we've been workin those
<blackboxsw> on the testing front we've re-enable tox support for integration tests
<blackboxsw> and Ubuntu-only has queued a 17.1 SRU release/update into xenial and zesty
<blackboxsw> smoser: rharper powersj anyone else anything else I'm missing on recent changes?
<rharper> blackboxsw: that sounds right
<blackboxsw> ok. next topic
<blackboxsw> #meetingtopic In progress development
<blackboxsw> As mentioned, we are walking through the Ubuntu xenial/zesty SRU validation process, so I excpect we will have a release update published this week
 * blackboxsw grabs the trello card link
<blackboxsw> #link https://trello.com/c/wROS4mKT/458-sru-171
<blackboxsw> This card will move to the Done lane once we've finished publishing
<blackboxsw> I know powersj has been working the integration test front for KVM as time permits. There will be some upcoming changes there to get us more complex storage/network  testing on kvm
<blackboxsw> I know smoser is also working on a couple of Azure-related fixes for artful as well.
<blackboxsw> anything else to add there?
<smoser> https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1722668
<rharper> nothing from me
<ubot5> Ubuntu bug 1722668 in cloud-init (Ubuntu) "Azure: bouncing of network device/publishing of hostname fails on artful" [Critical,Confirmed]
<blackboxsw> #link https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1722668
<blackboxsw> thx
<smoser> that one i'm working on, and then also been trying to get lxc/mount-image-callback
<smoser> the use we ahve for 'lxc-proposed-snapshot' and also for 'mount-image-callback'
<blackboxsw> Also in the same vein of improving dev testing of Ubuntu or really any lxc image is that work smoser referenced above.
<blackboxsw> smoser: is that worth a link at the moment or does it still need polish?
<smoser> https://gist.github.com/smoser/49444542158f2e5f88f1/#file-lxc-pstart-md
<blackboxsw> sweet
<blackboxsw> #link https://gist.github.com/smoser/49444542158f2e5f88f1/#file-lxc-pstart-md
<smoser> right now that is only known to work on lxc 2.18
<smoser> i think we can make it work with earlier versions, and would like to make it work with xenial (2.02.. maybe)
<blackboxsw> yeah I just got my artful box up and was going to use that for the SRU verification
<blackboxsw> also, I think we were going to peek at a solution for the following bug:
<blackboxsw> #link https://bugs.launchpad.net/cloud-init/+bug/1722992
<ubot5> Ubuntu bug 1722992 in cloud-init "On the latest centos 7 release, we are unable to resize our instances filesystems" [Medium,Confirmed]
<blackboxsw> so there might be some minor changes  for the OpenStack/MAAS and ConfigDrive datasources
<blackboxsw> ok anything else in "In progress development"?
<blackboxsw> I know we have a queue of active reviews we need to get through. I was expecting we'll have bandwidth for that after this SRU push.
<blackboxsw> #link http://bit.ly/ci-reviews
<blackboxsw> #meetingtopic Office Hours
<blackboxsw> #info open season for discussions, bug requests, review requests for the next 30 mins
<smoser> thanks blackboxsw
<blackboxsw> no prob. I was peeking around at puppet this weekend.... might have a branch puppet local(masterless deployment) to put up this week
<blackboxsw> I sort of got distracted by shiny objects while trying to write an SRU test  for our existing puppet
<blackboxsw> config module
<blackboxsw> ok two more SRU tests  left to write for Azure and datasourceOVF. then we can start validation for the upload
<blackboxsw> office hours coming to a close. but we'll still float in here as always. Happy Monday folks
<blackboxsw> just ping us directly by IRC nick if you aren't getting a response otherwise.
<blackboxsw> tanks again.
<blackboxsw> thanks even
<blackboxsw> #endmeeting
<meetingology> Meeting ended Mon Oct 16 17:03:16 2017 UTC.
<meetingology> Minutes:        http://ubottu.com/meetingology/logs/cloud-init/2017/cloud-init.2017-10-16-16.06.moin.txt
 * blackboxsw notices I hadn't published last meeting minutes....... will push these and the last meeting minutes to https://cloud-init.github.io/
<blackboxsw> ok smoser pushed all SRU test 'scripts' I use the term loosely for a couple of the gce/azure ones as I didn't write a cmdline verbatim for the instance creation.
<blackboxsw> ok I'm going to start validating SRU bugs from the top of the card if there are no objections
<smoser> blackboxsw: thanks
<smoser> remember i put a list of commands.... for launching somewhere
 * smoser looks to find
<smoser> and also, you should/could look at using backports for your lxc
<smoser> backports has 2.18 everywhere
<smoser> and everyone who is anyone is using it :)
<blackboxsw> heh
<blackboxsw> will do.
<smoser> http://paste.ubuntu.com/25754866/
<smoser> blackboxsw: ^ that is change to lxc-proposed-snapshot to use the lxc-pstart
<smoser> assuming you have it in your path
<blackboxsw> +1 using it
<blackboxsw> man almost 50% on SRU verification
<blackboxsw> sloooow going
#cloud-init 2017-10-17
<smoser> blackboxsw: tell me what to do
<blackboxsw> smoser: sure, was making coffee, feel free to do that too
<smoser> blackboxsw: ?
<blackboxsw> ok I'm on puppet/landscape SRU verification now
 * powersj must have missed a message
 * smoser too
 * blackboxsw made coffee
<blackboxsw> :)
<smoser> ah.
<smoser> yeah, let me warm some up. tell me what sru item to work on
<blackboxsw> smoser: if you wanted to grab  TEST: [5bba5db2](https://git.launchpad.net/cloud-init/commit/?id=5bba5db2) [#1686485](http://pad.lv/#1686485) cc_ntp: fallback on timesyncd configuration if ntp is not installable
<blackboxsw> or - TEST: [10f067d8](https://git.launchpad.net/cloud-init/commit/?id=10f067d8) [#1717598](http://pad.lv/#1717598) GCE: Fix usage of user-data.
<smoser> rharper: can you look at verifying https://bugs.launchpad.net/cloud-init/+bug/1718287
<ubot5> Ubuntu bug 1718287 in cloud-init "systemd mount targets fail due to device busy or already mounted" [High,Fix committed]
<blackboxsw> or the Azure dhcp networkd test. (need to verify xenial zesty still work
<smoser> it is really just a ticky mark we're lookign for as I know you made significant effort to diagnose and verify on trunk.
<smoser> or maybe suggest to someone else if they could test with -proposed .
<blackboxsw> wow, smoser want to lopk at this. I'm seeing strange behavior from lxc
<powersj> We do need to make sure we get MAAS test results, as well as a Curtin, run with cloud-init in proposed per our SRU exception.
<blackboxsw> http://paste.ubuntu.com/25760062/  my user-data listed in /var/lib/cloud/instance/user-data.txt
<blackboxsw> inside the lxc... but cloud-init.log says: 2017-10-17 15:21:16,445 - cc_runcmd.py[DEBUG]: Skipping module named runcmd, no 'runcmd' key in configuration
<powersj> blackboxsw: is runcmd indented under puppet?
<blackboxsw> yet is saw the puppet config key and ran that module
<blackboxsw> ahh lemme see
<blackboxsw> bah
<blackboxsw> thanks powersj
<blackboxsw> dumb
<blackboxsw> what's a silly bit of whitespace between friends
<blackboxsw> #timeforstrictschemavalidation
<blackboxsw> I love how often I shoot myself in the foot w/ writing the yaml file
<blackboxsw> ok done with landscape and puppet SRU verfication
 * blackboxsw moves on to - TEST: [f761f2b5](https://git.launchpad.net/cloud-init/commit/?id=f761f2b5) [#1715738](http://pad.lv/#1715738) [#1715690](http://pad.lv/#1715690) cloud-config modules: honor distros definitions in each module
<rharper> smoser: yes I'll look at that one (mounts)
<blackboxsw> I'll also spin up a xenial-daily on aws for the ipv6 test
<blackboxsw> ok done w/ #1715738
<blackboxsw> ok done w/ bug#1715738
<blackboxsw> onto aws ipv6
<smoser> blackboxsw: sorry...  so on http://pad.lv/#1686485
<smoser> you were the test you showed didnt really do much... right?
<smoser> or was i missing something
<smoser> you just tried an invalid 'ntp:' config.
<blackboxsw> smoser: that ntp config is valid and should install only the ntp package not timesyncd on xenial zesty
<blackboxsw> an emty ntp config only installs the 'ntp
<blackboxsw> an emty ntp config only installs the '$ntp' package
<blackboxsw> on snappy i'd expect that ntp doesn't get installed
<blackboxsw> with that same config
<blackboxsw> but yeah the test  didn't intend to test much other than ntp being installed (not broken by our  snappy-related  changes
<blackboxsw> admitedly, that test doc needs work, as I have invalid comments about spacewalk/intent there
<blackboxsw> I have a couple other tests docs that I've fixed as I went through the testing, I'll copy them into my sru-info in the next couple mins
<blackboxsw> and smoser please review the bug verification suggestions I had for these bugs as you are already doing to make sure I
<blackboxsw> am not going crazy (or testing nothing)
<smoser> blackboxsw: thanks.
<smoser> i think you probably gave invalid config there.
<smoser> ntp:
<smoser> oh. guess not.
<smoser> $ python3 -c 'import yaml;  print(yaml.load("ntp:\n"))'
<smoser> {'ntp': None}
<blackboxsw> If both pools and servers are
<blackboxsw>                          empty, 4 default pool servers will be provided of
<blackboxsw>                          the format ``{0-3}.{distro}.pool.ntp.org``.
<smoser> YYy
<blackboxsw> :)
<smoser> actually.
<blackboxsw> yeah we had a discussion w/ rharper on that when I was doing json schema definition for that module
<smoser> code though does
<smoser>   if not isinstance(ntp_cfg, (dict)):
<blackboxsw> so it should default
<smoser> raise runtiome
<smoser> i sued
<smoser> used
<smoser> printf "%s\n%s\n%s\n" "#cloud-config" "ntp:" " pools: []" > my.cfg
<blackboxsw>     ntp_cfg = cfg.get('ntp', {})  # at the start though
<blackboxsw> so it'll default to empty dict if None
 * blackboxsw checks my python 
<blackboxsw> umm
<blackboxsw> bah
<blackboxsw> right if None is actually set for the key, then it falls over as you said, becuase
<smoser> mine works.
<smoser> and verified.
<smoser> are you putting stuff int he bugs ?
<blackboxsw> I was going to put the SRU templates in all the bugs once verification is done (and my test scripts are vetted ;) )
<blackboxsw> I can start putting the templates up on each bug description for the logs I've already handled
<smoser> i'm not rushed on it.
<smoser> i'll update the sru template that have.
<blackboxsw> but, do you think it's a good idea to put them there?
<smoser> would like to show results too...
<blackboxsw> sounds good.
 * blackboxsw needs to run an errand back in a bit
<smoser> powersj: i remember that i was supposed to provide a list of "launch on cloud" commands
<smoser> from our sprint
<smoser> i dont know that i did
<powersj> smoser: correct
<smoser> http://paste.ubuntu.com/25760727/
<powersj> or a link to a gist :)
<smoser> that is what i have.
<smoser> just written down once during an sru when i wanted to validate stuff.
<powersj> smoser: awesome
<intheclouddan[m]> has anyone run into issues with cloud-init and creating multiple directories with mkdir -p? I'm passing in a shell script on AWS that has mkdir -p /opt/path1 /var/log/path1 but when I look at the output of cloud-init it's only showing mkdir =p /opt/path1....I'm really confused as to how this could be happening
<smoser> intheclouddan[m]: can you give config you're  using ?
<smoser> you're using runcmd?
<smoser> runcmd:
<smoser>  - [sh, -c, 'mkdir /foo//bar/ /zee/wark']
<smoser>  - mkdir /foo/bar /zee/wark
<smoser>  - ['mkdir', '/foo/bar', '/zee/wark']
<intheclouddan[m]> no passing in a bash script
<smoser> well, output shoudl be collected in /var/log/cloud-init-output.log
<smoser> i'd look there for errors.
<smoser> and also /var/log/cloud-init.log
<smoser> for WARN
<blackboxsw> nice paste reference smoser
 * blackboxsw is trying to figure out (remember) again how I setup the ipv6 association on an instance 
<blackboxsw> it seems I had it setup on my xenial vm, but not on my zesty vm
<blackboxsw> ... ec2 that is. gotta dig through the docs
 * blackboxsw is specifically not asking the tome of smoser knowledge for this, because I want to make this painful for me so I learn it 'right'
<rharper> blackboxsw: likely a flag during instance launch under advacned
<rharper> google knows the awscli command to toggle it
<blackboxsw> heh, tome of rharper knowledge.
<rharper> well, possible answers book
<blackboxsw> hah
<rharper> smoser: testing underway on the fstab one;  an up-to-date xenial VM falls over right away;  -proposed is 8 reboot loops in with no issues;  how far do we want to run up the count to declare success ?
<rharper> smoser1: testing underway on the fstab one;  an up-to-date xenial VM falls over right away;  -proposed is 8 reboot loops in with no issues;  how far do we want to run up the count to declare success ?
<rharper> blackboxsw: where are we updating our test-case and results for the SRU ?  a single bug, or the various bugs we're validating ?
<blackboxsw> rharper: I've only so far been adding a log comment to the megabug. 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> but when done, all test verification and log output will be updated  on each specific bug description
<blackboxsw> so each separate bug that relates to ubuntu will have it's desc updated with verification script  && results
<blackboxsw> s/it's/its/
<rharper> blackboxsw: ok, so I'll keep my own log for this specific bug, and we can append to both places as needed
<rharper> I think I'm going to call success on this case, 1) the change ensures that datasourceOVF doesn't poke any block device unless it has iso9660 files on that; I can verify that current cloud-init pokes *each* block device and -proposed pokes *none*;  I've got about 28 reboots with no issue so far.
<blackboxsw> ok sounds good rharper
<blackboxsw> thanks for the reboot run. just attaching output of the reboot script w/ anecdotal evidence of # of successful reboots should be good
<blackboxsw> I just attached updated SRU validation for ec2 ipv6 support to the megabug
<blackboxsw> found the cli params needd
<blackboxsw> aws ec2 assign-ipv6-addresses --network-interface-id eni-3b32d910 --ipv6-address-count 1
<blackboxsw> then clean-reboot (rm -rf /var/log/cloud-init* /var/lib/cloud*);
<blackboxsw> smoser: rharper anyone working on - TEST in artful: [9d2a87dc](https://git.launchpad.net/cloud-init/commit/?id=9d2a87dc) [#1718029](http://pad.lv/#1718029) Azure, CloudStack: Support reading dhcp options from systemd-networkd.?
<rharper> blackboxsw: I'm not, collecting my logs for the fstab one
<blackboxsw> and s-"=frequent IRC quits"-moser is probably dealing with network issues today :)
<smoser> https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1724354
<ubot5> Ubuntu bug 1724354 in cloud-init (Ubuntu Zesty) "WARNING in logs due to missing python-jsconschema" [Medium,Confirmed]
<smoser> :-(
<smoser> blackboxsw: that and i am transitioning (i think) to weechat from xchat+bip
<smoser> partially as a result of finicky network... i for some reason when teathering i'd get errors connecting to freenode about needing SASL and bip does not support that at all
<smoser> so, here i am learning a new irc client.
<blackboxsw> heh, agreed, I figured I'd give this irccloud a try for a year, but yeah I'm compelled to go back to xchat+bip. I'm not a fan of the forced backscroll to pull content from overnight or last week etc .
<blackboxsw> so irccloud you have to keep requesting to download a zipped collection of all IRC back channels so you can grep them etc.
<blackboxsw> smoser: I'm working on cmdline azure test for SRU
<blackboxsw> and I'll update the sru-info/bug for that when I get the magic
<blackboxsw> just ran into this v
<blackboxsw> https://github.com/Azure/azure-cli/issues/4692
<blackboxsw> on azure-cli (artful)
<blackboxsw> trying xenial
<smoser> blackboxsw: fun
<blackboxsw> yeah, tempted to just use the UI for the moment. even the cli install instructions are busticated.
<smoser> blackboxsw: hold on.
<blackboxsw> smoser: can you check your env for where you grabbed "azure" cli
<smoser> https://gist.github.com/smoser/5806147/
<smoser> 'azure' is the node version
<smoser> 'az' is the (newly favored) python client.
<smoser> i think if you use that 'az-ubuntu' it should work
<smoser> worked for me a couple days ago
<smoser> spits a command line like you'd never want to type
<smoser> $ az-ubuntu . --dry-run
<smoser> az vm create --name=smoser1017x --image=Canonical:UbuntuServer:16.04-DAILY-LTS:latest --admin-username=smoser "--ssh-key-value=ssh-rsa AAAAB3...keydata.kerhe...Hw== smoser@brickies"
<blackboxsw> awsome thanks
<smoser> blackboxsw: you can 'snap install azure-cli' . i think i just installed it with pip.
<blackboxsw> npm version works well
<blackboxsw> at least for login and group creation
<blackboxsw> still looking over your az-ubuntu
<smoser> blackboxsw: its a mess. :) 'azure-ubuntu' (which may well work if you have the npm cli) was what i had originally, but that only works with the old 'asm' mdoe.
<blackboxsw> looks like cmdline options changed
<blackboxsw> here's what works for me
 * rharper moves to zesty for the fstab tessts 
<rharper> tests even
<blackboxsw> azure vm create  -n xenial-azure-test -g srugroup1 --image-urn=Canonical:UbuntuServer:17.04-DAILY:latest --ssh-publickey-file=/id_rsa.pub --admin-username=ubuntu
<blackboxsw> hrm looks like it's still prompting me for location even though my group is defined in useast2
<blackboxsw> man naming convention is bogus eastus2 not useast2
<blackboxsw> improper ordering
<blackboxsw> just to be != EC2
<smoser> blackboxsw: it changed too between ASM and ARM mode
<rharper> what about that launcher that Robert had ?
<smoser> Robert ?
<smoser> rcj ?
<rharper> SUSE
<smoser> blackboxsw: https://gist.github.com/smoser/5806147
<smoser> that is updated, and just "worked for me" here.
<blackboxsw> trying again. I went UI for xenial
<blackboxsw> but will test
<smoser> well, it did just work for me.
<smoser> and i mentioned that you ahve to add the group
<smoser> thats a pita
<smoser> but.. oh well, and also showed how to get a list of locations.
 * smoser goes to dinner
<blackboxsw> smoser: here's the diff to your script that works for me http://paste.ubuntu.com/25761944/
<blackboxsw> since I'm also reckless and run as root in my lxc I also specify --admin-username=ubuntu as azure is smart and says (don't use root)
<blackboxsw> ok azure  verification done. thx smoser  for the az-ubuntu love
 * rharper kicks off recreate loop on zesty instance and grabs dinner 
<blackboxsw> smoser: I'm marking Azure validated for https://bugs.launchpad.net/cloud-init/+bug/1718029  for the cloudstack component. we'll probably just notify the most recent interested party
<ubot5> Ubuntu bug 1718029 in cloud-init "cloudstack and azure datasources broken when using netplan/systemd-networkd" [High,Fix committed]
<blackboxsw> rharper: same above
<blackboxsw> ok two SRU bugs remain needing verification
<blackboxsw> - TEST: [da6562e2](https://git.launchpad.net/cloud-init/commit/?id=da6562e2) [#1718287](http://pad.lv/#1718287) DataSourceOVF: use util.find_devs_with(TYPE=iso9660)
<blackboxsw> I think rharper is on this one
<blackboxsw> ^
<blackboxsw> and I think smoser is on this one - TEST: [10f067d8](https://git.launchpad.net/cloud-init/commit/?id=10f067d8) [#1717598](http://pad.lv/#1717598) GCE: Fix usage of user-data.
<blackboxsw> for tomorrow of course.
<blackboxsw> but I think that wraps up ubuntu's 17.1 SRU  for xenial/zesty
<rharper> ah, that's why we can't recreate on Zesty, it only runs the EC2 datasource since Zesty doesn't have the backwards compat ds-identify configuration; we  never run OVF on Zesty EC2 instances
<rharper> smoser: blackboxsw: so, I think in the SRU detail I'm mention that Zesty doesn't run the OVF datasource so the bug was never present there;
<rharper> blackboxsw: smoser: ok, updated fstab test-case log;  on zesty which used strict-mode ds-identify, OVF never runs so it always passed, I showed that it worked on current version and proposed didn't regress that.
#cloud-init 2017-10-18
<powersj> larsks: Could you comment on: https://bugs.launchpad.net/cloud-init/+bug/1724414
<ubot5> Ubuntu bug 1724414 in cloud-init "rhel distro selects FQDN as hostname" [Undecided,New]
<larsks> powersj: I don't have a strong preference re: that issue; just make sure that whatever hostname we pick we are consistent.  The current situation is the result of fixing an issue in which cloud-init would select the unqualified hostname initially but the fqdn would be used after a reboot (or something like that), which was causing ugly issues with stuff that used the hostname as an identifier.
<larsks> I guess I'll add that to the issue.
<smoser> blackboxsw: updated to take your patch on az-ubuntu. thanks.
<smoser> the 'azure-ubuntu' that i had was more helpful, it "knew" of regions and sizes and things. i'd like to add that back at some point, but for this at least knows about the '--image=Canonical:UbuntuServer:17.04-DAILY:latest' magic.
<blackboxsw> Network dead
<rharper> sent over the network
<blackboxsw> Heh cellular :)
<smoser> powersj: https://github.com/canonical-server/jenkins-jobs/pull/13
<powersj> smoser: thanks
<smoser> blackboxsw: bug 1724634
<ubot5> bug 1724634 in cloud-init (Ubuntu) "groups added with a user list must have all users present." [Undecided,New] https://launchpad.net/bugs/1724634
<smoser> (just fyi)
<blackboxsw> checking
<blackboxsw> smoser: nice apport bug btw :)
<smoser> blackboxsw: yeah. other than i coudlnt type 11
<smoser> (bug 1722564)
<ubot5> bug 1722564 in apport (Ubuntu) "apport question will not accept multi-character responses" [Medium,Triaged] https://launchpad.net/bugs/1722564
<smoser> blackboxsw: we get double '.txt'
<smoser> (see attached files... user_data.txt.txt and cloud-init-output.log.txt.txt)
<blackboxsw> I think I'll attach that patch to apport I suggestd to your bug there so there's something to chew on there
<blackboxsw> ohh yeah, right, cloud-init apport bug there then.
<smoser>  blackboxsw yeah... of course you need to do that. i had thought you had.
<smoser> gaughen is the maintainer of apport. lets bother her.
<smoser> (per https://launchpad.net/apport)
<gaughen> specifically me?
<gaughen> oh geez
<smoser> :)
<blackboxsw> <with devious mousish voice> ... excellent Pinky.... let's take over the Foundations team :)
<gaughen> I thought smoser you were making some broad stroke statement of the foundations team
<smoser> gaughen: well, that definiteliy would be possible. but no, you are specifically the maintainer.
<gaughen> I see that
<gaughen> thus my "oh geez"
<smoser> yeah, i wonder what other projects you maintain
 * gaughen checks to make sure cloud-init isn't on her list
 * smoser should have thought of doing that
<gaughen> so now I have to look and see why you all are talking about apport... I see bug 1722564
<ubot5> bug 1722564 in apport (Ubuntu) "apport question will not accept multi-character responses" [Medium,Triaged] https://launchpad.net/bugs/1722564
<smoser> powersj: i think that moving examples around broke/changed the default tests that are run in cloud_tests.
<powersj> smoser: how so
<smoser> ok. i guess not. its not running 'examples/' tests though
<powersj> let me see if they are enabled
<smoser> which the c-i runs
<smoser> so i ran something locally, it passed, i pushed a MP, it failed on c-i
<powersj> all tests in examples are "enabled: False" in the yaml
<powersj> ci runs the following command: sh 'python3 -m tests.cloud_tests run --verbose --os-name xenial --test modules/apt_configure_sources_list.yaml --test modules/ntp_servers --test modules/set_password_list --test modules/user_groups --deb cloud-init_*_all.deb'
<powersj> from: https://github.com/canonical-server/jenkins-jobs/blob/master/cloud-init/jobs-ci.yaml
<smoser> powersj: powersj i'm missing something
<smoser> https://jenkins.ubuntu.com/server/job/cloud-init-ci/405/console
<smoser> test_no_warnings_in_log failed (line 3497)
<smoser> the test test_user_barfoo ran
<smoser> which is from tests/cloud_tests/testcases/examples/including_user_groups.py
<powersj> which also happens to be in ./tests/cloud_tests/testcases/modules/user_groups.py
<powersj> grep -ir "test_user_barfoo" .
<powersj> ./tests/cloud_tests/testcases/examples/including_user_groups.py:    def test_user_barfoo(self):
<powersj> ./tests/cloud_tests/testcases/modules/user_groups.py:    def test_user_barfoo(self):
<powersj> python3 -m tests.cloud_tests run --verbose --os-name xenial --test modules/apt_configure_sources_list.yaml --test modules/ntp_servers --test modules/set_password_list --test modules/user_groups --deb cloud-init_17.1-21-gbc70e157-1~bddeb_all.deb
<powersj> is the command it ran
<powersj> and there is the modules/user_groups test
<smoser> huh. indeed it does
<smoser> :)
<powersj> :)
<powersj> while I like the bugs dir and our attempt to organize things
<powersj> I'm not a huge fan of the examples dir
<powersj> especially if everything is disabled
<powersj> seems pointless
<powersj> and you know... causes uncessary confusion :)
<smoser> *and* its 100% duplicate
<powersj> yeah
<smoser> at least
<smoser>  tests/cloud_tests/testcases/examples/including_user_groups.py
<smoser> ==
<smoser>  tests/cloud_tests/testcases/modules/user_groups.py
 * powersj would be happy to see examples get blown away
<smoser> :-(
<smoser> yeah
<blackboxsw> yeah, I thought the same about duplication. There is merit in making sure that the syntax/intent of our examples is testable. But, I don't think verbatim that example copies into integration tests will really *work* for us.
<blackboxsw> too many external services etc that need to be faked
 * blackboxsw is cut-n-pasting verification results into each SRU 17.1 sub-bug now.
<smoser> blackboxsw: i assumed you were going to be launchpad-libbing that
<smoser> blackboxsw: you able to hang out for a minute ?
<blackboxsw> good point, will do that. do we want it as a comment of bug description smoser
<blackboxsw> yeah definitely
<blackboxsw> hanging out
<blackboxsw> cloud-init channel
<smoser> blackboxsw: almost there.
<blackboxsw> no rush. just tweaking your lp-bugs-released script
<smoser> blackboxsw: https://bugs.launchpad.net/ubuntu/+source/curtin/+bug/1721808
<ubot5> Ubuntu bug 1721808 in curtin (Ubuntu Zesty) "sru curtin 2017-10-06 - 0.1.0~bzr532-0ubuntu1" [High,Fix committed]
<blackboxsw> smoser: ci passed https://code.launchpad.net/~smoser/cloud-init/+git/cloud-init/+merge/332383
<blackboxsw> shall I land it in master or are you?
<smoser> blackboxsw: i can land
<blackboxsw> gr8
<smoser> blackboxsw: merged.
<smoser> 41152f10ddbd8681cdac44b408038a4f23ab02df
<blackboxsw> ok see it. starting the cherry pick
<blackboxsw> smoser: wanted to double check. so I'm upstream-snapshotting into ubuntu/devel right?
<blackboxsw> then cherry pick into xenial zesty
<blackboxsw> or cherry pick all ubuntu/devel, ubuntu/xenial and ubuntu/zesty
<smoser> blackboxsw: just ignore artful (ubuntu/devel) for now
<smoser> and cherry-pick to ubuntu/xenial and ubuntu/zesty
<blackboxsw> ok won't touch it
<smoser> have MP ready, and i'll review later. i have to run now.
<blackboxsw> see ya
<smoser> if you care... here is what i started writing
<smoser> http://paste.ubuntu.com/25768023/
<smoser> for SRU template on that bug
<blackboxsw> ok, debugging cherry-pick not working in my env
<blackboxsw> http://pastebin.ubuntu.com/25768117/
<blackboxsw> strange thing is if I take the diff from within the cpick file, patch applies cleanly
<blackboxsw> ...  I'm not seeing the diff content for cloudinit/config/cc_users_groups.py and other files in the cherry picked patch diff. just a couple of the unit test files listed in the cpick file.
<blackboxsw> n/m I see the full diff/patch. looks good relative to changes that went into master... although cherry-pick is claiming it didn't apply cleanly
<blackboxsw> checking quilt output
<blackboxsw> today bbsw learns about quilt
<blackboxsw>  QUILT_PATCHES=debian/patches quilt push cpick-41152f1-schema-Log-debug-instead-of-warning-when-jsonschema-is
<blackboxsw> I needed to override QUILT_PATCHES defaults so it can actually find the series file in debian/patches/series so that I can run smoser's cherry-pick script
<blackboxsw> ahh much better
<blackboxsw> ok
<blackboxsw> zesty is up for review https://code.launchpad.net/~chad.smith/cloud-init/+git/cloud-init/+merge/332446
<blackboxsw> xenial is up for review https://code.launchpad.net/~chad.smith/cloud-init/+git/cloud-init/+merge/332447
<powersj> blackboxsw: I added a few things to the SRU checklist
<powersj> namely collecting results for other tests, per our SRU exception
<blackboxsw> powersj: URL? is it the cloudinit SRU exception page
<powersj> https://wiki.ubuntu.com/CloudinitUpdates
<blackboxsw> I'll reread now since I'm in the thick https://wiki.ubuntu.com/CloudinitUpdates?
<blackboxsw> yeah
<powersj> thx
 * blackboxsw reads  the page thanks
<blackboxsw> ok pulling together suggestions now for that page.
<blackboxsw> since I'm through my 2nd round of SRU uploads on this SRU.
<blackboxsw> hrm not sure if I have edit rights, I can't seem to login to the wiki.ubuntu
<powersj> blackboxsw: best not to make edits, but propose them first somehow
<powersj> if it is more than minor, we have to get things approved
<blackboxsw> sounds good pooling suggested edits now.
<blackboxsw> powersj: this is all I have http://pastebin.ubuntu.com/25768388/
<blackboxsw> your changes look good
<powersj> blackboxsw: that is 100% fine :) I wasn't sure if you were going to change the process or make changes such that we would need to ask for re-approval
<blackboxsw> nah, nothing big, just that we've added attachements to the SRU process bug  with logs instead of dumping all those manual results inline in the SRU template as it is unreadable with all that content
<blackboxsw> we will also likely add bug tasks for xenial/zesty on each SRU non-process bug. to allow marking that bug as fix-released in the specific series once it's published (post SRU)
<blackboxsw> not sure if that would need documenting on cloudinitupdates wiki page,  but it'll be part of our process going forward
<blackboxsw> to really document when a bug is released to a stable series
<powersj> blackboxsw: ok, thanks :) as far as bug tasks for that page, we are concerned with the one big that tracks the SRU
<blackboxsw> yeah figured
<blackboxsw> thx
#cloud-init 2017-10-19
<smoser> blackboxsw: sorry about that. dont know at what point in my history i did that. and then just assumed.
<smoser> http://paste.ubuntu.com/25769370/
<smoser> powersj: around ?
<smoser> understand whats going on at https://jenkins.ubuntu.com/server/job/cloud-init-ci/ ?
<smoser> https://code.launchpad.net/~chad.smith/cloud-init/+git/cloud-init/+merge/332446 has 2 failures reported, which i do not think are valid, and also 412 is still running . that seems odd. i figured it posted at end.
<powersj> smoser: nacc reported some odd runs at the end of the day. I think something is up with the system or Jenkins master is taking a dump
<powersj> 2017-10-19 12:06:38,215 - schema.py[WARNING]: Invalid config:\nntp.pools: {} is not of type \'array\'\nntp.servers: {} is not of type \'array\'\n
<powersj> based on this cloud-config: https://github.com/cloud-init/cloud-init/blob/master/tests/cloud_tests/testcases/modules/ntp.yaml
<powersj> 2017-10-19 12:06:14,762 - cc_lxd.py[WARNING]: lxd/bridge config must be a dictionary. found a \'<class \'NoneType\'>\'\n
<powersj> cased by this cloud-config: https://github.com/cloud-init/cloud-init/blob/master/tests/cloud_tests/testcases/modules/lxd_dir.yaml
<powersj> "If you are using the default CentOS configuration, and if you are not behind a proxy server, fastestmirror is highly recommended."
<powersj> well we are behind a proxy... soooo yeah enough of this
<rharper> powersj: we can inject a disable fastmirror
<powersj> sed -i s/enabled=1/enabled=0/ /etc/yum/pluginconf.d/fastestmirror.conf
<rharper> I did that in curtin a while back when we were testing
<rharper> I think there's a --disable-plugin <foo> to yum
<powersj> there is a block where I think we detect if we need to set the proxy
<rharper> if that's easier
<powersj> well if we only do it when we set the proxy, then it means others can keep using it rather than putting --disable.. everywhere we do a yum
<rharper> yeah
<powersj> I'll get an MP for that shortly
 * powersj is very fed up with those failures
<powersj> https://code.launchpad.net/~powersj/cloud-init/+git/cloud-init/+merge/332511
<powersj> blackboxsw: rharper ^ disables fastest mirror when using a proxy
<blackboxsw> I'll try disabling as well in my centos lxc to validatate here too
<blackboxsw> validate even
<blackboxsw> powersj: with enabled=0 on both my existing centos6 lxc and a fresh image w/ fastest mirror disabled, I can pull update and install any packages (epel included) without issues with the default mirrors provided.
<blackboxsw> we may have to tweak our preferred mirrors at some point if we find problems. but this is a step in the right direction.
<powersj> Yeah can try this first :)
<powersj> Thanks for checking
<blackboxsw> sorry meant to type that here.
<blackboxsw> agreed. I've +1'd your branch. ci fell over on it I'm just checking
<blackboxsw> Cannot contact torkoal: java.lang.InterruptedException
<blackboxsw> bah
<blackboxsw> Aborted by Joshua Powers
<blackboxsw> hrh
<blackboxsw> heh, who does that guy think he is
<powersj> yeah...
<blackboxsw> smoser: I'm about to merge powersj ci-script fix for no fastestmirror plugin on centos. I know it'll force us to cherrypick into ubuntu/artful your jsonschema branch instead of upstream-snapshot
<blackboxsw> https://code.launchpad.net/~powersj/cloud-init/+git/cloud-init/+merge/332511
<blackboxsw> any concerns smoser ?
<smoser> blackboxsw: my concern is that my favorite mirror in japan might not get used
<blackboxsw> smoser: ha, and all your click-through ad revenue
<smoser> slightly better
<smoser> inside "$name" sed -i "s/enabled=1/enabled=0/" "/etc/yum/pluginconf.d/fastestmirror.conf"
<smoser> dont need shell there
<smoser> blackboxsw: powersj commented there.
<blackboxsw> smoser: ah right you mean drop the sh -c
<blackboxsw> agreed
<blackboxsw> can could do the same with the line above
<smoser> yeah, as i said there... milliseconds faster. for a package build and install of dozens of packages...
<smoser> the line above uses the shell for redirection
<blackboxsw> can't we still pass that w/out sh -c to lxc exec -- "stringcmd >> output"
 * blackboxsw checks
<smoser> no.
<smoser> there is no shell involved.
<blackboxsw> sure enough. smoser correct +1
<smoser> shell is what reads '>>' and opens 'output' for write append and then hands the filehandle to the child process as 1
 * blackboxsw continues to be pleased w/  hackmd.io for doc writing
<smoser> yeah, hackmd.io is the new gist
<smoser> they just need to have a 'commit' button
<smoser> then powersj can stop making fun of me for using gists and instead make fun of me for using hackio.md
 * powersj shakes head at smoser's "hacks"
<powersj> I like that even better
<powersj> smoser: https://paste.ubuntu.com/25774147/
<smoser> powersj: no quotes
<smoser> there, you're executing a command 'sed -i s/....'
<smoser> just like if you typed that (with the quotes) in your shell
<powersj> ah ok
<powersj> ahhh I see how it is used in other places now
<powersj> blackboxsw: updated https://code.launchpad.net/~powersj/cloud-init/+git/cloud-init/+merge/332511
<blackboxsw> powersj: running it now
<smoser> i just want to  make sure everyone realizes that i realize how tiny an improvement that is..
<smoser> compared to the vast improvment that powersj made
<blackboxsw> I have a whole bag of 'microseconds' for you smoser
<powersj> :D
<smoser> you got them from not downloading dozens of megabytes from japan
<smoser> a penny saved is a penny earned
<blackboxsw> and mutiply that by 1000 CI runs
<blackboxsw> and you can buy a bag of candy
<rharper> mmm, candy
<blackboxsw> powersj: drop fastestmirror merged
<powersj> blackboxsw: thanks!
<blackboxsw> np created a card so we track things that we've actually landed in cloud-init (as I feel it's been too light given recent SRU work)
<blackboxsw> https://www.irccloud.com/pastebin/bsxEyHr8/
<blackboxsw> oops sorry about that paste... shame on you irccloud
<blackboxsw> powersj: was there a bug associated with this? schema.py[WARNING]: Invalid config:\nntp.pools: {} is not of type \'array\'\nntp.servers: {} is not of type \'array\'\n
 * blackboxsw checks if it is still happening. (I believe it should still happen on master)
<blackboxsw> and I'm writing a tiny MP for it
<powersj> blackboxsw: I have not put a bug in yet
<blackboxsw> powersj: don't worry 'bout it. I'll file one if needed
<blackboxsw> I think there's another ntp schema related bug smoser just filed. I can piggy back
#cloud-init 2017-10-20
<redcavalier> Hey, I've ran into another weird cloud-issue issue on our centos instances in our Openstack setup.
<redcavalier> This time, there's just this one VM which, for some reason, considers its cloud-init cache corrupt on every reboot.
<redcavalier> So basically, it ignores its cache, deletes it and re-execute all metadata/userdata every reboot.
<redcavalier> This seems to be unique to this one instance though, so I'm not sure what to check beside what I've already check. I think something may be interfering.
<smoser> redcavalier: a /var/log/cloud-init.log would be the starting point.
<smoser> for debugging
<redcavalier> Yea, that'S how I know it'S discarding its cache. I can post it on a pastebin
<redcavalier> smoser, http://pastebin.centos.org/385126/ . Line 25 bothers me especially, as the cache gets deleted every reboot.
<blackboxsw> bummer, powersj, the disabled fastestmirror plugin wasn't the magic bullet I'd hoped. still hit subprocess.CalledProcessError: Command '['yum', 'install'... on https://jenkins.ubuntu.com/server/job/cloud-init-ci/415/console   :(
<powersj> :(
<powersj> btw is smoser morning the loss today?
<powersj> too soon? ;)
<smoser> powersj: yeah, in mourning this morning.
<smoser> now my only hope is in the Houstan Astros.  I can't imagine anyone ever wants to see the Yankees win, and I'm kind of sore on the dodgers right now.
<powersj> heh I missed a 'u'
<smoser> powersj: so looking at https://jenkins.ubuntu.com/server/job/cloud-init-integration-a/171/consoleText
<smoser> i remember we had this in curtin
<smoser> its hard to tell easily what test failed
<powersj> yeah because of the large amount of text that gets spit out
<powersj> I usually search for "FAIL:"
<smoser> well, yes, but also because
<smoser>  test_no_warnings_in_log (tests.cloud_tests.testcases.get_suite.<locals>.tmp) ... FAIL
<smoser> doesnt tell me anything
<smoser> i thought in curtin we did something so that it would list the class being run
<powersj> well it is telling you the test that fails :)
<powersj> that there are no warnings in the log
<powersj> We did do that in Curtin and I even thought we already did that in our tests... let me check
<powersj> hmm you are right, this is not obvious where that test lives
<powersj> oh wait, we do have the change
<powersj> in base.py:shortDescription(self)
<powersj> """Prevent nose from using docstrings."""
<smoser> powersj: so i download artifacts from jenkins
<smoser> is there a way i can run 'verify' with those ?
<powersj> smoser: python3 -m tests.cloud_tests verify -h
<smoser> http://paste.ubuntu.com/25780059/
<powersj> point to it via the --data-dir variable
<smoser> thats my failed attempt^
<powersj> give it to /cloud-init/results
<powersj> sorry to be more specific --data-dir=/tmp/artful-171/archive/cloud-init/results
<smoser> thanks
<smoser> so why doesnt shortDescription work
<smoser> :-(
 * smoser nothaving a good day
<smoser> oh.
<smoser> cause we dont run nose
<smoser> powersj, blackboxsw https://code.launchpad.net/~smoser/cloud-init/+git/cloud-init/+merge/332585
 * blackboxsw thinks that was related to you testing my branch
<blackboxsw> just a 'feeling'
<blackboxsw> :)
<powersj> +1'ed
<smoser> blackboxsw: were you fixing the ntp warning ?
<blackboxsw> smoser: https://code.launchpad.net/~chad.smith/cloud-init/+git/cloud-init/+merge/332540
<blackboxsw> was debating about fixing the lxd warning in that branch
<blackboxsw> if you want
<blackboxsw> or separate branch
<smoser> i have http://paste.ubuntu.com/25780634/
<smoser> that i was going to grab in a "actually fix all warnings" merge
<smoser> i can fix the ntp also, but if you had a branch that fixed it i woudl not
<blackboxsw> yeah if you have a separate branch for that you're good, or take mine to supplement yours
<blackboxsw> smoser: yeah my branch fixes ntp plus adds a unit test that'll show these integration test errors to us earlier once jsonschema is defined for a module
<blackboxsw> it didn't address the lxd cfg warning throuhg
<blackboxsw> though
<smoser> blackboxsw: i have that one fine.
<smoser> so if you're fixing jsonschema warning in
<smoser>  tests/cloud_tests/testcases/modules/ntp.yaml
<blackboxsw> yep fixed per the above branch
<smoser> then we'll just grab yours, then mine. then i think we'll be happy on no failures from warnings
<blackboxsw> yeah for sure
<smoser> but /me doesn't kniow why ididnt see these when i ran...
<smoser> i really promise ir an!
<smoser> I ran
<blackboxsw> we didn't use to have a warning validation test did we?
 * blackboxsw looks over the git logs again.
<blackboxsw> yeah, maybe you were referring to when you landed 41152f10ddbd8681cdac44b408038a4f23ab02df
<smoser> blackboxsw: ... confused.
<blackboxsw> I certainly am. I'll take another good sir
<smoser> never mind
<smoser> you fixsed it right
<smoser> i was confused that modules/ntp.yaml had empty dicts for pools and servers
<smoser> but you fixed that ;)
<blackboxsw> right-o
<smoser> blackboxsw: https://code.launchpad.net/~smoser/cloud-init/+git/cloud-init/+merge/332587
<smoser> that has the other fixes
<smoser> i think enough to get a integration test fully run
<blackboxsw> reviewing (will have a minor test patch for that branch)
<blackboxsw> landed the ntp thanks
<blackboxsw> & thx powersj
<smoser> im going to grab https://code.launchpad.net/~smoser/cloud-init/+git/cloud-init/+merge/332585 after ci ACKs it
<blackboxsw> yes sorry, distracted on the followup
<blackboxsw> approved
<smoser> powersj had already done it, so i wasnt going to wait on you :)
<powersj> :)
<smoser> Your code has been rated at 10.00/10
<smoser> i love that.
<smoser> 2 significant digits of perfection.
<smoser> or is that 4
<smoser> either way. i'm like the Mary Lou Retton of python coding.
<blackboxsw> hahah
<smoser> powersj: https://github.com/canonical-server/jenkins-jobs/blob/master/cloud-init/integration.yaml
<smoser> in that, i think we're making the same sort of error as we were in curtin at one point.
<powersj> which error :)
<smoser> we're running trunk c-i against distro version of the code
<smoser> err.. trunk level of integration test with distro version of code
<powersj> I'm taking trunk, and building it using an sbuild of a particular release
<blackboxsw> smoser: https://code.launchpad.net/~smoser/cloud-init/+git/cloud-init/+merge/332587 updated
<powersj> there should be no test mismatch there
<powersj> if I were, however, to take the daily build of cloud-init and run it against the trunk tests then I would agree
<powersj> daily build of cloud-init for a particular release* to be even more specific
* blackboxsw changed the topic of #cloud-init to: is Reviews: http://bit.ly/ci-reviews | Meeting minutes: https://goo.gl/mrHdaj |  Next status meeting: Monday 10/16 16:00 UTC | cloud-init 17.1 released | quotes:  <@smoser> either way. i'm like the Mary Lou Retton of python coding.
<blackboxsw> :)
<smoser> yeah, you're right.
* blackboxsw changed the topic of #cloud-init to: is Reviews: http://bit.ly/ci-reviews | Meeting minutes: https://goo.gl/mrHdaj |  Next status meeting: Monday 10/16 16:00 UTC | cloud-init 17.1 released
<smoser> hm.. so why did i not see that failure.
<smoser> https://jenkins.ubuntu.com/server/job/cloud-init-ci/419/console
<blackboxsw> not behind a proxy?
<blackboxsw> where fastestmirror plugin is disabled?
<smoser> i thought we disabled it.
<smoser> where was that mp ?
<blackboxsw> hrm: Loaded plugins: fastestmirror
<blackboxsw> that mp landed yesterday.
<blackboxsw> digging it up
<blackboxsw> https://code.launchpad.net/~powersj/cloud-init/+git/cloud-init/+merge/332511
<blackboxsw> strange to see fastestmirror showing up on that run as I thought it was behind a proxy (and as such fastestmirror should be disabled)
<blackboxsw> or maybe I'm just focusing on the wrong problem
<powersj> your branch doesn't have my fix?
<blackboxsw> checking your branch out to make sure it has the fix
<powersj> it doesn't
<powersj> https://git.launchpad.net/~smoser/cloud-init/tree/tools/run-centos?h=fix/citest-show-class-in-failures
<blackboxsw> https://code.launchpad.net/~smoser/cloud-init/+git/cloud-init/+merge/332585 doesn't yeah : )
<blackboxsw> rebase for the win
<blackboxsw> too bad that canadian fastestmirror will be sad
<smoser> blackboxsw: thanks.
<smoser> https://jenkins.ubuntu.com/server/job/cloud-init-ci/422/ is about to post on https://code.launchpad.net/~smoser/cloud-init/+git/cloud-init/+merge/332585
<smoser> and then happy i'll pull that
<smoser> blackboxsw: did you sort the maas/-proposed thing ?
<blackboxsw> nope smoser I'm trying to figure out what gives with https://bugs.launchpad.net/cloud-init/+bug/1684869 and why it doesn't generate a 'proposed' image for me
<ubot5> Ubuntu bug 1684869 in cloud-init (Ubuntu Artful) "growing root partition does not always work with root=PARTUUID=" [Medium,Fix released]
<blackboxsw> was trying to reproduce the resize failure locally
<smoser> hm..
<smoser> blackboxsw: https://git.launchpad.net/~smoser/cloud-init/+git/sru-info/plain/bin/get-proposed-cloudimg just "worked for me"
<smoser> http://paste.ubuntu.com/25781060/
<blackboxsw> weird I think I'm being dumb.
<blackboxsw> the zesty image I downloaded didn't upgrade cloud-init
<blackboxsw> checking logs
<smoser> oh. yeah. it would not i guess.
<smoser> or possibly
<smoser> as cloud-init got kicked maybe ?
<smoser> hm.. no i get it there.
<blackboxsw> pulling latest get-proposed-cloudimg to check
<smoser> hm.. why is sfdisk --part-uuid not working
<blackboxsw> uefi images on xenial right?
<smoser> oh. no. what a pita
<smoser> xenial are mbr
<smoser> fudge
<blackboxsw> https://bugs.launchpad.net/cloud-init/+bug/1684869/comments/8
<ubot5> Ubuntu bug 1684869 in cloud-init (Ubuntu Artful) "growing root partition does not always work with root=PARTUUID=" [Medium,Fix released]
<blackboxsw> :)
<blackboxsw> ok my get-proposed-cloudimg was stale
<blackboxsw> ok my network in the kvm I created is borked. Could not resolve host: entropy.ubuntu.com or anything else, which is why my proposed cloud-init package didn't update
<smoser> blackboxsw: testing this
<smoser>  http://paste.ubuntu.com/25781127/
<smoser> dns issues scare me
<smoser> artful guest ?
<blackboxsw> artful host, zesty guest
<blackboxsw> trying on another box to be certain
<smoser> how did you make guest ?
<blackboxsw> strange it's working on another box. ok will copy it in
<smoser> oh. inside the mounted image you were failing dns ?
<smoser> my test got throug, following that bug and / got rezied on xenial.
<smoser> tryinng now with zesty
<blackboxsw> smoser: yes inside the image
<blackboxsw> and inside the image is cloud-init 0.7.9
<blackboxsw> not 17.1 as I had expected to see
<blackboxsw> 0.7.9-233-ge
<blackboxsw> yeah
<smoser> ok. yeah. so you have to (and i made this mistake) boot the -proposed
<blackboxsw> ok I performed the steps I had used in previous SRU https://bugs.launchpad.net/cloud-init/+bug/1684869
<ubot5> Ubuntu bug 1684869 in cloud-init (Ubuntu Artful) "growing root partition does not always work with root=PARTUUID=" [Medium,Fix released]
<blackboxsw> ahh gotcha right
<smoser> blackboxsw: so modify that template on the bug like:
<smoser> proposed=${raw%.*}-proposed.img
<smoser> qemu-img create -f qcow2 -b $proposed disk.img 10G
<smoser> but i did that just now for zesty and worked fine. verified cloud-init 17.1.... in the guest
<blackboxsw> oooooh
<blackboxsw> oops
<blackboxsw> thanks
<blackboxsw> ok, made it to the finish line. see the resize succeed on 17.1
<blackboxsw> zesty
<blackboxsw> soooo, our test case doesn't validate https://bugs.launchpad.net/cloud-init/+bug/1725067   for some reason
<ubot5> Ubuntu bug 1725067 in cloud-init (Ubuntu) "cloud-init resizefs fails when booting with root=PARTUUID=" [Medium,Triaged]
<blackboxsw> and bbsw is out of his depth
<smoser> blackboxsw: doesnt validate ?
<blackboxsw> I need knowledge smoser. got 10 mins before your weekend?
<smoser> blackboxsw: http://paste.ubuntu.com/25781261/
<smoser> yeah, we can chat 10  minutes
<smoser> that "works for me" to recreate failure actually in xenial
<blackboxsw> ok, I was wondering what I did wrong as I saw resizes happening on 17.1 zesty I thought
<smoser> i'm in hangout
<smoser> and yeah, it does seem to work fine for zesty
<blackboxsw> sorry joining
<blackboxsw> was running your script
<smoser> blackboxsw: for irc logs
<smoser> https://github.com/cloud-init/qa-scripts/blob/master/scripts/get-proposed-cloudimg
<smoser> https://github.com/cloud-init/ubuntu-sru/blob/master/bugs/lp-1684869/recreate.sh
<blackboxsw> yeah thanks, stinks to close the hangout window  when you didn't grab all the links discussed
<smoser> blackboxsw: ok. so the difference between xenial and zesty
<smoser> on zesty, *something* is making /dev/root exist
<smoser> but on xenial
<smoser> $ ls -l /dev/root
<smoser> ls: cannot access '/dev/root': No such file or directory
<smoser> zesty
<blackboxsw> ahh interesting... ok
<smoser> $ ls -l /dev/root
<smoser> brw------- 1 root root 8, 1 Oct 20 21:39 /dev/root
<blackboxsw> right I'm with you
<blackboxsw> saw the failure on xenial now thanks
<smoser> yeah, so fix at this point should be pretty straight forward knowing what we did originally and such.
<smoser> have a good one.
 * smoser out
<blackboxsw> yeah thanks again you too
<smoser> blackboxsw: https://jenkins.ubuntu.com/server/job/cloud-init-ci/426/console
<smoser> that is from https://code.launchpad.net/~smoser/cloud-init/+git/cloud-init/+merge/332587
<blackboxsw> no fastestmirror
<blackboxsw> hrm
<smoser> yeah
<smoser> its definitely not that coee
<smoser> it'd be nice ot have that in
 * smoser hits 'rebuild'
<smoser> you're welcome to just pull that though if you want...
<smoser> especially with powersj approval
<smoser> hopefully ci at 427 will agree
<smoser>  https://jenkins.ubuntu.com/server/job/cloud-init-ci/427/console
<smoser> (straight rebuild)
<smoser> but with that, trunk should pass c-i again .
<smoser> or rather the nightly integration test
<powersj> it only failed MAAS tests
<powersj> for that merge I don't care :) about those
<powersj> push it :D
<blackboxsw> I'll push it in
#cloud-init 2017-10-21
<blackboxsw> smoser: one thing I noticed which I didn't hit before was the time spent "[    7.839025] cloud-init[731]: Generating locales (this might take a while)...
<blackboxsw> "
<blackboxsw> for monday. I thought our images were supposed to have that locale properly generated so we don't have to regen. I know there's a bug for this, just thought it had been resolved.
