haasnWeird. 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 VMs00:00
haasnHave to go through the VMs all and recreated them manually I guess :/00:00
haasn2016-02-09 00:18:31 ERROR juju-log FATAL ERROR: Could not determine OpenStack codename for version 7.0.100:20
=== natefinch-afk is now known as natefinch
stubmarcoceppi: ETIMEZONE06:03
haasnWhat does “incomplete relations” mean?06:32
haasnIt's obviously different from “missing relations” in some sense06:32
haasnRevelation: 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 site09:49
apuimedojamespage: did you see the merge proposal I sent last night for fixing liberty support?10:34
jamespageapuimedo, I saw the charm mp - is there a charm-helpers proposal as well?10:35
jamespageI've not looked yet...10:35
apuimedolack of sleep10:35
apuimedoTotally forgot about updating it in charm-helpers10:36
apuimedoI'll send it now10:36
apuimedojamespage: https://code.launchpad.net/~celebdor/charm-helpers/plugin_pkg_fix/+merge/28545810:41
marcoceppistub: ping13:16
stubmarcoceppi: pong13:26
marcoceppistub: 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 module13:27
marcoceppiwhich is the pattern a lot of other layers are starting to use13:28
stubmarcoceppi: 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
marcoceppiwhat do you mean?13:28
stubSo if that gets rejected, yeah, I'll need to split things into $CHARM_DIR/reactive and $CHARM_DIR/lib13:29
stubThe branch fixes absolute imports, relative imports, and other import weirdness I've seen.13:30
marcoceppiTo 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 exporting13:31
stubI've got reactive stuff as my charm specific stuff, and lib for non charm/non juju stuff.13:33
marcoceppiright, 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 states13:34
stubBut in any case, it would be nice to get imports in reactive and hooks/{reactive,relations} working as expected.13:34
marcoceppiif cory_fu is around today I'll chat with him about it13:35
stubYes, 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
marcoceppiI'll chat with cory on goals and vision13:36
stubIt was all working fine for me until I switched to the standard hook stubs and lost $CHARM_DIR from my sys.path ;)13:36
stubYou 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 directly13:37
stubmarcoceppi: 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 different13:44
stubmarcoceppi: 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
marcoceppistub: 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 perspective13:45
stubI'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
stubmarcoceppi: 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
marcoceppistub: we've been prefacing modules by placing them in lib/charms/13:49
stubmarcoceppi: at which point I'm stomping around in cory's namespace.13:50
marcoceppithat way it's from charms import apt13:50
marcoceppithat was the guidance I got from him originally13:50
stubRight. Not as reactive specific as I'd like, but it will do in a pinch.13:50
stubI guess reactive *is* the new charms13:50
marcoceppistub: maybe we should namespace further in the charms module to be like charms.layers or possibly a lib/reactive/ ?13:51
marcoceppisomething work discussing13:51
stubthat is what I did with the symlink hack ;)13:51
marcoceppiyeah, but I think it went a little too far with the symlink to reactive dir13:51
marcoceppieither way13:51
marcoceppiI'll ping cory to chat about it either today or tomorrow13:52
marcoceppiI think he's still taking vacation after last week13:52
marcoceppiwill mail the list with the discussion13:52
stubmarcoceppi: Have you noticed the potential migration path for charmhelpers/core/hookenv.py yet? ;)14:00
marcoceppistub: I've been playing with a few ideas14:03
stubmarcoceppi: Was thinking if these layers and similar get accepted, the code they wrap could move directly into the layer.14:03
stubOld functionality, new, consistent api.14:04
ShruthimaHi 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
mbruzekHello Shruthima14:25
mbruzekShruthima: If IBM IM is a pre-requisite that tells me that is should be a layer that other charms could include.14:28
mbruzekShruthima: https://jujucharms.com/docs/devel/developer-layers14:31
Shruthimaok thanks14:32
mbruzekShruthima: 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
mbruzekI wrote a tls layer for one charm, that is now used in 2 charms.  https://github.com/mbruzek/layer-tls14:33
mbruzekShruthima: Although that layer is quite different than IBM IM, you may be able to use that as an example14:34
Shruthimayes ,i feel it right . will check on layers and try to do it is a layer.14:34
mbruzekShruthima: You _can_ write the layers in bash, but it may be easier to do in Python14:34
mbruzek(less code, easier to maintain, etc)14:35
Shruthimaoh k thank you if any queries will check with you.14:36
mbruzekShruthima: Good luck!14:37
cory_fustub, 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_fuI 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/* location15:21
cory_fuMaybe 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
marcoceppicory_fu: I think an explicit namespace for helpers that layers provide would be good15:37
marcoceppiin this case, the layer.py would just be __init__.py with those few methods?15:37
marcoceppior possibly charms.layers.config for the base layer stuff?15:37
jeiworthhi all15:49
jeiworthquick 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 t15:51
cory_fumarcoceppi: Yeah, I'm fine w/ an __init__.py for the options helpers16:01
jeiworth...sooo any ideas welcome... :-)16:03
marcoceppijeiworth: I will take a look in a min!16:17
jeiworthmarcoceppi: thanks!16:18
bdxHows it going everyone? Does anyone know how to switch the source of a deployed charm?18:34
marcoceppibdx: the charm source?18:35
=== CyberJacob is now known as Guest83242
stokachuhttp://paste.ubuntu.com/15004365/, anyone else seeing this issue with juju from master?20:07
stokachui see the Deploy function under the Service api type though20:08
bdxmarcoceppi: say you deploy local:trusty/nova-compute, following which you want to switch to cs:trusty/nova-compute20:10
marcoceppibdx: juju upgrade-charm --switch cs:trusty/nova-compute nova-compute20:10
bdxmarcoceppi: exactly20:12
bdxthanks 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!