| george_e | SpamapS: Can I put another script in the hooks folder that isn't actually a hook script? | 01:24 |
|---|---|---|
| george_e | I want to reuse some code between hooks. | 01:24 |
| james_w | george_e, you can | 01:56 |
| james_w | your hooks are executed with the PWD being the root of your branch | 01:57 |
| james_w | so you can load the code with | 01:57 |
| james_w | . ./hooks/shared | 01:57 |
| james_w | (assuming you are using shell) | 01:57 |
| george_e | james_w: Okay, thanks. | 02:30 |
| fwereade | hazmat: ONLY if this is an easy question you already know the answer to without hunting through the source (I can do that myself if necessary...): | 12:19 |
| fwereade | hazmat: what nodes are created by the unit agent? | 12:20 |
| hazmat | fwereade, its presence node its relation settings and presence nodes | 13:57 |
| fwereade | hazmat, cheers | 14:10 |
| fwereade | hazmat, I'll double-check which of those could have barfed a NodeExists at me, but haven't managed to repro it, so not to worry :) | 14:11 |
| hazmat | fwereade, i've got a branch which pushes the path into the exception of txzk.. i haven't felt a 100% comfortable with it.. but its useful for debugging these sorts of things | 14:20 |
| hazmat | fwereade, its https://code.launchpad.net/~hazmat/txzookeeper/errors-with-path/+merge/77254 | 14:20 |
| fwereade | hazmat, thanks, that's awesome; I'll grab it if I screw things up in the same way again :) | 14:21 |
| jcastro | m_3: thinkup charm needs another round o' review | 15:29 |
| hazmat | m_3, thanks again for setting up the reconnoiter ppa | 15:31 |
| fwereade | hazmat, I appear to be unable to recreate the unit agent presence node when the unit was previously "kill -9"ed (NodeExistsException, despite the fact that it was created ephemeral) | 15:40 |
| fwereade | hazmat, please confirm that I am smoking crack | 15:40 |
| hazmat | fwereade, the session is still alive | 15:41 |
| hazmat | fwereade, the agent need to store their session id, and reconnect with that only creating a new session if the previous is expired | 15:41 |
| fwereade | hazmat, awesome, the universe still works, I'm just ignorant | 15:42 |
| * fwereade sighs with relief | 15:42 | |
| hazmat | fwereade, we all gotta start somewhere.. for example if you put a sleep(10) in there it would just work ;-) | 15:42 |
| hazmat | fwereade, so i'd setup the base agent to store the client_id after connect to file on disk, and utilize that path if it exists when connecting for the session id | 15:43 |
| hazmat | if it doesn't work (sessionexpired) just reconnect sans the id | 15:43 |
| fwereade | hazmat, cool, on the plus side the unit agent does appear to work if it's killed normally :) | 15:43 |
| hazmat | fwereade, nice | 15:43 |
| hazmat | fwereade, yeah.. i was going through the workflow api.. you had it right.. transition_state is optimistic, fire_transition was pessimisitc | 15:44 |
| fwereade | hazmat, cool, that bit is changing a little in the current work anyway | 15:44 |
| hazmat | fwereade, what's current? which branch is this? | 15:44 |
| hazmat | fwereade, ie. are these changes to what's in the queue? | 15:45 |
| fwereade | hazmat, it's work on top of it, I probably should have written a bug for it | 15:45 |
| hazmat | fwereade, no worries, lbox makes us lazy ;-) | 15:45 |
| fwereade | hazmat, it's the distinction between "uses upstart" and "actually works properly in certain circumstances" | 15:46 |
| hazmat | fwereade, cool, i'm going to delay the session expiration work to build on the upstart stuff your doing, else we have to introduce additional primitives regarding stop/restart doing hook execution, vs stopping activity | 15:47 |
| fwereade | hazmat, yeah, figuring out just what should happen if we suddenly die mid-hook is beyond my understanding at the moment | 15:47 |
| hazmat | just doing a suicide on expiration seems like it would be easier than introducing additional paths for stop 'only activity' | 15:47 |
| fwereade | hazmat, that sounds good though | 15:48 |
| hazmat | fwereade, that's fine, when we save the queue state to disk, it should re-execute the hook | 15:48 |
| hazmat | fwereade, we're going for the at least once guarantee | 15:48 |
| fwereade | hazmat, cool | 15:48 |
| hazmat | instead of the at most once | 15:48 |
| hazmat | the latter has the potent to miss an exec | 15:49 |
| * hazmat grabs some coffee | 15:49 | |
| marcoceppi | Hey guys, any idea on this: http://askubuntu.com/questions/82632/juju-bootstrap-problem | 15:59 |
| hazmat | marcoceppi, in process on answering it now | 16:22 |
| hazmat | marcoceppi, hmm.. actually that's not what i thought it was | 16:25 |
| marcoceppi | Anything I can ask him to get more info> | 16:25 |
| hazmat | marcoceppi, not sure, i posted something, it looks like he might have another dns server on that machine | 16:28 |
| hazmat | perhaps a local caching proxy | 16:28 |
| marcoceppi | ah, thanks hazmat | 16:28 |
| hazmat | marcoceppi, i thought i'd setup a subscription to juju questions, but i don't every seem to get notified about new questions | 16:29 |
| marcoceppi | hazmat How did you subscribe? | 16:30 |
| hazmat | marcoceppi, via the web on the tag | 16:30 |
| marcoceppi | Ah, that only highlights questions in the main feed, IIRC | 16:30 |
| marcoceppi | hum, maybe not. | 16:31 |
| hazmat | marcoceppi, i don't get it.. it doesn't notify me of all new questions w/ the tag.. that question is in the rss feed | 16:31 |
| hazmat | marcoceppi, hmm.. seems like there are multiple interfaces for subscription management.. | 16:32 |
| hazmat | trying out the stackexchange one from my profile now | 16:33 |
| marcoceppi | hazmat Check out your profile's email preferences, make sure the checkbox to receive emails is selected. http://askubuntu.com/users/preferences/28532 | 16:33 |
| marcoceppi | It doesn't appear you do. Kind of seems like a bug. | 16:33 |
| marcoceppi | You can also change the frequency of emails. It defaults to a daily digest, IIRC | 16:34 |
| hazmat | marcoceppi, that seems to me the trick thanks | 16:35 |
| hazmat | s/me/be | 16:35 |
| marcoceppi | np | 16:35 |
| amithkk | Nice cozy juju room :) Hi guys | 16:49 |
| hazmat | amithkk, greetings | 16:52 |
| amithkk | hi hazmat | 16:53 |
| hazmat | bcsaller, jimbaker you guys in today? | 16:59 |
| * SpamapS tosses amithkk a beverage | 17:03 | |
| SpamapS | welcome! | 17:03 |
| hazmat | fwereade, up for a standup? | 17:03 |
| hazmat | bcsaller, jimbaker, fwereade invites out.. low attendance expected ;-) | 17:03 |
| amithkk | hi | 17:03 |
| fwereade | hazmat, ah yeah | 17:04 |
| * amithkk drinks beverage | 17:04 | |
| * SpamapS cries out "NO WAIT!" | 17:07 | |
| mainerror | What is a standup? | 17:15 |
| hazmat | mainerror, its a very short meeting | 17:17 |
| mainerror | I see. | 17:17 |
| hazmat | mainerror, we just do a quick roundtable on dev tasks | 17:17 |
| hazmat | less than 5m | 17:18 |
| hazmat | mainerror, http://en.wikipedia.org/wiki/Stand-up_meeting | 17:18 |
| m_3 | looks like the latest charm-tools package has a broken link... I'll try it on another machine to verify | 17:23 |
| hazmat | m_3, is that reconnoiter ppa a daily build recipe attached to the imported branch? | 17:29 |
| hazmat | m_3, looking at the imported branch recipes.. i just see https://code.launchpad.net/reconnoiter/+recipes | 17:29 |
| m_3 | SpamapS: but if he knew that you knew that he knew which vial was poisoned... | 17:30 |
| m_3 | no, I didn't use the recipe, just built the daily from the other day | 17:30 |
| m_3 | hazmat: ^ | 17:30 |
| m_3 | hazmat: figured if it worked, then we could use the recipe to do a daily build. I had to update debian/control to add deps to get it to build, so we'll have to add that to the recipe | 17:32 |
| fwereade | happy weekends all :) | 17:32 |
| hazmat | fwereade, cheers, have a good one | 17:32 |
| m_3 | fwereade: you too | 17:32 |
| hazmat | m_3, cool we should probably send a control diff upstream as well, it was just the protobuf dep? | 17:33 |
| m_3 | yup | 17:33 |
| hazmat | m_3, cool | 17:33 |
| * hazmat lunches | 17:33 | |
| jcastro | hazmat: bout how much longer after a charm is accepted does it take to show up in your charm browser thing? | 18:23 |
| hazmat | jcastro, 15m after its pushed to lp | 18:23 |
| hazmat | jcastro, it won't appear if the charm has structural errors | 18:24 |
| hazmat | jcastro, which one where you thinking of? | 18:24 |
| jcastro | thinkup | 18:24 |
| hazmat | jcastro, thinkup is there already | 18:24 |
| jcastro | ROCK. | 18:24 |
| hazmat | jcastro, its in a ppa, so you need to find via search | 18:24 |
| hazmat | unless its in the official distrib | 18:24 |
| hazmat | http://charms.kapilt.com/~george-edison55/oneiric/thinkup | 18:25 |
| jcastro | right so in the bug report mmims +1'ed it, I guess the next step is to 'promote' it or whatever we do? | 18:25 |
| jcastro | but then he found a bug in the charm tool or something | 18:25 |
| hazmat | jcastro, yup | 18:25 |
| hazmat | jcastro, per the spec its actually posisble for a ppa charm to be the official one, but the charm browser and practice seems to be moving it to ~charmers ownership | 18:26 |
| jcastro | oh ok, so basically we move it | 18:29 |
| jcastro | and then tell him to just propose fixes from then on? | 18:29 |
| marcoceppi | it needs to be promogulated, right? | 18:31 |
| rog | can we rely on the fact that we've always got cloud-init? or can that be provider-dependent? | 18:31 |
| marcoceppi | promulgated* | 18:32 |
| rog | hazmat: ^ | 18:32 |
| hazmat | rog, we use cloud-init everywhere but local provider | 18:32 |
| hazmat | rog, bcsaller and i debated using it there, but opted to pass on it to keep local fast | 18:33 |
| jcastro | we suck for naming it "promulgate" by the way, when "charm bless" or "charm sugar" would have been awesomer. | 18:33 |
| hazmat | jcastro, or just give him r/w access to it | 18:33 |
| hazmat | marcoceppi, i think m_3 and SpamapS know the procedure.. i'd have to look it up | 18:34 |
| rog | hazmat: darn. ok, thanks. | 18:34 |
| marcoceppi | hazmat: I've done it once before if they're pre-occupied | 18:34 |
| hazmat | rog, why? whats up? | 18:34 |
| m_3 | yeah, I can promulgate... just chasing down what's wrong with charm-tools | 18:34 |
| hazmat | rog, its generally a pretty reasonable assumption | 18:34 |
| hazmat | m_3, need another set of eyes? | 18:34 |
| rog | hazmat: just wondering what code can be factored out of providers | 18:34 |
| m_3 | also didn't know if acceptance meant it should be promulgated to lp:charm or stay in a ppa | 18:35 |
| rog | hazmat: in Go the decision has to be a bit more clear-cut than in python. | 18:35 |
| hazmat | rog, well the cloud init stuff is factored out of the provider implementations, individual provider implementations will by default get a common impl of the provider that uses cloud-init | 18:35 |
| jcastro | m_3: what's the difference from the deployment point of view of where the charm is? | 18:35 |
| m_3 | hazmat: I'm still trying to figure out how the packaging process works for charm-tools... the latest version just isn't installing enough stuff | 18:35 |
| jcastro | m_3: either way I need to charm get right? | 18:36 |
| rog | hazmat: yeah, i saw that, but hadn't seen that local didn't use the common implementation | 18:36 |
| hazmat | jcastro, yeah.. charms are always fetched locally, even with a store | 18:36 |
| m_3 | jcastro: yeah, it'll just be a different url | 18:36 |
| hazmat | er. deployed from local | 18:36 |
| jcastro | ok so from the end user perspective, they don't need to do anything different? | 18:36 |
| hazmat | the store just automates the fetch to local and deploy to env | 18:36 |
| jcastro | in other words, is this our problem or a user-visible problem? | 18:36 |
| hazmat | rog, it does use the base class, it just overrides that behavior | 18:37 |
| hazmat | by implementing its own start machine method | 18:37 |
| m_3 | jcastro: so that's the difference... right now 'charm get thinkup' says it doesn't exist in the official charm store | 18:37 |
| hazmat | rog, the local provider is a bit of abberation in several respects, besides the lack of cloud-init, there is no provisioning agent | 18:37 |
| m_3 | so I'll promulgate it | 18:37 |
| hazmat | rog, in the local provider case there is only one machine the host | 18:38 |
| hazmat | so cloud init never runs, we treat the containers as containers instead of machines | 18:38 |
| hazmat | the notion being that if where a new machine, we would indeed run cloud-init | 18:38 |
| rog | hazmat: yeah, it's an exception that seems like to be making things a bit harder, cos it makes everything less regular | 18:39 |
| hazmat | rog, it is actually pretty regular the delta is that its an environment with exactly one machine | 18:39 |
| rog | hazmat: it's things like no provisioning agent, etc | 18:40 |
| hazmat | rog, and that we have multiple units with isolation on it.. the original impl that SpamapS did had modeled containers as machines | 18:40 |
| hazmat | rog, there is only one machine in the env, so what does the provisioning agent do? | 18:40 |
| rog | hazmat: was that too slow? | 18:40 |
| hazmat | rog, no just that niemeyer didn't like the model that way | 18:40 |
| rog | hazmat: i'd model containers as machines... | 18:40 |
| rog | hazmat: fair enough | 18:40 |
| hazmat | rog, there was a long discussion on list about this | 18:40 |
| hazmat | rog, the problems with networking still haven't been addressed unfortunately | 18:41 |
| rog | hazmat: depends how you think of the local provider, i guess - as a test for the system, or as a thing to do useful work with | 18:41 |
| hazmat | wrt to pushing lxc everywhere | 18:41 |
| hazmat | rog, the goal of getting lxc everywhere is better served by the current impl (machines deploying units in containers), but lacking an appros solution for the networking, its a bit moot | 18:42 |
| rog | for LXC everywhere, i guess it'd make sense to treat containers as machines and have a provider on every real machine | 18:42 |
| hazmat | rog, not really | 18:42 |
| hazmat | rog, providers model real billable resources, container ares not | 18:42 |
| hazmat | s/ares/are | 18:42 |
| rog | oops | 18:42 |
| rog | i didn't mean provider, i meant provisioning agent | 18:43 |
| rog | totally different thing | 18:43 |
| hazmat | rog, same thing, providers are actualized by a provisioning agent | 18:43 |
| hazmat | there is no provider api for creating a container, the provider is abstraction to external resource interaction | 18:43 |
| rog | interesting. | 18:44 |
| hazmat | for the provisioning of compute resources, lxc are are just logical subdivisions of those resources imposed by juju for units | 18:44 |
| rog | if there *was* a provider api for creating a container, might that make things easier? | 18:44 |
| rog | because then creating a container would be very similar to allocating a new machine | 18:45 |
| rog | once you've got multiple levels of provider, spanning across multiple billable providers might become easier. but i'm speaking off the top of my head here, obviously :-) | 18:46 |
| rog | hazmat: what are the problems with the networking, BTW? | 18:47 |
| hazmat | rog, i don't think a container provider api helps at all, its a different level of the conceptual stack | 18:47 |
| hazmat | rog, your trying to posit the provider agent living on every machine.. why thats what the machine agent is there for | 18:48 |
| hazmat | rog, the networking problem is what i outlined on the mailing list, namely that because we're using dynamic port allocation for units, which itself is a less than 0.1% problem, instead of static port allocation in metadata, we lose the ability at deploy time to determine conflict/optimal placement of units when machines have multiple units | 18:49 |
| marcoceppi | What is the "peers" metadata config section for? | 18:49 |
| rog | i guess in the end, it doesn't matter what agent does provisioning, just as long as it follows the right zk state | 18:49 |
| hazmat | meaning that we can never have more than one unit on a machine without a soft network overlay | 18:50 |
| hazmat | marcoceppi, its for a special type of relation used to talk within a service among its service units.. like cassandra, or riak, mongodb replica set.. | 18:50 |
| hazmat | the units of those services need to be aware of the other members of the service and to talk to them, for things like setting up token rings for sharding or replication, or leader election | 18:51 |
| hazmat | rog, indeed | 18:51 |
| marcoceppi | hazmat: Cool, thanks | 18:51 |
| rog | hazmat: i wondered about peer relations as well. how exactly do they differ from provides/requires relations? | 18:52 |
| hazmat | rog, provides/requires are to model client/server relations across services, peers model intra service relations | 18:52 |
| hazmat | inter vs intra service relations.. for the one liner ;-) | 18:53 |
| rog | hazmat: so a peer relation is always established? | 18:53 |
| hazmat | rog, it is, but that's a convenience of the deploy cli impl, the rel impl is the same at the declaration and actualization layer as a client/server.. the main impl difference is in the watch mechanism feeding into hook execution | 18:55 |
| rog | hazmat: is hook execution any different for peer relations? | 18:57 |
| hazmat | rog, no | 18:57 |
| hazmat | rog, the structural layout of the relation is slightly different leading to slightly different related unit watching, instead of watching the units of the opposite end's service, it watches the units of the same service.. that feeds into a hook scheduler, which queues hook exec, the actual hook impl/semantics are the same | 18:59 |
| rog | hazmat: thanks | 19:00 |
| hazmat | i think i wrote most of that in a mad crazy code cycle this time last year | 19:01 |
| rog | hazmat: it's all in the machine agent, presumably | 19:03 |
| hazmat | rog, not at all | 19:03 |
| hazmat | rog, the machine agent has no responsibilities outside of deploying units | 19:03 |
| hazmat | and removing them if unassigned from the machine | 19:03 |
| rog | hazmat: ah, i thought the machine agent executed hooks | 19:03 |
| hazmat | rog, the unit agent does all unit management | 19:04 |
| hazmat | rog, most of this is abstracted into a unit workflow/lifecycle that the unit agent just starts | 19:04 |
| rog | hazmat: so it does, i've just seen | 19:04 |
| rog | hazmat: hmm, so... is there one machine agent per machine? | 19:05 |
| hazmat | rog, yes | 19:05 |
| rog | hazmat: but currently a machine maps exactly one to one with a unit, right? so what does the machine agent actually do? | 19:05 |
| * rog should just go and read the damn code! | 19:05 | |
| rog | ok, yes, it doesn't do much | 19:06 |
| hazmat | rog, none of the agents do very much, they activate semantic logic protocols in their process, but the agent code is always pretty minimal | 19:07 |
| hazmat | rog, the provisioning agent has been an exception to that, but not for long (expose-refactor pushes the firewall stuff out) | 19:08 |
| hazmat | rog, at the risk of repeat myself... machine agents only manage unit deployments | 19:09 |
| hazmat | their not one to one with a local provider | 19:10 |
| hazmat | their only one to one elsewhere due to the network issues as above, either a soft overlay network or static ports would resolve that | 19:11 |
| rog | i'd vote for static ports, otherwise you get addressing issues. | 19:11 |
| hazmat | yeah.. me too | 19:12 |
| hazmat | encapsulating units into lxc everywhere also solves the issue of the charm scribbling on a machine's root fs which makes machine reuse problematic | 19:12 |
| rog | gotta go | 19:13 |
| rog | thanks for the discussion | 19:13 |
| hazmat | rog, cheers have a good weekend | 19:13 |
| rog | and you | 19:13 |
| jcastro | james_w: fyi, your graphite and txstatsd charms got an initial review | 19:13 |
| james_w | yeah, thanks | 19:19 |
| james_w | important fixes needed, I just need to find the time now | 19:20 |
| jcastro | m_3: AWWW YEAH | 20:21 |
| jcastro | thinkup is working | 20:21 |
| jcastro | http://pad.ubuntu.com/thinkup | 20:21 |
| jcastro | are the commands I used. | 20:21 |
| m_3 | jcastro: phpmyadmin is reported as blocked BTW | 20:28 |
| m_3 | awesome!! | 20:28 |
| m_3 | ^ re: thinkup | 20:28 |
| jcastro | http://cloud.ubuntu.com/2011/11/deploying-thinkup-to-the-cloud-with-juju/ | 21:05 |
| m_3 | jcastro: gotta do a charm get mysql too | 21:22 |
| m_3 | (in the article you reference above) | 21:24 |
| jcastro | whoops! | 21:27 |
| SpamapS | charm-tools should be fixed shortly btw | 21:55 |
| m_3 | SpamapS: thanks! | 22:00 |
| marcoceppi | SpamapS I hope it wasn't anything I did | 22:16 |
| SpamapS | no | 22:16 |
| SpamapS | definitely me | 22:16 |
| SpamapS | rushing things before throwing the turkey in the oven yesterday ;) | 22:16 |
| SpamapS | can you guys try updating charm-tools on 11.10? | 22:19 |
| SpamapS | m_3: ^^ | 22:23 |
| SpamapS | marcoceppi: ^^ | 22:23 |
| marcoceppi | Has it been packaged? | 22:23 |
| SpamapS | it just updated | 22:24 |
| * marcoceppi wishes he can edit messages in IRC | 22:24 | |
| SpamapS | the PPA claims it is published | 22:24 |
| marcoceppi | Looks like it: 0.2+bzr85-4~oneiric1 | 22:24 |
| m_3 | SpamapS: will check now | 22:27 |
| m_3 | SpamapS: look fine | 22:30 |
| SpamapS | m_3: cool. thanks for the heads up | 22:31 |
| m_3 | thanks for not making me learn about recipes tonight :) | 22:31 |
| marcoceppi | What are the restrictions of names for charms? Just alphas? | 23:10 |
| hazmat | marcoceppi, alpha num not leading alpha, and '-' | 23:17 |
| hazmat | er. leading alpha | 23:17 |
| marcoceppi | thanks | 23:31 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!