=== Guest69465 is now known as mfisch === mfisch is now known as Guest67039 === harlowja is now known as harlowja_away [10:59] smoser: ping [13:00] harmw, here. whats up? [13:00] I'm working on some code to get the proper fbsd interfacename [13:01] should be ready soon [13:01] can you change the instance hostname in AWS? [13:28] btw, don't nuke that instance since I'm debugging on it :p [13:35] harmw, you can't change a hostname in aws [13:35] i can give you another instance if that'd help. [13:38] hmk [13:38] so ip-10-0-0-158 is the current hostname? [13:38] nah, I think that'll work [13:43] harmw, wlel, http://169.254.169.254/latest/meta-data/local-hostname would tell you [13:43] but you seem to have no sane tools on that system (curl or wget) [13:43] fetch :) [13:43] i remember a time before ubuntu whne i liked to play with sharp pointy objects. [13:43] :> [13:43] rather than things that worked ;) [13:50] smoser: https://code.launchpad.net/~harmw/cloud-init/amazon-fbsd-fixes/+merge/237595 [13:51] come to think of it, it's only relevant for configdrive setups since that's the only case where the nic is even used :p [13:51] hooray! [13:52] but nonetheless, it's always better then just using 'some' hardcoded name :p [13:53] harmw, oh, cause it reads that in interfaces. [13:53] yeah, thats all slated to change [13:53] where we'll get info on the mac and find it that way [13:54] yea, it should indeed be some higherlevel solution [13:54] but for now this'll do the trick [13:54] if only hiren_ would wake up [13:54] since he actually uses configdrive [13:55] harmw, the only coments i have on that merge proposal is that you should in general re-use 're.' [13:55] with re.compile [13:56] but its fine. [13:56] ie: [13:56] for line in ... [13:56] m = re.match('^\w+', line) [13:56] is going to re-compile that regex [13:56] where it could have used a cached version [14:03] so -always- compiled regexes? [14:04] ah, it's inside that for loop [14:04] damn [14:05] i dont know really about a good rule for when to do it and hwen not to [14:05] but clearly in that case on the loop, you're wasting cpu. [14:06] dont worry about it. [14:06] well in this case I honestly overlooked my own loop [14:06] stupid though [14:07] else I would've used a compiled regex, since you told that on some other review a while back :) [14:37] is this the right place to discuss cloud-init bugs? [14:38] jaxxstorm: yes [14:38] bring it on [14:39] I'm using the phone_home module and it's failing because of SSL, but my URL is http:// and on port 80 [14:39] output: [14:40] https://gist.github.com/jaxxstorm/0b2f7b20718bcb462fc6 [14:40] could you use paste.ubuntu.com or something please :) [14:41] anyway, it says this is the url: http://foreman.hostname.com80/unattended/ [14:41] yeah I've redacted the URL [14:41] but basically it's http://foreman.companyurl.com:80/unattended [14:41] ah, and that 80 is deliberatly without prepending :? [14:41] yeah that comes from the foreman [14:42] UrlError: [Errno 1] _ssl.c:492: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify faile [14:42] you're using a selfsigned cert? [14:43] well my foreman instance does have a self signed cert [14:43] exactly [14:43] but it's also available on port 80 without SSL for callbacks [14:43] so why would it even attempt to use SSL on port 80 with http? [14:43] isn't foreman just redirecting (forcing) to use ssl? [14:44] c-i won't just start SSL by itself [14:45] if I call the exact same URL with curl it doesn't use SSL [14:45] and doesn't redirect [14:47] weird [14:48] yeah [14:48] in any case, is there a way to have it not verify the SSL cert? [14:48] that's something smoser would know, though I think it is possible to import a custom CA [14:48] which would make c-i accept the certificate aswell [14:49] yeah I saw that module and I may go dow that route if needed [14:49] it would be the most elegant solution :) [14:52] smoser: could you accept the merger? [14:55] merged. thanks. [14:55] sweeeet [14:56] okay, never mind, sorry guys [14:56] < Status: 302 Found [14:56] getting redirected to https [14:56] :( [14:56] I told you :P [14:56] ah, you forgot curl -l [14:56] *probably [14:56] or actualy.. ah nvm [14:57] I guess I can add the CA cert, but that'll be a pain [14:59] jaxxstorm, you should probably be able to insert the ca cert in cloudconfig [15:00] yeah I think I can [15:00] does it rely on a package being present for CentOS? [15:00] how does it add the cert? [15:00] I want to make sure all the required packages are installed before I attempt it [15:00] i think it shoudl all be contained in cloud-init (and usage of python-requests) [15:01] cloudinit/config/cc_ca_certs.py: distros = ['ubuntu', 'debian'] [15:01] would that mean it's not supported on RHEL? [15:03] it seems that way... [15:03] :( [15:04] jaxxstorm: open up a bugreport, this is something worth adding I'd say [15:04] would love to, where do I go? [15:04] https://bugs.launchpad.net/cloud-init [15:06] done [15:06] https://bugs.launchpad.net/cloud-init/+bug/1378874 [15:10] that module is currently using some Debian-specific stuff, but if the logic applies to RHEL it should be fairly easy to get it to support that [15:11] thanks :) [15:12] I'm cheating anyway [15:12] runcmd: /usr/bin/curl -k <%= foreman_url('built') %> [15:13] btw, the app is amazing, has really helped my provisioning process, so thanks! [15:14] if foreman is redirecting you, you need a curl -L to follow the 30x [15:18] ah, v. true [15:36] jaxxstorm, hm.. i dont knwo. i'm not sure how specific that would be. [15:55] harmw, harlowja_away https://github.com/cloud-init [15:55] now to get source there. [16:54] why? [16:54] smoser: what's wrong with LP? [17:08] btw, you may nuke that instance now [17:10] harmw, ok. i'll kill instance === Guest67039 is now known as mfisch [17:10] nothing wrong with lp, but want to have something on github for people to find it, and or to contribute. there. some people just more comfortable there. [17:11] sounds legit === mfisch is now known as Guest72593 [17:12] smoser: is the copy in git or bzr going to be canonical? [17:12] I guess I could pick a better word [17:13] :p [17:13] I mean lowercase "c" canonical not uppercase "C" ubuntu [17:13] :P [17:14] :) [17:14] JayF, i dont know. not thought of that yet. [17:14] That's the most important thing to know, isn't it? [17:15] split brain problem and all that [17:18] yeah, its clearly important to know. [17:39] +1 for keeping LP master :p [17:50] +90001 for making it github [17:50] you make it github and all the sudden you'll see more contributions from me [17:50] that's for sure === harlowja_away is now known as harlowja [18:15] holy crap, github, woah [18:15] although the PR mechanism sux still [18:15] *imho [18:52] On, the bright side, it means not having to use bzr. [18:53] heh [18:53] only the maintainer(s) have to take care of keeping everything in sync [18:55] Yep [18:57] for git-git you can use hooks or send a message to github asking to mirror it (which means they'll pull in changes twice a day or so and it's more obvious for users that it's not the canonical one) [18:58] there's both bzr-git and git-bzr fwiw. besides that, i dislike both platforms. [18:58] (if we're shedding bikes, i'm taking part and now i'll run again) [19:02] I paint my bikeshed git of any kind [19:02] smoser: another option would be to put cloud-init in stackforge/ and use openstack processes [19:03] smoser: I have no idea how you'd feel about that, but you'd get some quantity of testing infra for "free" [19:03] smoser: plus you'd be more tightly integrated with one of your biggest users [19:41] stackforge sounds cool [19:49] JayF, this is true, and i've considered that before. but i'm not tied to openstack, and do not really want to be. [19:51] i'd have to lean towards not also, i've got about 3 stackforge projects and an oslo one, so i've been through it, i'm not sure its buying much for cloud-init that github + travis couldn't buy (i do personally like the gerrit that openstack has over pull requests, but this is a managable dislike) [19:52] although the stackforge one could have an interesting connection into the rest of openstack if that stackforge repo somehow got plugged into the image-building === Guest72593 is now known as mfisch [19:53] would be nice to have a new image-built when cloud-init review happens, and tested accordingly, thats like the true functional test that would be nice to have automated === mfisch is now known as Guest6813 [19:54] but if said thing doesn't exist ( JayF might know more about the image building stuffs that could be possible) then i'm not sure it matters, github, stackforge... === Guest6813 is now known as mfisch [19:55] i've had https://github.com/yahoo/Zake working with travis and for a project without ton of activity its worked out ok [20:02] harlowja, i want an easy "patch image with cloud-init" for sure. [20:02] but i dont think building the image from scratch is useful. [20:02] well scratch or whatever other mechanism that i believe the tripleo folks/ironic people are using [20:02] and 'mount-image-callback' or libguestfs makes patching it in trivial. [20:02] sure [20:03] http://ubuntu-smoser.blogspot.com/2014/08/mount-image-callback-easily-modify.html [20:03] be nice to have whatever that is part of the review 'check' pipeline [20:03] this is ture, but openstack would specifically be better off using a "stable" cloud-init for testing (ie, grabbing latest ubuntu image). [20:03] and probably even latest image of stable release. [20:04] :) [20:04] so the oslo program has done something sorta neat for that [20:04] it has a check pipeline that checks the existing (stable) and from source [20:04] so u can get early warnings from the source 'check' and still not affect users of 'stable' [20:05] ex @ https://review.openstack.org/#/c/126791/ (the gate-*-src-taskflow are testing this source version) [20:05] while afaik the other users of taskflow are not using that source version (but the last release thats avaialble) [20:07] so this could do something similar [20:14] hm.. [20:14] so that would seem like a 'nice to have' [20:14] but stackforge would not seem like a requirement for that. [20:15] in that they have "sources" that live other places. [20:15] such as cloud-images.ubuntu.com or fedora.mirror.org/foo [21:03] smoser agreed [21:04] its not a requirement, but could be simpler to make happen (emphasis on could) [21:04] since we already have people here in this channel that work with openstack and the infra there [21:26] openstack? what's that [21:26] sounds scary [21:32] I suspect if you moved cloud-init into stackforge/ you could easily convince people to help you get some of this testing working [21:32] because of the large number of crossover between openstack devs/opers and cloud-init users [21:32] I'm not saying *I* would (I owe this project other work already), but I'm saying people would :) === shardy is now known as shardy_z [21:44] JayF so that means u would? [21:44] lol