#cloud-init 2014-06-02 <smoser> harlowja_, https://bugs.launchpad.net/cloud-init/+bug/1315501 is fun. <harlowja_> damn, u guys changed to interfaces.d <harlowja_> didn't know that existed (interfaces.d) <smoser> yeah, its nice. but not so nice. all at the same time. <harlowja_> :) <harlowja_> smoser so that shouldn't be to hard to fix though, depending how u want to do this <smoser> so i think the right thinkg to do is: <smoser> * read all interfaces.d files (in order expected). <harlowja_> did the format for those files change? <smoser> * identify each interface and the file it was originally found in <smoser> * update the file that it was found in. <smoser> alternatively, we could put a cloud-init file down that just was last in the order (and truped the others) <smoser> the format didn't really change, the cloud iamge build process jsut started taking advantate fo the fact that /etc/network/interefaces can now do "#include interfaces.d" or whatever hte syntax is thre. <harlowja_> ah <harlowja_> u can probably then use my handy-dandy parser i suppose <harlowja_> http://bazaar.launchpad.net/~cloud-init-dev/cloud-init/trunk/view/head:/cloudinit/distros/net_util.py <harlowja_> and then scan all files, identify ones that u want to write, and as u said rewrite ones that match <harlowja_> *and leave the old way of doing this for pre-trusty? <smoser> well, ideally, the new way would still work. <smoser> right? <smoser> because /etc/network/interfaces would not contain the 'source-directory interfaces.d' <smoser> or if it did, we'd still order the stuff all correctly and know where to replace. <smoser> i really dont know the best way to do it. between "update-the-right-stanza" (if there is even 1 stanza, they may be additive). and "write a 99_cloud-init" config file that just trumps at the end. <harlowja_> ya, damn them for making this so complex :-P #cloud-init 2014-06-05 <Wulf> Hello <Wulf> Where can I get a complete list of things a cloud-init installation will do? <smoser> Wulf, not a good list, no. <Wulf> maybe I can start with a not-so-good list <harmw> Wulf: http://cloudinit.readthedocs.org/en/latest/ <smoser> so many improvements to cloud-init to do. <harmw> yea yea, and so damn little time <harmw> I know the drill :> <harmw> sounds like the stuff I keep telling people at work everyday aswell <harlowja> anyone can help make http://cloudinit.readthedocs.org/en/latest/ better btw <harlowja> http://bazaar.launchpad.net/~cloud-init-dev/cloud-init/trunk/files/head:/doc/rtd/ <harlowja> ^ this is where the above site comes from #cloud-init 2014-06-06 <smoser> harmw, powerpc cirros almost woring <smoser> http://paste.ubuntu.com/7598223/ <harlowja> i can finally run my G3 powermac <harlowja> woot <Wulf> Hello again.. <Wulf> I'm trying to add an ssh public key to my user but the ~/.ssh directory is never created <Wulf> http://codepad.org/76MkwitT is the config. The user is created, "passdwd -l" is run, sudoers entry is created <Wulf> any help with that one please? <Wulf> never mind, found the problem and wrote a bug report <harmw> smoser: nice! <harmw> its sad I've not had a chance to hook my cubietruck ARM device into openstack, for testing the allmighty cirros <JoeHazzers> how do i know in what order modules are run? <smoser> Wulf, bug link ? <smoser> JoeHazzers, its by the config <smoser> see /etc/cloud.d/cloud.cfg . <smoser> cloud_init_modules runs "as early as possible" (not guaranteed network access) <smoser> cloud_config_modules runs "as soon as network is up" <smoser> cloud_final_modules runs "rc.local time frame" <ddosia> hello everybody <ddosia> could someone tell me, is it possible to use #include and #cloud-config instructions in the same time? <smoser> ddosia, multipart input <smoser> or just <smoser> #include <smoser> http://my.cloud.config.url <smoser> http://some.other.thing <smoser> you can do multipart input in one of 2 ways: <smoser> a.) cloud-config-archive <smoser> b.) mime-multipart <ddosia> smoser: thanks #cloud-init 2014-06-07 <Wulf> smoser: https://bugs.launchpad.net/cloud-init/+bug/1327065 #cloud-init 2014-06-08 <redhot1> hi <redhot1> I've got some simple question <redhot1> I want to read variable in cloud-init config <redhot1> http://pastebin.com/racmcWwC <redhot1> I want pass the value of 'hostname' and 'public-ipv4' (from meta-data) into shell script <redhot1> is it possible to do? <redhot1> i've seen page http://coreos.com/docs/cluster-management/setup/cloudinit-cloud-config/ where guys use syntax likeaddr: $public_ipv4:4001 <redhot1> in my cause it doesn't work, it just pass string "$public_ipv4" <redhot1> can someone help me? :) #cloud-init 2014-06-09 <smoser> Wulf, it looks to me that it needs to be 'ssh_authorized_keys' <smoser> underscore, not - <smoser> ah. actually, i tlooks like either 'ssh-authorized-keys' or 'ssh_authorized_keys' will work. <smoser> as _normalize_users changes '-' to '_' #cloud-init 2014-06-10 <Wulf> smoser: is it supposed to be fixed on http://bazaar.launchpad.net/~cloud-init-dev/cloud-init/trunk/view/head:/doc/examples/cloud-config-user-groups.txt ? Cause it's not. <Wulf> ah, I'll just update the bug tracker <smoser> Wulf, i'm confuse.d <smoser> the diff you showed and my reading of the code shows that the correct alue is 'ssh-authorized-keys' <smoser> which is what is shown in tha tlink <Wulf> oh, you're there. Just updated the ticket <Wulf> smoser: yes, it's correct with the trailing "s" and in that link the "s" is missing <smoser> ah. line 72 its missing. its present on line 26 <smoser> so we're both right <smoser> :) <Wulf> (: <smoser> i'll fix that and push it right now. <smoser> thanks for patience <Wulf> thanks <harmw> smoser: how nice, the logo's even on the cirros page :) <smoser> :) <smoser> did you aever test the arm stuff ? <smoser> i got cirros all building on trusty and with the latest buildroot <smoser> but then my instance ot killed <smoser> :) <harmw> hah, no, -still- did't setup my cubietruck <smoser> so i lost that data. <harmw> ohmy <harmw> smoser: you're not giving away time for free, right? <harmw> I badly need more then just 24 hrs in a day :p <smoser> i understand that. <harmw> does ubuntu have something like armel64? <harmw> I'm seeing this in my buildscript: [ "$TARGETARCH" = "arm" ] && xarch="armel" && flav="omap" <harmw> and I'm wondering how easy it may or may not be to have it build arm64 stuff <harmw> hm, lets see if the scripts builds arm in the first place :) <smoser> arm definitely builds <smoser> arm64 migh tneed an update of buildroot <smoser> but i'm pretty sure i had it building <smoser> and ubuntu does have arm64 kernels <harmw> ok, well I'm already building with an updated buildroot <harmw> and such <smoser> feel free to merge propose updated buildroot stuff. <harmw> didn't I already propose such a merge a long time ago? :) <harmw> Ill look into that tonight <smoser> did you? <smoser> its quite possible <smoser> sometimes, i'm a bigger idiot than normal <harmw> https://code.launchpad.net/~harmw/cirros/cirros-buildroot-2014.02 thats the one, though I can't remember why I actually did not request a merge jus tyet <harmw> and I've started https://code.launchpad.net/~harmw/cirros/various-fixes, though with just one fix yet :) <smoser> harmw, thank you <harmw> think you can use it? <smoser> (haven't looked yet :) <pquerna> smoser: http://cloudinit.readthedocs.org/en/latest/topics/dir_layout.html what do you think about adding /var/lib/cloud/data/availability-zone or would you want it approached another way? <pquerna> (rather than... import pickle;pickle.loads(open('/var/lib/cloud/instance/obj.pkl').read()).availability_zone :D #cloud-init 2014-06-11 <smoser> pquerna, i want to solve the problem you are wanting to solve. <smoser> but the goal i think is to end up with 2 somewhat-commonly formed files with metadata information. <smoser> one would contain any thing that potentially was sensitive (ie, user-data) and one non-sensitive. <smoser> and their on-disk permissions represent that difference. <smoser> and then 'cloud-init query' would basically load those up and spit out answers, but you could just as easily load the json directly from /var/lib/cloud/instance/data.json <smoser> which i guess would ideally be in /run. #cloud-init 2014-06-12 <jmickle> hi all <jmickle> if anyone is around i have 2 questions probably config related that i have been racking my brain on <jmickle> if someone could assist it would be greatly appreciated <smoser> jmickle, whats up ? <smoser> in general, "don't ask to ask, just ask" <smoser> if someone sees your question and knows how to reply they will. <jmickle> hey smoser first thanks for responding and sure thing i didnt know how it worked in here so i didnt want to be rude <jmickle> smoser: I am running cloud-init on centos with openstack and when it runs it does not seem to be adding the user to sudo <jmickle> also growpart does not seem to be running although when i run growpart manually after logging in and rebooting it works <smoser> on an older kernel to make it all "just work", you'll need a drakut module cloud-initramfs-growroot <smoser> on 3.8 and later, cloud-init can do it all on mounted filesystems. <smoser> i think though that reboot would probably get you what you needed. <jmickle> interesting ok <jmickle> what about sudo ? it seems to be running the add ssh key <jmickle> but not adding the sudo line for the user <jmickle> though i did turn off the disable root login <smoser> can you paste cloud-init config ? /etc/cloud/cloud.cfg and anything in /etc/cloud/cloud.cfg.d/* <jmickle> the only thing i changed was disable root: 1 to 0 <smoser> root login should be disabled by default. <smoser> oh. i see. <jmickle> yeah i turned it off temporarily because i had a networkign issue at first <jmickle> and keys werent getting added <jmickle> so i needed to login with the root <jmickle> could that be why? <smoser> nah. it should still do it. <smoser> what cloud-init version ? <jmickle> 0.7.4 <smoser> - RH: require sudo >= 1.7.2p2-3 (with sudoers.d/) <smoser> htats just to verifiy that its not writing the file but sudo not caring <jmickle> im sorry i lost you <jmickle> you mean use cloud-init >= 1.7.2? <smoser> sudo <smoser> rpm -qi sudo <jmickle> ah <jmickle> 1.8.6p3 <smoser> k. that would seem san.e <smoser> http://paste.ubuntu.com/7634815/ <smoser> so your config has to have a 'sudo' line for the user <smoser> (default_user) <jmickle> got it which the default config from epel does not <jmickle> ok <smoser> and also see the new style <smoser> users: <smoser> - default <smoser> rather than <smoser> user: <foo> <jmickle> ok <jmickle> thank you so much <jmickle> il try the reboot with the grow part <jmickle> maybe it is running and just needs a reboot to kick in or something <smoser> if you run growpart on kernel < 3.8 <smoser> you have to reboot <jmickle> ok yeah centos 6.5 is 2.6 <jmickle> ty so much <smoser> the fix is to add that dracut module <smoser> and then it resizes in the initramfs <smoser> when the filesystem is not mounted <jmickle> ok do you have an example of that or documentation for it by chance? <smoser> (older kernels will not allow updates to partition tables of "physical disks" that have filesystems mounted on them) <jmickle> or is it in that config? <jmickle> ok <smoser> http://docs.openstack.org/image-guide/content/ch_openstack_images.html <smoser> https://apps.fedoraproject.org/packages/cloud-initramfs-tools/changelog <jmickle> ty <jmickle> is there a way to pass the hostname into the node-name variable in cloud init config for chef? #cloud-init 2014-06-13 <xmltok_> hi, does anyone know why the short hostname is perferred when setting the hostname on debian boxes? <smoser> harlowja_away, what was that library for network config and description <harlowja> smoser https://fedorahosted.org/netcf/ <harlowja> netcf <smoser> thank you <harlowja> np <harlowja> smoser still seems somewhat active (as a project), so thats good <harlowja> https://git.fedorahosted.org/git/netcf.git #cloud-init 2014-06-18 <anotheral> is this the canonical channel for cloud-init? <utlemming> anotheral: yup <anotheral> i was just wondering if there's any documentation of the order of operations that happens in a cloud-config yaml? <anotheral> i have some stuff that needs to happen before some other stuff :) <utlemming> anotheral: /etc/cloud.cfg controls what happens when <anotheral> beautiful <anotheral> ta <utlemming> anotheral: if you want to change that in user-data, you can do that too <utlemming> anotheral: i.e. put #cloud-config into user-data <anotheral> so the order of items in that cloud.cfg file is the order of execution? <anotheral> not the order in my yaml <utlemming> anotheral: yes <anotheral> ah, looks like write_files isn't even in 12.04 cloud-init <utlemming> anotheral: if you want to change that on boot, then define cloud_init_modules or cloud_config_modules in your #cloud-config user-data <anotheral> oh interesting - that's good to know! <anotheral> thanks folk! LOOOOVE your product <harlowja> yw! <anotheral> if you don't mind, i do have one more question <anotheral> i'm trying to create some files, but ubuntu 12.04 doesn't have the write_file capability <anotheral> is there a decent workaround anyone is aware of? <harlowja> anotheral send in a bash script that writes out the files <harlowja> using bash syntax <anotheral> ah right #cloud-init 2014-06-19 <harmw> ah, with facebook offline I can finally start doing something :> <harmw> oh, no, wait, I don't have FB <smoser> harmw, :) <smoser> i read that first line and was embarrased for you :) <smoser> nice save though. <harmw> haha <harmw> its true, btw <smoser> i do have a facebook account. but i spend less than 5 minutes per month. <harmw> smoser: you happen to know a hosting company that offers /48 ipv6 ranges? perhaps even free like he.net or sixxs.net? <smoser> no. i dont really have much hosting company experience. <smoser> i use dreamhost. <smoser> is my only relationship with one <harmw> hm hm ok <kwadronaut> harmw: can't you sign up with ripe or similar? <kwadronaut> i've got a /64 for ipv6 at 1 hosting company, and I believe that's what's custom/recommended (hetzner, ovh, bytemark and a bunch of others do this standard for each box) <kwadronaut> i know bytemark gives a /48 on simple request, don't know if they're any good <harmw> kwadronaut: this is just for at home :) <harmw> but bytemark, lets see if there close enough to even consider :) <kwadronaut> ripe doesn't mind, if they were to send me postcards, they'd get to my home with it's crappy dsl on the countrysideâ¦ <harmw> ok, ripe doesn't mind - but my wallet does :) #cloud-init 2014-06-20 <CatKiller> Hi there! I've got a small issue with cloud-init on Ubuntu 14.04 desktop edition <CatKiller> I've successfully installed it, but it seems that "dpkg-reconfigure cloud-init" fails with an error <CatKiller> When ran, it opens the curses menu correctly, I can for instance pick another source <CatKiller> but when I save, I get a few errors and the values of datasource_list remain unchangfed <CatKiller> Here's a paste of the errors <CatKiller> http://bpaste.net/show/nH2m5x3oKxGYP8cmrmBs/ <CatKiller> dpkg-reconfigure returns "0" on exit though <CatKiller> Also the strange thing is that if I look in reconfigure, only the OpenStack datasource is selected. <CatKiller> But if I look into /etc/cloud/cloud.cfg.d/90_dpkg.cfg only CloudStack appears on the datasource_list <smoser> CatKiller, bug 1325746 <CatKiller> smoser: Thanks! <smoser> i'm gonna upload that to proposed today <smoser> but it will be at least 7 days till its in trusty-proposed <CatKiller> Well I can probably compile and install cloud-init from source otherwise <CatKiller> purge the apt installed package <CatKiller> and just get the very latest <CatKiller> Also another question <CatKiller> I then changed /etc/cloud/cloud.cfg.d/90_dpkg.cfg "by hand" to include OpenStack and Ec2 <CatKiller> However when I run "cloud-init init" it doesn't seem to try to connect to the metadata server <smoser> you can. but whenver dpkg-reconfigure cloud-init runs it screws it. <smoser> you probably have to run 'cloud-init init --local' first <CatKiller> Could that be that dpkg-reconfigure does more than just setting the metadata sources? <smoser> as that will remove some state <CatKiller> smoser: I'll try that too, thanks <CatKiller> smoser: omg it worked. Thanks a lot. Not sure what that did though ;) <smoser> CatKiller, sudo rm -f /var/lib/cloud/instance <smoser> is about it really. <smoser> since it had all ran before it found the 'None' data source. so running it again just said "already found". <CatKiller> ahhhh ok <CatKiller> smoser: I get it, I was wondering what all this data was about <CatKiller> smoser: So basically, in the base image that directoy <CatKiller> *directory should be empty <smoser> well, its a symlink <smoser> so it doesn't really matter. <smoser> when it finds a datasource, it links that tot he current data. <smoser> and other data is otherwise ignroed <CatKiller> smoser: OK cool, that makes a bit of sense <CatKiller> smoser: On a clean image, should I delete the entire contents of /var/lib/cloud then? <CatKiller> I've noticed that this directory only gets populated the first time cloud-init runs <CatKiller> So that I can leave cloud-init pick the "right" data source on boot? <smoser> you can. <smoser> you dont need to <smoser> but you can <smoser> on boot, cloud-init --local gets run <smoser> so it will always pick the right datasource #cloud-init 2014-06-23 <harmw> smoser: I've got my cubietruck up&running with fedora rawhide <harmw> it (kernel+uboot) supports kvm/qemu now, so I should be able to launch cirros pretty easily <harmw> though not backed by openstack, yet <daxroc> Morning all <daxroc> How should I be generating the passwd for user-data, I've tried mkpasswd -m sha-256 password but any attempt to login with the resulting password fails ? <daxroc> To login as the user I need to set a new password and then it works fine. <smoser> daxroc, you're trying to log in on console ? <smoser> or on ssh <smoser> via ssh you likely have to enable password auth also <smoser> i'd never seen 'mkpasswd' before, but from reading its man page, i'd expect it to work otherwise. <smoser> you'll need to make sure that whatever distro you're talking to supports shadow entries in sha-256. <smoser> you can probalby iterate faster by just invoking 'adduser' yourself with '--password' and seeing if you can log in then. you should see a item in the log of cloud-init (/var/log/cloud-init.log) showing how it called adduser <daxroc> smoser appreciate the help, I needed to change for sha-512 and enable password auth #cloud-init 2014-06-24 <kfox1111> is there a way to ensure mounts cloud config section gets executed before a #!/bin/bash script? #cloud-init 2014-06-25 <harmw> hm ,smoser <harmw> I'm reading some doc about openstack/glance <harmw> glance image-create --location http://download.cirros-cloud.net/0.3.2/cirros-0.3.2-x86_64-disk.img --name "CirrOS 0.3.2 - Minimalist - 64-bit - Cloud Based Image" --is-public true --container-format bare --disk-format qcow2 <harmw> 'we' should have a cirros-latest for that <harmw> *perhaps <smoser> what is cirros-latest ? <smoser> ah. as in the '--location'. <harmw> like, the latest stable version <smoser> well, yes. and you can read this resopnse however you'd like. <smoser> feel free to assert i'm abusing a monopoly. <smoser> i'd like to get things using simplestreams. <harmw> monopoly? :) <smoser> as it can securely download said image <harmw> ah, its a python lib? <smoser> (abusing cirros to further simplestreams) <smoser> a library and metadata format <harmw> hmk <smoser> http://download.cirros-cloud.net/streams/v1/ <smoser> but anyway, i've been hesitant to make easy "just download cirros" that didn't use that. <harmw> looks nice <smoser> the data there is easily mirrorable (sstream-mirror) <smoser> we have it for cloud-images.ubuntu.com also. <smoser> and then, there is a tool http://bazaar.launchpad.net/~smoser/simplestreams/example-sync/files <smoser> that mirrors that into your glance. <smoser> and "sync"s it easily. <harmw> so its specific to glance/cloud stuff? <harmw> the whole simplestreams stuff, that is <smoser> not relaly. its just nice data <harmw> k <smoser> its data that describes downloads <harmw> looks nice, yes, json stuff <harmw> indeed <smoser> and sstream-sync mirrors that data to your local glance. <smoser> (knowing that it wants 'disk1.img' and such) <harmw> yea <harmw> you've looked at my buildroot branch lately btw? <smoser> no. i have not. i will. i need to do that. <smoser> and to get ppc64el merged in too. <harmw> oeh nice <smoser> err.. ppc64 big endian <smoser> i have that building <smoser> but it doesn't see virtio devices <smoser> er.. network virtio disk i think works. <harmw> you happen to know the defacto way of connecting compute nodes to an openstack environment over wan? <smoser> no. i dont. <harmw> google to the rescue! :p <CatKiller> Hi there! I've still have some issues with cloud-init. I can now use the correct data source in the image, but it does not seem to be able to access the source. <CatKiller> However, once the virtual machine has booted (without the cloud-init configuration so using password login) <CatKiller> I can access the metadataserver fine <CatKiller> I've pasted a full log there: http://bpaste.net/show/PAx9ZnCbT6N5D2QuR5pU/ <CatKiller> My guess is that it can't reach the metadata server as the NIC is not yet configured (NIC is probably configured afterwards by upstart/systemd). Could that be it? <CatKiller> If so, is there a way when installing cloud-init to bring up the network interfaces before the VM boots? <CatKiller> To make this image I installed Ubuntu desktop in a KVM session, and ran "sudo apt-get install cloud-init", changed the data source to "OpenStack" only (this is going to run exclusively on OpenStack) and booted the image in openstack. #cloud-init 2014-06-26 <CatKiller> Hi there, I'm having some issues with cloud-init, I've built a Ubuntu desktop image with cloud-init and OpenStack as the source, but cloud-init fails to retrieve the metadata from the server as the network isn't configured yet. Any ideas how to get cloud-init to configure the network so that the server can be contacted? Running it after the OS has finished booting (and subsequently once the network is up) works fine. <robjo> Just noticed that the Azure data source tries to start "walinuxagent". This appears inconsistent to me as the upstream source provides "waagent" <robjo> shouldn't cloud-init stick to upstream provided names? <robjo> Also the code is setup to always use the "service" command. While distros switching to systemd have service rewired to do the "right" thing it would be nice to use systemctl where appropriate <smoser> CatKiller, hi <smoser> cloud-init runs its network metadata search when all configured 'auto' interfaces are set up in /etc/network/interfaces. <smoser> i suspect you just need to put 'auto eth0' and config it for dhcp there. <smoser> robjo, i'm not opposed to that, but service is a functional work around. <smoser> ie, usage of it was by design. <smoser> wrt walinuxagent or waagent, i'm not sure. i'm fine for patches to go looking for the right name. <robjo> smoser: so conditional code for name and command would be OK? <smoser> sure. i dont really care. <smoser> once we got azure functional, i have not looked ramirezanna@example.org. and have been happier :) <robjo> yup, I usually look at this stuff only as long as I have to as well, will work on a patch <smoser> the worst hack in azure is bouncing the network interface in order to "publish" the hostname. <smoser> i'm guessing what i have there wont work on suse <robjo> OK, thanks for the heads up, will take a look at that as well <smoser> fwiw, the agent start command is configurable <smoser> via the datasource config <smoser> (and so is bounce command) <robjo> Yes I saw the "merge" call but I cannot put all the parts together just yet on how the configuration and everything else connects <CatKiller> smoser: Oh my god you're right, I know what's happening <CatKiller> Silly Ubuntu desktop comes with Network Managr <CatKiller> *Manager <CatKiller> Or nightmare manager as I like to call it <CatKiller> So cloud-init must be waiting from the network to be up from upstart which is probably not really happening with Network Manager <CatKiller> I'm going to remove it completely (unless there's a better option) <smoser> CatKiller, if it were me, i might go the route of grabbing a cloud image and apt-get install ubuntu-desktop <smoser> rather than building your own <CatKiller> smoser: I thought about this <CatKiller> smoser: I thought it would be bad <smoser> CatKiller, its not waiting for anything from network manager <CatKiller> but I just learned the hard way! <smoser> cloud-init's job only waits on "static networking" <CatKiller> I'm actually probably do what you suggested <smoser> which means "stuff configured 'auto' in /etc/network/interfaces" <CatKiller> It does make a lot of sense <CatKiller> Few distros use NetworkManager and no server ones would (which is usually what people start in the cloud) <CatKiller> smoser: I think I'll go the way you suggested with getting ubuntu-desktop in a cloud image <CatKiller> But thanks a lot for helping me understand what was going wrong <smoser> CatKiller, i might do something like: <smoser> get-cloud-iamge <CatKiller> it's good to know why something didn't work <smoser> mount-image-callback my.image -- chroot _MOUNTPOINT_ apt-get intsall ubuntu-desktop <smoser> that wont' "just work", but it will be pretty close <smoser> a couple gotchas: <smoser> a.) you'll have to resize the image to larger than 2G (maybe) <smoser> er... 1.4G <CatKiller> True, didn't think of that <smoser> b.) you'll have to disable services . i have that code somewhere, let me find it. <CatKiller> smoser: Thanks, that's great <smoser> (disable services so they dont start when you 'apt-get install' stuff) <smoser> CatKiller, https://code.launchpad.net/~smoser/maas/maas-ephemerals-v2 <smoser> the bin/maas-cloduimg2ephemeral is what we do to make the cloud images into "ephemeral" images. <smoser> the process is much the same <smoser> but we dont have to grow the disk. <CatKiller> smoser: Nice! <CatKiller> So I don't even have to boot the cloud image in KVM to configure it then? <smoser> CatKiller, well, i do the build process inside a kvm. <smoser> but thats neither here nor there. <smoser> we just do that for safety <CatKiller> ok but you don't need to actually boot the cloud-image to install packages etc <smoser> i'd be very open to patches to mount-image-callback for '--grow-first=4G' or something like that. <smoser> right. we dont boot it. <CatKiller> (which I had been doing to configure my existing cloud image, I booted it and configured it) <smoser> we chroot in and 'apt-get install' <CatKiller> smoser: If I can figure out a way to streamline the growing <CatKiller> I'll submit a patch <CatKiller> So your package is similar to "vmbuilder" right? <CatKiller> except it relies on Ubuntu's preconfigured cloud images instead of building one from scratch from what I can gathr <CatKiller> *gather <CatKiller> bbl <smoser> CatKiller, i really would never suggest to anyone that they build a cloud iamge from scratch <smoser> there are tools that do that, and i thik that they are silly <smoser> similarly i'd never suggest to anyone that they build their own linux kernel, python, glibc or php <smoser> people do that for you, use their work. <robjo> smoser: tried the config route for Azure and starting the agent <robjo> then "rm -rf /var/lib/cloud/*" <robjo> after running cloud-init -d {init, init --local, modules --mode=config} in that order on the command line there is no evidence of an attempt to start the agent? <robjo> Is this testable live or do I have to run a re-build upload etc. cycle? <robjo> The config entry looks as follows: <robjo> datasource: <robjo> Azure: <robjo> agent_command: ['service', 'waagent', 'start'] <smoser> robjo, it should be testable <smoser> pastbin /var/log/cloud-init.log ? <smoser> robjo, <smoser> init --local <smoser> needs to run first <smoser> (it clears the state) <smoser> then init <smoser> and init should have ran and found the azure datasource <robjo> OK, let me try again <smoser> you can configure off the other datasources to reduce cruft. <CatKiller> smoser: Makes total sense, I'll use the cloud image first <robjo> smoser: http://pastie.org/9326842 <smoser> robjo, /var/log/cloud-init.log should be much more verbose than that. <smoser> oh. and i see. seed=/var/lib/waagent <smoser> heres another fun bit of azure, robjo <smoser> you get that CDrom that has important data <smoser> but at some point in a reboot they just yank it from you <robjo> /var/log/cloud-init.log is empty, I pasted /var/log/cloud-init-output.log <smoser> robjo, you rpboably need to restart syslog <smoser> maybe remove that file and resart syslog. <smoser> or maybe on suse thats not hooked up right. but thtats a bug . <smoser> if its not. <smoser> hm.. <smoser> hm.. sorry for being dense. <smoser> there is defintiely more verbose output going somewhere. <robjo> smoser: http://pastie.org/9326911 <robjo> http://pastie.org/9326914 <robjo> http://pastie.org/9326917 <robjo> http://pastie.org/9326920 <robjo> Output in the terminal from each command, was too large for 1 paste <smoser> robjo, suse needs 'pastebinit' <smoser> its amazingly convenient. <smoser> pastebinit <file> <smoser> or <smoser> some-command | pastebinit <robjo> /var/log/cloud-init.log is still empty even after restarting syslog <smoser> 2014-06-26 14:39:34,259 - stages.py[DEBUG]: Restored from cache, datasource: DataSourceAzureNet [seed=/var/lib/waagent] <smoser> it found that, so its not going to go through its earch <smoser> not really sure why it found it as init --local should have removed that link <robjo> so where is that cache? so I can get rid off it ;) <smoser> well its /var/lib/cloud/instance that is a link. <smoser> you can purge all of /var/lib/cloud <robjo> I did, before I ran the commands.....grmbl <robjo> rm -rf /var/lib/cloud/* <smoser> are you able to just let me in to poke really quick ? <robjo> yes, send me your public key <robjo> ramirezanna@example.org <smoser> robjo, https://launchpad.net/%7Esmoser/+sshkeys <smoser> another tool you need is 'ssh-import-id' :) <robjo> smoser: OK, try this: ssh ramirezanna@example.org <smoser> robjo, k. i'm in <smoser> robjo, for logging, cloud-init sends its log to /dev/log <smoser> which in ubuntu gets sent to /var/log/cloud-init.log because of <smoser> http://paste.ubuntu.com/7706306/ <smoser> so yours is just goign to /var/log/messages <smoser> as its not being captured specifically somewhere <robjo> OK, can certainly setup the rule, thanks <smoser> if you ust remove the <smoser> [ *log_base, *log_syslog ] <smoser> line in /etc/cloud.d/cloud.cfg.d/05_loging <smoser> then it will go straight to the file <smoser> so i made that change <smoser> and now ran <smoser> cloud-init init --local <smoser> and <smoser> cloud-init init <smoser> and see the log <smoser> you can see your <smoser> 'service', 'waagent', 'start' <smoser> the reason for the logging being as it is, is that generally, i wanted to use syslog <smoser> but early in boot syslog isnt necessarily available <smoser> so cloud-init tries to write to /dev/log <smoser> and if htat fails it writes to /var/log/cloud-init.log directly <smoser> then, the next time it comes up (cloud-init init) it probably has /dev//log <smoser> and it works. <smoser> note, the file above in that pastebin is a rsyslog format file. i dont knwo about your syslog (syslog-ng) <robjo> OK, makes sense. I'll fix the logging ni my image builds. And will just configure the datasource in the config file, then there is no need to have a bunch of ugly serach code in the azure datasource code <robjo> we have syslog-ng in sles 11, rsyslog in openSUSE and rsyslog will be in SLE 12, it's a mess, bute getting better :) <robjo> Thanks, one problem down :) <smoser> so just one other gotcha there. <smoser> on our walinuxagent <smoser> we do not start it by default <smoser> and we basically configure off all of its function <smoser> as it overlaps with cloud-init. so we have cloud-init start it only on azure. and neuter it heavily. <robjo> I am setting "Provisioning.Enabled=n" in the waagent.conf, that's the info I got from M$ <robjo> so should I or should I not enable the agent to start at boot? <smoser> i'm trying to remember <CatKiller> smoser: Does cloud-init (using configuration found on the Ubuntu cloud-image) run unattended security upgrades on boot, or is it something that needs to be defined at the metadataserver level? <smoser> CatKiller, by default it does not do that. <smoser> you'd enable that via user-data or some other way <smoser> you could patch that on when you re-build your images <CatKiller> smoser: ok, no problem. I'll patch that while rebuilding <CatKiller> Another thing, what are the "cloud_config_modules" defined in the cloud.cfg config file? <CatKiller> Are they programs that will run during the config stage <CatKiller> For instance I wanted to know what "package-update-upgrade-install" was doing but couldn't really tell <smoser> CatKiller, i'm sorry that documentation for such things sucks. <smoser> that ends up involking the 'cc_package_update_upgrade_install.py' file <smoser> which handles 'apt_update' and 'apt_upgrade' <smoser> but this is not anywhere well documented. <CatKiller> smoser: OK, I'll look in that file. Just a quick question though <CatKiller> all of the modules defined in the cloud.cfg will run, or does that just mean they're available? <CatKiller> and the metadata will tell which one needs to run <smoser> they run <smoser> the user-data can configure which ones run <smoser> yes. <smoser> by re-defining that list <CatKiller> smoser: But if it's not defined in the user-data (we use OpenStack here and the user data is *very* scarce) it'll run <smoser> what do you mean the user data is very scarse <smoser> modules generally do the right thing. <smoser> if you give htem config, they may act and have sane defaults <CatKiller> smoser: Well the metadata only provides hostname, authorized SSH keys but not much more <smoser> user-data <smoser> not meta-data <CatKiller> ah ok sorry my bad I confused the two <smoser> user provides user-data when they launch an instance <smoser> nova boot --user-data=your.user-data.file.txt <CatKiller> Ah ok I see. We don't provide any specific user data here as far as I know <smoser> right. so you get the default behavior. which should be perfectly fine. <CatKiller> OK, sounsd good <CatKiller> Another thing I'm not entirely sure about. In the config there is a "package-update-upgrade-install" module, and in "cc_package_update_upgrade_install.py" the handle function looks for "package_update" and "apt_upgrade" from the configuration <CatKiller> these are unrelated right? <smoser> they're synonyms <smoser> distro-generic and distro-specific. <CatKiller> So "apt-get update" and "apt-get upgrade" will run on boot (or is that only on *first* boot) with the default cloud-init config? <smoser> default is off <smoser> you can turn it on and it will run on first boot <smoser> that module only runs 'per-instance'. by default. <smoser> meaning once per instance-id <CatKiller> But it's in the config file though, so the user-data defines the behavior here? <smoser> you can change it to run per-always <smoser> you can put it in config also <smoser> and the user-data can still override <CatKiller> ah ok, so here it's in the config but user-data probably overrides. <CatKiller> Where can I find the user data in the system actually? <CatKiller> (the default ones) <smoser> there is no real location for defaults. <smoser> most of stuff is described <smoser> http://bazaar.launchpad.net/~cloud-init-dev/cloud-init/trunk/view/head:/doc/examples/cloud-config.txt <smoser> and other files in http://bazaar.launchpad.net/~cloud-init-dev/cloud-init/trunk/files/head:/doc/examples/ <CatKiller> thanks for those files <CatKiller> but in the specific of cloud.cfg's "package-update-upgrade-install" module, where can I figure out what will happen there? <CatKiller> I'm not really sure what this clause does <CatKiller> or where it is configured <CatKiller> I guess I'm having trouble linking those modules with what will actually happen when they run (their config files etc) <smoser> CatKiller, by default basically nothing happens there. <smoser> but it responds to some settings in <smoser> http://bazaar.launchpad.net/~cloud-init-dev/cloud-init/trunk/view/head:/doc/examples/cloud-config.txt <smoser> (package_upgrade=true) <CatKiller> smoser: Ah ok, makes sense <CatKiller> smoser: And just a quick question so that I can understand this config file better <CatKiller> where are all these clause defined then in the code? <CatKiller> I grepped for "package-update-upgrade-install" without success <CatKiller> in the cloudinit Python code <CatKiller> (I wanted to figure out what config clause did what by looking at the source) <smoser> cloud_config_modules, cloud_init_modules and cloud_final_modules <smoser> are lists <smoser> they reference "config modules" <smoser> config_modules are loaded . they'r ein the source tree at cloudinit/config/cc_<name-in-list>.py <smoser> where 'name-in-list' has '-' replaced with '_' <CatKiller> smoser: Ahhh ok I get it. Sorry you were trying to tell me this earlier and I had completely missed it. I thought the "cc_" file you told me to lookup handled all of the "config modules" <CatKiller> smoser: It's much much clearer now, thank you very much <smoser> cool <CatKiller> smoser: There's one thing that I'm not quite sure about yet <CatKiller> smoser: Let's imagine I don't want to pass custom "user-data" to the instance, where can I configure a "default" user-data within the image? <smoser> you cant explicitly provide default user-data. <smoser> user-data an be cloud-config syntax or other syntaxes. <smoser> but you can provide any config in /etc/cloud/cloud.cfg.d/<your-file>.cfg <CatKiller> smoser: Ah great, so I could add a file /etc/cloud/cloud.cfg.d/my-config.cfg that would contain: <CatKiller> #cloud-config\npackage_upgrade: true <CatKiller> for instance <CatKiller> In that case, that config would be interpreted as a "cloud-config" file and the package_update should run on first boot <CatKiller> Does that sound right? <smoser> yes. <smoser> files in that dir do not need to start with #cloud-config <smoser> they can only be cloud-config <CatKiller> smoser: Good to know <CatKiller> smoser: In the absolute, it seems that I could add the package_upgrade: true clause at the top level of the /etc/cloud/cloud.cfg config file as well no? <CatKiller> looking at the cc_package.... script it seems that it'll get the flag from the config(s) files (presumably cloud.cfg included) <smoser> yeah. <smoser> config modules know no difference between "builtin" config and user-data <smoser> its all just config that they act on <harlowja> smoser hey, do u have any medium size ideas for cloud-init that i can do, need a diversion from the other projects :-P <smoser> is that medium sized in human terms <smoser> or in super-human harlowja terms <harlowja> lol <harlowja> harlowja terms i guess :-P <smoser> the stuff i have listed here is at: <smoser> https://blueprints.launchpad.net/ubuntu/+spec/servercloud-u-cloud-init <harlowja> Utopic ? <harlowja> whats that <smoser> 14.10 Utopic Unicorn <harlowja> ah <smoser> went looking for mark's post on utopic <smoser> and saw: <smoser> http://www.markshuttleworth.com/archives/1342 <harlowja> nice <smoser> http://www.markshuttleworth.com/archives/1363 <smoser> that one is utopic <harlowja> i should forward that on here, <smoser> anywah... <smoser> for things.. <smoser> the 2 things you might be interested in: <smoser> a.) python3 <harlowja> ack, that one again, lol <harlowja> python3 hasn't gone away yet, lol <smoser> b.) more work on ci-tool <smoser> http://bazaar.launchpad.net/~smoser/cloud-init/ci-tool/view/head:/ci-tool <smoser> i'm not sure how i feel about ci-tool <smoser> oh. the other one... the query stuff. <smoser> you revved that at some point. <smoser> it'd be nice to have 2 json files in /run <harlowja> smoser ya, good-ole-query stuff <smoser> i think thats the way i'd go now. <smoser> just 2 json files <smoser> one with non-sensitive data <smoser> and one with sensitive data <harlowja> right <smoser> and try to have a sane format for things common to most clouds <harlowja> :) <smoser> and allow the datasource to shove other stuff in its own place in the json <harlowja> right <harlowja> ci-tool; would that be needed with a more extensive query tool (or maybe they merge?) <harlowja> into super-ci-query-tool <smoser> ci-tool 'seed' is the real function of ci-tool <smoser> 'seed', 'reset', 'set-ds' <harlowja> oh man, marks page is now showing me 'Error establishing a database connection' <smoser> :) <harlowja> smoser sure, ya, the seed stuff is nice to have <smoser> oh. <smoser> the other bug... <harlowja> ? <smoser> the network interfaces stuff sucks <harlowja> :) <harlowja> yaaaa <harlowja> do u want to try to see how the netcf stuff works? <harlowja> i can try messing around there <harlowja> maybe its 'ready' for primetime <harlowja> *although we'd probably need both, if netcf isn't avaiable on given distro <harlowja> omg, what is my password doin in http://bazaar.launchpad.net/~smoser/cloud-init/ci-tool/view/head:/ci-tool#L51 <harlowja> haha <smoser> thats your password to? wow. coincidence. <smoser> too <harlowja> :) <harlowja> smoser in 14.10 unicorny no more 2.x python? <smoser> yeah, the netcf stuff. ive' come to needing that elsewhere too. <smoser> we really need to get openstack networking sorted <harlowja> :-/ <smoser> to the way that amazon does it. <smoser> so that you can hotplug a NIC into the system <harlowja> i believe with neutron u can do that <smoser> and then the system can hit the metadata service and get the interface config for that. <harlowja> ya <smoser> and that itnerface config needs to be in some format <smoser> and thus... i was asking you again about netcf <harlowja> :) <harlowja> ya, let me see if i can get mark mcclain in here to chat about the openstack neutron networking thing <smoser> maybe after running xml2json on it <harlowja> how we can get from here to there <harlowja> smoser ya, xml == evil <harlowja> lol <smoser> it really just isnt suitable for that reason <harlowja> smoser exactly <markmcclain1> harlowja: here <smoser> hi markmcclain1 <harlowja> markmcclain1 hey, so we were just wondering a little bit about the future of hot-plugging, metadata in openstack, and how cloud-init will help out here <harlowja> thought u might have some knowledge (that i don't have) <harlowja> *hotplugging nics <smoser> you can plug the nics in <smoser> i have done that. <smoser> and they do show up <smoser> all that works. <harlowja> i know what yahoo is doing here (with config drive, which won't work obviously here) <smoser> and then atually.... in the metadata servie i noticed one of them actually in a /etc/network/interfaces file after hotplugging. <smoser> config drive will die <smoser> and that will be ok <harlowja> :) <harlowja> ya, i'll have to fight the people here on that one to make it die (if possible) <smoser> i'm not too hung up on it. <smoser> mostly people hated the metadata service because it didn't work. <smoser> or the networking never worked to get the instance to it. <smoser> but now i think that those problems are less comon <smoser> but anyway.. <smoser> i hotplugged a nic <harlowja> k <markmcclain1> yeah so with hotplugging dhcp should work on that interface <smoser> and then an entry in /etcnetwork/interfaces styel file was in the interfaces location in the metadata service <smoser> but it was out of order :) <smoser> ie, the new nic was eth0 and the orig was eht1 <smoser> so its just silly. <smoser> thus need for some beter format for describing <harlowja> and then enter xml netcf format :-P <harlowja> *xml (cough) <smoser> yeah, i most certaily would make major mistakes if i invented my own language. <smoser> but really would not be interested in putting xml into a stack where it doesn't otherwise exist. <harlowja> :) <harlowja> xml is da best <harlowja> markmcclain1 has there been any thought on moving to a more agnostic format in the community for this <harlowja> not saying it has to be https://fedorahosted.org/netcf/ (but something similar in json or other would be nice) <markmcclain1> I haven't heard too much yet about how to fix these issue <harlowja> k <harlowja> smoser so the mission, if u choose to accept it, is to fix this issue, this message will self-destruct in 5 seconds <harlowja> boom <smoser> yeah. i'd like to do it. it generally needs doing i think <harlowja> agreed <harlowja> smoser would this be a cloud-init thing at that point, or something else? <harlowja> something else that listens for hotplugs and then does stuff <harlowja> network-cloud-init (or something) <smoser> i think i'd keep it in cloud-init. but try to make it separatable <harlowja> k <smoser> basically, its udev hooks, code to get the data, and then code to act on it. <harlowja> ya <harlowja> any idea how that works for freebsd ? <harlowja> harmw activate, lol <smoser> and cloud-init would get the original datasource, and then the udev hooks would say "ok, i just got an interface, what cloud should i get data from!" <smoser> and cloud-init would have configured that. <harlowja> right, makes sense <harlowja> smoser do u want to do a joint writeup to the openstack-dev ML, i can draft somethign <harlowja> and we can start this discussion there <harlowja> and then see about how to make this really happen <harlowja> fix the brokeness that exists for this in to many places (nova has parts of this code, neturon seems like it has others) <harlowja> smoser sound ok with u boss <harlowja> it just requires like cleanup in lots of places, which would be nice to just do <harlowja> like nova has a metadata part, so does neutron, so this would have to be made in both of them? <harlowja> and config-drive basically doesn't get this, idk <harlowja> or does nova rewrite the config-drive when a hotplug occurs <smoser> harlowja, well, it could re-pouplate it for reboot i guess. <smoser> but theres really no other way for the guest to "free" it. <harmw> harlowja_away: sup <harlowja> harmw nadda was just discussing how more dynamic network configuration can be done <harmw> you know fbsd is still ancient in many ways, right :p <harlowja> :) #cloud-init 2014-06-27 <CatKiller> smoser: Hi, I had a quick question about mount-image-callback: Are the commands provided with args executed from inside the chroot? If running "apt-get install" will it run using the apt-get binary from inside the image, or the "host"'s apt-get? <CatKiller> Because I'd like to modify a 14.04 cloud image on an older 10.04 system (or 12.04) <smoser> hosts. <smoser> if you want chroot. then chroot <smoser> mount-image-callback .... -- chroot _MOUNTPOINT_ apt-get update <CatKiller> smoser: And do you think that would work then (running apt-get from inside a chroot with a different host's version?) <utlemming> CatKiller: yeah, that works unless you need kernel modules from the host <CatKiller> utlemming: Ah yes good point, didn't think about that. Here I'd be trying to install ubuntu-desktop within a ubuntu-cloudimage (server) <utlemming> CatKiller: that works just fine, I do that all the time <CatKiller> smoser, utlemming: Thanks a lot for the help <CatKiller> smoser: Another thing, I'm going to implement resizing the image, but I was wondering whether it would not make more sense to create a separate image resize script instead of forking mount-image-callback as you initially suggested <smoser> the reason it woudl fit in mount-image-callback is that in order to resize , you will need to set up the qemu-nbd device <smoser> and re-implement a lot of that. <CatKiller> smoser: Very true. Then mount-image-callback it is :) <CatKiller> I'll submit a patch when I'm done provided my boss gives the go ahead. <CatKiller> I will try and keep it really nice and clean like your own scripts <smoser> CatKiller, thakns. i i think i'd just try to do it as both a '--resize' flag <smoser> and also a 'mount-image-callback <resize>' <CatKiller> The second being like a command you pass to mount-image-callback? <smoser> CatKiller, well, i was tihning mount-image-callback would handle that specifically <smoser> kind of like a subcommand of mic <smoser> harlowja_away, https://review.openstack.org/#/c/103193/ <CatKiller> smoser, ok, I'll let you know when I'm done for a quick review <smoser> k #cloud-init 2015-06-01 <devicenull> can I configure cloud-init to not do anything if it can't reach some kind of metadata service? <devicenull> I keep hitting issues where it'll fail to reach the metadata server, and fall back to the OS's default config <strikov> devicenull: If you can modify the image you may want to overwrite datasource_list: [....] in the /etc/cloud/cloud.cfg. This is a list of datasources which cloud-init tries to use and you may leave just a single entry there (one that works). <devicenull> yea, I think I figured it out <devicenull> having ', None' at the end of that would cause it to ignore failures #cloud-init 2015-06-02 <larsks> smoser harlowja : when you're around, do you have an opinion on https://bugs.launchpad.net/cloud-init/+bug/1461201 ? This attempts to make the check for systemd less dependent on distro naming... <smoser> larsks, seems reasonable. <larsks> Thanks for taking a look. I want to carry this (or something similar) in our RHEL packages for 0.7.6 to ensure that they work on derivatives. <harlowja> seems fair to me, want to make a branch and put that one up? <larsks> harlowja: well, it's here: https://github.com/larsks/cloud-init/tree/bug/detect-systemd <harlowja> ah, ok <larsks> Can you use that? <harlowja> wrong system :-P <larsks> I'll see if I can figureo out bzr this evening. <harlowja> orrr http://stackoverflow.com/questions/20273368/launchpad-pull-request ;) <harlowja> * http://stackoverflow.com/a/20273376 <harlowja> yes i know, bzr is super-awesome <harlowja> and we could really now go through the stackforge repo <larsks> The neat things is that I am using git locally with bzr33ec:265c:71fe:e26d:2682:4ec2:aaa1:99ab remotes, so I can't tell :) <harlowja> ah <harlowja> maybe its easy then, never tried doing that <larsks> But in any case I will submit that as an actual PR later today. <harlowja> cools #cloud-init 2015-06-03 <impaque> hey guys, quick question: how can i use the variables provided by the (cloudstack) metadata, such as local-hostname, in my scripts? <impaque> does cloud-init expose them somehow somewhere? <larsks> It does not, currently (wish it did!). You can talk to the metadata service yourself using a simple HTTP api. <larsks> There is a 'cloud-init query' command, but it appears to be unimplemented at this time. <impaque> larsks: thanks! <impaque> although, i believe they *are* exposed in cloud-config scripts <impaque> from some coreOS page: <impaque> #cloud-config coreos: fleet: public-ip: $public_ipv4 metadata: region=us-west <impaque> (merged to one line, but you get the idea) <impaque> hmmmm <larsks> Note that coreos has their own version of cloud-init. <impaque> ah :/ <smoser> larsks, yeah, we need cloud-init query <smoser> so... impaque we will fix that for you in 2.0... its in the plans. <smoser> cloud-inti will expose (via json or versioned python module/access) objects to get you that stuff. <impaque> smoser: so basically, the only way to get that meta-data is by writing a module, if i get that correclty, via cloudinit.util? <weaseal> does anyone know if it is possible to detect AWS resources such as RDS, ELB, etc by only feeding in a VPC ID? <weaseal> using cloud-init <smoser> "detect" ? #cloud-init 2015-06-04 <larsks> harlowja: btw, submitted that pr yesterday. And now it has tests, too. <Odd_Bloke> smoser: I'm looking at fixing https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1411582 in cloud-init. <Odd_Bloke> smoser: My suggested fix is to shift the udev rule that creates /dev/disk/azure/... in to cloud-init, and then teach cloud-init to dereference /dev/disk/... symlinks. <Odd_Bloke> smoser: We could also look at making the directory created more generic (e.g. /dev/disk/cloud-init/...), so that we have a single place to look for stuff on different clouds. <Odd_Bloke> (This would, for example, allow us to answer 'do I have an ephemeral disk?' by just looking at /dev/disk/cloud-init/ephemeral or whatever) <Odd_Bloke> smoser: Thoughts? <smoser> Odd_Bloke, well, looking forward, there is a plan for a block device usage languange. that explicitly declares how disks should be used. this will support raid, lvm, bcache ... <smoser> that is happening for curtin usage. <smoser> i'd like for cloud-init to be able to take that language and render it into being also. <smoser> the added piece that cloud-init needs is kind
{'channel': 'cloud-init', 'month': 6}