=== kadams54-away is now known as kadams54 === kadams54 is now known as kadams54-away [04:37] cann't bootstap in lxc environments | http://askubuntu.com/q/589150 [11:17] Where does juju store its cache | http://askubuntu.com/q/589242 [11:28] dosaboy, gnuoy: if you have time - https://code.launchpad.net/~openstack-charmers/charm-helpers/0mq/+merge/238855 [11:28] addes redis support for zeromq [11:30] looking [11:32] gnuoy, its fairly isolated [11:33] jamespage, approved [11:33] gnuoy, ta [11:34] I'll merge it === Murali_ is now known as Murali === kadams54-away is now known as kadams54 === natefinch_ is now known as natefinch [15:14] cool [15:16] marcoceppi: I just got an email about failed test results pointing to http://reports.vapour.ws/charm-tests/charm-bundle-test-11056-results, but the page is empty of information. [15:23] http://reports.vapour.ws/charm-test-details/charm-bundle-test-11056-results looks like the correct URL [15:35] hazmat: got time to chat this version key in the bundle file? That seems to be the only sticking thing on that branch left correct? [15:35] rick_h_: sure [15:36] hazmat: hangout or just chat? [15:36] rick_h_: so nutshell is that if we start sniffing, we'll keep sniffing each change till its a mess [15:36] rick_h_: can't hangout atm [15:36] hazmat: understand but the only sniff is just the removing of multiple bundles per file. it's a one time 'raising' of the data up one level [15:36] the rest of backward compatible/etc [15:38] hazmat: I guess I'd agree but for two things. 1) these things are hand written so we're not going to be able to rely on a version key long term and 2) the changes planned and such are small and blindingly sniffable [15:38] rick_h_: but isn't the next incoming change, machines as a top level key [15:38] so it just seems overkill and unreliable to go the version string route atm [15:38] hmm [15:39] hazmat: right, but I'm missing how that's a version increase. If it was an API I'd just call it a new API and not increment the version number of that api [15:39] rick_h_: the thought is also there that things might diverge down more lines [15:39] that's totally true, but honestly the talk now is a whole new format [15:39] and so I don't want to go too far into that future to be honest [15:39] ie. not linear version.. but machines added to both formats, the extant format is majority usage .. with inheritance [15:39] that's more with core involved, specs, and a lot of total changes from the sounds of things [15:40] hmm, I suppose on the inheritance front... [15:40] rick_h_: i'm okay with pushing forward with the change (w/ test).. [15:41] its not ideal.. but its small and easy to fix if we go a different way in the future [15:41] hazmat: cool, I know he was adding that yesterday per standup so that'd be great. I think we'll keep an eye out though as you're right that if the delta gets big explicit > implicit [15:41] right [15:41] Makyo: ^ [15:42] hazmat, rick_h_ that should be pushed [15:43] Makyo: cool then. hazmat can you TAL then please? [15:43] Oh, I'd left the internal services check. Do you think there's a chance of someone naming their bundle 'services'? I can take that out if not. [15:43] rick_h_: Makyo i have to wait till this evening, don't have network access for it atm [15:44] hazmat: rgr ty much [15:44] Makyo: let's take that out. [15:44] ack [15:44] Makyo: i think they deserve what they get if they do that ;-) [15:44] lol [15:45] Haha, fair :) [16:03] stub: looks like ci has changed the details page, I'll update reviewq === roadmr is now known as roadmr_afk === kadams54 is now known as kadams54-away === kadams54-away is now known as kadams54 === roadmr_afk is now known as roadmr === kadams54 is now known as kadams54-away === kadams54-away is now known as kadams54 === roadmr is now known as roadmr_afk === roadmr_afk is now known as roadmr === roadmr is now known as roadmr_afk === kadams54 is now known as kadams54-away [20:43] hey, got a question about variables set in config.yaml and if they can be overridden with the "juju set" command [21:26] I need some help with configuring and deploying nova-compute with FlatDHCPManager. I can not get it deployed correctly where I can ssh into a VM. I would like eth1 to be the public interface. [21:28] I have tried various combinations using both eth0 and eth1 for flat-interface, but so far it isn't working. I can look at the VM boot log and it can't reach the metadata server. Any help, please? [21:33] jamespage ^^? === roadmr_afk is now known as roadmr [22:01] juju deploy ceph 'hook failed: "mon-relation-changed"' | http://askubuntu.com/q/589506 [22:04] ctlaugh: jamespage is UK time, response may be latent, its pretty late over there. [22:05] lazyPower: I'll take help from anyone -- just trying to start pinging ones I thought might be able to help :) I was about to post on AskUbuntu and hopefully get a response. [22:06] ctlaugh: that would be a good place to put it, or the mailing list. [22:25] How to correctly configure nova-compute to use FlatDHCPManager | http://askubuntu.com/q/589516 === scuttlemonkey is now known as scuttle|afk === scuttle|afk is now known as scuttlemonkey [22:56] Methinks Azure tests are broken: http://reports.vapour.ws/charm-tests-by-charm [22:56] The 3rd one in the list is mine, and it shouldn't be a change that makes *anything* fail. [22:58] blahdeblah: if you look at the test results, http://reports.vapour.ws/charm-test-details/charm-bundle-test-11054-results, you can see that the test threw a SKIP (100) [22:58] looks like a timeout [22:59] marcoceppi: Is that fairly common? [23:00] blahdeblah: I've seen azure deployments timing out at 15mins. Tests by default use a 15 min timeout, you could try to increase that for slower clouds [23:01] marcoceppi: What's our obligation as MP submitters in terms of getting clean testing results? I only looked at it because it emailed me about a failure, and it seems pretty clear to me that it's the cloud's fault, not the charm's. [23:02] blahdeblah: charmers will always review the test output regardless of pass or fail. With the new charm testing stuff we're actually going to change a bit on how the CI bot reponds to merge requests. [23:02] So as a reviewer, I would look at the change, the test results, and if need be, run the tests myself for clouds missing [23:02] OK - thanks [23:02] instead of saying "TESTS (PASSED|FAILED)" it's just going to say testing was completed results available at URL [23:03] blahdeblah: increasing the timeout to something higher than 15 mins wouldn't hurt [23:03] HPCloud hit 10 mins for deployment [23:03] hi ctlaugh, see corresponding nova-compute flat networking options @ http://bazaar.launchpad.net/~openstack-charmers/charms/trusty/nova-compute/trunk/view/head:/config.yaml#L89 (ymmv with flat - but let us know) [23:04] moving it to 30 mins, for example, wouldn't hurt blahdeblah [23:04] marcoceppi: Is that something that is controlled in the charm? [23:04] blahdeblah: it's in the test file typically [23:05] marcoceppi: Pardon my ignorance - the test file in the charm repo? [23:05] http://bazaar.launchpad.net/~mbruzek/charms/precise/nrpe-external-master/tests/view/head:/tests/99-autogen#L21 [23:05] hello [23:05] mbruzek: unintentional ping [23:06] blahdeblah: http://bazaar.launchpad.net/~charmers/charms/precise/nrpe-external-master/trunk/view/head:/tests/99-autogen#L21 [23:06] marcoceppi: So would a change to that take effect on the first test run afterwards? === scuttlemonkey is now known as scuttle|afk [23:06] blahdeblah: if you change that and reupload, on the next test run it'll use the updated timeout value for waiting for the deployment [23:06] cool - thanks [23:07] beisner: Thank you, I've seen those (both looking in the charm and on the charm store) -- what I can't get working right is the correct combination of settings needed to make it work on my config. For example, what do I need to set flat-interface, bridge-interface (and anything else?) so that it uses eth1 for all VM public network traffic and uses eth0 for everything else? [23:07] ^^ I posted this question (http://askubuntu.com/q/589516) that has more details on what I have done and what I am seeing. [23:14] ctlaugh, tbh, i don't have a definitive answer. but i just made a best guess for my enviro and kicked off a flat deploy. may not get back to that till tomorrow though. [23:14] beisner: Sorry, I see that you already saw the question and responded :) [23:14] beisner: ok, thank you. I appreciate it. [23:15] ctlaugh, so here's how I interpret it: bridge-ip is something static in your LAN, and of course bridge-netmask is the matching subnet. [23:16] ctlaugh, bridge-interface's default br100 shouldn't matter; flat-interface for me is eth1. so, the charm should take all instance traffic across eth1, and create bridges on eth1. [23:17] So, flat-interface is for instance traffic? I thought it was for internal traffic. [23:17] ctlaugh, fwiw, secgroups could also be tripping you up. [23:17] ctlaugh, aiui, yes. [23:18] And, for the bridge-ip (and netmask), what purpose does that serve? Does it need to be an address in the same subnet I would assign for floating-ips, or something different? [23:19] ctlaugh, i don't think you can use floating ips with the flat network option. [23:19] ctlaugh, what i'm doing is this: eth0 and eth1 are wired to the same LAN. i've told the charms nothing about eth0, and expect it to use it for api traffic. i've told the charms about eth1, giving it some static IP info compatible with my LAN. [23:21] ctlaugh, but keep in mind, i've not personally used the charm flat network options, so i'm just going by what i know about the default behaviors, the configs I see, and a little bit of filling in the gaps. [23:21] beisner: understood [23:23] beisner: I've got to head out for a few hours, but will be back online sometime later tonight. Thank you for the tips -- I'm going to kick another install off tonight to try. [23:23] ctlaugh, hope that helps, best to you!