| === Spads_ is now known as Spads | ||
| === bodie__ is now known as bodie_ | ||
| === mup_ is now known as mup | ||
| === anthonyf is now known as Guest90478 | ||
| === meetingology` is now known as meetingology | ||
| === Tribaal_ is now known as Tribaal | ||
| wallyworld_ | axw: hey, you seen this issue before? I'm trying to land dimiter's fix to unblock trunk | 10:56 |
|---|---|---|
| wallyworld_ | Extant directories unknown: | 10:56 |
| wallyworld_ | labix.org/v2/mgo | 10:56 |
| axw | errm | 10:56 |
| axw | nope | 10:56 |
| wallyworld_ | seems a bot scripting issue | 10:56 |
| axw | we shouldn't be using labix.org/v2/mgo anymore | 10:56 |
| wallyworld_ | yup | 10:56 |
| axw | it's not snuck into dependencies.tsv is it? | 10:56 |
| wallyworld_ | hmm, don't think so, i'll check | 10:57 |
| axw | nope | 10:57 |
| wallyworld_ | i'll have to grep the release tools scripts, i think they print that message | 10:57 |
| wallyworld_ | i really want to get our stuff landed, otherwise will need to make a feature branch, but if i do it off trunk now, local lxc will be broken until the fix lands | 10:58 |
| === kadams54 is now known as kadams54-away | ||
| anastasiamac | menn0: waigani:ping | 21:14 |
| menn0 | anastasiamac: pong | 21:32 |
| menn0 | anastasiamac: pong (again) | 21:57 |
| menn0 | waigani: just reviewed the FindId/RemoveId change. | 22:09 |
| waigani | menn0: thanks | 22:09 |
| anastasiamac | menn0: sorry - day off... kids running around... m missing ur answers :D | 22:17 |
| anastasiamac | menn0: do u know what tim changed in facade creation/calling? | 22:17 |
| anastasiamac | menn0: related bug 1414027 | 22:18 |
| mup | Bug #1414027: Increment client facade or return agent version in login <juju-core:Triaged> <https://launchpad.net/bugs/1414027> | 22:18 |
| menn0 | anastasiamac: not off the top of my head | 22:18 |
| anastasiamac | menn0: i think its smth in dependencies... | 22:18 |
| menn0 | anastasiamac: but I can try and figure it out if it's urgent | 22:18 |
| anastasiamac | menn0: is tim not around today? | 22:18 |
| menn0 | anastasiamac: he's back tomorrow | 22:18 |
| menn0 | anastasiamac: has the day off today | 22:19 |
| anastasiamac | menn0: k. i'll ask tomorrow | 22:19 |
| anastasiamac | menn0: it's not urgent 4 me :D | 22:19 |
| menn0 | anastasiamac: ok | 22:19 |
| anastasiamac | menn0: but hazmat has troubles calling all new clients | 22:19 |
| anastasiamac | menn0: he can see them but when he calls them he get errors | 22:20 |
| menn0 | anastasiamac: ok. i'll try and have a look and see if this is related to Tim's changes | 22:20 |
| menn0 | anastasiamac: stop working on your day off! | 22:20 |
| anastasiamac | menn0: m nt working :P m talking to u :D | 22:20 |
| menn0 | anastasiamac: that's work :) | 22:20 |
| anastasiamac | menn0: just an fyi, all feature tests run fine | 22:20 |
| anastasiamac | menn0: they all work when u do a full go install ../... from juju root... | 22:21 |
| anastasiamac | menn0: only new facades are affected | 22:21 |
| anastasiamac | menn0: axw saw the same behaviour on his environment (i did too) | 22:21 |
| anastasiamac | menn0: and had to re-build from scratch... | 22:21 |
| anastasiamac | menn0: as per above :D | 22:22 |
| menn0 | anastasiamac: ok. good to know. | 22:23 |
| anastasiamac | menn0: thnx! that's what at least 2 cases of scotch now?.. :D | 22:26 |
| menn0 | anastasiamac: umm... I haven't done anything yet :) | 22:26 |
| menn0 | anastasiamac: but yes please :-p | 22:26 |
| anastasiamac | menn0: 1 for CI blockers (well for unblocking them) and 2nd in anticipation :D | 22:28 |
| menn0 | anastasiamac: i'll see what I can do. onyx is in crunch mode at the moment, trying to get MESS working before the mid-cycle sprint. | 22:29 |
| anastasiamac | menn0: understood... tanzanite's storage has a new client for sprint demo too... | 22:30 |
| anastasiamac | menn0: just making sure that there will b no hiccups for us either :D | 22:30 |
| menn0 | anastasiamac: I will look at that bug later today | 22:31 |
| menn0 | anastasiamac: I even just assigned to me and everythign | 22:31 |
| anastasiamac | menn0: thnx :D but really m happy to wait til tim and tomorrow | 22:33 |
| menn0 | anastasiamac: well I'll see if I can figure it out but if it turns into an epic then Tim can look tomorrow. | 22:34 |
| anastasiamac | menn0: thnx :D | 22:37 |
| hazmat | menn0, dropped a note on 1414027 | 22:57 |
| menn0 | hazmat: just read it. I'm pretty sure that the idea is if the client knows about /environment/:uuid/api it should use that. | 22:59 |
| menn0 | hazmat: I believe that much of the API available at the root is going to go away at some point | 22:59 |
| hazmat | menn0, you mean it should keep trying different endpoints till one works? | 22:59 |
| hazmat | ie. does a 1.20.x env respond to that? | 23:00 |
| menn0 | hazmat: not sure. thumper has a clearer picture of how this is supposed to work. | 23:00 |
| * menn0 checks the code | 23:01 | |
| hazmat | menn0, i'm writing an app/client that's autonegotiating from 1.18 to 1.23.. on facades that esasy | 23:01 |
| hazmat | changing the endpoint is something else | 23:01 |
| * hazmat waits up for the australian open to start | 23:04 | |
| menn0 | hazmat: ok, I'm not exactly sure what the plan is. thumper will know more and he's back tomorrow. | 23:11 |
| menn0 | hazmat: AFAIK the existing env-specific functionality will continue to work from the root for some time (but probably only for the initial environment I guess) | 23:12 |
| menn0 | hazmat: actually, thinking some more, the env functionality at root should work for any env, as long as you log in to that env. | 23:15 |
| hazmat | menn0, sure but without telling clients that they may talking to a multi-state server env, they don't know till they Info() on the env to get version.. it should go to the jenv so they know where to connect, connecting to root only works for legacy envs (env 0) in multi-tenant state servers, and connecting to multiple state servers. juju should add some info to disambiguate that in the client side info it stores, and avoid apps having to hit multiple endp | 23:16 |
| hazmat | oints (legacy, multi-style) to discover the correct one. | 23:16 |
| hazmat | menn0, you login by username, password, not by env uuid | 23:16 |
| hazmat | on the root | 23:16 |
| menn0 | hazmat: i'm also pretty sure you can specific the environment tag at login time | 23:17 |
| * menn0 checks | 23:17 | |
| menn0 | hazmat: actually, it's before login | 23:18 |
| menn0 | hazmat: api.Info has a EnvironTag field. if you set that you get a connection for that envrionment | 23:19 |
| menn0 | hazmat: if it's blank you get the initial / state server env | 23:19 |
| hazmat | re before login, was there it weaved together prior to login in the src? | 23:21 |
| menn0 | never mind | 23:21 |
| menn0 | i've just looked further | 23:21 |
| menn0 | setting that field changed the endpoint URL used by the juju API client | 23:22 |
| menn0 | it's not passed through | 23:22 |
| * menn0 goes to check what 1.20 does with that... | 23:22 | |
| menn0 | and 1.18 even | 23:23 |
| hazmat | s/was/where | 23:23 |
| hazmat | k | 23:23 |
| hazmat | menn0, so yeah.. client api compatibility across multiple versions is the question.. i think dropping it in the jenv is appropriate. a multi-tenant root would be useful, but there's no initial request outside of login which would be a fine place to pass as older clients would ignore, but its also keeping compatibility with the older endpoints | 23:25 |
| hazmat | which is nice, but given apps want to be compatible with both, also enshrines it as endpoint for a little while... and of course assuming it does take env-uuid as a param on login | 23:26 |
| hazmat | environ tag is already in the jenv | 23:27 |
| hazmat | at least for 1.23.. dunno how far back that goes. | 23:27 |
| menn0 | still digging... code for 1.18 was in LP so it's a little harder to check | 23:28 |
| hazmat | i'm currently doing conditional on that.. but that's a rather subtle distinction which would be better explicit, given the variety of tooling around the api. | 23:28 |
| hazmat | ie. juju client compatibility is great but there are other api clients that need to do the same dance.. at least js and multiple py clients wrt to common usage... so some explicit delineation and email/doc would be useful.. | 23:31 |
| menn0 | hazmat: i've almost got this figured out. bear with me. | 23:34 |
| menn0 | hazmat: so environ-uuid has been in the .jenv since 1.20.0. 1.18 didn't have it. | 23:35 |
| menn0 | hazmat: and if you have environ-uuid in the .jenv then you should be using a endpoint of /environment/:uuid/api | 23:36 |
| menn0 | hazmat: otherwise you use the root | 23:36 |
| menn0 | hazmat: basically, if the jenv includes environ-uuid then the server supports it | 23:37 |
| menn0 | hazmat: thumper will probably have some more detail but the above is what I'm seeing from the code at various points in time | 23:38 |
| menn0 | hazmat: agreed that this needs to be documented better | 23:38 |
| hazmat | menn0, cool, thanks.. although i'll note.. not all clients use jenv (landscape and gui both collect info via forms) | 23:38 |
| menn0 | hazmat: ok. and that's been fine up until now because there's only been one env and if you connect at root you just get the initial env. | 23:40 |
| hazmat | for client-side py tools that should handle things, thanks again | 23:40 |
| menn0 | hazmat: those forms are going to need to take the env uuid as well i guess | 23:40 |
| menn0 | hazmat: i'll follow up with thumper tomorrow and confirm all this and get the docs updated | 23:41 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!