=== zz_CyberJacob is now known as CyberJacob
=== CyberJacob is now known as Guest35316
=== frankban|afk is now known as frankban
=== redir is now known as redir_sprint
[09:05] <magicaltrout> [boom dynamically scaling DC/OS masters
[09:05] <magicaltrout> nearly there
=== Guest35316 is now known as CyberJacob
[09:26] <kjackal> magicaltrout: Nice!
[09:26] <magicaltrout> yeah only took 3 evenings to figure it out :P
[09:26] <magicaltrout> what a geek
[09:27] <magicaltrout> just converting the main tarball to a charm resource now
[09:27] <kjackal> Cool!
[09:27] <magicaltrout> although the docs suck...
[09:27] <kjackal> Let us know when/what to review!
[09:27] <magicaltrout> do I do
[09:28] <magicaltrout> hookenv.resource_get ?
[09:28] <kjackal> Oh you know what documentation is like...
[09:28] <magicaltrout> which should give me a path according to the docs?
[09:31] <magicaltrout> oh I found an example by mbruzek
[09:31] <magicaltrout> should do the job
[09:49] <marcoceppi> magicaltrout: there's also an example here: https://github.com/marcoceppi/layer-charmsvg
[10:00] <kjackal> Hello marcoceppi!
[10:01] <marcoceppi> o/
[10:01] <kjackal> Do you have ay news for me marcoceppi?
[10:01] <marcoceppi> no
[10:03] <kjackal> :) cool, let me know if there is anything I can do from my side
[10:42] <kjackal> Thank you marcoceppi!
[10:49] <stub> cory_fu, bcsaller_ : Whats happening with https://github.com/juju-solutions/charms.reactive/pull/66 ? I have some actions to write for an internal charm and need to know if I should be waiting, forking or going in a different direction.
[11:24] <kjackal> Good morning kwmonroe. I am looking on the issue you reported on reading/writing topics. How do you reproduce it?
[11:25] <rambit0> hello
[11:25] <rambit0> 1
[11:27] <rambit0> I get the message missing relation messaging
[11:48] <rambit0> on neutron-gateway
[11:48] <rambit0> do you know where I should search
[11:59] <rambit0> :D:D:D:D:D:D:D:D:D:D:D:D:D:D:D:D:D:D:D:D:D:D:D:D
[12:16] <lazyPower> stub ooo an @action decorator
[12:17] <lazyPower> magicaltrout - are you still having issues with resources (per mailing list post)?
[12:17] <lazyPower> magicaltrout - i may be doing this incorrectly, but what's worked for me w/ etcd, is to push the charm code, then `charm attach` the resources, *then* publish like so:  charm publish ~lazypower/etcd --resource etcd-0 --resource etcdctl-0 (these are the resource identifiers returned from charm attach).
[12:17] <lazyPower> also pardon my omission of revision on the charm entity... it should read ~lazypower/etcd-2  for example.
[12:25] <magicaltrout> thanks lazyPower , the error on the list looks non fatal
[12:25] <magicaltrout> just ugly
[12:25] <lazyPower> right, i think the messaging could be better
[12:25] <lazyPower> but i didnt want you blocked since there is a known good workflow there
[12:26] <magicaltrout> well I've just got out of a meeting to find a node saying dc/os installed
[12:26] <magicaltrout> so I assume its not lying
[12:26] <magicaltrout> just gonna check
[12:28] <magicaltrout> lets spin up 2 more and have a party
[12:30] <magicaltrout> or a quorum at least
[12:34] <lazyPower> woo
[12:34] <lazyPower> quorum party
[12:37] <magicaltrout> boo i lied
[12:37] <magicaltrout> I hadn't republished
[12:38]  * magicaltrout tries lazyPower's method
[12:44] <magicaltrout> okay
[12:44] <magicaltrout> not a clue if its broken or not
[12:44] <magicaltrout> this is a bit shit
[12:44] <magicaltrout> charm attach cs:~spicule/wily/dcos-master-1 software=/home/bugg/Projects/dcos-master/bootstrap.tar.gz
[12:44] <magicaltrout> lazyPower: does that look right?
[12:44] <lazyPower> yep, if thats the name of the resource
[12:45] <lazyPower> it should yield a resource id like  software-0  when its successfully completed
[12:45] <magicaltrout> I get the same squid error
[12:45] <lazyPower> rick_h_ urulama any idea why we're getting squid errors on attaching resources? I've run into this before when i dont specify a charm revision... but this is clearly not the case per magicaltrout's paste above.
[12:46] <lazyPower> the squid responses both vex and frustrate me magicaltrout, i feel your pain here.
[12:47] <magicaltrout> aye bit of a pain when I'm just trying to clear DC/OS stuff off my desk and get it into the store for people to hack on ;)
[12:47] <magicaltrout> doesn't help when I can't understand what its trying to tell me :)
[12:50] <urulama> lazyPower: jrwren was looking into that. the default settings disconnect long uploads
[12:50] <lazyPower> ah right there was a post to the list about this last week
[12:50] <lazyPower> magicaltrout - whats the size of your payload?
[12:56] <magicaltrout> 478M lazyPower
[12:56] <magicaltrout> from a data centre not over my pipes
=== urulama is now known as urulama-sprint
[12:59] <stub> lazyPower, urulama, magicaltrout : it also looks very similar to the bug report on the mailing list about large resources failing.
[12:59] <urulama-sprint> stub: yes, that's the same thing
[12:59] <magicaltrout> merlijn's?
[13:00] <stub> yes
[13:00] <magicaltrout> k
[13:00] <magicaltrout> I'll revert to wget from dropbox then :)
=== lazyPower changed the topic of #juju to: Welcome to Juju! || Docs: http://jujucharms.com/docs || FAQ: http://goo.gl/MsNu4I || Review Queue: http://review.juju.solutions || Unanswered Questions: http://goo.gl/dNj8CP || Youtube: https://www.youtube.com/c/jujucharms || Juju 2.0 beta-10 release notes: https://jujucharms.com/docs/devel/temp-release-notes
[13:44] <cory_fu> stub: I commented on https://github.com/juju-solutions/charms.reactive/pull/66 with a recap of the recent discussion I had with bcsaller_ about that.  When he comes on, I'd like him to verify that I didn't forget anything.  Let me know if that wall of text is unclear.  :p
[13:44] <cory_fu> I'd also like anyone else's input, because how actions are handled will affect everyone.
[13:44] <cory_fu> I know marcoceppi has thought about this as well
[13:45] <cory_fu> stub: Also, apologies for it taking so long to move on those PRs.  We've just been pulled in other directions.
[13:46] <magicaltrout> I like the idea of an action annotation
[13:46] <cory_fu> marcoceppi: I know the new RQ is very charm focused, but PRs like that one would really benefit from me being able to kick it up to community as a whole to make it clear that, "hey, I could use help with this"
[13:52] <marcoceppi> cory_fu: it's super charm focused atm, but we could expand that
[13:52] <marcoceppi> cory_fu: or, just mail the list
[14:22] <kwmonroe> kjackal - re: kafka write topic failure.. i believe it's only repro-able when the broker doesn't know its own hostname.  in the older charm, we had to set advertised.host.name so kafka knew when to listen.
[14:24] <marcoceppi> mm, 99% test coverage, it's been a while
[14:24] <kjackal> kwmonroe: ok, so I got the kafka charm deployed on EC2 and actions were working fine
[14:25] <kjackal> kwmonroe: also we were not opening the ports of kafka so that might have been an issue
[14:43] <stub> cory_fu: Ta, and rebutted ;)
[14:50] <stub> I wonder if the reactive phases to be run should be declared by the bootstrap script that kicks off reactive.main() ? main(['setup', 'hooks', 'main']). Could extend the framework in all sorts of ways then without messing with the core.
[15:04] <marcoceppi> cory_fu: is config.changed.<option> invoked on first hook run?
[15:04] <cory_fu> marcoceppi: Yes
[15:04] <marcoceppi> \o/
[15:17] <marcoceppi> cory_fu: does config.changed reactive states mess with config().previous ?
[15:31] <cory_fu> marcoceppi: The config.changed states are set based on hookenv.config().previous(), but they do not change the result of that
[15:33] <marcoceppi> cory_fu: one last question
[15:34] <marcoceppi> I'm rewriting an @hook(config-changed) state, one of the config option is version of software
[15:34] <marcoceppi> the rest are literally for the application
[15:34] <marcoceppi> so I basically want to do when any configuration changes, so long as it's not just version, but could also be version
[15:36] <marcoceppi> I'm trying to avoid needless spaming of writing out configuration files
[15:38] <cory_fu> Hrm.  If only the version changes, are you not going to need to re-write the config anyway as part of the update / reinstall?
[15:39] <marcoceppi> cory_fu: a seperate logic handles that
[15:40] <marcoceppi> cory_fu: and I want to avoid a race where config.changed is processed before everything else
[15:40] <cory_fu> What do you mean, before everything else?
[15:41] <marcoceppi> cory_fu: well, I have two handlers now, config.changed.version and config.changed
[15:41] <marcoceppi> if config.changed gets processed before config.changed.version then it's wasteful
[15:41] <stub> Probably simpler to use an if statement and the data_changed() helper
[15:42] <cory_fu> Ah, yeah.  I would say stub is right about the if statement, but I don't think you actually need data_changed
[15:42] <marcoceppi> I just want to know if more than version was changed, is there a way to list all changed keys?
[15:44] <cory_fu> marcoceppi: Not sure why you would want to do that?
[15:44] <stub> [state.split('.',3][-1]  for state in bus.get_states() if state.startswith('config.changed.')]
[15:44] <cory_fu> marcoceppi: Let me write up how I would structure this.  One second
[15:45] <marcoceppi> stub: that is certainly one way
[15:45] <marcoceppi> cory_fu: I'll put what I'm doing in a branch if you want to optimize the rest of my crap
[15:46] <cory_fu> marcoceppi: http://pastebin.ubuntu.com/17975757/
[15:46] <marcoceppi> cory_fu: I want to avoid rewriting config is version is the /only/ state changed though
[15:46] <marcoceppi> since it'll be written after intsall
[15:47] <stub> marcoceppi: Only way I could find - I needed similar for the apt layer.
[15:50] <cory_fu> Actually, that pastebin isn't ideal.
[15:51] <cory_fu> marcoceppi: What about this?  http://pastebin.ubuntu.com/17975982/
[15:51] <arosales> lazyPower: do you know where the code location for mariadb is at:
[15:51] <arosales> https://jujucharms.com/mariadb/
[15:51] <marcoceppi> cory_fu: I was about to do that
[15:51] <marcoceppi> cory_fu: but I argued why I shouldn't
[15:51] <cory_fu> If the version changes, even if other config values have changed, you don't need to worry about rewriting the config
[15:51] <marcoceppi> but it doesn't matter
[15:51] <marcoceppi> cory_fu: yeah
[15:51] <cory_fu> I don't see the problem
[15:52] <cory_fu> Only one of those two will ever run
[15:52] <marcoceppi> cory_fu: yeah
[15:52] <marcoceppi> cory_fu: http://paste.ubuntu.com/17976046/
[15:52] <arosales> lazyPower: looks like you may have touched the charm last.  I would specifically like to know where the upstream code lives. I didn't find a branch at LP where the bug link is, and the project link just goes to mariadb.org
[15:52] <cory_fu> It basically says what you asked for.  Run the first when the version changed.  Run the second when any config has changed except the version
[15:53] <marcoceppi> cory_fu: earlier I hadn't refactored the mongodb.ready, but since I did I never really reconsidered this as a solution
[15:53] <cory_fu> Ah
[15:54] <marcoceppi> cory_fu thanks stub I will def be using that snippet for latter
[15:55] <cory_fu> stub: Your point about charms needing to react to changes made by actions is a good one.  So my only outstanding item on that PR is the CLI support.  Perhaps I can add it as part of the merge, though
[15:55] <cory_fu> Unless you want to take a stab
[15:56] <stub> cory_fu: I don't know where to begin on that bit
[15:56] <cory_fu> Ok, no worries
[15:57] <cory_fu> stub: I do think, though, that the goal for reactive actions should be to have charm-build populate actions from the templates by default.  I think marcoceppi is on board with me on that, yes?
[15:57] <stub> cory_fu: If charm build discovers and creates hooks for defined actions, an you think of a way for the user to specify that an action is 'traditional' or 'reactive' ?
[15:57] <cory_fu> stub: If they create the action file manually, charm-build will not replace it with the reactive template
[15:57] <stub> (although from what I can tell, charm build doesn't discover anything and only automatically creates hooks for interfaces)
[15:58] <stub> ok. I guess that is a perfectly reasonable UI.
[15:58] <cory_fu> Right.  charm-build is missing that functionality, but I want to add it
[15:58] <stub> ok. I had assumed we would be stuck declaring them in layer.yaml.
[15:58] <marcoceppi> cory_fu: +1 stub my thought was, interogate the actions.yaml file, if there's not actions/<action> file, create from boilerplate
[15:59] <stub> marcoceppi: oh, yeah. discovery of actions is easy that way.
=== frankban is now known as frankban|afk
[16:21] <lazyPower> arosales - i do, its still focused on the ~charmers branch in launchpad. http://launchpad.net/~charmers/charms/trusty/mariadb/trunk
[16:22] <lazyPower> arosales - looks like i need to bump the metadata on the charm, this was one of the high priority items that squeeked through a couple weeks back...
[16:25] <arosales> lazyPower: ok htanks
[16:25] <arosales> lazyPower: if you are touching that charm may be good to put http://launchpad.net/~charmers/charms/trusty/mariadb/trunk as the contribute repo unless dbart would like to move that else where
[16:25] <arosales> petevg: ^ note mariadb upstream link repo
[16:26] <lazyPower> right, i wound up creating the group mariadb-charmers for pushing the charm as there wasn't one provided by dbart
[16:26] <marcoceppi> arosales: if we're touching a charm, it's not going to live in ~charmers anymore
[16:26] <petevg> arosales: useful. thx.
[16:26] <marcoceppi> lazyPower: +1
[16:26] <lazyPower> https://launchpad.net/~mariadb-charmers   for reference
[16:28] <lazyPower> arosales petevg - is someone actively working on mariadb at hte moment for a review/etc?
[16:29] <petevg> lazyPower: arosales asked me to add a check for z Linux to make it install the package from universe, rather than from the mariadb repo.
[16:29] <petevg> That's all I'm doing to it at the moment, though -- adding a check for z Linux.
[16:29] <lazyPower> petevg - ok, so lets move that rpeository from ~charmers, and target a repository in ~mariadb-charmers then.
[16:30] <lazyPower> i'll send an email to dbart, cc you as well
[16:30] <lazyPower> make it nice and official
[16:32] <petevg> Sounds good.
[16:40] <marcoceppi> writing unit tests for reactive files is brutal
[16:41] <lazyPower> marcoceppi - its reminiscent of the stacks of @patch decorators in old amulet tests
[16:41] <lazyPower> i dont like it
[16:41] <marcoceppi> is there way I can like, globally mock status_set, set_state, etc?
[16:42] <marcoceppi> like in setUp?
[16:42] <lazyPower> only using with() statements, problem is, if you have a large method body calling those methods, you've re-implemented the stack of patches in a less obvious way
[16:42] <petevg> marcoceppi: You can manually create a mock patch, and then call stop and start on it whenever you want, instead of using the decorator.
[16:43] <arosales> lazyPower: could you cc me on the email to dbart I would like to discuss the s390x and ppc64el install paths
[16:43] <lazyPower> arosales will do
[16:43] <marcoceppi> petevg: you got an example?
[16:43] <arosales> lazyPower: thanks
[16:43] <marcoceppi> I just always want to mock these
[16:43]  * arosales waves at marcoceppi
[16:43] <petevg> It's been awhile since I've been foolish enough to try. Give me a moment to look it up :-)
[16:43] <arosales> marcoceppi: feel comfortable with  me giving your mongodb layers a run on s390?
[16:44] <marcoceppi> arosales: give me a min
[16:44] <kwmonroe> cory_fu: are you worried that 00-deploy (for https://github.com/apache/bigtop/pull/120/files#diff-30135d8baafe145bd84fb0ec91657c93R1) is going to run twice in bundletester?  do we need a restrictive glob for tests in tests.yaml?
[16:44] <marcoceppi> arosales: I'm just finishing unit tests and I've made a lot of changes in the past few hours
[16:44] <arosales> marcoceppi: no rush I can also check in tomorrow
[16:44] <marcoceppi> arosales: yas
[16:44] <arosales> marcoceppi: thanks for working on it
[16:44] <petevg> marcoceppi. From the docs here: http://www.voidspace.org.uk/python/mock/patch.html, you get:
[16:44] <petevg> https://www.irccloud.com/pastebin/KTRbAA80/
[16:45] <marcoceppi> petevg: could you do it with a real pastebin?
[16:45] <petevg> Yes.
[16:45] <marcoceppi> apparently IRC cloud won' tlet you view it unless you're in irccloud, what a worthless sack
[16:45] <petevg> That's annoying.
[16:45] <petevg> here's a gist: https://gist.github.com/petevg/2b22752b29f1a5f809560f448f6e7f63
[16:46] <cory_fu> kwmonroe: It may run twice (I guess Tim's out, but he'd be able to answer that more definitively) but the second one would be close to a noop.  It would add only around 30s, maybe a minute, to the total run time
[16:46] <cory_fu> A test pattern would not be bad, though, if you want to figure out what that should be
[16:46] <kwmonroe> yeah cory_fu, but i think that's only because we luckily have reset: false in our tests.yaml.  i pity the soul that uses us as a reference and double's their test time.
[16:47] <kwmonroe> not a biggie cory_fu.. i'll scan our bits and see if it could be as simple as *.py.
[16:47] <cory_fu> Well, the only reason we can use the bundle_deploy option at all is because we also use reset: false.  It wouldn't do anything useful w/o it
[16:47] <petevg> marcoceppi: You can use that in conjunction with unittest's setUpClass and tearDownClass methods and have code that isn't too messy, or too prone to failure. You wind up with a lot of lines like "self.foo_patcher = ...", "self.bar_patcher=...", though.
[16:48] <marcoceppi> there has to be a better way
[16:48] <Odd_Bloke> marcoceppi: If you do it in a TestCase super-class and inherit from that, then you only have to write it once.
[16:49] <petevg> Odd_Bloke says smart things.
[16:51] <marcoceppi> Odd_Bloke: yeah, I'm trying to read up on testcase superclassing
[16:51] <Odd_Bloke> marcoceppi: Like this: https://gist.github.com/OddBloke/d9a3e87bd397878a77f21bb080e05275
[16:51] <marcoceppi> Odd_Bloke: you da real mvp
[16:52] <Odd_Bloke> marcoceppi: Note what you'll need to do for test cases that do already have a setUp: https://gist.github.com/OddBloke/d9a3e87bd397878a77f21bb080e05275
[16:52] <Odd_Bloke> marcoceppi: (And a tearDown, for that matter)
[16:53] <marcoceppi> Odd_Bloke: up!
[16:53] <marcoceppi> thanks
[16:54] <Odd_Bloke> marcoceppi: (And if you're patching loads of things consider shoving them in a list and having your tearDown just do: `for patcher in self.list_of_patchers: patcher.stop()`)
[16:55] <marcoceppi> Odd_Bloke: is setup called for ever test method, or once per testcase class?
[16:55] <Odd_Bloke> marcoceppi: Per method; setUpClass is per class.
[16:55] <Odd_Bloke> (You probably want it per-method, else you'll end up with previous tests mocks which will already have some state)
[16:56] <marcoceppi> Odd_Bloke: I do, just wanted to make sure I didn't need to run reset_mock
[16:58] <Odd_Bloke> :)
[17:00] <marcoceppi> Odd_Bloke petevg thanks!
[17:01] <Odd_Bloke> marcoceppi: Any time. :)
[17:02] <Odd_Bloke> Pretty much my entire professional career has consisted of arriving at a place, throwing up my hands at the testing, and then writing tests until I give up. ;)
[17:03] <lazyPower> Odd_Bloke <3
[17:07] <arosales> stub: nice work it looks like https://jujucharms.com/postgresql/ may "juju work" on s390x
[17:07] <stub> cool
[17:07]  * arosales has a "Live master (9.5.3) " workload status on a s390x machine atm
=== mwhudson_ is now known as mwhudson
[21:38] <bdx> is there a way to set arbitrary enpoint bindings for charms when deployed in bundles?