[12:42] jclift, you culd just read /var/lib/cloud/instance/user-data [12:43] it wont have any meta-data tags, but will have the user-data. [12:43] and user-data.i is mime-multipart "pre-processed" (as in has consumed #include for you if you were interested in that). [13:25] smoser: Thanks. Looked into that yesterday, but the way Rackspace does stuff, metadata doesn't get into userdata. [13:25] Figured out a way of doing it though. [13:26] smoser: Does this seem terrible? https://forge.gluster.org/glusterfs-rackspace-regression-tester/glusterfs-rackspace-regression-tester/blobs/script_refactoring/snippets/metadata_retriever.py [13:27] Saved that to git for a bit after figuring it out yesterday. Investigating potentially alternative approaches instead atm. [13:28] jclift, you're right. metadata isn't going ot get into user-data. [13:28] a feature that i've wanted to add in the past is 'cloud-init query' [13:29] either a cmdline tool, or a explicit promise of how you can load data from the cloud in a datasource agnostic way. [13:29] ie, i think the answer might just be to dump json into /run some where. [13:30] but we dont have that now. so what you have isn't horrendus. [13:30] Yeah. Could be useful. [13:30] Thanks. :) [13:30] and i doubt i would have even bothered sucggesting reading the 'system_info'['paths'] [13:30] rather than just loading /var/lib/cloud/instance/obj.pkl [13:30] Heh, was more of a "just in case", since I have 0 idea how things are structured on non CentOS. [13:31] And Gluster Community has people on all different kinds of OS's that may try it out [13:31] yeah. its better in that sense. [13:31] hm.. [13:31] so one thing you could do, is not use metadata [13:31] but just user-data. [13:31] is there a reason for meta-data ? [13:32] Yeah, there's a 2K limit for user data, and I want to keep them separate [13:32] Also, I don't know how to do the multi-part stuff programatically yet [13:32] the limit should be i think 16k, and it can be compressed. [13:32] It's definitely 2K with rackspace cloud [13:32] well, it can at least be compressed. [13:33] 2k is silly small [13:33] It's even documented as 10K in some places in source... but in practice their API rejects anything over 2K [13:33] Yeah, agreed [13:33] (and you can use '#include') [13:33] Yep [13:33] Discovered that yesterday ;) [13:33] but #include increases complexity [13:33] eg https://forge.gluster.org/glusterfs-rackspace-regression-tester/glusterfs-rackspace-regression-tester/blobs/script_refactoring/remote_centos6.cfg [13:33] Yeah [13:33] multipart is really easy though to do programatically. [13:33] you just throw whatever "parts" you want into a yaml list [13:33] Ahhh cool. [13:34] k [13:34] (and yaml == json) [13:34] Sure [13:34] I need to include a config file (eg as above), plus a script file to run afterwards (aka runcmd) [13:35] Tried listing both under an #include, but only the config file gets executed [13:35] ? [13:35] It's on my ToDo list to figure out later on today wtf is going wrong there [13:35] that should work. [13:35] oh. [13:36] it should work. [13:36] #include [13:36] http://url/1 [13:36] http://url/2 [13:36] you just have to get the "startswith" right. [13:36] ie, '#cloud-config' or '#!' [13:36] and cloud-init should do the right thing [13:37] anyway, other than being config-drive specific i dont think what you have there is horrendos [13:44] Yeah, that's what I tried yesterday. The config bit worked (first url), the 2nd didn't. But I haven't looked through the cloud-init log to figure out why, even though I could see the 2nd URL was pulled down into user-data.i (or similar name, this is from memory) [13:45] I'll look into it later on today, it's probably something simple. :) [13:45] smoser: Does this seem like a valid startswith? https://forge.gluster.org/glusterfs-rackspace-regression-tester/glusterfs-rackspace-regression-tester/blobs/script_refactoring/regression_test.sh [13:46] eg bash [13:46] Probably nothing bash specific in there, so changing to /bin/sh instead would likely work straight off [13:46] Meh, I'll investigate later. Other things to finish first. [13:46] :) [13:48] it should, yeah, '#!' should be good enough. [13:51] jclift, regarding "obvious" [13:51] maybe that /usr/bin/bash doesn't exist ? [13:52] Hmmm, completely possible [13:52] I'll check in a sec. Filling forms for other stuff atm. [13:52] also, one thing i'd suggest, is to set "cloud-init-output" [13:52] output: {all: '| tee -a /var/log/cloud-init-output.log'} [13:52] that is the default in trunk now, but is extremely useful. [13:53] that way any output of subprocesses of cloud-init goes there. [14:00] Useful tip. I'll look into it shortly. :) === harlowja_away is now known as harlowja [18:11] smoser: Interestingly, there's no flag file written by kernel updates for CentOS/RHEL/etc. [18:11] smoser: However, there's a yum "reboot_suggested" flag that gets written to yum metadata [18:11] Yum is written in Python [18:12] And various parts of yum can be imported for use in python [18:12] There's an example of something called PackageKit using it here: https://gitorious.org/packagekit/packagekit/source/945faa959f00e27d419517116c37e960d6093f56:backends/yum/yumBackend.py [18:13] In theory, it might be possible to just do something like "from yum.update_md import UpdateMetadata", and get it working from there [18:15] * jclift will experiment a bit, but my Python is very noobie level so you might be able to just glance at it and tell what to do. ;) [19:42] So, after speaking with the guys in the #yum channel, it looks like the reboot_suggested flag isn't that widely used. So, may not actually be reliable. [19:43] They suggested just checking the version of the running kernel vs the latest installed one, and rebooting if they're different [19:43] I'll see if I can whip up a suitable patch to do that in a bit. Kind of brain faded atm tho :/ [20:04] jclift, that sounds fine. [20:05] its non-trivial to determine "latest kernel" though. [20:05] i dont know how one is supposed to do that. you'll probably have to use yum to compare versions. [20:05] They pointed me towards a recent yum command addition that does it. [20:06] smoser: I'll hunt that down and see if it's feasible to copy. Yum being written in python too, etc. [20:06] May not be tonight though. Kind of needing a break atm. :) [20:07] oh, its not reasnoable to copy. [20:07] you'd want to use the library. iirc rpm's "which version is greater" is massive spaghetti. [20:17] Damn. This is apparently a new yum command, in recent Fedoras. I haven't yet looked into it. [20:17] You could be completely right thogh. [20:17] Guess I'll be finding out soon. ;) === harlowja is now known as harlowja_away === harlowja_away is now known as harlowja