#cloud-init 2013-10-07
<smoser> hey all
<smoser> i'm hoping to mark 0.7.3 today.
<pedroalvarez> cool
<pedroalvarez> smoser: I don't know why I cannot make cloud-init receive data from OpenStack, I have a log this time. http://paste.ubuntu.com/6205664/
<smoser> pedroalvarez, what are you expecting to find ?
<smoser> configdrive or ec2 metadata service ?
<pedroalvarez> i have installed ubuntu in openstack, and the cloud-config simply worked
<pedroalvarez> I'm using the same configuration in other operating system, and I don't know why doesn't work
<smoser> ah.
<smoser> is ubuntu using cloud-config or ec2 
<smoser> er.r..
<smoser> config-drive or ec2 i meant.
<pedroalvarez> how can I know? where in the log?
<pedroalvarez> smoser: forget it for today, I have to go home. I'll ask you again tomorrow
<smoser> cloud-init output should say.
<smoser> but basically either you've configured openstack to offer config-drive (or requested it at launch) or to offer the ec2 metadata service.
<smoser> if you don't know, then you're prbably doing the MD service.
<smoser> but i have less guessses as to what is going wrong with your install for MD than I would for config-drive.
<smoser> for config-drive, i'd suspect that enough drivers are not loaded to see the disk or a race condition in it becoming avialable.
<smoser> harlowja, around ?
<harlowja> yo
<harlowja> smoser poke
<smoser> you hav eanything really important that you'd like to have in to 0.7.3 ?
<smoser> cause i'm about to push "go" on that.
<harlowja> not afaik :)
<smoser> k.
<harlowja> that windows stuff?
<harlowja> lol
<smoser> yeah. windows. :)
<harlowja> alexpilotti ;)
<utlemming> smoser: problem with the latest uplaod to lp:cloud-init
<smoser> utlemming, ?
<utlemming> smoser: ephemeral0 is not mapping to the first partition
<utlemming> smoser: on parted disks
<utlemming> smoser: http://paste.ubuntu.com/6206712/
<utlemming> smoser: http://paste.ubuntu.com/6206721/ 
<smoser> i thought you had tested this.
<utlemming> smoser: yeah, I did
<utlemming> smoser: which is why I am confused
<utlemming> smoser: because I took the branch you pinged me and tested against that
<smoser> well i merged your branch
<smoser> utlemming, please figure out what needs fixing. i just released 0.7.3 so that sucks.
<utlemming> smoser: yeah, this blows hard
<utlemming> smoser: I'll get this ASAP
<smoser> i'll be back in in a couple hours.
<utlemming> smoser: lp:~utlemming/cloud-init/lp1236594-bad_ephemeral0_mnt
<smoser> utlemming, still there?
<utlemming> smoser: yup
<smoser> I did the "if not partition" by design.
<smoser> because input to devnode_for_dev_part
<smoser> should be a string or None
<smoser> bool("0") == True
<smoser> oh. but i guess "" is not true. that must be what was occuring there?
<utlemming> right
<smoser> no.
<smoser> expand_dotted_devname("ephemeral0")
<smoser> would return None
<smoser> hm..
<utlemming> the issue is "ephemeral0" is not selecting ephemeral0 or epehemeral0.1 because of that "if partition"
<smoser> right.
<smoser> utlemming, so i think the right place for that change is in sanitiz_devname.
<smoser> i think . as its there that we're saying "ephemeral0" == ephemeral0.0 or ephemeral0.1
<utlemming> hrm...
<utlemming> but isn't that the same things as my patch? 
<smoser> well mostly, except for then there is no way to call devnode_foor_dev_part with "do not expand this"
<smoser> err.. with "do not allow part 0 or part 1"
<utlemming> smoser: since this is a specific function to cc_mounts, I think adding a flag that controls that behavior seems sane
<utlemming> otherwise we have two functions that only get halfway there
<utlemming> i.e. def ...(..., literal=False)
<utlemming> which controls the beavhior
<utlemming> but again, this is one function that is called by one module
<smoser> i think you're right
<smoser> utlemming, you're changes are correct.
<smoser> i'mpretty sure.
<utlemming> smoser: I tested those changes on SmartOS, EC2 and Azure
#cloud-init 2013-10-08
<smoser> alright, utlemming uploaded.
<smoser> i kind of am planning on doing an 0.7.4 release to just tie this fix in and anything else that flushes out in the nexst 36 hours.
<utlemming> smoser: ack
<smoser> utlemming, it just made it through
<smoser> so please get builds in if you can
<pedroalvarez> Running 2 OS, in the same OpenStack system, Ubuntu gets the userdata through Ec2 and the other OS doesn't receive anything..
<pedroalvarez> I've got the two log files: 
<pedroalvarez> -Ubuntu: http://paste.ubuntu.com/6209011/
<pedroalvarez> -The other: http://paste.ubuntu.com/6209024/
<pedroalvarez> I even downgraded my cloud-init version to 0.7.2, but still not working
<smoser> neat that btrfs resize worked. that was mostly theoretical
<smoser> :)
<pedroalvarez> :)
<smoser> Oct 08 11:15:33 baserock cloud-init[196]: [CLOUDINIT] __init__.py[DEBUG]: Searching for data source in: ['DataSourceNoCloudNet', 'DataSourceConfigDriveNet', 'DataSourceAltCloud', 'DataSourceOVFNet', 'DataSourceNone']
<smoser> that is your problem
<smoser> i'm not sure whats causing it, but for some reason its not looknig for the DataSourceEc2, while it seems like you've configured that.
<smoser> Oct 08 11:15:33 baserock cloud-init[196]: [CLOUDINIT] __init__.py[DEBUG]: Looking for for data source in: ['NoCloud', 'ConfigDrive', 'AltCloud', 'OVF', 'MAAS', 'Ec2', 'None'], via packages ['', 'cloudinit.sources'] that matches dependencies ['FILESYSTEM', 'NETWORK']
<pedroalvarez> That's exactly what I was checking right now
<pedroalvarez> yes, it is on my cfg file: datasource_list: [ NoCloud, ConfigDrive, AltCloud, OVF, MAAS, Ec2, None ]
<pedroalvarez> smoser: there is a module called "disable-ec2-metadata"
<pedroalvarez> I have tried to make it works with and without it
<pedroalvarez> Seems like the importer can't import it:  importer.py[DEBUG]: Found DataSourceEc2 with attributes ['get_datasource_list'] in []
<smoser> pedroalvarez, disable-ec2-metdata not related.
<smoser> well... disable-ec2-metadata would most certainly disable your ec2metadata
<smoser> pedroalvarez, what is your python version ?
<pedroalvarez> smoser: Python 2.7.2
<pedroalvarez> and I have already disabled the "disable-ec2-metadata" module
<smoser> that wont affect cloud-init
<smoser> that runs late in the boot process
<smoser> and if it is enabled by user data 
<smoser> then it routes the url off
<pedroalvarez> Is the python version enough?
<smoser> i think so
<smoser> i thought it might have an issue if it was 2.6 or 2.6
<smoser> err 2.5
<pedroalvarez> smoser: I could try using configDrive instead Ec2, but I don't know how to configure OpenStack to do it
<smoser> no. yo ushoudl fix ec2.
<smoser> i'm not sure why you're not finding that datasource, though.
<smoser> can you let me into an instance?
<pedroalvarez> It's not visible from outside I think
<pedroalvarez> Let me ask
<pedroalvarez> I can't, but maybe I can try to upload it to a free Openstack online
<pedroalvarez> (trystack)
<pedroalvarez> hmm.. do you know another alternative than trystack?
<smoser> pedroalvarez, i dont know. 
<smoser> you could put it on amazon
<smoser> oh, or even do a devstack *in* amazon
<smoser> or tunnel out of theinstance
<smoser> can you let me into the bootstrap node ?
<smoser> ssh-import-id smoser
<pedroalvarez> smoser: found the problem I think. I didn't import boto, essential for run Ec2. I will let you know. Thanks
<smoser> hum.. i'd have thoguht we'd see a traceback log there.
<smoser> maybe there was on the consoel
<pedroalvarez> there isn't:
<pedroalvarez>         except ImportError:
<pedroalvarez>             pass
<smoser> boooo
<pedroalvarez> Solution:
<pedroalvarez>         except ImportError, e:
<pedroalvarez>             LOG.debug("Failed to import %s: %r", full_path, e)
<smoser> i'd use util.logexc
<smoser> but yeah
<smoser> harlowja, pedroalvarez hit a but that was hidden somewhat by the fact that the datasource loader hides import errors
<harlowja> :-/
<harlowja> hmmm
<smoser> so the datsource loading
<smoser> tried to load ddatasourceec2
<smoser> which eneeded boto
<smoser> and so tboto import-errored
<smoser> and then the laoder just swallowd that up.
<smoser> so i couldn't figure out from his log why he wasn't seeing the datasource ec2 (or attempting to use it)
<harlowja> hmmm
<harlowja> ya durn imports of imports failing
<harlowja> those are tough ones
<harlowja> maybe we should log something at least
<harlowja> maybe to start a debug message
<harlowja> around try:
<harlowja>             mod = import_module(full_path)
<harlowja>         except ImportError:
<harlowja>             pass
<harlowja> except its hard to tell the difference between import not existing (which might be ok) and import having a dependency that is failing
<harlowja> both come out as import errors
#cloud-init 2013-10-09
<smoser> harlowja, yeah, its not completely straight forward. 
<pedroalvarez> the example of power_state crashes: http://bazaar.launchpad.net/~cloud-init-dev/cloud-init/trunk/view/head:/doc/examples/cloud-config-power-state.txt
<pedroalvarez> the message needs " "  
<smoser> really?
<pedroalvarez> maybe it's the space between "Bye" and "Bye"
<smoser> $ python -c 'import yaml, pprint; pprint.pprint(yaml.load("powerstate:\n message: Bye Bye\n"))'
<smoser> {'powerstate': {'message': 'Bye Bye'}}
<smoser> unless i'm loading it as an array.
<pedroalvarez> cc_power_state_change.py[WARNING]: expected string or buffer Not performing power state change!
<pedroalvarez> hmmmm
<pedroalvarez> I did two changes to make it works. I also changed "delay" to "now"
<smoser> pedroalvarez, right. isee that
<smoser> funny
<smoser> the doc about it is correct
<smoser> it needs to be "+30"
<pedroalvarez> yes, the doc helped me
<smoser> pedroalvarez, http://paste.ubuntu.com/6213844/ that fixes doc and supports the bad example
<pedroalvarez> smoser: cool, thanks! :)
<pedroalvarez> I'm just trying all the modules to check the integration
<pedroalvarez> testing :)
<harlowja> smoser yt
<smoser> here
<harlowja> hey
<harlowja> adding a warning message for import failure seems ok?
<smoser> yeah, i think so . that would hvae been a smoking gun here.
<harlowja> :)
<harlowja> k
<harlowja> will do boss!
<harlowja> vote for me http://lists.openstack.org/pipermail/openstack-dev/2013-October/016288.html
<harlowja> lol
 * harlowja this is a paid message (not by joshua harlow)
<harlowja> ha
<smoser> i am josh harlow and i approve of this message
<harlowja> ha
<harlowja> if the above gives u a XYZ for longer than 24hours see your doctor
<harlowja> lol
<harlowja> hmmm, i guess thats a different advertisement, nm
<harlowja> ha
<harlowja> smoser https://code.launchpad.net/~harlowja/cloud-init/log-import-fail/+merge/190225
<harlowja> * nothing so special :-P
#cloud-init 2013-10-10
<ikkeT> hi guys, any info on vcloud support for cloud-init?
<ikkeT> do you know if it's been considered as possible datastore for cloud-init, or if there perhaps would be some initial code for it?
<ikkeT> or if there is no way of getting it to work?
<ikkeT> vmware vcloud that is...
<ikkeT> i'm wondering if the same guest templates could work in both openstack and vmware
<smoser> vcloud ?
<smoser> oh. vmware vcloud. i'm not aware of any work to that effect.
<utlemming> ikkeT: are you talking about vCHS? 
<smoser> ikkeT, but patches are definitely welcome for that.
<ikkeT> i haven't yet looked into it myself, but will need to start looking soon.
<ikkeT> smoser, sure, we'll push out patches if that's the path we need to take
<smoser> please do!. see HACKING.rst in trunk (bzr branch lp:cloud-init)
#cloud-init 2013-10-11
<evilissimo> alexpilotti: are you around? :)
<alexpilotti> evilissimo: hey
<evilissimo> alexpilotti: I was wondering what's the plan with cloudbase init for windows
<alexpilotti> evilissimo: in what sense? :-)
<evilissimo> I read somewhere, don't remember where exactly that you might want to get it into cloud-init 
<alexpilotti> true
<evilissimo> is that still the plan?
<alexpilotti> sure
<alexpilotti> but it's shell of a work
<evilissimo> kk, any help needed in that regard?
<alexpilotti> *a hell of a 
<alexpilotti> definitely yes
<evilissimo> To put things a bit into perspective
<alexpilotti> cloud-init needs to be heavily refactored for that to happen
<evilissimo> I am working for Red Hat
<alexpilotti> I see
<alexpilotti> are you coming to the summit in HK?
<evilissimo> No, unfortunately not
<evilissimo> Well I am working at the Red Hat Enterprise Virtualization team, and I am mainly responsible for the Windows Guest Agent
<evilissimo> which also means oVirt ;)
<alexpilotti> that's interesting
<evilissimo> So and we are thinking about introducing cloud-init as alternative to sysprep
<alexpilotti> we should talk about the status of the virtio drivers :-)
<evilissimo> hehe
<evilissimo> we can talk about that, if there's anything I can pass along to the devs
<alexpilotti> we are currently using a mix of sysprep + cloudinit
<alexpilotti> sys prep takes care of generalisation and setting the user name
<alexpilotti> cloudbase-init of all the rest
<evilissimo> I see
<alexpilotti> sorry, s/user/host/
<evilissimo> hmm but cloud-init could also set the host name, no?
<evilissimo> cloudbase-init ;)
<alexpilotti> actually the unattended.xml starts cloudbase-init for that
<alexpilotti> it does
<alexpilotti> but since setting the host name requires a reboot
<alexpilotti> we avoid that by putting that step during generalization 
<alexpilotti> another thing we are working on is passwordless authentication in Windows
<evilissimo> SSO?
<alexpilotti> nope
<alexpilotti> WSMan + client certs
<evilissimo> that's for WMI?
<evilissimo> I don't know WSMan
<alexpilotti> not only
<alexpilotti> Powershell demoting for example
<alexpilotti> WSMan == SSH in the Windows world :-)
<evilissimo> oh right
<alexpilotti> darn autocorrect
<evilissimo> lol, I fortunately don't have that :D
<alexpilotti> s/demoting/remoting/
<evilissimo> yeah I guessed that ;)
<alexpilotti> no, but you have: https://github.com/Openwsman/openwsman
<evilissimo> oh, I mean autocompletion :)
<evilissimo> I don't have auto completion ;)
<alexpilotti> lol
<alexpilotti> good choice, I think I'll follow the advice
<evilissimo> The only autocompletion I use is the nick completion
<evilissimo> alexpilotti: so what's the problem with the VirtIO drivers?
<alexpilotti> we had some issues with the latest versions
<alexpilotti> some blue screens
<evilissimo> oh?
<evilissimo> I haven't heard about that
<alexpilotti> so there's some black magic involved in choosing what version to use for what OS :-)
<evilissimo> hmm well since I don't handle the packaging for Windows, I am not really aware of it
#cloud-init 2014-10-06
<nvucinic> hi guys, i have disable_root: 0 and ssh_pwauth: 1, and after cloud init passes i cannot log into instance with my root pwd, or over ssh 
<smoser> nvucinic, it should be supported.
<smoser> nvucinic, its a bug. its a result of sshd config being changed in 14.04 to disallow root login by default
<smoser> it went from
<smoser>  PermitRootLogin without-password
<smoser> to
<smoser> err.  from
<smoser>  PermitRootLogin yes
<smoser> to
<smoser>  PermitRootLogin without-password
<smoser> harlowja, around ?
<harlowja> sup dawg
<smoser> for some work i'm doing on containersa nd openstack...
<harlowja> uh oh
<smoser> i need to store some information for a user in the db
<smoser> here. http://paste.ubuntu.com/8507232/
<harlowja> hmmm
<harlowja> so this would be like a keystone addition?
<harlowja> or a nova + keystone one
<smoser> well, i think so. i think that s  where that information would make sense to store.
<smoser> well, nova uwell, nova needs to store and retrice that information about a user *somewhere*
<smoser> in a per-az way.
<harlowja> ya
<smoser> i assumed that keystone would make sense, but if you tihnk something better , thats fine too.
<harlowja> seems like keystone, although i don't know how much knowledge keystone has of nova azs
<harlowja> i'd say bug the keystone guys :-P
<harlowja> wonder if they have any input
<smoser> well, i'm assuming that i can get my own az
<smoser> ie, the nova system would be able to know that of itself, and maintain it itself.
<smoser> {'az1': {'subuid': [1,2,3], 'subgid', [5,6,7]}, 'az2': {...}}
<harlowja> sure, nova i guess can have that
<smoser> so is there some similar code that i could look at / base off of that needs to lock and update a keystone value ?
<harlowja> hmmm
<harlowja> not sure :-/
<smoser> thanks for reading, harlowja.
<harlowja> :)
<nvucinic> smoser: yes, but i am using it on centos 6, and still i cannot login even through console after cloud init 
<nvucinic> not ssh, console.
<smoser> nvucinic, i'd need more info to debug. 
<smoser> you might try adding a backdoor user
<smoser> logging in as hat user, and then watching it fail for root
<smoser> theres a fair shot that https://code.launchpad.net/~smoser/+junk/backdoor-image
<smoser> will allow you to backdoor an image vairly easiy
<nvucinic> smoser: i can login as root with key 
<nvucinic> but first password that is setup on image before cloud init is not working anymore 
<nvucinic> i am using "golden template"  for all instalation and cloud init for network configuration on first boot 
<nvucinic> so after cloud init gets initilized i cannot login with root password that setup on template 
<smoser> are you sure you could log in with password before ?
<nvucinic> yup, 100% sure 
<nvucinic> after cloud init i can login only via ssh key 
<nvucinic> password for root fails at console and ssh 
<smoser> nvucinic, please file a bug. maybe harlowja can look at it . i dont have a setup access to centos that i could easily poke at.
<smoser> i'm not sure what it would be doing that would lock root out. other than if you have 'user' to 'root' .
<smoser> and lock_passwd for that.
<nvucinic> i can paste your tommorow whole config 
<harlowja> nvucinic if u can get the logs, the config that would be great
<harlowja> *cloud-init logs without secret stuff in them
<harlowja> that'd help figure out whats happening
#cloud-init 2014-10-07
<harmw> smoser: e.t.a. for 0.7.6 release?
<harmw> harlowja_away: upgrading from 6.5 to 7 went rather smooth, atleast for base
<harmw> quite impressive
<harmw> hiren_: you got that vm running by now?:p
<smoser> harmw, is it ready for you?
<smoser> i'll release today if so.
<harmw> ok, cool
<harmw> well afaik it all just works, including configdrive and static networking
<harmw> lets just wait a little so hiren_ can confirm this, I'd rather not be the only tester in this
<smoser> harmw, cool. hiren_ if you could test that would be awesome.
<smoser> harmw, so you will upload that to ports ?
<smoser> or submit it for upload?
<smoser> i really have no idea how this works.
<harmw> no worries, Ill manage that :)
<smoser> harmw, so what do you do ?
<smoser> is there some doc i can rtfm ?
<harmw> porters guide
<harmw> let me check
<smoser> when i tell someone "look, cloud-init is in freebsd" i don't want to sound like a *complete* idiot.
<smoser> i try to limit how much of an idiot i appear.
<smoser> its not easy to do
<harmw> hehe
<harmw> https://www.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook/index.html
<harmw> and eventually, this is produced:
<harmw> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=192674
<smoser> so "time needed to include a new port in FreeBSD can vary from a few days to a few months"
<harmw> nah
<smoser> do you have people that you'd ping that would help you or have you done this before ?
<harmw> yup
<smoser> cool.
<harmw> that bugreport is about one of 2 earlier ports I did
<smoser> awesome.
<smoser> so your new $work has you working on some of this ?
<harmw> submitted on aug/15, committed on aug/18. Fairly quick I'd say :)
<smoser> yeah, way  more responsive than that cloud-init project
<harmw> :P
<harmw> $newjob will hopefully ditch vmware and go the openstack route
<harmw> they expressed their love during the interview :)
<smoser> well, harm everyone loves you
<harmw> lol
<smoser> have you ever tried freebsd on ec2 ?
<harmw> nope
<harmw> only in my own openstack cloud
<smoser> it'd be nice if i could say that that ds works also.
<harmw> which is more like fog, rather than full cloud :p
<harmw> +1
<harmw> if I find time, perhaps I can get my hands on a trial account at amazone/azure
<smoser> i can spin you some instances if you want for sure.
<harmw> ah
<harmw> well in that case, all I need is a proper FBSD image with c-i inside
<smoser> well, we wont get one with c-i inside as easily.
<harmw> you can't upload your own image to amazon?
<smoser> i can
<smoser> but thats just more painful. i'd just launch one of the freebsd
<smoser> and then put cloud-init in, clean up and reboot
<smoser> at least for initial testing
<harmw> sure thing
<smoser> if you want one to poke at let me know.
<harmw> definately
<harmw> perhaps tonight
<harmw> their current image is based on nothing? no automation whatsoever?
<harmw> smoser: know what, spin me up an fbsd 10 instance on amazon and Ill look at that somewhere this week
<harmw> which most of the time means the same day :P
<smoser> harmw, i'm not sure how they build them or what is in them.
<smoser> i suspect they have something that pulls in ssh keys
<smoser> and possibly runs #! user-data
<harmw> hmk, well we'll just have to find out :) smoser, I do hope they offer version 10.0?
<smoser> http://paste.ubuntu.com/8514448/
<smoser> harmw, to my knowledge those are the closest to official freebsd images. owned by '118940168514'
<harmw> ami-19dae970 10.0-RELEASE 64-bit
<harmw> excellent
<harmw> smoser: go ahead and bring me a fbsd instance
<smoser> k
<harmw> I think I can play with it later tonight, in about 2hrs
<harlowja> harmw cool, i still haven't convinced myself to go on the RDO list and try to sell anvil to folks, haha
<harmw> hah lol
<harmw> well, I was stupid enough to post first and check archives later
<harlowja> :-P
<harlowja> https://review.openstack.org/#/c/126447/ was something neat though, an alternative to rpm packages if u will
<harlowja> ^ is similar to what dreamhost and rackspace are doing afaik
<harmw> hmk
<harmw> interesting
<harlowja> basically saying screw packages, put everything in a virtualenv, deploy virtualenv
<harmw> yup
<harmw> sounds adventurous :)
<harlowja> we (y!) team have considered it, i'm still not sure if its better or worse yet
<harmw> well for now, Ill just go back at fixing python deps that are unfilled since upgrading to centos7 :p
<harlowja> :-P
<harlowja> fair enough, ha
<smoser> harmw, ok. i'll get you an instance.
<jaxxstorm> hi all
<jaxxstorm> is there any way to disable SSL verificaation in cloud-init?
<smoser> harlowja_, ^
<smoser> jaxxstorm, possibly... you can also put in certificates though
<jaxxstorm> I did give thata try
<jaxxstorm> think I'm missing a package
<harmw> smoser: ping
<smoser> hey
<harmw> you got that instance online?
<smoser> will do that right now.
<smoser> harmw, freebsd 10 ?
<smoser> right
<smoser> ?
<harmw> yup
<smoser> k. working on it. i launched one. i think it should come up with an ip here shortly
<harmw> wicked
<smoser> harm@manbearpig -> ec2-user@54.172.71.8
<smoser> harmw, ^
<harmw> cool
<harmw> excellent, I'm in
<harmw> hehe, interesting this instance has an xn0 nic
<harmw> c-i wont like that
<harmw> well, my stupid code won't
<harmw> thre are some ec2_* scripts in /usr/local/etc/rc.d
<harmw> hm, sounds fun: I should make some discovernetdev() function in freebsd.py
<harmw> ok, removed ec2-scripts-1.8
<harmw> lets see if it survives a reboot smoser 
<harmw> cool, it does
<smoser> well thats good :)
<harmw> smoser: are all those recent changes/fixes in trunk?
<harmw> I guess so..
<smoser> everything shoudl be in trunk, yeah.
<harmw> smoser: rebooting now, with c-i enabled
<harmw> let's see what happens :)
<harmw> it's back up, so thats good
<harmw> hm, c-i just logs everything to console or something
<harmw> Oct  7 20:12:20 ip-10-0-0-158 kernel: Can not apply stage final, no datasource found! Likely bad things to come!
<harmw> aw damn, I forgot to edit cloud.cfg
<smoser> :)
<smoser> you can still get in though
<smoser> right ?
<smoser> or you need a new instance
<harmw> oh ys
<harmw> rebooting, again :)
<harmw> this time with datasource Ec2 added
<harmw> this is an eastcoast instance, right?
<smoser> east coast, yeah
<harmw> hm, you did something special with the sshkey smoser ?
<harmw> since it just added someone else's key to the beastie user :)
<harmw> and perhaps you can specify some hostname in the ec2 interface?
<smoser> harmw, i dont follow.
<smoser> i launched the instance iwth 
<smoser> smoser's ssh key
<harmw> ok, and how did you add my ky?
<smoser> vi .ssh/authorized_keys :)
<harmw> hihi
<harmw> ok
<harmw> well I added my key to the c-i created beastie account
<harmw> login is ok, sudo works
<harmw> can you change the hostname from within the EC2 interface?
<Wulf> yo
<Wulf> I want to execute a "User-Data Script". This script needs a few variables. How could I provide them?
<harlowja_> 	 harm@manbearpig 
<harlowja_> to much southpark harmw 
<harlowja_> lol
<harmw> lol harlowja_ 
<harmw> I even have manbearpig.nl and cartman.land :>
<harlowja_> :-P
<harlowja_> nice, ha
<harmw> :p
<smoser> harmw, you can't change the hostname from within ec2.
<smoser> harmw, i have to run. thanks for your sniff.
<smoser> i'll make an 0.7.6 tomorrow... would love to have a yahoo (hiren_/harlowja run on it though on freebsd)
<harlowja_> hmmm, hiren_ have u had anytime to work through the above?
<Wulf> any help for my question, please?
<gholms> You have to stuff them into the script somehow, Wulf.  EC2 doesn't provide a way to set arbitrary info as you run instances.
<gholms> You could add tags later or upload things elsewhere, though.
<gholms> Templating FTW
<Wulf> gholms: then it's the script. Was hoping that cloud-init might provide some key-value store
<Wulf> thanks
 * gholms looks through modules to see if something reads that kind of thing
<gholms> If it's just a plain user-data script then yeah, that's the only input cloud-init is likely to get.
<gholms> You might be able to pull off some multi-part trickery, but I'm not at all familiar with how cloud-init handles that.
<Wulf> gholms: hmm.. I'm using mime-multipart already. MIME supports headers, so that might be a place. But sounds too ugly :)
<gholms> If it was up to me I'd template the script or try to put the bits that will change somewhere that it can download.
<Wulf> gholms: doing that now. Got a deadline for a beta version of the project, can always change it later if I find a neater solution
#cloud-init 2014-10-08
<harmw> smoser: ping
<smoser> harmw, here. whats up?
<harmw> I'm working on some code to get the proper fbsd interfacename
<harmw> should be ready soon
<harmw> can you change the instance hostname in AWS?
<harmw> btw, don't nuke that instance since I'm debugging on it :p
<smoser> harmw, you can't change a hostname in aws
<smoser> i can give you another instance if that'd help.
<harmw> hmk
<harmw> so ip-10-0-0-158 is the current hostname?
<harmw> nah, I think that'll work
<smoser> harmw, wlel, http://169.254.169.254/latest/meta-data/local-hostname would tell you
<smoser> but you seem to have no sane tools on that system (curl or wget)
<harmw> fetch :)
<smoser> i remember a time before ubuntu whne i liked to play with sharp pointy objects.
<harmw> :>
<smoser> rather than things that worked ;)
<harmw> smoser: https://code.launchpad.net/~harmw/cloud-init/amazon-fbsd-fixes/+merge/237595
<harmw> come to think of it, it's only relevant for configdrive setups since that's the only case where the nic is even used :p
<smoser> hooray!
<harmw> but nonetheless, it's always better then just using 'some' hardcoded name :p
<smoser> harmw, oh, cause it reads that in interfaces.
<smoser> yeah, thats all slated to change
<smoser> where we'll get info on the mac and find it that way
<harmw> yea, it should indeed be some higherlevel solution
<harmw> but for now this'll do the trick
<harmw> if only hiren_ would wake up
<harmw> since he actually uses configdrive
<smoser> harmw, the only coments i have on that merge proposal is that you should in general re-use 're.'
<smoser> with re.compile
<smoser> but its fine.
<smoser> ie:
<smoser> for line in ...
<smoser>   m = re.match('^\w+', line)
<smoser> is going to re-compile that regex
<smoser> where it could have used a cached version
<harmw> so -always- compiled regexes?
<harmw> ah, it's inside that for loop
<harmw> damn
<smoser> i dont know really about a good rule for when to do it and hwen not to
<smoser> but clearly in that case on the loop, you're wasting cpu. 
<smoser> dont worry about it.
<harmw> well in this case I honestly overlooked my own loop
<harmw> stupid though
<harmw> else I would've used a compiled regex, since you told that on some other review a while back :)
<jaxxstorm> is this the right place to discuss cloud-init bugs?
<harmw> jaxxstorm: yes
<harmw> bring it on
<jaxxstorm> I'm using the phone_home module and it's failing because of SSL, but my URL is http:// and on port 80
<jaxxstorm> output:
<jaxxstorm> https://gist.github.com/jaxxstorm/0b2f7b20718bcb462fc6
<harmw> could you use paste.ubuntu.com or something please :)
<harmw> anyway, it says this is the url: http://foreman.hostname.com80/unattended/
<jaxxstorm> yeah I've redacted the URL
<jaxxstorm> but basically it's http://foreman.companyurl.com:80/unattended
<harmw> ah, and that 80 is deliberatly without prepending :?
<jaxxstorm> yeah that comes from the foreman
<harmw> UrlError: [Errno 1] _ssl.c:492: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify faile
<harmw> you're using a selfsigned cert?
<jaxxstorm> well my foreman instance does have a self signed cert
<harmw> exactly
<jaxxstorm> but it's also available on port 80 without SSL for callbacks
<jaxxstorm> so why would it even attempt to use SSL on port 80 with http?
<harmw> isn't foreman just redirecting (forcing) to use ssl?
<harmw> c-i won't just start SSL by itself 
<jaxxstorm> if I call the exact same URL with curl it doesn't use SSL
<jaxxstorm> and doesn't redirect
<harmw> weird
<jaxxstorm> yeah
<jaxxstorm> in any case, is there a way to have it not verify the SSL cert?
<harmw> that's something smoser would know, though I think it is possible to import a custom CA
<harmw> which would make c-i accept the certificate aswell
<jaxxstorm> yeah I saw that module and I may go dow that route if needed
<harmw> it would be the most elegant solution :)
<harmw> smoser: could you accept the merger?
<smoser> merged. thanks.
<harmw> sweeeet
<jaxxstorm> okay, never mind, sorry guys
<jaxxstorm> < Status: 302 Found
<jaxxstorm> getting redirected to https
<jaxxstorm> :(
<harmw> I told you :P
<harmw> ah, you forgot curl -l
<harmw> *probably
<harmw> or actualy.. ah nvm
<jaxxstorm> I guess I can add the CA cert, but that'll be a pain
<smoser> jaxxstorm, you should probably be able to insert the ca cert in cloudconfig
<jaxxstorm> yeah I think I can
<jaxxstorm> does it rely on a package being present for CentOS?
<jaxxstorm> how does it add the cert?
<jaxxstorm> I want to make sure all the required packages are installed before I attempt it
<smoser> i think it shoudl all be contained in cloud-init (and usage of python-requests)
<harmw> cloudinit/config/cc_ca_certs.py: distros = ['ubuntu', 'debian']
<harmw> would that mean it's not supported on RHEL?
<jaxxstorm> it seems that way...
<jaxxstorm> :(
<harmw> jaxxstorm: open up a bugreport, this is something worth adding I'd say
<jaxxstorm> would love to, where do I go?
<harmw> https://bugs.launchpad.net/cloud-init
<jaxxstorm> done
<jaxxstorm> https://bugs.launchpad.net/cloud-init/+bug/1378874
<harmw> that module is currently using some Debian-specific stuff, but if the logic applies to RHEL it should be fairly easy to get it to support that
<jaxxstorm> thanks :)
<jaxxstorm> I'm cheating anyway
<jaxxstorm> runcmd: /usr/bin/curl -k <%= foreman_url('built') %> 
<jaxxstorm> btw, the app is amazing, has really helped my provisioning process, so thanks!
<harmw> if foreman is redirecting you, you need a curl -L to follow the 30x
<jaxxstorm> ah, v. true
<smoser> jaxxstorm, hm.. i dont knwo. i'm not sure how specific that would be. 
<smoser> harmw, harlowja_away https://github.com/cloud-init 
<smoser> now to get source there.
<harmw> why?
<harmw> smoser: what's wrong with LP? 
<harmw> btw, you may nuke that instance now
<smoser> harmw, ok. i'll kill instance
<smoser> nothing wrong with lp, but want to have something on github for people to find it, and or to contribute. there. some people just more comfortable there.
<harmw> sounds legit
<JayF> smoser: is the copy in git or bzr going to be canonical?
<JayF> I guess I could pick a better word
<harmw> :p
<JayF> I mean lowercase "c" canonical not uppercase "C" ubuntu
<JayF> :P
<smoser> :)
<smoser> JayF, i dont know. not thought of that yet.
<JayF> That's the most important thing to know, isn't it?
<JayF> split brain problem and all that
<smoser> yeah, its clearly important to know.
<harmw> +1 for keeping LP master :p
<JayF> +90001 for making it github
<JayF> you make it github and all the sudden you'll see more contributions from me
<JayF> that's for sure
<harlowja> holy crap, github, woah
<harlowja> although the PR mechanism sux still 
<harlowja> *imho
<gholms> On, the bright side, it means not having to use bzr.
<kwadronaut> heh
<kwadronaut> only the maintainer(s) have to take care of keeping everything in sync
<gholms> Yep
<kwadronaut> for git-git you can use hooks or send a message to github asking to mirror it (which means they'll pull in changes twice a day or so and it's more obvious for users that it's not the canonical one)
<kwadronaut> there's both bzr-git and git-bzr fwiw. besides that, i dislike both platforms.
<kwadronaut> (if we're shedding bikes, i'm taking part and now i'll run again)
<JayF> I paint my bikeshed git of any kind
<JayF> smoser: another option would be to put cloud-init in stackforge/ and use openstack processes
<JayF> smoser: I have no idea how you'd feel about that, but you'd get some quantity of testing infra for "free"
<JayF> smoser: plus you'd be more tightly integrated with one of your biggest users
<harmw> stackforge sounds cool
<smoser> JayF, this is true, and i've considered that before. but i'm not tied to openstack, and do not really want to be. 
<harlowja> i'd have to lean towards not also, i've got about 3 stackforge projects and an oslo one, so i've been through it, i'm not sure its buying much for cloud-init that github + travis couldn't buy (i do personally like the gerrit that openstack has over pull requests, but this is a managable dislike)
<harlowja> although the stackforge one could have an interesting connection into the rest of openstack if that stackforge repo somehow got plugged into the image-building
<harlowja> would be nice to have a new image-built when cloud-init review happens, and tested accordingly, thats like the true functional test that would be nice to have automated
<harlowja> but if said thing doesn't exist ( JayF might know more about the image building stuffs that could be possible) then i'm not sure it matters, github, stackforge...
<harlowja> i've had https://github.com/yahoo/Zake working with travis and for a project without ton of activity its worked out ok
<smoser> harlowja,  i want an easy "patch image with cloud-init" for sure.
<smoser> but i dont think building the image from scratch is useful.
<harlowja> well scratch or whatever other mechanism that i believe the tripleo folks/ironic people are using
<smoser> and 'mount-image-callback' or libguestfs makes patching it in trivial.
<harlowja> sure
<smoser> http://ubuntu-smoser.blogspot.com/2014/08/mount-image-callback-easily-modify.html
<harlowja> be nice to have whatever that is part of the review 'check' pipeline
<smoser> this is ture, but openstack would specifically be better off using a "stable" cloud-init for testing (ie, grabbing latest ubuntu image).
<smoser> and probably even latest image of stable release.
<harlowja> :)
<harlowja> so the oslo program has done something sorta neat for that
<harlowja> it has a check pipeline that checks the existing  (stable) and from source 
<harlowja> so u can get early warnings from the source 'check' and still not affect users of 'stable'
<harlowja> ex @ https://review.openstack.org/#/c/126791/ (the gate-*-src-taskflow are testing this source version)
<harlowja> while afaik the other users of taskflow are not using that source version (but the last release thats avaialble)
<harlowja> so this could do something similar
<smoser> hm..
<smoser> so that would seem like a 'nice to have'
<smoser> but stackforge would not seem like a requirement for that.
<smoser> in that they have "sources" that live other places.
<smoser> such as cloud-images.ubuntu.com or fedora.mirror.org/foo
<harlowja> smoser agreed
<harlowja> its not a requirement, but could be simpler to make happen (emphasis on could)
<harlowja> since we already have people here in this channel that work with openstack and the infra there
<harmw> openstack? what's that
<harmw> sounds scary
<JayF> I suspect if you moved cloud-init into stackforge/ you could easily convince people to help you get some of this testing working
<JayF> because of the large number of crossover between openstack devs/opers and cloud-init users
<JayF> I'm not saying *I* would (I owe this project other work already), but I'm saying people would :)
<harlowja> JayF so that means u would?
<harlowja> lol
#cloud-init 2014-10-09
<harlowja> harmw yt
<harmw> harlowja_away: sup
<smoser> harmw, so if i mark 0.7.6 today...
<smoser> will you push to ports ?
<harmw> smoser: as long as I can gt my cloud back online... (with the buildstuff inside)
<harmw> might wnt to wait just another day :)
<smoser> harmw, ok. i know that you've been very patient. so its hard for me, but i'm impatient now :)
<harmw> imagine how I feel now
<harmw> harlowja: ping
<harlowja> pong
<harmw> ping
<harmw> ha! I win
<harlowja> harmw oh ya, was gonna mention that me and some others met with RH people and they were like u probably shouldn't use that rhel6->7 migration script at any large scale, lol
<harlowja> so that reminded me of u, haha
<harmw> hehe
<harmw> did it on 2 machins now
<harlowja> i don't like those meetings, they trying to sell us more stuff again :-P
<harmw> :P
<harmw> did they mention why?
<harlowja> to much manual stuff i think, i didn't dig into it
<harlowja> i was almost gonna say 'wtf u make an upgrade tool if u don't recommend people to use it'
<harlowja> lol
<harlowja> but i resisted
<harmw> :P
<harmw> hopefully, rebuilding qemu-kvm is the last step required for my hypervisor to function
<harlowja> :(
<harmw> since it's a poorpeople cloud, I didn't migrate all instances to some other hypervisor :)
<harlowja> lol
<harmw> ok, so, building qemu-kvm with the rhev flag enabled
<harmw> just to get ceph blockdevice support in
<harlowja> ah
<harlowja> ya
<harlowja> RH does that more than i like
<harmw> uhu
 * gholms is going to have to ship qemu-kvm-rhev, too  :/
<harlowja> rhev, oh goodie
<harlowja> why is that still around?
<harlowja> doesn't that probably have like 1000 patches on it
<harmw> 1001, yes
<harlowja> 10 million
<harlowja> lol
<harlowja> qemu-kvm-0.12.1.2-2.355 has 2858 patch files
<harlowja> which is scary
<harlowja> i'm pretty sure u can't call it 0.12 at that point :-P
<harlowja> when u have more than 10 patch files its not the same version anymore, lol
<harmw> :p
<harlowja> especially sort of odd since RH i thought had good relations with upstream kvm/qemu?
<harlowja> i'd of thought that if they had good relations, the number of patches would be small, but maybe i'm reading into it to much
<gholms> You're reading into it too much.  They're all backports.
<gholms> Version bumps for that kind of thing are rather rare in a stable release, so apparently individual patches go in instead.
 * gholms chuckles a bit at the number of patches
<harlowja> fair enough, although i'd not want to be a maintainer of anything with ~2500 patches, lol
<harlowja> that would cause me to jump off building, lol
<gholms> Well, when you have git or quilt or whatever it isn't really that bad.
<harmw> hm, now why isn't qemu-img listing rbd as supported format :|
<harlowja> harmw i'm pretty sure thats compiled out
<harlowja> or not compiled in...
<gholms> Did you also install librbd1?
<harlowja> i think if u are compiling qemu your self u have to also do --block-drv-rw-whitelist=rbd (and a bunch of other stuff)
<harmw> harlowja: I defined rhev 1, so that should've been tken care of
<harlowja> hmmm, ok, no idea what that does, lol
<harlowja> i just know i see http://paste.ubuntu.com/8528714/ in a version of the qemu-kvm spec file
<harmw> though it looks like I defined that the wrong way
<harmw> %if %{rhev} --enable-live-block-ops \ --enable-ceph-support \
<harmw> %else
<harmw> thats the magicstuff
<harmw> but for some reason my old faithfull buildscript doesn't define rhev as 1
<harlowja> hmmm, okie okie
<harmw> so if that fails, ill just patch the spec
<harmw> which is overkill, for what I'm after here
<harmw> but hey, if it's about openstack, everything is allowed!
<harmw> :p
<harlowja> :-P
<gholms> I juat grab the qemu-kvm-rhev source package from them and build that.
<gholms> (Yes, the only difference is the flag at the top.)
<smoser> harlowja, patches are just a different name for commits
<smoser> what is the difference between upstreams 30,000 commits and a distros version-X+30 commits ?
<harlowja> who knows, lol
 * hiren_ forked early this week. Baby things will keep him away for a few weeks at least. :-)
<harmw> hiren_: +1 on that
<harmw> forked without bugs I hope?
<hiren_> So far, so good.
<hiren_> thanks.
 * hiren_ -> away
<harmw> and this was a private branch of yours?
<harmw> :p
<gholms> Awwww
<gholms> Also, eww.
<gholms> :P
<harmw> :P
<harlowja> hiren_ pretty sure u don't need a fork to get cloud-init into y! 
<harlowja> so hopefully shouldn't need such a thing, some patch files might be ok (but not ~2500 files, thx)
<harlowja> so maybe u are just meaning u cloned from bzr or soemthing?
<harmw> you rly not getting the joke here are you
<harlowja> oh
<harlowja> i get now
<harlowja> u guys sux
<harlowja> lol
<harmw> :>
<gholms> Haha
<harmw> ok, qemu is rbd aware and just booted instance #1
<harmw> now to fix the networking part of this hypervisor
#cloud-init 2014-10-10
<skullone> anyone run into 'No distribution found for distro rhel" error/
<skullone> Running centos6.5, and seems a recent update in EPEL may possibly have broken cloud-init
<skullone> ah, found the issu
<skullone> someone has a newer python-configobj in our internal repo, which seems to be buggy, and it trips up cloud-init
<JayF> I don't think centos6.5 offers a cloud-init package officially?
<smoser> skullone, can/should probably just drop the python-configobj usage.
<smoser> that is really only for *very* legacy stuff.
<harlowja> and for all that sysconfig stuff on rhel, lol
<harlowja> http://bazaar.launchpad.net/~cloud-init-dev/cloud-init/trunk/view/head:/cloudinit/distros/parsers/sys_conf.py#L56
<harlowja> ;)
<skullone> JayF: been on EPEL for a while now
<skullone> not official, but about as official as itll be
<smoser> harmw, 0.7.6 ?
<harmw> yea well, I'm expecting my cloud to come back online so I can scavange the fbsd port files from there :p
<harmw> but nonetheless, I don't see a reason to keep you from releasin 0.7.6
<harmw> well, I did the only testing so that kinda sucks
<harmw> smoser: I think 0.7.6 would be nice, and just wait till next week with the proper announcement
<harmw> the port should be ready by then as well
<smoser> proper announcement ?
<harmw> yea well, announcement or whatever
<harmw> I don't even know if you do that though :p
<harmw> hm, using neutron ML2 with openvswitch... brctl shoudn't display any bridges, right
<harmw> lets hope a node reboot will make sure the right neutron service is started this time
<smoser> harmw, i'd just send an email to cloud-init log
<smoser> err blog
<smoser> er.... mailing list
<harmw> oh my, we have our very own ML?
<smoser> :)
<harmw> you realy want me to google now, right?
<smoser> https://lists.launchpad.net/cloud-init/maillist.html
<smoser> harmw, i'm going to call 0.7.6
<harmw> sure
<harmw> 39 of 39 messages, page 1
<harmw> realy
<harmw> that's all:p
<harmw> 'IRC room dead? + Feature requests '
<harmw> I'd hardly call this room dead
<smoser> :)
<smoser> thanks harm.
<smoser> https://launchpad.net/cloud-init/trunk/0.7.6
<harmw> wicked
<smoser> email sent
<harmw> smoser: connectivity with my cloud is restored :)
<smoser> whoowhoo
<harlowja> hiren_ how's the fork going
<harlowja> u gonna be out for a while ?
<harmw> harlowja: you ever played with serial console access on kvm/openstack?
<harmw> eg. write to console.log, instead of just reading it?
<smoser> harmw, ?
<smoser> write to consolelog ?
<harmw> yup, providing serial input 
<harmw> but console.log is readonly, ofcourse
<smoser> from inside ?
<smoser> or outside ?
<harmw> outside
<smoser> i think it imght have ben hiren_ who i was talkign to at last summit. it was someone from yahoo.
<smoser> the issue is that libvirt puts it to a file
<smoser> so that it can be logged.
<harmw> yup
<smoser> you'd need a multi-plexer of some sort there as the target
<smoser> if you wanted to get a console then.
<smoser> such multiplexers do exist.
<smoser> there is also bug 832507
<smoser> that is related.
<harlowja> harmw i've not done much directly, someone here's done it
<harmw> finally
<harmw> victory
<harmw> both disks in this instance where feeling ill and bcause there was no vnc way of accessing 'em, I just mounted both to some other instance
<harmw> +1 for virsh attach
<harmw> smoser: cheetah is no longer a dependency, right?
<smoser> correct.
<harmw> ok, building freebsd port now
<harlowja> JayF yt
<JayF> yeah but pretty busy
<JayF> what's up?
<harlowja> np
<JayF> irc is async so ask but I reserve the right to make you wait ;)
<harlowja> a co-worker wanted to try out a rackspace baremtal thing, and i was like maybe JayF can help 
<JayF> the wonderful thing is
<JayF> you don't need my help
<harlowja> ?
<JayF> just signup for a standard rackspace cloud account; when you spin up servers use the "OnMetal - *" images from image-list and onmetal-{io,compute,memory}1 flavors
<JayF> or if you use mycloud.rackspace.com, there's a tab for it
<harlowja> but then i like have to pay for that? :-P
<JayF> I mean, free stuff you have to talk to folks other than me :P
<harmw> couponcode: JayF-R0XXX
<JayF> for purposes of "look at the shiny thing we did with ironic/cloud-init" I would spin up a node for you
<harlowja> hmmmm, sureeeeeee, would that be possible :)
<JayF> but if it's a co-worker, that's a little far down the path
<harlowja> nah, she just wants to look at what u guys did with cloud-init and ironic
<JayF> I mean, our patched cloud-init is here : https://github.com/pquerna/cloud-init/pull/1/files
<JayF> and our builders are: https://github.com/racker/cloud-init-docker-build which use https://github.com/racker/cloud-init-debian-pkg and https://github.com/racker/cloud-init-fedora-pkg
<JayF> the only thing we're doing otherwise to enable it
<JayF> is a patch to enable Configdrive in Ironic, which is upstream somewhere in gerritt
<harlowja> kk, that was one of her questions, config drive and such, anyways
<JayF> jroll: just in search of our upstream patches for configdrive
<JayF> jroll: have they ever been split out from the giant agent patch of giantness?
<jroll> JayF: oh, we haven't upstreamed them yet because process
<jroll> openstack process, that is
<JayF> jroll: so the only configdrive support we have in the open right now is in Josh's old giant agent patch?
 * harlowja not this josh
<harlowja> lol
<JayF> harlowja: JoshNang is josh :)
<harlowja> ;)
<JayF> harlowja: Rackers running Ironic are slowly invading all your IRC haunts, better watch out
<harlowja> :-P
<jroll> JayF: yes
<JoshNang> o/
<spandhe_> hey JayF, are u guys using config drive for Ironic?
<harlowja> spandhe_ (the coworker)
<harlowja> ;)
<JayF> hi spandhe_ 
<JayF> yeah, we hope to have it upstream'd in K
<JayF> there's a spec up
<JayF> and I can link you to a really old patch that has a lot of other stuff in it that has basically what we're running
<spandhe_> JayF: thats cool! can you give me the link for the spec?
<JayF> https://review.openstack.org/#/c/98930/ + https://review.openstack.org/#/c/99235/
<JayF> spandhe_: and some details on the general way we run onmetal -> http://developer.rackspace.com/blog/how-we-run-ironic-and-you-can-too.html -- that includes a link to the large older patch that'll never go upstream (https://review.openstack.org/#/c/84795/) which contains the configdrive bits
<JayF> just one of those things were that patch reflected, more or less, what we were doing at the time, but to get it upstream we had to chop it into smaller pieces
<JayF> we're all also in #openstack-ironic and glad to answer any questions you have :)
<spandhe_> thanks JayF ! I am going to go through these.. Will bug you in case I have any questions.. 
<JayF> spandhe_: just bug #openstack-ironic in general, during PST business hours and sometimes outside of it the team is in there
<JayF> and I think we all listed our IRC names on that blog jim wrote that I just linked
<harmw> smoser: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194295
<smoser> woot. thanks.
<gholms> Nice
<smoser> gholms, you going to re:invent?
<smoser> or openstack summit?
<gholms> There's apparently an all-hands during re:invent, so now I don't get to go to that.  Again.  :-\
<gholms> Not sure about the openstack summit.  When was that?
#cloud-init 2014-10-11
<harlowja> harmw if u get a sec, https://code.launchpad.net/~harlowja/cloud-init/test-fixups/+merge/238042
<harlowja> fixed some tests that weren't working for me locally
<harlowja> also since y! is going more ahead with chef, beefed up that module @ https://code.launchpad.net/~harlowja/cloud-init/better-chef-module
<harlowja> comments welcome/appreciated
<harmw> ah, chef
<harmw> thats on my wishlist for to long ...
#cloud-init 2014-10-12
<beaver6675> Hi
<beaver6675> ssh_authorized_keys is adding to /root, but disabling only one of the two keys...
<beaver6675> ...with "echo 'Please login as the user \"centos\" rather than the user
<beaver6675> Should it disable all the keys?
<beaver6675> The keys are correctly added to the default user with is centos (on  CentOS7 / cloud-init 0,7,5)
<beaver6675> root seems to get a malformed authorized_key file
<beaver6675> Line #1: no-port-forwarding...Please login as the user...<KEY1>
<beaver6675> Line #2: <KEY2>
<beaver6675> Should the lines get the "no-port-forwarding...Please login as the user..." prefix?
<beaver6675> I meant: Shouldn't all the lines...
<Wulf> beaver6675: why would you need disabled keys at all?
<beaver6675> The authorized_keys are meant for the centos/cloud-user default user
<beaver6675> but cloud-init seems to copy the keys to root anyway...
<beaver6675> and disables the login using the prefix command...
<beaver6675> but it only added the prefix commant to one of the keys...
<beaver6675> ...so it happened that the second key could be used to login to the root user...
<beaver6675> To be clearer: all the ssh_authorized_keys were added correctly to the default user...
<beaver6675> however the keys were also copied to the root user, and supposedly disabled with with a prefix command
<beaver6675> which echoed the message Please login as user centos instead of user root
<beaver6675> However one of the keys copied to /root/.ssh/authorized_keys was not disabled with this technique
<Wulf> beaver6675: I think that the keys should not be copied to the root user.
<beaver6675> Seems to be a bug...the key was an ECDSA key so the prefix was not prepended...
<beaver6675> With two DSA keys, /root/,ssh/authorized looks correct now.
<bechampion> hey all
<bechampion> im struggling hard with an issue 
<bechampion> im putting a dumb script on user-data on ec2 ,  something like " #!/bin/bash touch /tmp/test"
<bechampion> but it seems to run it only sometimes
<bechampion> im sure im missing something about how to "sysprep" a default ami
<bechampion> im using a custom ami (that came from a 14.04 ami ) but im reading that there's some stuff that i have to remove
<smoser> bechampion, you shouldn't have to remove anything.
<smoser> but it will only run once "per-instance" by default.
<smoser> you can change that to run "always" (every boot). but normally thats probalby not what you want.
<bechampion> thanks ,  is it ran by root?
<bechampion> cause im running an s3cmd but it doesn;t log out nothing ...
#cloud-init 2015-10-05
<smoser> hoonetorg, there have been a couple attempts to resolve your general query.
<smoser> some thigns you can do:
<smoser>  iso9660 or vfat on writable drive can simply be destroyed after you've read it.
<smoser>  that quite easilys olves your "x2go" situation above.  you do have to tell cloud-init that it is 'manual_cache_clean', so it does not go looking for the datasource again, but the data is gone once you've deleted it (assuming you've shred'd' or what not).
<smoser> the second thing you can do via http metadata service is to
<smoser> a.) null-route the datasource url after you've consumed it.
<smoser> also you can use '#include-once' in user-data.  and have some service that allows data to be read once.
<smoser> and then generate long un-guessable urls.
<smoser> i guess that was 'b'
<smoser> oh yeah. and cluod-init can null-route the ec2 metadata service for you with :
<smoser>  disable_ec2_metadata: true
<smoser> http://bazaar.launchpad.net/~cloud-init-dev/cloud-init/trunk/view/head:/doc/examples/cloud-config.txt
<smoser> for reference.
<hoonetorg> smoser: thank your very much for your answer
<hoonetorg> smoser: i hv a patch lying around for implementing injecting ca_certs for rh based distries. it implements what has begun at http://bazaar.launchpad.net/~jbellone/cloud-init/redhat-cc-ca-certs/view/head:/cloudinit/config/cc_ca_certs.py except the remove_default_ca_certs functionality.
<hoonetorg> smoser: i hv written mr. kai engert from rh an email, and asked him to explain how to remove standard ca-certs on rh the right way, but did not get an answer yet.
<hoonetorg> smoser: i hv no launchpad account and would like to show you what has been done as gist: https://gist.github.com/hoonetorg/c88e071885295d05dd95#file-gistfile1-txt
<smoser> hoonetorg, that seems reasonable.
<hoonetorg> smoser: i recompiled rpm package cloud-init on el7 and put it in my self made cloud images (oz). ca-cert injection works for me
<hoonetorg> and should work on el6 too (did not try yet). not sure bout el5.
<hoonetorg> not true, would not work on el5, command update-ca-trust does not exist there afaik.
<hoonetorg> smoser: once i hv remove_default_ca_certs implemented, would it be ok for you to include it, if I send you a gist link here.
<hoonetorg> or is there an easy way to use launchpad without creating an account?
<smoser> well, its nto that hard to create a launchpad account :)
<hoonetorg> :) i could imagine --- one account more --- o.k. I'll do
<smoser> i'm not terribly opposed to accepting a patch outside of launchpad but we still have to have cla signed and such.
<hoonetorg> :) i hv an account already and (surprise) the password i tried works, don't laugh, last login 2013, i can't remember, getting old.
<SimonTremblay> Hi, I have some question about using cloud-init to modify ubuntu cloud image disk partitions, but maybe it's not possible to do what I want with these tools.
<SimonTremblay>  If I want to create a specific partition layout like one partition for /var, one for /home, /tmp, etc. using ubuntu cloud image and cloud-init, I was thinking that I can use Disk Setup, but as I can see it's being run when root partition has been mounted...
<SimonTremblay> like that can say that error message:  [CLOUDINIT] util.py[DEBUG]: Failed reading the partition table Unexpected error while running command.#012Command: ['/sbin/blockdev', '--rereadpt', '/dev/sda']#012Exit code: 1#012Reason: -#012Stdout: ''#012Stderr: 'BLKRRPART: Device or resource busy\n'#012Traceback (most recent call last):#012  File "/usr/lib/python2.7/dist-packages/cloudinit/config/cc_disk_setup.py", line 588, in read
<SimonTremblay> I try to figure out how I can partition the disk automatically from ubuntu cloud image
<SimonTremblay> maybe I should create a custom image?
<SimonTremblay> (and sorry if I'm not at the right place to ask that question, I was wondering if there was a cloud-init user group too and can't find any yet)
<smoser> SimonTremblay, well, the image comes the way it is. you could probably get away with putting /home on a different partition and /tmp even with a reboot, and could deasily enough move /var/ content elsehwere.
<smoser>  /home cuold make some sense, but id' suggest for /var/ it might be better for you to manage whatever you're doing with the image to confine its data writing to /var/lib/your-app or some other directory  entirely
<smoser> and then just mount that directory to a different volume
#cloud-init 2015-10-06
<smoser> claudiupopa, around ?
<claudiupopa> yes
<smoser> hey
<smoser> i just responded (finally) to your data may provide filters or limits on what config modue
<smoser> bah
<smoser> data may provide filters or limits on what config modue
<smoser> bah bah
<smoser> https://review.openstack.org/#/c/220095/
<smoser> horay! i can paste!
<smoser> claudiupopa, if you ignore config-drive and openstack metadata service, do you have example of such "multiple datasources" ?
<claudiupopa> Oh, thanks, I'm looking right now.
<claudiupopa> No, except those two I don't recall other pair of data sources that can be found together.
<claudiupopa> But you have a good argument there, it's not worth it to architect something around this.
<claudiupopa> The only problem though is that configdrive has some capabilities that aren't in http and viceversa.
<smoser> oh ?
<smoser> what is in config drive that is not in MD ?
<smoser> personally i think config drive will go away over time
<smoser> and i'm willing to push an upstream patch that would have it declare the presense of the metadata service
<smoser> (and its location even)
<claudiupopa> the admin_pass field if I'm not mistaken, I don't recall right now, but I can reverify this.
<claudiupopa> And on the other hand, posting passwords for http.
<smoser> oh. you're saying no admin pass field in the MD ?
<claudiupopa> Not in the http one.
<smoser> odd. i can try to check quickly.
<claudiupopa> I need to check this first, so don't take my words for it. ;-)
 * smoser launches an instance
<claudiupopa> Yeah, if you could do it right now.
<smoser> sees 'adminPass' 'f7eeY3iiSSU9' in his 'nova boot' output
<claudiupopa> but in the instance, is it present in http and in the configdrive md? because one for sure didn't have it.
<smoser> claudiupopa, i think you're right.
<smoser> although i think its silly
<smoser> if the http service provides a way to say "done", then it might as well provide the password there.
<smoser> and jsut expect that until you say done you're not rooted
<smoser> claudiupopa, hm..
<smoser> where is it supposed to be ?
<claudiupopa> It should be in meta_data.json, admin_pass.
<smoser> claudiupopa, you're correct
<smoser>  http://paste.ubuntu.com/12699297/
<smoser> claudiupopa, so there is a 'password' *listed* in the http://169.254.169.254/openstack/latest/ index
<claudiupopa> Is it the same? I don't have an instance available right now.
<smoser> its just listed there.
<smoser> see that paste
<smoser> it is zero lenght
<smoser> not sure if it is one time only read
<smoser> looking at source, not sure where that is
<smoser> i dont see why its not in the md actuall. looking at source
<smoser> id ont see why.
<smoser> well, i think i'd still just consider the 2 of them to be one source then.
<smoser> got to run.
<smoser> later. thanks, claudiupopa . talk to you tomorrow
<claudiupopa> Okay, see you. Thank you for the review!
#cloud-init 2015-10-07
<natorious> morning
<smoser> good morning sir.
<natorious> I'd noticed the decorator properties in the http ds are not in the parent class.  Is that intentional?
<natorious> also noticed what you were referring to w/ network config returning and I'll fix that in the existing merge req
<natorious> re prop decorator, I was thinking that would change the method signature and therfore not inherit/override
<smoser> ok.
<smoser> cloud-init meeting
<claudiupopa> hi.
<smoser> hello natorious smoser claudiupopa
<smoser> jgrimm,
<smoser> Odd_Bloke,
<jgrimm> o/
<natorious> \o
<smoser> my bit.ly url for cloudinit-reviews somehow busted. :-(
<smoser> so
<smoser> http://bit.ly/cloudinit-reviews-public
<smoser> i finally got around to reading claudiupopa's proposal at https://review.openstack.org/#/c/220095/ yesterday
<smoser> talked with him a bit.  i think we agree that openstack's config-drive and MD are odd fellows.
<smoser> natorious, wonder if you have thoughts on that.
<smoser> would xenstore on rackspace still be a possible datasource ?
<natorious> yea, I don't see why not
<natorious> the image would have to have some baked in deps to be able to access it like a store
<natorious> but thats essentially how the openstack guest agents use it today
<smoser> it woudl be the preferred one there ?
<smoser> or do they now have openstack MD everywhere.
<natorious> likely, yeah.  Citrix makes it dead easy as a preferred
<natorious> were doing http and configdrive too
<smoser> citrix ?
<natorious> XenServer
<smoser> ok.
<smoser> ok. so... how about this.
<smoser> the one topic we have from last week was python2.6 .
<smoser> and Odd_Bloke quickly pointed out that there are official python2.7 sources for centos and for redhat
<smoser> in 'SCL's
<smoser> that still leaves me sles to look at, but i went and built some images last week and have them in a local cloud so i can easily poke around.
<smoser> so i think we can say 2.7
<smoser> then i guess move on./
<natorious> um
<smoser> um ?
<smoser> as in you dont like that?
<natorious> to clarify, the products I'm currently working on dont use xenstore
<natorious> at all
<natorious> dunno the full context
<smoser> does rackspace have any that to do your knowledge?
<natorious> yea, their public cloud
<natorious> this is how they mine that source too
<natorious> https://github.com/rackerlabs/openstack-guest-agents-unix
<natorious> so right now to get cloud-init to work w/ this guest agent
<natorious> you have to tweak the boot order and deps
<natorious> bc cloud-init pretty much requires networking to function properly and unless the guest agent has configured it, it wouldn't work
<smoser> right. 0.7.x definitely does.
<natorious> we were managing that ordering outside of the pkgs though
<smoser> that is a primary goal to be addressed.
<natorious> k, cool
<smoser> i kind of talked a bit to the plan for that in my response to claudio
<smoser> on boot, we have something that goes looking for "network config sources"
<smoser> that thing blocks boot until it decides how your networking shoudl be configured.
<smoser> it configures it, and then lets boot continue.
<smoser> later in boot (when network comes up)
<smoser> cloud-init again goes looking for a datasource for user-data, meta-data ... other things.
<natorious> makes sense
<smoser> i'll start trying to write this better into a spec
<smoser> it is tricky
<smoser> because figuring out what networking is supposed to be is not easy
<smoser> and figuring out if this is config you've found should be applied (and possibly overwrite the user's config) is not easy either. ie, if this was a reboot.
<smoser> honestly, ditching the "snapshot without clean" thing... woudl make things so much easier.
<smoser> natorious, i'll look back above at your questions here in a minute.
<smoser> and will try to write down my theory on boot order for cloud-init into a spec for review.
<natorious> ty
<natorious> I'd like to get this WIP configdrive merge request in today and have a few low fruit hangers left
<natorious> or we still waiting for discussion?
<smoser> natorious, i think we're done with meeting
<smoser> ok... so wht do you want me to look at
<natorious> oh, lol
<natorious> so is the taskflow bit a + now that 2.7 works?
<natorious> I'm finishing load and _get_data for the cd ds and I'll submit it as a WIP.   There were some properties defined in the http ds that were not defined as properties in the base
<natorious> wasn't sure if that was intentional
<smoser> wrt taskflow, i dont know. still need to lok at that. it has quite a dependency chain.
<natorious> also was hoping to chat a bit about BaseOpenStackSource.network_config
<smoser> and my virutal-env pip install of taskflow jsut failed here... doign a c compile
<smoser> i'll see if we can't strike that ctaskflow conversation up with Odd_Bloke later. who appears non-present.
<smoser> ok. your questions. you want to go down the list of what you wrote before meeting ?
<natorious> really its just _is_password_set in the  http ds is set as a property but the BaseDataSource._is_password_set is not
<jgrimm> smoser, are you cancelling next week meeting?  or still planning to have while you are travelling?
<smoser> well, yeah, i'm not going to be there.
<smoser> but willsend mail to that affect and say that it can occur in my absense.
<jgrimm> k
<natorious> and the network_config bit which w/ network_json being its own format, should we still plan on returning the json data in those cases and the file content in the other?
<natorious> like type check on the receiving end whatnot?
<smoser> i think it shoudl be a property in the base class.
<smoser> as we use it as one in the tests
<natorious> ah right, I'll include that change in here then too
<smoser> natorious and "file_content" ? you mean /etc/network/itnerfaces file ?
<natorious> yea
<natorious> the projects I'm working on are moving away from that to using network json but the way the ds classes are modeled would mean network_config could then return either or
<natorious> just want to make sure that was acceptable
<smoser> the end goal in my head is for cloud-init to read that network_json from its "network config source" (which here is an http source... see the tricky-ness of network config sources ? )
<smoser> and then turn that into an interneal representation of networking configuration and then render it.
<natorious> right, so dhcp to static
<smoser> since we have multiple different formats we're going to have to read.
<smoser> network_json, /etc/network/interfaces, ec2 metadata format ..
<natorious> if the ds class is to process each, its going to take me a bit longer on this
<smoser> well, dont worry about "rendering" the network config for now.
<natorious> k, so I'll just return it as is and look at either processing it outside of the ds or add to it when I get there
<smoser> just have the datasource fetch it. have it available. and some future "render networking" thing will take that as input and do its job.
<smoser> yeah. i think so.
<natorious> for the configdrive ds there were a few base methods that didn't make sense too. Like post_password and is_password_changed
<natorious> the base doesn't raise an exc so there could be unexpected results down the road
<smoser> i think NotImplementedError makes sense at least initially
<natorious> and thats all I got for now.  Will try and get this w/ some tests in today sometime.  I'll look at some network config bits after this too.  Hopefully get something to test w/ :)
<natorious> k
<natorious> where are you traveling to?
<smoser> seattle next week.
<natorious> ah sweet.  If you all end up going to the Austin, TX OpenStack Summit 2016, we should get up for sure
<natorious> I live an hour away from Austin
<smoser> claudiupopa, what would you use to render your specs/<spec>.rst  ?
<harlowja> smoser https://pypi.python.org/pypi/restview
<harlowja> what i do is
<harlowja> restview -l :5000 specs/
<harlowja> the open a webbrowsr @ localhost:5000
<harlowja> and bam
<harlowja> 'Every time you reload the page, restview will reload the document from disk and render it. This is very convenient for previewing a document while youâre editing it.' is nice
<smoser> thanks harlowja
<harlowja> np
<claudiupopa> Aaa, cool, didn't know about that, thanks.
<harlowja> its pretty nice
<harlowja> what i use for all my rst specs stuffs
<smoser> i'm guessing there are other tools that do this, and you will just laugh at me, but i had 'venv' to do things like this.
<smoser> https://gist.github.com/smoser/2d4100a6a5d230ca937f
<smoser> then i just have a 'restview' file in my ~/bin/
<smoser> #!/bin/sh
<smoser> exec venv restview restview "$@"
<harlowja> smoser cool, no idea, i have a tool that looks for a .venv on every 'cd' and tries to source it, and on leaving that directory exits the venv
<harlowja> that way i can have each repo i work on have a different venv, and just cd .. and all that will enter/exit it
<harlowja> https://gist.github.com/garyjohnson/394c58e22a2adfa103e2 and similar
<harlowja> various ones of those around
#cloud-init 2016-10-11
<robjo> smoser: ping
<smoser> hey
<smoser> robjo,
<robjo> smoser: Any thoughts on the e-mail I sent to the list yesterday? Have done some more digging and it appears to me that
<robjo> init.apply_network_config(bring_up=bool(mode != sources.DSMODE_LOCAL))
<robjo> i.e. stage # should be guarded such that it does not run during the -local phase
<smoser> well, the specific error you point to is fixed i believe
<smoser> er... hold on
<smoser> https://code.launchpad.net/~harlowja/cloud-init/+git/cloud-init/+merge/305882
<smoser> i belive is the one
<robjo> smoser: I can try this, but it still appears to be opposing the definition of the intent, cloud-init-local is set to run prior to network-pre, thus there is no guarantee that the device is up
<robjo> in this case why do we even try to read the device state? Should we no simply forgoe this whole network stuff in -local?
<smoser> ah
<smoser> robjo, right.
<smoser> sorry, i really, really need to write a description of all of this and what is supposed to happen.
<smoser> so local should run before networking comes up
<smoser> before the OS would bring up networking
<smoser> as it is going to configure it.
<smoser> it doesn't bring it up because the OS should on boot
<smoser> as it would normally in non-cloud-init boots.
<smoser> just as if cloud-init-local had run before boot and wrote the files
<smoser> thats the goal
<robjo> that at least is my interpretation based on what's in the unit file. thus stage#6 should be guarded and should not execute the network call at all if in local mode
<robjo> Oh, I think the light just came on and I see the chicken and egg problem
<robjo> in -local we want to write the config for the network interface, but in order to write the config we check if the device is actually online, thus we read the carrier file
<robjo> but that is not OK at this point
<robjo> so one option may be to write out configurations for every device we find whether the device is connected or not
<robjo> then let the network client figure it out from there
<robjo> the other option may be to delay the configuration as proposed in my e-mail
<robjo> btw, I did test the delayed config approach and that worked for me
<smoser> robjo, sorry.
<smoser> was distracted reading. sorry.
<smoser> why is it not ok to read the carrier ?
<smoser> because it's not been set 'up' i guess ?
<robjo> as the trace shows it may not be there, so we get EINVAL from the kernel
<smoser> sure... so in that case we decide "don't know"
<smoser> and assume it available i think
<smoser> delaing configuration until existing configuration as found in the system (ie, readying /etc/sysconfig)
<robjo> following the way I currently understand the logic that would imply that we will not write the config, so why bother to begin with?
<smoser> would mean that that network config might come up
<smoser> which might be wrong
<smoser> and or detrimental
<smoser> ie, if i launch 2 isntances from same captured node
<smoser> then they'd both bring up networking as the old ip address
<robjo> the wheels are turning, just a moment...
<robjo> So, at this point the configuration can only come from a config drive or the config file, as there is no network cannot pull any data from a server, correct?
<robjo> That also implies that we can simply write the configuration we get from the source, i.e. the config drive
<robjo> there is really no need to check the carrier flag or other status of the device.
<smoser> robjo, sort of.
<robjo> If we simply write the configuration we promise that the instance will not come up with a duplicate IP
<smoser> right.
<smoser> (or if it does, not our problem)
<smoser> the thing where it kind of matters is "fallback"
<smoser> basically, if cloud-init does not find anything at this point
<robjo> then once the config is written by -local and the network stack comes up it will sort out the interfaces that are actually in use
<smoser> it generates a config that equates to old behavior "dhcp on eth0"
<smoser> and writes that.
<smoser> but it tries to be a bit smarter, and not dhcp on a device that is not connected
<robjo> but the network client will figure that out, so if cloud-init always writes "dhcp" on "eth0" but eth0 is not there then dhcp-client, or in our case wicked will just drop that interface
<robjo> now of course we can argue whether it is better to generate the EINVAL error form the kernel or let the network client figure out that the interface isn't really there ;)
<robjo> I am not certain there is a good answer to that question
<robjo> Other than, if we try to be to clever we create problems ;)
<smoser> well, if the thing isn't connected, then its pointless to try to dhcp on it.
<smoser> but if we just go on , as i think the branch i pointed at does.... then we end up with "dhcp on eth0" and eth0 not being connected, but not much else we can really do.
<smoser> in the future, what we will be doing is like the digital ocean datasource does now.
<smoser> the cloud-init local will actually be part of every datasource...
<smoser> and the datasources will check to see if they are on their platform.
<smoser> if they are, then they'll configure networking manually enough to get to the network metadata service
<smoser> and find the real network data
<smoser> and then write that.
<smoser> and tear down their temporary stuff
<smoser> that make sense ? its what makes us able to get networking information from a source that lives on the network
<robjo> yes, makes sense
<robjo> backporting the patch to 0.7.8 for my package.....
<robjo> unless 0.7.9 is right around the corner ;)
<smoser> well, lets get that merged.
<smoser> does it work for you, robjo ?
<robjo> smoser: still backporting I probably need an hour before I can test, have a meeting in a couple of minutes
<smoser> robjo, ok. it did seem to fix things for others.
<robjo> I'll let you know as soon as possible
<hkominos> morning everyone. I would like to ask quick question if you dont mind. I am using a small openstack installation and i am passing cloud-init to configure the VM. I am using the cloud images from ubuntu for now. In those image
<hkominos> morning everyone. I would like to ask quick question if you dont mind. I am using a small openstack installation and i am passing cloud-init to configure the VM. I am using the cloud images from ubuntu for now. In those images the default user is Ubuntu. I dont want that created so I make a new one. However the default key which is passed from openstack never reaches the user[0] name created. Is that default behaviour?]
<smoser> hkominos, what is "default key" ?
<smoser> oh. i see. the ssh key.
<hkominos> I mean a key-pair created from the openstack UI
<hkominos> http://paste.openstack.org/show/585344/
<hkominos> this is the relevant cloud-init snipet
<robjo> smoser: works for me with the patch applied
<smoser> hkominos, i thin if you just set 'default: true' on one of those entries you'll get what you want
<smoser> shoot. no that doesnt seem to work even though it should
<hkominos> that is a good idea. +I think that the -default attribute would create a user named ubuntu thought. Not the one that i want to create. (i think)
<smoser> well i think it was intended to update the exiting 'default'
<smoser> just launching an lxc container, i get the user created
<smoser> and no ubunt user
<hkominos> you mean withou the -default user.
<smoser> http://paste.ubuntu.com/23308735/
<smoser> right
<smoser> all i get is /home/smoser
<hkominos> http://paste.ubuntu.com/23308739/
<hkominos> so this would create 2 users.
<hkominos> That is the only use of "default" tag that i know of.
<prometheanfire> going to have to finish the cloud-init gentoo networkv2 stuff to get v6-only networking working I think
<jgrimm> smoser, powersj:  wrt cloud-init integration testing... magicalChicken has some time to help with that, interested?
<smoser> sure.
<jgrimm> smoser, cool  i really want to get that off the ground, but wasn't sure if either of you'd started into it at all
<smoser> no. other than what i'd written there.
<jgrimm> smoser, what's ETA for next cloud-init release?
<smoser> i hadnt targetted one.
<jgrimm> ok, we probably should for the SRU waiting in the wings?
<harlowja> prometheanfire are u the main gentoo person?
<harlowja> prometheanfire  if so, got any time to look at https://code.launchpad.net/~harlowja/cloud-init/+git/cloud-init/+ref/kill-brpm
<harlowja> just preferring to use a single spec file...
<harlowja> makes things a little bit simpler...
<harlowja> though i  can say i didn't merge in the packages/suse/cloud-init.spec.in stuff; so there might be a tiny bit of work
<prometheanfire> harlowja: I suppose so
<prometheanfire> harlowja: do you have a diff?
<harlowja> ya, let me get one
<prometheanfire> the files modified doesn't look like I'd care
<prometheanfire> I treat it like a python package
<prometheanfire> a somewhat special one (due to having to run a script iirc)
<prometheanfire> https://github.com/gentoo/gentoo/blob/master/app-emulation/cloud-init/cloud-init-0.7.8-r1.ebuild#L66-L86
<prometheanfire> that's how I install
<prometheanfire> someone should look at https://code.launchpad.net/~prometheanfire/cloud-init/+git/cloud-init/+merge/307969 too :P
<harlowja> prometheanfire so the part that might bother u is that i dropped the suse spec file, lol
<prometheanfire> harlowja: I'm not suse :P
<harlowja> oh
<harlowja> nm then
<harlowja> lol
<prometheanfire> hwoarang might
<harlowja> kk
#cloud-init 2016-10-12
<amitprakash> Hi, I've enabled cloud-init-local, cloud-init, cloud-config and cloud-final services via systemd, however, on boot I don't see any of the services executing
<amitprakash> furthermore systemctl status cloud-* shows the Active status as inactive (dead)
<amitprakash> Finally, there are no logs in /var/logs .. any ideas why cloud-init isn't starting off?
<hkominos> hello all. Can anybody help with a smallo cloud-init problem that i have?
<prometheanfire> any chance https://code.launchpad.net/~prometheanfire/cloud-init/+git/cloud-init/+merge/307969 can get reviewed today?
<smoser> prometheanfire, is the description repetative ?
<prometheanfire> smoser: the actual commit message?
<prometheanfire> smoser: I'd say it's just fully explained
<smoser> ok. i thought the 2nd and 3rd paragraphs might have had some copy and paste and not cleanpu
<smoser> "cloud-inti-local needs to be run ...."
<prometheanfire> you've not heard of cloud-inti-local?
<prometheanfire> I don't see that anywhere
<smoser> prometheanfire, sorry, i typod
<smoser> the 2 and 3 paragraphs start with "cloud-init-local"
<prometheanfire> is that wrong?
#cloud-init 2016-10-13
<openstackgerrit> melissaml proposed openstack/cloud-init: Fix LOG.warn to LOG.warning  https://review.openstack.org/385987
<smoser> magicalChicken, https://code.launchpad.net/~wesley-wiedenmeier/cloud-init/+git/cloud-init/+merge/308218 <-- neat!
<magicalChicken> smoser: thanks, it works pretty well
<magicalChicken> smoser: heres the logging docs too
<magicalChicken> https://code.launchpad.net/~wesley-wiedenmeier/cloud-init/+git/cloud-init/+merge/308021
<smoser> magicalChicken, thank you
<harlowja_at_home> ultradocs!
<harlowja_at_home> ftw
<harlowja_at_home> smoser, can we somehow get https://code.launchpad.net/~cloud-init-dev/cloud-init/+git/cloud-init/+ref/master/+activereviews listed on https://code.launchpad.net/cloud-init :-P
<smoser> you *can* get there.
<smoser> click master
<smoser> then
<smoser> 20 branches proposed for merging into this one.
<harlowja_at_home> hmmmm
<harlowja_at_home> ok
<harlowja_at_home> :-P
<smoser> harlowja_at_home, you can file a bug against launchpad
<smoser> tha't dbe how it'd get fixed
<harlowja_at_home> but but u are launchpad
<harlowja_at_home> mr.canonical
<rharper> smoser: I've updated my snapuser/local-user branch with support for local-user assertions; I've tested and validated in lxc and then in Ubuntu-Core-16; interested in your review/feedback now that it's functionally complete. https://code.launchpad.net/~raharper/cloud-init/+git/cloud-init/+merge/304700
<smoser> rharper, ok.
<jgrimm> rharper, obviously you can ignore my review comments if they are nonsense. :)
<rharper> you're not supposed to say that  =)
<jgrimm> lol
<jbrooks> cloud-init is starting up and creating an ifcfg-eth0 config file, which includes the setting 'NM_CONTROLLED', False -- I'd like to override this to True. I'm having trouble figuring out how, though
<jbrooks> https://git.launchpad.net/cloud-init/tree/cloudinit/net/sysconfig.py
<jbrooks> Alternatively, I'd like to tell cloud-config not to create this file at all
<jbrooks> I'm having trouble figuring out how to do that
<smoser> jbrooks, you can disable networking entirely
<smoser> # To disable cloud-init's network configuration capabilities, write a file
<smoser> # /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg with the following:
<smoser> # network: {config: disabled}
<smoser> (that is written as a header in cloud-init's /etc/network/interfaces renderer)
<smoser> i would think you dont want network manager managing your devices though.
<prometheanfire> smoser: do I still need to edit that pr?
<jbrooks> smoser, awesome, thanks, I'll try that
#cloud-init 2016-10-14
<powersj> Reading the docs there is a "preserve_source_list" option to prevent sources.list from being modified. However, it looks like it does not have any effect.
<powersj> Then I looked at a modified sources.list and at the top there is a comment about "apt_preserve_source_list", which is different thant he docs
<powersj> 1) which "verb" should I use? 2) can I use it to prevent any changes? or only some?
<jgrimm> powersj, i'm far from knowledgeable.. but the docs do say  "only  extra  source specifications will be written into /etc/apt/sources.list.d/* " even when preserve_source_list is true.    WRT you're question #2 (looks like only 'some' is the answer)
<rharper> powersj: jgrimm:  recall that the base /etc/apt/sources.list is generated from a template
<rharper> there's a default template built-in to cloud-init; or you have to provide your own template
<rharper> combined with jgrimm comment, the preserve would only be for .d/ entries IIUC
<rharper> cpaelzer might know more;  powersj also looking at curtin's vmtest for apt may be informative
<jgrimm> rharper, good idea wrt curtin tests
<jgrimm> powersj, i'm curious to know more by what you mean " there is a comment about "apt_preserve_source_list", which is different thant he docs"  .. sounds peculiar
<powersj> rharper: jgrimm thanks, from the note in the docs made me think it would preserve sources.list not the .d/*
<jgrimm> ah
<jgrimm> if you think some clarification could improve things, please do submit fixup. :)
<powersj> jgrimm: here is from a cloud-init generated source.list: https://paste.ubuntu.com/23324063/
<powersj> so that mentions apt_preserve... but I don't see that mentioned anywhere else in the docs
<magicalChicken> i think cloud-init should follow 'preserve_sources_list'. in cc_apt_configure.py at line 300 it checks if that's there before generating
<rharper> powersj: that's if you snapshot and boot it in a different instance
<rharper> then cloud-init won't re-create the templated file
<rharper> powersj: are you seeing that sources.list is re-written when you switch instances ?
<powersj> rharper: haven't tried that, just trying to understand all the options and which to actually use.
<rharper> gotcha
<magicalChicken> powersj: the apt_preserve_sources_list is rewritten to preserve_sources_list in cc_apt_configure.convert_v2_to_3_apt_format
<powersj> magicalChicken: ah! so it is a legacy name so to speak
<jgrimm> ah, apt_* version is old, so indeed maybe useful to fix up
<jgrimm> yeah
<powersj> "Convert old to new keys..."
<magicalChicken> powersj: yeah, the new format is everything under a general apt: key
<jgrimm> so looks like a minor cleanup bug for the emitted text
<harlowja> smoser did u ever get my cla email ?
<smoser> where did you send ? more contexst ?
<harlowja> godaddy never got a copy of theres
<harlowja> let me figure out where i sent it
<harlowja> somewhere
<harlowja> lol
<harlowja> (canonical ccla for godaddy)
<harlowja> Scott Moser <smoser@ubuntu.com>
<harlowja> that one
<harlowja> sent again :-P
<smoser> k
<harlowja> smoser so mdorman may have some resources for VMs :)
<harlowja> if we can just figure out what we want :)
<harlowja> we/canonical/us ...
<mdorman> hello o/
<harlowja> o/
<harlowja> smoser is https://public.etherpad-mozilla.org/p/cloud-init-centos-unittest still the idea for rhel?
<mdorman> so i am not totally up to speed with the whole discussion here, but we should be able to provide you N VMs to help with this.  but if you need an openstack api endpoint to hit as a way to dynamically spin up/down vms, thatâs a little more complex and iâm not sure we can accommodate that (we donât have an OS api exposed publically today)
<harlowja> smoser is the one up to speed :-P
<harlowja> haha
<smoser> see the 'mostly now'
<smoser> https://gist.github.com/smoser/19e65095b342e98fd4d6466e4d4fa1ac
<smoser> that works last i checked
<harlowja> so with that kind of stuff just VMs with LXC would be fine
<harlowja> no need for API acccess
<harlowja> just some VMs with ability to login (for certain keys)
<harlowja> (perhaps?)
<smoser> actually.. so using lxc i can npretty easily run unit tests as seen there.
<smoser> and we can do that on existing canonical hardware.
<harlowja> k
<smoser> can/should
<harlowja> canonical orange boxes?
<mdorman> :)
<harlowja> or whatever they were called :-P
<smoser> so at the moment i guess i dont need anything
<smoser> right, all our boxen are orange.
<harlowja> just like the next president!
<harlowja> lol
<mdorman> ehe
<mdorman> alright, cool.  well if thatâs something we can assist with, feel free to reach out to me and/or via josh.  itâs pretty easy for us to stand up
<smoser> ok.
<harlowja> wfm
#cloud-init 2017-10-09
<blahdeblah> Hi. If I want to use cloud-init in VMs on a standalone host, is there an easy way to create the metadata server to provide them with the correct userdata?
<akik> blahdeblah: you can use any httpd to serve the files and use ds=nocloud-net
<_ix> Good afternoon folks. I'm having some extended issues with 0.7.9 and 17.1 on CentOS 7.4 in OpenStack deployments.
<_ix> 0.7.9 exhibited a bug with puppet, but if I'm reading this correctly, that was resolved in 17.1
<_ix> https://bugs.launchpad.net/cloud-init/+bug/1699282
<ubot5> Ubuntu bug 1699282 in cloud-init "cloud-init process fails to configure puppet" [Medium,Fix released]
<_ix> As suggested, we found a recent build of 17.1 from copr, but it's exhibiting other issues like not dropping the ssh keys to cloud-user or abiding by the additional configuration files we're passing into instantiation.
<_ix> Any idea why I'd be getting `<cloudinit.simpletable.SimpleTable object at 0x1e01ed0>` in my network device table output.
<blkadder> Hi all, having an issue with write_files. File is created fine, permissions are set fine, but owner is not and remains root. Doing chown manually on the file to the proper user and group (postgres) works fine. Looked through the logs and nothing popped out. Any suggestions where to look?
<blkadder> Ooh, I am guessing write_files happens before package install where postgres user is created.
#cloud-init 2017-10-10
<leonaldo> is it possible that cloudinit will rerun with local configuration if network is not archieveable
<leonaldo> i assume that it only run per instance with default configurationã
<leonaldo> ð
<rharper> smoser: powersj:  saw this in the log here: <_ix> 22:34:48> Any idea why I'd be getting `<cloudinit.simpletable.SimpleTable object at 0x1e01ed0>` in my network device table output
<rharper> would we have a cloud-init.log from a centos boot in ci ?
<smoser> rharper, well, its where it is rendering the table for display. :-(
<rharper> smoser: right, missing a str method or something
<blackboxsw> will check it out. see if I can reproduce it
<blackboxsw> rharper: we reproduced it w/ lxd, I'm working on a fix for simpletawble
<blackboxsw> simpletable even
<rharper> blackboxsw: cool
<blackboxsw> looks like that issue with simpletable also broke ssh_authkey_fingerprints
<blackboxsw> fix committed locally, adding a couple more unit tests
<intheclouddan[m]> is there a clean way to remove a \n from a set_fact? I'm defining a value for it and not sure why that value, IE 0\n or 1\n is being set that way and not just 0 or 1
<intheclouddan[m]> wrong room...
<blackboxsw> smoser: https://code.launchpad.net/~chad.smith/cloud-init/+git/cloud-init/+merge/332066
<blackboxsw> intheclouddan[m]: :)
<smoser> powersj, when c-i runs on a MP
<smoser> it does not collect any artifcats, is that correct ?
<powersj> smoser: correct only the console output of the tests
<smoser> i'd have hoped to have been able to look at the artifacts from the integration test of the MP abov e from blackboxsw  and see that it had hte desired content in /var/log/cloud-init-output.log
<powersj> smoser: put in a card for me and I can change that
 * blackboxsw installs on aws, cleaned-boot env to check
<smoser> https://trello.com/c/fWq8GFKB
<powersj> smoser: thx
<blackboxsw> http://paste.ubuntu.com/25714850/ an aws clean-boot run
<blackboxsw> with my branch
<smoser> blackboxsw, it failed integration test for maas
<smoser> i think just because no good reason
<smoser> but...
<_ix_> I'd be down to test whatever you folks have got.
<smoser> _ix_, the simpletable issue you reported is in process of being fixed
<smoser> https://code.launchpad.net/~chad.smith/cloud-init/+git/cloud-init/+merge/332066
<_ix_> That's really great. Thank you!
<blackboxsw> yeah that looks like the same case _ix_
<blackboxsw> yeah we just ran into that today too
<blackboxsw> should have a daily copr build up today with that fix
<smoser> powersj, https://jenkins.ubuntu.com/server/job/cloud-init-ci/398/console
<smoser> do you recognize that as "transient yum noise?"
<smoser> with a better placement of the '?'
 * smoser triggers rebuild
<smoser> https://jenkins.ubuntu.com/server/job/cloud-init-ci/399/
 * blackboxsw is trying to build in my centos lxc
<powersj> smoser: yes
<powersj> Cannot retrieve metalink for repository: epel/x86_64. Please verify its path and try again
<powersj> is networking noise/issues
<powersj> "mirror.bytemark.co.uk" because we know those super fast US -> UK pipes are always faster... not
<smoser> faster than .jp pipes usually .  "faster" is a relative term.
<powersj> :)
<powersj> true
<blackboxsw> ci looks happy this time https://code.launchpad.net/~chad.smith/cloud-init/+git/cloud-init/+merge/332066
<blackboxsw> also just built and installed on centos7 in an lxc here to validate
<blackboxsw> smoser: are you working on the apport bug? otherwise I can peek
<blackboxsw>     def raw_input_char(self, prompt):
<blackboxsw>         '''raw_input, but read only one character'''
<blackboxsw> heh, kinda built into the DialogCLI class
<smoser> blackboxsw, you can take a look for sure
<smoser> i coudlnt figure out what was getting called
<smoser> dmulford_, you there?
<smoser> https://code.launchpad.net/~smoser/cloud-init/+git/cloud-init/+ref/fix/rh-subscription-add-null-check
<dmulford_> smoser: yep, what's up?
<smoser> just posted on your mp
<smoser> blackboxsw, you want to pull your MP
<smoser> or i can
<blackboxsw> thanks I'll pull. keeps me in practice.
<dmulford_> smoser: ahh perfect :)
<smoser> ok.
<smoser> blackboxsw, ok. pull that, and then you want to do an artful new-upstream-snapshot ?
<smoser> and then we can do one for x and z also
<smoser> and while i wait i'll just think about the sru bugs.
<dmulford_> smoser: thank you, this looks great! I will pull and test it out as you've requested
<blackboxsw> smoser: got a lead on the apport fix  http://paste.ubuntu.com/25715415/
<blackboxsw> that'll force read two chars if choices are > 10 (10 includes one key for the builtin "C" cancel).
<blackboxsw> anyway. onto the MP for cloud-init. then I can manufacture a 'good' fix for apport I think
<blackboxsw> was just testing on artful
<blackboxsw> merged simpletable fix. working on artful now
<blackboxsw> only change in apport behavior is that any choices with greater than 10 items, will have to hit <enter> after single-character choices
<smoser> i didnt see where that was
<smoser> that you had to hit enter. how does/did you do that ?
<smoser> i'd let the choices go to 100 at least before complaint. its a long list, but you raising RuntimeError is just going to make someone not file a bug.
<smoser> that they were going to file
<blackboxsw> smoser when you say 'y' for simple choices (Y/N/C) it is just one character
<smoser> hm... funny. you could instead of raising RuntimeError you could file a bug "too many choices in question 'XXXX'"
<blackboxsw> if it's a 18 item choice (like what cloud you are on) you have to hit >enter> for choice 9 or 'c'
<smoser> yeah, that makes sense. but ididnt see where you did that in your patch
<smoser> it reads 2 chars.
<smoser> ah
<smoser> .strip()
<blackboxsw> yeah 1 chars plus the strip
<blackboxsw> 2 I mean
<blackboxsw> I was wondering what you thought about that RuntimeError. it's something that should file a bug against package X.
<blackboxsw> maybe it just appends to the report that is being created .   .... 'question X had too many choices so user's couldn't respond'
<blackboxsw> s/user's/user/
<smoser> blackboxsw, why cuoldnt user respond ?
<smoser> you arbitrarily picked '50' as too long
<smoser> oh. it gets bad when over 100. casue then the user has to hit enter twice for < 10 :)
<blackboxsw> heh, will I just thought is was an arbitrarily long set of options to the point that it was unreadable
<blackboxsw> just a line in the sand. that doesn't really need to be drawn
<blackboxsw> but, the logic itself only handles up to  99 choices
<smoser> blackboxsw, i'd let it go to 100. personally.
<smoser> i have a scrollbar on my terminal
<blackboxsw> heh true
<smoser> blackboxsw, https://hackmd.io/BwUwrAhgRg7ADFAtMCBOJAWCDHQGwyIBmcAJqiBnhiAExRRA?both
<smoser> cank you see that ?
<smoser> kind of etherpad + markdown.
<_ix_> Hello again -- do the successful builds appear in copr immediately?
<smoser> powersj, can you confirm...
<smoser>  https://jenkins.ubuntu.com/server/view/cloud-init/job/cloud-init-copr-build/
<smoser> if i rebuild that, it will do trunk -> copr -> _ix_-gets-what-he-wants
<blackboxsw> smoser: I can see that
<_ix_> smoser: Very cool. I think we can be patient and wait for the regular nightly and give it a shot tomorrow.
<powersj> blackboxsw: yes that pushes to the cloud-init-dev copr repo
<powersj> smoser: ^
<smoser> _ix_, i just pushed "go"
<smoser> so i'm guessing 20 minutes-ish
<blackboxsw> ok smoser I'm ready for pushing to artful I think
<blackboxsw> got time for a hangout?
<blackboxsw> to check that I've gone through  the proper release steps
<smoser> yeah
<smoser> i'll join in m inute
<blackboxsw> smoser: https://code.launchpad.net/~chad.smith/cloud-init/+git/cloud-init/+merge/332076
<blackboxsw> https://code.launchpad.net/~chad.smith/cloud-init/+git/cloud-init/+merge/332078
<blackboxsw> https://code.launchpad.net/~chad.smith/cloud-init/+git/cloud-init/+merge/332080
<powersj> FYI there is a new daily build on COPR https://copr.fedorainfracloud.org/coprs/g/cloud-init/cloud-init-dev/
<smoser> blackboxsw, https://bugs.launchpad.net/cloud-images/+bug/1722663
<ubot5> Ubuntu bug 1722663 in cloud-images "Azure: /etc/resolv.conf points to /run/resolvconf/resolv.conf in artful" [Critical,Confirmed]
#cloud-init 2017-10-11
<dudeotron> So, can anyone point me at a blog-rant about why https://github.com/pellaeon/bsd-cloudinit is a thing? is it too hard to get cloud-init proper to run on bsd?
<smoser> dudeotron, i'm not aware of the motivation. we do have recently several commits to improve freebsd. specirfically on azure.
<blackboxsw> it's interesting, so it's a spinoff of cloudbase-init instead of cloud-init
<smoser> blackboxsw, hostname stuff is a mess . :-(
<blackboxsw> smoser: want to hangout to gripe
<smoser> cant'. at library.
<blackboxsw> integration tests are improving :) they were disabled
<blackboxsw> and broken
<smoser> oh. :-(
<smoser> the chef tests i know were disabled
<blackboxsw> but we'll have a puppet, landscape and chef test working appropriately soon
<smoser> because we didn't want to depend on network resources
<smoser> ie, we dont want c-i failing because chef.io is down or transient
<blackboxsw> yeah I'm adding chef local (knife) and puppet local (apply) tests which shouldn't have to hit the network. I *think* our goal with these integration tests is to combine as many features or cc module as possible because the integration tests are so costly
<smoser> blackboxsw, yeah, thats kind of where we are moving.
<smoser> what i'd really like to have is a bunch of different configs available and tests that test those things.
<smoser> and then the ability to combine configs and run all relavant tests
<smoser> blackboxsw, some thinking put into bug https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1722668
<ubot5> Ubuntu bug 1722668 in cloud-init (Ubuntu) "Azure: bouncing of network device/publishing of hostname fails on artful" [Critical,Confirmed]
<smoser> and linked some other bugs there too.
<blackboxsw> thx smoser, just refining the integration tests here
<blackboxsw> slow going
<paulmey> smoser / blackboxsw : we'd like to track some Azure-specific telemetry work...
<paulmey> what would be the best place to do that?
<paulmey> LP bugs?
<blackboxsw> hrm, generally I'd prefer LP bugs we can update etc. But is cloud-init delivering a feature for that?
<paulmey> yeah, I'll be coming up with an Azure specific reporter that I plan to enable through the data source...
<dudeotron> The silliness I'm encountering is with digital ocean, and i'm trying to figure out what the story is ...
<dudeotron> I'm really not sure what I can do to help with this though :S
#cloud-init 2017-10-12
<blkadder> Is there a way to specify installation order of packages?
<blkadder> Iâm finding that they arenât necessarily done in the order specified.
<redcavalier> A few weeks ago, I ended up filing a bug related to the cloud-init package on centos 7 on the centos bug tracker. I haven't had any feedback from centos since, but I'm figuring out I'll probably need to make my own package. Are there any pointers as to how to properly make a spec file for the rpm for cloud-init? I've never built my own packages before.
<redcavalier> (btw, the bug prevents root filesystem resize on boot)
<blackboxsw> redcavalier: we have nightly builds in our copr repo at  https://copr.fedorainfracloud.org/coprs/g/cloud-init/cloud-init-dev/ if you'd like a centos specific bug fix in cloud-init upstream I'm sure we'd be happy to look it over with a bug filed at https://bugs.launchpad.net/cloud-init/+filebug referencing your centos bug
<blackboxsw> to get yourself started, we have some build tools that help us out when testing:
<blackboxsw> if you are building yourself. you could look at running: "make ci-deps-centos" to get all build dependencies
<blackboxsw> then try "make rpm"
<blackboxsw> it builds an rpm for us from cloud-init/packages/redhat/cloud-init.spec.in
<redcavalier> I see. I'll make the launchpad bug and then go forward with testing newer versions.
<blackboxsw> that'd be good, we have addressed a couple of resize fs bugs in recent history on lp:cloud-init/master
<redcavalier> Out of curiosity, are you aware if the the centos official builds are based on the latest cloud-init versions? Or do they generally use older versions? I'm not sure if their numbered releases match the upstream numbers, or if they just renumber them when released as a centos package.
<blackboxsw> redcavalier: most distros generally lag the latest cloud-init version by a little bit. We are working on improving the distro & cloud adoption frequency
<blackboxsw> I'd expect centos is still on 0.7.9, but we've recently released 17.1 (re-versioned to match <YEAR>.<minor-release-num>
<redcavalier> blackboxsw, yes, centos just release 0.7.9 last month, they were on 0.7.5 before
<redcavalier> Normally I would have downgraded until my issue is fixed, but I'm getting pressure from higher up to not downgrade so I'm looking for alternatives. Since this issue needs to be fixed pretty much yesterday, as it affects all our customers, I'm crossing my fingers that upgrading will fix it.
<blackboxsw> out of curiosity: redcavalier, do you have a link to that centos bug
<redcavalier> yes, https://bugs.centos.org/view.php?id=13931
<blackboxsw> redcavalier: that texture of error looks like it might be pointing to invalid vendordata from your cloud instance
<redcavalier> ftr, our cloud-init userdata does quite a few operations, like writing network files, changing passwords, executing scripts, but the only operation that has started to fail is the resize.
<redcavalier> blackboxsw, yea, but vendordata is empty and has always been
<redcavalier> This is on openstack Ocata btw
<blackboxsw> hrm. I'll peek at our ocata instances as well tomorow. and I'll look back in the irc log for when you first brought this up
<blackboxsw> this convesation/problem rings a bell
<redcavalier> yea, it was last month, I have the log right here
<redcavalier> Thu Sep 28 around noon japan time
<blackboxsw> cheers. will look it up a bit and see if anything jogs a memory.
<blackboxsw> ahh thanks again for the reference
<redcavalier> I'll come back tomorrow at around the same time to see if you'Ve seen anything. In the meantime though, I'll continue testing with more recent versions on my side.
<smoser> paulmey, so azure clients... the python one 'az' is generally the future plan ? rather than the node 'azure' ?
<paulmey> Oh yes, smoser , definitely
<smoser> paulmey, ok. thanks.
<smoser> i filed https://github.com/Azure/azure-sdk-for-python/issues/1527
<smoser> find its usage odd.
<smoser> i dont htink that was the right place though
<smoser> there. https://github.com/Azure/azure-cli/issues/4656
<paulmey> smoser: there was much complaining about positional parameters on the nodejs cli... so now everything is a named parameter. Thanks for giving feedback though!
<smoser> paulmey, funny
<smoser> its very reminiscent of lxc 1.0 interface
<smoser> lxc-create -n containername
<paulmey> in a boo hoo way or in a ha ha way?
<smoser> but containername was required (and quite possibly the only argument needed)
<smoser> lxc-delete -n containername
<smoser> WHY DO I NEED -N !
<smoser> but lxc 2.0/lxd is:
<smoser>  lxc delete containername
<smoser> oh well
<paulmey> I guess you'll have to wait for az 2.0 then...
<smoser> blackboxsw, https://bugs.launchpad.net/cloud-init/+bug/1723213
<ubot5> Ubuntu bug 1723213 in cloud-init "vendor_raw stored to disk is broken if non-empty and not bytes" [Undecided,New]
<smoser> its not as bad as we thouguht though
<smoser> the key thing i realized...
<smoser> nothing uses the vendordata_raw.
<smoser> we dont ever read it back. its just there for other consumers. it should be a blob.
<blackboxsw> for other consumers that load the bpickle and run get_vendordata() on the datasource?
<smoser> other consumers ?
<blackboxsw> per "its just there for other consumers"
<smoser> yeah, and i suspect there arent many.
<smoser> and it really should be a blob.
<blackboxsw> s/m// :)
<blackboxsw> just because it's also broken right?
<smoser> well that does make it harder :)
<smoser> blackboxsw, ok... so i'll start at bottom of the checklist
<smoser> in https://trello.com/c/wROS4mKT
<blackboxsw> smoser: I'm testing landscape right now
<powersj> smoser: that bug you just filed, isn't it the same as LP: #1722992
<ubot5> Launchpad bug 1722992 in cloud-init "On the latest centos 7 release, we are unable to resize our instances filesystems" [Undecided,New] https://launchpad.net/bugs/1722992
<smoser> it probably is.
<smoser> whoops
<powersj> smoser: thx
<smoser> blackboxsw, i'm going to try to fix mount-image-callback lxd:
<blackboxsw> smoser: yes please.
<smoser> as i tried to use it (through lxc-proposed-snapshot) and foobar
<blackboxsw> I'll need that shortly I suspect
<blackboxsw> yeah, I had been using artful, so hadn't gotten that far yet
<blackboxsw> mount-image-callback is used by lxc-proposed-snapshot right?
<smoser> yes. as i found :)
<smoser> i didnt remmeber, but yeah
<blackboxsw> pushed two bug updates to sru-info for puppet and landscape
<blackboxsw> moving onto the list from the top of the trello card
<blackboxsw>  Unapproved: rejected cloud-init [source] (zesty-proposed) [17.1-17-g45d361cb-0ubuntu1~17.04.1]
<blackboxsw> hmm checking it out
<blackboxsw> well see it in rejected state in the queue https://launchpad.net/ubuntu/zesty/+queue?queue_state=4&queue_text=
<blackboxsw> trying to find the history of it
<smoser> blackboxsw, 17 is less than 18
<smoser> 18 is in
<blackboxsw> ahh dumb me
<smoser> https://launchpad.net/ubuntu/+source/cloud-init
<smoser> and on that link above ...
<smoser> "higher numbers are better"
<smoser> :)
<smoser> the source of my confusion earlier
<smoser> i think the best thing to do for mount-image-callback is to drop support for lxd:
<powersj> doh
<smoser> but add a 'lxc-chroot' which does something like it did
<smoser> i had a lxc-chroot before, but moved to using mount-image-callback as it was nice. but the chroot path seems quite plausable now.
<blackboxsw> smoser: you mean like sudo chroot /var/lib/lxd/containers/a1/rootfs/
<blackboxsw> and then manipulate the rootfs before lxc start a1
 * blackboxsw looks at mount-image-callback again to see what it thinks it is doing
<smoser> thats mostly what mount-image-callback does
<smoser> the two things it really aded for lxd was
<smoser> well... it effectively gave you "chroot" into a lxd container
<smoser> which meant no network namespace
<smoser> and mic would set up /etc/resolv.conf to work, and then it appeared that networkign was all golden
<blackboxsw> done testing chef on artful
<blackboxsw> and pushed an sru-info test for it
#cloud-init 2017-10-13
<redcavalier> blackboxsw, it looks like my issue is indeed a cloud-init bug. I do have some questions remaining though : 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]
<redcavalier> The explanation implies that vendordata is not fed in an appropriate format to cloud-init. I was wondering if there was a way I could change this, by forcing openstack to provide inconsequential vendor data, versus the empty data it currently gives.
<redcavalier> Additinally, I'Ve been wondering if this bug is really the cause of growpart not running.
<blackboxsw> redcavalier: do you see cc_growpart in your /var/log/cloud-init.log and also in /etc/cloud/cloud.cfg?
<blackboxsw> In ubuntu I see  - growpart
<blackboxsw>  - resizefs
<blackboxsw>  - disk_setup
<blackboxsw> in my /etc/cloud/cloud.cfg
<blackboxsw> those cloud-config module names would  need to be listed in the cloud_init_modules: section if they were to get run at all during cloud-init
<blackboxsw> and each module should be announced in /var/log/cloud-init.log if it is run (or ignored)
<blackboxsw> on my system: 2017-10-12 02:31:52,089 - handlers.py[DEBUG]: start: init-network/config-growpart: running config-growpart with frequency always
<blackboxsw> 2017-09-21 21:48:15,613 - stages.py[DEBUG]: Running module growpart ...
<redcavalier> blackboxsw, let me check quickly the last logs I made yesterday
<blackboxsw> anyway we've seen images that didn't have a couple of those disk related modules listed in /etc/cloud/cloud.cfg and that skipped some partition resizing.
<redcavalier> ah, it is listed
<redcavalier> It's a custom image we make ourselves
<redcavalier> and it used to work on previous versions of cloud-init
<blackboxsw> redcavalier: mind attaching your /etc/cloud/cloud.cfg to 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> just for reference
<redcavalier> sure
<blackboxsw> thanks a ton. yeah we looked at it today a bit and scott came up with the issue there which we need to address.
<blackboxsw> it's a bit late in the evening tonight but we'll be looking at fixing this
<redcavalier> yea, I'm just curious if that'S the no resize cause or just another issue
<blackboxsw> in the cloud-init.log you attached to the bug, I don't see any reference to cc_growpart in var/log/cloud-init.log it makes me think that module is not configured to run in that image for some reason
<blackboxsw> but I'll get some fresh eyes on it my tomorrow morn
<blackboxsw> have a good one
<redcavalier> Thanks, I'll probably drop by again tomorrow
<redcavalier> have a good night
<paulmey> What is the approximate release cadence for cloud-init nowadays?
<blackboxsw> paulmey: the goal is every 3 months.
<blackboxsw> just agreed to that cadence for >= 17.1
<blackboxsw> https://lists.launchpad.net/cloud-init/msg00106.html   explains the cadence and shows mid-sept release for 17.1, I'm expecting Xmas or New Year's for next release
<sedition> happy friday
<paulmey> Ah thanks blackboxsw, I now remember that email indeed. I must say I love holidays for releases... It's the best time to do live site support... ;-)
<blackboxsw> absolutely, I say release on Fridays and a day before long vacations so 3rd tier support really gets a workout ;)
<blackboxsw> and/or
<paulmey> :-) so yeah, happy Friday indeed
<blackboxsw> heh definitely :)
<blackboxsw> working toward an Ubuntu SRU release of 17.1 into xenial and zesty, but I think we'll miss this friday for our validation and publishing :(
<blackboxsw> tracking ubuntu 17.1 release progress here for those interested  https://trello.com/c/wROS4mKT/458-sru-171
<smoser> paulmey, well, the release will be near the holiday.
<smoser> it wont need to go to ubuntu (or any other distro) till after that
<smoser> probably we'd' expect it to be in 18.04 (the in-development development release) right away
<smoser> but not an aru
<smoser> sru
<paulmey> make sense
<blackboxsw> 6 bugs left to write SRU tests for
<blackboxsw> hrm, tried to forkbomb via runcmd. in hopes of systemd task limit would have held runcmd  to a sensible limit for forked tasks...
<blackboxsw> didn't work and bricked my lxc
<blackboxsw> I actually set DefaultTaskMax=20 in /etc/systemd/system.conf with the thought that it'd stop too many processes from being forked
<smoser> blackboxsw, link_up_and_dad
<smoser> bah
<smoser> https://gist.github.com/smoser/49444542158f2e5f88f1/#file-lxc-pstart-md
<blackboxsw> ummm
<smoser> thats what i got...
<smoser> "sort of works"
<smoser> so mount-image-callback lxd:foo
<smoser> now can be done with
<smoser>  lxc_pstart.py foo
<smoser>  lxc exec foo <command>
<smoser>  lxc stop foo
<smoser>   # and then edit out the 'pstart' profile from 'foo'
<blackboxsw> meh, forkbomb did work and systemd DefaultTaskMax=20 worked too
<blackboxsw> from cloud-init-output.log d: /var/lib/cloud/instance/scripts/runcmd: 2: /var/lib/cloud/instance/scripts/runcmd: Cannot fork
<smoser> hm..
<blackboxsw> I had forgotted to set DefaultTaskMax=20 in /etc/systemd/systemd.conf (and remove the TaskMax=Infinite in cloud-init.final.service
<blackboxsw> ok reading gist
<smoser> i got to run. it seems to basically work, but right now the profile gets left over on the containers config.
<smoser> see issues.
<blackboxsw> wow nice smoser
<blackboxsw> will test it a bit today
<blackboxsw> have a good one
<blackboxsw> smoser:think I'm running into lxc versionitis on xenial
<blackboxsw> I'm hitting some usage errors with your scripts. lemme paste before I look
<blackboxsw> http://pastebin.ubuntu.com/25734851/
<blackboxsw> ahh b'\nerror: unknown command: network\n'
<blackboxsw> ok will look it over (and will try on artful)
<blackboxsw> i  lxd                                         2.0.9-0ubuntu1~16.04.2                                   amd64        Container hypervisor based on LXC - daemon
<blackboxsw> ii  lxd-client                                  2.0.9-0ubuntu1~16.04.2
<blackboxsw> ii  liblxc1                                     2.0.7-0ubuntu1~16.04.2                                   amd64        Linux Containers userspace tools (library)
<blackboxsw> ii  lxc                                         2.0.7-0ubuntu1~16.04.2                                   all          Transitional package for lxc1
<blackboxsw> ii  lxc-common                                  2.0.7-0ubuntu1~16.04.2
#cloud-init 2017-10-14
<powersj> blackboxsw: may also consider running with lxc from ppa
<powersj> I know smoser and I both run artful, which will have latest and greatest, and base version in xenial probably isn't totally going to have everything
<powersj> ppa: https://launchpad.net/~ubuntu-lxc/+archive/ubuntu/stable?field.series_filter=xenial
<smoser> powersj, blackboxsw yeah, i figured i might need to address different lcx versions.
<redcavalier> blackboxsw, good evening. Were you able to have a look to the cloud.cfg I posted?
<blackboxsw> redcavalier:thanks for posting. hmm ok looks like you have resizefs as you mentioned. only difference I'm seeing from ubuntu related to disks  is you are missing a  disk_setup in your cloud config modules... but I don't think that alone would preclude you from resizing
<redcavalier> yea, it has always worked before the upgrade, with that cloud.cfg
<redcavalier> Hence why I think there's definitely a bug there and why I assumed it is related to the vendordata issue, but it could also be an error that'S not logged
<redcavalier> I mean, do you think the vendordata issue could prevent growpart from running?
<blackboxsw> redcavalier: I talked w/ smoser today about your bug, we're hoping to work out a fix for that in earnest  next week. At least the vendordata_raw will be sorted in 17.1+ shortly (and you'd be able to pull our daily builds from copr).
<redcavalier> Ah, then we'll see if that'S the cause or if there's something else
<blackboxsw> redcavalier: I don't believe that is really breaking the resize is the thing..... I just don't see that module even running on your attached cloud-init.log
<blackboxsw> that's what baffles me. I see other cloudinit modules running
<redcavalier> It's definitely running at least once though. Let me give you a small explanation regarding what we do.
<blackboxsw> maybe you could share some of your #cloud-config with us/me in pvt message ? I'll share with scott as we look this over on Monday. my email is chad.smith@canonical.com if there is stuff you want to keep semi-private. (or you could redact some of the content)
<redcavalier> We actually have a VM that's constantly running. To create (and update) our images, we make a snapshot of it's volume, convert it to image and then boot up on a new volume.
<redcavalier> Our latest image is still on the older cloud-init, so the VM does resize on first boot. I do believe that should at least be in the log. It's not though.
<redcavalier> We don't even erase the log from the previous VM when we create an image, so the file is already there when the VM boots.
<redcavalier> I don'T really get it.
<redcavalier> Anyhow, I'll send you a copy of our cloud-init by email, it'll give you a good idea.
<blackboxsw> on 17.1 you could run "cloud-init analyze show" on the commandline and it'd give a simple breakdown of what modules ran from your cloud-init.log files and how long it took. I'd also expect to see growpart and resizefs in that report
<blackboxsw> thanks for the additional context. it'll help us understand what might be happening
<redcavalier> ah, there might be a thing I forgot to say also
<redcavalier> The cloud-init daemon is crashed
<redcavalier> Like, the daemon doesn'T start
<redcavalier> again, the only error it gives in journalctl is that it can'T retrieve the vendordata, but I think there's something else
<blackboxsw> hrm. ok I'll poke at centos7 again tonight/this weekend just to make sure we can run. we test all the time in lxc w/ centos, but I'm not sure how frequent our coverage is on openstack
<redcavalier> Ok. All this makes me wonder if there's something wrong in our user data
<blackboxsw> it also might be worth a quick check of the pickled datasource object
<blackboxsw> redcavalier: something like this http://pastebin.ubuntu.com/25735734/
<blackboxsw> just find the pkl filename under /var/lib/cloud
<blackboxsw> then you can pkl load it and check userdata  userdata_raw vendordata vendordata_raw on your instance
<blackboxsw> make sue it has the content you expect
<redcavalier> Alright, I'll do that. Not right now because it'S Saturday morning here, but I'll have a look monday
<redcavalier> Just sent the email
<blackboxsw> thanks again. we'll be in touch
<blackboxsw> yeah, it's Friday night, gotta get some movie time in ;)
<blackboxsw> have a good weekend
<redcavalier> You too! see ya next week
#cloud-init 2019-10-07
<jgrasser>  /ignore JOINS PARTS QUITS
#cloud-init 2019-10-08
<AnhVoMSFT> do we have the status meeting blackboxsw rharper
<rharper> yes, we forgot to start it
<blackboxsw>  AnhVoMSFT correct you are. time just slipped away. starting it now
<blackboxsw> #startmeeting Cloud-init bi-weekly status
<meetingology> Meeting started Tue Oct  8 16:18:28 2019 UTC.  The chair is blackboxsw. Information about MeetBot at http://wiki.ubuntu.com/meetingology.
<meetingology> Available commands: action commands idea info link nick
<blackboxsw> Welcome back folks o/ And thanks AnhVoMSFT for the ping to get us started
<blackboxsw>  #chair rharper Odd_Bloke
<blackboxsw> #chair rharper Odd_Bloke
<meetingology> Current chairs: Odd_Bloke blackboxsw rharper
<blackboxsw> cloud-init upstream uses this meeting as a platform for community updates, feature/bug discussions, and an opportunity to get some extra input on current development.
<Odd_Bloke> o/
<Odd_Bloke> Thanks for the reminder, Anh.
<blackboxsw> Feel free to interject at any time. Our typical format is the following: Previous Actions, Recent Changes, In-progress Development, Office Hours (~30 mins).
<blackboxsw> For this, and subsequent, status meetings I proposed we add a new topic: Ongoing Community Charter  which would give context on the new trello lane we added at the cloud-init summit.
<blackboxsw> Odd_Bloke: rharper AnhVoMSFT does that sound good? We can then better advertise and remind about long-term community involvement projects that are available for anyone
<AnhVoMSFT> I would propose that the last agenda item of any status meeting would be to update the banner to reflect the next status meeting - and perhaps the next ETA for next release / SRU
<blackboxsw> +1 AnhVoMSFT that sounds good too.
<AnhVoMSFT> yep, sounds good on the Community Charter
<rharper> AnhVoMSFT: +1
<rharper> I think one topic each
<rharper> and end with the next status meeting
<blackboxsw> ok starting to turn the meeting crank
<blackboxsw> #topic Previous Actions
<blackboxsw> last meeting was 09/09/2019
<blackboxsw> #link https://cloud-init.github.io/status-2019-09-09.html#status-2019-09-09
<blackboxsw> meeting minutes at the link above ^
<blackboxsw> only action was  #action blackboxsw send email to the list notifying of status meeting day change.
<blackboxsw> which was done https://lists.launchpad.net/cloud-init/msg00224.html
<blackboxsw> no further outstanding actions from last meeting
<blackboxsw> #topic Recent Changes
<blackboxsw>  The following branches have landed in tip since last meeting: via git log --since 2019-09-09
<blackboxsw>     - Add RbxCloud datasource [Adam Dobrawy]
<blackboxsw>     - get_interfaces: don't exclude bridge and bond members (LP: #1846535)
<blackboxsw>     - Add support for Arch Linux in render-cloudcfg [Conrad Hoffmann]
<blackboxsw>     - util: json.dumps on python 2.7 will handle UnicodeDecodeError on binary
<blackboxsw>       (LP: #1801364)
<ubot5> Launchpad bug 1846535 in cloud-init "cloud-init 19.2.36 fails with python exception "Not all expected physical devices present ..." during bionic image deployment from MAAS" [Critical,Fix committed] https://launchpad.net/bugs/1846535
<ubot5> Launchpad bug 1801364 in cloud-init "persisting OpenStack metadata fails" [Undecided,Fix committed] https://launchpad.net/bugs/1801364
<blackboxsw> oopsie daisy
<AnhVoMSFT> :)
<blackboxsw> got kicked on flood. chunking that now
<blackboxsw>     - Add RbxCloud datasource [Adam Dobrawy]
<blackboxsw>     - get_interfaces: don't exclude bridge and bond members (LP: #1846535)
<blackboxsw>     - Add support for Arch Linux in render-cloudcfg [Conrad Hoffmann]
<blackboxsw>     - util: json.dumps on python 2.7 will handle UnicodeDecodeError on binary
<blackboxsw>       (LP: #1801364)
<blackboxsw>     - debian/ubuntu: add missing word to netplan/ENI header (LP: #1845669)
<blackboxsw>     - ovf: do not generate random instance-id for IMC customization path
<ubot5> Launchpad bug 1845669 in cloud-init "The meaning of "Changes to it will not persist across an instance." in 50-cloud-init.yaml is unclear" [Undecided,Fix committed] https://launchpad.net/bugs/1845669
<blackboxsw>     - sysconfig: only write resolv.conf if network_state has DNS values
<blackboxsw>       (LP: #1843634)
<blackboxsw>     - sysconfig: use distro variant to check if available (LP: #1843584)
<blackboxsw>     - systemd/cloud-init.service.tmpl: start after wicked.service
<ubot5> Launchpad bug 1843634 in cloud-init (Suse) "cloud-init misconfigure the network on SLES" [Undecided,Incomplete] https://launchpad.net/bugs/1843634
<blackboxsw>       [Robert Schweikert]
<blackboxsw>     - docs: fix zstack documentation lints
<ubot5> Launchpad bug 1843584 in cloud-init "cloudinit/net/sysconfig.py lacks support for openSUSE 15.x and Tumbleweed" [Medium,Fix committed] https://launchpad.net/bugs/1843584
<blackboxsw>     - analyze/show: remove trailing space in output
<blackboxsw>     - Add missing space in warning: "not avalid seed" [Brian Candler]
<blackboxsw>     - pylintrc: add 'enter_context' to generated-members list
<blackboxsw>     - Add datasource for ZStack platform. [Shixin Ruan] (LP: #1841181)
<blackboxsw>     - docs: organize TOC and update summary of project [Joshua Powers]
<blackboxsw>     - tools: make clean now cleans the dev directory, not the system
<blackboxsw>     - docs: create cli specific page [Joshua Powers]
<ubot5> Launchpad bug 1841181 in cloud-init "add datasource for ZStack" [Low,Fix committed] https://launchpad.net/bugs/1841181
<blackboxsw>     - docs: added output examples to analyze.rst [Joshua Powers]
<blackboxsw>     - docs: doc8 fixes for instancedata page [Joshua Powers]
<blackboxsw>     - docs: clean up formatting, organize boot page [Joshua Powers]
<blackboxsw>     - net: add is_master check for filtering device list (LP: #1844191)
<ubot5> Launchpad bug 1844191 in cloud-init "azure advanced networking sometimes triggers duplicate mac detection" [Critical,Fix committed] https://launchpad.net/bugs/1844191
<blackboxsw>     - docs: more complete list of availability [Joshua Powers]
<blackboxsw>     - docs: start FAQ page [Joshua Powers]
<blackboxsw>     - docs: cleanup output & order of datasource page [Joshua Powers]
<blackboxsw>     - Brightbox: restrict detection to require full domain match .brightbox.com
<blackboxsw>     - VMWware: add option into VMTools config to enable/disable custom script.
<blackboxsw>       [Xiaofeng Wang]
<blackboxsw>     - net,Oracle: Add support for netfailover detection
<blackboxsw>     - atomic_helper: add DEBUG logging to write_file (LP: #1843276)
<ubot5> Launchpad bug 1843276 in cloud-init "cloudinit.atomic_helper.write_file should have the same logging as util.write_file" [Low,Fix committed] https://launchpad.net/bugs/1843276
<blackboxsw> Thanks Brian, Shixin Ruan, Conrad Hoffmann, Adam Dobrawy and robjo for the contributions over the last month!
<blackboxsw> beyond tip commits to cloud-init the upstream team went through two SRUs of cloud-init
<blackboxsw> it's also excellent to see new datasources like the  RbxCloud datasource added
<blackboxsw> cloud-init just passed validation for Ubuntu Xenial, Bionic and Disco on the 2nd SRU 19.2-36-g059d049c-0ubuntu2
<blackboxsw> cloud-images today should have that updated revision in them I blieve
<blackboxsw> there are fixes for both Azure accelerated networking support and handling issues seen on MAAS network bridge configuration
<AnhVoMSFT> on that note the last Azure image we had published was early September, which still didn't have the first SRU
<AnhVoMSFT> is there something going on with the image publishing pipeline again?
<blackboxsw> AnhVoMSFT: the publishing pipeline paused while we sorted the 2nd SRU pass for maas network bridge issues introduced by 19.2-36-g059d049c-0ubuntu1
<AnhVoMSFT> i see - that makes sense
<blackboxsw>  19.2-36-g059d049c-0ubuntu2 was verified as fixing all support there for both Azure and MAAS datasources and the expectation is that image builds are continuing today but I'll verify that the box is â there on images rebuilding
<Odd_Bloke> There may also be Azure-specific publication pipeline issues, which we wouldn't necessarily know about off-hand.
<blackboxsw> #action blackboxsw verify cpc image builds are unpaused/unblocked for Azure
<meetingology> ACTION: blackboxsw verify cpc image builds are unpaused/unblocked for Azure
<blackboxsw> thx Odd_Bloke right
<blackboxsw> looks like Odd_Bloke is already on that verification internally
<blackboxsw> ok so SRU is through verification on our side. cloudimages should be getting latest version of cloud-init for Xenial, Bionic and Disco imminently
<blackboxsw> I think that is *it* for Recent Changes
<blackboxsw> #topic In-progress Development
<blackboxsw> the SRU verification work took a bit of steam out of our current work in progress as it involved a lot of manual and upgrade scenario tests.
<blackboxsw> But, as always we try to track ongoing work in trello
<blackboxsw> #link https://trello.com/b/hFtWKUn3/daily-cloud-init-curtin
<blackboxsw> there are a number of branches in progress that are of interest:
<blackboxsw> Azure CI for one would be a great add for cloud-init's CI infrastructure
<blackboxsw> https://code.launchpad.net/~ahosmanmsft/cloud-init/+git/cloud-init/+merge/372957
<blackboxsw> we need to get eyes on that this week if we can
<blackboxsw> #action cloud-init upstream review https://code.launchpad.net/~ahosmanmsft/cloud-init/+git/cloud-init/+merge/372957
<meetingology> ACTION: cloud-init upstream review https://code.launchpad.net/~ahosmanmsft/cloud-init/+git/cloud-init/+merge/372957
<ahosmanmsft> That would be great
<blackboxsw> there are also a number of freebsd branches that need to close out.
<blackboxsw> and I know Odd_Bloke has started peeking at some initial github integration for CI.
<blackboxsw> Odd_Bloke: any details you want to add about github CI at the moment?
<Odd_Bloke> I've started iterating on a Travis configuration to run what we currently run in our CI pipeline.
<Odd_Bloke> Unsurprisingly, setting up linting/unit testing was easy.
<Odd_Bloke> The other thing we do is run some integration testing from a built deb file.  I got as far as being able to successfully sbuild the package in Travis, and ran into some initial stumbling blocks with running lxd.
<Odd_Bloke> That's as far as I've got, I expect to pick that work back up this week.
<blackboxsw> thanks Odd_Bloke , I've added the following card to trello for those interested.
<blackboxsw> #link https://trello.com/c/pqA1adVM/1195-investigate-adding-github-travis-ci-to-cloud-init
<blackboxsw> I think that about wraps in progress work. We'll tackle reviews a bit at the end of the meeting
<blackboxsw> ok next topic
<blackboxsw> #topic Community Charter
<blackboxsw> at the cloud-init summit we decided to highlight community work in trello so that any community member with some dev cycles and interest can join in and contribute to ongoing tasks
<blackboxsw> that lane is now in trello representing low-hanging-fruit content that upstream cloud-init is interested in completing, and that anyone can commit to.
<blackboxsw> #link https://trello.com/b/hFtWKUn3/daily-cloud-init-curtin
<blackboxsw> the lane is labelled "Community low-hanging-fruit" and currently contains a number of doc update work items  as well as json schema validation extensions for each cloud-init config module
<blackboxsw> we invite everyone to participate and feel free to grab those items as they have interest
<blackboxsw> we'll revisit this topic in each meeting so folks have context
<blackboxsw> #topic Upcoming meetings and releases
<blackboxsw> cloud-init upstream has just passed validation of cloud-init 19.2.36-*-ubuntu2  which should approved for upload into Xenial, Disco and Bionic (and queued for Eoan)
<blackboxsw> the cloud build team will be generating images for various clouds imminently and we will confirm that build pipelines are active so platforms get new bits asap
<blackboxsw> 19.3 upstream should by coming shortly, we will update the topic with the expected upstream release date and send an  email to the mailing list with the estimated upstream cut
<blackboxsw> #action upstream cloud-init email about 19.3 release date
<meetingology> ACTION: upstream cloud-init email about 19.3 release date
<blackboxsw> next meeting is Oct 22
<blackboxsw> same bat time same bat channel
* blackboxsw changed the topic of #cloud-init to: Reviews: http://bit.ly/ci-reviews | Meeting minutes: https://goo.gl/mrHdaj | Next status meeting Oct 22 16:15 UTC | cloud-init v 19.2 (07/17) | cloud-init 19.3 TBD | https://bugs.launchpad.net/cloud-init/+filebug
<blackboxsw> #topic Office Hours (next ~30 mins)
<blackboxsw> we spend this time for reviews, bug triage and cloud-init discussions.
<blackboxsw> upstream devs should have eyes on this channel. Thanks everyone for tuning in
<AnhVoMSFT> have you had a chance to discuss about the python deprecation issue, or did the SRU verification take most of the time since the summit
<blackboxsw> AnhVoMSFT: last week was vacation plus the remainder of us on sru verification  .
<blackboxsw> But now we have cleared that hurdle we should we able to discuss it this week.
<AnhVoMSFT> yep, sounds good.
<blackboxsw> #action revisit python deprecation and report to mailinglist
<meetingology> ACTION: revisit python deprecation and report to mailinglist
<blackboxsw> Good meeting for actions
<blackboxsw> Thanks for the participation folks I'll publish minutes to github
<blackboxsw> #endmeeting
<meetingology> Meeting ended Tue Oct  8 17:54:37 2019 UTC.
<meetingology> Minutes:        http://ubottu.com/meetingology/logs/cloud-init/2019/cloud-init.2019-10-08-16.18.moin.txt
