| thumper | wallyworld_: ack | 00:23 |
|---|---|---|
| wallyworld_ | thumper: thanks for review | 01:47 |
| thumper | np | 01:48 |
| === kadams54 is now known as kadams54-away | ||
| stokachu | if i wanted to query AllMachines from the state package is there a preferred method of accessing that data? i used to do a juju.NewConnFromName which would expose that state api | 04:31 |
| stokachu | i can't seem to find an alternative way now since that has disappeared | 04:31 |
| thumper | stokachu: hmm... | 04:36 |
| thumper | stokachu: where and why? | 04:37 |
| thumper | stokachu: short answer is you should use the client API | 04:37 |
| thumper | stokachu: which you should be able to get the machine information out of | 04:37 |
| thumper | using the status command | 04:37 |
| thumper | hmm... 16:30 and brain is going fuzzy | 04:38 |
| thumper | about 3-4 hours later than yesterday | 04:38 |
| stokachu | thumper: yea that's what im using now, im just updating https://github.com/battlemidget/juju-sos/blob/master/cmd.go | 04:38 |
| stokachu | to work with latest juju code | 04:38 |
| stokachu | ill push everything through the api though, makes more sense anyway | 04:38 |
| thumper | stokachu: yeah, juju.Conn isn't the way | 04:38 |
| stokachu | thumper: cool, thanks for confirming the api client | 04:39 |
| thumper | stokachu: also, change the logger to be 'juju.cmd.sos' | 04:39 |
| stokachu | ah ok will fix that too | 04:39 |
| thumper | or | 04:39 |
| thumper | juju.plugin.sos | 04:39 |
| thumper | fairly arbitrary definition | 04:39 |
| thumper | plugin probably makes more sense | 04:39 |
| stokachu | ok sounds good ill fix that too | 04:40 |
| thumper | cheers | 04:40 |
| stokachu | thanks :) | 04:40 |
| thumper | np | 04:40 |
| dimitern | jam, dooferlad, please take a look http://reviews.vapour.ws/r/1465/ - follow-up to the branch from yesterday, this time adding tests | 08:53 |
| dooferlad | dimitern: *click* | 08:55 |
| dimitern | dooferlad, ta | 08:56 |
| jam | dimitern: why are we getting "not supported" rather than "EPerm" for NewMachineTag("42") ? | 09:11 |
| jam | it makes me wonder if we should be doing the address check later. | 09:11 |
| jam | I'm not particularly worried about it, just made me wonder | 09:11 |
| dimitern | jam, well, it is a valid tag - why ErrPerm? | 09:16 |
| jam | the machine exists? | 09:16 |
| jam | (because we don't do NotFound | 09:17 |
| jam | ) | 09:17 |
| dimitern | jam, it does not exists, but that's fine, because you're not supposed to call the method at all without the feature flag | 09:18 |
| jam | dimitern: yeah, seems ok | 09:21 |
| jam | you're not leaking information about a particular entry | 09:21 |
| dimitern | jam, cheers | 09:21 |
| dimitern | jam, actually that issue you raised was bugging me as well for its behavioral inconsistency, so I'm changing it to return results with the same len as the passed args when the flag is not on | 09:38 |
| * fwereade has so far found 27 workers running in the machine agent for one reason or another and knows he's missing some :/ | 10:19 | |
| mattyw | dimitern, are you around for a quick review? http://reviews.vapour.ws/r/1466/ | 11:04 |
| mattyw | dimitern, (I'm ocr today so I can't do it) | 11:05 |
| wwitzel3 | perrito666: ping | 11:14 |
| perrito666 | wwitzel3: pong | 11:38 |
| wwitzel3 | ericsnow: ping | 11:47 |
| fwereade | perrito666, I'm wondering if you'd know: is the limitLoginsDuringRestore stuff goroutine-safe? | 11:49 |
| perrito666 | I think it is | 11:50 |
| perrito666 | fwereade: btw, hi :) | 11:50 |
| fwereade | perrito666, can you point me to how it is? all I can see are a bunch of unprotected fields in the agent, and callbacks to methods using them in the api server | 11:51 |
| fwereade | perrito666, hi indeed :) | 11:51 |
| dimitern | mattyw, sure, will have a look in a bit | 11:52 |
| perrito666 | fwereade: can you ask me again tomorrow I really really am trying to fit something into 1.24 for ian | 11:52 |
| fwereade | perrito666, sure, np | 11:52 |
| mgz | hm, the pre-push hook doesn't check that the *tests* build | 11:56 |
| dimitern | mattyw, this just occurred to me: the reason why you're getting 2 events on linux and only 1 on windows might be because windows does not run the apiserver (yet), where the server-side watcher resided | 11:56 |
| mattyw | dimitern, windows doesn't run the apiserver????? | 11:56 |
| dimitern | mattyw, well, not that I know of - bootstrap is not supported on windows and there's some issues around packaging mongo with ssl on windows | 11:57 |
| dimitern | mattyw, reviewed | 11:57 |
| mattyw | dimitern, cheers | 11:59 |
| mattyw | dimitern, what do we do in tests then under windows? | 11:59 |
| dimitern | mattyw, but then again - this could have nothing to do with windows not running an apiserver | 11:59 |
| dimitern | mattyw, we test we can use a juju client on windows to talk to a bootstrapped environment on ubuntu | 12:00 |
| jam | dimitern: fwereade: you coming to the malta powow? | 12:00 |
| dimitern | jam, sure, omw | 12:00 |
| fwereade | jam, just a mo | 12:00 |
| dimitern | pow's done, wow's mostly :) | 12:00 |
| jam | :) | 12:00 |
| mattyw | dimitern, yeah - I think we're only dealing with state | 12:00 |
| mattyw | dimitern, looking into it now - but as you have shown an "interest" it's you I'm coming to if I have questions ;) | 12:01 |
| dimitern | mattyw, no sweat :) | 12:01 |
| jam | dimitern: I'm pretty sure you can at least run the infrastructure of the API server on Windows. | 12:02 |
| jam | I'm not sure that "jujud' runs, but that is different | 12:02 |
| mgz | wwitzel3: did you mean to remove all the windows deps in your gosigma dependencies.tsv update? | 12:27 |
| wwitzel3 | mgz: nope :( | 12:43 |
| mgz | wwitzel3: happened to not go through anyway, so easy enough to fix | 12:43 |
| wwitzel3 | mgz: yep, already fixed, thanks | 12:44 |
| fwereade | dimitern, jam, anybody: this is my current best guess at the workers we might run in a machine agent: http://paste.ubuntu.com/10865749/ | 12:55 |
| dimitern | fwereade, looking | 12:55 |
| fwereade | dimitern, jam, annybody: I know it lacks detail and/or existence in several bits where one worker spawns many others (eg container provisioning, per-env provisioners, etc) | 12:55 |
| fwereade | any suggestions, clarifications, additions gratefully received | 12:55 |
| dimitern | fwereade, sure, will let you know | 12:56 |
| jam | fwereade: my irc client seems to have not buffered the original request, I'm interested to look, but can you link it again? | 12:57 |
| dimitern | fwereade, you've missing one of the most recent ones - worker/addresser | 12:57 |
| fwereade | jam, http://paste.ubuntu.com/10865749/ | 12:57 |
| dimitern | fwereade, runs on each master state server (like cleaner, resumer) | 12:58 |
| fwereade | dimitern, is that a *new* worker that uses a direct state connection? grrbml grrmbl | 12:59 |
| dimitern | fwereade, also the workers in worker/provisioner are fairly twisted, but I know most of their deps from my dealings with lxc containers | 12:59 |
| dimitern | fwereade, it's supposed to be run on the state servers only | 12:59 |
| fwereade | dimitern, I have high hopes that one day we will have a simple provisioner that is no more or less than a watcher/broker adapter | 13:00 |
| fwereade | dimitern, it's still something reaching into the database directly | 13:00 |
| dimitern | fwereade, and it needs cloud creds as well | 13:01 |
| fwereade | dimitern, and? | 13:01 |
| dimitern | fwereade, the addresser | 13:01 |
| fwereade | dimitern, let's not violate layers unless we have to | 13:01 |
| dimitern | fwereade, +1 | 13:01 |
| fwereade | dimitern, nothing should touch state apart from the apiserver itself | 13:01 |
| dimitern | fwereade, but frankly it's not worse than the resumer and cleaner | 13:01 |
| fwereade | dimitern, they should have been done in the initial pass as well | 13:02 |
| fwereade | dimitern, not sure why they weren't | 13:02 |
| fwereade | dimitern, api-everywhere was quite the goal for us at one point | 13:02 |
| dimitern | fwereade, because we said "meh - it's only on the apiserver, so it's fine" | 13:02 |
| fwereade | dimitern, the apis might be simple, but that's no reason to drop the benefits | 13:03 |
| fwereade | dimitern, there's no *general* statement that particular workers must be bound to particular machines | 13:04 |
| dimitern | fwereade, agreed, however it's easy to introduce apis for such cases at any point | 13:04 |
| jam | fwereade: TerrifyinglyExtremeSuiciderName :) | 13:04 |
| fwereade | dimitern, every time we make a choice like that we add to the friction and make it harder to move the workers from one place to another easily | 13:06 |
| fwereade | dimitern, please add a card to move the new one behind an api (and if you can bear to add 2-method apis for the others, that would be awesome...) | 13:07 |
| dimitern | fwereade, will make a note of it, ok | 13:07 |
| fwereade | dimitern, cheers | 13:08 |
| ericsnow | wwitzel3: pong | 13:45 |
| mup | Bug #1447174 was opened: state crash with juju terminate-machine --force X <juju-core:New> <https://launchpad.net/bugs/1447174> | 13:48 |
| sinzui | dimitern, can you read my addition (a comment) to the proposed 1.23.1 release notes about the feature flag? https://docs.google.com/document/d/1JApj2hsEwKKmAqDmIayGrZ1fkKNPQWvyDmv_bKOcQek/edit | 14:31 |
| dimitern | sinzui, sure, will look in a bit | 14:32 |
| sinzui | dimitern, the release is actually live for some people. Can you look now? | 14:32 |
| dimitern | sinzui, ok, looking now | 14:33 |
| dimitern | sinzui, looks good | 14:41 |
| sinzui | thank you dimitern | 14:41 |
| ericsnow | cherylj: I left a short review on your "system" command patch | 14:43 |
| ericsnow | cherylj: basically, "system" is pretty ambiguous, but simply making the doc for the command more explicit will be sufficient to address that IMO | 14:44 |
| cherylj | ericsnow: thanks for the feedback. There have been discussions around "server" vs. "system", and things landed on "system". I'll see if I can make it clearer. | 14:51 |
| ericsnow | cherylj: I think "system" is fine as long as we are clear about its context (in documentation and help strings) | 14:51 |
| wwitzel3 | mgz: can you stop #2915 build, it is missing a commit | 15:18 |
| mgz | wwitzel3: done | 15:19 |
| wwitzel3 | mgz: ty | 15:19 |
| === urulama is now known as urulama|afk | ||
| mup | Bug #1447174 changed: state crash with juju terminate-machine --force X <terminate-machine> <vivid> <juju-core:New> <https://launchpad.net/bugs/1447174> | 15:42 |
| === kadams54 is now known as kadams54-away | ||
| perrito666 | wwitzel3: hey, do you currently have a vmaas for testing? | 15:55 |
| perrito666 | http://pastebin.ubuntu.com/10866692/ <-- I am trying to bootstrap my vmaas and getting this, Ill try master to see if it is my branch, but looks like not | 15:56 |
| mup | Bug #1447234 was opened: juju prints "error" when deploying yet no units are in error <charms> <improvement> <set> <juju-core:Triaged> <https://launchpad.net/bugs/1447234> | 16:03 |
| mup | Bug #1447235 was opened: add stdin support to "juju set" <juju-core:New> <https://launchpad.net/bugs/1447235> | 16:03 |
| === dpb1_ is now known as dpb1 | ||
| wwitzel3 | perrito666: yeah, I have one | 17:00 |
| perrito666 | wwitzel3: could you try to deploy master and tell me if it works or you get the error I pasted above? | 17:32 |
| wwitzel3 | perrito666: yep, I can give that a shot | 17:36 |
| wwitzel3 | perrito666: working just fine so far | 17:37 |
| wwitzel3 | perrito666: what version of maas? | 17:37 |
| perrito666 | mm, good question, I had to kill it to get resources in the machine, but ill look as soon as I finish running tests | 17:38 |
| perrito666 | wwitzel3: if it reaches the end ofbootstrap succesfully then its ok, and it is most likely something in my vmaas | 17:39 |
| perrito666 | tx a lot btw | 17:40 |
| wwitzel3 | perrito666: same failure | 17:40 |
| perrito666 | ok, so I am not crazy, if I had to guess I would say that the changes merged in the sprint to support centos broke that | 17:42 |
| * perrito666 looks at gsamfira | 17:43 | |
| wwitzel3 | perrito666: I'm trying 1432affde02cd81b354871d679804beca9bbe21a right now | 17:46 |
| wwitzel3 | perrito666: yeah, so it is after 1432affde02cd81b354871d679804beca9bbe21a if you want to do a git bisect, probably an easy find | 17:49 |
| perrito666 | wwitzel3: tx a lot, I think Ill try after I finish this | 17:49 |
| gsamfira | perrito666: pinging bogdanteleaga | 17:52 |
| perrito666 | gsamfira: I am not saying it was that, it is just an educated guess | 17:53 |
| gsamfira | perrito666: I think I know where the problem is. Should be an easy fix. | 17:53 |
| === kadams54 is now known as kadams54-away | ||
| === kadams54-away is now known as kadams54 | ||
| === kadams54 is now known as kadams54-away | ||
| === arosales__ is now known as arosales | ||
| wallyworld_ | thumper: got a minute? | 23:44 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!