| === 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 | ||
| magicaltrout | [boom dynamically scaling DC/OS masters | 09:05 |
|---|---|---|
| magicaltrout | nearly there | 09:05 |
| === Guest35316 is now known as CyberJacob | ||
| kjackal | magicaltrout: Nice! | 09:26 |
| magicaltrout | yeah only took 3 evenings to figure it out :P | 09:26 |
| magicaltrout | what a geek | 09:26 |
| 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:27 |
| 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:28 |
| magicaltrout | oh I found an example by mbruzek | 09:31 |
| magicaltrout | should do the job | 09:31 |
| marcoceppi | magicaltrout: there's also an example here: https://github.com/marcoceppi/layer-charmsvg | 09:49 |
| kjackal | Hello marcoceppi! | 10:00 |
| marcoceppi | o/ | 10:01 |
| kjackal | Do you have ay news for me marcoceppi? | 10:01 |
| marcoceppi | no | 10:01 |
| kjackal | :) cool, let me know if there is anything I can do from my side | 10:03 |
| kjackal | Thank you marcoceppi! | 10:42 |
| 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. | 10:49 |
| kjackal | Good morning kwmonroe. I am looking on the issue you reported on reading/writing topics. How do you reproduce it? | 11:24 |
| rambit0 | hello | 11:25 |
| rambit0 | 1 | 11:25 |
| rambit0 | I get the message missing relation messaging | 11:27 |
| rambit0 | on neutron-gateway | 11:48 |
| rambit0 | do you know where I should search | 11:48 |
| 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 | 11:59 |
| lazyPower | stub ooo an @action decorator | 12:16 |
| 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:17 |
| 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:25 |
| 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:26 |
| magicaltrout | lets spin up 2 more and have a party | 12:28 |
| magicaltrout | or a quorum at least | 12:30 |
| lazyPower | woo | 12:34 |
| lazyPower | quorum party | 12:34 |
| magicaltrout | boo i lied | 12:37 |
| magicaltrout | I hadn't republished | 12:37 |
| * magicaltrout tries lazyPower's method | 12:38 | |
| 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:44 |
| 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:45 |
| lazyPower | the squid responses both vex and frustrate me magicaltrout, i feel your pain here. | 12:46 |
| 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:47 |
| 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:50 |
| magicaltrout | 478M lazyPower | 12:56 |
| magicaltrout | from a data centre not over my pipes | 12:56 |
| === urulama is now known as urulama-sprint | ||
| 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? | 12:59 |
| stub | yes | 13:00 |
| magicaltrout | k | 13:00 |
| magicaltrout | I'll revert to wget from dropbox then :) | 13:00 |
| === 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 | ||
| 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:44 |
| cory_fu | stub: Also, apologies for it taking so long to move on those PRs. We've just been pulled in other directions. | 13:45 |
| 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:46 |
| marcoceppi | cory_fu: it's super charm focused atm, but we could expand that | 13:52 |
| marcoceppi | cory_fu: or, just mail the list | 13:52 |
| 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:22 |
| 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:24 |
| kjackal | kwmonroe: also we were not opening the ports of kafka so that might have been an issue | 14:25 |
| stub | cory_fu: Ta, and rebutted ;) | 14:43 |
| 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. | 14:50 |
| marcoceppi | cory_fu: is config.changed.<option> invoked on first hook run? | 15:04 |
| cory_fu | marcoceppi: Yes | 15:04 |
| marcoceppi | \o/ | 15:04 |
| marcoceppi | cory_fu: does config.changed reactive states mess with config().previous ? | 15:17 |
| cory_fu | marcoceppi: The config.changed states are set based on hookenv.config().previous(), but they do not change the result of that | 15:31 |
| marcoceppi | cory_fu: one last question | 15:33 |
| 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:34 |
| marcoceppi | I'm trying to avoid needless spaming of writing out configuration files | 15:36 |
| 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:38 |
| marcoceppi | cory_fu: a seperate logic handles that | 15:39 |
| 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:40 |
| 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:41 |
| 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:42 |
| 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:44 |
| 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:45 |
| 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:46 |
| stub | marcoceppi: Only way I could find - I needed similar for the apt layer. | 15:47 |
| cory_fu | Actually, that pastebin isn't ideal. | 15:50 |
| 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:51 |
| 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:52 |
| 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:53 |
| marcoceppi | cory_fu thanks stub I will def be using that snippet for latter | 15:54 |
| 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:55 |
| stub | cory_fu: I don't know where to begin on that bit | 15:56 |
| cory_fu | Ok, no worries | 15:56 |
| 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:57 |
| 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:58 |
| stub | marcoceppi: oh, yeah. discovery of actions is easy that way. | 15:59 |
| === frankban is now known as frankban|afk | ||
| lazyPower | arosales - i do, its still focused on the ~charmers branch in launchpad. http://launchpad.net/~charmers/charms/trusty/mariadb/trunk | 16:21 |
| 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:22 |
| 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:25 |
| 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:26 |
| lazyPower | arosales petevg - is someone actively working on mariadb at hte moment for a review/etc? | 16:28 |
| 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:29 |
| lazyPower | i'll send an email to dbart, cc you as well | 16:30 |
| lazyPower | make it nice and official | 16:30 |
| petevg | Sounds good. | 16:32 |
| marcoceppi | writing unit tests for reactive files is brutal | 16:40 |
| 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:41 |
| 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:42 |
| 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:43 |
| 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:44 |
| 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:45 |
| 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:46 |
| 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:47 |
| 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:48 |
| petevg | Odd_Bloke says smart things. | 16:49 |
| 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:51 |
| 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:52 |
| marcoceppi | Odd_Bloke: up! | 16:53 |
| marcoceppi | thanks | 16:53 |
| 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:54 |
| 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:55 |
| marcoceppi | Odd_Bloke: I do, just wanted to make sure I didn't need to run reset_mock | 16:56 |
| Odd_Bloke | :) | 16:58 |
| marcoceppi | Odd_Bloke petevg thanks! | 17:00 |
| Odd_Bloke | marcoceppi: Any time. :) | 17:01 |
| 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:02 |
| lazyPower | Odd_Bloke <3 | 17:03 |
| 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 | 17:07 | |
| === mwhudson_ is now known as mwhudson | ||
| bdx | is there a way to set arbitrary enpoint bindings for charms when deployed in bundles? | 21:38 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!