[00:27] sinzui: I am having trouble enabling the 'proposed' repository for trusty [00:28] oh no [00:28] wait [00:28] yeah, that got it [02:14] http://www.windowsazure.com/en-us/documentation/articles/manage-availability-virtual-machines/ [02:27] wallyworld, axw, waigani: https://docs.google.com/a/canonical.com/document/d/1PJiqBiAndIKvT6WYT1fG4rBX2b4sF90j3m7GTLNoZiE/edit [02:32] I upgraded to trusty and the environment I started under saucy doesn't look great now... [02:32] http://paste.ubuntu.com/6795052/ [02:32] what's going on? [02:33] bigjools: you probably need to upgrade the environment [02:33] bigjools: but the short answre is "we hate you" [02:33] thumper: I knew *that* already [02:34] bigjools: first mistake - upgrading to alpha software for production purposes [02:34] :-P [02:34] who said it was production purposes? :) [02:35] anyway you're missing all the fun weather over here [02:37] hot? [02:37] heat index is nearly 47 [02:37] ah, so cool then [02:37] your missus will be asking you for a/c when you get back :) [02:37] amongst other things [02:39] thumper: how do I upgrade an environment? [02:39] bigjools: juju upgrade ?? [02:39] you may point me at TFM [02:39] upgrade-juju? [02:40] think so [02:41] if it's upgrading to a trunk release from source, you need --upload-tools IIRC [02:41] I am using 1.17.0-trusty-amd64 [02:41] I think my existing env is 1.16 [02:41] so it should find tools for 1.17 without the --upload I guess? [02:43] well looks like it didn't work anyway :( === tim is now known as thumper === tim is now known as thumper [03:35] thumper: https://codereview.appspot.com/55300043/ [07:28] folks, I deleted a service and it's machine so I can redeploy it on a new series, but when trying to deploy it says the service already exists. It doesn't appear on "juju status" though..... is this a bug? v1.17.0.1 [07:28] its* gah hate that [07:36] bigjools, is this a local env? [07:36] dimitern: canonistack [07:37] dimitern: http://paste.ubuntu.com/6795916/ [07:38] bigjools, hmm that's weird [07:38] dimitern: I upgraded the tools from 1.16 earlier. I suspect that may have something to do with it [07:38] bigjools, we had issues like that but with the local provider, and they were fixed since [07:38] bigjools, can you perhaps do a mongo dump and file a bug please? [07:39] dimitern: if you give me monkey-like instructions to do that, yes :) [07:40] bigjools, :) just a sec [07:42] dimitern: np. There's a massive storm bearing down on me that is likely to cut my power/internet, so no pressure. :) [07:42] bigjools, using juju backup [07:43] bigjools, it's a plugin that does that - it has --help as well [07:43] where do I get it? [07:49] dimitern: I have to run out for a bit, can you send me details please :) [08:25] axw, am I right in thinking bigjools' problem above is that one about the env life field, that's fixed in trunk? [08:37] fwereade: morning [08:37] fwereade: any chance to take another look at https://codereview.appspot.com/44540043/ this morning? [08:37] TheMue, heyhey [08:37] TheMue, all I can say is "maybe" :/ [08:39] fwereade: ok, thx [08:39] dimitern: after your help yesterday a deeper look at https://codereview.appspot.com/44540043/ would be appreciated too [08:40] * TheMue is getting closer, but so far didn't found any watcher via API used in cmd/juju so far [08:49] TheMue, definitely looks better now [08:49] bigjools, it's part of core - in cmd/juju/plugins [08:51] mornin' all [08:59] rogpeppe1, morning [08:59] rogpeppe1, thanks again for all the reviews yesterday [09:00] dimitern: np [09:00] dimitern: i'm looking for a review of https://codereview.appspot.com/55150043 BTW [09:00] rogpeppe1, looking [09:06] rogpeppe1, quick question - what's the deal with NoVote and VotingMachineIds ? [09:07] dimitern: that's the way that EnsureAvailability will be able to reduce the number of machines in the peer group without just removing them. [09:08] rogpeppe1, and a peer group is a set of machines in a replicaset ? [09:08] dimitern: if a machine goes down, we don't want to just remove it from the peer group, because it may come up again [09:08] dimitern: yes [09:08] rogpeppe1, i see [09:08] dimitern: not all machines in a replica set are necessarily voting [09:08] dimitern: it also gives us the freedom in the future to be able to deliberately bring up non-voting machines to act as backup [09:09] dimitern: there will also be another field associated with the machine: IsVoting - indicating the actual voting status of the machine. [09:09] dimitern: that will be set by the peergrouper worker [09:10] rogpeppe1, IsVoting or WantVote ? [09:10] dimitern: IsVoting [09:10] rogpeppe1, and WantVote ? [09:10] dimitern: that's just the negation of NoVote [09:10] rogpeppe1, (looking in the code comments of Ensure..) [09:10] rogpeppe1, ah, ok [09:10] dimitern: i didn't want to do WantsVote in the machineDoc because that would be incompatible with previous versions. [09:11] dimitern: which wouldn't have the field in the schema [09:14] rogpeppe1, yeah, but can't it be added in a compatible way? Like the default value (when missing) is fine? [09:15] dimitern: that just makes the logic harder - you'd have to look for "wantsVote==true || wantsVote==nil" [09:15] dimitern: i think it works pretty well inverted actually [09:15] rogpeppe1, i see, well this can be hidden behind a machine method, no? [09:16] dimitern: it is, isn't it? [09:16] rogpeppe1, sorry, just got there [09:16] rogpeppe1, I see now [09:16] dimitern: apart from in the MachineTemplate, where NoVote actually makes sense, because you actually almost always want a vote [09:17] dimitern: things became simpler when I changed MachineTemplate.WantsVote to MachineTemplate.NoVote [09:17] rogpeppe1, yeah, i agree [09:29] rogpeppe1, reviewed [09:29] dimitern: thanks a lot [09:37] fwereade: ping about API version numbering [09:37] I've been trying to respond to your email and thinking about it, but I think it comes across rambling in email form, so it might be better as a 1:1 chat [09:44] jam, pong [09:45] fwereade: hey hey [09:45] jam, was I terribly unclear? [09:47] fwereade: there is just a lot that I've thought about it. [09:47] fwereade: specifically, what does it actually *mean* to have a global rev vs a local rev, how does stuff look like in code, etc. [09:48] jam, so, I think the local revs are purely an internal tool to help us manage bloat [09:49] fwereade: I sent my long rambly email [09:49] fwereade: there are problems with global rev that we should probably explore as well [09:49] namely, where /when is that sent on the wire [09:49] jam, codewise, a request comes in with a version, namespace, method, params; we get the facade by looking up the namespace given the version and get an actual facade on which we can call.Method(Params) [09:49] fwereade: codewise *today* it comes in with namespace, ??, method, params [09:50] and we can make ?? == version [09:50] jam, my suggestion earlier was that we demand it on every call [09:50] jam, yeah [09:50] It looks confusing that global version comes after namespace [09:50] but supersedes it [09:50] fwereade: so the next failure I explored is that we can have a relatively new client [09:50] that still calls a really old version [09:50] just because we never touched that code [09:50] and then we can't actually remove compatibility [09:51] so even though the API is 5 years old, and "Machine", "100", "Add" works just fine and is identical to "Machine", "1", "Add" [09:51] the very newest 'juju' commandline tool still calls [09:51] "Machine", "1", "Add" [09:52] jam, I think that's the least of our problems because we can at least control that -- it's everybody else calling v1 that's the problem, surely? [09:52] jam, and also that there will be old server versions that we'll have to fall back to even with new clients, at least for some time [09:52] fwereade: we can audit for it, but it is fairly expensive to sort out what version of Juju was calling what version of the API. If we work on making the juju CLI always call "latest" versions, then you don't have 2 pieces that break independently [09:53] jam, well, we *do* probably want to keep the CLI up to date with API versions, it's true, but we also need to leave fallback code in place, right? [09:53] fwereade: so, if you have 1 global rev number, then all call sites get bumped any time you change anything, right? [09:54] except the ones where that actually changes the implementation so we use the 'slightly older one' as we transition / (we want to update all our call sites eventually, I'm sure) [09:54] jam, they could do, yes, but I don't think it's necessarily required or expected that everybody does so [09:56] fwereade: so there is a little bit of "what do we do in Juju because we control both ends" and "what do we suggest 3rd parties do" [09:56] if we're going with a global bump, and we can remove old ones after we've deprecated it for "long enough" [09:56] jam, yeah, I think *we* should, but we can't necessarily impose it on everybody else [09:56] then we do want some sort of push for people to go to the latest thing they could [09:57] for example, how do people get informed that the API they are using is deprecated? [09:58] jam, I'm not sure what mechanisms we have for encouraging people to update their clients (apart from public warnings that vX will be going away in N months -- and making version removal clear in release notes) [09:59] fwereade: well, you can return something in the API that "this is deprecated" but it needs to be done in a way that is actually useful [10:00] Users don't actually care [10:00] its developers that need to be informed about it [10:00] I guess you could have client versions logged, and calling a deprecated version generates an email to juju-core that client X version Y is still using a now deprecated API ? :) [10:01] jam, ok, you're talking about us here? or everyone else as well? [10:02] fwereade: I mean the juju server would notice when a client connects and calls a deprecated API and aggregate that into something useful for other people [10:02] then you have some sort of report about "juju-1.16.5 is still very common in the wild and is making lots of calls to X", and "juju-developer 0.8 is still calling Y" [10:03] it would be *useful* in the fact that we can then contact the developer directly and let them know we're deprecating something [10:03] but it is highly invasive :) [10:03] jam, well there is some reasonable worry about collecting that data [10:45] Hi guys, I'm was trying to bootstrap a juju env and I got this: http://paste.ubuntu.com/6796595/. Is this a known problem? It does not seem to happen consistently but I don't think that's the first time I saw this. [10:45] rvba: looking [10:49] rvba: what version of the client are you using? [10:49] (juju version) [10:49] mgz: wallyworld: standup? [10:50] jam: apt-cache policy juju-core → 1.16.3-0ubuntu0.13.10.1 [10:50] ta jam [10:50] rvba: it is *possible* that this was something we fixed in 1.16.5 [10:50] rvba: there was an EOF bug that we implemented a workaround fro [10:50] for [10:51] jam: ah ok, thanks. I guess I'll upgrade using the PPA and test again… [10:52] rvba: you'll probably want a 1.16 series, rather than 1.17, I think [10:53] The stable PPA has 1.16.5-0ubuntu1~ubuntu13.10.1~juju1. [10:53] rvba: great, I think devel has 1.17.0 [10:57] jam: same problem with the new version: http://paste.ubuntu.com/6796653/ [10:57] rvba: looks like https://bugs.launchpad.net/juju-core/+bug/1239558 [10:58] but that actually claims it was only fixed in 1.17 :( [10:58] ah, right. [11:04] jam: sorry to bother you again… I'm trying to use juju on Trusty (1.17.0-0ubuntu2) and now I get: http://paste.ubuntu.com/6796670/ [11:04] Any idea what might be wrong? [11:05] rvba: there you need to use "juju bootstrap --upload-toolS" [11:05] we're looking for tools on streams.canonical.com [11:05] but that hasn't been finished being set up yet [11:05] Ah okay, makes sense. [11:05] Thanks. [11:23] mgz: do you have a chance to investigate why "juju-1.17" can't do "status" vs a 1.16 server? (Did it get fixed and I'm missing something?) [11:25] (at least here trunk r2239 still fails) [11:26] jam: er, I'll recheck [11:31] I am trying to bootstrap an environment using 1.17 and it insists that I am already bootstrapped but I am not. What else is it checking? there are no instances running [11:32] bigjools: probably the bootstrap-verify file in your cloud storage [11:32] bigjools: you can just run `juju destroy-environment` to clear everything out [11:32] mgz: it fails [11:32] because I have no instances [11:33] I guess that's a provider bug then [11:33] Continue [y/N]? y [11:33] ERROR no instances found [11:33] it should always do all the work, even if some parts of it have already completed [11:33] this is the openstack provider [11:33] can you list the control bucket externally and see what it contains? [11:34] how do I do that? sorry I know bugger all about openstack [11:34] eg, look in ~/.juju/environment/ for the control bucket name [11:34] then `swift list ` [11:34] mgz: just have him delete the fixed bucket in environments.yaml ? [11:34] ok [11:34] python-swiftclient if you don't have it [11:34] so we generate a random one [11:35] jam: I curious if we actually have a provider bug on destroy [11:35] yes it lists the files [11:35] provider bug [11:36] so, now delete those with `swift delete` and bootstrap - if that works, please do file a bug [11:36] ok cheers [11:37] mgz: that fixed it indeed. thanks for the help [11:37] * bigjools files bug [11:39] fwereade: when you get a chance, I'd like to talk about your comments on the EnsureMongoServer stuff. [11:47] fwereade: it turns out that Machine.Destroy only fails if the machine has JobManageEnviron, not JobManageState... [11:48] fwereade: i think that's probably a bug, but it makes me think (yet again) of changing the semantics of those two jobs [12:37] jam: I /think/ the problem we're struggling with in MAAS+Juju might be related to https://bugs.launchpad.net/juju-core/+bug/1257649. I don't understand the comment on there that says this is irrelevant now… care to enlighten me? [13:03] rogpeppe1, I'd be +1 on that [13:03] natefinch, might need to be a bit later [13:04] fwereade: np, I am currently encumbered anyway [13:06] fwereade: my thought is to have two manager jobs, one for jobs which can be blown away with probs (e.g. the API server) and one for jobs which require special handling with EnsureAvailability and freidns [13:06] friends, even [13:06] s/with probs/without probs/ [13:06] fwereade: for the time being though, i'm wondering about just ditching one of the jobs entirely [13:06] rogpeppe1, I'd be most happy just ditching one of them [13:07] fwereade: i don't think the distinction between ManageEnviron and ManageState is currently useful === gary_poster|away is now known as gary_poster [13:07] fwereade: cool, i'll do that. [13:07] rogpeppe1, agreed, it seemed like a good idea at the time [13:07] fwereade: yeah [13:07] rogpeppe1, the universal explanation [13:07] fwereade: at some point in the indefinite future, i'd like to be able to scale up API servers independently of mongo servers [13:08] fwereade: but i think that's easier to do by adding a new job then [13:08] rogpeppe1, agreed, but I don't think we're actually getting there any faster by maintaining that somewhat fuzzy distinction at the moment [13:08] fwereade: yup [13:08] rogpeppe1, sweet, thanks [13:10] rvba: in the current code in trunk, we don't have an internal timeout for the SSH connection. (I think) I'd have to double check what version you're running and what disconnections you're seeing [13:28] jam: we think the bug in question might be the cause of the problem we're seeing in the lab. It takes more than 10 minutes to bring up a bootstrap node in MAAS because before installing jujud on it, we have to install it using d-i. [13:29] jam: we're trying to re-build juju with a different timeout to confirm this. [13:38] jam: what we're seeing is that 'juju bootstrap' gives up after 10 minutes and we think it might have succeeded with a bit more time :) [14:25] debugging-by-println, sometimes nothing else works :D [14:30] aaaaargh, apiserver.StringsWatcher requires to be called by an agent, client is not allowed (dunno why). THATS why debug-log has a "permission denied error" [14:30] *sigh* [14:35] can anyone verify that a juju 'upgrade' to an older revision is possible on pyjuju please? === rogpeppe2 is now known as rogpeppe [14:50] fwereade: re: your comment on EnsureMongoServer, it's not adding anything that isn't already there [14:51] fwereade: and if the state port isn't stored in the agent config, where *would* it be stored? [14:52] rogpeppe, well it's already in the env config [14:52] fwereade: but the agent doesn't have access to the env config until they've connected to the state, right? [14:53] rogpeppe, this is all bootstrap time, isn't it? perhaps I'm confused there [14:54] fwereade: it's also used after bootstrap time, when new state servers come up [14:54] fwereade: but... [14:54] fwereade: i'm thinking you may be right, because a second state server will have access to the API, even if they can't connect to mongo [14:54] rogpeppe, but anything setting up a state server is either doing so at bootstrap, or in response to being told to by the API, right? [14:54] rogpeppe, yeah [14:55] rick_h_, pyjuju didn't have juju upgrades at all [14:55] fwereade: you may help me with a design decision? why do the watcher in apiserver/root.go require to be called by an agent? [14:56] fwereade, natefinch: huh, that call to ensureMongoServer in MachineAgent.Run doesn't look right at all [14:56] TheMue, that was the only thing that needed it at the time [14:56] fwereade: would like to use the StringsWatcher from the client [14:56] fwereade: so changing would be ok? [14:56] TheMue, let me take a quick look at the code [14:56] fwereade: yep [14:57] TheMue, aw hell [14:57] TheMue, yes it's fine to change it [14:57] TheMue, but it's not a simpleone [14:58] fwereade: great, that helps a lot for debug-log [14:58] TheMue, ISTM that there's a pretty serious problem with all the watchers [14:58] fwereade: oh *listening* [14:58] TheMue, there's nothing preventing clients from grabbing each other's watchers willy-nilly [14:59] fwereade: come on, let them have some fun *lol* [14:59] TheMue, there's presumably something about a given resource that ties it to a particular client, otherwise we couldn't tidy up resources when conns are closed [14:59] TheMue, haha [14:59] fwereade: clients don't share resources [14:59] TheMue, so ISTM this is something that can and should (nay must) be fixed for all the watchers [14:59] rogpeppe: exactly, that's how I understood it too [15:00] rogpeppe, yeah, I just can't remember the exact mechanism [15:00] rogpeppe, ohhhhh ok it's maybe ok? individual clients get separate resource idspaces anyway, right? [15:00] fwereade: exactly [15:00] rogpeppe, cool [15:00] TheMue, belay that panic then [15:01] TheMue, you can just open up stringswatcher I think [15:01] fwereade: yes, will start with that one as I only need it [15:01] fwereade: specifically, newSrvRoot allocates a new resources map, and it's called when a client successfully logged in, and stored in the root object for that client [15:02] TheMue, fwereade: opening up StringsWatcher seems fine to me [15:03] * TheMue takes the key to open it [15:28] fwereade: back, let me know when you'd like to talk [15:48] rogpeppe, fwereade, natefinch - I have two branches up for review, which complete the firewaller API story: https://codereview.appspot.com/55670043 and - https://codereview.appspot.com/55680043 I'd really appreciate if someone takes a look [16:32] could somebody have a llok here: https://codereview.appspot.com/55690043 ? [16:35] adeuring: looking [16:36] thanks [16:46] adeuring: reviewed [16:46] natefinch: thanks! [16:46] adeuring: thank you :) [16:57] rogpeppe: what was the problem you had with ensuremongoserver? I saw a couple problems while reviewing it with William (like, we only need to call it if we have a managestate job, and I need to be more tolerant in case the directory and files already exist). [16:57] natefinch: why is it called unconditionally in the machine agent? [16:58] natefinch: ah, yes, that's "we only need to call it if we have a managestate job" [16:58] rogpeppe: right, I realized that when I went back to look over the code [17:01] natefinch: i'm just about to delete JobManageState throughout the code, BTW, and just use JobManageEnviron throughout [17:03] rogpeppe: cool, I'll check for that one then [17:03] natefinch, rogpeppe, review poke? [17:03] dimitern: will look shortly [17:03] rogpeppe, cheers [17:12] rogpeppe: is openApiState the appropriate way to get the list of jobs for the machine agent? I don't see an easier way to do it [17:12] natefinch: yes [17:12] rogpeppe: cool [17:12] natefinch: you might not find it that easy [17:13] natefinch: but actually, as long as jobs stay constant, it's probably not too bad [17:13] natefinch: the difficulty comes at bootstrap time [17:14] natefinch: because at bootstrap time (or if a single remaining state server machine reboots) there's no API server to go to to ask for jobs [17:15] rogpeppe: ahh, right [17:17] natefinch, can you take a look at this please? https://codereview.appspot.com/55680043 [17:18] dimitern: sure thing [17:20] natefinch, cheers [17:45] hmm, a recent update (revno 2226) has broken tests for me [17:58] rogpeppe, natefinch , guys, sorry to poke you again, but i'd like to land these two today if possible [17:59] dimitern: looking, sorry, i've been struggling to get tests to pass [17:59] rogpeppe, what's wrong? [18:00] dimitern: i've just reported https://bugs.launchpad.net/juju-core/+bug/1271674 and https://bugs.launchpad.net/juju-core/+bug/1271672, [18:00] dimitern: but mostly just crap from removing JobManageState [18:01] rogpeppe, wow test.invalid resolves in your local net? [18:01] dimitern: yeah. blame my ISP [18:02] dimitern: they resolve everything to their yahoo search page [18:02] rogpeppe, ah, nasty [18:02] dimitern: it resolves to 92.242.132.16 for me [18:03] to what lengths some people go for the sake of marketing [18:06] dimitern: sorry, caught me during lunch. I'm looking now for real though [18:07] natefinch, thanks [18:07] rogpeppe: my ISP does similar things, forwards DNS failures to their own page. In theory you can disable it at the router, but I've forgotten the password to it :/ [18:08] * dimitern is aft for a while [18:08] afk even [18:24] dimitern: reviewed [18:50] will any folks here be joning the charm writing virt. sprint? [19:00] arosales: core is pretty slammed right now. I know I'm pretty behind where I'm supposed to be.... not sure about others. [19:03] natefinch, ack I'll check with some others [19:19] to whomever fixed the state-watcher bug, i could hug you. [19:22] lazypower: you're welcome :-) [19:22] rogpeppe, you + me + beer in our future [19:23] lazypower: SGTM! === fcorrea__ is now known as fcorrea === BradCrittenden is now known as bac [20:47] arosales: hey there [20:47] arosales: I think you are under the mistaken impression that we know how to write charms :-) [20:49] thumper: roger does, more or less :) He wrote that Go charm thing, which looks pretty cool. [20:49] hey natefinch [20:49] * natefinch might be biased for anything Go and against anything bash, though [20:49] thumper: howdy [20:50] natefinch: heh [20:50] thumper: you're using Sublime Text and GoSublime, right? [20:50] natefinch: I am now [20:51] getting the hang of it [20:51] does go to definition work for you on methods? Like if you have s.Foo() can you go to the definition of the Foo() method? It doesn't work for me, and it's really annoying [20:52] I can go to definition of types and top level functions, but not methods on types. [20:53] I end up having to resort to a full text search like some kind of Neanderthal. [20:54] thumper, you guys are coding kings I am sure you can crank out all sorts of quality code [20:54] bwahaha [20:54] thumper, heyhey [20:54] arosales: we are kinda focused on several areas that will make others more happier [20:54] fwereade: hey dude [20:55] thumper, understood. I thought it wouldn't hurt to ask though [20:55] thumper, I should have come on earlier and arranged things and so on [20:55] just in case :-) [20:55] arosales: sure [20:55] thumper, thanks for the consideration though [20:55] thumper, don't suppose you're free to chat about availability sets a bit? [20:55] arosales: if we were just sitting around drinking, then yeah, we'd help [20:55] fwereade: sure [20:56] thumper, lol [20:56] thumper: that doesn't sound like you guys.... [20:56] thumper, or have you just been explaining to arosales that you wouldn't do them? ;p [20:56] thumper, I know you aren't doing that given I brought up the availability sets too [20:56] arosales: we aren't working on the availability sets just yet, but we have talked about it... [20:56] fwereade, that was charm tests thumper was breaking my heart on [20:56] arosales: we are working on proxy support, local provider improvements [20:57] aww [20:57] fwereade: want a hangout? [20:57] thumper, sgtm [20:57] thumper, its only mid week :-) [20:58] fwereade: https://plus.google.com/hangouts/_/7acpibmqriabeqpmu77ctb34ns?hl=en [20:58] arosales: for you.. thursday morning for us [20:59] thats 2 full days :-) I'll let you get back to work [21:23] natefinch, ping [21:23] fwereade: pong [21:33] natefinch: we should chat about upgrades [21:33] thumper: I love upgrades [21:34] thumper: shall I join the hangout? [21:34] natefinch: sure [21:34] natefinch, damn sorry I had a response half typed out [21:35] natefinch: fwereade just left the hangout, but I'm still there waiting for you === gary_poster is now known as gary_poster|away [22:19] thumper, runonallmachines .. runs on all units.. or just machines? [22:19] hazmat: it does what it says :-) [22:19] on the machiens [22:19] or machines [22:19] we don't have an --all-units [22:20] if you need it, file a bug :) [22:20] thumper, so this isn't juju-run.. this is arbitrary script run? [22:20] no... [22:20] only when running on a unit does it get the unit context [22:20] you can also run on the machine outside of a unit context [22:21] however it will get the hook execution flock [22:21] to make sure that it doesn't run in parallel with a hook [22:21] cool, was just doing my monthly check for new api methods and came across. [22:21] :-) [22:22] it is freaky magic shit [22:22] orchestration even ;-) [22:22] yeah, that [22:22] ansible-lite [22:23] thumper, so commands string need a #!/bin/executable preprend? [22:23] no [22:23] we do that [22:23] actually, we send it through /bin/bash -s [22:23] hmm.. so assumes bash? [22:23] yes [22:23] * hazmat files a bug ;-) [22:24] bcsaller, ^ you might be interested in this [22:24] nah [22:24] why? [22:24] if you want to execute a magic script [22:24] write it to disk and call it [22:24] i guess exec works.. just feels a little klunky that way [22:24] * bcsaller reads [22:27] bcsaller: we have 'juju run' now [22:27] which has an api end point [22:27] so in theory, the gui could run arbitrary code on any machine, service or unit [22:28] thumper: good stuff [22:29] * thumper considers a button on a machine in the gui called 'reboot' [22:29] * thumper chuckles to himself [22:30] if only there were machines in the gui ;-) [22:31] yeah... [22:31]