[00:52] <stokachu> wallyworld, should i be doing a PR against staging branch on GH?
[00:52] <stokachu> it's a small change to the bash completion so nothing major
[00:52] <anastasiamac> stokachu: what release is it for?
[00:52] <wallyworld> stokachu: propose against develop. that will get into staging automatically after each blessed CI tun
[00:52] <anastasiamac> stokachu: develop is essentially 2.2
[00:53] <stokachu> ok cool
[00:53] <anastasiamac> stokachu: if u need it in 2.1, propose against 2.1
[00:53] <wallyworld> good point if it's for 2.1 then PR gainst 2.1
[00:53] <anastasiamac> stokachu: which will b merged in develop and then eventually staging
[00:53] <stokachu> ok so propose against 2.1 branch and it will go into develop/staging?
[00:54] <anastasiamac> stokachu: yes
[00:54] <stokachu> anastasiamac, great, thanks
[00:54] <anastasiamac> stokachu: here to help \o/
[01:09] <stokachu> ok lets see how this looks https://github.com/juju/juju/pull/6927
[01:09]  * anastasiamac looking
[01:17] <stokachu> anastasiamac, when you say flag do you just have to mention them and thats it?
[01:17] <stokachu> or do i need to do anything
[01:18] <anastasiamac> stokachu: I have "flagged" them by virtue of @ on github :) hipefully they'll notice and will know what to do with it ;)
[01:18] <stokachu> anastasiamac, ok cool thanks
[01:19] <anastasiamac> stokachu: ideally, we'd ove to have QA tests for this to ensure that code behaves but also that priorites are respected
[01:19] <anastasiamac> love*
[01:20] <stokachu> anastasiamac, yea maybe some expect tests would be nice
[01:44] <wallyworld> perrito666: did you test your mongo tuning work when the server rebooted? it seems the values as set in mongo.go are not sticky
[01:46] <perrito666> I did I even upgraded
[01:46] <perrito666> You mean the cache size one?
[01:48] <stokachu> wallyworld, do you guys want a force push to squish additional commits into one?
[01:48] <stokachu> anastasiamac, ^
[01:48] <wallyworld> stokachu: many folks do that, some don't
[01:48] <wallyworld> us bzr refugees hate throwing away history
[01:48] <stokachu> is there a preference?
[01:49] <wallyworld> depends who you ask :-)
[01:49] <stokachu> haha
[01:49] <anastasiamac> stokachu: no preference here, but history is nice \o/
[01:49] <stokachu> ok cool ill stick to that
[01:49] <anastasiamac> world would b better place if history was remembered :D
[01:49] <wallyworld> except git discourages that :-(
[01:58] <perrito666> stokachu: in my opinion history is good while each commit compiles
[01:59] <perrito666> wallyworld: btw, did you see my answer to the mongo tuning?
[01:59] <wallyworld> which answer?
[01:59] <wallyworld> oh, that one
[01:59] <wallyworld> perrito666: i mean a server reboot
[02:00] <perrito666> wallyworld: but by tuning you mean the mongo cache size?
[02:00] <wallyworld> the hugepage values are not applied again
[02:00] <perrito666> ahh I see, that is odd
[02:00] <wallyworld> well ensure mongo is not run every agent start yo
[02:00] <wallyworld> up
[02:00] <perrito666> wallyworld: it should
[02:01] <wallyworld> unless i tested wrong
[02:01] <wallyworld> which i could have done
[02:02] <perrito666> wallyworld: mm, you might be right
[02:02] <wallyworld> did you test it?
[02:02] <wallyworld> enesure mongo only runs at bootstrap i am almost certain
[02:02] <perrito666> wallyworld: I did, but I might have got confused by the syslog output
[02:02] <wallyworld> and hence the hugpage values are no reapplied
[02:03] <wallyworld> i can't see a way of adding those to sysctl.conf so will find another way
[02:04] <perrito666> wallyworld: I believe ensuremongoserver IS called upon restart but cant be sure because its inside a convoluted network of manifold nonsense
[02:04] <perrito666> this code looks like javascript spaghetti
[02:04] <wallyworld> EnsureMongo is called from jujud/bootstrap.go
[02:04] <wallyworld> that is only run once at bootstrap time
[02:04] <perrito666> becaise its called by MachineAgent.initState which is passed as OpenState in machine.ManifoldsConfig
[02:05] <perrito666> wallyworld: EnsureMongoServer
[02:05] <perrito666> wallyworld: for reasons completely unknown to me: cmd/jujud/util/util.go:	EnsureMongoServer = mongo.EnsureServer
[02:05] <wallyworld> right, called from func (c *BootstrapCommand) startMongo
[02:05] <perrito666> wallyworld: then cmd/jujud/agent/machine.go:	if err := cmdutil.EnsureMongoServer(ensureServerParams); err != nil {
[02:06] <perrito666> wallyworld: that is eventually called by MachineAgent.ensureMongoServer
[02:06] <wallyworld> is that in 2.1?
[02:07] <perrito666> wallyworld: ghaa, that fix is not applied to 2.1 of course,
[02:07] <perrito666> it is though
[02:07] <perrito666> if you look at cmd/jujud/agent/machine.go line 1352
[02:08] <wallyworld> ok, i'll dig into it a bit
[02:08] <perrito666> the only difference is that a fix removing the if !mongoInstalled has not been applied
[02:09] <wallyworld> right, i do not want to remove that
[02:09] <wallyworld> that check is there for a reason
[02:09] <perrito666> wallyworld: no, it isnt
[02:09] <wallyworld> removing it would be wrong
[02:09] <perrito666> wallyworld: its wrong
[02:10] <wallyworld> if we have already installed mongo, there's no need to go through the work of doing it again
[02:10] <perrito666> wallyworld: that check means "if there is a service file for mongo dont make sure its there"
[02:10] <perrito666> wallyworld: its just por wording
[02:10] <perrito666> wallyworld: what it actually checks is that systemd/upstart file is there
[02:10] <perrito666> if not it re-generates it
[02:10] <perrito666> you want to re-generate it in case mongo parameters have changed
[02:11] <wallyworld> but it all installs mongod all over again etc
[02:11] <wallyworld> EnsureMongo does a lot more than just mess with conf files
[02:13] <perrito666> wallyworld: it should be idempotent, if its not, something is effed up
[02:13] <wallyworld> is is of course. but it's unnecessary work
[02:13] <wallyworld> overhead to starting up the agent
[02:14] <wallyworld> messing with packaging etc
[02:14] <wallyworld> maybe we don't care
[02:14] <perrito666> wallyworld: you are not restarting 1k times per second
[02:15] <wallyworld> still potentially hits repos etc
[02:15] <perrito666> its an unnecessary optimization and, incidentally, also a bug :p
[02:15] <wallyworld> slow network would cause agent startup to hang for a bit
[02:15] <wallyworld> i disagree it's unnecessary
[02:16] <perrito666> wallyworld: allow me to quote william on that one: show me numbers
[02:16] <wallyworld> there's a difference between applying new config and installing mongo
[02:16] <perrito666> apt will not hit repos for installed packages
[02:16] <perrito666> apt will just say "all this is installed" since the dependency resolution is done offline
[02:17] <wallyworld> i'll backport from develop then since it's already landed there
[02:18] <perrito666> wallyworld: :) see, all it takes is some civiliced conversation and quoting william
[02:18] <wallyworld> i still think we should have separated cfg management from othe rthings
[02:18] <wallyworld> it's just too hard to do anything else right now
[02:18] <perrito666> wallyworld: sure, also we should not have used mongo but we are too late to fix things done 2 years ago
[02:19] <wallyworld> well changing this behaviour wasn't done 2 years ago
[02:19] <thumper> ugh
[02:19] <perrito666> wallyworld: EnsureMongo is at least 2 years old
[02:19] <wallyworld> we don't for example attempt to install over and over all of our other packages
[02:19] <thumper> fixing the conflicts in this branch is *awesome*
[02:19] <wallyworld> perrito666: sure ENsureMongo is 2 years old, but calling it every time unnecessarily isn't
[02:20] <perrito666> wallyworld: we dont install other packages, juju is not installed using apt
[02:20] <wallyworld> juju install dependencies
[02:20] <wallyworld> using apt as part of bootstrap
[02:20] <perrito666> wallyworld: perhaps we should
[02:20] <wallyworld> disagree
[02:21] <perrito666> wallyworld: apt-get install on an already intalled package takes:
[02:21] <perrito666> real	0m0.807s
[02:21] <perrito666> user	0m0.768s
[02:21] <perrito666> sys	0m0.028s
[02:21] <wallyworld> it's not just that - it's the inconsistent behaviour
[02:22] <perrito666> we install mongo separately from the other packages, its not entirely inconsistent
[02:22] <wallyworld> some packages are reinstalled each agent start up, others aren't
[02:22] <wallyworld> anyways, looks like there's only one way forward
[02:22] <perrito666> wallyworld: there are not reisntalled, its a no-op they are never going to be reinstalled
[02:22] <wallyworld> i didn't mean that literally
[02:22] <perrito666> wallyworld: you are free to add an EnsureServerParams field that avoids the apt call if it makes you happy
[02:23] <perrito666> it should be trivial and harmless
[02:23] <wallyworld> not for 2.1, i'll just stick to what was done for develop
[02:23] <wallyworld> we haven't got time to change all that at the moment
[02:24] <perrito666> wallyworld: suit yourself, for me the apt call is free and harmless and consistent with a gazillion other idempotent behaviors and keeps mongo startup encapsulated
[02:24] <perrito666> leverage the tools at hand, no need to re-implement checks that the package manager does for free
[02:25] <wallyworld> nothing is ever "free" :-) but will stick to that
[02:25] <perrito666> wallyworld: we should have a discussion about marginal costs some day :p
[02:25] <perrito666> also my eye drops just stopped making effect so I am going to sleep
[02:25] <wallyworld> ttyl
[02:29] <wallyworld> axw: remind me, do we support controllers on redhat? or just ubuntu
[02:29] <axw> wallyworld: just ubuntu
[02:29] <wallyworld> ok, ta. the kernal tweaks to disable hug pages are potentially different on redhat
[02:34] <thumper> hug pages?
[02:34]  * thumper needs a hug
[02:35] <anastasiamac> thumper: potentially different hug, like redhat?
[02:35] <thumper> :)
[02:35] <anastasiamac> looks like we are disabling hugs per above :D
[02:51] <wallyworld> sigh
[03:06] <axw> thumper: can you please take a look at https://github.com/juju/cmd/pull/46?
[03:07]  * thumper looks
[03:07] <thumper> axw: we don't need to do it this way... I don't think
[03:07] <thumper> axw: we have other places that do special output for a single value
[03:07] <thumper> you just don't call the format method
[03:07] <thumper> but write the output
[03:08] <axw> thumper: we have a broken version in "model-config", which isn't honouring --output
[03:08] <axw> thumper: fixed in my upcoming PR
[03:08] <thumper> ok
[03:09] <axw> thumper: the alternative would be to expose the io.WriteCloser to the command, but then it needs to close the file. seems a bit safer/neater this way to me
[03:09]  * thumper nods
[03:11] <thumper> axw: lgtm
[03:11] <axw> thumper: thanks
[03:26]  * thumper out... 
[03:34] <axw> anastasiamac and/or wallyworld: when you can, please take a look at https://github.com/juju/juju/pull/6928
[03:34] <wallyworld> ok
[03:38] <wallyworld> axw: what was the dep change?
[03:40] <axw> wallyworld: https://github.com/juju/cmd/pull/46
[03:43] <wallyworld> lgtm, thNK
[04:25] <axw> anastasiamac: what is "eda" ?
[04:26] <anastasiamac> axw: Escaped Defect Analysis
[04:26] <axw> anastasiamac: okey dokey. thanks
[04:26] <anastasiamac> axw: means it got out into the wild, should have been caught in QA by functional test (possibly)
[04:26]  * axw nods
[04:27] <anastasiamac> axw: QA specifically monitor bugs with this tag :) so it's a means of us flagging the bug to their attention...
[04:27] <anastasiamac> for us*
[04:27] <axw> anastasiamac: ah ok
[06:07] <pranav_> Hi. I have a question regarding Cinder charm.
[06:08] <pranav_> If i locally modify the cinder.conf through the shell and then modify config through the juju-gui
[06:08] <pranav_> the local changes get overridden. Any workaround this?
[07:14] <wallyworld> pranav_: you may be better asking in #juju where likely to be folks with more direct experience on that issue
[07:20] <blahdeblah> Anything I can do to get new regions available in GCE on 2.0.2?
[07:24] <anastasiamac> axw: m looking at ur 6929 pr :)
[07:26] <pranav_> wallyworld: doing it in parallel on both :)
[07:27] <wallyworld> if you don't what you need, an email to the juju list normally gets answers as well
[07:28] <wallyworld> blahdeblah: is the region in public clouds yaml? if so, update-clouds should do it
[07:29] <blahdeblah> wallyworld: I did an upgrade-clouds, and the regions closest to us (US West & Asia East) weren't there.
[07:30] <wallyworld> blahdeblah: hmmm, it may be the publoc clouds yaml needs updating
[07:32] <wallyworld> blahdeblah: yeah, the public clouds yaml file oooks out of date to me http://streams.canonical.com/juju/public-clouds.syaml
[07:33] <wallyworld> blahdeblah: you can for now edit your own clouds.yaml file with the new regions
[07:33]  * blahdeblah looks for clouds.yaml
[07:34] <wallyworld> it won't be there unless you create it
[07:34] <wallyworld> you can use juju add-cloud
[07:34] <blahdeblah> I've got a ~/.local/share/juju/clouds.yaml with canonistack & maas in it.
[07:34] <wallyworld> that CLI command takes a cloud name and an optional yaml file
[07:35] <wallyworld> ok, so you can copy the gce cloud info from public clouds and edit it
[07:35] <blahdeblah> OK - thanks; will give that a try
[07:35] <wallyworld> put it in your local file
[07:35] <wallyworld> keep the cloud name the same - it will override the upstream
[07:36] <wallyworld> we'll haveto organise to get publoc clouds yaml updated
[07:39] <blahdeblah> thanks wallyworld
[07:39] <wallyworld> i'm off to soccer soon, but let me know if you still have issues with the workaround
[07:43] <blahdeblah> that seemed to work fine; much appreciated, wallyworld
[07:47] <wallyworld> yay, great
[07:50] <wallyworld> blahdeblah: i raised bug 1662449. no need to target to 2.1 since fixing the yaml will alllow 2.1 and 2.0.2 to get the latest regions with upload-clouds
[07:50] <mup> Bug #1662449: public clouds missing google regions <juju:Triaged> <https://launchpad.net/bugs/1662449>
[07:51] <blahdeblah> I had it wrong; it was US West & Asia Northeast which were missing
[07:51] <blahdeblah> I'll update bug
[08:40] <axw> protip: reboot -h does not mean reboot --help
[08:57] <axw> anastasiamac: if you're still around, here's another one: https://github.com/juju/juju/pull/6930
[08:59] <anastasiamac> axw: have soccer but m happy to look when/if m back
[08:59] <axw> anastasiamac: I hope you don't stay at soccer forever... thanks :p it can wait till tomorrow
[09:00] <anastasiamac> axw: \o/ soccer forever... nice :D
[10:32] <jam> axw: yeah, same for shutdown -h
[10:33] <axw> jam: yeah I knew that one, didn't realise reboot did the same
[10:33] <axw> reboot --halt seems weird
[10:34] <axw> poweroff rather
[10:34] <jam> axw: I have a feeling it is the sort of 'everything is linked to the same object'
[10:34] <anastasiamac> axw: good one \o/ i hope it did not cause u too much pain ;(
[10:34] <axw> jam: yup. -> systemctl
[10:34] <axw> anastasiamac: nah, just annoying
[10:34] <jam> axw: or ultimately "busybox" :)
[10:35] <anastasiamac> axw: i imagine :)
[10:35] <axw> jam: can you bind an endpoint to a space after deployment?
[10:36] <jam> axw: no, we don't have moving things
[10:36] <jam> axw: we'd probably like to get there, but there are the risks around "not all units are in the same space"
[10:37] <jam> axw: would you mind if we set up a regular "standup" like call together? I'm finding that without a team around it can be hard for me to organize my next steps sometimes.
[10:37] <axw> jam: sure, no worries
[10:38] <axw> jam: what time would be best for you? you're +4 right?
[10:41] <jam> yeah. start-of-my-day would be good, which is around UTC 5, but I'm open for whatever time
[10:41] <axw> jam: that'll work
[10:42]  * axw bbl
[11:19] <anastasiamac_> axw: (I hope u r afk but) LGTM :)
[11:42] <axw> anastasiamac_: thanks
[11:42] <anastasiamac_> axw: my pleasure \o/ awlways amazingly nice to see ur code ;)
[11:44] <perrito666> morning all
[11:45] <anastasiamac_> perrito666: o/
[11:57] <perrito666> jam: would you stamp the backport? https://github.com/juju/juju/pull/6931
[11:58] <jam> perrito666: submitted
[11:59] <perrito666> jam: tx
[11:59] <anastasiamac_> perrito666: backports only need stamps if there is significant difference... if it's exactly the same as the originally reviewed code, feel free to self-stamp :) why re-invent the wheeel and re-stamp?
[12:01] <jam> perrito666 is probably worried that he'll accidentally get a tramp-stamp
[12:01] <perrito666> I am sure there is ajoke there
[12:01] <jam> but perrito666, I agree with anastasiamac_ that backports/forward ports can be self-stamped if there isn't any significant changes. With the caveat that 2.1 is in prep-for-RC mode so we should be careful what we want to put in it
[12:01] <perrito666> but it requires for me to google
[15:22] <jam> perrito666: any chance you could look at https://github.com/juju/juju/pull/6933
[15:24] <perrito666> jam: certainly, any chance you can jump into the outage channel on the other irc? :) need a second opinion
[15:25] <jam> outage?
[15:49] <cory_fu> Was credentials support added for lxd in the latest beta?  It has started prompting me for a credential when working with a shared lxd controller where it did not previously, and I have no credential to supply it with.
[15:54] <perrito666> jam: ship it
[16:04] <jam> cory_fu: axw was the one making some of those changes. I'm not sure how it interacts with existing LXD deployments. I think there is an upgrade step to fix that sort of thing, but that would be a 2.0=>2.1x upgrade
[16:04] <jam> vs a 2.1b4 => 2.1b5
[16:09] <cory_fu> jam: I don't understand.  This is a freshly bootstrapped 2.1b5 localhost controller.  I used add-user + grant, then registered the controller with another juju and tried to add model from there and it said "no controller specified."  This worked in the last beta.  I could add a credential for the controller like I have to do for aws, etc, but I don't have a credential to add
[16:29] <cory_fu> jam, axw: So, I tried upgrading a juju 2.0.2 to the latest beta and then registering the controller, and I got a new error about an invalid credential: http://pastebin.ubuntu.com/23948469/
[16:34] <jam> cory_fu: sounds like a bug we need to address in 2.1b5, can you submit one and we'll poke axw to look into it
[16:34] <cory_fu> Sure
[16:34] <jam> cory_fu: I know we were doing bad things with credentials and LXD before, it looks like fixing credentials may have broken multi-user
[16:35] <cory_fu> jam: I'm currently testing whether how I bootstrapped it has an effect.  I don't recall if I bootstrapped it as lxd or localhost.  Testing with localhost to be sure
[16:54] <cory_fu> jam, axw: Filed https://bugs.launchpad.net/juju/+bug/1662587  Thanks
[16:54] <mup> Bug #1662587: 2.1beta5 breaks lxd shared controller <juju:New> <https://launchpad.net/bugs/1662587>
[17:22] <redir> morning juju-dev (almost forgot!)
[17:23] <alexisb> morning redir
[17:24] <perrito666> redir: morning
[17:24] <redir> :)
[17:26] <mup> Bug #1662599 opened: Change maas api and password controller in model already created <juju-core:New> <https://launchpad.net/bugs/1662599>
[18:06] <perrito666> hey Ill step out for a moment and return later, cheers
[19:26] <redir> intermittent internet today
[19:26] <redir> lots of rains
[19:26] <redir> and winds
[19:46] <redir> easy PR: https://github.com/juju/juju/pull/6935
[20:09] <perrito666> redir: ship it
[20:19] <redir> tx
[20:19] <redir> perrito666:
[20:19] <redir> wallyworld: yt?
[20:48] <redir> me steps away shortly to run a couple errands.
[21:50] <kwmonroe> cory_fu!  i'm so l33t.  i shared a lxd controller and added a localhost stanza to the credentials.yaml on the remote user (jenkins in your case). it needs the contents of server.crt, client.crt, and client.key from the remote lxd host.  then a set-default-credential for jenkins, and bingo bango, add-model for days.
[21:50] <kwmonroe> i'll expand on the workaround in https://bugs.launchpad.net/juju/+bug/1662587, but wanted to let you know in case you were stuck.
[21:50] <mup> Bug #1662587: 2.1beta5 breaks lxd shared controller <juju:New> <https://launchpad.net/bugs/1662587>
[21:51] <cory_fu> kwmonroe: Awesome!
[21:55] <cory_fu> kwmonroe: Is that with beta5 on both the sharer and sharee?
[21:55] <kwmonroe> you made up some of those words cory_fu
[21:55] <kwmonroe> yes, b5 all around
[21:55] <cory_fu> :)  Ok
[21:56] <balloons> perrito666, you on-call reviewer?
[21:57] <balloons> cory_fu, ouch that bug
[22:00] <perrito666> balloons: no, but I am keen to review things if you need
[22:00] <balloons> perrito666, ohh, well then; https://github.com/juju/juju/pull/6936
[22:01] <babbageclunk> ugh, who decided that using dashes as the separator between items that have dashes in them was a good idea?
[22:01] <balloons> not sure how much you've played around with snaps, so this is your chance to vet
[22:02] <perrito666> balloons: build-packages: [gcc] ?
[22:03] <perrito666> balloons: I have snapped things, go things to be accurate :)
[22:03] <balloons> perrito666, that was requested by snapcraft upstream for there builder. It's no-change from the previou
[22:04] <perrito666> k then, lgtm, let me stamp it
[22:04] <balloons> perrito666, mind trying out a build; I'm keen to make sure it's easy for developers to snap up there local repo
[22:04] <kwmonroe> cory_fu: bug 1662587 updated if you need the steps..
[22:04] <mup> Bug #1662587: 2.1beta5 breaks lxd shared controller <juju:New> <https://launchpad.net/bugs/1662587>
[22:05] <balloons> not sure how much you've tried to to that. snap, and then push to the store
[22:05] <perrito666> balloons: let me see if this computer has the snapcraft things
[22:05] <balloons> perrito666, ahh, no worries if not
[22:06] <perrito666> balloons: building
[22:07] <cory_fu> kwmonroe: Thanks.  Does set-default-credential actually work with beta5 on an imported controller?
[22:07] <kwmonroe> $ juju set-default-credential localhost hamburgalar
[22:07] <kwmonroe> Default credential for localhost set to "hamburgalar".
[22:08] <kwmonroe> yeah, looks to work for me.. subsequent "juju add-model blah" don't need a --credential flag
[22:09] <kwmonroe> $ juju add-model see-cory-fu
[22:09] <kwmonroe> Uploading credential 'localhost/cwr-ci/hamburgalar' to controller
[22:09] <kwmonroe> Added 'see-cory-fu' model on localhost/localhost with credential 'hamburgalar' for user 'cwr-ci'
[22:10] <kwmonroe> and now i need to google how to spell hamburgalar.. i think it probably hamburgler
[22:10] <kwmonroe> i'm sure that's not a special case in the juju code though, so you should be fine.
[22:11] <cory_fu> kwmonroe: Ok, so they fixed that, so that's nice.  Not sure how we'll handle the transition, though
[22:12] <cory_fu> kwmonroe: Interesting.  Doing `juju add-credential localhost` in 2.0.2 creates a cred with "auth-type: empty" and no other props, like we tried to create before
[22:23] <kwmonroe> it's hamburglar
[22:27] <perrito666> balloons: interesting, I have time to take a shower while snap builds juju
[22:27] <perrito666> actually I could take two since it has not finished yet and I am already back
[22:34] <balloons> perrito666, :p
[22:37] <cory_fu> kwmonroe: Good to know
[22:37] <kwmonroe> :)
[23:13] <balloons> wallyworld, perrito666, anastasiamac_, abentley, sinzui, https://github.com/juju/juju/pull/6936 is the PR. I have pushed 2.1-beta5 to the beta channel, and 2.0.2 to the stable channel. Check them out. snap install juju --classic and snap install juju --classic --beta
[23:13] <balloons> they should all "just work" as you expect
[23:14] <sinzui> thank you balloons
[23:14] <wallyworld> awesome
[23:15] <balloons> wallyworld, you'll note btw it uses your local tree by default, but there's a few options to specify tags, commits or branches as well as location. Should make dev builds easy
[23:15] <wallyworld> ok, i'll check it out