#cloud-init 2014-04-01 <jclift> Script failure was caused by /usr/bin/bash not existing. /me sighs <jclift> Well, that's fixed at least ;) <cds> does anyone know how i can force cloud-init to only run once? <cds> i pass nocloud data as a cdrom during first boot, everything works fine <cds> reboot without it and it falls back to the no data source and resets all my changes <smoser> cds, 2 options: <smoser> a.) don't detach the cdrom <smoser> b.) set manual_cache_clean: True <smoser> http://bazaar.launchpad.net/~cloud-init-dev/cloud-init/trunk/view/head:/doc/examples/cloud-config.txt <cds> cool, thanks <cds> is setting the kernel param ds=nocloud acceptable? <cds> i am just using this vm on a local machine <smoser> well, how did you get the kernel and intiramfs? <cds> let me back up, i just want to boot ubuntu cloud once, have cloud-init configure it via nocloud-data <cds> then not worry about passing it anything cloud-init related <cds> changing ds=nocloud in /etc/grub/default after the initial configuration worked ok <smoser> ah. ok. that doesn't sound terrible. <smoser> probably other ways to do it, but i'd have to think. yours doesn't sound terrible. <cds> cool, thanks :) <jclift> smoser: Btw, for the RHEL/Fedora/CentOS thought on "how to tell if a reboot is needed", it might not be that hard to tell for kernel changes <jclift> eg just retrieve + store the version info strings prior to running yum, retrieve them again afterwards, if they compare differently, voila, new kernel installed. No need to even understand the version number breakdown inside, just "if it's different, reboot". #cloud-init 2014-04-02 <msbrown> Hey, have an oddball situation. I've taken a server installed via maas (d-i install), and moved it off of maas to be a stand-alone server. What's the best way to disable the cloud-init boot sequence? <smoser> msbrown, you can probably <smoser> dpkg-reconfigure cloud-init <smoser> and just seleect the None datasource <msbrown> thx <smoser> if that doesn't work, then i'd just put some data in /var/lib/cloud/nocloud/seed <smoser> so that it would think it found *that* datasource all the time. <msbrown> I'll try the first method <msbrown> well, that makes the boot faster, you get some ugly messaging but as long as you know to ignore it.... <msbrown> (whatever you do, *don't* just delete all the cloud* entries from /etc/init :-) <SpamapS> smoser: question <SpamapS> smoser: oh and HI <SpamapS> smoser: so, cloud-config sets the hostname right? <SpamapS> smoser: I'm considering that we need to delay runlevel 2 until after cloud-config finishes <SpamapS> smoser: thoughts on that? <SpamapS> smoser: we're having problems where things don't always get the same hostname on reboot because they start faster the second time for whatever reason.. just before cc_set_hostname runs <smoser> ubuntu ? <smoser> SpamapS, ? <SpamapS> smoser: yeah <SpamapS> smoser: this is with baremetal hardware, but using EC2 metadata.. so.. yeah.. we're on crack a bit. :) <smoser> cloud_init_modules should set hostname per default config <smoser> which should execute <smoser> start on mounted MOUNTPOINT=/ and stopped cloud-init-nonet <smoser> which almost certainly should block the starting of runlevel 2 <SpamapS> smoser: so cloud-config doesn't run the cc_* modules? <smoser> see cloud.cfg, SpamapS <smoser> they run at different stages per that config <SpamapS> smoser: AH <SpamapS> misunderstanding resolved <SpamapS> smoser: ok.. so hm.. why are we seeing our hostname different on two successive boots.. argh <SpamapS> first boot we get no .novalocal <SpamapS> or we do, then second we don't get it.. I can't remember now <smoser> SpamapS, based on very little info, i guess its related to <smoser> http://bazaar.launchpad.net/~cloud-init-dev/cloud-init/trunk/view/head:/cloudinit/sources/__init__.py#L169 <SpamapS> smoser: we do have local-hostname <SpamapS> smoser: but good thinking :) <harlowja> SpamapS who are u, lol <harlowja> no cloudinit for u <harlowja> lol <SpamapS> harlowja: i can haz hostname plzzzzz <harlowja> SpamapS ha <harlowja> SpamapS let me know if u figured it out, can help if u don't <SpamapS> harlowja: I don't think our problem is cloud-init <SpamapS> something else subtle going on <harlowja> k <harlowja> stop doing those bad things then <harlowja> lol <SpamapS> am I the only one that thinks lol looks like a ghost raising its arms and chasing somebody from right to left? <SpamapS> lol==---... <harlowja> :) <harlowja> run away! <SpamapS> ..---===/o/ <harlowja> ha <SpamapS> well now it looks like bennie hill <harlowja> SpamapS do u know if anyone from HP is going to http://www.meetup.com/openstack/events/172017412/ ? <SpamapS> just need doors and gratuitous un-garmenting <harlowja> "OpenStack at Mega-scale" (whatever that means) <SpamapS> harlowja: I hope so <harlowja> ya, i'm not sure i want to go yet, lol <SpamapS> harlowja: but most of our actual dev/ops who would be able to contribute are in "not bay area" <harlowja> megascale sounds to much like marketing blah blah <SpamapS> gigascale would be better <SpamapS> terascale <SpamapS> Have a competing meetup next door. "OpenStack at petascale" <harlowja> :) <harlowja> +2 <harlowja> mine bigger than yours meetup <harlowja> *maybe shouldn't call it that* <SpamapS> might attract the wrong crowd <harlowja> :) <SpamapS> lol===---... <harlowja> ha <harlowja> ..---===/o/ <harlowja> ha <SpamapS> o/` [ kazoo music ] o/` <harlowja> ^ did the ghost just pass threw a kazoo? <harlowja> cause ghosts can do that afik <harlowja> *afaik <lipinski> How do I get a VMs instance id via cloud init? e.g., the one that is in openstack meta-data.json? <harlowja> cat /var/lib/cloud/data/instance-id <harlowja> *thats one way <lipinski> harlowja: that's not the instance ID I need. I think that's the EC2 one? I need the one that is available via Openstack metadata <lipinski> e.g., curl 936-429-9875/openstack/latest/meta_data.json (uuid) <harlowja> ah, which cloud-init are u using <lipinski> My problem is that using the 936-429-9875 ties me to the network-based metadata service. I would like to use Cloud-init so that I am abstracted from metadata via network vs cloud-drive <lipinski> one sec <harlowja> yup, the newest cloud-init has that abstraction <lipinski> 0.7.2-2.el6.noarch <harlowja> ya, that one only knows how to fetch from the EC2 metadata/userdata from 169 <harlowja> which is why u see the ec2 id <lipinski> Is there a newer Cloud-Init that would give me what I need? <lipinski> (hopefully in a RHEL6 RPM form.. :) ) <harlowja> ya, 0.7.5 would have what u need, although u'll need to build your own rpm afaik <harlowja> which isn't that hard to do since the cloud-init code has that <harlowja> i don't think rhel has published that version yet <lipinski> harlowja: thanks a bunch. So, the UUID/VMID that I'm looking for would then be accessible via /var/lib/cloud/data/instance-id ? Or somewhere else? <harlowja> that'd be the place <lipinski> fantastic. thanks again. <lipinski> harlowja: sorry to bother again. 0.7.4-2 have what I need, or do I need 0.7.5? <harlowja> i think 0.7.5 <harlowja> which was just released afaik <harlowja> the other option is u can just add a script into user-data that fetches that information lipinski (basically running `curl 936-429-9875/openstack/latest/meta_data.json`) <lipinski> harlowja: thanks. Yes - I may do that as a stop-gap measure until we can get to 0.75. <harlowja> right <harlowja> shouldn't be to bad, could even do something simple in python to get it <harlowja> although u should be able to checkout cloud-init and run 'make rpm' and a rpm should pop out <lipinski> I didn't want to get into the "business" of interfacing with metadata services. Prefer Cloud-Init do the lifting for me and that way I get cloud-drive+metadata support without any change on my side :) <harlowja> yup <lipinski> I've never downloaded cloud-init before (since we get RPMs). <lipinski> Thanks again. <harlowja> np #cloud-init 2014-04-03 <smoser> harlowja, lipinski thats another request for "cloud-init query" <smoser> for 0.7.6 we should get that back in one way or another. <smoser> 2 json files. one with privledged info (user-data), one with public data. <harlowja> harlowja thats true, forgot about all that ;) <smoser> harlowja, are you talking to yourself again? <harlowja> oops <harlowja> that was supposed to be smoser not myself, lol <harlowja> about the cloud-init query stuff :) <harlowja> harlowja u so awesome <harlowja> harlowja i know <harlowja> lol * smoser can't look at lol any more without thinking about running away from ghosts <harlowja> ;) <smoser> l0l <--- cyclops running away from a ghost. <harlowja> all SpamapS fault <harlowja> :) <harlowja> smoser how'd http://itsfoss.com/facebook-to-buy-ubuntu-for-3-billion/ go over @ canoincal, lol <harlowja> hope canonical folks were in on the joke <smoser> joke? <smoser> carp. <smoser> i probably need to return all that jewelry i bought. <harlowja> def <harlowja> and cars <harlowja> u might want to return all that <smoser> yeah. that really sucks. <smoser> cause i look DOPE in all that bling <harlowja> ;) <harlowja> ya, next time wait till the deal is verified before gold plating all your teeth #cloud-init 2014-04-04 <SpamapS> smoser: http://download.cirros-cloud.net/streams/v1/index.json.gpg <-- whose key is that? <SpamapS> smoser: doesn't mean much to sign things if the public key isn't itself in the web of trust <SpamapS> smoser: anyway, I need to know where I can fetch that key so I can use cirros w/o wondering if I've been MITM'd <harlowja> my guess SpamapS is thats smoser key, but not sure <harlowja> since smoser is mr.cirros <SpamapS> it is not <SpamapS> harlowja: that key is unknown.. not in any key servers. <harlowja> hmmm <harlowja> not my key <SpamapS> Ideally smoser would sign it, and upload the signed public key <harlowja> agreed <SpamapS> Actually ideally several people would sign it, whoever has root on the box that builds those really. <SpamapS> But smoser has enough sigs.. his key is good enough for me. :) <harlowja> :-P #cloud-init 2014-04-06 <jeffspeff> i'm trying to find documentation on how to use cloud-init to change a computers name and add it to an active directory domain. if it's relevant, i'm using windows 7 guest vm's and ovirt <jclift> jeffspeff: As a thought, it might also be worth asking in the oVirt channel(s) too * jclift doesn't know enough about cloud-init to help out with your question here though <jclift> active directory <-- no idea <jclift> Changing the non-active directory hostname can be done using the "hostname: foo" and "fqdn: foo.example.org" cloud-init statements <jclift> Not sure if that's relevant though :) #cloud-init 2014-04-07 <yann2> Hello! I am trying to use cloud-init with FOG and rackspace, but am failing miserably. It seems that my mime encoded cloudinit script is properly copied to /var/lib/cloud/seed/nocloud-net/user-data , but it doesnt appear to be run... not sure where I should look to see whats wrong... any idea? the rackspace examples I found on the web didnt work <smoser> SpamapS, yeah, i have creds to that private key. <smoser> but it is separate by design from my private key. <smoser> i'll sign it and upload <jclift> yann2: Does the script work when it's not mime encoded? <jclift> yann2: Also, there's a log file in /var/log/cloud-init.log <yann2> jclift, yes, actually I got it to run using nova client <jclift> k, so it sounds like the mime encoding is busting it somehow <jclift> yann2: I've not tried using mime encoded version <jclift> yann2: At a guess, you'll probably need to look through /var/log/cloud-init.log to see if there's anything there <yann2> trying this now http://pastealacon.com/34262 - I think the problem is that rackspace only tries to get cloud init files from config disks by default and not from /var <yann2> jclift, the only error seem to be unrelated and linked to a "ubuntu" user that is not found.. the rest seems to be rackspace stuf <yann2> 2014-04-07 14:27:13,937 - __init__.py[WARNING]: Unhandled non-multipart userdata ' < maybe that <jclift> yann2: Hmmm, I don't use Ubuntu so no idea there <jclift> Yeah, that warning could be significant <jclift> yann2: Are you able to put your proper #cloud-config file on a webserver somewhere, and then point to it using an #include? <jclift> yann2: This is what I use as a #cloud-config file: https://forge.gluster.org/glusterfs-rackspace-regression-tester/glusterfs-rackspace-regression-tester/blobs/raw/master/remote_centos6.cfg <yann2> There is also this file in /etc/cloud/cloud.cfg.d/90_dpkg.cfg that contains this datasource_list: [ ConfigDrive ] <yann2> so I assume my only way to include additional cloud init config would be via the configdrive... <jclift> yann2: I pass that remote_centos6.cfg in to the local VM via config drive, and then cloud-init goes and retrieves the external URLs itself <jclift> yann2: Is the mime-encoded script showing up in /var/lib/cloud/instance/user_data ? <jclift> Or /var/lib/cloud/instance/user_data.i ? <yann2> jclift, cf my last paste, I am now trying to see if I can pass the cloud init file directly to the config file, a bit like the nova client does here http://developer.rackspace.com/blog/using-cloud-init-with-rackspace-cloud.html <jclift> yann2: I'm using cloud-init with Pyrax in rackspace <yann2> but otherwise, yeah, when i used to copy files using personality, the file showed up mime encoded at the right place ('/var/lib/cloud/seed/nocloud-net/user-data' ) but I think cloud init is not configured to read it <yann2> jclift, and where do you put the cloud init configuration? <jclift> Unfortunately, it's not documented (so I should write up some docs for it to help the next guy) <jclift> yann2: Are you ok with Python? <yann2> I can read, yes, but I need ruby <jclift> k. This might be helpful for reading then. It's kind of spagetti code atm though... I need to clean it up. But it works. https://forge.gluster.org/glusterfs-rackspace-regression-tester/glusterfs-rackspace-regression-tester/blobs/master/create_servers.py <jclift> yann2: Line 179 is where the new server instance is created <jclift> yann2: One of the parameters to the call which creates the new server is "userdata". <yann2> thanks a lot for your help, I ll read this :) <jclift> yann2: I provide the #cloud-config file to that, which passes it automatically to cloud-init using config drive <jclift> (note that I have config_drive=True as another parameter) <jclift> yann2: The #cloud-config file I use, is that "remote-centos6.cfg" thing <jclift> So, when cloud-init starts up, it gets given that remote-centos6.cfg file. It reads that, noticing it starts with #include, then goes and gets the URLs on the next two lines. <jclift> Those URL contain what actually needs to be done <jclift> The first is a proper #cloud-config thing <jclift> The seconds is a script to execute after the #cloud-config thing has fully run <jclift> s/seconds/second/ <yann2> so you use config_drive as well <yann2> and userdata = ci_config... should be very similar to what I m doig... <jclift> yann2: As a thought, when I was getting my head around cloud-init for the first time last week, I spun up the various VM's remotely (like you), then logged into them to try and figure out wtf was happening <jclift> yann2: Yeah, it sounds similar <yann2> so ci_config is not mime encoded, nor base64 encoded <jclift> Correct. Have you logged into a VM, and mounted /dev/xvde to a temp spot to see what's being passed via config_drive? <jclift> yann2: The userdata= argument here can actually be just a newly opened file handle. You don't even need to read in the contents. <yann2> nope, good idea <jclift> yann2: Yeah, mount /dev/xvde to a temp spot, and take a look through it's structure <jclift> yann2: Helps to get a better conceptual understanding of wtf is going on :) <yann2> indeed.. its xvdd here, where would my userdata be? <jclift> Ahh yeah. xvdd is right <jclift> xvde is the data drive <jclift> Sorry <jclift> Been using xvde a lot over the weekend :) <yann2> mhhh <yann2> so I have a xvdd with bunch of jsons, and no xvde <jclift> That just means you're using a VM type without an additional data disk <jclift> eg 512 Standard or 1GB Performance <jclift> Don't get hung up on xvde thing. That was my mistage <jclift> mistake <yann2> ok <jclift> My typing sucketh today ;) <yann2> cant see my config copied anywhere on the config disk though <jclift> yann2: Is this similar to what you're seeing? http://fpaste.org/92259/96882152/ <yann2> yep <yann2> is my user_data supposed to be copied somewhere there? <jclift> yeah <jclift> New paste: http://fpaste.org/92262/13968823/ <jclift> That shows the same mount, but also shows the user_data file that was pulled in by the userdata= parameter in my Pyrax call <jclift> That file gets placed into /var/lib/cloud/instance/user_data <jclift> After the remote urls are grabbed, the result is /var/lib/cloud/instance/user_data.i, which is then run/processed/whatever <yann2> yeah your ci_config variable actually contains the content of the file <jclift> Yeah <yann2> so this file is a cloud init config file <jclift> Yeah <yann2> and if i read it right you do not base64encode it nor is it mime encoded <jclift> Correct <yann2> I ll show you my script give me a sec <jclift> I don't base64 or otherwise touch it <jclift> k <yann2> http://pastealacon.com/34263 <jclift> Does it work like that? <yann2> I dont have a user_data in openstack/latest though <yann2> nope <yann2> I mean it runs and creates the vm, but no userdata in the config disk <yann2> maybe its a question for fog... <jclift> What happens if you try "userdata" instead of "user_data" ? * jclift noticed some inconsistency in naming around user_data and userdata <jclift> Some parts of Nova require "user_data" <jclift> But Pyrax definitely needs it as userdata <yann2> https://github.com/fog/fog/blob/f531f0bdd715e6f0e3008b35535834ad8e854ec1/lib/fog/cloudstack/models/compute/server.rb <yann2> seems to be an alias, lets try it.. <yann2> still no success :'( <jclift> Damn <jclift> Hmmm, maybe time to ask the Fog guys then <yann2> yep.. <jclift> Do they have an example of working Fog code with userdata you could copy to experiment with? <yann2> dont know, I just asked on #ruby-fog <yann2> found this, but its old http://pastebin.com/n6fRuF0C :D <jclift> yann2: Heh, well "Good Luck" I guess. I'm not into Ruby... hopefully the Fog guys can help. :) <yann2> yeah thanks, I think it's supported by the openstack compute but not the rackspace one... <yann2> I ll try my luck with a bug report <yann2> opened a bug there https://github.com/fog/fog/issues/2824 let's wait and see <yann2> jclift, trying my luck patching fog, wish me luck ;) <jclift> :) <jclift> Definitely good luck! <yann2> yeah man, epic skills here :) I ll do a pull request this evening <jclift> :) <sauce> i am using cloud-init for the first time. using it with EC2. i created a very simple user-data #cloud-config file (see here http://pastebin.com/gE8C0M1d). i am using centos6.4 AMI's from cloudmarket.com that say "with cloud-init installed". when I do "ec2-run-instances -f myuserdata.yaml", it boots up fine, i can see cloud-init is installed, but my user-data file was not taken into consideration. anyone know why? <smoser> sauce, what is the version of cloud-init ? <yann2> https://github.com/yannh/fog/commit/e335084b200e88263f739a867366afd97fc6b0cb jclift , for what its worth <yann2> testing a bit more before sending my pull request :) <harlowja> smoser so when we switching cloud-init to git? ;) <smoser> harlowja, i try to avoid flamewars. <harlowja> lol <SpamapS> smoser: cool. I just fetched the key from keyserver.ubuntu.com and it does not have your signature on it. <SpamapS> really any signatures on it <yann2> https://github.com/fog/fog/pull/2826/files now just need a nice soul to merge it and I should be good <smoser> SpamapS, i can sign it. thats fine. the thing i didn't know is what i should sign. <smoser> its a subkey <yann2> alright, off for today, thanks a lot for all your help jclift that was immensely useful <yann2> have a nice day/evening <smoser> SpamapS, i signed now. and put onto keyserver.ubuntu.com . <SpamapS> smoser: sign the main key. The point is to allow downloaders to verify the key without prayer. ;) <smoser> SpamapS, yeah. i did, right? <SpamapS> smoser: indeed, well done :) <sauce> smoser cloud-init-0.5.15-68.el6_bashton1.noarch <sauce> smoser nevermind, cloud-init did run. i tried it with some low level stuff like touch /tmp/file1 and it did. now i gotta figure out why the puppet module didnt work <sauce> while i am here, whats the best way to add a host to /etc/hosts with cloud-init? <smoser> sauce, that is old <smoser> i really dont know what support there would be in something called that version. <smoser> without looking. so that i'd be my first guess. <smoser> wrt /etc/hosts, you can modify the apprpriate template file with a boothook. <SpamapS> smoser: note that it would be quite useful now if you started either signing the images, or producing SHA256SUMS <SpamapS> smoser: MD5 is broken <smoser> i am signing the images. <smoser> http://cloud-images.ubuntu.com/releases/streams/v1/com.ubuntu.cloud:released:download.sjson <smoser> thats the preferred way. <SpamapS> preferred by who? <harlowja> 0.5.15, woah <smoser> err.. wait. bad link. <SpamapS> I can use jq to grab those sha256sums tho .. so that works <harlowja> sauce u are on rhel6? <smoser> http://download.cirros-cloud.net/streams/v1/net.cirros-cloud:devel:download.sjson <sauce> 6.4, about 1 year old <harlowja> http://repos.fedorapeople.org/repos/openstack/cloud-init/ should be newer :) <harlowja> although i thought u could install a newer one <harlowja> 0.7.2 is much better ;) <SpamapS> smoser: color me old fashioned.. but a .asc file for each image would be um.. a bazillion times preferrable to that for scripting. :-P <SpamapS> smoser: but I can work with it. :-P <smoser> i agree that having FILE.asc is simpler for scripting. <SpamapS> jq has at least made json available to bash <SpamapS> smoser: would be quite helpful if this format actually had a _list_ for the products. :-P <smoser> list ? <smoser> its a dict <smoser> because the products is a key <SpamapS> smoser: so to find latest version, I should still use /version/released ? <SpamapS> smoser: Yeah, but I have to sort the keys to find the latest. :-P * SpamapS will call the whambulance <SpamapS> smoser: just whining. :) <jclift> sauce: There's modern cloud-init in EPEL isn't there? <sauce> jclift im just being lazy and using someone elses AMI <sauce> rather than create my own <smoser> SpamapS, http://paste.ubuntu.com/7218123/ <jclift> Heh. Doesn't seem to be working for you in this instance. :( <smoser> that is secure and allows you to easily point it at a mirror if you want. <smoser> and '--max=1' does the sorting for you. <harlowja> sauce i'd recommend at least upgrading the AMI cloud-init version :) <SpamapS> $ sstream-query <SpamapS> sstream-query: command not found <SpamapS> smoser: no package suggestion. :( <SpamapS> smoser: also I have a really giant set of Fedora users so I have to be mindful of hard it will be for them to use. <smoser> $ dpkg -S `which sstream-query` <smoser> simplestreams: /usr/bin/sstream-query <smoser> SpamapS, that giant set of users installs random garbage from pip all the time. <smoser> so... not being packaged isn't a *huge* thing. <harlowja> bad users <SpamapS> smoser: oh we're quite happy to abuse pip :) <smoser> so i should get a simpelstreams into pip. <sauce> ubuntu's official EC2 ami's use: 0.6.3-0ubuntu1.10 <SpamapS> smoser: yes. but for now, jq will suffice <smoser> jq ? <harlowja> http://stedolan.github.io/jq/ <harlowja> those bash people <harlowja> lol <SpamapS> --===/o/ <harlowja> lol <smoser> its C ? <SpamapS> smoser: also, you have files that are '.gpg' but they have .asc content in them <SpamapS> smoser: yeah tiny little utility, we use it everywhere to process json <smoser> thats nice. <smoser> SpamapS, i dont think i started that. <smoser> the little i know came from modelling ubuntu <smoser> http://cdimage.ubuntu.com/ubuntu-server/daily/current/MD5SUMS.gpg <SpamapS> sure <SpamapS> they did it wrong too :) <SpamapS> it confuses gpg, you have to tell it that it is ascii armored detached <harlowja> i left my ascii armor at home :-/ <smoser> SpamapS, well that sucks. <smoser> my damned ignorance keeps getting in the way. <smoser> the sstreams code only really handles the inline signed anyway. <SpamapS> smoser: Yeah, and the inlined signed is kind of hard to use w/ jq.. as I have to strip off the signature.. :-P <smoser> right. so we need to improve jq for inline signed json <SpamapS> smoser: jq example: <SpamapS> $ jq '.["products"]["net.cirros-cloud:standard:0.3:i386"]["versions"] | keys | sort | max' net.cirros-cloud\:released\:download.json <SpamapS> "20140317" <SpamapS> see how hard that is. :-P <SpamapS> $ jq '.["products"]["net.cirros-cloud:standard:0.3:i386"]["versions"]["20140317"]["items"]["disk.img"]["sha256"]' net.cirros-cloud\:released\:download.json <SpamapS> "f0803c2d179c8a02d029239d35fc3e752cc81ad3436ea52b757e11685ca7c074" <smoser> see how much easier it was with the tool i gave you ? <SpamapS> smoser: is it on pypi yet? <smoser> its not. i can put it there, although i've never done that before. <smoser> so again with the damned ignorance getting in my way. <SpamapS> smoser: I've got a jq solution. It's not horrible. But if/when you do get it on pypi, please let me know so I can switch. <smoser> SpamapS, are you looking to put that into devstack ? <smoser> or elsewhere <SpamapS> devstack is dead to me :) <SpamapS> but it should go there too yes <SpamapS> smoser: TripleO devtest yes <SpamapS> smoser: https://review.openstack.org/#/c/83347/ <smoser> well, its interesting actually. both of them are. <smoser> from the "continuous integration" perspective. <smoser> in that I can randomly change / break things. <sauce> where can i get full cloud-init docs other than http://cloudinit.readthedocs.org/en/latest/? the Modules section is empty, and i feel that the examples don't list everything. <sauce> i.e. it's not clear how to add a 3rd party apt repo <sauce> i would even settle for code to look through. where are the modules stored? <smoser> sauce, you get docs for the version you'r using in the package you're using. <smoser> the config modules are stored in cloudinit/modules/cc_* <smoser> (except they might be different in 0.5.x) <smoser> to add a 3rd party apt repo is trivial <smoser> and is shown at http://bazaar.launchpad.net/~cloud-init-dev/cloud-init/trunk/view/head:/doc/examples/cloud-config.txt#L21 <harlowja> SpamapS u say devstack is dead?? <harlowja> intersting <harlowja> SpamapS u know u want to use anvil, lol <SpamapS> harlowja: I say that devstack is dead _to me_ <SpamapS> harlowja: we use devtest.. because multi-node matters. :) <harlowja> lol <harlowja> ya <sauce> thanks smoser ! <sauce> smoser you say the docs come with the package, i have no man cloud-init though <smoser> sauce, in ubuntu they're in /usr/share <smoser> in centos or whatever, id' rpm -qa | grep -i doc <sauce> thanks sir <sauce> i switched to ubuntu for now. i want to learn cloud-init in ubuntu first, then i'll go to centos <smoser> or just stay on a sane OS :) <smoser> although, to be fair, 2.6.18 was a good kernel. <smoser> sauce, i was making fun of centos. <sauce> i know i know <smoser> :) <sauce> we are working on building a new app at work, and i have the opportunity to choose the linux distro <sauce> i want to use ubuntu, but that's just the kid in me talking <sauce> hey smoser, i'm gonna paste somethin in chan, forgive me <sauce> apt_sources: - source: deb http://apt.puppetlabs.com $RELEASE main dependencies <sauce> keyid: 4BD6EC30 # GPG key ID published on a key server <sauce> filename: puppetlabs.list <sauce> i can't get that to work. i troubleshooted down to the "keyid" line. if i comment it out, cloud-init works <smoser> sauce, indentation is important. <smoser> youc an see that what you're going to get is sane by just doing somethin glike: <smoser> python -c 'import yaml, pprint, sys; pprint.pprint(yaml.load(open(sys.argv[0])))' my.file <sauce> also maybe yamllint.com ? <smoser> http://paste.ubuntu.com/7218786/ <smoser> sure. <sauce> yamllint.com says the yaml is OK but outputs it vastly different than it appears in examples <sauce> lemme try python <sauce> i don't think indentation is the problem here <smoser> sauce, its not that its valid or not. <smoser> its that the result is int he right format <sauce> i hear ya <smoser> apt_sources is a list of dictionaries <sauce> i don't see how i can be messing up the indentation <sauce> its just a few spaces, everything is lined up <sauce> i deleted the line and rewrote it char by char <sauce> "filename" works with the same indentation <sauce> keyid doesn't <smoser> hm. <sauce> i know right <smoser> pastebin /var/log/cloud-init.log ? <sauce> absolutely hang on <sauce> welp there ya go: Apr 7 20:42:26 ip-10-30-4-54 [CLOUDINIT] cc_apt_update_upgrade.py[WARNING]: Source Error: deb http://apt.puppetlabs.com precise main dependencies:failed to get key from keyserver.ubuntu.com <smoser> sauce, its actuall preferable from both security and reliability perspective to insert the full key <sauce> running this again, lemme check <sauce> smoser ok i will try that <smoser> http://bazaar.launchpad.net/~cloud-init-dev/cloud-init/trunk/view/head:/doc/examples/cloud-config.txt#L120 <smoser> hte example there. <smoser> its more reliable because you dont depend on the keyserver <smoser> and int his case all you're really using it for is a object store to map <short_key_id> to <public key> <sauce> i gotcha. i pasted the key block and it validated as yaml. running it now. <sauce> many ec2 instances have died at my hand stoday <sauce> hands today <smoser> sauce, for playing, you can use lxc or kvm <smoser> lxc you can use quite performantly inside a ec2 instance <smoser> see example here: http://ubuntu-smoser.blogspot.com/2013/08/lxc-with-fast-cloning-via-overlayfs-and.html <sauce> while this is running i have another question: can i specify the order that things are run? i.e. i want to install puppetlabs repo, then use the puppet module <sauce> nice the key worked!! <sauce> and it installed in the right order, that was a 50/50 chance probably right? <smoser> well, no. :) <smoser> puppet module runs after apt_config <smoser> and that is by design <smoser> you can specify the order of things <smoser> just define the list in your user-data <smoser> http://bazaar.launchpad.net/~cloud-init-dev/cloud-init/trunk/view/head:/config/cloud.cfg <smoser> the easiest thing to do is just re-define the whole list <smoser> cloud_init_modules runs first, then cloud_config_modules, then cloud_final_modules <smoser> nd the listst there in order. <smoser> you really should take a look at that blog post, it makes testing this stuff really easy and much faste rthan waiting on instances in amazon <sauce> awesome smoser <sauce> just awesome <smoser> thanks. <sauce> why do i even need puppet, if i have cloud-init? #cloud-init 2014-04-08 <yann2> hello! I am trying to manage my /etc/hosts file in rackspace - and as soon as I set manage_etc_hosts to True, the lines for eth0, eth1 do not get created anymore <yann2> I found this bug : $dev_eth0 $fqdn $hostname from this bug report on launchpad: https://bugs.launchpad.net/cloud-init/+bug/1020695 but I m not sure, does this mean I need to change the hosts.tmpl from cloud init, at the very beginning? <lipinski> Is there any known problems to passing multiple CloudConfig resources to cloud-init via HEat? I'm trying to write two files separately via write_files, but only the second actually appears #cloud-init 2014-04-09 <smoser> harmw, hey. just thought i'd share : http://paste.ubuntu.com/7227342/ <smoser> thtas just a "test cirros" <smoser> harlowja, <smoser> 2014-04-09 19:04:16,975 - url_helper.py[DEBUG]: Calling 'http://936-429-9875/openstack/2012-08-10/meta_data.json' failed [10/-1s]: request error [(<urllib3.connectionpool.HTTPConnectionPool object at 0x7f1339863a10>, 'Connection to 936-429-9875 timed out. (connect timeout=10.0)')] <smoser> 2014-04-09 19:04:16,975 - url_helper.py[DEBUG]: [0/1] open 'http://936-429-9875/openstack/2013-04-04/meta_data.json' with {'url': 'http://936-429-9875/openstack/2013-04-04/meta_data.json', 'headers': {'User-Agent': 'Cloud-Init/0.7.5'}, 'allow_redirects': True, 'method': 'GET', 'timeout': 10.0} configuration <smoser> 2014-04-09 19:04:26,986 - url_helper.py[DEBUG]: Calling 'http://936-429-9875/openstack/2013-04-04/meta_data.json' failed [20/-1s]: request error [(<urllib3.connectionpool.HTTPConnectionPool object at 0x7f1339863c50>, 'Connection to 936-429-9875 timed out. (connect timeout=10.0)')] <harlowja> why u timing out :-P <smoser> because its not there. <smoser> the -1 is what i was annoyed at <smoser> [10/-1s] <harlowja> ya, thats odd, lol <harlowja> are u in a time machine <harlowja> will investigate <smoser> well that is maxwait <smoser> oh. <smoser> it seems like it should timup should have happened <harlowja> did ntpd jump? <harlowja> looking at code, one sec <smoser> i think there is no timeout set (or it is actually set to -1) <smoser> for that datasource <smoser> but for some reason its trying agiain <harlowja> smoser ya, its trying the provided urls, but failing after all of them don't work <harlowja> http://936-429-9875/openstack/2012-08-10/meta_data.json, http://936-429-9875/openstack/2013-04-04/meta_data.json' <harlowja> then after none of those work, it gives up <smoser> ah. i see. you're right. <harlowja> https://code.launchpad.net/~harlowja/cloud-init/no-negative-max-wait/+merge/215020 <smoser> so i guess ideally if we got a timeout <smoser> then we wouldn't try other entries. <smoser> as opposed to a 404 <harlowja> well should we :) <harlowja> might be different hostname in other urls <harlowja> right? <harlowja> bb, got a friend coming over <smoser> well it hink its urls ar ll just the MD url <smoser> but with different versions <smoser> unlikely a.) that you have a friend coming over :) , and b.) that you'd find one metadata version on the same metadata server after timing out on another i think <smoser> ie: <harlowja> lol <harlowja> he's not here yet :-P <smoser> wget http://$IP/2012-08-10/meta_data.json <harlowja> but i agree <harlowja> in this case we can abort early <harlowja> *or likely can abort early <smoser> so i'm not really opposed to the -1 <smoser> that seems not entirely unreasonable <smoser> i just didn't realize htat it was trying different urls <smoser> i thought it was re-trying, waiting for some future time when -1 seconds had passed :) <harlowja> back to the future <smoser> if i sit around and wait long enough, it will be -1 seconds from now. <harlowja> lol <harlowja> let me do the change to abort it if its all the same hostname <harlowja> bb <harlowja> smoser https://code.launchpad.net/~harlowja/cloud-init/early-abort/+merge/215036 <harlowja> think that should do it #cloud-init 2014-04-10 <cppking> hello guys , i'm a openstack SA , i don't want use dhcp-agent , then i tought i can use cloud-init to assign static IP for VM instances, can anybody show me some document about how to use it ? <cppking> Also, i don't want to use metadata server , so i have to configure cloud-init not to curl metadata-server ,how to do it? <smoser> cppking, cloud-init needs some metadata s ource <smoser> but anything recent should be able to use config drive <smoser> so configure openstack to always use config drive <smoser> and then cloud-init wont hit the MD server because it will have already found a datasource. <smoser> regarding static Ip, in general I would just say not to do that <smoser> but you maybe an manage it if your images are configured properly. #cloud-init 2014-04-13 <harmw> smoser: nice little script :) #cloud-init 2014-04-14 <natorious> is there a reason why the include.txt example in the docs is not valid? <harlowja> probably not a real reason but a mistake <natorious> apparently cloud-init attempts to parse the non-user-data linked files and barfs. <harmw> god I hate building kernels <harlowja> natorious can u open a bug, doesn't seem like a hard fix <natorious> harlowja: sure <harlowja> thx #cloud-init 2014-04-15 <smoser> harlowja, https://github.com/coreos/coreos-cloudinit <smoser> flattery <harlowja> lol <harlowja> there u go <harlowja> although not a fan of forks :-/ <smoser> in go. <smoser> i got to go <smoser> later. <harlowja> go go <harmw> forking cloudinit... <harmw> why! <harmw> harlowja_away: I think they are scared by your presence, thats keeping them to contribute and made them fork instead :p <harlowja_> harmw possibly, although maybe they just like go alot, lol <harlowja_> or they don't want to include python in there distro thingy <harlowja_> or who knows :-P <harlowja_> maybe u scared them harmw <harlowja_> lol <harlowja_> smoser http://hg.python.org/peps/rev/76d43e52d978 durn <harlowja_> does that change canonicals plan? <smoser> oh wwo. <smoser> well it makes life much nicer <harlowja_> probably less pressure for python3 then i suspect? <harlowja_> now that there is an extra 5 years <smoser> well, i think we'll mostm likely still be almost completely python-free by 2016.4 <harlowja_> except that damn cloud-init <harlowja_> lol <harlowja_> python-free? <harmw> yep, it costs like $155,95 untill april 2016 <smoser> :) <harlowja_> damn <harmw> well, thats what I was told by my local retailer <harlowja_> do i get a bulk discount? <harlowja_> 2 for 1? <harmw> dunno, have to ask him <harlowja_> so guido is your local retailer? <harlowja_> python drug dealer <harlowja_> lol <harmw> :> <harlowja_> guido give me some more of that python, for 155.95 <harlowja_> ha * harlowja_ i gotta figure out what happened to sean <harmw> lol <harlowja_> i saw him at lunch yesterday <harmw> well, he's busy in #bsdmips :p <harmw> occasionaly <harlowja_> really? <harmw> yup <harlowja_> hmmm, gonna have to track him down there then, haha <harmw> lol <harlowja_> pull him by his ear in here <harlowja_> get packages uploaded to ports <harlowja_> smoser so when u gonna do some taskflow work? <harlowja_> huh huh <harlowja_> lol #cloud-init 2014-04-16 <cppking> 0 <sonia_> Hi , need help with re-starting cloud-init without rebooting the VM <sonia_> I could achieve it by deleting /var/lib/cloud/instance/ and running cloud-init modules --mode init/config/final <sonia_> is there a way I can inject my own user-data in between to run that instead of originally provided ? #cloud-init 2014-04-17 <Sonia_> Hi , need help in cloud-init ? <kwadronaut> Sonia_: please state your question and stick around. <kwadronaut> formulating your question often already helps understanding the problem <kwadronaut> and people are not always behind their keyboards, so asking for the question, doesn't mean people stick around until it is there. <Sonia_> sorry , yesterday I put my question and got no response till today morning, hence realized if there is no one in the chat , and if time is out , question gets deleted <Sonia_> my question on cloud-init is , how we can re-run cloud-init without rebooting the VM .....and in the same process give another user-data to it. (not the one initially executed by cloud-init) <kwadronaut> ah i see it now if i scroll up...., you could add any local data in /var/lib/cloud/? <Sonia_> I was doing following steps to re-run cloud-init : <Sonia_> 1. rm -rf /var/lib/cloud/insance* <Sonia_> 2. run cloud-init init , cloud-init modules --mode init/config/final <Sonia_> these will run it with the same user-data which I supplied at the time of VM provisioning <Sonia_> but in between if I try to give my own, doenst work <harmw> you could also fetch the userdata using curl, just to make sure it got updated properly on the infra-side (beeit openstack or whatever platform you're running) <Sonia_> I used config-drive here ,and user-data gets to the VM successfully and gets executed. <Sonia_> when i re-run cloud-init , it again gets the user-data from config-drive <kwadronaut> i see a typo in your rm -rf, a t has gone missing in the instance <kwadronaut> well, if you want to use different data/source, that needs to be changed too of course? <smoser> Sonia_, you can use 'ci-tool' as a friendly-ish way to "seed" data. <smoser> http://bazaar.launchpad.net/~smoser/cloud-init/ci-tool/view/head:/ci-tool <smoser> it also has 'reset' which will clean out the state in /var/lib/cloud <smoser> Sonia_, also, if you're just wanting to quickly iterate on testing things... lxc can provide a really nice way to do that. <smoser> http://bazaar.launchpad.net/~smoser/cloud-init/ci-tool/view/head:/ci-tool <smoser> oops. <smoser> http://ubuntu-smoser.blogspot.com/2013/08/lxc-with-fast-cloning-via-overlayfs-and.html <Sonia_> thanks smoser for the link , I will certainly look at the tool <Sonia_> my use case is that , initially coud-init will work with user-data supplied during provisioning time <Sonia_> just that at later point of time , want to re-run cloud-init without rebooting the VM with a different user-data script. <Sonia_> kwadronaut , sorry for the typo in the chat , during testing , 't' is there <smoser> Sonia_, why do you want to do that ? <smoser> ci-tool would help you accomplish it, but curious. <Sonia_> kwadronaut , so if I want a different data source after the VM is provisioned, can I change it later point of time ? <Sonia_> well , I dont want VM to do all the initial configurations .....running them again may wipe out many settings done <Sonia_> smoser , shouldnt these steps work too ? <Sonia_> 1. clean out /var/lib/cloud 2. run cloud-init init 3. replace the user-data script with out own in the instance/ directory 4. run cloud-init modules --mode init/config/final <smoser> no. it probably wont work. <smoser> i'm sorry, i can't really help now. <Sonia_> no problem , I will try ci-tool <Sonia_> smoser , is there a way to change the data source also ? <smoser> sure. its configurable. <smoser> in ubuntu 'dpkg-reconfigure cloud-init' <smoser> dpkg-reconfigure or ci-toolw ill adjust etc/cloud/cloud.cfg.d/90_dpkg.cfg <Sonia_> ok , I am on RHEL <Sonia_> hope I can still change the configurations. <kwadronaut> smoser: awwww. that lxc link is promising! <smoser> kwadronaut, yeah, its nice. <smoser> on ubuntu, you can also snapshot quickly with btrfs (or lvm if you wanted). <smoser> the big feature really was the "clone hook" to allow you to pass in user-data on the clone rather than create. <sauce> smoser you the man <smoser> thanks <smoser> :) <Sonia_> smoser , I may need help with ci-tool <Sonia_> so first i ran ci-tool reset , which removed instance and instances/ directory for me. <Sonia_> post that , I am trying to seed data using the command , "ci-tool seed -s nocloud /opt/my-user-data" <Sonia_> then I run cloud init again by "ci-tool run" <Sonia_> correcting my earlier command : "ci-tool seed /opt/SJuser-data" <Sonia_> running ci-tool again doesnt execute the new user-data file , any mistake I am doing here in using the tool ? #cloud-init 2014-04-18 <Sonia> smoser, let me know once you are back in this chat. <Sonia> anyone else explored ci-tool ? <smoser> Sonia, run isn't implmeented yet :-( <smoser> but basically, yeah, you'd do the things you were doing before there. <Sonia> Hi smoser , so if i run these commands : "ci-tool reset" followed by "ci-tool seed /opt/SJuser-data" and then "cloud-init init" ...then it should work ? <smoser> cloud-init init --local <smoser> cloud-init init <smoser> cloud-init config <smoser> oops <smoser> exec cloud-init modules --mode=config <smoser> well, not exec <smoser> cloud-init modules --mode=final <Sonia> ok , let me try <Sonia> it worked , thanks Scott , I was missing this "cloud-init init -local" <Sonia> so basically without ci-tool , one cannot seed own user-data <smoser> Sonia, well you can. you just have to do it carefully. <smoser> ci-tool more selectively rm -Rf /var/lib/cloud <Sonia> right , i will try to do without ci-tool , thanks again ! #cloud-init 2014-04-21 <sauce> hey smoser <smoser> sauce, here now . <smoser> whats up? <sauce> just saying hey <sauce> cloud-init is such a joy <smoser> :) thanks. <smoser> feel free to say "but it could be better if .... " <sauce> i've been using ubuntu 12.04 LTS AMI, which comes with cloud-init pre installed <sauce> well, all i use it for is 1 thing: configuring puppet. puppet handles the rest <sauce> i probably don't need the complication of puppet in my setup but i enjoy using it #cloud-init 2014-04-23 <harlowja> any bugs are smoser fault sauce_ <harlowja> haha <harlowja> *not mine <yjiang5> smoser: hi <smoser> hi <yjiang5> smoser: I'm talking with alexpilotti on the config drive format support. alexpilotti is considering to support only iso format, but version 1 of cloud-init has only vfat format. Do you know how is the usage of cloud-init version 1? <alexpilotti> smoser: hey there! <smoser> yjiang5, i'm on a call now. can read respond in 20 minutes <yjiang5> smoser: sure. <smoser> ok. <smoser> yjiang5, alexpilotti here now. <smoser> sorry. <smoser> whats the question ? <smoser> what is "version 1" ? <smoser> the config-drive-v1 ? <smoser> i was initially more strict on what i would take in as config drive. i would only reaad a "full disk" and only if it was the last disk on the system. <smoser> and people wanted it to be more forgiving. <smoser> yjiang5, alexpilotti i would'nt concern myself with config-drive-v1. <alexpilotti> smoser: my point is that multiple configdrive fs and disk formats = more support hassles <alexpilotti> smoser: Iâd like to keep only iso9660 + CD/DVD <alexpilotti> smoser: thus deprecating vfat and raw hdd <smoser> i dont think it makes sense to say CD/DVD <smoser> its only your broken OS that cares about such things <smoser> the requirement for attaching a CD in order to pass data is annoying. <alexpilotti> smoser: so you think itâs feasible or there are still lots of images using versions of cloud-init with vfat support only or no cdrom? <smoser> i'd have to dig up data on what versions of cloud-init are where. <smoser> i really dont knwo ff the top of my head. <smoser> but i really would suggest that we not require hardware toimplement a virtual CD-rom in order to implement config drive. <alexpilotti> afaik you added cdrom in 0.7 or 0.7.1 max <alexpilotti> no idea for iso9660, that was wayy before I got started with OpenStack :-D <smoser> think about that, you're saying new hypervisors will be required to have support for shiney circles with data on them. <smoser> how does openstack create vfat at the moment? <alexpilotti> depends on a pragmatic point IMO: if the images out there w/o iso / cd are like 5%, Iâd say letâs move on <smoser> you'r suggesting lets move off of a ISO standard <alexpilotti> as they move their shiney butts and update cloud-init :-) <smoser> on to a possibly patent encumbered filesystem <alexpilotti> ISO + cd/dvd drive <smoser> oh. is see. <smoser> i say ISO + hard-disk <smoser> is the saner path. <alexpilotti> hard disk is a no go on Woindows before 2012 <smoser> and you have to fix your silly operating system that thinks iso9660 filesystems can only be found on cd-roms. <smoser> because if you go the route of "iso + cd/drive" <alexpilotti> smoser: thatâs not the point: itâs the raw hdd the issue <smoser> then you force all future hypervisors to implement CD roms <alexpilotti> windows expects to have partitions on disks <smoser> right. <smoser> so you're saying either: <alexpilotti> smoser: arenât they all supporting cdroms already? <smoser> smoser-hypervisor-2015 doesn't. <smoser> why would i implmeent a cdrom ? ide ? whats iDE ? <smoser> this is 2015! <alexpilotti> well smoser-nypervisor has plenty of time to look at the specs before release ;-) <smoser> i'm suggesting that CDroms are more arcane than filessystems on unpartitioned disks. <alexpilotti> Iâm suggesting that plenty of people use guests OSs that donât support unpartitioned disks <alexpilotti> and Iâm surely not gonna tell them that openstack is not the tool for them <smoser> i reallydont undstand it. <smoser> i admit to not understanding windows <smoser> but somehow, somewhere, you can open a device <smoser> and read data from it <alexpilotti> what we do now on 2012 is: <smoser> and then realize 'oh look, these bytes look like a filesystem!' <alexpilotti> open the device, dd out of it on a file <alexpilotti> mount the file (iso) as a loopback device <alexpilotti> read from it <smoser> why mount it as a looback ? <smoser> why "mount" at all <alexpilotti> because I need to access the content <smoser> there are many user space iso9660 filesystem implementations. <alexpilotti> as I have no native tool to extract it <alexpilotti> I need an Apache 2 friendly tool <alexpilotti> lib I mean <smoser> see. <alexpilotti> or whatever OS tool that I can bundle with cloudbase-init <smoser> now you're talking about personal problems <smoser> :) <alexpilotti> well not really ;-) <alexpilotti> cloudbase-init is Apache 2 and itâs surely not getting GPLed due to a lib <alexpilotti> anyway I didnât really find one <alexpilotti> at some point I started thinking on writing an ISO lib to extract the content <smoser> ah. <smoser> apache2 ? <smoser> how about bsdtar <smoser> that good enough ? <alexpilotti> btw 7-zip fails <alexpilotti> for some reason teh ISO images taht come out from the the iso tool used on teh server are not valid for it <smoser> libarchive13 <alexpilotti> IMO due to the very small size <alexpilotti> bsdtar? <smoser> bsdtar depends on libarchive <smoser> libarchive supports reading iso9660 <smoser> http://www.libarchive.org/ <smoser> BSD license. <alexpilotti> I tested this one, no luck <alexpilotti> but Iâm gonna do another round, they might have fixed the issues I had <alexpilotti> consider that almost 2 years passed <smoser> i'd be surprised if it didnt work. <smoser> http://gnuwin32.sourceforge.net/packages/libarchive.htm <alexpilotti> consider that 7-zip, the most popular OSS archiver on WIndows, didnât <alexpilotti> doing a build now, if this works, well, problem solved <alexpilotti> cmake is still crying for mising posix stuff, will take a bit to finish <alexpilotti> in the meaning: did you do anything with MaaSâs fast boot for WIndows thing since we talked last time? <alexpilotti> s/meaning/meantime/ <yjiang5> alexpilotti: smoser sorry, just back for lunch. <smoser> alexpilotti, i've not done anything on maas fastboot for windows, no. <yjiang5> alexpilotti: http://openstack.10931.n7.nabble.com/HDD-type-config-drive-and-Windows-VM-td32968.html give some interesting point that they want vfat so that the cloud-init can delete all contents for security reason . <alexpilotti> yjiang5_away: well, you could wipe an ISO raw hdd as well <harlowja> i've used winrar to extract iso's on windows before <harlowja> guess thats not apache2 though #cloud-init 2014-04-24 <smoser> alexpilotti, is correct. 'dd if=/dev/zero' is better than 'rm $MOUNTPOINT/*' <alexpilotti> smoser: not sure what you meant :-) <alexpilotti> smoser: in the meantime: libarchive compiled, looks promising <smoser> alexpilotti, in your response to yjiang5 <smoser> most certainly, vfat is better from a data security perspecitve <smoser> than iso. <alexpilotti> smoser: why? whatâs the difference in wiping with dd a raw hdd containing iso vs vfat? <smoser> as why would you 'rm *' when you can 'dd if=/dev/zero of=/dev/by-label/CONFIG_DRIVE' <smoser> bah <smoser> vfat is *no* better <smoser> (that was an important word to miss :) <smoser> ie, i agree with " well, you could wipe an ISO raw hdd as well" completely <smoser> which is actually an argument against CDROM <smoser> :) <smoser> unless you were going to attach a cdrw <alexpilotti> smoser: on that point, I agre e <alexpilotti> smoser: but, metadata are no secure mean <alexpilotti> so giving the message that you can secure a clear-text config drive just becuase your attacker is not fast enough is IMo absolutely wrong <alexpilotti> especially if somebody pretends to put passwords in there <alexpilotti> my 2c are that natural selection should take itâs toll in such cases ;-) <alexpilotti> anyway, if your suggestion with libarchive works fine, my concerns for not using a raw hdd disappear <alexpilotti> and we already agree on ISO, from what I got so far <smoser> alexpilotti, your attacker does not have access to your system before you have config drive wiped. <smoser> if he does, then all bets are off. <smoser> ie, if he's rooted you before rc.local is run, you are compltely SOL <smoser> i think we can manage to secure things to thath poitn :) <alexpilotti> smoser: what about faulty heat templates for example? <alexpilotti> beside that, we also donât have that advantage on Windows <smoser> you're suggesting that my system is rooted before its booted. <alexpilotti> while it boots <alexpilotti> I guess youâre going to do
{'channel': 'cloud-init', 'month': 4}