[01:46] <smoser> harmw, well, some news. seems busted in my 0.3.2~pre1 also.
[01:50] <smoser> hm.. and interesting. it seems busted in 0.3.1 also. the partition table does get grown.
[11:34] <harmw> smoser: I just filed https://bugs.launchpad.net/cloud-init/+bug/1261710
[11:34] <harmw> I'll see if I can work on that tonight
[11:34] <harmw> annoying
[11:35] <harmw> hm, and why didn't I file that against cirros :|
[11:37] <harmw> there, changed it
[13:39] <smoser> harmw, thanks.  i can't figure it out. i think something is killing the resize2fs process after it starts.
[13:40] <smoser> i changed 'resize2fs' to 'sleep 5' and it seems to die also.  also tried putting the content of the 'sh -c' in its own program. that didnt work either.
[13:40] <smoser> the one thing that does work is removing the '&'
[13:40] <smoser> ie, not backgrounding.
[13:40] <smoser> i'll put this in the bug.
[14:03] <harmw> great, nice
[14:04] <harmw> (-1 for that silly typo btw)
[15:42] <smoser> harmw, it seems that using start-stop-daemon does work. but i couldn't get start-stop-daemon to sanely call a 'sh' -c program
[15:42] <smoser> so had to put it in a different program
[15:43] <harmw> ah great
[16:44] <smoser> harmw, want to take the fix for a spin ?
[16:44] <smoser> get cirros trunk (bzr branch lp:cirros)
[16:44] <smoser> then
[16:45] <smoser> tar -C src -cvf - sbin/resize-filesystem etc/init.d/resizefs lib/cirros/shlib | ssh cirros@$IP 'sudo tar -C / -xvf - && sudo reboot'
[16:46] <smoser> seems to work for me, and when its done you get a nice message like:
[16:46] <smoser> /dev/root resized successfully [took 43.12s]
[19:07] <harmw> smoser: ill give it a go in a few minutes
[19:16] <smoser> harmw, k. good. i dont really know how i feel about "fixing" it. given the 45 seconds it took to run.
[19:16] <smoser> i'm apt to put this in and then turn it off by default.
[19:22] <harmw> it kinda goes straight into the whole cirros philosophy
[19:23] <harmw> any thoughts on how to enable it if the default where to have it disabled?
[19:23] <harmw> [19:23] <harmw> +1 for a lightspeed cloud :>
[19:27] <harmw> [19:27] <harmw> and that was after the reboot + resizefs stuff
[19:28] <harmw> # grep resize e1ba8f11-097f-4bc1-bf9b-475710fee5ef/console.log 
[19:28] <harmw> wheeljack login: /dev/root resized successfully [took 92.04s]
[19:41] <smoser> one thought on how to enable it if it were disabled is via file injection (through config drive or openstack api)
[19:41] <smoser> i think it would work.
[19:42] <smoser> if /etc/init.d/resizefs read /etc/default/resizefs.conf
[19:49] <harmw> ./sem/instance.i-00000052.userdata
[19:49] <harmw> ./sem/instance.i-00000052.cirros-apply-net
[19:49] <harmw> ./sem/once.once.resize-rootfs
[19:49] <harmw> ./sem/instance.i-00000052.check-version
[19:50] <harmw> isn't that missing the tiny touch of consistency? :)
[19:52] <harmw> can't it be specified in user-data? a believe there already is a module to allow for this to happen
[19:53] <harmw> smoser: perhaps have the resizefs script read /var/run/cirros/datasource/data/user-data to make the decision to run/start
[19:53] <smoser> consistency ?
[19:54] <smoser> well, 'instance' is that this is 'per-instance', and then the second portion is the instance id. and then the key.
[19:54] <smoser> for 'once', there is no useful second portion
[19:54] <smoser> so i just reused the sring 'once'
[19:54] <smoser> ie, the resize will only run once, ever.
[19:54] <smoser> it could be 'per-instance', and probably woudl work. but i really dont think people are "rebundling" cirros :)
[19:55] <smoser> we could have it specified as user-data, yes. but at the moment cirros doesn't support any sort of "cloud-config" user data.
[19:55] <smoser> it only supports '#!'
[19:55] <smoser> if i had some cloud-config analog then it'd be perfect. but thats not there yet.
[19:56] <smoser> the inject-files in the openstack api "should work" as it is right now i think. 
[19:56] <smoser> with no other features needed from cirros except having the rc.d script source (if it exists) that file.
[19:56] <harmw> true
[19:56] <smoser> i agree that cloud-config like function is better long term goal
[19:56] <harmw> indeed
[19:56] <smoser> but i'd wan to have this enable-able in 0.3.2 and want that "real soon now"
[19:57] <harmw> though having it work based on the presence of a certain file is cool enough for now :)
[19:57] <smoser> well, i'd have it source the file
[19:57] <smoser> if present
[19:57] <smoser> ie, so the file could have:
[19:57] <smoser> enabled=0
[19:57] <smoser> background=0
[19:57] <smoser> or something to that affect.
[19:57] <smoser> or mabye just 
[19:58] <harmw> isn't it easier to just check if a (0byte) file exists?
[19:58] <smoser> mode=(foreground|disabled|background)
[19:58] <smoser> existence doesn't allow  me to do foreground and background
[19:58] <smoser> and i really do thikn the backgrounding is weird
[19:58] <harmw> right on that
[19:58] <smoser> cause for race conditions
[20:10] <smoser> harmw, feel free to give this a try
[20:10] <smoser> http://paste.ubuntu.com/6590740/
[20:10] <smoser> bah. bad syntax.
[20:10] <harmw> darn, I was just busy on something myself :)
[20:11] <smoser> http://paste.ubuntu.com/6590744/
[20:11] <smoser> harmw, sorry to get in your way, i'd love for you to particpate in cirros developement :)
[20:11] <harmw> and I should have openstack create the /etc/default/resizefs file
[20:11] <harmw> haha np :)
[20:12] <smoser> yeah, you should be able to do somethin glike:
[20:13] <smoser> nova boot --file /etc/default/resizefs=my.resizefs.txt
[20:14] <harmw> yea
[20:19] <harmw> hm, seems my cloud is not very fond of inserting files
[20:19] <harmw> like this: /data/openstack/nova//instances/b0471e49-094c-4eed-b8f0-7a979ed35957/disk: No such file or directory
[20:21] <harmw> NovaException: Error mounting /data/openstack/nova//instances/b0471e49-094c-4eed-b8f0-7a979ed35957/disk with libguestfs
[20:22] <smoser> harmw, i think you can turn that off. 
[20:22] <smoser> we dont need the host to insert it
[20:22] <smoser> (i would never find that an acceptable solution)
[20:23] <smoser> there is a way where the "inserted files" just appear in the config drive
[20:23] <smoser> and then cirros reads them and *it* inserts them.
[20:23] <smoser> harlowja, do you know how to set that ?
[20:23] <harlowja> hmmm
[20:23]  * smoser goes to try to remember if cloud-init supports that in config drive. i thin it does
[20:23] <harmw> well, i don't use config drive atm and enabling it causes the other vm's to fail on boot iirc
[20:24] <smoser> harmw, well, you dont need config drive. cirros should read it from the MD also
[20:24] <smoser> (the files can be inserted there too)
[20:24] <harmw> yea, i thought so
[20:24] <harmw> was expecting that as well
[20:24] <smoser> but clearly if you're trying to insert config for ifconfig eth0' then its probably not going to work :)
[20:24] <harmw> hehe
[20:25] <smoser> harlowja needs to write a proper cloud-init DataSourceOpenstack
[20:25] <harlowja> :)
[20:25] <smoser> that reads from the openstck MD. we dont really ahve that now. only could reaad those files from the config drive.
[20:25] <harlowja> one sec, let me see what the option is
[20:26] <smoser> harlowja, that really is something i'd like for 14.04
[20:27] <harlowja> hmmmm
[20:27] <smoser> proper oepnstack metadata service datasource (rather than just riding on ec2)
[20:29] <harlowja> agreed
[20:37] <harmw> smoser: does cirros read metadata? since then we could use a metadata key+value instead of inserting a file
[20:38] <smoser> harmw, i think it does read it in some sense.
[20:38] <smoser> in that it would write keys to files in the datadir
[20:38] <smoser> so it could pretty easiliy use that
[20:39] <smoser> the thing i dont like about that is that i dont know that i want to support it going forward
[20:39] <smoser> i can trivially keep support for /etc/default/.... injection
[20:41] <harlowja> harlowja i think if u make sure all 'inject_partition=0', 'inject_key=0' nova.conf values are off that will be step 1
[20:42] <harlowja> apparently this is on by default
[20:42] <harlowja> inject_key=true
[20:42] <harlowja> https://github.com/openstack/nova/blob/master/etc/nova/nova.conf.sample#L2510
[20:43] <harlowja> but u are hitting this code
[20:43] <harlowja> https://github.com/openstack/nova/blob/master/nova/virt/libvirt/driver.py#L2570
[20:43] <harlowja> "If we're not using config_drive, inject into root fs"
[20:43] <harlowja> :(
[20:43] <harlowja> harmw i think u can also use the following
[20:43] <harlowja> https://github.com/openstack/nova/blob/master/nova/virt/libvirt/driver.py#L2544
[20:43] <harlowja> inject_files and CONF.libvirt.inject_partition != -2
[20:44] <harlowja> so make inject_partition=-2
[20:44] <harlowja> weirddd
[20:44] <harlowja> ha
[20:44] <harlowja> # The partition to inject to : -2 => disable, -1 => inspect
[20:44] <harlowja> # (libguestfs only), 0 => not partitioned, >0 => partition
[20:44] <harlowja> # number (integer value)
[20:44] <harlowja> #inject_partition=1
[20:44] <harlowja> by default 1
[20:44] <harlowja> crazy
[20:45] <harmw> hehe
[20:45] <smoser> some day the default will be -2
[20:46] <harlowja> ya, i hope so
[20:46] <harmw> so change to -2 and then nova boot --file should work just fine
[20:47] <harlowja> harmw using config drive or nothing at all?
[20:47] <harmw> nope, just metadata
[20:48] <harmw> no configdrive here
[20:48] <harlowja> so sure, then if smoser is correct and cirros understands special openstack metadata then u should be good to go
[20:49] <harlowja> never know with that smoser  guy, ha
[20:49] <harmw> time to find out :)
[20:50] <harlowja> :)
[20:50] <harlowja> but ya, i should (or should get someone from y!) to write a best-impl of an openstack metadata/config-drive thing
[20:50] <harlowja> *datasource thing
[20:50] <harlowja> as smoser  suggested
[20:53] <smoser> uh oh. 
[20:53] <smoser> it imight only do that from config-drive (not MD). hmm.
[20:53] <smoser> suck. i don tthink cirros has proper openstack metadata source either.
[20:54] <smoser> so harmw that isn't going to work :-(
[20:56] <harlowja> hmmm
[20:58] <harmw> indeed, it didn't inject the file
[20:59] <harmw> uhm, why doesn't it read the stuff from user-data again?
[21:01] <smoser> it should execute user-data
[21:01] <smoser> if it starts with '#!'
[21:01] <smoser> but thats its only consumption of user-data at the moment.
[21:01] <smoser> and that runs after resize would have run
[21:01] <smoser> but if you want, from that '#!' you could just *run* '/sbin/resize-filesystem /dev/root'
[21:01] <smoser> at the beginning.
[21:04] <harmw> nah, thats far to easy :)
[21:18] <harlowja> smoser a start at this, http://paste.openstack.org/show/55206/
[21:19] <smoser> harmw, you think thats a acceptable work around for now ?
[21:19] <smoser> and then when we get either a true file insertion or "cirros-config" format in user-data we'll allow enabling it that way.
[21:20] <smoser> (in the mean time the user can enable it by actually modifying the image, or by config-drive still should work)
[21:20] <smoser> harlowja, woohoo
[21:21] <harmw> smoser: yes, probably good enough for now
[21:22] <harmw> though ultimately reading from user-data would be the best choice 
[21:23] <smoser> yeah. i agree.
[21:23] <smoser> https://bugs.launchpad.net/cirros/+bug/1232239
[21:23] <smoser> is a start at that.
[21:23] <smoser> ie, there is code there to read  mime-multipart
[21:23] <smoser> and since i have a json reader, we can pretty easily support a "cloud-config-archive" like thing in a similar fashion
[21:25] <harmw> nice
[21:26] <harmw> how does this behave when I've put yaml in user-data?
[21:27] <smoser> probably barf.
[21:27] <smoser> i only have a json parser
[21:28] <smoser> and i dont plan on a proper yaml one.
[21:28] <smoser> its easy enough to convert yaml to json before passing to cirros
[21:28] <smoser> and hard (without C programming) in cirros to write a yaml parser.
[21:29] <harmw> you mean I should feed json user-data to nova on instance boot, or have cirros convert user-data to json upon loading/booting?
[21:31] <smoser> 2 things here (kind of unrelated)
[21:31] <smoser> a.) want to have cirros support "multi-part" user-data as input.
[21:32] <smoser>  a.1) mime-multipart (as seen in that bug with the awk parser)
[21:32] <smoser>  a.2) cloud-config-archive like multipart (cloud-config-archive is a cloud-init thing that basically just allows you to make an "archive" of parts in yaml rather than mime)
[21:33] <smoser> for a.2, cirros would not support that being yaml, but instead just json. but same basic format.
[21:33] <smoser> b.) some of those parts could be "cirros-config" which would be a json config format similar to "cloud-config"
[21:33] <smoser> with the same caveat of not supporting yaml, but only json
[21:34] <smoser> in the future if somehow i got a small enough yaml parser, we could just support yaml in both of those places.
[21:34] <harmw> ok
[21:35] <harmw> would've been easier to just put cloud-init in cirros :p
[21:42] <smoser> $ apt-cache show python2.7-minimal | grep -i size
[21:42] <smoser> Installed-Size: 3399
[21:42] <smoser> Size: 1187530
[21:43] <harmw> ye yea, bit to large
[21:43] <smoser> so 3.XMB for python-minimal.
[21:43] <smoser> i'm sure you could get stuff smaller
[21:44] <smoser> but all of cirros is ~ 8M (the disk images are bigger because of filesystem overhead and the fact that the disk1.img file actually has *2* copies of cirros in it)
[21:45] <smoser> oh. wait. no it doesnt.
[21:52] <harlowja> smoser i'll try to work on improving that
[21:53] <smoser> python ?
[21:53] <harlowja> *openstackdatasource, ha
[21:53] <harlowja> not python, ha
[21:53] <harlowja> smoser u fix python, lol
[21:55] <smoser> i have to admit, i kind of like programming in awk and busybox sh
[21:55] <smoser> having python in cirros would just be no fun.
[21:55] <harmw> hehe
[21:59] <harmw> smoser: is multipart realy required straight away? or would a simpler implementation be fine as well, for starters. To just have some json user-data beeing applied. Allowing more input in a second phase, where you implement multipart.
[21:59] <harmw> having it read user-data and apply any json found inside would be a nice start I'd guess
[22:00] <harmw> however, given there already is a multipart parser...
[22:01] <harmw> shoot, I'll just go back to do some work on the fbsd module - tomorrow
[22:02] <smoser> harmw, i dont understand what yoiure asking really.
[22:02] <smoser> i dont wanto to just overload userdata. like grepping through it to see if there is a key in it.
[22:04] <harmw> agreed
[22:09] <smoser> harmw, thanks for all your input. i will try to get a re-build of cirros and a proper "0.3.2~pre2" out.
[22:10] <smoser> (proper meaning actually available in simplestreams data and without 'local
[22:10] <smoser>  and tagged and such)
[22:10] <smoser> before i leave for holiday (friday).
[22:10] <harmw> ah excellent
[22:10] <smoser> i just pushed the configuration change.
[22:10] <harmw> ill take a look tomorrow