| === asavu_ is now known as asavu | ||
| === grapz is now known as grapz_afk | ||
| === grapz_afk is now known as grapz | ||
| koolhead11 | hi all | 13:46 |
|---|---|---|
| _mup_ | juju/robust-test-removed-service-unit r457 committed by jim.baker@canonical.com | 18:57 |
| _mup_ | Fix test in use of watch so it doesn't assume that it will see all changes to a ZK node (because it won't) | 18:57 |
| === hspencer is now known as hspencer[lunch] | ||
| _mup_ | juju/increase-session-timeout r448 committed by kapil.thangavelu@canonical.com | 20:49 |
| _mup_ | allow managed zk to specify longer timeout | 20:49 |
| === robbiew1 is now known as robbiew | ||
| hazmat | adam_g, ping | 21:34 |
| === hspencer[lunch] is now known as hspencer | ||
| adam_g | hazmat: pong | 21:50 |
| hazmat | hi adam_g i was playing around with deploying dependencies to create automated tests that can verify relations, and smoser pointed out that for openstack there is a required ordering to make it work.. i was just curious about some of the details, the sample test plan i have for nova-compute is.. http://paste.ubuntu.com/831927/ | 21:52 |
| hazmat | also i wanted to talk about the dependencies for the swift charm, it seemed strange to me that swift-storage both requires and provides swift, seems like it was intended that it provides 'swift', and the proxy requires it. | 21:53 |
| adam_g | hazmat: sure, one sec | 21:54 |
| adam_g | hazmat: so, wrt ordering.. service like nova-volume and nova-compute are basically useless without functioning [nova-cloud-controller, rabbitmq, mysql]. all the nova-* components require access to the database and rabbit queue | 21:58 |
| SpamapS | hazmat: this goes back to what I said, which is that relations shouldn't actually be established until all of a service's required relations are established | 22:00 |
| adam_g | hazmat: for nova's authentication to work, the nova-api server (part of nova-cloud-controller) needs a relation to the keystone service.. which, ideally, has a relation to a database. its possible to not use an external database and store in a local sqlite database, but if a new data store is introduced through a new relation, all existing auth + service entries need to be migrated to the new db. | 22:00 |
| hazmat | SpamapS, it goes beyond that, its assuming a global ordering to the required relation establishment. | 22:01 |
| adam_g | hazmat: nova-compute + cloud-controller then need another relation to the glance service in order for images to function. glance also requires a database and a keystone relation | 22:01 |
| hazmat | adam_g, so it sounds like, what SpamapS said, if all the required relations for a service are deployed for a service then its provided interfaces can have relations established | 22:04 |
| hazmat | ie. it doesn't need a particular ordering of dependency established, ie. add rabbitmq before keystone or mysql for nova-compute | 22:05 |
| adam_g | hmm | 22:06 |
| adam_g | (looking thru charms) | 22:07 |
| adam_g | hazmat: so, deploy keystone, nova-*, glance. for each, satisfy required relations. once each components required relations are established, add relations between each depending on what is provided. ? | 22:12 |
| hazmat | adam_g, yeah | 22:13 |
| adam_g | hazmat: is it an issue that keystone is a required relatin of both nova-* and glance? it may end up that things do adhere to some global order depending on what interfaces exist, even if its not defined explicitly | 22:19 |
| hazmat | adam_g, that's fine re keystone | 22:23 |
| adam_g | hazmat: fwiw, this is what a deployment looks like currently, in terms of ideal ordering: http://paste.ubuntu.com/831987/ | 22:23 |
| koolhead17 | m_3: hello there | 22:27 |
| adam_g | hazmat: about swift. yea, you're right. the interfaces are poorly / incorrectly named. that charm is a bit dated and ive got work items this cycle to rewrite it. for now, i can propose an update along the lines of: swift-proxy provides proxy:swift-proxy, swift-storage provides storage-ring:swift-storage | 22:41 |
| hazmat | adam_g, that sounds good | 22:42 |
| adam_g | hazmat: i'll also propose merging those changes to interfaces we talked about last week. i had gotten distracted and forgot about that, sorry | 22:49 |
| hazmat | adam_g, thanks | 23:01 |
| hazmat | adam_g, fwiw, here's what i get for an automated ordered relation list http://paste.ubuntu.com/832017/ | 23:02 |
| hazmat | for nova-compute | 23:02 |
| * koolhead17 scratching his head to try this whole OS charms!! :P | 23:03 | |
| adam_g | hazmat: is this the oneiric charms? | 23:16 |
| SpamapS | hazmat: That looks awfully close to "establish required relations before provided relations start working" | 23:18 |
| SpamapS | hazmat: I don't think you have to assume global ordering. Juju can simply see that nova-cloud-controller isn't ready to start providing things until the requires: are satisfied.. so it would do nothing with the relations established to its provide side, until the requires side is done. | 23:20 |
| SpamapS | hazmat: the problem there is that the relations have no way of saying "I am established" | 23:20 |
| ejat | hi, is there a way to generate admin-secret & control-bucket | 23:27 |
| ejat | for environments | 23:27 |
| jimbaker | SpamapS, i don't understand that statement, isn't that the point of relation settings to say stuff like that? | 23:30 |
| hazmat | SpamapS, your right it is just establish required first, i was concerned it might be more than that, wrt to relation established just identifying a steady state for a timeout wrt to status changes for the rel should suffice | 23:31 |
| SpamapS | hazmat: I suppose steady state is achieved if all hooks exit 0 w/o relation-set | 23:34 |
| SpamapS | jimbaker: relation settings are for the other side of the relation. They're meaningless to juju itself. | 23:34 |
| SpamapS | hazmat: Actually, this could work. | 23:35 |
| jimbaker | SpamapS, agreed on their meaning to juju. i guess the problem here is you want more explicit support from juju on relations being established | 23:38 |
| hazmat | SpamapS have you seen smoser's deployer script, i'm thinking about just feeding these plans into that | 23:38 |
| hazmat | http://bazaar.launchpad.net/~smoser/+junk/juju-deployer-concurrent/view/head:/deployments.cfg.jstack | 23:38 |
| jimbaker | stacks, nice :) | 23:39 |
| hazmat | jimbaker, SpamapS we can add a helper script to juju-tools for better external rel inspection and watching | 23:39 |
| jimbaker | hazmat, just for inspection, or also used to control the adding of relations in a stack? | 23:40 |
| adam_g | hazmat: i wrote that script btw, the weight'ing was my naive solution to the issue of 'i need keystone up first before anything else' | 23:41 |
| hazmat | adam_g, oh.. cool, i like it :-) | 23:41 |
| hazmat | jimbaker, just for inspection, but inspection against a rel is a timeout against a steady state of no change, we can either have the timeout on status change or just use the related watch | 23:42 |
| jimbaker | hazmat, ok, such tools at least tell us the real needs here. ideally there would be no need to have the deployment script need to manage having keystone up before it can do anything else | 23:45 |
| adam_g | jimbaker: well, keystone should ideally have a relation to its back end database before taking relations from any services on the interface it provides. | 23:46 |
| jimbaker | adam_g, sure, it just seems that this can be negotiated using relation settings | 23:47 |
| hazmat | jimbaker, agreed, bcsaller's described implementing subordinates that way before.. which gave the properties/effect that deploying things with unfufilled requirements where a noop. | 23:48 |
| jimbaker | hazmat, albeit it seems like an orthogonal concern to subordinates. anyway, real code will give us a better understanding of what's missing in juju, so certainly adam_g's plan sounds good | 23:49 |
| bcsaller | hazmat: well, the service state is still created and appears in status, but no units are allocated and no machine assigned | 23:50 |
| === koolhead17 is now known as koolhead17|zzZZ | ||
| SpamapS | I don't think any drastic change is necessary.. except that people would be confused by nothing happened when required relations aren't established.. | 23:57 |
| SpamapS | Basically right now relations are just watched and acted on, but the unit agent would have to delay acting on provides relations until all required relationships have reached a steady state where all hooks have exitted w/o changing any settings. | 23:57 |
| SpamapS | So there would need to be another state beyond 'up' which would be 'steady' or something like that... and that would be managed by the unit agents on both sides. | 23:58 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!