| blackboxsw | bogdanteleaga, it seems in juju2 that behavior has changed from juju1 for the websockets api call to "Action" "RunOnAllMachines". It looked like juju1 would return the synchronous results of the RunOnAllMachines call as the api response complete with Stdout and Stderror for the commands run. It appears that juju2 now returns immediately from a RunOnAllMachines call with a response that lists a bunch of actions still in "pending" s | 00:55 |
|---|---|---|
| blackboxsw | tate. So our responsibility is to sniff action deltas from the Allwatcher Next queue for action changed deltas. Does that sound about right? | 00:55 |
| blackboxsw | I mentioned some misunderstandings I was having with RunOnAllMachines to cherylj a bit earlier today and it sounded like you might have a bit of additional context on what changed in juju2 for the Run* api calls. | 00:57 |
| blackboxsw | ... just wanted to queue up the question for tomorrow. Will check in later | 00:58 |
| === blackboxsw is now known as blackboxsw_away | ||
| === redir_afk is now known as redir | ||
| xbox360pll | =D:)=);D =D ;D:P=) :D:D :P :):P :P=D :D;D:>=D;D=D;D=);D:) :D ;D :P =D=) :)=D=D =D;D =) :> ;D=D :>:P =D:) =):P=) :D=D :P :) :)=D ;D:D :P :> :D :) ;D =D :P=):D =) ;D=) | 04:31 |
| === urulama|__ is now known as urulama | ||
| === frankban|afk is now known as frankban | ||
| === _thumper_ is now known as thumper | ||
| dimitern | I'm trying to follow https://jujucharms.com/docs/devel/developer-layers-interfaces and looking at existing examples | 10:59 |
| dimitern | Is the version: significant? Do I need to define both interface.yaml and metadata.yaml (for the 'peers: ...' section), or just peers.py and interface.yaml? | 11:00 |
| stub | dimitern: Just peers.py and interface.yaml. 'version' is only documentation at the moment, but may one day be used for 'juju relation-add' or just flagging charms in need of maintenance. | 11:18 |
| dimitern | stub: OK, less stuff to care about keeping in sync :) thanks! | 11:19 |
| dimitern | stub: can I define config settings in the interface layer somewhere, so they are available in peers.py? | 11:21 |
| stub | dimitern: I don't think so, no. I'm told you are not supposed to put implementation in the interface layer, so you might be overreaching. I think interface layer is just supposed to catch events and set states so the charm or layer providing the real implementation can hook in, and an API for driving the protocol. I'm still somewhat fuzzy on this. | 11:25 |
| dimitern | stub: I see, that makes sense | 11:27 |
| dimitern | stub: I looked at existing examples and most of them just set/clear states. | 11:28 |
| === spammy is now known as Guest41987 | ||
| === Guest41987 is now known as spammy | ||
| === mthaddon` is now known as mthaddon | ||
| bbaqar | Hey guys. What could be going wrong if i see a unit in an error state in juju status but when I resolve it it gives the error that the unit is not in an error state. | 12:54 |
| bbaqar | all services on the node are configured and running properly | 12:55 |
| rick_h_ | bbaqar: is this from the Juju GUI? | 12:56 |
| bbaqar | no from the CLI | 12:57 |
| bbaqar | juju stat --format=tabular | 12:57 |
| jcastro | who's in the mood to unpromulgate mediawiki-scalable? | 13:45 |
| bluetack | Can anyone tell me if there is a way for an action to trigger a hook? I can't seem to find anything in the docs | 14:11 |
| stub | bluetack: Your action is running in a hook context, so you could just call ../hooks/whatever | 14:17 |
| stub | bluetack: But probably better to factor out the common functionality into a library, and have both the hook and action call it. | 14:18 |
| marcoceppi | jcastro: unpromulgated | 14:20 |
| bluetack | I tried a library (writing in python), but despite may __init__.py files all over the place, I couldn't import a sibling folder. How would I have a common library directory accessible to both actions and reactive dirs? | 14:20 |
| stub | bluetack: If this is for reactive charms, you might want https://github.com/juju-solutions/charms.reactive/pull/66 | 14:20 |
| stub | bluetack: Also, if you want imports to work sanely with reactive you want https://github.com/juju-solutions/charms.reactive/pull/51 | 14:20 |
| stub | bluetack: $CHARM_DIR/lib is in your reactive hook's PYTHONPATH, so you can put things in there. | 14:21 |
| bluetack | I do and I do, but they're not merged in yet | 14:21 |
| bluetack | stud: I'll give the ../hooks/whatever approach a try for now. thanks | 14:24 |
| bluetack | stub | 14:24 |
| bluetack | my intentions are purely honourable | 14:24 |
| stub | bluetack: It might be ./hooks/whatever - I think the cwd is $CHARM_DIR | 14:24 |
| bluetack | stub: can I reuse an existing hook? | 14:25 |
| bluetack | i.e. I dont have a hooks folder yet | 14:25 |
| marcoceppi | bluetack: you shouldn't need to create any hooks, they're generated during the build process | 14:27 |
| bluetack | understood. thankyou | 14:27 |
| shruthima | hi kwmonroe , how can i use "resource-get" option in the python code...? could you please provide links of any charms written in python using resources ..!! | 14:36 |
| kwmonroe | shruthima: check out charm-svg: https://jujucharms.com/u/marcoceppi/charm-svg | 14:39 |
| kwmonroe | shruthima: search resource_get in this source: https://github.com/marcoceppi/layer-charmsvg/blob/master/reactive/charmsvg.py | 14:39 |
| shruthima | thanks kevin :) | 14:41 |
| shruthima | kwmonroe: In IBM_IM charm for amulet testing how resources will be fetched..? | 14:42 |
| shruthima | we have noticed u have removed 00-setup file and added tests.yaml | 14:44 |
| shruthima | kwmonroe : i have tried to deploy ibm-im charm using amulet but is not fetching resources it is failing at timeout .. | 14:51 |
| === fwereade_ is now known as fwereade | ||
| cory_fu | mthaddon: Hey, are you around? | 14:54 |
| mthaddon | yep | 14:54 |
| kwmonroe | shruthima: the ibm-im charm will fetch the placeholder resources from the store when the charm deploys.. it's expected to fail, but i see the status message it was waiting for is incorrect. fixed here: http://bazaar.launchpad.net/~kwmonroe/charms/trusty/layer-ibm-im/switch-to-resources/revision/19#tests/01-deploy.py | 14:54 |
| cory_fu | mthaddon: You're listed as the maintainer of https://jujucharms.com/nrpe-external-master/ I'm looking to merge https://code.launchpad.net/~aluria/charms/precise/nrpe-external-master/donotremove-hostdefs/+merge/290957 since it has been approved, but because we have a new publish / promulgation process, I need it to be pushed & published into the maintainer's namespace (either yours personally, or an appropriate group) from which I can re-promulgate | 14:56 |
| kwmonroe | shruthima: until we can host the real resources (i think we've been calling that "resources phase 2" during our calls), we'll just test that the charms deploy and we see the right status message for the placeholder resources. | 14:57 |
| cory_fu | mthaddon: The end goal of this is to give more power to the maintainers to publish updates directly | 14:57 |
| shruthima | kwmonroe : is it like once the resources are in charm store only we can test amulet? | 14:57 |
| shruthima | oh k thanks kevin :) | 14:57 |
| mthaddon | cory_fu: we're migrating away from that charm to https://jujucharms.com/nrpe/trusty - is there a reason you'd prefer nrpe-external-master? | 14:58 |
| kjackal | Hey marcoceppi do you have any news for me regarding charmers? Thanks | 14:59 |
| cory_fu | mthaddon: I don't prefer it. Just trying to get an approved MP merged in. Are you to the point where we can unpromulgate nrpe-external-master entirely and get that change applied against cs:trusty/nrpe if applicable? | 15:00 |
| mthaddon | cory_fu: both charms are owned by ~charmers which you're a member of so you should be able to merge and promulgate yourself, no? | 15:02 |
| cory_fu | mthaddon: The point is that we're doing away with ~charmers ownership of promulgated charms in favor of ownership by the maintainer (or group, if more appropriate). | 15:03 |
| cory_fu | And the one bit that I can't do is push & publish to the new namespace in the store. | 15:03 |
| cory_fu | marcoceppi: Do we have a write-up of this new process somewhere? | 15:03 |
| mthaddon | cory_fu: I'm familiar with the new process, I just wasn't aware you were actively unowning things from ~charmers | 15:05 |
| rick_h_ | cory_fu: https://jujucharms.com/docs/devel/developer-getting-started | 15:09 |
| cory_fu | rick_h_, mthaddon: By new process, I specifically meant the fact that promulgated charms are no longer to be owned by ~charmers and that we are transitioning them as they are touched during review | 15:11 |
| cory_fu | I also believe marcoceppi was working on an email to the mailing list with a full list of charms that will need to be transitioned out of ~charmers ownership | 15:12 |
| rick_h_ | cory_fu: ah, yea that's not in the charmstore section or the charmers getting started section | 15:12 |
| cory_fu | Again, this is what I've been told by marcoceppi, so I'd like to get his feedback, but I think he's on a call and is going to get annoyed at me pinging him. ;) | 15:16 |
| rick_h_ | cory_fu: no, you're correct on the goal and how things are built | 15:16 |
| rick_h_ | cory_fu: we want to celebrate the true authors and make it clear it's not all canonical/one team that is responsible for the charms | 15:16 |
| cory_fu | Indeed | 15:17 |
| mthaddon | cory_fu: I'm not sure what to suggest in terms of that specific charm. I may be listed as the maintainer in the charm itself, but we consider it pretty much obsolete at this point. Is there a suggested approach for that case? | 15:17 |
| rick_h_ | mthaddon: cory_fu so are they compatible at all? e.g. can we provide a migration math and move over? | 15:19 |
| cory_fu | Yeah, if it's consider obsolete, then we should look at deprecating, migrating people off, and unpromulgating | 15:19 |
| aisrael | petevg: psst, don't forget to check the lock icon in the review queue ;) | 15:20 |
| cory_fu | aisrael: He can't | 15:20 |
| rick_h_ | cory_fu: and with the new process you can move what charm is promulgated and it maintains a history so we can look at a true migration path | 15:20 |
| mthaddon | but we don't have any way of migrating people off do we? surely that's up to them | 15:20 |
| aisrael | cory_fu: how so? | 15:20 |
| petevg | aisrael: yeah. I don't have permission to set the locked status. I think that I'm officially waiting for the new review queue to launch to get it. | 15:21 |
| mthaddon | rick_h_: nrpe supports the functionality of nrpe-external-master, but you need to set some specific config options. Not sure if that qualifies as a migration path | 15:21 |
| cory_fu | aisrael: Locking doesn't work for him or kjackal. Some bug due to them being newer accounts that was deemed not worth fixing since we're about to move to a new RQ platform anyway | 15:21 |
| aisrael | cory_fu: fair point. I meant to point out that the nagios stuff petevg just reviewed were locked to me, so I could have saved you some time | 15:22 |
| petevg | aisrael: right. I guess I could look at the locked icon :-) Whoops. | 15:22 |
| aisrael | tl;dr, unit tests in the nagios charm in the store are completely busted, so no tests are going to pass | 15:22 |
| cory_fu | aisrael: There is also an issue with the charmhelpers code synced into the proposed branch as well, though | 15:23 |
| aisrael | cory_fu: Yeah, one of many problems with the charm :/ | 15:24 |
| cory_fu | mthaddon: Are the config options different than the ones you would set with nrpe-external-master? | 15:24 |
| mthaddon | cory_fu: yes, you need to set new config options if you're migrating from nrpe-external-master to nrpe | 15:25 |
| rick_h_ | cory_fu: mthaddon so it'd be interesting to see if the upgrade charm hook in nrpe could help manage an upgrade from nrpe-external-master to itself | 15:25 |
| cory_fu | rick_h_: From the store page, it doesn't look like cs:precise/nrpe-external-master is used in any bundles. Do we have any other usage stats to see if it's being actively used such that we shouldn't simply unpromulgate it? | 15:25 |
| stub | nrpe-external-master is precise, nrpe is trusty. People need to redeploy to switch anyway. | 15:26 |
| rick_h_ | cory_fu: looking | 15:27 |
| cory_fu | stub: Good point | 15:27 |
| cory_fu | rick_h_: I feel like we need a better way of indicating to users that something is no longer recommended without breaking their stuff right away. Something like a flag we could set on the charm store that would cause Juju to emit a deprecation warning when deploying the charm. *shrug* Just a thought | 15:29 |
| rick_h_ | cory_fu: so https://api.jujucharms.com/charmstore/v4/nrpe-external-master/meta/stats/ suggests it's getting used twice today, 5 times this week, etc. | 15:36 |
| rick_h_ | cory_fu: so it's not a big footprint, but does exist? | 15:36 |
| cory_fu | rick_h_: Also, I suppose the fact that there's a MP against it means that it's being used | 15:39 |
| cory_fu | So I'm not sure what the appropriate action to take here is | 15:39 |
| stub | I'd lay money it is entirely Canonical internal, and a decent chance of all that being CI systems. | 15:39 |
| cory_fu | aluria: Since this is your PR, care to chime in? | 15:42 |
| * stub wanders off into the night | 15:42 | |
| aluria | cory_fu: hey, I think I don't have perms to merge it | 15:43 |
| cory_fu | aluria: :) Not looking for you to merge it. Looking for your input on the conversation about it being dropped in favor of cs:trusty/nrpe | 15:43 |
| cory_fu | And whether the usage of cs:precise/nrpe-external-master is entirely Canonical IS / CI | 15:44 |
| cory_fu | If so, it looks like the right approach is to transition | 15:44 |
| aluria | cory_fu: aah sorry... we're using it in several deployments but will start moving to lp:charms/trusty/nrpe in future ones | 15:44 |
| rick_h_ | cory_fu: so I think we unpromulgate it, move it to the new namespace, publish it to the juju list and update the readme perhaps | 15:47 |
| rick_h_ | cory_fu: and let folks like aluria know, maybe look for any other comitter in the "recent" tree | 15:47 |
| cory_fu | aluria: Do you know if that PR is applicable to nrpe as well? | 15:47 |
| cory_fu | rick_h_: New namespace being ~mthaddon? | 15:48 |
| aluria | cory_fu: it's not.... nrpe-external-master is written in bash while nrpe is in python (but will need to write a MP for nrpe too) | 15:48 |
| rick_h_ | cory_fu: if he wants it there, or we had an ~unmaintained, or we can do some ~deprecated-promulgated | 15:48 |
| cory_fu | aluria: Yeah, sorry, I meant the fix in general, not the specific patch | 15:48 |
| aluria | cory_fu: issue is very specific, and it also needs to be addressed in nrpe charm --- hacluster charm is a subordinate for OpenStack endpoints, and deploys /var/lib/nagios/exports/service__${hostname}_blabla.cfg and host__${hostname}.cfg | 15:49 |
| aluria | cory_fu: nrpe charm thinks there's only one host definition and removes all to recreate the non-subordinate hostdef one | 15:50 |
| aluria | you can end up having service defs without host defs --- patch only removes host defs without service defs | 15:51 |
| * mthaddon is +1 to moving it to a team with a name like ~unmaintained or something | 15:51 | |
| cory_fu | aluria: Ok, I opened it as a bug on nrpe: https://bugs.launchpad.net/charms/+source/nrpe/+bug/1595612 | 15:53 |
| mup | Bug #1595612: Be more selective in deleting host__*.cfg files <nrpe (Juju Charms Collection):New> <https://launchpad.net/bugs/1595612> | 15:53 |
| aluria | cory_fu: ta | 15:53 |
| cory_fu | rick_h_, mthaddon: I'm also +1 to moving it to ~deprecated or ~unmaintained. I wonder if we should promulgate it from there for a short period to give people like aluria a chance to transition | 15:54 |
| cory_fu | The short-term transition could just be adding the namespace, of course | 15:54 |
| cory_fu | Also, the question remains about merging this PR. I assume we need to get that fix in during the move. | 15:55 |
| arosales | kwmonroe: do you know if there are docs on how to use the docker box? | 15:57 |
| aluria | cory_fu: I ran into this bug which I think it's already solved -- https://bugs.launchpad.net/charms/+source/nrpe/+bug/1473205 | 16:00 |
| mup | Bug #1473205: nrpe charm creates checks with _sub postfix, breaking compatibility with nrpe-external-master <canonical-bootstack> <nrpe (Juju Charms Collection):New> <https://launchpad.net/bugs/1473205> | 16:00 |
| cory_fu | arosales: https://github.com/juju-solutions/charmbox | 16:02 |
| cory_fu | The README is pretty good on it | 16:03 |
| cory_fu | That one is designed for dev & testing. If you want a Docker image for just deploying using Juju, you can use the lighter-weight jujubox: https://github.com/juju-solutions/jujubox | 16:04 |
| cory_fu | arosales: ^ | 16:04 |
| === frankban is now known as frankban|afk | ||
| === zz_CyberJacob is now known as CyberJacob | ||
| marcoceppi | cory_fu: I've gone a bit off the deep end, but I think it's for the best | 19:53 |
| marcoceppi | cory_fu: https://github.com/juju-solutions/layer-apache-php/pull/5/files | 19:54 |
| marcoceppi | cory_fu: what I'd like to do, is build a layer tactic that merges apache.yaml to layer.yaml prior to validation | 19:55 |
| cory_fu | marcoceppi: +1 I've been meaning to update the apache-php layer to use layer.yaml for some time but never use it so didn't have the time or motivation | 20:03 |
| cory_fu | I suppose a custom tactic would be one way to handle migrating. How many charms are using that layer currently? Maybe we can submit patches against them all? | 20:04 |
| magicaltrout | oooh look at that | 20:06 |
| magicaltrout | you can spy on charm summit submissions in google forms :) | 20:06 |
| * magicaltrout bookmarks that page | 20:07 | |
| magicaltrout | marcoceppi: out of interest excluding merlijn's uploading issues, are their restrictions on resource sizes ? | 20:51 |
| marcoceppi | magicaltrout: not that I'm aware of | 20:53 |
| marcoceppi | magicaltrout: probably around the 50 GB size we have to start asking hard questions | 20:53 |
| marcoceppi | like "why" and "what" | 20:53 |
| magicaltrout | lol okay | 20:53 |
| marcoceppi | magicaltrout: wait | 20:59 |
| marcoceppi | you can see the submissions? | 20:59 |
| marcoceppi | magicaltrout: eheh, not anymore ;) | 21:00 |
| magicaltrout | :( | 21:03 |
| magicaltrout | didn't think that was on purpose :P | 21:03 |
| marcoceppi | Google forms comes with, by default, "allow users to see summary" which is follish | 21:14 |
| marcoceppi | foolish, even | 21:14 |
| magicaltrout | hehe | 21:14 |
| magicaltrout | well i didn't notice the first time | 21:14 |
| * magicaltrout should pay more attention | 21:14 | |
| * magicaltrout has plans afoot to transfer all of his data center ops to DC/OS and Juju... because..... why not... | 22:09 | |
| magicaltrout | reap what you sow and all that | 22:09 |
| magicaltrout | marcoceppi: you guys need to get 2.0 out so I can deploy without fear! ;) | 22:09 |
| === urulama is now known as urulama|__ | ||
| marcoceppi | magicaltrout: that sounds awesome | 22:14 |
| marcoceppi | magicaltrout: yeah, I'm pumped for 2.0 landing, we're really close to RC's which means we'll be upgradability between releases | 22:14 |
| magicaltrout | woop | 22:14 |
| magicaltrout | oh also on a slightly different note | 22:14 |
| magicaltrout | http://www.darpa.mil/news-events/2016-06-17 with my NASA hat on I should be working on this soon | 22:15 |
| magicaltrout | now I have no idea about what will actually happen, but most of the Darpa stuff gets open sourced | 22:15 |
| marcoceppi | bad ass! | 22:15 |
| magicaltrout | so automatic model discover over juju big data sounds pretty cool | 22:15 |
| magicaltrout | so if they do make is ASL I'll make sure we can stand up whatever is produced | 22:15 |
| magicaltrout | there's a bunch of the last darpa/nasa project I'm slowly working with some of the JPL guys on bringing to Juju, dark web crawling and stuff | 22:16 |
| === thumper is now known as thumper-afk | ||
| === mwhudson is now known as mwhudson__ | ||
| cholcombe | anyone around that knows mojo? | 23:21 |
| === alexisb is now known as alexisb-afk | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!