| thumper | wallyworld_: I'm in the hangout now if you feel like joinging | 00:59 |
|---|---|---|
| thumper | or joining | 00:59 |
| thumper | o/ axw | 00:59 |
| axw | heya thumper | 00:59 |
| thumper | axw: just for you https://codereview.appspot.com/43730044/ | 01:00 |
| axw | cool beans | 01:00 |
| davecheney | sinzui: i cannot reproduce that failure in aws | 01:03 |
| davecheney | does anyone have hp credentials I can use ? | 01:03 |
| axw | thumper: why did you end up not using they private key we already have? | 01:16 |
| thumper | axw: it felt wrong | 01:17 |
| thumper | that's the guts of it | 01:17 |
| thumper | hard to explain | 01:17 |
| axw | mmk | 01:17 |
| thumper | I think separate keys for different jobs is a good thing | 01:18 |
| wallyworld_ | +1 | 01:19 |
| thumper | ugh | 01:44 |
| thumper | need coffee | 01:45 |
| * thumper decides not to wait for Rachel | 01:45 | |
| axw | wallyworld_: why did you remove TestNoWarningForDeprecatedButUnusedEnv? | 02:53 |
| * axw is particularly slow today | 02:53 | |
| wallyworld_ | axw: not sure. that code block was in a place that tested for deprecated attr processing which was moved. i must have missed the fact that there was a test which should have been kept | 02:54 |
| wallyworld_ | i'll take a look and add it back if needed. | 02:55 |
| axw | wallyworld_: thanks | 02:55 |
| wallyworld_ | i'm the one who is slow | 02:55 |
| wallyworld_ | thumper: it seem we already show rev info in status, at least at the service level. the charm url includes the rev no | 04:48 |
| wallyworld_ | did we need to extend that to the unit level? is it possible to have units with different rev numbers to the parent service? | 04:48 |
| === davecheney is now known as hartman | ||
| thumper | wallyworld_: I don't think so | 07:46 |
| thumper | wallyworld_: I think all our charms should be at the same version | 07:46 |
| thumper | wallyworld_: and all we actually care about is the service itself, not the individual units | 07:46 |
| thumper | I think | 07:46 |
| wallyworld_ | thumper: we do record versions for unit charms and i can see how a unit charm could get out of date with the nominal service version so we may want to report on both | 08:03 |
| wallyworld_ | thumper: fwiw, i've hacked togethe rsome code to produce the following https://pastebin.canonical.com/102221/ | 08:03 |
| dimitern | rogpeppe, morning | 08:46 |
| rogpeppe | dimitern: hiya | 08:46 |
| dimitern | rogpeppe, I decided to change the code to calculate the hash in place | 08:47 |
| rogpeppe | dimitern: why? | 08:47 |
| dimitern | rogpeppe, instead of messing with charm store code | 08:47 |
| dimitern | rogpeppe, it's just 5 lines of code anyway | 08:47 |
| rogpeppe | dimitern: you don't need to mess with the charm store code - just the charm client code | 08:47 |
| rogpeppe | dimitern: and it already calculates the hash in exactly the way we need | 08:48 |
| rogpeppe | dimitern: and it's actually a trivial change | 08:48 |
| dimitern | rogpeppe, how about if we support github charms? | 08:48 |
| dimitern | rogpeppe, then the hash and size have to come from the file we download | 08:48 |
| rogpeppe | dimitern: then we can implement GetBundle on the GithubRepository | 08:49 |
| dimitern | rogpeppe, this way it's more future proof, in case we need to support other stores than the charm store | 08:49 |
| rogpeppe | dimitern: i think it's good that the charm package is in charge of calculating the hashes in exactly the right way | 08:49 |
| rogpeppe | dimitern: if we implement github charms, we won't put the code to talk to github inside the api server, will we? | 08:50 |
| dimitern | rogpeppe, well, I talked to william and we decided it's best to do it that way | 08:50 |
| rogpeppe | dimitern: we'd implement it in the charm package | 08:50 |
| dimitern | rogpeppe, I have updated https://codereview.appspot.com/43860043/ | 08:51 |
| dimitern | rogpeppe, we can change it later if needed | 08:51 |
| rogpeppe | dimitern: your code will fail with github charms anyway, as you're type asserting the downloaded charm to *charm.Bundle, and github charms will probably not be in bundled form | 08:52 |
| rogpeppe | dimitern: if you're asserting that the result is a bundle, you may as well leverage the code that knows that (and knows the sha sum) | 08:53 |
| rogpeppe | why do we have to make things more complex than they need to be? | 08:53 |
| dimitern | rogpeppe, please, I want to get on with it and start on ServiceDeploy | 08:54 |
| axw | rogpeppe: I've updated https://codereview.appspot.com/38240043/, but the diff got messed up after I merged in trunk. I might just end up doing a new CL... but the changes are all in there | 09:33 |
| rogpeppe | axw: thanks - currently i need to finish my action item before the meeting, but will take a look afterwards | 09:34 |
| axw | rogpeppe: no problems, thanks | 09:34 |
| axw | jam: FYI, destroy-environment is LGTM'd, just need to do a final test and I'll land it (hopefully this evening) | 09:38 |
| dimitern | rogpeppe, thanks for the review btw | 09:57 |
| rogpeppe | dimitern: np | 09:57 |
| dimitern | rogpeppe, jam, mgz, meeting? | 10:01 |
| thumper | fwereade: you too | 10:02 |
| jam | mgz: if you're around, weekly standup is now | 10:03 |
| axw | jam: not sure if it's related to compatibility, but add-machine seems to be busted on trunk | 10:14 |
| axw | I'm digging into it now | 10:14 |
| jam | axw: I'm just finishing up my patch to do 1.16.3 compat add-machine | 10:15 |
| axw | jam: I mean targeting a 1.17.0 env | 10:15 |
| axw | actually I'm not on trunk, I shouldn't assume it's in the truk code... just pretend I didn't say anything yet | 10:16 |
| axw | wallyworld_: authenticationworker doesn't look happy | 10:17 |
| wallyworld_ | i what way? | 10:18 |
| axw | it's continuously dying, with "generating key fingerprint: exit status 1" | 10:18 |
| wallyworld_ | hmmm. sounds like ssh-keygen is not being run | 10:18 |
| wallyworld_ | that should be installed i would hope | 10:19 |
| axw | wallyworld_: I'll have a look | 10:19 |
| wallyworld_ | it runs ssh-keygen -lf blah from memory | 10:19 |
| wallyworld_ | i ran a system on trunk today and it appeared fine | 10:20 |
| axw | wallyworld_: it's there, and running that directly works fine | 10:22 |
| wallyworld_ | hmmm | 10:22 |
| wallyworld_ | axw: sadly i think our command running infrastructure tends to swallow the real error, so possibly some debug code might be needed | 10:24 |
| wallyworld_ | is this for an env you are running on ec2 or? | 10:25 |
| axw | wallyworld_: azure | 10:26 |
| wallyworld_ | i'm not sure what would be wrong | 10:27 |
| axw | wallyworld_: I can see one of the RPC responses is returning what looks like a list of authorised keys, one of which is "" | 10:27 |
| wallyworld_ | that's interesting. i wonder what the authorised_key file has in it | 10:27 |
| axw | wallyworld_: and authorized-keys in my .jenv has a blank line at the end | 10:27 |
| * axw looks | 10:27 | |
| wallyworld_ | the \n are supposed to be stripped out | 10:27 |
| wallyworld_ | well, they are when reading the .ssh/auth_keys file | 10:28 |
| wallyworld_ | and also the auth_keys env setting from the db | 10:28 |
| wallyworld_ | not sure about the jenv | 10:28 |
| wallyworld_ | but i would hope so | 10:28 |
| axw | wallyworld_: ~ubuntu/.ssh/authorized_keys has a single line, with a key on it | 10:28 |
| wallyworld_ | that sounds correct | 10:28 |
| axw | wallyworld_: looks like that's it | 10:30 |
| axw | wallyworld_: I did juju set-env with what it had minus the blank line, and it's fixed | 10:30 |
| wallyworld_ | so you saying if the auth keys env setting has a blank line it barfs? | 10:30 |
| axw | wallyworld_: yes | 10:31 |
| axw | wallyworld_: well, I'll try add it back in and see what happens | 10:31 |
| wallyworld_ | from memory blnak lines are ignored everywhere else, i think perhaps i though env setting would not have blank lines | 10:31 |
| axw | wallyworld_: although, is it too late after it's started? | 10:31 |
| wallyworld_ | you should be able to use set-env i think | 10:32 |
| wallyworld_ | i wonder how the env setting got an extra \n added | 10:32 |
| wallyworld_ | i will do a patch to fix it, curious how it got there though | 10:32 |
| wallyworld_ | cause as i said, i ran up an ec2 env today and it appeared ok | 10:33 |
| * axw shrugs | 10:34 | |
| axw | I'm not sure why it'd be blank, I'm not familiar with that code | 10:34 |
| axw | oh shit, add-machine has been working, it's just returning an error as well | 10:35 |
| * axw quickly destroys 5 machines | 10:36 | |
| wallyworld_ | the code should be defensive anyway. the \n issue is handled properly for reading .ssh/auth_keys etc | 10:36 |
| dimitern | rogpeppe, natefinch, https://codereview.appspot.com/44240045 deploy using the API | 12:47 |
| rogpeppe | dimitern: looking | 12:48 |
| rogpeppe | dimitern: do you need to worry about compatibility with an API server that has API EnvironmentGet but not AddLocalCharm ? | 13:01 |
| rogpeppe | dimitern: i'm concerned that the code that's in cmd/juju/deploy.go won't actually cope with a legacy environment | 13:02 |
| dimitern | rogpeppe, 1) wasn't sure, because EnvGet was there before and some 1.16 releases have it I think | 13:03 |
| dimitern | rogpeppe, 2) what do you mean? | 13:03 |
| rogpeppe | dimitern: one mo, just checking something | 13:04 |
| rogpeppe | dimitern: have you verified that 1.16 environments return a MethodNotAllowed status when trying to POST? | 13:07 |
| dimitern | rogpeppe, yes | 13:07 |
| rogpeppe | dimitern: ah, that's lucky | 13:07 |
| rogpeppe | dimitern: i guess the websocket handler does the right thing there | 13:08 |
| rogpeppe | dimitern: we'll have to be a bit careful when we do charm GETs though | 13:09 |
| dimitern | rogpeppe, agreed | 13:13 |
| === gary_poster|away is now known as gary_poster | ||
| axw | rogpeppe: I got an LGTM on https://codereview.appspot.com/41280043/, but it occurred to me today as I was testing that we should probably have a --force on destroy-environment now to not call the API | 13:36 |
| axw | rogpeppe: does that sound okay to slip in there? | 13:36 |
| rogpeppe | axw: we definitely need that, yes | 13:37 |
| rogpeppe | axw: how much of a change to that CL do you think it will be? | 13:37 |
| axw | rogpeppe: +8/-4 lines in destroyenvironment.go | 13:38 |
| rogpeppe | axw: well worth it | 13:38 |
| axw | rogpeppe: basically just adding a boolean flag to destroy-environment, and not callig the API if it's enabled | 13:38 |
| axw | does that sound sensible to you? | 13:38 |
| rogpeppe | axw: yeah. | 13:39 |
| axw | rogpeppe: thanks for the review before. I'll unexport the testing.BootstrapContext type as you suggested | 13:40 |
| axw | rogpeppe: it needed to be because the embedded Context is modified in tests | 13:40 |
| axw | rogpeppe: but I'll just have the constructor take a cmd.Context as an arg instead | 13:40 |
| rogpeppe | axw: ok | 13:40 |
| axw | rogpeppe: what makes you say that Bootstrap is no longer viable inside a web service? I don't see how any of the recent changes would prevent that | 13:58 |
| rogpeppe | axw: if you're running it inside a web service, how would you, for instance, allow the user to enter an ssh password inside the web page when requested? | 13:59 |
| axw | rogpeppe: you don't ever need to, unless you're doing manual provisioning | 14:00 |
| rogpeppe | axw: it would be nice to be able to do manual provisioning too, i'd imagine | 14:00 |
| axw | rogpeppe: actually, that's possible too with a pty | 14:00 |
| rogpeppe | axw: and expect(1)-like logic... | 14:01 |
| rogpeppe | axw: yuck :-) | 14:01 |
| axw | rogpeppe: how else would you do it? | 14:01 |
| rogpeppe | axw: i'd make the package API have some kind of a password callback function | 14:02 |
| rogpeppe | axw: and use sshpass to call back into juju | 14:02 |
| rogpeppe | axw: it would definitely be more work though | 14:02 |
| rogpeppe | axw: for not much benefit at this point | 14:03 |
| axw | rogpeppe: sshpass wrapping juju doesn't seem viable, since we shell out multiple times | 14:03 |
| axw | rogpeppe: not sure if you saw the branch, but you can now set $SSHPASS and sshpass will be used if it's available | 14:03 |
| rogpeppe | axw: that's ok, but it's unfortunately global | 14:04 |
| axw | true | 14:04 |
| axw | rogpeppe: alternatively we could just use go.crypto/ssh, which I've started looking into when the system shell isn't available for bootstrapping | 14:05 |
| axw | rogpeppe: I was also thinking that it'd be nice to be able to manually provision from the GUI | 14:05 |
| axw | that could be useful there | 14:05 |
| rogpeppe | axw: i'd be so much happier if we could do that, but i know that the go.crypto/ssh is in a state of flux | 14:05 |
| rogpeppe | axw: it's also important if we want to run under non-unix platforms | 14:06 |
| axw | rogpeppe: yes indeed, that's the prime motivation at the moment - Windows CLI is currently broken on 1.17 | 14:06 |
| rogpeppe | axw: forgive my badly-articulate comments, but i just wanted to indicate some level of discomfort... | 14:06 |
| rogpeppe | s/ate/ated/ | 14:06 |
| axw | rogpeppe: not at all, I'm glad to discuss it. if CLI things are getting too interwoven with the core, then that's not ideal | 14:07 |
| rogpeppe | axw: yeah, it's the kind of thing that feels a bit like breaking of abstraction boundaries | 14:08 |
| rogpeppe | axw: i also feel like that with respect to the Stderr stuff, BTW | 14:09 |
| rogpeppe | axw: i've been wondering whether we could leverage the logging mechanism instead of that | 14:09 |
| rogpeppe | axw: for instance logging to the "progress" module could be a convention for printing progress messages | 14:10 |
| rogpeppe | axw: which would make it easy to run in quiet mode, for example (which is something we don't support now, AFAIK) | 14:10 |
| axw | rogpeppe: I thought thumper was working on something longer-term for that, but I don't know what happened | 14:11 |
| rogpeppe | axw: i don't know anything about that | 14:11 |
| dimitern | rogpeppe, review poke | 14:11 |
| dimitern | :) | 14:12 |
| rogpeppe | dimitern: i'm still on it, sorry | 14:12 |
| rogpeppe | dimitern: it's been a bit involved | 14:12 |
| dimitern | rogpeppe, np, just checking :) | 14:13 |
| rogpeppe | dimitern: reviewed | 14:20 |
| dimitern | rogpeppe, ta! | 14:29 |
| * rogpeppe passes the -e flag to destroy-environment almost every time :-\ | 14:34 | |
| dimitern | rogpeppe, ok, I just checked EnvironmentGet was not available in 1.16, so checking for IsCodeNotImplemented there will allow nice splitting of 2 straight code paths | 14:38 |
| dimitern | rogpeppe, InferURL will return an error when defaultSeries is empty and the URL does not provide one | 14:38 |
| rogpeppe | dimitern: cool | 14:38 |
| rogpeppe | dimitern: yeah, i checked that InferURL error | 14:39 |
| rogpeppe | dimitern: but you might want to make it return a specific error in that case | 14:39 |
| dimitern | rogpeppe, I don't think skipping EnvironmentGet for the sake of 1 less round-trip is worth it, because we need the config later anyway (for local charms), and most importantly will allow me to gate the 1.16 compatibility code nicely | 14:39 |
| rogpeppe | dimitern: sure, that's good enough reason to keep it for the time being | 14:39 |
| dimitern | rogpeppe, that's and entirely different CL | 14:40 |
| rogpeppe | dimitern: BTW why do you need the config for local charms? | 14:41 |
| dimitern | rogpeppe, but I agree that behavior can be better | 14:42 |
| rogpeppe | dimitern: (i can't see that it's used in that case, but i'm probably missing something) | 14:42 |
| axw | dimitern, rogpeppe: do either of you have time for a small review? hazmat found a bug, and is waiting on this: https://codereview.appspot.com/44200043/ | 14:44 |
| rogpeppe | axw: will look | 14:44 |
| axw | thanks | 14:44 |
| dimitern | rogpeppe, we need the config to get the default series | 14:47 |
| rogpeppe | dimitern: so you need that for local or cs charms, right? depending on whether the user specified the series in the charm url. | 14:48 |
| rogpeppe | dimitern: that's just the step i was suggesting that could be skipped. | 14:49 |
| rogpeppe | axw: reviewed | 14:51 |
| axw | rogpeppe: ta | 14:51 |
| dimitern | rogpeppe, both local and cs charms | 14:52 |
| * rogpeppe goes for lunch | 15:12 | |
| mramm | anybody for the cross team meeting? | 15:34 |
| natefinch | mramm: if you need a warm body, I can sit in | 15:36 |
| dimitern | rogpeppe, when you're back, I've updated https://codereview.appspot.com/44240045/ and I think it's ready to land | 15:39 |
| natefinch | man #mongodb is useless. Asked twice in two days for suggestions about this 2.2 vs 2.4 problem I'm having with replicasets, and can't even get anyone to respond | 15:49 |
| natefinch | makes me glad I've at least responded to people asking questions on here | 15:49 |
| mgz | two times is certanly fall back to mailinglist moment | 15:53 |
| sinzui | hazmat, The devs want to release 1.17.0 this week, and then do a 1.17.1 the first week of January. Does that work for you? | 15:55 |
| sinzui | hazmat, I see axw has three things in review. Are these the items you wanted in a release: https://code.launchpad.net/~axwalk | 15:56 |
| natefinch | mgz: I posted to their google group, can't hardly get anyone to even look at my post :/ They don't seem to have a more traditional mailing list | 15:56 |
| natefinch | mgz: granted, it's only been a couple hours | 15:57 |
| hazmat | sinzui, sounds good | 16:13 |
| hazmat | sinzui, just the manual detection stderr, there will be more i suspect though in the new year. | 16:13 |
| hazmat | i've worked around it for now, by shipping binaries built from the branch | 16:13 |
| sinzui | hazmat, fab. I am writing release notes. I expect it to take most of my day. I will release any goodness that arrives in trunk while I write | 16:14 |
| rogpeppe | dimitern: looking | 16:16 |
| dimitern | rogpeppe, thanks | 16:36 |
| dimitern | rogpeppe, and once you're done with it, I have one last one: https://codereview.appspot.com/44230045/ | 16:38 |
| dimitern | :) | 16:38 |
| rogpeppe | dimitern: with regard to this: | 16:39 |
| rogpeppe | Of course we do! The changes actually assume we're using the API properly, | 16:39 |
| rogpeppe | instead of in a compatible mode. | 16:39 |
| rogpeppe | AFAICS the changes don't assume anything of the sort | 16:39 |
| dimitern | rogpeppe, yes? | 16:39 |
| dimitern | they do | 16:39 |
| rogpeppe | the API works equally well if someone isn't using the API properly | 16:40 |
| dimitern | checking the charm exists in state implies this | 16:40 |
| rogpeppe | thus the old code is perfectly sufficient | 16:40 |
| rogpeppe | AFAICS | 16:40 |
| dimitern | the old code will be gone eventually | 16:40 |
| dimitern | so the API shouldn't do more than it should and duplicate features | 16:40 |
| rogpeppe | dimitern: sure - when we want to break compatibility, we can remove the PutCharm piece | 16:40 |
| rogpeppe | dimitern: i don't understand that last remark | 16:41 |
| rogpeppe | dimitern: the API behaviour has not changed at all | 16:41 |
| dimitern | we have Add(Local)Charm and ServiceDeploy - all API calls taking charm urls assume they're already in stte | 16:41 |
| dimitern | state | 16:41 |
| rogpeppe | dimitern: so why change the code? | 16:41 |
| dimitern | rogpeppe, a good API has one call per feature more or less, not some calls that internally do what other calls are doing in a different way | 16:42 |
| rogpeppe | dimitern: i'm not saying that we should not change it in the future | 16:42 |
| rogpeppe | dimitern: that's definitely the plan | 16:42 |
| rogpeppe | dimitern: but i don't see that we need to change it now | 16:43 |
| rogpeppe | dimitern: because we still need all the old (addcharm + putcharm) functionality for backward compatibility | 16:44 |
| rogpeppe | dimitern: can you give me an example of how the new API call differs at all semantically from the old API call? | 16:44 |
| dimitern | rogpeppe, yes | 16:45 |
| dimitern | rogpeppe, when the charm is there, no conn is used at all | 16:45 |
| fwereade | rogpeppe, I think the idea here is to structure the code so as to demonstrate intent, and what's important, and make it easy to extract the simpler version | 16:46 |
| rogpeppe | fwereade: honestly, i think that a simple comment is sufficient there | 16:46 |
| fwereade | rogpeppe, and demanding that add-service reference a charm is no worse than demanding that add-unit reference a service ;p | 16:46 |
| rogpeppe | fwereade: rather than cluttering the logic | 16:46 |
| rogpeppe | fwereade: the new code does not demand that | 16:47 |
| rogpeppe | fwereade: it's exactly the same as the old call | 16:47 |
| rogpeppe | fwereade: except with more logic | 16:47 |
| rogpeppe | fwereade: and maybe a touch more efficient (as dimitern says, it avoids an EnvironConfig when the charm already exists in state) | 16:48 |
| fwereade | rogpeppe, the extra logic looks to me like it's separating the weird and deprecated bits from the intended thrust of the logic | 16:48 |
| rogpeppe | fwereade: (but we could easily avoid that by making conn.PutCharm a function that takes a *state.State as an argument rather than requiring a Conn | 16:48 |
| rogpeppe | fwereade: it looks a lot more complex to me, and it really isn't that complex. | 16:50 |
| fwereade | rogpeppe, it STM to exist for a valid purpose | 16:51 |
| rogpeppe | fwereade: which is? | 16:51 |
| fwereade | rogpeppe, to structure the code so as to demonstrate intent, and what's important, and make it easy to extract the simpler version | 16:52 |
| rogpeppe | fwereade: (i can understand the old logic at a glance; i'm spending a while on the new logic now) | 16:52 |
| fwereade | rogpeppe, the old logic is wrong, though, right? it barfs on local charm urls | 16:52 |
| rogpeppe | fwereade: i don't see how it makes it any easier to extract the simpler version (which will be *much* simpler) | 16:52 |
| fwereade | rogpeppe, there needs to be some sort of change | 16:52 |
| rogpeppe | fwereade: that is a good point about the local charm barfing | 16:53 |
| rogpeppe | [16:45:59] <dimitern> rogpeppe, when the charm is there, no conn is used at all | 16:55 |
| rogpeppe | actually that doesn't appear to be the case | 16:55 |
| rogpeppe | dimitern: i think you can lose the need1dot16Compatibility variable entirely and things become much simpler (and i'll be happier :- | 16:56 |
| rogpeppe | ]) | 16:56 |
| dimitern | rogpeppe, sorry, yes | 16:57 |
| dimitern | rogpeppe, I was thinking of upgrade-charm | 16:57 |
| dimitern | rogpeppe, but it needs conn because of DeployService - we can get rid of this once we drop 1.16 compat + PutCharm and stuff | 16:58 |
| rogpeppe | dimitern: let's just turn DeployService into a function that takes state.State as an argument | 16:59 |
| rogpeppe | dimitern: it has no need to be a method on Conn | 16:59 |
| sinzui | Hi devs. I am pondering why Hp is so prone to interment mysql hook errors. I wonder if the machine is under powered. Do you think 2G for mysql + juju agent is low? | 17:00 |
| dimitern | rogpeppe, and conn.AddUnits as well | 17:00 |
| rogpeppe | dimitern: yeah | 17:01 |
| dimitern | rogpeppe, then we can skip creating a conn entirely for the API I think | 17:01 |
| rogpeppe | dimitern: indeed | 17:01 |
| dimitern | rogpeppe, compat. code will still be using it though | 17:01 |
| rogpeppe | dimitern: it's easy to change conn.DeployService(...) into juju.DeployService(conn.State, ...) | 17:02 |
| dimitern | rogpeppe, yeah, I agree, let's do that | 17:03 |
| dimitern | rogpeppe, and land it :) | 17:03 |
| dimitern | rogpeppe, and this will also fix bug 1216830 | 17:04 |
| _mup_ | Bug #1216830: apiserver should not depend on Conn <tech-debt> <juju-core:Triaged> <https://launchpad.net/bugs/1216830> | 17:04 |
| rogpeppe | dimitern: i don't think you actually need to call Conn.PutCharm at all BTW | 17:04 |
| rogpeppe | dimitern: am just making a small suggestion | 17:04 |
| dimitern | rogpeppe, it's needed, because the GUI doesn't yet use Add(Local)Charm() calls | 17:05 |
| dimitern | rogpeppe, and needs to keep working | 17:05 |
| rogpeppe | dimitern: ha, but you can call Client.AddCharm from Client.ServiceDeploy... | 17:05 |
| dimitern | rogpeppe, so alas, the bug cannot be fixed because of this single PutCharm | 17:05 |
| dimitern | rogpeppe, hmm | 17:05 |
| dimitern | rogpeppe, yes, actually! | 17:06 |
| rogpeppe | dimitern: yeah, i've just published that suggestion | 17:06 |
| rogpeppe | dimitern: it takes the compatibility code down to 4 lines | 17:06 |
| dimitern | rogpeppe, cheers, looking | 17:06 |
| dimitern | rogpeppe, about a cs: charm deploy test - I really tried, in fact I was almost at the point of changing the mock charm store to have all methods of *charm.CharmStore and making the latter an interface, but it's too much work for this CL | 17:10 |
| rogpeppe | dimitern: yeah, i wondered that | 17:10 |
| dimitern | rogpeppe, fortunately I tested charm deployment from the charm store live on ec2 and it seems to work fine | 17:10 |
| rogpeppe | dimitern: that's good | 17:10 |
| rogpeppe | dimitern: serviceSetCharm could call Client.AddCharm too, i think | 17:12 |
| rogpeppe | dimitern: then we really would be no juju.Conn dependencies in apiserver | 17:13 |
| rogpeppe | dimitern: which would be cause for minor celebration :-) | 17:13 |
| dimitern | rogpeppe, yes, indeed | 17:14 |
| hazmat | hmm.. deploy silently ignores invalid service names | 17:24 |
| hazmat | through the api that is | 17:24 |
| dimitern | rogpeppe, did you manage to look at upgrade-charm as well? | 17:39 |
| dimitern | hazmat, file a bug please | 17:39 |
| rogpeppe | dimitern: no, totally distracted by other conversation and development. | 17:39 |
| rogpeppe | dimitern: looking now | 17:39 |
| dimitern | rogpeppe, thanks | 17:39 |
| dimitern | rogpeppe, i'm almost done with the suggestions about deploy - reproposing shortly, + conn removal from apiserver | 17:40 |
| rogpeppe | dimitern: great! thanks. | 17:40 |
| rogpeppe | anyone got an idea why this might die with a "SyntaxError: Unexpected identifier" error? | 18:13 |
| rogpeppe | mongo --ssl -u admin -p mypassword localhost:37017/admin --eval "use juju" | 18:13 |
| hazmat | rogpeppe, use symbol valid for shell not for eval | 18:14 |
| hazmat | i'd guess | 18:14 |
| rogpeppe | hazmat: yeah, i'm thinking that "use juju" isn't valid js | 18:14 |
| rogpeppe | hazmat: i thought the two things were the same | 18:14 |
| rogpeppe | hazmat: i hope there's a js equivalent of "use" | 18:14 |
| hazmat | no.. its a mysqlism propogated | 18:15 |
| hazmat | re db shells | 18:15 |
| rogpeppe | hazmat: hmm, there must be some other way of accessing a different db then | 18:15 |
| hazmat | rogpeppe, see top of mongo -h | 18:16 |
| rogpeppe | hazmat: i can't do that unfortunately | 18:16 |
| rogpeppe | hazmat: i have to log into a different db then switch | 18:16 |
| rogpeppe | hazmat: i guess i can just pipe into mongo | 18:17 |
| hazmat | its trivial in the client drivers, through the shell you point to the one you want.. or use shell syntax ('use') | 18:18 |
| rogpeppe | hazmat: db=db.getSiblingDB("juju") | 18:22 |
| rogpeppe | hazmat: useful to know that db is just a normal variable actually | 18:23 |
| dimitern | rogpeppe, also updated https://codereview.appspot.com/44240045/ - just needs an LGTM :) | 18:25 |
| rogpeppe | dimitern: don't they all? :-) | 18:25 |
| rogpeppe | dimitern: looking | 18:25 |
| hazmat | rogpeppe, is it okay to strip go binaries? | 18:33 |
| rogpeppe | hazmat: no | 18:33 |
| rogpeppe | hazmat: the symbols are used by the runtime | 18:33 |
| rogpeppe | hazmat: you can create executable compressed binaries though | 18:33 |
| rogpeppe | hazmat: though i can't remember the tool that was used | 18:33 |
| hazmat | rogpeppe, oh? do tell.. you just mean gzip? | 18:33 |
| rogpeppe | hazmat: no | 18:34 |
| hazmat | i'll dig through our tools code | 18:34 |
| rogpeppe | hazmat: i mean you can get a much smaller binary that uncompresses itself when run | 18:34 |
| rogpeppe | hazmat: i'll have a quick search, one mo | 18:34 |
| rogpeppe | hazmat: https://github.com/pwaller/goupx | 18:35 |
| rogpeppe | hazmat: i can't verify that it still works though | 18:35 |
| rogpeppe | hazmat: it seemed to work when i last played with it | 18:35 |
| rogpeppe | dimitern: reviewed | 18:41 |
| dimitern | rogpeppe, cheers | 18:44 |
| * rogpeppe just got a working status from a restored environment, woo | 18:51 | |
| rogpeppe | if anyone cares to take a look, juju-restore now seems to work: https://codereview.appspot.com/44350043/ | 20:06 |
| rogpeppe | natefinch: ^ | 20:07 |
| natefinch | rogpeppe, cool | 20:10 |
| natefinch | rogpeppe, I just got confirmation from a mongo engineer that the problem I was having with replica sets in mongo 2.2.0 is likely just a bug in 2.2.0. I think we may have to just tell people they need to upgrade to get HA | 20:11 |
| rogpeppe | natefinch: ok, that's good to know | 20:12 |
| thumper | o/ | 20:19 |
| thumper | as hazmat mentioned on the mailing list, I thought we already did use a later version | 20:19 |
| natefinch | thumper, I thought older environments had 2.2.0 that didn't get upgraded when we upgraded juju... but I might be wrong about that. | 20:19 |
| thumper | natefinch: hmm.. not sure about that | 20:20 |
| natefinch | thumper, it may be my misunderstanding | 20:21 |
| thumper | I just don't know | 20:21 |
| thumper | dimitern: well done on getting deploy done \o/ | 20:30 |
| dimitern | thumper, and upgrade-charm | 20:31 |
| thumper | dimitern: that's great. what's left? | 20:31 |
| dimitern | thumper, both are about to land as soon as the bot finishes with them | 20:31 |
| dimitern | thumper, let me check | 20:31 |
| dimitern | thumper, only one - apiendpoints | 20:33 |
| thumper | dimitern: is status done? | 20:33 |
| dimitern | thumper, but it's trivial and might benefit from some caching | 20:33 |
| dimitern | thumper, yes, i think it got landed | 20:33 |
| thumper | oh yay | 20:33 |
| dimitern | thumper, i'm updating the blueprint now | 20:33 |
| dimitern | thumper, actually, looking at status it seems it still uses state | 20:35 |
| dimitern | thumper, https://code.launchpad.net/~gz/juju-core/status_api/+merge/198444 this is the branch and it haven't landed yet, but seems done | 20:36 |
| thumper | I think it will be great to get this all landed for 1.18 | 20:37 |
| dimitern | indubitably | 20:38 |
| dimitern | seems mgz have changed something recently (2h ago), so perhaps he's looking into landing it | 20:38 |
| rogpeppe | thumper: hiya | 20:56 |
| thumper | hi rogpeppe | 20:56 |
| rogpeppe | thumper: looking for a review of https://codereview.appspot.com/44350043/ if you have a moment or two | 20:56 |
| thumper | sure | 20:57 |
| * thumper has a visitor | 21:01 | |
| * rogpeppe has a beer | 21:08 | |
| hatch | it's Chrismas time....that means rum and eggnog! | 21:08 |
| dimitern | rogpeppe, you've got LGTM on https://codereview.appspot.com/37850043/ | 21:09 |
| rogpeppe | dimitern: tyvm | 21:10 |
| dimitern | ok, time to stop | 21:10 |
| dimitern | g'night all | 21:10 |
| rogpeppe | dimitern: night night | 21:10 |
| * rogpeppe has also reached eod | 21:18 | |
| rogpeppe | g'night all | 21:18 |
| natefinch | rogpeppe, good night | 21:19 |
| natefinch | thumper: who do I talk to about upgrading mongo on the bot? I can't commit my HA stuff until it's upgraded | 21:54 |
| thumper | natefinch: sinzui | 21:54 |
| sinzui | yes? | 21:54 |
| thumper | sinzui: natefinch wants to upgrade mongo on the bot | 21:55 |
| thumper | or do you just do CI and not landing? | 21:55 |
| * thumper frowns | 21:55 | |
| sinzui | I don't land, sorry. | 21:55 |
| sinzui | thumper, natefinch. I wonder if I can ssh to the machine if I know the IP address. | 21:57 |
| thumper | natefinch: perhaps wallyworld_ can help, I've not logged into the bot | 21:57 |
| natefinch | thumper, sinzui: jam told me the IP in a hangout like yesterday... but I forgot to write it down ,and now it has flittered into the ether | 21:58 |
| sinzui | I can push/tag gobot branches | 21:58 |
| natefinch | thumper, well, it's EOD for me anyway. I'll email jam about it and he'll fix me up. | 22:03 |
| thumper | kk | 22:03 |
| thumper | natefinch: see you around | 22:03 |
| natefinch | thumper, see you | 22:04 |
| sinzui | wallyworld_, thumper. I don't understand how to use/document to juju backup plugin. | 22:40 |
| thumper | sinzui: neither do I | 22:41 |
| wallyworld_ | sinzui: i can do that. it was more or less a prototype but can be documented | 22:41 |
| wallyworld_ | there's also the restore utility which i know little about | 22:41 |
| wallyworld_ | it may still be wip, not sure | 22:42 |
| sinzui | wallyworld_, we can not document it in the 1.17.0 release if you think a 1.17.1 or 1.18.0 is a better time | 22:43 |
| wallyworld_ | i think that would be better given i suspect the restore utility may not be done fully (but am not sure, i could be wrong) | 22:43 |
| sinzui | fab. I will just remove it from the notable section. thank you wallyworld_ | 22:44 |
| wallyworld_ | no-one would care too much i suspect | 22:44 |
| bradm | anyone know whats going on with LP#1241674? we're upgrading to havana with multiple neutron networks, and are pretty interested in the bug | 23:10 |
| _mup_ | Bug #1241674: juju-core broken with OpenStack Havana for tenants with multiple networks <cts-cloud-review> <openstack-provider> <juju-core:Triaged> <https://launchpad.net/bugs/1241674> | 23:10 |
| wallyworld_ | bradm: the best person to fix this quickly on the core team is martin. i'm not sure if he has been looking at it, but can catch up with him when he comes online for his SOD | 23:16 |
| bradm | wallyworld_: its going to become pretty critical for us next year | 23:17 |
| wallyworld_ | bradm: how would someone determine which network to use? via an environ config? | 23:17 |
| wallyworld_ | juju environ that is | 23:17 |
| bradm | wallyworld_: aiui each environment has its own network | 23:17 |
| wallyworld_ | so if we introduced a new config attribute called "network-name" or something? | 23:18 |
| bradm | maybe, I'd want to look into it a bit more | 23:18 |
| wallyworld_ | i can start work on it | 23:18 |
| wallyworld_ | i'd just need a little more guidance on what we want to do | 23:19 |
| bradm | I'm just trying to get my head around what would be required here, the neutron network stuff is new to me | 23:19 |
| wallyworld_ | me too | 23:19 |
| wallyworld_ | martin knows about it though :-) | 23:19 |
| bradm | I'm fairly sure its deterministic per tenant what network they have | 23:19 |
| wallyworld_ | i'll see if i can catch up with him | 23:19 |
| wallyworld_ | so if it's deterministic, we can either specify one, or maybe just choose the first one or something if none is specified? | 23:20 |
| bradm | aiui there's a mapping from tenants to networks | 23:21 |
| bradm | oh, you can tell nova what net-id to use when you boot | 23:22 |
| wallyworld_ | so maybe a net-id juju config attribute | 23:22 |
| bradm | yeah, if you can't get it progmatically | 23:23 |
| wallyworld_ | well, even if you could, i think maybe it would be needed to allow the user to specify | 23:24 |
| wallyworld_ | if there's more than one | 23:24 |
| bradm | yeah, since you can have different nics on different networks | 23:24 |
| wallyworld_ | ok. so we will have this fixed definitely by next year if not sooner. but most people are away next week so getting any changes reviewed and committed may be difficult | 23:25 |
| wallyworld_ | i'll talk to martin and we'll work something out | 23:25 |
| bradm | that's fine, I'm nearly on holidays anyway | 23:26 |
| wallyworld_ | me too :-D | 23:26 |
| bradm | we're just building the next version of prodstack, it'd be nice to know there's a plan for the bug | 23:26 |
| wallyworld_ | definitely a plan | 23:26 |
| wallyworld_ | the bug is down for the 1.17 milestone | 23:26 |
| wallyworld_ | which sorta means we can't do the next release until fixed | 23:27 |
| bradm | we kind of need to do multiple networks so we can segregate off things into seperate pools, so we have some control over badwidth | 23:27 |
| bradm | bandwidth, even. | 23:27 |
| wallyworld_ | yep. there's a whole unit of work planned for that sort of stuff | 23:28 |
| wallyworld_ | will be started in january | 23:28 |
| bradm | we're going to end up with 2 different physical router clusters, doing active/passive failover for neutron and firewalls | 23:28 |
| bradm | with channel bonding on each to allow the different sections to have the required bandwdith they need | 23:28 |
| wallyworld_ | sounds good | 23:28 |
| bradm | it should be, it'll let us bring more into juju / openstack, since some of our apps use a lot more bandwidth than others | 23:29 |
| wallyworld_ | and is what customers would be doing | 23:30 |
| wallyworld_ | so good to get it all dog fooded | 23:30 |
| bradm | yup | 23:30 |
| bradm | its good to see more redundancy happening in the stack, we'll have more control over hardware etc if we can fail things over | 23:32 |
| wallyworld_ | yeah | 23:32 |
| bradm | wallyworld_: let us know if we can help, we should have a full havana stack with multiple networks early next year, mostly waiting on hardware atm | 23:34 |
| wallyworld_ | bradm: is there something there now? or only next year? | 23:34 |
| bradm | wallyworld_: we have most of the stack now, we're missing ceph, and decent amount of swift storage | 23:36 |
| bradm | wallyworld_: and we don't have the 2nd physical router & neutron setup either | 23:36 |
| wallyworld_ | ok. i'mjust thinking we need something with multiple networks just to test with while we develop the solution for the bug | 23:36 |
| wallyworld_ | so we don't need a full setup with all the bell and whistles, just something that will fail without the new code and work once we add the necessary fixes | 23:38 |
| bradm | didn't james page say there was a cloud like that already? | 23:38 |
| bradm | https://bugs.launchpad.net/juju-core/+bug/1241674/comments/5 | 23:38 |
| _mup_ | Bug #1241674: juju-core broken with OpenStack Havana for tenants with multiple networks <cts-cloud-review> <openstack-provider> <juju-core:Triaged> <https://launchpad.net/bugs/1241674> | 23:38 |
| wallyworld_ | ah yes he did | 23:39 |
| wallyworld_ | i wasn't really familiar with the bug | 23:39 |
| wallyworld_ | jamespage: is the havana based cloud referenced in the above bug just lyc02 on canonistack? | 23:41 |
| bradm | I don't think canonistack has multiple networks | 23:43 |
| bradm | or is even using neutron | 23:43 |
| wallyworld_ | ah ok. i seemed to recall lyc02 was havana but didn't know to what extent it also used neutron etc | 23:44 |
| bradm | yeah, its havana, but I don't think its using neutron with openswitch, I'd say that'll be the next upgrade for canonistack | 23:45 |
| wallyworld_ | ok. i'll get the details mentioned in the bug so us core guys can work on the bug | 23:47 |
| bradm | awesome | 23:47 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!