[00:39] wallyworld, looks like curtis did open a bug: https://bugs.launchpad.net/juju/+bug/1629985 [00:39] Bug #1629985: TestNewModelConfig can't connect to the local LXD server (lxd 2.3)

[00:39] I assigned it to you [00:39] ok [00:39] alexisb: but it should be assigned to tycho [00:39] as it is his pr [00:40] i assume he will be the one landing the fix [00:40] tych0, are you around to land you PR after wallyworld reviews? [00:40] i am testing it and also reviewing [00:48] https://github.com/juju/juju/pull/6372 anyone? [00:48] I'm off to give the dog a quick walk while the sun is shining === thumper is now known as thumper-dogwalk [01:04] Bug #1629113 opened: Juju deploy wordpress fails with MaaS === thumper-dogwalk is now known as thumper [02:09] thumper: remind me how to see the running workers/goroutines in a controller agent? [02:09] using the developer-mode stuff [02:10] juju-goroutines [02:11] thumper: thanks [03:29] axw: howdy, got time for a hangout about credentials? [03:30] wallyworld: yup, just give me a minute please [03:30] sure [03:31] wallyworld: see you in 1:1? [03:31] yup [04:37] wallyworld: I *think* I've got a fix for the problem of Juju taking ages to recover when the primary controller node goes away [04:37] oh stop it, now you're just teasing [04:39] wallyworld: with the fix in place the cluster recovers (i.e. apiservers back up) in under 30s [04:39] and a good chunk of that time is mongodb arranging a new primary [04:39] wow, finally! [04:39] menn0: was it a mgo fix? [04:39] the fix is hacky at the moment so I won't be proposing it until tomorrow [04:39] nope [04:40] it's around HackLeadership and the handling of state in the apiserver [04:40] joy [04:40] the fix also means that the apiserver no longer needs it's own copy of state [04:40] i'm going to help out at home for a bit now and tidy up the fix later on this evening [04:40] sgtm === frankban|afk is now known as frankban [09:08] Anyone else using lxd 2.3? [09:13] I'm getting weirdly slow juju bootstraps with it - not sure whether it's me or them. [09:49] mwhudson: ping? [09:49] babbageclunk: mmf [09:50] * babbageclunk isn't sure whether that means you're ready to receive or not. [09:50] babbageclunk: it means i should be in bed but i'm not so be quick :) [09:50] mwhudson: Ok! :) [09:51] mwhudson: I'm trying to find a memory leak in Juju [09:51] mwhudson: I found something that purports to view heapdumps, but it needs a patch to Go. [09:52] mwhudson: I was looking at the patch before I tried building it myself and saw a TODO with your name on it. [09:52] babbageclunk: ok [09:52] heh [09:52] uh oh [09:52] where is it? [09:53] mwhudson: So I thought, "Hey, I wonder whether he knows anything about viewing heap dumps." [09:53] https://github.com/tombergan/goheapdump/blob/master/runtime.heapdump.go.patch [09:53] oh [09:54] I've tried a couple of things so far but not managed to get anything to work. [09:54] that's boring, basically if you have a go program used shared libraries you only get part of the info [09:55] babbageclunk: sorry don't really know anything, i'm afraid [09:55] ok, thanks anyway! Sorry to keep you up! [09:56] babbageclunk: i wonder why he hasn't sent that patch upstream [09:56] babbageclunk: no worries, sorry i couldn't help [09:57] mwhudson: Well, I think it's something that's still in flux. Found it from here: https://github.com/golang/go/issues/16410 [09:58] babbageclunk: heh i guess i got all the mails for that issue but just blanked on them :-) [09:58] * mwhudson goes to bed [11:34] morning all [11:34] perrito666: o/ [11:53] Bug #1630123 opened: OpenStack base 45 not being deployed with Juju GUI

[12:27] how do I create a model with a different owner from the cli, does annyone know? [12:50] cmars, rogpeppe1: I'm having trouble understanding the proper behavior of logout/login got a minute to talk? [12:52] natefinch, not at the moment. i may free at 10:30 central [12:52] cmars: ok [13:05] natefinch: what's up? [13:08] rogpeppe1: I'm confused as to the expected behavior of login/logout [13:09] rogpeppe1: if I log out of a GCE environment that I created, is juju supposed to prompt for a password when I log back in? [13:11] natefinch: s/environment/model/ ? [13:11] natefinch: this is without an identity-url configured, right? [13:11] rogpeppe1: yeah, I just bootstrapped with the normal defaults to google [13:12] natefinch: what did the logout command print? [13:12] rogpeppe1: and yes, I guess it's logging into the modelk? or the controller? I'm not sure [13:13] rogpeppe1: $ juju login [13:13] username: admin [13:13] You are now logged in to "gce" as "admin@local". [13:13] natefinch: you always log into a controller, although you may choose an API connection specific to a model when you log in [13:14] natefinch: what did the logout command print? [13:14] rogpeppe1: $ juju logout [13:14] Logged out. You are still logged into 1 controller. [13:14] (after changing my password) [13:15] rogpeppe1: the bug I'm working on says I should be prompted for my password when I log back in, but I'm not sure when that's the case and when it's not, since I know there's some macaroon stuff... [13:15] rogpeppe1: https://bugs.launchpad.net/bugs/1621375 [13:15] Bug #1621375: "juju logout" should clear cookies for the controller [13:15] natefinch: after logging out, what do you see in accounts.yaml ? [13:15] rogpeppe1: gce: [13:15] user: admin@local [13:15] last-known-access: superuser [13:17] natefinch: hmm, that's odd - it should have deleted the entry [13:17] natefinch: although it doesn't have any password, which is also odd [13:17] rogpeppe1: where is the code that controls the password etc? I can't seem to find it [13:18] natefinch: what does "juju switch" print? [13:18] natefinch: inside the jujuclient package [13:18] rogpeppe1: at the time, gce was my default controller... I have since messed with things [13:19] * natefinch rebootstraps to do more testing [13:19] natefinch: so if you do: "juju switch gce; juju logout", so you still have gce entry in your accounts.yaml ? [13:19] natefinch: you shouldn't need to re-bootstrap [13:19] natefinch: this is a client-side problem AFAICS [13:20] rogpeppe1: yes, I just couldn't find the client side code :) [13:20] rogpeppe1: also, I wasn't clear on when it should prompt and when it shuld not, based on macaroons and all that jazz [13:22] rogpeppe1: where's the code that produces the password prompt? some naive greps under jujuclient isn't finding much [13:25] natefinch: after it's told you it's logged in, can you actually use the connection (e.g. use juju status, juju list-models, etc?) [13:26] rogpeppe1: yep [13:26] rogpeppe1: just tried it [13:27] natefinch: ISTR there's a "local login" macaroon created somewhere, and it looks as if logout is failing to delete it [13:27] natefinch: axw is the man to talk to [13:28] rogpeppe1: k, thanks [13:32] natefinch: it's almost certainly in the cookie jar [13:33] natefinch: if you get logout to remove all cookies in the cookie jar associated with the controller, it'll probably work [13:34] natefinch: FWIW the password prompting is hooked up in modelcmd.NewAPIContext (environschema.v1/form is the thing that actually does the prompting) [13:36] natefinch: hmm, actually i'm not sure about that [13:41] babbageclunk, ping [13:45] rogpeppe1: ok, thanks, I'll look at that.... [13:46] rogpeppe1: totally would not expect a function called NewAPIContext to do login stuff [13:49] natefinch: actually, the user password stuff is done in api/authentication [13:50] natefinch: in Visitor.VisitWebPage [13:51] rogpeppe1: yeah, I was just looking there. Again.. VisitWebPage is not a function I would expect to prompt for a password via the command line :/ [13:51] Bug #1630123 changed: OpenStack base 45 not being deployed with Juju GUI [13:51] natefinch: yeah, history plays a role in that name [13:52] natefinch: i think "Interact" might be a better name really [13:56] natefinch: i'm going for lunch now === alexisb is now known as alexisb-afk [13:57] rogpeppe1: kk [13:57] rogpeppe1: thanks for the help [13:57] natefinch: np [13:59] mgz: pingg [13:59] voidspace: yo [14:00] mgz: I need help with vsphere and the company vpn [14:00] mgz: ah, it's standup time [14:00] I'm in standup for fast bandwidth options too [14:00] mgz: cool [14:00] happy to hang on after [14:01] oh, look at that, you cant add-model for a user other than you when you have add-model [14:01] rick_h_: alexisb-afk is that the intended behavior? [14:01] natefinch: ping for standup [14:01] perrito666: huh? [14:01] rick_h_: lets say I grant you addmodel [14:01] you can juju addmodel mymodel [14:01] which makes you happy [14:02] but you can not juju add-model --owner=perrito hismodel [14:07] ok, I might get soon disconnected [14:07] guess who lives where that giant blob of red is going http://www.smn.gov.ar/vmsr/general.php?dir=YVcxaFoyVnVaWE12WVhKblpXNTBhVzVoYzJWamRHOXlhWHBoWkdFdmFXNW1MM05q [14:09] perrito666, stay safe [14:09] alexisb-afk: I have a roof :p [14:09] but I dont have faith on my internet air link [14:12] rick_h_: ping me after standup so we discuss this plz [14:13] perrito666: rgr [15:06] rick_h_: dont forget me [15:09] perrito666: mind talking through some architecture details with me while you wait for rick_h_? :) [15:11] babbageclunk: I was thiking on lunching but I can spare a few mins [15:11] what can I do for you? [15:12] perrito666: sorry, otp having fun [15:12] perrito666: will ping when free sorry [15:13] perrito666: Thanks! I've tracked down a memory leak to us keeping State instances in the api server statePool even after they're destroyed and never closing them. [15:13] perrito666: I mean, after the corresponding model is destroyed. [15:14] perrito666: And I'm trying to work out how to go about closing them when the model is destroyed. [15:17] perrito666: There doesn't seem to be any way that a state from the pool can be returned to the pool - can state objects be shared between goroutines/concurrent requests? [15:17] babbageclunk: doesnt state knows best and figures the model is gone? [15:19] babbageclunk: point me to the code [15:19] perrito666: Not as far as I can see - at least, the worker stopping done in State.Close() doesn't happen. [15:19] perrito666: finding links... [15:21] perrito666: This is the stuff that doesn't happen: https://github.com/juju/juju/blob/master/state/open.go#L522 [15:21] perrito666: state pool: https://github.com/juju/juju/blob/master/state/pool.go [15:22] perrito666: Here's where it gets the state from the pool to serve a request: https://github.com/juju/juju/blob/master/apiserver/apiserver.go#L556 [15:22] so, close is actually never happening? [15:23] babbageclunk: this is essentially a connection pool. so the connections to mongo won't be closed until close is called on the pool which (guessing here) will only happen when the process is torn down? [15:23] perrito666: I mean, the server will close the pool if it gets shut down, and that will close the states. [15:23] babbageclunk: i.e. it's ok that close isn't being called on the connections -- we want them to stay open [15:24] babbageclunk: what is the memory leak you're tracking down? [15:24] ill let you with katco for a moment as the oven is beeping [15:24] katco: lots of add-models/destroy-models in a row. [15:24] katco: bug 1625774 [15:24] Bug #1625774: memory leak after repeated model creation/destruction

[15:24] perrito666: Thanks! [15:25] babbageclunk: ah i see the logic bug then [15:25] katco: It seems less like a connection pool and more like a cache. [15:25] babbageclunk: it's a connection pool (a cache of connections ;p) [15:26] babbageclunk: so close can only be called on the pool, not for a model [15:26] babbageclunk: so when you do add/destroy modela bunch of times, you get a lot of connections cached, but connections for the model you destroy hang around for the life of the pool [15:26] katco: :) Sure, but in others I've seen there's a concept of taking the connection out of the pool while it's in use and returning it. [15:26] katco: That's right/ [15:27] babbageclunk: errr... i made a bad assumption. i wonder why we're not using sync.Pool for this [15:27] babbageclunk: i suppose bc we want multiple people using 1 connection [15:27] katco: Ok - that's the bit I wasn't sure about. [15:28] babbageclunk: you are correct: this is a cache and not a pool [15:28] babbageclunk: so basically all you need to do is to make sure that the code-path the destroys the model closes the connection from the cache and removes it [15:28] katco: Ooh, I didn't know about sync.Pool. Neat. [15:28] babbageclunk: yep [15:29] babbageclunk: maybe not useful here. i suppose the value in the map here could be a sync.pool [15:29] katco: Yeah, that's what I was thinking - the bit I wasn't sure about was making sure that others weren't using the state when I close it. [15:31] babbageclunk: i imagine you'd need a refcount for that. i wonder if we could deduce a logically safe way though wherein a call to invalidate the cache is guaranteed to be the only consumer [15:32] babbageclunk: i.e. if you destroy the model, you could create a watcher that waits until the model is destroyed, and then invalidate the cache knowing nothing else could be using it? [15:32] katco: Yeah, that would make sense. [15:32] babbageclunk: but i don't know the specifics. that's going to require a deep=dive [15:33] katco: Also, maybe this is the source of some other weird bugs we see around destroy-model - old state objects still swimming in the pool after the model's gone away. [15:33] babbageclunk: or the refcount with a drain op. dunno which is cleanest/logically most correct [15:34] cmars: ping when you get the time about macaroons / logout etc [15:34] babbageclunk: like what? [15:35] katco: in the course of reproducing this I've gotten into states where I had models that would show up in list-models but couldn't be destroyed. [15:35] natefinch, i'm available now [15:36] babbageclunk: =| i'm not sure open connections to state would cause that? [15:37] katco: I'm not sure it would either, just wondering. [15:37] babbageclunk: converge the code towards correctness and we'll get there ;) [15:37] katco: :) [15:38] katco: ok, so you think it's deliberate that the pool allows multiple requests to share states? [15:38] cmars: ok - https://hangouts.google.com/hangouts/_/canonical.com/core?pli=1&authuser=2 [15:38] babbageclunk: probably; to limit the number of connections open. ironically to prevent what you're trying to solve [15:39] babbageclunk: i know we had a go at reducing memory leaks, and this was probably part of it [15:39] babbageclunk: if not, we should be using sync.Pool [15:40] babbageclunk: looks like this is over a year old though [15:40] katco: ok, doing some code archaeology to understand the history. [15:44] katco: Thanks for the help! I'll probably have more questions soon. :) [15:45] babbageclunk: hth! not an expert on this by any means, but looked like i understood what was happening [15:46] katco: might pick Menno's brains about it too - he's all through the blame for it. [15:46] babbageclunk: lol yep [15:48] voidspace: is https://bugs.launchpad.net/juju/+bug/1616098 related at all to your investigation? [15:48] Bug #1616098: Juju 2.0 uses random IP for 'PUBLIC-ADDRESS' with MAAS 2.0 <4010> [16:04] rick_h_: looking [16:06] rick_h_: I don't believe so [16:06] rick_h_: the vsphere issue, use fe80:: as an address, which is a loopback address - is a fairly specific problem I think [16:07] rick_h_: so that bug is a different one - partly impacted by my changes as addresses are now sorted (hence the "lower" address noted in Ante's latest comment) [16:07] rick_h_: there's currently no space awareness in the public address picking logic [16:08] rick_h_: but as we have to pick *one* address, it's not immediately clear to me how we should resolve that [16:08] rick_h_: so bug 1616098 is definitely related to the address picking logic I've worked on, the vsphere one is different [16:08] Bug #1616098: Juju 2.0 uses random IP for 'PUBLIC-ADDRESS' with MAAS 2.0 <4010> [16:09] voidspace: k, ty [16:10] rick_h_: the issue there is that the machine has multiple public IPs, some of which are not routable, and the address picking logic just has to pick one [16:10] rick_h_: that logic is currently space unaware - it needs to become space aware and pick an address from a space that the controller is in [16:10] voidspace: rgr, have to think on it. It's on my list of stuff we don't seem to have a firm rulebook for [16:11] rick_h_: I think that rule "pick an IP from space the controller machine is in" works [16:11] rick_h_: then the public IP is routable from the controller, so we can ssh to it [16:13] *a space === alexisb-afk is now known as alexisb [16:42] can someone explain the difference of these two to me? https://github.com/juju/names/blob/v2/application.go#L13 https://github.com/juju/charm/blob/v6-unstable/url.go#L49 [16:43] the one diff is the firm ending $ on the second. [16:44] though not sure what effect that would have [16:44] in practice [16:44] rick_h_: i'm not looking for a comparison of regexes :p [16:44] katco: heh, ok then have to be more clear on "explain the diff" :) [16:44] rick_h_: aren't the two concepts equivalent? do we have 2 checks in different libs? [16:46] rick_h_: i think "name" in the charm lib is the same as "app" in our names lib? i think we should be centralizing checks in our names lib? [16:48] katco: there is the work to make sure they're compatible. I'm not sure why names is not a dep in charm to share the logic. [16:48] rick_h_: it is actually a dep... not sure why it isn't just using the logic though [16:49] rick_h_: that makes it all the more puzzling =/ [16:49] katco: ok, then even more "don't know" [16:49] rick_h_: haha [16:49] rick_h_: would you consider "series" something else that should be validated in names? [16:49] katco: I'd suggest asking rogpeppe1 ^ for any justification and if none then carry on [16:49] * rogpeppe1 looks [16:49] katco: hmm, maybe as far as reserved words go, but not sure how easy series are to pull in like that in a light weight way [16:50] rogpeppe1: ta [16:50] rick_h_: https://github.com/juju/charm/blob/v6-unstable/url.go#L48 [16:50] rick_h_: i would just look to pull this same validation logic over [16:50] katco: hmm, that's interesting. Since series are hard coded a regex to valid them seems interseting [16:51] rick_h_: juju proper does more validation against a fixed list. something else we might want to pull over into names [16:51] rick_h_: i think we go in circles on this stuff bc there's no clarity across the team at a high-level as to what libs are for. lots and lots of reimplementation of thing [16:51] katco: they match identical texts [16:52] rogpeppe1: sorry, can you restate? [16:52] katco: the names one has a few non-grouping qualifiers [16:52] katco: they're the same expression [16:52] rogpeppe1: right, so can we nix the one in charm and consolidate to names? [16:52] katco: but the names one has ?: qualifiers to prevent subgroup matching [16:52] rogpeppe1: also, any opposition to moving the series check over? [16:53] katco: i think it's probably fine for the charm package to use names.ApplicationSnippet instead of validName [16:54] katco: the series check? [16:54] rogpeppe1: see the regex in charm right above the name regex [16:54] rogpeppe1: https://github.com/juju/charm/blob/v6-unstable/url.go#L48 [16:55] katco: does names need to know about series? [16:55] rogpeppe1: same question for schema. can we centralize all correctness logic to the names lib? [16:56] rogpeppe1: this is my fundamental question: is the names lib where we centralize correctness checks? [16:56] katco: i'm wary of moving all "name" logic to juju/names. names are not all the same. [16:57] rogpeppe1: can you state what you feel the purpose of the name lib is? [16:57] katco: i think that moving all checks for all name-like things to juju/names is a recipe for mixed concerns. [16:57] katco: it's about names of juju entities in a juju controller [16:57] rogpeppe1: not names of charms themselves? [16:58] katco: i think that charm urls could be considered separate, yes [16:58] katco: where do we stop? do we put all the charm URL parsing code in names.v2 too? [16:59] rogpeppe1: if that's the case, then i think it's correct that the two are separate. how the controller spells charm entities is only coincidentally (and maybe not permanently) the same [16:59] katco: yeah, actually, that's right [16:59] rogpeppe1: i wonder how we can make that justification clear... [17:00] katco: an application name really is different from the name of a charm in the charm store [17:00] katco: even though the default application name is taken from the charm name [17:01] rogpeppe1: yeah makes sense [17:01] rogpeppe1: ta for the clarity [17:01] katco: tbh i still don't mind the charm package using ApplicationName for the constant [17:02] rogpeppe1: they're not logically coupled, so imo, i don't think it makes sense to artificially do so [17:03] katco: fair enough, i pretty much concur === frankban is now known as frankban|afk [17:33] * rick_h_ grabs lunchables [17:46] * perrito666 learns that he must close the huge closing of his garage before the storm [17:46] perrito666: stay safe down there [17:46] I am safe, a bit wet though [17:47] I have one of these things http://mla-d2-p.mlstatic.com/toldo-vertical-para-balcon-toldos-de-lona-para-balcones-716221-MLA20740247242_052016-F.jpg?square=false [17:47] but its one big piece, a good 4m width [17:47] and was half deployed when the wind storm started [17:48] good news is I closed it before it was ripped apart [17:48] bad news is I am soaking wet [17:54] https://pbs.twimg.com/media/Ct8R1BPWAAAsAxb.jpg:large <-- as you can see, the water level is at the first step of the house :p [18:00] yikes [18:00] no worries, I guessed this would happen so I built the house 1m above ground [18:01] I am a bit surprised I still have internet though [18:04] I live on a hill like 10m above the nearest low point. If my house ever floods, water in the basement will be the least of my worries [18:05] build an ark [18:06] pretty much [19:16] * rick_h_ goes to get boy from school [19:59] this city cannot stand rain http://www.lavoz.com.ar/ciudadanos/tormenta-en-cordoba-con-granizo-y-calles-anegadas?cx_level=catastrofe [19:59] that is 2 hs of rain [20:02] yikes [20:03] gah, who decided that SetCookies(url, nil) would be a NOOP instead of just deleting all cookies? [20:07] perrito666, you around ? [20:08] alexisb: sorry here, Was trying to avoid a few tiles from flying from my roof [20:08] o boy [20:08] perrito666, do you need to be left alone? [20:08] alexisb: no, I decided that its the roofers problem, not mine [20:08] pretty sure there's only one answer to that question ;) [20:09] I am not climbing to the roof in the middle of a storm [20:09] hey perrito666 can you help tych0 with a question [20:09] sure I can [20:09] tych0, has a failed merge due to dep updates [20:10] see https://github.com/juju/juju/pull/6367 [20:10] tych0: sorry to hear that [20:10] i'm trying to untangle it now [20:10] perrito666, do you know what he needs to do to move things forward? [20:10] but supposing i can't, what's the policy on adding new deps? [20:11] tych0: afaik, adding new deps needs to go through the tech board [20:11] tych0: they need to be reviewed. what's the new dep? [20:11] * perrito666 reads the code [20:11] tych0: it needs license review/etc [20:12] tych0: I dont see you adding a new dep [20:12] rick_h_: https://github.com/inconshreveable/log15 [20:13] tych0: where is that being added? [20:14] tych0: why that dep vs the standard logging tools in core? [20:14] tych0: that might cause issues [20:14] ok, i'm hearing "no" then :) [20:14] that will cause issues most likely [20:14] especially since we are doing the logs to mongo thing [20:15] perrito666: tych0 yea, and audit logs/etc. a new logging tool will make things complicated [20:15] tych0: also, I dont see on your code where is this added, I am confused [20:15] perrito666: it's picked up in the github.com/lxc/lxd hash update [20:16] tych0: oic, a dep if a dep? [20:16] i didn't add it to juju explicitly, lxd added a dep mostly accidentally [20:16] .... that is different [20:16] wallyworld: ^ [20:16] wallyworld: has opinions and isbon the board and such [20:18] rick_h_, ian is hopefully sleeping [20:18] alexisb: nonsense, ian doesnt sleep [20:19] alexisb: ah, was thinking the evening call was closer than it is [20:19] * rick_h_ actually looks at clock [20:20] do we need to add the dep of the dep directly to juju [20:21] (it's also possible that none of this is necessary if i can untangle it) [20:21] alexisb: i hooe it's not that bad, but it provavly still does need license review and such [20:23] rick_h_, ack [20:23] alexisb: Is Menno around today? His name's on the StatePool which is what's hanging onto States. [20:23] babbageclunk, he is [20:23] cool cool [20:24] but it will be another 30 minute sbefore he start of day [20:24] babbageclunk, ^^ [20:25] rick_h_: ideally lxc people should have checked that and if we are licence compatible with them that should be enough, if they did not they might have tainted the code and are in deep s***t [20:25] tych0: do you have more info about that? [20:26] babbageclunk: heavy summoning skills [20:27] perrito666: ha ha [20:27] perrito666: about what? [20:27] perrito666: it's apache license should be good [20:27] tych0: I invoked menn0. [20:27] tych0: what rick_h_ said [20:27] tych0: duh ignore me [20:27] wat? [20:28] perrito666: yes, we check licenses :) [20:28] menn0: morning! [20:28] babbageclunk: howdy :) [20:28] o/ babbageclunk [20:28] thumper: o/ [20:28] hey thumper [20:29] menn0: Actually, just need to walk Alice's sister back to her hotel - can I grab you in 15 mins? [20:29] babbageclunk: sure [20:30] menn0: For context, I'm chasing bug 1625774 and it turns out it's state.StatePool hanging onto State instances. So I think it needs to grow a way to release them for models that have gone away. [20:30] Bug #1625774: memory leak after repeated model creation/destruction