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:00 |
jimbaker | convention | 00:01 |
SpamapS | that seems to violate the encapsulation that is around relation settings right now | 00:01 |
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:02 |
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:03 |
SpamapS | jimbaker: they're *too* powerful | 00:04 |
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:05 |
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:06 |
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:07 |
jimbaker | other than whatever interface two services agree upon, without juju making any special assumptions about that | 00:08 |
SpamapS | right so I think we're talking past eachother then | 00:09 |
jimbaker | SpamapS, no worries. i'm sure it will be clearer with some good code examples | 00:10 |
jimbaker | and we should definitely put this api change out there for juju status and 'steady' | 00:11 |
jimbaker | and see if that's something that can be done or not | 00:12 |
SpamapS | I don't necessarily think it has to be an API change at first | 00:13 |
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:14 |
jimbaker | SpamapS, changing the unit lifecycles is an api change, even if it's pretty trivial as above | 00:16 |
SpamapS | jimbaker: aye | 00:17 |
adam_g | hazmat: still around? | 01:00 |
hazmat | adam_g, yup | 01:11 |
SpamapS | going through the steady state idea in my head.. I think its doable.. but would break ZK backward compatibility | 01:13 |
SpamapS | since you'd need a new state for unit relations | 01:14 |
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:17 |
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:18 |
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:19 |
SpamapS | ejat: you forgot 'local:' | 01:20 |
ejat | if i want to try at ec2 ? | 01:20 |
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:21 |
ejat | SpamapS: owh okie | 01:22 |
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:23 |
hazmat | adam_g, the ambiguity was that both 'nova-cloud-controller' and 'nova-volume' provide the 'nova' interface | 01:24 |
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:25 |
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:26 |
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:27 |
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:28 |
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:29 |
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:30 |
adam_g | ok i think we're on the same page now :) | 01:31 |
hazmat | cool | 01:31 |
ejat | apache not start ? | 01:31 |
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:33 |
ejat | thanks .. forget -y :) | 01:35 |
ejat | brb .. | 01:35 |
ejat | fixing it .. | 01:35 |
hazmat | SpamapS, no need for the additional relation, just trying to unambigiously identify the dependencies for a charm | 01:42 |
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:43 |
ejat | SpamapS: http://paste.ubuntu.com/832120/ | 01:47 |
ejat | which charm sample should i refer | 01:47 |
ejat | for the mysql thingss | 01:47 |
SpamapS | ejat: there is already a mysql charm. Why are you deploying mysql? | 01:52 |
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:53 |
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:54 |
* SpamapS disappears | 01:55 | |
ejat | ok .. | 01:55 |
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:05 |
hazmat | adam_g, why do you have ambigious relations? | 02:06 |
adam_g | hazmat: nova-cloud-controller provides a second interface to nova-compute for nova-network configuration | 02:08 |
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:09 |
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:10 |
ejat | hazmat: http://paste.ubuntu.com/832144/ | 02:11 |
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:12 |
=== hspencer is now known as hspencer[afk] | ||
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:13 |
hazmat | adam_g, with quantum does the network component still have to be installed on the compute nodes? | 02:14 |
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 | 02:15 |
=== hspencer[afk] is now known as hspencer | ||
=== asavu_ is now known as asavu | ||
niemeyer | Good mornings! | 12:00 |
jcastro | SpamapS: may I G+ you when you're around? | 15:42 |
jcastro | I need maybe 10 minutes of feedback from you and then I'll be done. :) | 15:43 |
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:44 |
SpamapS | jcastro: you had dibs at hello | 15:57 |
SpamapS | jcastro: You had dibs at *HELLO* | 15:57 |
* SpamapS breaks down | 15:57 | |
koolhead17 | SpamapS: good morning sir!! :) | 15:58 |
mpl | SpamapS: Hello? | 16:05 |
mpl | feeling any better now? :) | 16:05 |
_mup_ | Bug #928348 was filed: Charm bundles should work with symlinks <juju:New> < https://launchpad.net/bugs/928348 > | 16:27 |
SpamapS | mpl: hi! | 16:34 |
mpl | :-) | 16:40 |
=== hspencer is now known as hspencer[mtg] | ||
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:34 |
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:38 |
jcastro | SpamapS: available yet? | 17:56 |
SpamapS | jcastro: meetings over soon | 17:57 |
SpamapS | jcastro: t-minus 5 minutes | 18:28 |
=== hspencer[mtg] is now known as hspencer | ||
SpamapS | jcastro: GO | 18:35 |
jcastro | SpamapS: hangout firing up | 18:35 |
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. | 19:09 |
SpamapS | otubo: Currently stop is never called. | 20:44 |
SpamapS | otubo: destroy-environment == rm -rf | 20:44 |
SpamapS | otubo: be careful. :) | 20:44 |
otubo | SpamapS, roger that! Thanks :-) | 21:43 |
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:26 |
SpamapS | oh this is weird | 22:33 |
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:34 |
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:35 |
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:36 |
SpamapS | sh -c 'juju set jenkins "plugins=openid instant-messaging ircbot bazaar"' | 22:37 |
SpamapS | *that* worked | 22:37 |
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:52 |
* Atlantic777 has to change keyboard... | 22:53 | |
m_3 | Atlantic777: hey | 23:12 |
m_3 | Atlantic777: I was using a charm called juju-classroom... it's just a specialization of byobu-classroom | 23:13 |
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:14 |
m_3 | Atlantic777: sure thing | 23:15 |
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:16 |
m_3 | yup... that should scale nicely | 23:17 |
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. | 23:39 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!