| rogpeppe | fwereade: i think it's quite straightforward actually | 09:39 |
|---|---|---|
| rogpeppe | fwereade: none of the tools-choosing logic is in the provider currently | 09:39 |
| fwereade | rogpeppe, the tools change? it's probably not *that* big I agree | 09:40 |
| fwereade | rogpeppe, but it's another environ thing the api needs to know/care about and I'm not currently sure I know how that stuff works | 09:40 |
| rogpeppe | fwereade: i think it's just a matter of adding some kind of canary tag to an agent's info in the state. | 09:40 |
| rogpeppe | fwereade: if the api just provided a way to list the available tools, that would be sufficient, i think | 09:41 |
| fwereade | rogpeppe, I'd rather be able to ask a machine directly what it should be running really | 09:42 |
| rogpeppe | fwereade: essentially we'd be making environs.FindAvailableTools call a method on state rather than on the provider (it might even take an interface so it could work on both) | 09:42 |
| rogpeppe | fwereade: i dunno, i don't mind much | 09:43 |
| fwereade | rogpeppe, we could indeed do it that way too, I think I'd generally prefer to keep as much of that sort of work behind the API as possible | 09:43 |
| rogpeppe | fwereade: i quite like the idea that an agent can choose how to upgrade itself. | 09:43 |
| fwereade | rogpeppe, maybe it has advantages I'm not seeing | 09:44 |
| rogpeppe | fwereade: it's more flexible and it's very similar to the current system, so less churn. it may be more flexible than we need, i dunno. | 09:45 |
| rogpeppe | fwereade: i can see the upgrade path more clearly in my head this way | 09:46 |
| rogpeppe | fwereade: but that's probably just me being fuzzy headed :-) | 09:46 |
| fwereade | rogpeppe, we'll see how it looks when we actually implement it, that usually forces an extra dose of perspective | 09:47 |
| rogpeppe | fwereade: indeed | 09:47 |
| rogpeppe | fwereade: i'm hoping we can avoid too many semantic changes as we move towards using the API - they can happen later, i think. | 09:48 |
| fwereade | rogpeppe, agreed in principle at least, I just don't think we can get away with *none* | 09:49 |
| rogpeppe | fwereade: we'll see, i guess. | 09:49 |
| rogpeppe | fwereade: i'm hoping for none, but there will probably be some necessary. | 09:49 |
| ahasenack | hi guys, how do you update all the branches that go get fetched and placed in $GOPATH/src/*? go get doesn't seem to update | 12:01 |
| ahasenack | you just go into each one and bzr pull / git pull / hg whatever? | 12:02 |
| dimitern | ahasenack: either that, or use go get -u project-import-path/... - will fetch and update the project and all dependencies | 12:03 |
| ahasenack | dimitern: ah, cool, -u is what I was looking for, thanks | 12:03 |
| rogpeppe | "The engineers onside have advised that due to the severity of the damage they have to supply a revised fix date. They have confirmed that it is now 03/05/2013." | 13:16 |
| rogpeppe | looks like my internet is going to continue to be knackered for a while yet then | 13:16 |
| rogpeppe | it will have been dead for two weeks tomorrow :-( | 13:18 |
| TheMue | rogpeppe: at least you'll have hope that it is fixed when we're returning from oakland | 13:24 |
| mgz | good thing you won't be there next week rogpeppe | 13:24 |
| rogpeppe | that is true | 13:25 |
| rogpeppe | not sure carmen will be very happy with no skype calls tho' | 13:25 |
| rogpeppe | not to mention no bbc iplayer :-) | 13:25 |
| mgz | :) | 13:26 |
| TheMue | :) | 13:26 |
| rogpeppe | my phone has been a very busy gateway these last weeks | 13:27 |
| rogpeppe | mobile hotspot ftw | 13:27 |
| === wedgwood_away is now known as wedgwood | ||
| rogpeppe | if anyone fancies a non-juju review, here are the first two branches of the new godeps tool: https://codereview.appspot.com/9016043/ https://codereview.appspot.com/9047043/ | 13:54 |
| hazmat | rogpeppe, to avoid the working copy not pointed to master.. ideally you could detect origin/remote to see if its a non default checkout/branch, also a IsModified to check working copy for changes, abort in both cases | 14:14 |
| mgz | hazmat: right. | 14:15 |
| hazmat | fwiw, here's my take atm on a similiar problem, i don't have the branch/origin detection yet though. IsModified was little tricky with bzr non current revs via the cli, i ended up using it as a lib.. http://bazaar.launchpad.net/~hazmat/juju-deployer/refactor/view/head:/deployer.py#L392 | 14:17 |
| rogpeppe | hazmat: in a call | 14:19 |
| rogpeppe | hazmat: does it really matter if the working copy isn't pointed to master? | 14:32 |
| mgz | rogpeppe: yes, as we were talking about yesterday | 14:33 |
| mgz | you can make work-in-progress hard to recover (and probably without much sign it's been unlinked) | 14:34 |
| rogpeppe | fwereade: is the relation-list CL fixing a bug? it seems to me the change just removes an optional argument. is that right? | 14:34 |
| fwereade | rogpeppe, it drops the arg and uses a flag insteam | 14:34 |
| fwereade | er instead | 14:34 |
| rogpeppe | fwereade: oh yes, i'd missed the fact it wasn't using Var before | 14:35 |
| rogpeppe | mgz, hazmat: istm that if we make it easy for the user to restore things as they were (for instance by printing the godeps before the modification) then it's not too bad a problem | 14:38 |
| mgz | that doesn't help overwriting the head of someone's in-progress feature branch | 14:38 |
| rogpeppe | mgz: we wouldn't overwrite any work that couldn't be restored easily | 14:39 |
| mgz | rogpeppe: try it. | 14:40 |
| rogpeppe | mgz: ok, i will. what's the exact scenario you have in mind, so i can try it? | 14:40 |
| mgz | `bzr switch -b feature && bzr commit --unchanged -m "Important work, really" && ???` | 14:43 |
| mgz | we're pretty careful about not chucking stuff away, but you can easily confuse people | 14:43 |
| rogpeppe | mgz: what work will be lost there if we do "bzr update -r revid:something" ? | 14:45 |
| mgz | the question is, what steps do you do to restore your feature branch? | 14:45 |
| hazmat | rogpeppe, in the absence of certainity refuse the temptation to guess, if its modified or non pointing to the origin, bailing is the simplest correct thing to do | 14:46 |
| rogpeppe | hazmat: i'm just wondering about the "non pointing to the origin" thing here. what's the "origin" when you're using git for example? | 14:46 |
| mgz | (answer: `bzr update` and perhaps `bzr revert` if there were conflicts, but you need to notice and do those steps to recover, | 14:47 |
| mgz | and, it's different for each vcs) | 14:47 |
| hazmat | rogpeppe, default remote master | 14:47 |
| rogpeppe | mgz: will "bzr update revid:foo; bzr update revid:bar" not always end up with revid:bar ? | 14:48 |
| mgz | yes, but you don't know the state of the tree after doing those two commands | 14:48 |
| rogpeppe | mgz: insert -r's as appropriate | 14:48 |
| mgz | (the first will helpfully fail if the branch doesn't actualyl contain the revision at least) | 14:48 |
| rogpeppe | mgz: oh. i thought the point of "bzr update -r revid:x" was to change the tree to update to revid:x. | 14:49 |
| mgz | also, git does GC and things, so I don't think you can trust a dangling head will persist for ever | 14:49 |
| rogpeppe | mgz: what other state might the tree end up in? | 14:49 |
| rogpeppe | mgz: that's an interesting point. | 14:50 |
| rogpeppe | mgz: although hopefully it won't be a dangling head, right? | 14:50 |
| rogpeppe | mgz: it should be part of the history, and if it's not you should be able to fetch it with go get -u. | 14:50 |
| rogpeppe | mgz: oh, i see | 14:51 |
| rogpeppe | mgz: you mean the user's dangling head | 14:51 |
| rogpeppe | mgz: hmm | 14:51 |
| mgz | rogpeppe: my feature branch removes file X. trunk changes file X. you update my feature branch to trunk... what is X? you update again back to the head rev from the feature branch... what is X? | 14:51 |
| rogpeppe | mgz: doesn't a given revid specify file X absolutely? | 14:52 |
| mgz | bzr answer: conflict, you have both varients present in the tree and need ot resolve (or use `bzr revert` to just wipe state back to the current selected rev) | 14:52 |
| mgz | sure, but update is really a three way merge when history has diverged | 14:53 |
| mgz | it's not a "wipe everything and switch to this"... because that's less safe (and has a different spelling) | 14:54 |
| rogpeppe | mgz: naively, i'd have thought that X after updating to trunk would be X as changed in trunk (newly created); updating back to the head rev would remove it again. | 14:54 |
| rogpeppe | mgz: but you're saying that's not the case? | 14:54 |
| mgz | nope. | 14:54 |
| rogpeppe | mgz: this destroys my faith in vcs's :-) | 14:55 |
| mgz | it should help encourage you, otherwise your un-landed changes would be much easier to accidentally lose | 14:55 |
| mgz | (and are I think, in one spelling of this people use with git) | 14:56 |
| rogpeppe | mgz: i always thought that, given a clean tree, rm -r *; bzr update revid:x; would be semantically the same as bzr update revid:x (but faster) | 14:57 |
| rogpeppe | mgz: i still don't quite see where the conflicts come in | 14:57 |
| mgz | it is not. | 14:57 |
| rogpeppe | mgz: pardon my lack of vcs-fu | 14:58 |
| mgz | hg handles the same situation by refusing to update to a non-descendant | 14:58 |
| rogpeppe | mgz: or ancestor? | 14:58 |
| fwereade | rogpeppe, dimitern: a thought about charm config changes on upgrade-charm | 14:59 |
| dimitern | fwereade: yeah?\ | 15:00 |
| fwereade | rogpeppe, dimitern: when a setting type changes, is it *really* any better for us to barf than to just ignore it? | 15:00 |
| fwereade | rogpeppe, dimitern: if we ignore it we just get the default | 15:00 |
| rogpeppe | fwereade: i think so | 15:00 |
| dimitern | fwereade: sgtm | 15:00 |
| rogpeppe | fwereade: it's an incentive for charm authors to keep things compatible by only adding compatible settings | 15:01 |
| fwereade | rogpeppe, but *actual* compatibility is more than just the type | 15:01 |
| rogpeppe | fwereade: sure. the new charm must declare all the old settings, right? | 15:02 |
| fwereade | rogpeppe, nope, we just discard ones that are now irrelevant | 15:02 |
| fwereade | rogpeppe, maybe *that* is crazy | 15:02 |
| rogpeppe | fwereade: so you're proposing that there are no charm settings compatibility rules at all? | 15:02 |
| fwereade | rogpeppe, but I don;t *think* so | 15:02 |
| rogpeppe | s/there are/there should be/ | 15:02 |
| fwereade | rogpeppe, the only one that was ever mooted was the type one, and I'm struggling to see what value it delivers | 15:03 |
| fwereade | rogpeppe, delete is fine and add-new is fine | 15:03 |
| rogpeppe | fwereade: i thought it was stronger than that. i think that the new charm should declare all the old settings and they should be of the same type. | 15:03 |
| fwereade | rogpeppe, so if a newer version of a charm adds some smarts that render some option irrelevant, it has to carry them forever? | 15:04 |
| rogpeppe | fwereade: yeah. that's compatibility for you. | 15:04 |
| fwereade | rogpeppe, I don;t think that's helpful | 15:04 |
| rogpeppe | fwereade: i think that settings are a good indicator of compatibility. relations not nearly so much. | 15:05 |
| fwereade | rogpeppe, this means that there's never any incentive to make a charm smarter -- once there's a config setting, the charm author either has to support it forever and allow it to override (complex) or just ignore a published config setting (evil) | 15:05 |
| fwereade | rogpeppe, the relations *are* a hard constraint | 15:05 |
| rogpeppe | fwereade: yes, but loads of very different charms declare the same relations, right? | 15:06 |
| fwereade | rogpeppe, allowing a charm upgrade to break an existing relation is I think clearly not ok | 15:06 |
| rogpeppe | fwereade: agreed. but my point is that's not a very strong constraint | 15:06 |
| fwereade | rogpeppe, yeah, that's inevitable | 15:06 |
| fwereade | rogpeppe, --switch has valid use cases, but they are tiny islands of sanity in a great ocean of borken | 15:07 |
| rogpeppe | fwereade: i think that specifying settings compatibility makes the islands substantially larger | 15:07 |
| fwereade | rogpeppe, it just feels like walling off one tiny area of the borkenness and saying "this is really really bad" should probably be justified a bit more strongly | 15:07 |
| fwereade | rogpeppe, what is the benefit of not allowing config settings to be deleted? | 15:08 |
| rogpeppe | fwereade: how about an explicit "deprecated" type? | 15:08 |
| rogpeppe | fwereade: so you can upgrade to deprecated and deprecated settings can be deleted. | 15:09 |
| fwereade | rogpeppe, but we still have to carry "deprecated" forever, and I don't see who's helped by this | 15:09 |
| rogpeppe | fwereade: that gives charm authors a path to deleting settings. | 15:10 |
| fwereade | rogpeppe, I don't see how it improves on just deleting the settings straight off | 15:10 |
| rogpeppe | fwereade: it means we have much greater confidence that we're not upgrading to a totally unrelated charm | 15:11 |
| fwereade | rogpeppe, ah, sorry, you're proposing that we validate the two charms' schemas against one another | 15:11 |
| rogpeppe | fwereade: isn't that essentially what we're currently doing? | 15:12 |
| rogpeppe | fwereade: except we only validate some relations | 15:12 |
| fwereade | rogpeppe, no, we just validate the old settings against the new schema as forgivingly as possible, *apart* from the types | 15:12 |
| fwereade | rogpeppe, for config | 15:12 |
| fwereade | rogpeppe, and for relations, we validate only that the relations the charm is currently in can continue to exist | 15:13 |
| fwereade | rogpeppe, --switch is a great big gun that can blow your whole leg off ;) | 15:13 |
| rogpeppe | fwereade: here's another much simpler validation scheme: just check that charm.Meta.Name() is the same | 15:14 |
| rogpeppe | fwereade: and the relation check too | 15:14 |
| fwereade | rogpeppe, previously considered and discarded, the name is just a heuristic | 15:15 |
| rogpeppe | fwereade: aren't heuristics exactly what we're playing at here? | 15:16 |
| fwereade | rogpeppe, I'm more concerned about --switch not allowing something that's sane than about it allowing something that's insane | 15:16 |
| fwereade | rogpeppe, the only sanity I think we can legitimately care about is that which maes our own internal state invalid | 15:16 |
| rogpeppe | fwereade: i think that people will play by the rules we write | 15:16 |
| fwereade | rogpeppe, everything else is in the hands of the person who hopefully knows well enough what they're doing | 15:16 |
| rogpeppe | fwereade: i think some sanity checks are really useful here. it's so easy to type a wrong url | 15:17 |
| rogpeppe | fwereade: and the settings compatibility checks seem like a Good Thing to me | 15:17 |
| rogpeppe | fwereade: it's not hard to comply with them | 15:17 |
| rogpeppe | fwereade: compatibility rules that say you can change something you already support are quite usual | 15:18 |
| teknico | hi, I'm debugging the juju-gui charm and trying to manually run the config-get command, where do I get the client id it needs? | 15:19 |
| rogpeppe | fwereade: but i think it's perfectly reasonable to say that the charm name is the lynchpin of compatibility | 15:19 |
| rogpeppe | fwereade: heuristic or not. (well, we make it non-heuristic by attaching some semantics to it, i think) | 15:19 |
| fwereade | teknico, sorry, it's basically impossible... well, not *impossible*, but definitely impractical | 15:20 |
| fwereade | teknico, will a CLI get not help? | 15:20 |
| rogpeppe | mgz: ah, a non-descendant of the same root, i suppose | 15:22 |
| teknico | fwereade, what's a CLI get? | 15:22 |
| fwereade | rogpeppe, `juju get myservice [configkey]` | 15:22 |
| rogpeppe | teknico: ^ | 15:22 |
| fwereade | er teknico ^^ | 15:22 |
| mgz | right, it basically refuses to deal with the three-way merge case (which is reasonable) | 15:23 |
| mgz | though it will still screw you over if you have uncommitted changes and don't pass a flag to abort on that too | 15:23 |
| teknico | fwereade, yes, it does, thank you | 15:24 |
| fwereade | teknico, sweet | 15:25 |
| fwereade | rogpeppe, I'm still not following how your proposed checks solve user problems | 15:27 |
| fwereade | rogpeppe, I am taking as an idealistic axiom that charms should work correctly with all-default values, which I know is not strictly true, but I have no interest in making it any easier to deploy charms that are broken by default | 15:28 |
| fwereade | rogpeppe, we don't have the ability to track a charm's provenance, and I'm not sure we want to disallow the possibility of one charm being a drop-in replacement for another | 15:28 |
| rogpeppe | fwereade: does the install hook get called again when a charm is upgraded? | 15:28 |
| fwereade | rogpeppe, no | 15:29 |
| rogpeppe | fwereade: well then. charms should work correctly when *installed from scratch with all-default values*. | 15:29 |
| rogpeppe | fwereade: but starting from the middle, probably not | 15:29 |
| fwereade | rogpeppe, what is the value to users in disallowing a --switch to an arbitrary charm? ISTM that we simply *cannot* know for sure that the user is doing something crazy *except* when existing relations do not match | 15:30 |
| fwereade | rogpeppe, I feel like --switch is an implicit "I know what I'm doing" to which the only acceptable failure is "that action is impossible" rather than "that action appears to be bloody stupid" ;) | 15:31 |
| rogpeppe | fwereade: ISTM that with such a potentially dangerous feature, we should at least have some sanity checking | 15:32 |
| fwereade | rogpeppe, on the other side, when we're upgrading from the same base url, I don't see any value to fossilizing the config | 15:32 |
| rogpeppe | fwereade: yeah, maybe. i'd like to speak to a real user about this issue. | 15:33 |
| Makyo | I'm getting a bunch of panics around mongo when running tests in trunk and out of ideas. I'm on raring, think that might make a difference? | 15:34 |
| rogpeppe | Makyo: paste? | 15:35 |
| fwereade | m_3, rogpeppe and I would be interested to know (1) what level of safety you will require around upgrade-charm --switch and (2) your views on how liberal we should be wrt config conversion at upgrade-charm time (with or without --switch) | 15:36 |
| rogpeppe | fwereade: the user problem i'm imagining is: juju upgrade-charm --switch wordpress # oops, i meant to type one of the dozen other charms that happened to have db and http relations declared. | 15:36 |
| Makyo | rogpeppe, http://pastebin.ubuntu.com/5619482/ | 15:37 |
| rogpeppe | fwereade: perhaps we should do compatibility checks by default, but provide a --force flag to override them | 15:37 |
| fwereade | rogpeppe, I think that if you're using --switch you have a bit of extra responsibility to switch to things that are sane | 15:37 |
| fwereade | rogpeppe, hmm, --force-url? | 15:37 |
| fwereade | rogpeppe, --force's pre-existence is irritating | 15:38 |
| rogpeppe | fwereade: what's the name of the flag currently? | 15:38 |
| fwereade | rogpeppe, there isn't one | 15:38 |
| fwereade | rogpeppe, it's to support a use case originally reported by m_3 | 15:38 |
| fwereade | rogpeppe, it's --switch but nothing has been released with that flag | 15:39 |
| rogpeppe | fwereade: oh, darn, i'd forgotten about the existing --force | 15:39 |
| fwereade | rogpeppe, wrt config changes I am not confident, apart from anything else, that every existing charm is compatible with every version of itself | 15:39 |
| rogpeppe | fwereade: it's highly unlikely to be. | 15:40 |
| fwereade | rogpeppe, so additional checking breaks upgrades that worked before | 15:40 |
| fwereade | rogpeppe, we could probably get away with that ofc | 15:40 |
| rogpeppe | fwereade: but we can probably make the default (non-forced) behaviour reasonably safe | 15:40 |
| fwereade | rogpeppe, what is unsafe about using default values for removed or incompatible settings? | 15:41 |
| rogpeppe | fwereade: just that settings are the only decent indicator that we have of whether a charm really is the same | 15:41 |
| fwereade | rogpeppe, charms *ought* to work with default settings, and if they don't I think I am comfortable calling it a charm bug | 15:42 |
| fwereade | rogpeppe, if it's from the same base charm url we have a pretty good indicator already I think | 15:42 |
| fwereade | rogpeppe, and --switch is a big-boy tool | 15:42 |
| rogpeppe | fwereade: charms will probably work with default settings, but if you upgrade to a random charm, it will probably not work, because its install hook has never been called | 15:42 |
| fwereade | rogpeppe, right, so be careful with --switch | 15:43 |
| rogpeppe | fwereade: we seem to have switched our usual roles here :-) | 15:43 |
| rogpeppe | fwereade: what's wrong with using the charm name again? | 15:44 |
| fwereade | rogpeppe, I was pondering that, and I *think* I'm consistent: sync-tools is a *necessity* for a broad class of users, while --force-url (which I think is better than --switch) is a nice feature for a small group of particularly technical users | 15:44 |
| fwereade | rogpeppe, what does it get us? in the normal case it's redundant, in the --force-url case it's an arbitrary safety guard covering part of one blade on an infernal machine ;) | 15:45 |
| rogpeppe | fwereade: nice features like that have a tendency to be picked up and used by everyone :-) | 15:45 |
| rogpeppe | fwereade: yeah - it's like a safety catch | 15:45 |
| rogpeppe | fwereade: it's easy to disable, but useful nonetheless | 15:46 |
| fwereade | rogpeppe, on one barrel of a terrifying scifi multicannon ;) | 15:46 |
| fwereade | rogpeppe, if the nuke doesn't get you the CAM dusting will | 15:46 |
| rogpeppe | fwereade: that bad? | 15:46 |
| rogpeppe | fwereade: why do we have a charm name anyway? | 15:47 |
| fwereade | rogpeppe, well, yeah, there is an arbitrarily large number of ways a charm can be irreparably broken despite all our checks here | 15:47 |
| rogpeppe | fwereade: i see the mooted charm name check as a symbolic check more than anything | 15:48 |
| === makyo_ is now known as Makyo | ||
| rogpeppe | stupid python question: how do i easily find the source for a given python package? | 16:41 |
| rogpeppe | i'm about to do find / -name pythonpackage, and i'm sure there's a better way | 16:41 |
| benji | rogpeppe: import foo; foo.__file__ | 16:41 |
| benji | (it will normally return a .pyc, just drop the "c" to get the source) | 16:41 |
| ahasenack | or foo.__path__ if it's a module | 16:42 |
| rogpeppe | benji: bingo, thanks | 16:42 |
| benji | my pleasure | 16:42 |
| rogpeppe | mgz, hazmat: i'm thinking that my proposed godeps -u is at least no more dangerous than go get -u, is it? | 16:53 |
| rogpeppe | mgz, hazmat: leaving aside for the time being whether that's sufficiently safe or not | 16:53 |
| mgz | go get -u is indeed a similar thing. | 16:54 |
| rogpeppe | mgz: ha, trying your suggested scenario from before: http://paste.ubuntu.com/5619713/ | 16:58 |
| * rogpeppe has reached eod | 17:01 | |
| rogpeppe | g'night all | 17:02 |
| mgz | rogpeppe: right, it's not a sane thing to do with that bzr model | 17:02 |
| === deryck is now known as deryck[lunch] | ||
| marcoceppi | So, does juju-core have the ability to upgrade the current environment in place? | 18:30 |
| === deryck[lunch] is now known as deryck | ||
| mramm | marcoceppi: it does | 18:50 |
| mramm | marcoceppi: it currently is limited to minor version upgrades (1.10 to 1.11 for example) | 18:51 |
| mramm | marcoceppi: but we will be adding major version upgrades in one of the very next minor version releases | 18:51 |
| marcoceppi | mramm: at a high level, how does it work? is there a juju command for it - or is it just automagic | 18:52 |
| mramm | there is a command | 18:53 |
| mramm | so you get to control when the update happens | 18:53 |
| marcoceppi | cool, good enough for me | 18:53 |
| marcoceppi | thanks | 18:53 |
| m_3 | fwereade: sorry I missed the question about --switch earlier... conferencing atm | 19:39 |
| fwereade | m_3, no worries | 19:39 |
| fwereade | m_3, if you have leisure to read a spot of the conversation that went before, for context, I would be interested to know your thoughts | 19:39 |
| m_3 | I'm wondering if specific charm version should be shown and then specified, but lemme read a bit more carefully | 19:40 |
| fwereade | m_3, we have a separate --revision, which just updates to the specified revision of the charm a service is already using | 19:42 |
| fwereade | m_3, we probably don't output "upgraded from %s to %s", and surely should | 19:42 |
| m_3 | fwereade: yes... I'd almost conider the revision part of the charm namespace | 19:44 |
| fwereade | m_3, not sure what you mean by namespace -- but whenever we describe a charm we should certainly include the rev | 19:45 |
| m_3 | fwereade: but anyways... in answer to the orig question, I think that if the user is specifying both the service and the namespace of the new charm explicitly | 19:46 |
| m_3 | then a '--force' variant is not nec | 19:46 |
| m_3 | fwereade: namespace would mean cs:mysql:5 or local:mysql:37 | 19:47 |
| m_3 | but not really important | 19:47 |
| m_3 | fwereade: should work to have `juju upgrade-charm --switch local:mysql my_database_service` | 19:47 |
| fwereade | m_3, that's the use case I had in mind | 19:48 |
| m_3 | and then the equiv `juju upgrade-charm --switch --revision 5 cs:mysql my_database_service` | 19:48 |
| m_3 | the "cs:mysql" could be "mysql" of course | 19:48 |
| fwereade | m_3, the idea is that charm urls are inferred just as they would be at deploy time | 19:48 |
| m_3 | and --revision optional | 19:48 |
| m_3 | ack | 19:49 |
| fwereade | m_3, we currently have it that --switch and --revision are mutually exclusive | 19:49 |
| fwereade | m_3, seemed simpler all round | 19:49 |
| fwereade | m_3, if you're switching, specify the url properly :) | 19:49 |
| m_3 | but 1.) still service-specific, and 2.) the presence of '--switch' is enough checking imo | 19:49 |
| fwereade | m_3, if you skip revision, you get latest, which is probably what you meant | 19:49 |
| m_3 | fwereade: hmmm.... as to mutially exclusive... | 19:50 |
| fwereade | m_3, --switch foo-1 --revision 2 | 19:50 |
| m_3 | oh, so I only am able to switch from local to the latest store rev? | 19:50 |
| fwereade | m_3, no -- you specify the target charm as precisely as you care to in switch | 19:50 |
| m_3 | but how can I specify target charm revision? | 19:51 |
| m_3 | other than with '--revision' | 19:51 |
| m_3 | oh, just `juju upgrade-charm --revision 5 mysql my_database_service` | 19:51 |
| fwereade | m_3, `--switch foo-1` will be expanded just as it would in deploy to cs:precise/foo-1 | 19:51 |
| fwereade | m_3, I have clearly not explained well at all | 19:52 |
| fwereade | m_3, no args: latest with same base url | 19:52 |
| m_3 | sorry, I'm a bit confused as to how one switches _back_ to the store-based charm | 19:52 |
| m_3 | scenario... `juju deploy mysql` gives me cs revision 5 say | 19:56 |
| m_3 | find a bug... update local:mysql.. then switch with | 19:56 |
| m_3 | sorry... lemme fix the previous | 19:56 |
| m_3 | scenario... `juju deploy mysql mydb` gives me cs revision 5 say | 19:56 |
| m_3 | now | 19:56 |
| m_3 | `juju upgrade-charm --switch local:mysql mydb` | 19:56 |
| m_3 | the fix didn't work... so I revert | 19:56 |
| m_3 | but I'd like to revert to mysql '4' in the cs | 19:56 |
| m_3 | what would the syntax for this be? | 19:56 |
| m_3 | (if the answer is you can only revert back to the latest in the charm store, that's fine) | 19:56 |
| m_3 | but does that "switch" require a '--switch'? | 19:56 |
| fwereade | m_3, `--switch mysql` for the latest; `--switch mysql-127` for a specific rev | 19:56 |
| fwereade | m_3, similarly `--switch local:mysql` or `--switch local:mysql-17` | 19:56 |
| fwereade | m_3, balls, thought of a bug, we might infer the wrong series | 19:56 |
| fwereade | m_3, we should take it from the previous charm url, not from the env | 19:56 |
| fwereade | dimitern, ^ | 19:56 |
| m_3 | fwereade: ack... perfect | 19:57 |
| m_3 | fwereade: also not effecting 'myotherdb' service happily singing along on cs:mysql-5, right? | 19:58 |
| fwereade | m_3, shouldn't do -- there is the usual hairiness around local repos but I think it's near-enough orthogonal | 19:58 |
| m_3 | fwereade: ack... thanks! (and thanks roger) | 19:59 |
| thumper | mramm: did you plan some 1:1 calls? | 21:25 |
| mramm | yea | 21:26 |
| mramm | I do | 21:26 |
| mramm | I just found out an hour ago that I need to get all the blueprints in by tomorrow morning | 21:26 |
| mramm | so I am madly working on that stuff right now | 21:26 |
| mramm | but I should probably take a break and schedule the 1 on 1's or the tyranny of the urgent will get me ;) | 21:26 |
| thumper | :) | 21:27 |
| mramm | thumper: added one for you | 21:49 |
| mramm | already talked to dave on sunday night, but going to touch base again if he's around | 21:49 |
| * thumper nods | 21:53 | |
| davecheney | mramm: ping, you sent me a meeting invite for 45 mins ago | 23:32 |
| === wedgwood is now known as wedgwood_away | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!