| === mhall119_ is now known as mhall119 | ||
| === mup_ is now known as mup | ||
| blahdeblah | Any charmers around to look at http://juju-ci.vapour.ws:8080/job/charm-bundle-test-lxc/1392/console ? | 10:51 |
|---|---|---|
| apuimedo | gnuoy: Hi | 11:48 |
| apuimedo | do you know who to contact to remove a charm from the store? I thought removing the branch would suffice | 11:49 |
| apuimedo | but it's been a week and the charm remains in the store | 11:49 |
| gnuoy | hi apuimedo, I'm not sure how that happens. jcastro might be able to point us in the right direction when he comes online | 11:51 |
| apuimedo | thanks | 11:51 |
| MrBy | hi, i successfully deployed landscape and now i have a minimal openstack installation. how can i extend it with juju to deploy ceilometer, heat, ...? | 11:57 |
| coreycb | cory_fu, I'm looking through the vanilla demo for layers: https://jujucharms.com/docs/1.24/authors-charm-building | 15:46 |
| coreycb | cory_fu, who calls provide_database()? I'd think it would be called in mysql/postgresql charm but I'm not seeing anything there. | 15:47 |
| jrwren | anyone familiar with mongodb charm ansible tests able to help me with its test failures? | 16:05 |
| jrwren | https://code.launchpad.net/~evarlast/charms/trusty/mongodb/fix-dump-actions/+merge/277191 i tried to fix the failing tests due to the recent juju change in unit numbering, but it is still failing, I do not see why. | 16:06 |
| cory_fu | coreycb: In a meeting, sorry. Give me a bit | 16:07 |
| coreycb | cory_fu, me too, no rush | 16:07 |
| lazypower | jrwren - 1 sec let me take a look | 16:08 |
| lazypower | jrwren looking @ the console output of the failing test, it looks unrelated to your change. its due to the unit numbering behavior change | 16:14 |
| lazypower | jrwren and there's still some older syntax in the tests - DEBUG:runner: mongo = self.deploy.sentry.unit['mongodb/0'].info['public-address'] | 16:14 |
| lazypower | thats emitting from the relate-ceilometer test | 16:14 |
| jrwren | lazypower: oh, I thought I updated all those old reference forms. I'll push a change updating those. Thanks. | 16:17 |
| tvansteenburgh | jrwren: http://reports.vapour.ws/charm-test-details/charm-bundle-test-parent-3607 | 16:18 |
| jrwren | *doh* now I see how I missed it. | 16:18 |
| jrwren | oh wow, fails proof too. should I address those? | 16:18 |
| tvansteenburgh | jrwren: yes plz | 16:19 |
| jrwren | poor neglected mongodb charm. | 16:19 |
| jrwren | in the charm proof output for that mongodb charm, it says benchmark has no hooks. There is nothing there for benchmark. Can I delete the interface from metadata.yaml? | 16:28 |
| lazypower | if its I: you can safely ignore it | 16:29 |
| lazypower | W:/E: are the blockers | 16:29 |
| jrwren | ah, ok. i won't touch that. | 16:30 |
| cory_fu | coreycb: If you're talking about, e.g., https://github.com/johnsca/juju-relation-mysql/blob/master/provides.py#L50, then yes, it would be called by the mysql charm, e.g. https://github.com/marcoceppi/mysql-charm-layer/blob/master/reactive/mysql.py#L246 | 16:35 |
| cory_fu | coreycb: Of course, if the relation is being provided by the existing, non-reactive mysql charm, then it won't use the interface layer at all. But it should still work as long as I got the interface protocol right (fair chance I mucked it up somehow) | 16:36 |
| coreycb | cory_fu, ok I think that's the issue, I was looking at lp:charms/trusty/mysql | 16:37 |
| cory_fu | Yeah, that doesn't use the interface layer at all, yet. | 16:37 |
| coreycb | cory_fu, but the net is you need reactive charms on each side of the interface, right? | 16:39 |
| lazypower | coreycb - not at all :) recall the etcd example i showed yesterday on our h/o? | 16:40 |
| coreycb | lazypower, sort of, can you point me to that again? | 16:40 |
| lazypower | https://github.com/chuckbutler/interface-etcd | 16:41 |
| lazypower | i apologize in advance for the state of this repository and it slack of a proper readme | 16:41 |
| coreycb | lazypower, not a problem, thanks! | 16:41 |
| coreycb | lazypower, would it also be legitimate to call relation_get/set in requires.py? | 16:44 |
| natefinch | marcoceppi, dpb1: There's an error in CI trying to deploy the landscape bundle on master. Looks like an error in config-changed. This line is throwing a KeyError for 'services': https://github.com/charms/haproxy/blob/master/hooks/hooks.py#L354 | 16:48 |
| natefinch | Seems like maybe the latest changes on master are firing config-changed before all the data the charm expects to be there actually exists... but I think the charm shouldn't depend on it being there, right? | 16:49 |
| dpb1 | natefinch: can you show me the bundles you are using? | 16:49 |
| natefinch | dpb1: it's something CI is deploying. mgz_ do you know where those bundles live? | 16:50 |
| dpb1 | (it's probably an older bundle deploying more recent code) | 16:50 |
| natefinch | dpb1: here the CI log, FWIW: http://reports.vapour.ws/releases/3307/job/aws-quickstart-bundle/attempt/1317#highlight | 16:51 |
| natefinch | dpb1: looks like it's called landscape_scalable.yaml.... but I don't know where it comes from | 16:54 |
| natefinch | (asking sinzui on juju-dev) | 16:55 |
| coreycb | lazypower, ok so I just looked through the RelationBase code a little and it looks like get/set_remote call relation_get/set. | 17:04 |
| coreycb | so I think that answers my question | 17:05 |
| cory_fu | coreycb: You should use get/set_remote instead of relation_get/set in interface layers because of how conversations are managed. | 17:08 |
| sharan | Hi | 17:08 |
| cory_fu | coreycb: Conversations group remote units together based on whether it makes sense for them to proceed through states as a logical group and to share data. To set_remote can send data to multiple remote units if the scope is SERVICE or GLOBAL | 17:09 |
| cory_fu | This really only applies to developing interface layers, though | 17:09 |
| cory_fu | When using interface layers, you shouldn't need to worry about conversations or using either set_remote nor relation_set, etc, because the interface layer should provide an API for interacting with the other side | 17:11 |
| coreycb | cory_fu, awesome thanks, it's making sense now. | 17:28 |
| lazypower | I just saw something interesting during a review. a hook decorator that doesn't implicitly define the hook context in which it should be run decorating 2 methods | 17:51 |
| lazypower | as in @hooks.hook() <cr> def install(): | 17:52 |
| lazypower | same declaration for a config_changed()... does this run on every hook context without the proper identifier? | 17:52 |
| sharan | Hi i am trying to implement peer relation in my charm. I have deployed my charm and using "juju action do" downloading package after completion of this download i'll set license flag true and charm works perfectly. when i do "juju add-unit" to get peer relation at this time license flag is made true for the first deployment , here before downloading the package charm is going into installation of the product but package is not present | 17:53 |
| lazypower | sharan - this seems like something the charm should do natively instead of relying on an action, or call the action from the hook code. | 17:58 |
| sharan | is it possible to call juju action from the hook code? | 17:59 |
| lazypower | you can. The CWD during hook execution is $CHARM_DIR | 18:00 |
| lazypower | so you can call action/thing-you-need-to-do | 18:00 |
| lazypower | but you wont have any action parameters available, so you will need to compensate for that | 18:00 |
| lazypower | by either allowing it to be parameterized on the CLI, import the method from the action (if written in python) | 18:00 |
| marcoceppi | lazypower: sharan the long of the short of it is no. Actions are only invoked by operators | 18:01 |
| marcoceppi | they are one time tasks and not a way to persist data in a service. If you need to persist data it should be modeled as configuration | 18:02 |
| marcoceppi | that way scale out will get the same copy of data instead of worrying about quorum and managing peer relation data | 18:02 |
| lazypower | and thats a fair point ^ | 18:07 |
| sharan | how do we configure the data? is it in config.yaml we need to configure? | 18:11 |
| lazypower | sharan - correct. if there's something you need to provide as configuration, it belongs in config.yaml and you can then take action when its present, if no value is present you can set status to blocked identifying the user they need to configure the charm before it can proceed. | 18:18 |
| === BradCrittenden is now known as Guest54329 | ||
| natefinch | rick_h_: you around? | 20:37 |
| natefinch | or marcoceppi or anyone else... trying to deploy a charm I just pushed to my personal namespace, and juju is saying charm not found | 20:38 |
| rick_h_ | natefinch: howdy | 20:38 |
| rick_h_ | natefinch: which charm? what command? | 20:39 |
| natefinch | $ bzr push lp:~natefinch/charms/vivid/ducksay/trunk | 20:39 |
| natefinch | Created new branch. | 20:39 |
| natefinch | $ juju deploy cs:~natefinch/vivid/ducksay | 20:39 |
| natefinch | ERROR cannot resolve URL "cs:~natefinch/vivid/ducksay": charm not found | 20:39 |
| rick_h_ | natefinch: not seeing it yet when did you push? https://jujucharms.com/u/natefinch/ | 20:40 |
| natefinch | rick_h_: like 3 minutes ago.... too fast? | 20:40 |
| rick_h_ | natefinch: yea, by about 2hrs | 20:40 |
| natefinch | rick_h_: ug | 20:40 |
| natefinch | rick_h_: why is there lag? | 20:41 |
| rick_h_ | natefinch: yea, the charm upload/etc stuff will be more like you're expecting | 20:41 |
| rick_h_ | natefinch: processing bzr uploads every 15min between legacy and new servers that have to stay in sync and take a while to process and sync up between them | 20:41 |
| natefinch | rick_h_: I guess I figured the charm could be retrieved on the fly when requested. But *shrug*. | 20:42 |
| natefinch | rick_h_: are we getting deploy from github any time soon? | 20:43 |
| rick_h_ | natefinch: not deploy from github but upload to the store by EOY | 20:43 |
| natefinch | rick_h_: as long as it means I don't have to type bzr, I'm happy. | 20:44 |
| rick_h_ | natefinch: +1 | 20:44 |
| rick_h_ | natefinch: talk to uros and see if you can get in early | 20:44 |
| rick_h_ | natefinch: but they're working on getting it asap | 20:44 |
| rick_h_ | natefinch: and have PoC working and should be beta'able this monthish and such | 20:44 |
| natefinch | rick_h_: it's ok, just makes it hard to test features that require specific charms in the store | 20:45 |
| rick_h_ | natefinch: well to test the charm do you need it in the store? | 20:45 |
| natefinch | rick_h_: I need to test that my code does the right thing when the charm is coming from the store vs. local | 20:45 |
| rick_h_ | natefinch: ah gotcha | 20:46 |
| rick_h_ | natefinch: you can ask uros for access to the current charm upload command | 20:46 |
| rick_h_ | it's not the official stuff, but it works today to upload straight to the store and bypass bzr | 20:46 |
| rick_h_ | natefinch: if it's just testing/etc it'd save you hours | 20:47 |
| rick_h_ | natefinch: showed you a doc | 20:47 |
| rick_h_ | natefinch: shared that is | 20:48 |
| natefinch | rick_h_: cool, thanks | 20:48 |
| natefinch | rick_h_: I'll talk to uros | 20:49 |
| blahdeblah | Hi. Any charmers still around to tell me why http://juju-ci.vapour.ws:8080/job/charm-bundle-test-lxc/1392/console is failing? | 23:40 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!