[00:00] <SpamapS> Should be pretty simple too.. if hook=changed && len(relation_changes) == 0: relation.set_state('steady')
[00:00] <jimbaker> SpamapS, i just don't understand why that isn't a relation setting itself
[00:00] <SpamapS> jimbaker: so you're going to make state a special relation setting?
[00:00] <jimbaker> you could put any number of such state variables in the relation settings, just need to agree on a conention
[00:01] <jimbaker> convention
[00:01] <SpamapS> that seems to violate the encapsulation that is around relation settings right now
[00:02] <jimbaker> i just don't see the special treatment required, that's all. it's just between service units anyway imho
[00:02] <SpamapS> 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] <SpamapS> If both sides of a relationship are steady, it would be considered fully established.
[00:03] <jimbaker> sure, that might be useful from a status perspective
[00:03] <SpamapS> from an ordering perspective, its vital
[00:03] <SpamapS> I need to know that keystone has mysql and rabbitmq before I start asking it for credentials
[00:03] <jimbaker> i guess i just don't understand why relation settings are not powerful enough to express this
[00:04] <SpamapS> jimbaker: they're *too* powerful
[00:05] <SpamapS> jimbaker: they're free form, and can be anything... juju shouldn't imply anything by any of the relation settings.
[00:05] <SpamapS> 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] <jimbaker> 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] <SpamapS> It is going to sit back and orchestrate. Right now it is providing relationships that it cannot possibly satisfy
[00:06] <SpamapS> jimbaker: keystone simply cannot provide 'interface: keystone' until it has mysql and rabbit
[00:07] <SpamapS> 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] <jimbaker> SpamapS, i definitely don't want to make any relation setting special
[00:08] <jimbaker> other than whatever interface two services agree upon, without juju making any special assumptions about that
[00:09] <SpamapS> right so I think we're talking past eachother then
[00:10] <jimbaker> SpamapS, no worries. i'm sure it will be clearer with some good code examples
[00:11] <jimbaker> and we should definitely put this api change out there for juju status and 'steady'
[00:12] <jimbaker> and see if that's something that can be done or not
[00:13] <SpamapS> I don't necessarily think it has to be an API change at first
[00:14] <SpamapS> well yeah, using a second state would be lame
[00:14] <SpamapS> but really, this has almost *nothing* to do with status output
[00:14] <SpamapS> thats just a nice side effect
[00:16] <jimbaker> SpamapS, changing the unit lifecycles is an api change, even if it's pretty trivial as above
[00:17] <SpamapS> jimbaker: aye
[01:00] <adam_g> hazmat: still around?
[01:11] <hazmat> adam_g, yup
[01:13] <SpamapS> going through the steady state idea in my head.. I think its doable.. but would break ZK backward compatibility
[01:14] <SpamapS> since you'd need a new state for unit relations
[01:17] <adam_g> 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] <SpamapS> adam_g: you were just meant to always be explicit about which relation you meant to use. :)
[01:17] <hazmat> adam_g, if a charm provides the same interface multiple times, the name has to be specified when adding the relation
[01:17] <adam_g> ok
[01:18] <hazmat> adam_g, this was in regard to nova-compute and nova-volume depending on nova-controller?
[01:18] <SpamapS> 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] <ejat> hazmat & SpamapS : mind to help with this http://paste.ubuntu.com/832099/
[01:19] <adam_g> 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] <SpamapS> ejat: you forgot 'local:'
[01:20] <ejat> if i want to try at ec2 ?
[01:21] <hazmat> SpamapS, true, either we spec them explicitly or avoid the use of multiply providing it.
[01:21] <hazmat> ejat, its still local: prefix to the charm
[01:21] <ejat> repository ?
[01:21]  * ejat blur
[01:21] <SpamapS> adam_g: no hooks? doesn't that sort of mean that its not the same interface?
[01:21] <SpamapS> ejat: symfony should be 'local:symfony'
[01:21] <hazmat> adam_g, yeah.. that sounds odd
[01:22] <ejat> SpamapS: owh okie
[01:23] <hazmat> adam_g, so take nova-compute.. http://charms.kapilt.com/~gandelman-a/precise/nova-compute
[01:23] <hazmat> its depending on nova-volume, but its using a generic interface 'nova'
[01:23] <adam_g> 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] <hazmat> which is also used by nova-cloud-controller
[01:23] <hazmat> there are different interfaces
[01:23] <hazmat> s/there/those
[01:24] <hazmat> adam_g, the ambiguity was that both 'nova-cloud-controller' and 'nova-volume' provide the 'nova' interface
[01:25] <hazmat> thats actually two interfaces, they don't provide the same thing
[01:25] <adam_g> right
[01:25] <adam_g> nova-volume will now provide instance-storage:nova-volume
[01:25] <hazmat> sounds good
[01:25] <adam_g> nova-cloud-controller cloud-controller:nova
[01:26] <hazmat> ok
[01:26] <adam_g> nova-volume + nova-compute both interface with cloud-controller:nova
[01:26] <hazmat> so now nova-compute depends on nova, and nova-volume, and nova-volume depends on nova
[01:26] <hazmat> eek hard to parse
[01:27] <adam_g> 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] <hazmat> 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] <SpamapS> I'd guess because they can exist w/o eachother.
[01:28] <adam_g> nova-compute and nova-volume never talk to one another directly, the message bus and database provide that
[01:28] <hazmat> adam_g, what's the api endpoint?
[01:29] <adam_g> and yes, one can exist w/o the other, tho the features its exposed to would then be limited
[01:29] <hazmat> adam_g, do nova-compute and nova-volume both have different api endpoints?
[01:29] <ejat> http://paste.ubuntu.com/832105/ .. i follow wordpress charm
[01:29] <adam_g> hazmat: they dont have api endpoints
[01:29] <hazmat> adam_g, what component offers the nova api?
[01:29] <adam_g> hazmat: nova-cloud-controller
[01:29] <adam_g> (nova-api, nova-scheduler)
[01:29] <SpamapS> ejat: sweet
[01:29] <hazmat> adam_g, then nova-cloud-controller has the dependency on nova-volume and nova-compute
[01:30] <adam_g> hazmat: right
[01:30] <ejat> but it wont expose :(
[01:30] <adam_g> hazmat: and nova-compute + nova-volume have no knowledge of each other, in terms of metadata/hooks. correct?
[01:30] <SpamapS> ejat: state: pending ... you need 'state: started' ;)
[01:30] <hazmat> adam_g, right
[01:31] <adam_g> ok i think we're on the same page now :)
[01:31] <hazmat> cool
[01:31] <ejat> apache not start ?
[01:33] <SpamapS> hazmat: so, whats the idea here? that you can relate them to aid with what?
[01:33] <SpamapS> ejat: ssh in and look at /var/lib/juju/units/symfony-0/charm.log
[01:35] <ejat> thanks .. forget -y :)
[01:35] <ejat> brb ..
[01:35] <ejat> fixing it ..
[01:42] <hazmat> SpamapS, no need for the additional relation, just trying to unambigiously identify the dependencies for a charm
[01:43] <hazmat> 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] <SpamapS> hazmat: yeah it sounds like the nova interface was accidentally overloaded
[01:47] <ejat> SpamapS: http://paste.ubuntu.com/832120/
[01:47] <ejat> which charm sample should i refer
[01:47] <ejat> for the mysql thingss
[01:52] <SpamapS> ejat: there is already a mysql charm. Why are you deploying mysql?
[01:53] <ejat> owh .. thnaks remind .. sorry ..
[01:53] <ejat> removing it ..
[01:53] <SpamapS> ejat: its perfectly normal to have mysql + another thing in one charm.. just seems odd
[01:54] <ejat> bcoz just now i test it all in one ..
[01:54] <SpamapS> 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] <ejat> already put -y
[01:54] <SpamapS> anyway, I have to go
[01:55]  * SpamapS disappears
[01:55] <ejat> ok ..
[02:05] <adam_g> 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] <hazmat> adam_g, why do you have ambigious relations?
[02:08] <adam_g> hazmat: nova-cloud-controller provides a second interface to nova-compute for nova-network configuration
[02:09] <hazmat> 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] <hazmat> nova-cloud-controller depends on nova-network, nova-volume, nova-compute interfaces
[02:10] <adam_g> 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] <ejat> hazmat: http://paste.ubuntu.com/832144/
[02:12] <adam_g> 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
[02:13] <hazmat> 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] <hazmat> adam_g, with quantum does the network component still have to be installed on the compute nodes?
[02:15] <adam_g> 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
[12:00] <niemeyer> Good mornings!
[15:42] <jcastro> SpamapS: may I G+ you when you're around?
[15:43] <jcastro> I need maybe 10 minutes of feedback from you and then I'll be done. :)
[15:44] <SpamapS> jcastro: server team meetings have me busy from now until 2+ hours from now
[15:44] <jcastro> ok, can I have dibs after?
[15:44] <jcastro> :)
[15:57] <SpamapS> jcastro: you had dibs at hello
[15:57] <SpamapS> jcastro: You had dibs at *HELLO*
[15:57]  * SpamapS breaks down
[15:58] <koolhead17> SpamapS: good morning sir!! :)
[16:05] <mpl> SpamapS: Hello?
[16:05] <mpl> feeling any better now? :)
[16:27] <_mup_> Bug #928348 was filed: Charm bundles should work with symlinks <juju:New> < https://launchpad.net/bugs/928348 >
[16:34] <SpamapS> mpl: hi!
[16:40] <mpl> :-)
[17:34] <hazmat> 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] <hazmat> 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] <jcastro> SpamapS: available yet?
[17:57] <SpamapS> jcastro: meetings over soon
[18:28] <SpamapS> jcastro: t-minus 5 minutes
[18:35] <SpamapS> jcastro: GO
[18:35] <jcastro> SpamapS: hangout firing up
[19:09] <otubo> Hello guys, I was wondering if the 'stop' hook is called when calling 'destroy-environment' command.
[19:09] <otubo> My idea is to backup my data and upload it (to dropbox, for example) before actually destroying the instance.
[20:44] <SpamapS> otubo: Currently stop is never called.
[20:44] <SpamapS> otubo: destroy-environment == rm -rf
[20:44] <SpamapS> otubo: be careful. :)
[21:43] <otubo> SpamapS, roger that! Thanks :-)
[22:26] <hazmat> 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] <SpamapS> oh this is weird
[22:34] <SpamapS> $ juju set jenkins plugins='openid instant-messaging ircbot bazaar'
[22:34] <SpamapS> Expected `option=value`. Found `instant-messaging`
[22:34] <SpamapS> no way to do a space delimited value
[22:35] <hazmat> SpamapS, i think you just need the right escape there
[22:35] <SpamapS> juju set jenkins plugins=openid\ instant-messaging\ ircbot\ bazaar
[22:35] <SpamapS> that doesn't work
[22:36] <SpamapS> I wonder if this is argparse's problem
[22:36] <hazmat> SpamapS, it might be a problem with the parse logic.. i'd try a double qoute..
[22:36] <SpamapS> juju set jenkins "plugins=openid instant-messaging ircbot bazaar"
[22:36] <SpamapS> does not work
[22:37] <SpamapS> sh -c 'juju set jenkins "plugins=openid instant-messaging ircbot bazaar"'
[22:37] <SpamapS> *that* worked
[22:52] <Atlantic777> 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] <Atlantic777> When*
[22:53]  * Atlantic777 has to change keyboard...
[23:12] <m_3> Atlantic777: hey
[23:13] <m_3> Atlantic777: I was using a charm called juju-classroom... it's just a specialization of byobu-classroom
[23:14] <Atlantic777> m_3: a friend of mine wants to start irc classrooms so I find this a useful thing for him. :)
[23:14] <Atlantic777> thanks
[23:15] <m_3> Atlantic777: sure thing
[23:16] <m_3> there're plans to scale this... it's limited by ajaxterm atm
[23:16] <m_3> somethiung like 20 connections at once or so
[23:16] <Atlantic777> m_3: native ssh client is more interesting :D
[23:17] <m_3> yup... that should scale nicely
[23:39] <SpamapS> 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.