| thumper | waigani: the parseTag method is only used in the annotator | 00:02 |
|---|---|---|
| thumper | waigani: and it is doing a doc exists check | 00:02 |
| thumper | so the id has to be the docID, not a local ID | 00:02 |
| waigani_ | when I bootstrap and deply mysql with trunk I get the following in juju status: agent-state-info: 'hook failed: "install"' | 00:25 |
| rick_h_ | waigani_: what did you deploy it with? | 00:26 |
| rick_h_ | waigani_: the gui or cli? | 00:27 |
| waigani_ | rick_h_: cli | 00:27 |
| rick_h_ | waigani_: k, nvm then. There was a known gui bug | 00:27 |
| waigani_ | okay, anyone else hit this with trunk or am I a special snowflake? | 00:28 |
| rick_h_ | waigani_: knowing what's in the unit log would be helpful | 00:28 |
| rick_h_ | waigani_: juju ssh mysql/0 and then check the end of /var/log/juju/unit-<tab> | 00:29 |
| waigani_ | rick_h_: ugh I just destroyed the env. Let me repeat my steps and I'll check out the log | 00:29 |
| rick_h_ | waigani_: rgr | 00:29 |
| waigani_ | rick_h_: http://pastebin.ubuntu.com/8407234/ | 00:35 |
| rick_h_ | waigani_: what series is this? | 00:38 |
| rick_h_ | waigani: curious what series that is? | 00:45 |
| waigani | rick_h_: https://bugs.launchpad.net/juju-core/+bug/1372699 | 00:47 |
| mup | Bug #1372699: juju status reports: agent-state-info: 'hook failed: "install"' <juju-core:New> <https://launchpad.net/bugs/1372699> | 00:47 |
| rick_h_ | waigani: gotcha, interesting. | 00:49 |
| rick_h_ | waigani: last bit of info I'd include is where you were doing this at, lxc, ec2, etc | 00:49 |
| waigani | rick_h_: ah right, thanks | 00:49 |
| rick_h_ | since the issue is around a package install wonder if there's some mirror thing going on there | 00:49 |
| waigani | rick_h_: Using trunk (daee198586afe412948b23d68f58592c625de08f) with LXC containers on my machine (amd64 14.04) ? | 00:52 |
| rick_h_ | waigani: hmm, you know what. I wonder if this is any part of the apt-get upgrade by default stuff | 01:06 |
| rick_h_ | waigani: is that env still up? | 01:07 |
| waigani | rick_h_: sorry, I moved on. I had to test a different branch. | 01:08 |
| waigani | rick_h_: what did you want me to check? | 01:09 |
| rick_h_ | waigani: understood, still trying to get an lxc env up to test something out | 01:09 |
| rick_h_ | waigani: so I'm wondering if you could manually apt-get install python-jinja2 | 01:09 |
| rick_h_ | waigani: and if not, if an apt-get update && apt-get install python-jinja2 would work | 01:09 |
| rick_h_ | waigani: just trying to figure out why that install would fail to run and pondering | 01:10 |
| waigani | rick_h_: Setting up python-jinja2 (2.7.2-2) ... | 01:10 |
| rick_h_ | waigani: :/ | 01:10 |
| waigani | installed no problem | 01:10 |
| waigani | a could flaky Internet connection have anything to do with it? | 01:11 |
| rick_h_ | waigani: yes, if that apt-get install failed to work then it would die and cause the non-0 exit | 01:12 |
| rick_h_ | waigani: in which case it would be a temp issue I'd imagine | 01:12 |
| rick_h_ | assuming flaky means it works some of the time :) | 01:12 |
| waigani | rick_h_: right, my guess is that is it. | 01:13 |
| rick_h_ | waigani: ah ok | 01:13 |
| waigani | rick_h_: begs the question, if there is a better way to handle this situation? | 01:14 |
| rick_h_ | waigani: well the tough part is that the charm is doing it in the script. If it doesn't really check/handle that I'm not sure what juju can do. | 01:14 |
| waigani | right, got ya | 01:14 |
| rick_h_ | waigani: there is talk of juju proviing a way for defining package deps before the charm even gets going, which might help as juj then can watch/manage that | 01:15 |
| waigani | rick_h_: +1 from me | 01:15 |
| rick_h_ | waigani: not sure where that is in the pain point list currently. | 01:15 |
| rick_h_ | davechen1y: any idea? ^ | 01:15 |
| waigani | top of my list today ;) | 01:15 |
| rick_h_ | looks like wallyworld is afk today | 01:16 |
| davechen1y | rick_h_: hold up,reading the backscroll | 01:18 |
| rick_h_ | davechen1y: is there anything on the charms listing system deps as part of the charm vs in the hook itself on the pain point list for the nearish future? | 01:19 |
| axw | thumper: is there a topic doc for the sprint? | 01:20 |
| davechen1y | rick_h_: nothing | 01:20 |
| rick_h_ | axw: one got started today | 01:20 |
| davechen1y | rick_h_: what is the context | 01:20 |
| davechen1y | ie, what doesn't the install hook provide you that you need ? | 01:20 |
| axw | rick_h_: okey dokey, can you link me please? | 01:20 |
| rick_h_ | davechen1y: k, sorry waigani. | 01:21 |
| rick_h_ | axw: sent | 01:21 |
| axw | cheers | 01:21 |
| rick_h_ | davechen1y: well the idea is that it would run pre-hook and in this case the charm doesn't do a good job of helping identity the issue when install failed | 01:21 |
| rick_h_ | davechen1y: where as if it was something more juju controlled it could do better, make sure deps are there before the install hook (python deps used in the python based single hook), etc | 01:22 |
| rick_h_ | davechen1y: so I know it was brought up but wasn't sure where it landed on plans/measure of pain | 01:22 |
| davechen1y | rick_h_: what is a pre-hook ? | 01:22 |
| davechen1y | rick_h_: i'm having trouble filtering out the bits you wish juju had from the problem you've hit | 01:22 |
| rick_h_ | davechen1y: so one problem is the new single hook stuff. If it's a python script, and I need python deps (python-jinja2) | 01:23 |
| rick_h_ | how can the install hook run? | 01:23 |
| davechen1y | rick_h_: is teh default hook stuff going in ? | 01:23 |
| davechen1y | i thought that it had many problems | 01:23 |
| rick_h_ | davechen1y: or let's say my hook is py2 but utopic is py3 out of the box, I need to have py2 available available | 01:24 |
| rick_h_ | davechen1y: my understanding is that it's waiting on charm feature flags in some form or other | 01:24 |
| rick_h_ | davechen1y: and that's the only blockers | 01:24 |
| davechen1y | rick_h_: i strongly recommend always writing the install hook in shello | 01:24 |
| davechen1y | 'cos you can't depend on anyting | 01:24 |
| rick_h_ | davechen1y: right, well that's the point :) | 01:24 |
| davechen1y | rick_h_: default hook wasn't my suggestion | 01:24 |
| davechen1y | i think it sounds good in theory | 01:25 |
| davechen1y | but fails in practice | 01:25 |
| rick_h_ | davechen1y: ok, well anyway. I was just curious. It's come up as an idea but guess it didn't have as much traction as it seemed | 01:25 |
| davechen1y | default hook is a large hammer to solve very specific problem, no symlink support on windows | 01:25 |
| davechen1y | but windows chamrs by definition are indepdent of unix charms | 01:25 |
| davechen1y | so they should adopt a different pattern | 01:26 |
| davechen1y | for unix charms, you symlinks | 01:26 |
| rick_h_ | well the other problem is that so many charms find a single script easier to write/maintain. That's regardless of platform | 01:26 |
| rick_h_ | davechen1y: but all good, thanks for the sanity check on the idea | 01:26 |
| thumper | axw: yep | 01:43 |
| davechen1y | waigani: 1372699 | 01:59 |
| davechen1y | do you still have this machine up ? | 01:59 |
| davechen1y | you'd missing the crucial bit of the log | 01:59 |
| davechen1y | it appears above the python stack trace | 01:59 |
| waigani | davechen1y: ah no, sorry | 02:00 |
| waigani | davechen1y: I can try to reproduce, though I had a bad Internet connection at the time - pretty sure that was it | 02:00 |
| rick_h_ | davechen1y: sorry, was going to update that. In chatting we assume a flaky network connection was to blame | 02:00 |
| davechen1y | rick_h_: waigani which provider ? | 02:00 |
| davechen1y | my money is on another process holding the apt lock | 02:01 |
| davechen1y | or apt failing | 02:01 |
| rick_h_ | davechen1y: lxc | 02:01 |
| rick_h_ | davechen1y: a manual apt-get install worked in debugging after the fact | 02:01 |
| davechen1y | waigani: rick_h_ yup, that matche sboth scenaruios | 02:02 |
| davechen1y | ie, if the apt lock was held by another process running apt-get afterwards won't fail because the other process has finished | 02:02 |
| davechen1y | also, if your network crapped out, same | 02:02 |
| davechen1y | antoher common charm bug is not running apt-get update in the install hook | 02:02 |
| davechen1y | because of 'reasons' the apt mirrors will 404 debs taht are not current | 02:03 |
| davechen1y | so if you have an old apt index on disk | 02:03 |
| rick_h_ | davechen1y: ok, I couldn't dupe it locally in my lxc but also not running trunk but 1.20.7 | 02:03 |
| davechen1y | and go to apt-get install some pacakge, if that pacakge has been replaced by a newer one in the archive | 02:03 |
| davechen1y | you get a 404 and apt returns status 1 | 02:03 |
| davechen1y | and then your day is ruined | 02:03 |
| davechen1y | rick_h_: i'd be very surprised if this was related to any version of juju | 02:03 |
| davechen1y | this is most likely a charm bug | 02:04 |
| davechen1y | well | 02:04 |
| davechen1y | that isn't true | 02:04 |
| davechen1y | older versions of juju would force apt-get update/upgrade on bootup | 02:04 |
| davechen1y | now we don't do this | 02:04 |
| rick_h_ | davechen1y: just stating the diff in my attempt to replicate vs reported bug | 02:04 |
| davechen1y | it shows up the charms that expect this to happen | 02:04 |
| axw | does anyone have time for a quick review? fixes a critical bug that I'd like to backport to 1.20 ASAP: http://reviews.vapour.ws/r/75/diff/# | 02:58 |
| * thumper looks | 02:59 | |
| thumper | axw: done | 03:02 |
| axw | thanks thumper | 03:02 |
| bradm | anyone about who can help with a juju deploy --to question? I want to have some charms deployed to lxc on a specific unit, as in openstack-ha/0 - I know you can do things like lxc:25, but is there a way to say lxc:openstack-ha/0 ? | 03:23 |
| bradm | (where openstack-ha is just a cs:ubuntu unit) | 03:23 |
| bradm | looks like juju-deployer supposed lxc:openstack-ha=0 style of deployment, if I'm reading the docs right | 03:30 |
| thumper | bradm: no, I don't think you can say that | 03:35 |
| bradm | thumper: thats a pity, we're using it quite extensively | 03:36 |
| thumper | menn0: got a minute for a hangout? | 03:51 |
| menn0 | thumper: yep | 03:56 |
| menn0 | thumper: where? | 03:56 |
| thumper | here -> https://plus.google.com/hangouts/_/g2ozjdukkzbchwadejkjpa5e2ma?hl=en | 03:56 |
| davechen1y | waigani: would you please find some time today to review http://reviews.vapour.ws/r/66/ | 04:08 |
| waigani | davechen1y: I'll try, probably this evening | 04:08 |
| davechen1y | ta | 04:09 |
| waigani | menn0, thumper: on trunk I get disconnected from the API if I upgrade AND specify the version e.g: juju --show-log upgrade-juju -e local --version 1.21-alpha2 --upload-tools | 04:11 |
| waigani | menn0: your script did not test with specifying the version | 04:12 |
| waigani | menn0: could you run that upgrade step (with the version) from 1.20 to verify? | 04:13 |
| menn0 | you mean the test case I used before | 04:13 |
| menn0 | ? | 04:13 |
| waigani | menn0: yep | 04:13 |
| waigani | menn0: so for me, on trunk this works: juju upgrade-juju --upload-tools | 04:14 |
| waigani | menn0: this does not: juju --show-log upgrade-juju -e local --version 1.21-alpha2 --upload-tools | 04:14 |
| waigani | the latter is taking from the original CI blocking bug | 04:14 |
| waigani | *taken | 04:15 |
| menn0 | waigani: I'll try it out on my machine | 04:15 |
| menn0 | waigani: works for me | 04:18 |
| menn0 | waigani: with master | 04:19 |
| menn0 | waigani: although I did see the "invalid entity name or password" error once | 04:19 |
| menn0 | waigani: the next attempt at juju status worked | 04:19 |
| waigani | menn0: yeah that's what I get | 04:19 |
| menn0 | waigani: I suspect that could be before once of the DB migration steps has run | 04:19 |
| waigani | menn0: that would be a bug woudn't it? | 04:20 |
| menn0 | waigani: I don't think so | 04:20 |
| waigani | menn0: I upgraded twice and got that error message both times | 04:20 |
| menn0 | waigani: that's just because you're trying juju status before the upgrade steps have run | 04:21 |
| menn0 | if you had waited slightly longer it would have been ok | 04:21 |
| waigani | menn0: yeah I get that, but from the user's point of view it does not look like that | 04:21 |
| waigani | menn0: it looks like it's broken | 04:21 |
| menn0 | waigani: well we could try and add more hacks like the one I did | 04:21 |
| menn0 | waigani: so that more stuff works even without the migration has run | 04:22 |
| waigani | menn0: or change the message | 04:22 |
| waigani | "upgrade in progress" | 04:22 |
| menn0 | except we want status to work during upgrades if possible | 04:23 |
| waigani | and if not possible? | 04:24 |
| menn0 | I guess if the login fails during an upgrade we could return "upgrade in progress" | 04:25 |
| menn0 | that's probably a good idea | 04:25 |
| menn0 | lets write up a ticket for that. | 04:25 |
| waigani | okay | 04:25 |
| menn0 | waigani: will you or should I? | 04:25 |
| waigani | menn0: I've got to finish testing this branch so i can land it and you can use it | 04:26 |
| menn0 | I'm already using it :) | 04:26 |
| menn0 | but I'll write up that ticket | 04:26 |
| waigani | oh - right well then | 04:26 |
| waigani | okay, I'm easy | 04:26 |
| thumper | axw: slight problem with the lastest branches you have landed with upgrade steps | 04:31 |
| thumper | axw: should have checked it earlier | 04:31 |
| thumper | I have waigani adding in upgrade steps for 1.21-alpha2 | 04:31 |
| thumper | which is where any upgrade steps should go since the lastest version was tagged | 04:31 |
| thumper | will not impact anyone going from release to release | 04:32 |
| waigani | ah... | 04:32 |
| thumper | but will if someone tries upgrading from 1.21-alpha1 to 1.21-alpha2 | 04:32 |
| thumper | which is supported but I'm not sure how formally | 04:32 |
| axw | thumper: I didn't think we bothered with that | 04:32 |
| axw | can fix though, not a big deal | 04:32 |
| thumper | I think we should bother | 04:32 |
| thumper | axw: very minor change, and can be done after waigani's branch lands | 04:33 |
| thumper | small tweak | 04:33 |
| axw | okey dokey, no problems | 04:33 |
| thumper | cheers | 04:33 |
| menn0 | waigani: here's bug 1372752 | 04:33 |
| mup | Bug #1372752: juju status fails with "invalid entity name or password" before DB migrations have run <juju-core:New for menno.smits> <https://launchpad.net/bugs/1372752> | 04:33 |
| waigani | menn0: thanks :) | 04:33 |
| waigani | thumper: talking of which, completed live testing | 04:36 |
| thumper | and... | 04:36 |
| waigani | thumper: replied to your rb comment | 04:36 |
| waigani | all good | 04:36 |
| thumper | cool | 04:36 |
| menn0 | waigani: \o/ | 04:37 |
| * thumper feels ever so slight amount of terror getting this in | 04:37 | |
| thumper | but someone has to be first | 04:37 |
| waigani | haha | 04:37 |
| waigani | like a lamb to the slaughter | 04:37 |
| thumper | waigani: done | 04:37 |
| thumper | waigani: I suggest the machine collection next | 04:38 |
| thumper | waigani: nothing like getting the big ones done first | 04:38 |
| waigani | thumper: yeah, sorry I took a wrong turn or two. I *think* I've got a pretty good idea how to do the rest now (famous last words) | 04:39 |
| waigani | thumper, right machinesC next? menn0 what are you doing? | 04:42 |
| menn0 | waigani: units | 04:42 |
| thumper | waigani: ack | 04:42 |
| waigani | okay cool | 04:42 |
| menn0 | thumper, waigani: I think we need to discuss these env UUID changes a little more on a hangout. now or tomorrow? | 04:48 |
| axw | thumper: won't the 1.21 upgrade steps always run in alpha versions? i.e. they'd run from 1.20 -> 1.21-alpha1, and also from 1.21alpha1->1.21-alpha2... up until 1.21 (non-alpha) | 04:49 |
| menn0 | thumper, waigani: I'm seeing a lot of places where we need to worry about filtering and I'm thinking the "minimal change" approach we're going with is going to be the less safe approach | 04:50 |
| axw | (I can test, but if you know the answer...) | 04:50 |
| thumper | menn0: now is fine | 04:50 |
| waigani | menn0: yep | 04:50 |
| thumper | axw: it collects all from where it is, to the version going to | 04:50 |
| waigani | hangout channel? | 04:50 |
| menn0 | thumper, waigani: yep, hangout channel | 04:50 |
| thumper | axw: so you are right for migrating from 1.20 to 1.21 | 04:50 |
| thumper | it collects all the 1.21-alpha1 and 1.21-alpha2 steps along the way | 04:51 |
| === urulama-afk is now known as urulama | ||
| bradm | ugh, this cloud-tools ppa being pinned lower is causing me issues | 06:05 |
| === Spads_ is now known as Spads | ||
| dimitern | fwereade, ping | 09:47 |
| fwereade | dimitern, pong | 09:47 |
| dimitern | fwereade, I've updated the firewaller PR: https://github.com/juju/juju/pull/799 and I'd appreciate if you have a look | 09:48 |
| fwereade | dimitern, will do | 09:48 |
| dimitern | fwereade, it turned out surprisingly hard to get to the unexported environTag inside *api.State from *apifirewaller.State | 09:49 |
| fwereade | dimitern, hmm, that's surprising, I could have sworn I'd seen a simple EnvironTag method | 09:54 |
| fwereade | dimitern, yeah, api.State.EnvironTag() | 09:55 |
| dimitern | fwereade, yes, in *api.State, but what you get in api/firewaller/New** is a base.FacadeCaller | 09:55 |
| dimitern | fwereade, so I added EnvironTag to the base.APICaller interface and exposed it as firewaller.State.EnvironTag by internally calling st.RawAPICaller().EnvironTag() | 09:56 |
| fwereade | dimitern, cool | 09:56 |
| fwereade | dimitern, sent a couple of quick responses to your responses, looking from the start again now | 09:56 |
| dimitern | fwereade, cheers | 09:57 |
| dimitern | jam, re exposing EnvironTag() from *api.State to facade callers ^^ I'd like to hear your thoughts as well | 09:57 |
| jam | dimitern: is there a Reviewboard version? | 09:58 |
| dimitern | jam, nope, when I proposed it, I forgot :/ | 09:58 |
| jam | dimitern: well, you can always add it at any time :) | 09:58 |
| jam | I guess the discussion is already here | 09:58 |
| dimitern | jam, indeed, but it will loose a bit of context after some comments were added on the PR | 09:59 |
| * jam really dislikes the "everything is State" because then it is confusing which foo.EnvironTag() you're actually calling. | 10:03 | |
| waigani | davechen1y: http://reviews.vapour.ws/r/66 reviewed as requested | 10:03 |
| davechen1y | waigani: ta | 10:04 |
| jam | dimitern: so is Tag.Id() a tag-thing or an id "thing" ? | 10:06 |
| jam | (envTag.Id() returns environ-UUID or just UUID ? | 10:06 |
| dimitern | jam, envTag.Id() == UUID, envTag.String() == "environment-<UUID>" | 10:08 |
| jam | dimitern: k, because there are lines like: https://github.com/juju/juju/pull/799/files#diff-06b44def560ee3d858becda14c28ba17L201 | 10:08 |
| dimitern | jam, that's one of rogpeppe's :) calling most facades *State or *API | 10:08 |
| jam | where it looks like it used to take something called a Tag, and it is now taking the UUID | 10:08 |
| jam | it may be that st.EnvironTag() returned the UUID, which was a bad name | 10:09 |
| dimitern | jam, yes it did - it was string | 10:09 |
| jam | dimitern: it was a string, but was it "environ-uuid" or "uuid" ? | 10:09 |
| jam | In which case, you should be passing .String() and not .Id() | 10:09 |
| rogpeppe | /me hears his name taken in vain :-) | 10:10 |
| dimitern | :) | 10:10 |
| rogpeppe | i don't understand the issue here | 10:10 |
| dimitern | jam, hmm, you're right in that case - it should be envTag.String(), I'll fix it (looking deeper the string is parsed as a tag in cacheChangedAPIInfo) | 10:10 |
| * rogpeppe probably doesn't need to | 10:10 | |
| jam | dimitern: k, it would appear we are lacking test coverage if you were able to change it without something breaking | 10:11 |
| dimitern | rogpeppe, it's about how naming a whole lot of things State in the api that's gets confusing | 10:11 |
| jam | state.State, api.State, uniter.State | 10:11 |
| dimitern | jam, I haven't run the full test suite yet, but I'm doing it now to see if anything will break | 10:11 |
| TheMue | United States of Juju | 10:11 |
| jam | TheMue: :) | 10:12 |
| rogpeppe | jam: given you've got always got the package prefix there, why is it confusing? | 10:12 |
| jam | dimitern: I'm going to need a bit longer to digest your proposal, I have to take my dog out before standup. | 10:12 |
| jam | rogpeppe: because you often don't have the package prefix | 10:12 |
| jam | like in all the packages | 10:12 |
| jam | and when looking at a diff | 10:12 |
| jam | all you see is "State" objects | 10:12 |
| jam | and you have to carefully reread what file you're currently in | 10:12 |
| rogpeppe | jam: but then you don't have the "State" name either, right? | 10:13 |
| dimitern | jam, sure, np | 10:13 |
| jam | rogpeppe: everything is just a State there | 10:13 |
| rogpeppe | jam: oh i see, in the package itself | 10:13 |
| jam | rogpeppe: and the bigger shortcomming is that then everyone abreviates their variable as "st" | 10:13 |
| rogpeppe | jam: but you should surely be aware of what file you're looking at? | 10:13 |
| jam | and you don't have a clue what "self.st" is | 10:14 |
| jam | rogpeppe: so the information is there, but it is 20 lines away past the line boundary (again, when looking at a diff) | 10:14 |
| rogpeppe | jam: if you're just looking at a diff without surrounding context, i can see | 10:14 |
| rogpeppe | jam: the idea behind it is that actually they're all windows onto the same underlying state. | 10:16 |
| rogpeppe | jam: a given package is only going to be using a single facade throughout, right? | 10:16 |
| dimitern | fwereade, re https://github.com/juju/juju/pull/799#discussion_r17899691 - do you mean the api watcher should return 0:juju-public changes (not the state watcher - it should still return global keys as changes I think, and the api watcher will convert them) | 10:21 |
| fwereade | dimitern, no | 10:21 |
| fwereade | dimitern, globalKeys should not leak out of state | 10:21 |
| fwereade | dimitern, they're meant to be purely internal | 10:21 |
| fwereade | dimitern, so fix the state watcher soon | 10:21 |
| fwereade | dimitern, and one day we'll fix the api watchers by inserting an id->tag translation thingy in a consistent place/way | 10:22 |
| dimitern | fwereade, ideally, we should have a PortsWatcher instead of StringsWatcher, which returns changes like []{MachineId: 0, NetworkName: "juju-public"} | 10:22 |
| fwereade | dimitern, yeah, that'd probably be nicer | 10:23 |
| dimitern | fwereade, ok, I'll do a follow-up for that | 10:23 |
| fwereade | dimitern, great, thanks | 10:23 |
| dimitern | jam, i can't hear you btw | 10:45 |
| jam | dimitern: my browser crashed | 10:45 |
| jam | dimitern: and after restarting it... it crashed again, I think I have to reboot after the last updated, bbiab | 10:45 |
| dimitern | TheMue, standup? | 10:46 |
| TheMue | dimitern: omw | 10:47 |
| jam | fwereade: dimitern: so we should have a discussion about how we want to handle Agents in a MESS scenario | 10:54 |
| jam | because so far, the MESS design was that the Environ was implicit to the connection | 10:54 |
| fwereade | jam, is this about the firewallers/provisioners for the various envs? | 10:55 |
| jam | It may be that for Agent's we'll want them to be multi-environment aware, but that wasn't the MESS design (As I understand it), because Login takes the environ-uuid, and not the rest of the system. | 10:55 |
| jam | fwereade: so this is brought up in the context of Dimiter's changes, but I'd like us to have a plan for what we're going to be doing so that we can work towards consistency. | 10:56 |
| fwereade | jam, I *think* it's doable without conflict -- ok, an environ is implicit to a connection, because the agents are running in the initial environment; but I don't think that prevents us from explicitly using tags for other environs, for those environs' workers | 10:56 |
| fwereade | jam, at the moment we pull the environ uuid out of the connection | 10:57 |
| fwereade | jam, but we are explicitly referencing environs in api calls | 10:57 |
| fwereade | jam, and I think it's relatively simple to move that awareness down a level, directly into the workers, without mucking with the actual API | 10:57 |
| fwereade | jam, ie without mucking with the wire format | 10:58 |
| fwereade | jam, there will still be code changes ofc :) | 10:58 |
| fwereade | jam, any places where we depend on the implicit environment will be problems | 10:58 |
| fwereade | jam, but I hope there aren't many of them | 10:58 |
| fwereade | jam, I've tried to spot them and block them | 10:59 |
| jam | fwereade: so Dimiter is needing EnvironTag from his api.Client object in order to pass it back into the api.Networker facade | 10:59 |
| jam | which means changing api.FacadeCaller to also include EnvironTag, etc | 10:59 |
| jam | which is why his changes are large-ish | 10:59 |
| jam | but if you're getting your context from your context, it doesn't make a ton of sense. | 10:59 |
| fwereade | jam, well, yes, I think I have a comment along those lines -- that there's no need for explicit knowledge of environ tag at the firewaller level at the moment, because the client can put it into the calls directly | 11:00 |
| fwereade | jam, dimitern: I waffled on that comment though | 11:00 |
| jam | fwereade: some of it would be "do you want to run a multi-environment firewaller" as in, 1 Firewaller worker for N environs | 11:01 |
| fwereade | jam, I do not want to do that | 11:01 |
| dimitern | fwereade, we're finishing standup, will respond shortly | 11:01 |
| fwereade | jam, both provisioner and firewaller are bloated enough | 11:01 |
| fwereade | jam, layering multi-environment-icity on top will be horrible | 11:01 |
| fwereade | jam, isn't it "just" a matter of having a parent worker that keeps track of the list of environs, and starts appropriate workers for each? | 11:02 |
| fwereade | jam, a provisioner-deployer, if you will | 11:03 |
| === fabrice is now known as fabrice|lunch | ||
| jam | fwereade: well the question is, do these things Login separately (and thus all have their own state connection), or is it all a shared connection and the Environ they are operating on needs to be explicit in the API | 11:03 |
| jam | I *thought* the plan was that the apiserver's State root object would know what environment you were working in. | 11:04 |
| jam | certainly if you are then talking about some *other* environment you'd have a tag for it | 11:04 |
| jam | But do we need the API to be "StartInstance(environTag, constraints, etc)" | 11:04 |
| fwereade | jam, different example please? StartInstance isn't our API ;p | 11:05 |
| jam | fwereade: AddMachine(environtag) ? | 11:05 |
| jam | that is at the Client level, though | 11:05 |
| fwereade | jam, WatchPorts(environTag)? | 11:05 |
| fwereade | jam, yes, I think it should be | 11:05 |
| fwereade | jam, implicit args have seemed to cause us more trouble than they're worth | 11:06 |
| jam | fwereade: so, we just did Login(environTag) for that worker, right? | 11:06 |
| fwereade | jam, but I think there's no conflict in being connected to the initial environment, and asking about some hosted environment | 11:06 |
| fwereade | jam, yes | 11:07 |
| jam | fwereade: I don't view environments as things that can be nested. Do you mean connected to the initial state server? | 11:07 |
| fwereade | jam, where are the workers for the hosted envs running, if not in the initial env? | 11:08 |
| fwereade | jam, blast, brb, keep talking | 11:08 |
| jam | a fair point. though the workers for the hosted environs could have their own connections | 11:11 |
| jam | fwereade: it feels like, if we want to be explicit about Environ, we pretty much need to add it to *every* request, which then means that we might as well make it common to every request | 11:11 |
| jam | and it should just go back to implicit | 11:11 |
| fwereade | jam, mmm, I'm not sure we really want N connections, one for each hosted env, from a single agent in a MESS | 11:13 |
| fwereade | jam, I think there's some additional distinction too but I'm having some trouble articulating it | 11:15 |
| dimitern | fwereade, jam, I'll make the environ tag argument to WatchOpenedPorts client-side firewaller facade implicit, but the server-side will still take Entities | 11:15 |
| dimitern | fwereade, jam, is that OK? | 11:15 |
| fwereade | jam, there's something worse about operate-on-nothing getting an implicit context than operate-on-something having it | 11:15 |
| fwereade | dimitern, yeah, that's what I'd favour here | 11:16 |
| dimitern | fwereade, cheers | 11:16 |
| fwereade | dimitern, with the expectation that we do add environ-awareness to FW and P at some point in the not-too-distant future | 11:16 |
| fwereade | dimitern, but that we don't want or need it this minute# | 11:16 |
| * jam is making some coffee, but I feel this is probably hangout worthy | 11:16 | |
| fwereade | dimitern, and that all we'd need to do to accommodate that is to tweak the client code on one side, and the auth on the other | 11:17 |
| fwereade | jam, just a sec, let me see | 11:17 |
| jam | fwereade: so if you are WatchPorts(environTag), then surely anything you then do because of that watch | 11:17 |
| jam | needs to take an environTag | 11:17 |
| dimitern | fwereade, by "don't want or need it this minute" do you also mean making WatchOpenedPorts at server-side not taking Entities as well? | 11:17 |
| jam | You can't do WatchPorts(envTag), => OpenPort() | 11:17 |
| jam | fwereade: and as for multiple "Conns", it could be as simple as a different logical connectiion, it wouldn't have to be a separate TLS /TCP session. | 11:18 |
| fwereade | jam, ha, yes, you're completely right | 11:19 |
| fwereade | dimitern, server-side we do want it | 11:19 |
| fwereade | dimitern, jam: I still *think* that this consideration is specific to provisioner/firewaller (maybe some others?) | 11:20 |
| dimitern | fwereade, ok | 11:20 |
| fwereade | jam, separating out logical connections would be nice, yeah | 11:20 |
| jam | fwereade: so I'm fine enough that we'll have some "things" that are actually aware of multiple environments (cross environ relationship manager), but I'd like to be cautious about adding EnvironTag to any API that isn't ever going to take 2 different ones | 11:20 |
| fwereade | jam, I'm still worried that every time we do a no-args thing we end up with problems | 11:21 |
| jam | fwereade: I think mixing noargs and args is going to be worse in the general case | 11:24 |
| jam | now, if we actually went all the way to stateless... then you have always-args | 11:24 |
| jam | which I'm actually happy with, but hasn't been the design we went for | 11:24 |
| fwereade | jam, heh, I just realised OpenPort doesn't apply -- but asking which ports are open still does | 11:25 |
| jam | fwereade: well, there is an "actually implement this change in the Provider" which at this point may be just a direct callout, but the logical "if I have an API that takes an environTag, then whatever I call as a result of that first API call then also needs an environTag" | 11:27 |
| jam | and I feel like, 90% ? of what we are going to do needs to then take an EnvironTag, which is why we made it implicit in the first place | 11:28 |
| fwereade | jam, I guess that may be the main point of difference? I feel like the firewaller/provisioner are relatively rare and special | 11:31 |
| jam | fwereade: so I think there is a definite case for different "rings" of agents | 11:31 |
| jam | There is the Client API for "juju" | 11:31 |
| jam | there is the Agent API for machine-10/unit-mysql-5 | 11:31 |
| jam | and there is the EnvironmentManager API for Provisioner/Firewaller/etc. | 11:32 |
| jam | It would be good to actually separate those out in code. | 11:32 |
| fwereade | jam, that does sound sane, yeah | 11:32 |
| fwereade | jam, certainly different forces apply to the different categories | 11:32 |
| jam | (and then there is the API server which is obviously underneath that) | 11:32 |
| fwereade | jam, I'm not wholly clear on how that separation would work though -- purely as an organisational thing? | 11:34 |
| dimitern | fwereade, re https://github.com/juju/juju/pull/799#discussion_r17900095 - do you think it's better to change "case changes ,ok := <-in:" to "case changes := <-in:" as it was? | 11:35 |
| fwereade | dimitern, no, I'd prefer to be explicit about checking for channel closes, they can happen | 11:36 |
| dimitern | fwereade, ok | 11:36 |
| jam | fwereade: right, just different directories (apiserver/RING0/provisioner) | 11:36 |
| dimitern | tasdomas, ping | 11:36 |
| fwereade | dimitern, it's the fact that MustErr can panic | 11:37 |
| jam | fwereade: given that is the whole point of Must, right? | 11:37 |
| fwereade | jam, sure | 11:37 |
| fwereade | jam, it's really the usage/existence of MustErr | 11:38 |
| jam | fwereade: I certainly think we would benefit from "Agent" vs "Client" apis, especially as we split up Client into many Facades | 11:38 |
| dimitern | tasdomas, re https://github.com/juju/juju/commit/7694614984932598535639e09129820f15b9d58d - changing dependencies.tsv to bump a revision of a versioned import path like gopkg.in/juju/charm.v3 instead of "releasing" a new version gopkg.in/juju/charm.v4 is BAD, let's not do that please | 11:38 |
| fwereade | jam, I feel like it should be more GiveMeSomeErrorIndicatingEitherTheWatcherErrOrTheFactThatThereIsntOne | 11:38 |
| dimitern | tasdomas, the whole point of having versioned import paths is to rely on "vX" meaning the same thing as the package evolves | 11:39 |
| jam | fwereade: EnsureErr ? (EnsureThatIHaveSomeSortOfError) | 11:40 |
| fwereade | jam, good idea | 11:40 |
| jam | most Must* mean panic | 11:40 |
| fwereade | jam, agree | 11:40 |
| fwereade | jam, and yes I think splitting the API up like that would be smart too | 11:40 |
| jam | fwereade: and in thinking about Client vs Agent, it does reveal that there are some meta-juju level APIs, but I'm not as sold that those are worth splitting out | 11:41 |
| jam | if we did, then where does Upgrader fit in, as it is also pretty "Meta" | 11:42 |
| fwereade | jam, it feels agenty to me but maybe I'm not thnking it through properly | 11:43 |
| === fabrice|lunch is now known as fabrice | ||
| jam | fwereade: you could consider the division to be the point where things run on machine-0, but you could also consider it to be where the worker is doing things about Juju vs things for the user | 12:04 |
| fwereade | jam, I don't think machine-0 is quite right | 12:04 |
| fwereade | jam, (or even state0server) | 12:04 |
| fwereade | jam, only-on-state-server though I guess? | 12:05 |
| jam | fwereade: sure, I'm not saying explicitly 0, but potentially "things running on agents with JobManageEnviron" ? | 12:05 |
| fwereade | jam, yeah, that sounds good to me | 12:06 |
| fwereade | dimitern, fwiw, I kinda think we should be dropping unitData, my spidey sense says there's a big simplification waiting t oget out | 12:15 |
| fwereade | dimitern, but I'm not sure it's one for this CL | 12:16 |
| dimitern | fwereade, ok, so this seems the last blocking issue, I'll repropose for a final look shortly (did a live test just now to make sure it works ok) | 12:25 |
| * fwereade lunch | 12:46 | |
| dimitern | fwereade, final look at https://github.com/juju/juju/pull/799 before landing? | 12:50 |
| natefinch | ericsnow: you around? | 12:59 |
| dimitern | fwereade, if you think it's ok, I'll queue it for landing, and I'm already working on 2 follow-ups - state opened ports watcher to report "0:juju-public" changes and environTag handling across the API facades | 13:05 |
| * dimitern late lunch | 13:08 | |
| perrito666 | ill tell you this my friends, spanish kb layout is a torture for programming | 13:29 |
| wwitzel3 | when ever I try to add an alternate KB layout my system hangs and I have to hard reset. So now i just type without the accents. | 13:31 |
| perrito666 | wwitzel3: why would you use accents in english? | 13:32 |
| wwitzel3 | perrito666: I wouldn't | 13:32 |
| wwitzel3 | perrito666: it is for French | 13:33 |
| perrito666 | ah hehe, I can write french with this layout but It is a bit like using emacs | 13:33 |
| wwitzel3 | haha | 13:33 |
| katco | perrito666: which is to say, awesome! right! right? guys? | 13:34 |
| mgz | can I get a stamp on <http://reviews.vapour.ws/r/78/>? needs rebasing now but can do that as I land | 13:34 |
| mgz | natefinch: maybe plz? ^ | 13:36 |
| perrito666 | katco: I need a couple of extra fingers | 13:36 |
| wwitzel3 | mgz: LGTM | 13:37 |
| perrito666 | katco: but the issue is more in the fact that I dont recall where they keys are since I dont use them | 13:37 |
| mgz | wwitzel3: thanks! | 13:38 |
| wwitzel3 | jam: ping, you still around? | 13:52 |
| dimitern | wwitzel3, it's perhaps a bit late for jam at this time | 13:52 |
| wwitzel3 | I figured as much, sometimes he hangs around though :) | 13:53 |
| perrito666 | dimitern: is not like many of us have lifes :p | 13:54 |
| dimitern | perrito666, :) well, some of us at least | 13:55 |
| perrito666 | shame on you | 13:55 |
| perrito666 | I actually am around while cooking dinner | 13:55 |
| perrito666 | :p | 13:55 |
| perrito666 | my washing machine is an excelent standing desktop | 13:55 |
| ericsnow | natefinch: you still need me? | 13:56 |
| natefinch | ericsnow: yeah... rbt is being annoying | 13:58 |
| ericsnow | natefinch: what's up? | 13:59 |
| natefinch | rbt setup-repo keeps failing for me | 14:00 |
| natefinch | ericsnow: we can talk in the standup | 14:01 |
| ericsnow | natefinch: k | 14:01 |
| === ChanServ changed the topic of #juju-dev to: https://juju.ubuntu.com | On-call reviewer: see calendar | Open critical bugs: 1372961 | ||
| sinzui | jam, natefinch can you get someone to look into bug 1372961 | 14:20 |
| sinzui | mgz, adeuring : just reported bug 1372961 and this is my investigation of the errors in CI https://docs.google.com/a/canonical.com/document/d/1HJozm1Yo_d3mC0QyQif9XfQXf5AxRtd86_aroMd1OpE/edit# | 14:22 |
| === alexlist is now known as alexlist` | ||
| natefinch | sinzui: ok | 14:25 |
| mgz | sinzui: ace, I'll read that | 14:29 |
| sinzui | mgz, there are some failures I think are not juju, I can you read the two logs I included to 1862? | 14:30 |
| sinzui | abentley, mgz, adeuring, jog: joyent very slow this week. tests fail because of timeouts, and we can see many tests fail during setup. We many need to take away their voting rights | 14:32 |
| abentley | sinzui: That's a shame. | 14:32 |
| sinzui | abentley, mgz, adeuring http://juju-ci.vapour.ws:8080/view/Cloud%20Health/job/test-cloud-joyent/ doesn't show the extent of the problem | 14:34 |
| wwitzel3 | anyone know off had any cmd client commands that have been refactored out of api/client and in to their own facade? | 14:34 |
| wwitzel3 | I'd be interested looking at examples of how we did it previously | 14:35 |
| fwereade | SHIT | 14:35 |
| * fwereade just overfilled bath | 14:36 | |
| fwereade | bbiab | 14:36 |
| wwitzel3 | I will reserve my laughing for later after we've determined there is no serious damage | 14:36 |
| fwereade | wwitzel3, it'll be fine | 14:41 |
| fwereade | wwitzel3, all on tiles | 14:41 |
| fwereade | wwitzel3, any damage there may be will be as nothing compared to the 3 separate pipes that went a week or two ago | 14:41 |
| fwereade | wwitzel3, my illusion of competence is the real victim here | 14:42 |
| wwitzel3 | that was too sad and self deprecating for me to laugh at all now | 14:43 |
| * wwitzel3 kicks the dirt | 14:43 | |
| fwereade | wwitzel3, ehh, I deserve at least a bit of pointing and laughing | 14:44 |
| * fwereade really *needs* a bath now after mopping all that up, but may be out of towels :-/ | 14:59 | |
| mbruzek | Hello juju developers. I noticed that I can no longer view my own logs on juju local. I need sudo to view them. There was a recent change to the log rotate function. Has anyone else experienced this problem? | 15:05 |
| katco | mbruzek: hi there. this was actually an issue raised by our security reviewers. there is some sensitive information that we felt any user on the system shouldn't be able to read. | 15:06 |
| katco | mbruzek: this changed back in... 1.18 i believe. does that help at all? | 15:06 |
| mbruzek | katco: Thanks for the reply. As a developer I regularly look at the logs to diagnose failures. This seems more recent to me, I keep up-to-date on juju releases, this seems like a 1.21 change as I was able to view the logs last week. | 15:07 |
| katco | mbruzek: interesting. this is what i am referring to: https://bugs.launchpad.net/juju-core/+bug/1286518 | 15:10 |
| katco | mbruzek: which logs are you trying to read? | 15:10 |
| mbruzek | I am usually interested in the unit-<charm-name>-#.log files because all-machines or the machine logs are too noisy. | 15:11 |
| mbruzek | katco: no this is not the problem I am seeing, I was able to view them as recently as last week. They are indeed 600 permissions, but now they seem to be owned by syslog. | 15:12 |
| mbruzek | -rw------- 1 syslog syslog 25642 Sep 23 09:57 machine-0.log | 15:12 |
| mbruzek | which is != mbruzek, thus the need for sudo. | 15:12 |
| katco | natefinch: ping ^^^ | 15:13 |
| katco | mbruzek: does seem like a new issue. what's the path? in ~/.juju? | 15:13 |
| natefinch | katco: in a meeting, but we did just change log rotation stuff... that may have changed things for local accidentally. | 15:14 |
| katco | natefinch: ok np, thanks for the response. | 15:15 |
| katco | natefinch: any dev i should ping? | 15:15 |
| mbruzek | katco: I actually see the logs all owned by syslog, but in up to 3 groups (adm, syslog, and fuse) | 15:15 |
| mbruzek | -rw------- 1 syslog adm 26787 Sep 23 09:57 all-machines.log | 15:15 |
| mbruzek | -rw------- 1 syslog syslog 25642 Sep 23 09:57 machine-0.log | 15:15 |
| mbruzek | -rw------- 1 syslog fuse 44601 Sep 23 09:56 unit-mongodb-0.log | 15:15 |
| katco | mbruzek: what's the path? | 15:15 |
| natefinch | katco: wwitzel3 may know about the all-machines stuff | 15:15 |
| katco | natefinch: ty sir | 15:15 |
| mbruzek | katco: the path I am looking at is /var/log/juju-mbruzek-local/ the one you referenced (~/.juju/local/log) is a symbolic link there. | 15:17 |
| mbruzek | katco: your log location would be /var/log/juju-katco-local/ I suspect. | 15:17 |
| katco | mbruzek: not quite, but close ;) | 15:18 |
| * mbruzek does not know the username you use. | 15:18 | |
| katco | mbruzek: i'll have to defer to natefinch et. al. since they implemented the new log rotation. looking at my log directory, it looks like my permissions fix may have actually been undone in addition to the bug you're seeing | 15:18 |
| katco | mbruzek: all of my stuff is world-readable and owned by root | 15:19 |
| mbruzek | katco: my memory is not clear but I KNOW I was able to view the files as recently as last week. What version is your juju. | 15:20 |
| katco | mbruzek: i run tip | 15:20 |
| mbruzek | of course you do! | 15:20 |
| katco | mbruzek: but i suppose it's possible that once the logs are created correctly, the code would never recreate them, so only new log files would have issues | 15:21 |
| mbruzek | $ juju version | 15:21 |
| mbruzek | 1.21-alpha1-trusty-amd64 | 15:21 |
| katco | 1.21-alpha2-trusty-amd64 | 15:21 |
| mbruzek | katco: That is a possibility I often destroy-environment and my understanding is that wipes out the "local" directory. | 15:22 |
| katco | mbruzek: but maybe not anything buried in var? it would be elucidating to manually remove the log files to see what juju creates | 15:23 |
| mbruzek | katco: Let me do that now... | 15:24 |
| mbruzek | katco: destroy-environment does not wipe out the log files, but it does remove ~/.juju/local directory. | 15:25 |
| katco | mbruzek: how does juju create the log files if they don't exist? | 15:25 |
| mbruzek | the ~/.juju/local directory only contained a symbolic link to /var/log/juju-mbruzek-local/ | 15:26 |
| katco | mbruzek: right; i'm wondering if you move/remove log files under /var how juju will recreate them. i.e.: are you seeing a ghost of a bug that is now fixed | 15:27 |
| mbruzek | katco: ahh! Let me try that | 15:28 |
| === fabrice is now known as fabrice|family | ||
| mbruzek | katco: http://pastebin.ubuntu.com/8411564/ | 15:30 |
| katco | mbruzek: interesting. yep, i think you need to talk to natefinch's team | 15:30 |
| mbruzek | I moved the old directory and the new one was created upon bootstrap | 15:30 |
| mbruzek | katco: OK thanks for troubleshooting with me. | 15:31 |
| katco | wwitzel3: perrito666: ericsnow: ping ^^^ | 15:31 |
| katco | mbruzek: sorry i couldn't help more. i tuned in b/c i thought i had worked in the space you were describing. | 15:31 |
| * mbruzek is glad someone tuned in. | 15:31 | |
| mbruzek | wwitzel3, natefinch, perrito666, ericsnow if you are done with meeting please ping me. | 15:32 |
| natefinch | mbruzek: will ping once I'm out | 15:37 |
| dimitern | fwereade, here's the follow-up about the state.openedPortsWatcher http://reviews.vapour.ws/r/85 | 15:46 |
| dimitern | natefinch, ^^ as OCR, can you take a look as well please? | 15:47 |
| natefinch | dimitern: sure | 15:48 |
| fwereade | dimitern, LGTM with a trivial | 15:53 |
| dimitern | fwereade, cheers! | 15:53 |
| jcw4 | rogpeppe: your review is much appreciated! Will discuss and get your suggestions implemented | 15:55 |
| rogpeppe | jcw4: np | 15:55 |
| natefinch | evilnickveitch: https://github.com/juju/docs/pull/174 | 15:55 |
| rogpeppe | jcw4: i'm not sure i've finished, but i'm taking a break from it for a while. | 15:55 |
| rogpeppe | jcw4: i'd really like to see doc comments for everything | 15:56 |
| jcw4 | rogpeppe: cool. Some of your comments I can explain, but some of your suggestions (charminfo) make a lot of sense to me | 15:56 |
| rogpeppe | jcw4: the last thing i was looking at was Cancel - i'm not sure quite how that's meant to work | 15:56 |
| jcw4 | rogpeppe: Yeah, I should have added the doc comments like you suggested | 15:56 |
| jcw4 | rogpeppe: I'll be updating today with those comments, etc. | 15:57 |
| rogpeppe | jcw4: great, thanks | 15:57 |
| * fwereade is really tired and taking a break, will be back in the evening sometime | 16:00 | |
| wwitzel3 | 6 | 16:08 |
| wwitzel3 | sure, why not | 16:08 |
| wwitzel3 | mbruzek: the permission commit that katco referenced was on 2014-07-02, that is when that went in to master. | 16:11 |
| mbruzek | wwitzel3: Would you know why I was able to look at the logs last week and not this week? The owner looks different between katco and my system. | 16:12 |
| wwitzel3 | mbruzek: the only thing I can think of, I think was mentioned before, if the old logs were not cleaned up for some reason and had the old permissions. | 16:14 |
| wwitzel3 | mbruzek: actually let me check when that commit was actually merged in .. the day it was commited and the day it was merged can be very different | 16:15 |
| mbruzek | wwitzel3: Please do, I think this is a big change that will make it harder for charm authors to diagnose problems when they are writing charms. | 16:15 |
| wwitzel3 | mbruzek: https://github.com/juju/juju/pull/232 .. was merged in 02 Jul 2014. Not sure why you would of had access to the logs since then, if they had been newly created. | 16:20 |
| mbruzek | wwitzel3: ack. Thanks. I am kind of concerned about this change since it will be more difficult for authors to look at the log files of their own units to diagnose problems. Was there anything in there anything about the owner changed? | 16:22 |
| wwitzel3 | mbruzek: the original ticket is here, https://bugs.launchpad.net/juju-core/+bug/1286518 and has a comment that shares your concern, I'd recommend bumping that | 16:23 |
| mup | Bug #1286518: juju log files should not be world readable <logging> <juju-core:Fix Released by cox-katherine-e> <https://launchpad.net/bugs/1286518> | 16:23 |
| mbruzek | wwitzel3: this link is likely why I have not seen it until this week. https://bugs.launchpad.net/juju-core/+bug/1286518 | 16:23 |
| mbruzek | It looks like it was fix released on 09/10 | 16:24 |
| wwitzel3 | mbruzek: yep | 16:24 |
| mbruzek | thanks wwitzel3. | 16:27 |
| wwitzel3 | mbruzek: yep, np | 16:27 |
| katco | wwitzel3: ah missed that point. i just assumed it had been released awhile ago | 16:28 |
| katco | wwitzel3: ty | 16:28 |
| wwitzel3 | katco: np | 16:30 |
| === urulama is now known as urulama-afk | ||
| * katco needs to get her glasses adjusted again (sigh). bbiab. | 18:02 | |
| * natefinch did not realize glasses were something one got adjusted | 18:04 | |
| perrito666 | I am not sure if she speaks about the prescription or the nose thing | 18:05 |
| perrito666 | I have to change the nose thinguies every 3 months | 18:05 |
| perrito666 | although the ones I got last time lasted for the whole cycle :p | 18:06 |
| perrito666 | ericsnow: ping | 18:13 |
| ericsnow | perrito666: hey | 18:14 |
| perrito666 | ericsnow: I need your help swimming trough a sea of indirections | 18:14 |
| ericsnow | perrito666: k | 18:14 |
| perrito666 | ericsnow: lets go priv | 18:14 |
| === Ursinha is now known as Ursinha-afk | ||
| natefinch | turns out the answer is "yes" to the question "are the outdoor receptacles on the same circuit as my office?" | 18:33 |
| natefinch | not that it was a question I had intended to ask today | 18:35 |
| perrito666 | apparently your AP is not on that circuit | 18:36 |
| perrito666 | :p | 18:36 |
| perrito666 | I for once have the internet connection on a separate 6mm cable line along with the tv, the ps3 and the fridge | 18:37 |
| perrito666 | because priorities | 18:37 |
| natefinch | haha | 18:38 |
| natefinch | YEah, I'm currently actually running an ethernet cord from the other room to here.... I have an ethernet wall jack I need to install... but, well, it involves getting into the crawlspace under my office, and... priorities | 18:39 |
| perrito666 | lol | 18:39 |
| perrito666 | well when I moved here the house was under remodeling so I just passed special cables for the important stuff, a different circuit breaker line and walled the home theater cables so the satellite speakers look wireless | 18:40 |
| natefinch | nice | 18:40 |
| natefinch | Evidently Mark Shuttleworth is annoyed that HA is only a single command "ensure-availability" for both starting HA and recovering from a failed machine, so he wants us to change it. | 18:41 |
| natefinch | Which is valid | 18:43 |
| natefinch | I wonder if this is my penance for actually documenting it :) https://juju.ubuntu.com/docs/juju-ha.html | 18:43 |
| ericsnow | natefinch: no good turn goes unpunished :) | 18:44 |
| natefinch | No, I kind of agree.... I just was ready to not look at HA for another 6 months at least :) | 18:44 |
| === Ursinha-afk is now known as Ursinha | ||
| natefinch | ericsnow, perrito666, wwitzel3: who wants to be in the meeting to talk about revamping HA? I may be able to find the time to do it, but I might not... which means it might get delegated. | 19:09 |
| katco | natefinch: i just got this pair. they fit to your nose/ears differently and apparently you have to go through a few rounds of adjustments before they don't hurt your head | 19:10 |
| ericsnow | natefinch: I will if you need me to but would rather stay focused on backups | 19:10 |
| perrito666 | katco: so how does that work, do they adjust your nose and ears? | 19:11 |
| perrito666 | :p | 19:11 |
| natefinch | ericsnow: yeah, good point... you'd disqualified | 19:11 |
| natefinch | (lucky ;) | 19:11 |
| katco | perrito666: lol no they put the frames in this heat thing and bend them | 19:11 |
| ericsnow | natefinch: :) | 19:11 |
| katco | perrito666: this is all new to me, but my wife is a veteran glass wearer lol | 19:11 |
| natefinch | katco: ahh, I didn't realize that was necessary | 19:11 |
| perrito666 | katco: ah yes, you can do that in your house with a cheap hair dryer | 19:11 |
| natefinch | having never had eyeglasses myself... | 19:12 |
| katco | natefinch: apparently so | 19:12 |
| katco | natefinch: i literrally got my first pair 4 days ago | 19:12 |
| natefinch | katco: I naively assumed they were like sunglasses where you can just slap them on | 19:12 |
| natefinch | katco: ahh | 19:12 |
| perrito666 | natefinch: well after wearing a few days you can notice how they slide on your face | 19:12 |
| katco | but now i can smugly say, "of _course_ you have to adjust them (gufaw)" | 19:12 |
| perrito666 | and also the material settles and you might need to adjust a bit | 19:12 |
| perrito666 | if the ear thinguies are not properly adjusted the nose ones will hurt your skin because of the weight and vice versa | 19:13 |
| natefinch | maybe this is how they justify paying $200 for some wire and plastic | 19:13 |
| katco | lol | 19:13 |
| perrito666 | natefinch: that is how they justify getting laser surgery | 19:14 |
| natefinch | haha | 19:14 |
| === fabrice|family is now known as fabrice | ||
| natefinch | ericsnow: you around? | 19:55 |
| ericsnow | natefinch: yeah | 19:55 |
| natefinch | ericsnow: actually, nevermind. I had problems with rbt, but realized I don't actually need that code to get onto reviewboard anymore | 19:56 |
| ericsnow | natefinch: ok | 19:56 |
| === Ursinha is now known as Ursinha-afk | ||
| === Ursinha-afk is now known as Ursinha | ||
| === Ursinha is now known as Ursinha-afk | ||
| === Ursinha-afk is now known as Ursinha | ||
| wwitzel3 | if I register a facade and put the import in all facades .. why am I still getting an ERROR unknown object type "RunCommand" | 21:33 |
| katco | wwitzel3: did you update your servers? | 21:33 |
| katco | i.e. juju upgrade-juju --upload-tools | 21:34 |
| wwitzel3 | katco: yep :/ | 21:34 |
| katco | wwitzel3: hrm. that was my guess! :) | 21:34 |
| cmars | thumper, time for a hangout? | 22:01 |
| thumper | cmars: aye, already there | 22:01 |
| === Ursinha is now known as Ursinha-afk | ||
| davecheney | hazmat: ping | 23:22 |
| waigani | menn0: so there is a switch in state.parseTag. In the case for services I've set the id to DocID. You'll need to do the same for the unit case. The other place you'll have to do this is in allWatcherStateBacking.docID | 23:27 |
| thumper | cmars: review done | 23:27 |
| cmars | thumper, thanks | 23:27 |
| waigani | menn0: allWatcherStateBacking.docID is in the megawatcher, it's only used in the Changed function there. | 23:27 |
| waigani | menn0, thumper, davecheney: if every watched entity was a tag (i.e. had a .Tag() method that returned a tag of the entity), then we could use state.parseTag(tag) whenever we needed to get the docID | 23:32 |
| thumper | waigani: I don't think that is the case though | 23:33 |
| thumper | is it? | 23:33 |
| thumper | pretty sure we watch many things that are only losely linked to entities | 23:33 |
| waigani | thumper: note the *if* | 23:33 |
| * thumper nods | 23:34 | |
| waigani | just an observation while working on that branch | 23:34 |
| thumper | although might be intersting to have something that goes from the shitty globalId() ('m#3' for machine-2) to a tag | 23:34 |
| thumper | waigani: definitely worth leaving a note to think about | 23:34 |
| waigani | so forget entities, basically if anything that is watched is a tag... | 23:35 |
| wwitzel3 | since I have a fresh group .. if I register a facade and put the import in all facades .. why am I still getting an ERROR unknown object type "RunCommand" | 23:52 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!