[00:09] <sedition> huh. for some reason the user declarations that work for cent dont work on amazon linux. 'failed to create user'
[01:16] <smoser> sedition: /var/log/cloud-init-output.log and /var/log/cloud-init.log probably have more info.
[01:16] <sedition> its getting far enough in the process for the ec2-user account to be gone
[01:17] <smoser> mgerdts: you still there?
[01:18] <smoser> hm.. sedition well, if you have other access then go in that way. other wise, i think youprobalby need to just make a image that you have another into, or detach the ebs volume and re-attach
[01:18] <smoser> :-( sorry thats a pain.
[01:19] <mgerdts> smoser here now
[01:20] <smoser> mgerdts: so what i recommend for you to do for trusty is to use 'git ubuntu'
[01:20] <smoser> you can use 'snap install git-ubuntu'
[01:20] <sedition> smoser: its all good
[01:20] <smoser> or skip that and just use git without the porcelin that it provides
[01:20] <sedition> im just debugging
[01:20] <sedition> i wanna know why the same rendered template craps out on amazon linux but works on cent7 when its just adding users
[01:20] <smoser> git clone -o pkg https://git.launchpad.net/~usd-import-team/ubuntu/+source/cloud-init ubuntu
[01:21] <smoser> cd ubuntu
[01:21] <sedition> and installing vim
[01:21] <sedition> lol
[01:21] <mgerdts> do that on trusty, xenial, bionic, or something else?
[01:21] <smoser> mgerdts: so... focus on what you have there. you'll see branches for 'pkg/ubuntu/trusty-devel'
[01:21] <smoser> that is what you want to base yourself off of.
[01:22] <smoser> when you make chnages in this way you have to actually put your changes into debian/patches/some-patch.diff
[01:24] <smoser> mgerdts: i'm wrtining some more ... hopefully will get you ont he right step.
[01:25] <mgerdts> ok, thanks.
[01:26] <mgerdts> I'm involved in a couple other conversations at the moment and won't pick this up until the morning.
[01:28] <smoser> https://hackmd.io/7K5bl1lwSoOCY7A3uu7bnQ
[01:28] <smoser> mgerdts: going there.
[01:44] <smoser> mgerdts: i'm goign afk. feel free to ping tomorrow.
[01:44] <mgerdts> thanks
[08:33] <mdt[m]> hi, i need some help how to investigate a problem. cloud-init does not work in an image i provided (debian) while another image (centos) works fine in the same environment. where can i start to dig? i found the logs and the only warning message is "Used fallback datasource" but no hint why.
[13:26] <smoser> mdt[m]: there is probably something else, another WARN in /var/log/cloud-init-output.log
[13:26] <smoser> and running cloud-init collect-logs is a start to collect what we would need
[13:42] <smoser> philroche: that image has been booted before
[13:58] <smoser> philroche: ping when you get a chance.
[13:58] <smoser> i *think* what happened is that the first boot did not for some reason run cloud-init.service . only cloud-init-local.service run.
[14:01] <smoser> we dont seem to have a journal from that failed run
[14:02] <smoser> if we did i suspect it contains the words 'ordering cycle' and 'Breaking'
[14:05] <smoser> we have a journal from the second run, and the second run seems happy
[14:38] <philroche> smoser: I will mount the failed launch to get some more logs for you. I should probably create a bug for this
[14:42] <smoser> philroche: i mounted the failed launch. there is no journal there. only the second boot you did.
[14:44] <philroche> smoser: My bad. I meant to upload the clean image. I have done so now https://private-fileshare.canonical.com/~philroche/cosmic-dailies/20180530/
[15:24] <mgerdts> smoser - the backport of my fixes to trusty is a bit of a mess because there's been a lot of change.  How distasteful would it be to backport at least '0b3e3f8 initial commit of rework' and perhaps all/most of these: https://hastebin.com/ivotoyirac.sql ?
[15:31] <smoser> wow.
[15:31] <smoser> hm..
[15:32] <smoser> mgerdts: well, i'm fine with ou basically just having one patch that replaces the old file in SmartOS with what you want
[15:32] <smoser> "sync-smartos-to-upstream.patch"
[15:32] <mgerdts> I like the way you think.
[15:32] <smoser> i like that you use hastebin :)
[15:33] <smoser> and you just lucked in to .sql extension :)
[15:35] <mgerdts> Are all of the interfaces it uses/exposes likely to be compatible?
[15:36] <mgerdts> I avoided later changes that touched DataSourceSmartOS and other files because of feared incompatibility
[15:40] <smoser> mgerdts... much of it the same... i do expect there are some significant differences though.
[15:40] <sedition> anyone happen to know what's so custom about cloud-init for Amazon Linux?
[15:41] <smoser> sedition: youc an get their source... i'mmve not compared them in some time. they do have some patches and fixes, but i believe they are largely getting those things upstream.
[15:42] <sedition> so odd
[15:42] <sedition> i still cant figure out why user declarations wont work
[18:16] <hatifnatt> Is there any place where meta-data format is described? I can't find any good documentation anywhere.
[18:19] <hatifnatt> What difference between OpenStack metadata and EC2 metadata? AWS have at least some docs about metadata https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-metadata.html but can't find nothing helpful about OpenStack metadata.
[19:26] <smoser> hatifnatt: https://docs.openstack.org/nova/latest/user/metadata-service.html
[19:51] <hatifnatt> smoser: Thanks I have read this already, but that is not a reference, it's very superficial description of meta data service. I mean something like table with a detailed description like in EC2 docs https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-metadata.html#instancedata-data-categories
[19:54] <hatifnatt> For example I have line in configdrive meta-data file '"network_config": { "content_path": "/content/0000" }' where except source code I can find reference what does this mean?
[19:57] <smoser> hatifnatt: well, what it means is that at the entry point of the metadata service
[19:57] <smoser> under /content/0000 is the content of the network config.
[19:58] <smoser> its basically a blob store location and reference to that.
[20:15] <hatifnatt> smoser: so any parameter can be stored separately and referenced by 'content_path' or it's specila for network_config? As I can tell by source code https://github.com/cloud-init/cloud-init/blob/master/cloudinit/sources/helpers/openstack.py#L298 "network_config" is special one.
[20:15] <smoser> hatifnatt: well, its not special to that.
[20:15] <smoser> other things can too
[20:16] <smoser> the reason is config drive.
[20:16] <smoser> they duplicate the versioned/ data on the disk
[20:16] <smoser> and they did not want to duplicate all the things that were the same
[20:16] <smoser> and no symlinks or such in standard iso9660
[20:16] <smoser> or vfat