=== zz_natorious is now known as natorious === natorious is now known as zz_natorious === tmclaugh[work]_ is now known as tmclaugh[work] [13:44] smoser: thx for getting me back in, my instance here got rebooted this morning and I hadn't saved my latest irssi config yet [13:45] cloud-init would need a resolvconf handler. [13:45] the other thing you could do ... [13:46] is just remove the link before publishing the image [13:46] if /etc/resolv.conf is not a link into /run [13:46] then resolvconf will not do anything [13:46] you might be able to apply that change in a boothook too [13:46] but it might be racy [13:49] smoser: If you could have a look at https://code.launchpad.net/~daniel-thewatkins/cloud-init/lp1464253/+merge/261849, it would be much appreciated. [13:49] Odd_Bloke, i will i cant do it now, but 70 minutes [13:50] Ack. [13:58] harlowja: https://review.openstack.org/#/c/191081/ is my project-config change. [14:01] claudiupopa: I'm looking at https://github.com/stackforge/cloud-init/blob/master/cloudinit/tests/osys/test_base.py#L22-L42; does platform.linux_distribution really return 'Windows' if called on Windows? [14:03] harlowja: We need to improve coverage (because otherwise we won't be able to land any changes once that project-config change lands). Do you want to/are you looking at improving test coverage of url_helper, or is that something I could do? [14:04] That's a bit misleading, but in fact platform.system will be called in that condition. [14:05] claudiupopa: Then I think we have a bit of a faulty test. :) [14:05] Yeah, it is, thanks for noticing. [14:05] :) [14:09] Claudiu Popa proposed stackforge/cloud-init: Fix a faulty test https://review.openstack.org/191085 [14:10] Odd_Bloke: ^ here's the patch. [14:13] +1'd. [14:14] thanks! will need another +2 of course ;-) [14:17] WTB +2 rights. :p [14:29] smoser, Odd_Bloke heya fellas, quick question ... can cloud-init log without rsyslog? like to a local file? [14:36] Odd_Bloke: would it make sense if url_helper.wait_any_url would return a tuple of url and response? [14:37] I have an use case where I need the backoff logic, but I also need the response, which isn't provided. [14:38] I don't see why not. [14:38] harlowja: ^ [14:51] Claudiu Popa proposed stackforge/cloud-init: Change the API of wait_any_url to return a tuple of url and response https://review.openstack.org/191100 [14:59] I see two different types of license header on files; which should I be using? [15:01] The less verbose one. The other should be replaced. [15:02] Cool. [15:02] Thanks. :) [15:06] rangerpb, yes. [15:06] rangerpb look in etc/cloud/cloud.cfg.d/05_logging.conf [15:06] its *supposed* to figure out whether or not it can use rsyslog and not use it if it cant. [15:06] but that doesn't work so terribly well [15:07] short answer for you though... comment out the line about syslog. and it will just do what you want [15:07] - [ *log_base, *log_syslog ] [15:10] ok roger that thanks smoser [15:48] Merged stackforge/cloud-init: Fix a faulty test https://review.openstack.org/191085 [16:11] Daniel Watkins proposed stackforge/cloud-init: Don't try to generate autodoc for Windows modules. https://review.openstack.org/191137 [16:13] Daniel Watkins proposed stackforge/cloud-init: Clean up stale auto-generated autodoc files. https://review.openstack.org/191139 [16:36] Daniel Watkins proposed stackforge/cloud-init: Basic implementation of a reporting framework. https://review.openstack.org/191144 [16:37] smoser: ^ is a basic outline of the reporting framework. === zz_natorious is now known as natorious [16:44] Daniel Watkins proposed stackforge/cloud-init: Fail the doc build if we have any warnings. https://review.openstack.org/191149 [16:46] Odd_Bloke, i'd realy rather not use wget. [16:46] that just seems like failure [16:48] but that bug just plain sucks [16:48] smoser: CloudStack use wget for their equivalent functionality, so they are only every going to test with wget. [16:49] smoser: Using anything else is just asking for regressions in the future. [16:49] not really. [16:49] saying "our http endpoint might arbitrarily not be an http endpoint" is asking for regressions [16:50] i suspect they're not testing with all versions of wget from 10.04 to 16.04 and also those found on linux-distro-X version Y [16:50] Sure, but they are _definitely_ not testing with any version of cloud-init. :p [16:52] i admit that i'd probably be as opposed to your implementation of a solution in any way. [16:52] I don't disagree that CloudStack are asking for regressions (and that the way they implemented this to begin with is embarassingly terrible). [16:52] But they are and they did and it's deployed in places now. [16:52] but it was broken in one specific way [16:52] right? [16:53] and now its a sane response ? [16:53] Yeah. [16:53] (For now ¬.¬) [16:53] ok. so 2 paths [16:54] a.) your wget path.b [16:54] b.) use url_helper [16:54] and catch exception and fallback to either old code or wget. [16:55] smoser: With (b), we'd have to hit the endpoint more than once. [16:55] and in either path, with wget, use long names in command line options rather than short. [16:55] wget --quiet --timeout= [16:55] ... [16:55] we only hit it more than once when its broken. [16:56] oh yeah, and with wget alos, do not use shell=True. [16:56] i dont know why you did.. i dont think you gain anthing from it other than the possibility of shell expansion on funny domu_requst input [16:57] It was breaking up DomU_Request in a way that was breaking everything. [16:57] And I was sick of CloudStack and their shitty implementation, so just did it the fastest way I could. ¬.¬ [16:57] _do_request(domu_request="foo\"; rm -Rf /;") [16:57] If we merge code that does that, we almost certainly have bigger problems. :p [16:58] But: point taken. [16:58] I'll revisit this on Monday. [16:58] if we merge code that does what ? [16:59] if you wantto put in the wget... i'm fine with that for now. i think its not the greatest. [16:59] but do want no shell=True and use long command line options. [16:59] smoser: If we merge code that calls _do_request with those parameters. [17:00] Yep, I'll fix that on Monday. [17:00] I'm EOD'ing now. [17:00] smoser: Have a good weekend. :) [17:00] k [17:33] Daniel Watkins proposed stackforge/cloud-init: Fail the doc build if we have any warnings. https://review.openstack.org/191149 [17:34] Daniel Watkins proposed stackforge/cloud-init: Basic implementation of a reporting framework. https://review.openstack.org/191144 [17:35] Odd_Bloke can also include https://pypi.python.org/pypi/doc8 if u want [17:35] another tool i helped mak [17:35] can be used for more extensive testing of doc things [17:36] harlowja: Nice, I'll have a look at that. :) [17:36] ex: https://github.com/openstack/taskflow/blob/master/tox.ini#L65 [17:36] using it to blow-up the py27 testing env, if it has some issues [17:42] Daniel Watkins proposed stackforge/cloud-init: Add doc8 checks to docs tox target. https://review.openstack.org/191162 [17:46] Odd_Bloke your reporting framework i wonder if it could benefit from http://docs.openstack.org/developer/taskflow/types.html#taskflow.types.notifier.Notifier [17:46] ^ anyone one of my other project [17:47] could split that off into its own little library or something [17:47] your's looks slightly similarish [17:49] https://pypi.python.org/pypi/blinker/ is also something similarish === natorious is now known as zz_natorious === zz_natorious is now known as natorious === natorious is now known as zz_natorious === zz_natorious is now known as natorious === natorious is now known as zz_natorious