| haasn | Weird. Destroying the VM and re-creating it and now everything seems to work. Must have been some weird failure due to the way I batch-created the VMs | 00:00 |
|---|---|---|
| haasn | Have to go through the VMs all and recreated them manually I guess :/ | 00:00 |
| haasn | 2016-02-09 00:18:31 ERROR juju-log FATAL ERROR: Could not determine OpenStack codename for version 7.0.1 | 00:20 |
| haasn | Huh? | 00:20 |
| === natefinch-afk is now known as natefinch | ||
| stub | marcoceppi: ETIMEZONE | 06:03 |
| haasn | What does “incomplete relations” mean? | 06:32 |
| haasn | It's obviously different from “missing relations” in some sense | 06:32 |
| haasn | Revelation: Writing configs by hand is faster, easier, more efficient, more robust and more scaleable than attempting to use juju for anything other than setting up a basic wordpress site | 09:49 |
| apuimedo | jamespage: did you see the merge proposal I sent last night for fixing liberty support? | 10:34 |
| jamespage | apuimedo, I saw the charm mp - is there a charm-helpers proposal as well? | 10:35 |
| jamespage | I've not looked yet... | 10:35 |
| apuimedo | heh | 10:35 |
| apuimedo | lack of sleep | 10:35 |
| apuimedo | Totally forgot about updating it in charm-helpers | 10:36 |
| apuimedo | I'll send it now | 10:36 |
| apuimedo | jamespage: https://code.launchpad.net/~celebdor/charm-helpers/plugin_pkg_fix/+merge/285458 | 10:41 |
| marcoceppi | stub: ping | 13:16 |
| stub | marcoceppi: pong | 13:26 |
| marcoceppi | stub: love the apt layer, but have some concerns symlinking the reactive directory into lib. I feel it'd be better to instead move the 4 or 5 methods you want to expose to other layers as a charms.apt module | 13:27 |
| marcoceppi | which is the pattern a lot of other layers are starting to use | 13:28 |
| stub | marcoceppi: That is a hack until I can get absolute imports working with charms.reactive (I've got a pull request up for that) | 13:28 |
| marcoceppi | what do you mean? | 13:28 |
| stub | https://github.com/juju-solutions/charms.reactive/pull/51 | 13:29 |
| stub | So if that gets rejected, yeah, I'll need to split things into $CHARM_DIR/reactive and $CHARM_DIR/lib | 13:29 |
| stub | The branch fixes absolute imports, relative imports, and other import weirdness I've seen. | 13:30 |
| marcoceppi | To me, it seems that reative/* files are basically main() methods for dispatching. i wouldn't want people importing or relying on them. whereas things in lib/ are the public apis I'm exporting | 13:31 |
| stub | I've got reactive stuff as my charm specific stuff, and lib for non charm/non juju stuff. | 13:33 |
| marcoceppi | right, but I think putting reactive stuff would be okay in lib/charms/ since this prefaced as a charm thing. I wouldn't want people importing my reactive/ files because they're basically just glue for managing states | 13:34 |
| stub | But in any case, it would be nice to get imports in reactive and hooks/{reactive,relations} working as expected. | 13:34 |
| marcoceppi | if cory_fu is around today I'll chat with him about it | 13:35 |
| stub | Yes, it could go in there. In my case, reactive *isn't* just glue and is documented that way. But I can change that. | 13:35 |
| marcoceppi | I'll chat with cory on goals and vision | 13:36 |
| stub | It was all working fine for me until I switched to the standard hook stubs and lost $CHARM_DIR from my sys.path ;) | 13:36 |
| stub | You want files containing handlers to be able to import other files containing handlers in any case, as sometimes they are triggered by state and sometimes you want to invoke them directly | 13:37 |
| stub | marcoceppi: I'll still shuffle things around to $CHARM_DIR/lib/apt.py if that is where things like this should go - no point being unnecessarily different | 13:44 |
| stub | marcoceppi: The leadership layer will have the same thing, and the coordinator layer (which I was blocking announcing until that pull request got commented on) | 13:44 |
| marcoceppi | stub: I'd appreciate it, at least for the apt layer, as it'll make integration easier for some of the other layers. As for the others coordinator and leadership there may be a use case there for them to import reactive directly, I'll let cory_fu judge that from a library maintainer perspective | 13:45 |
| stub | I've got gpg keys, json data files, and a few small Python helpers lurking in lib. Its a bit of a grab bag. | 13:47 |
| stub | marcoceppi: oh, that was an issue. In particular for the apt layer. 'import apt' will get the system apt module. I'd need to stick it in charms/reactive/apt since this is specificly reactive framework stuff. | 13:49 |
| marcoceppi | stub: we've been prefacing modules by placing them in lib/charms/ | 13:49 |
| stub | marcoceppi: at which point I'm stomping around in cory's namespace. | 13:50 |
| marcoceppi | that way it's from charms import apt | 13:50 |
| marcoceppi | that was the guidance I got from him originally | 13:50 |
| stub | Right. Not as reactive specific as I'd like, but it will do in a pinch. | 13:50 |
| stub | I guess reactive *is* the new charms | 13:50 |
| marcoceppi | stub: maybe we should namespace further in the charms module to be like charms.layers or possibly a lib/reactive/ ? | 13:51 |
| marcoceppi | something work discussing | 13:51 |
| stub | that is what I did with the symlink hack ;) | 13:51 |
| marcoceppi | yeah, but I think it went a little too far with the symlink to reactive dir | 13:51 |
| marcoceppi | either way | 13:51 |
| marcoceppi | I'll ping cory to chat about it either today or tomorrow | 13:52 |
| stub | ta | 13:52 |
| marcoceppi | I think he's still taking vacation after last week | 13:52 |
| marcoceppi | will mail the list with the discussion | 13:52 |
| stub | marcoceppi: Have you noticed the potential migration path for charmhelpers/core/hookenv.py yet? ;) | 14:00 |
| marcoceppi | stub: I've been playing with a few ideas | 14:03 |
| stub | marcoceppi: Was thinking if these layers and similar get accepted, the code they wrap could move directly into the layer. | 14:03 |
| stub | Old functionality, new, consistent api. | 14:04 |
| Shruthima | Hi Mbruzek, IBM installation manager is a prerequisite tool for many IBM products installation such as WAS, DB2, HTTP Server. So, it doesn't have database relation or web interface. Can we charm without using any interface ? Could you please suggest me which interface i can use for IBM-Installation manager charm..? | 14:24 |
| mbruzek | Hello Shruthima | 14:25 |
| mbruzek | Shruthima: If IBM IM is a pre-requisite that tells me that is should be a layer that other charms could include. | 14:28 |
| mbruzek | Shruthima: https://jujucharms.com/docs/devel/developer-layers | 14:31 |
| Shruthima | ok thanks | 14:32 |
| mbruzek | Shruthima: So to answer your question, if software X is a pre-requisite and has no known relations that is the perfect reason to make a layer. The trick is to make it useful so that ALL the other IBM charms can use that layer, and they would not have to have any IBM IM code in their charms. | 14:32 |
| mbruzek | I wrote a tls layer for one charm, that is now used in 2 charms. https://github.com/mbruzek/layer-tls | 14:33 |
| mbruzek | Shruthima: Although that layer is quite different than IBM IM, you may be able to use that as an example | 14:34 |
| Shruthima | yes ,i feel it right . will check on layers and try to do it is a layer. | 14:34 |
| mbruzek | Shruthima: You _can_ write the layers in bash, but it may be easier to do in Python | 14:34 |
| mbruzek | (less code, easier to maintain, etc) | 14:35 |
| Shruthima | oh k thank you if any queries will check with you. | 14:36 |
| mbruzek | Shruthima: Good luck! | 14:37 |
| cory_fu | stub, marcoceppi: Sorry for the late reply. Got a late start today because I'm sick following the summit. I'm torn on the issue of importing within reactive/. On the one hand, I like the idea of cleaning up the import code. On the other, I'm leaning strongly against reactive handlers being imported directly for anything other than tests. | 15:20 |
| cory_fu | I prefer to think of files under reactive/ as executables and thus anything that is common to multiple handler files should be factored up into a lib/charms/* location | 15:21 |
| cory_fu | Maybe we could reserve a namespace specifically for helpers that a given layer provides? We currently have lib/charms/layer.py used in the base layer for the layer.yaml options support, but maybe we could restructure that and reserve lib/charms/layer/<layer-name> for each layer to put its own helpers? So, the apt layer would have helpers you would access via "import charms.layer.apt" | 15:27 |
| marcoceppi | cory_fu: I think an explicit namespace for helpers that layers provide would be good | 15:37 |
| marcoceppi | in this case, the layer.py would just be __init__.py with those few methods? | 15:37 |
| marcoceppi | or possibly charms.layers.config for the base layer stuff? | 15:37 |
| jeiworth | hi all | 15:49 |
| jeiworth | quick question, i am using juju deployment in aws and have the landscape-client charm deployed and connected to my instances. my landscape i have standalone in another environment. first, i configured the landscape client from ssh cli and all was good, i later adapted the same configuration through the juju-gui of the charm and since then it apparently does't recognize reboots? i can still update packages through landscape and if i send t | 15:51 |
| cory_fu | marcoceppi: Yeah, I'm fine w/ an __init__.py for the options helpers | 16:01 |
| jeiworth | ...sooo any ideas welcome... :-) | 16:03 |
| marcoceppi | jeiworth: I will take a look in a min! | 16:17 |
| jeiworth | marcoceppi: thanks! | 16:18 |
| bdx | Hows it going everyone? Does anyone know how to switch the source of a deployed charm? | 18:34 |
| marcoceppi | bdx: the charm source? | 18:35 |
| === CyberJacob is now known as Guest83242 | ||
| stokachu | http://paste.ubuntu.com/15004365/, anyone else seeing this issue with juju from master? | 20:07 |
| stokachu | i see the Deploy function under the Service api type though | 20:08 |
| bdx | marcoceppi: say you deploy local:trusty/nova-compute, following which you want to switch to cs:trusty/nova-compute | 20:10 |
| marcoceppi | bdx: juju upgrade-charm --switch cs:trusty/nova-compute nova-compute | 20:10 |
| bdx | marcoceppi: exactly | 20:12 |
| bdx | thanks mon! | 20:12 |
| === menn0_ is now known as menn0 | ||
| === natefinch is now known as natefinch-afk | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!