[00:00] Should be pretty simple too.. if hook=changed && len(relation_changes) == 0: relation.set_state('steady') [00:00] SpamapS, i just don't understand why that isn't a relation setting itself [00:00] jimbaker: so you're going to make state a special relation setting? [00:00] you could put any number of such state variables in the relation settings, just need to agree on a conention [00:01] convention [00:01] that seems to violate the encapsulation that is around relation settings right now [00:02] i just don't see the special treatment required, that's all. it's just between service units anyway imho [00:02] The convention I'm agreeing on is that the hooks decide not to change anything, so this is a clear intent: that side of the relationship is steady. [00:02] If both sides of a relationship are steady, it would be considered fully established. [00:03] sure, that might be useful from a status perspective [00:03] from an ordering perspective, its vital [00:03] I need to know that keystone has mysql and rabbitmq before I start asking it for credentials [00:03] i guess i just don't understand why relation settings are not powerful enough to express this [00:04] jimbaker: they're *too* powerful [00:05] jimbaker: they're free form, and can be anything... juju shouldn't imply anything by any of the relation settings. [00:05] But you can absolutely imply that the relationship is fully estblished if neither side sets any values. [00:05] * SpamapS feels that perhaps code is needed. [00:05] SpamapS, right, but again, i don't understand why juju should do anything except sit back and orchestrate. anyway, agreed on the utility of saying this in status [00:06] It is going to sit back and orchestrate. Right now it is providing relationships that it cannot possibly satisfy [00:06] jimbaker: keystone simply cannot provide 'interface: keystone' until it has mysql and rabbit [00:07] jimbaker: if you make a relation setting special, that will work. But there's no need for tampering with relation settings. You have an implied state already. [00:07] SpamapS, i definitely don't want to make any relation setting special [00:08] other than whatever interface two services agree upon, without juju making any special assumptions about that [00:09] right so I think we're talking past eachother then [00:10] SpamapS, no worries. i'm sure it will be clearer with some good code examples [00:11] and we should definitely put this api change out there for juju status and 'steady' [00:12] and see if that's something that can be done or not [00:13] I don't necessarily think it has to be an API change at first [00:14] well yeah, using a second state would be lame [00:14] but really, this has almost *nothing* to do with status output [00:14] thats just a nice side effect [00:16] SpamapS, changing the unit lifecycles is an api change, even if it's pretty trivial as above [00:17] jimbaker: aye [01:00] hazmat: still around? [01:11] adam_g, yup [01:13] going through the steady state idea in my head.. I think its doable.. but would break ZK backward compatibility [01:14] since you'd need a new state for unit relations [01:17] hazmat: im adding some of these optional required relations to the nova charms, as per our conversation last week. now i'm hitting the 'Ambiguous relation' errors. is that just a PITA atm or are actually charms not meant to provide multiple interfaces? [01:17] adam_g: you were just meant to always be explicit about which relation you meant to use. :) [01:17] adam_g, if a charm provides the same interface multiple times, the name has to be specified when adding the relation [01:17] ok [01:18] adam_g, this was in regard to nova-compute and nova-volume depending on nova-controller? [01:18] hazmat: thats actually a pretty big problem... we'll break lots of deploy scripts any time we add an optional relation for convenience purposes or something. :-( [01:19] hazmat & SpamapS : mind to help with this http://paste.ubuntu.com/832099/ [01:19] hazmat: yes, about having an optional cloud-controller interface that is listed in the metdata but actually has no hooks. there is also another interface on cloud-controller that is specific to compute nodes, which is causing the ambiguity [01:20] ejat: you forgot 'local:' [01:20] if i want to try at ec2 ? [01:21] SpamapS, true, either we spec them explicitly or avoid the use of multiply providing it. [01:21] ejat, its still local: prefix to the charm [01:21] repository ? [01:21] * ejat blur [01:21] adam_g: no hooks? doesn't that sort of mean that its not the same interface? [01:21] ejat: symfony should be 'local:symfony' [01:21] adam_g, yeah.. that sounds odd [01:22] SpamapS: owh okie [01:23] adam_g, so take nova-compute.. http://charms.kapilt.com/~gandelman-a/precise/nova-compute [01:23] its depending on nova-volume, but its using a generic interface 'nova' [01:23] as we discussed last week, there is the issue that nova-compute and nova-volume will never have a direct relationship between them, but listing them in the metadata helps model the dependencies of the entire deployment, at least IIRC [01:23] which is also used by nova-cloud-controller [01:23] there are different interfaces [01:23] s/there/those [01:24] adam_g, the ambiguity was that both 'nova-cloud-controller' and 'nova-volume' provide the 'nova' interface [01:25] thats actually two interfaces, they don't provide the same thing [01:25] right [01:25] nova-volume will now provide instance-storage:nova-volume [01:25] sounds good [01:25] nova-cloud-controller cloud-controller:nova [01:26] ok [01:26] nova-volume + nova-compute both interface with cloud-controller:nova [01:26] so now nova-compute depends on nova, and nova-volume, and nova-volume depends on nova [01:26] eek hard to parse [01:27] hazmat: i guess whats fuzzy to me is the dependency between nova-compute and nova-volume. there will never be a direct relation, but IIRC last week we discussed listing it in nova-computes metadata as an optional require:, is that right? [01:27] adam_g, they depend on the interface not the named interface, but sounds good, why doesn't nova-compute have a dependency on the 'nova-volume' interface [01:28] I'd guess because they can exist w/o eachother. [01:28] nova-compute and nova-volume never talk to one another directly, the message bus and database provide that [01:28] adam_g, what's the api endpoint? [01:29] and yes, one can exist w/o the other, tho the features its exposed to would then be limited [01:29] adam_g, do nova-compute and nova-volume both have different api endpoints? [01:29] http://paste.ubuntu.com/832105/ .. i follow wordpress charm [01:29] hazmat: they dont have api endpoints [01:29] adam_g, what component offers the nova api? [01:29] hazmat: nova-cloud-controller [01:29] (nova-api, nova-scheduler) [01:29] ejat: sweet [01:29] adam_g, then nova-cloud-controller has the dependency on nova-volume and nova-compute [01:30] hazmat: right [01:30] but it wont expose :( [01:30] hazmat: and nova-compute + nova-volume have no knowledge of each other, in terms of metadata/hooks. correct? [01:30] ejat: state: pending ... you need 'state: started' ;) [01:30] adam_g, right [01:31] ok i think we're on the same page now :) [01:31] cool [01:31] apache not start ? [01:33] hazmat: so, whats the idea here? that you can relate them to aid with what? [01:33] ejat: ssh in and look at /var/lib/juju/units/symfony-0/charm.log [01:35] thanks .. forget -y :) [01:35] brb .. [01:35] fixing it .. [01:42] SpamapS, no need for the additional relation, just trying to unambigiously identify the dependencies for a charm [01:43] SpamapS, the current nova-compute has an ambigious dependency around 'nova' which could be satisified by nova-volume or nova-cloud-controller, but it sounds like really that dependency doesn't exist, and instead its the nova-cloud-controller that depends on unique interfaces of -volume and -compute [01:43] hazmat: yeah it sounds like the nova interface was accidentally overloaded [01:47] SpamapS: http://paste.ubuntu.com/832120/ [01:47] which charm sample should i refer [01:47] for the mysql thingss [01:52] ejat: there is already a mysql charm. Why are you deploying mysql? [01:53] owh .. thnaks remind .. sorry .. [01:53] removing it .. [01:53] ejat: its perfectly normal to have mysql + another thing in one charm.. just seems odd [01:54] bcoz just now i test it all in one .. [01:54] ejat: anyway, if you use the juju from the PPA, instead of oneiric.. you'll get DEBIAN_FRONTEND=noninteractive when you run 'apt-get -y install foo' it won't ask these questions. [01:54] * SpamapS hopes to SRU that back to oneiric.. if we fix the bug where you can't SRU juju because it won't allow pulling from proposed. :-P [01:54] already put -y [01:54] anyway, I have to go [01:55] * SpamapS disappears [01:55] ok .. [02:05] hazmat: sent some merge proposals to fix the interfaces on the oneiric branches. need to update that deployer script those ambigious relations before fixing precise, else our CI breaks [02:06] adam_g, why do you have ambigious relations? [02:08] hazmat: nova-cloud-controller provides a second interface to nova-compute for nova-network configuration [02:09] nova-cloud-controller afaics shouldn't be providing interfaces to nova-x services. it should be depending on all of the nova-x's [02:10] nova-cloud-controller depends on nova-network, nova-volume, nova-compute interfaces [02:10] hazmat: there is currently no nova-network charm. depending on which networking flavor is configured, nova-network may run on the cloud-controller or compute node. [02:11] hazmat: http://paste.ubuntu.com/832144/ [02:12] hazmat: configuring FlatManager requires nova-network on the cloud-controller + a bridge interface manually configured on -compute + -cloud-controller. FlatDHCPManager requires no bridge configuration, but nova-network running on the compute node with a couple of flags set in config === hspencer is now known as hspencer[afk] [02:13] adam_g, sounds like something which needs to be driven off the 'nova-compute' relation between -cloud-controller and -compute, in those cases its not really a separate charm [02:14] adam_g, with quantum does the network component still have to be installed on the compute nodes? [02:15] hazmat: im not sure, i haven't touched quantum yet. AFAIK, its a seperate service that runs somewhere in the deployment with nova-network configured to use a pluggable QuantumManager driver like it would FlatDHCPManager === hspencer[afk] is now known as hspencer === asavu_ is now known as asavu [12:00] Good mornings! [15:42] SpamapS: may I G+ you when you're around? [15:43] I need maybe 10 minutes of feedback from you and then I'll be done. :) [15:44] jcastro: server team meetings have me busy from now until 2+ hours from now [15:44] ok, can I have dibs after? [15:44] :) [15:57] jcastro: you had dibs at hello [15:57] jcastro: You had dibs at *HELLO* [15:57] * SpamapS breaks down [15:58] SpamapS: good morning sir!! :) [16:05] SpamapS: Hello? [16:05] feeling any better now? :) [16:27] <_mup_> Bug #928348 was filed: Charm bundles should work with symlinks < https://launchpad.net/bugs/928348 > [16:34] mpl: hi! [16:40] :-) === hspencer is now known as hspencer[mtg] [17:34] m_3, SpamapS, adam_g fwiw i've put the automated charm testing tools i've been experimenting with over here https://code.launchpad.net/~hazmat/+junk/charmrunner [17:38] currently it can generate an automated test plan for deps and setup an environment from a json file (the environment is reusable between setups) [17:56] SpamapS: available yet? [17:57] jcastro: meetings over soon [18:28] jcastro: t-minus 5 minutes === hspencer[mtg] is now known as hspencer [18:35] jcastro: GO [18:35] SpamapS: hangout firing up [19:09] Hello guys, I was wondering if the 'stop' hook is called when calling 'destroy-environment' command. [19:09] My idea is to backup my data and upload it (to dropbox, for example) before actually destroying the instance. [20:44] otubo: Currently stop is never called. [20:44] otubo: destroy-environment == rm -rf [20:44] otubo: be careful. :) [21:43] SpamapS, roger that! Thanks :-) [22:26] bcsaller, adam_g, SpamapS fwiw, i ended up doing this for service watching.. http://bazaar.launchpad.net/~hazmat/+junk/charmrunner/view/head:/charmrunner/watcher.py [22:33] oh this is weird [22:34] $ juju set jenkins plugins='openid instant-messaging ircbot bazaar' [22:34] Expected `option=value`. Found `instant-messaging` [22:34] no way to do a space delimited value [22:35] SpamapS, i think you just need the right escape there [22:35] juju set jenkins plugins=openid\ instant-messaging\ ircbot\ bazaar [22:35] that doesn't work [22:36] I wonder if this is argparse's problem [22:36] SpamapS, it might be a problem with the parse logic.. i'd try a double qoute.. [22:36] juju set jenkins "plugins=openid instant-messaging ircbot bazaar" [22:36] does not work [22:37] sh -c 'juju set jenkins "plugins=openid instant-messaging ircbot bazaar"' [22:37] *that* worked [22:52] m_3: hi! Hen you held an class in #ubuntu-classroom during ubuntu developer week you were using something to show us juju via ssh. What tool was thta? [22:52] When* [22:53] * Atlantic777 has to change keyboard... [23:12] Atlantic777: hey [23:13] Atlantic777: I was using a charm called juju-classroom... it's just a specialization of byobu-classroom [23:14] m_3: a friend of mine wants to start irc classrooms so I find this a useful thing for him. :) [23:14] thanks [23:15] Atlantic777: sure thing [23:16] there're plans to scale this... it's limited by ajaxterm atm [23:16] somethiung like 20 connections at once or so [23:16] m_3: native ssh client is more interesting :D [23:17] yup... that should scale nicely [23:39] Yeah should be able to scale out using a simple tiered approach where every node ssh's once time into the backend byobu and then all ssh clients just join that screen.