| === kadams54 is now known as kadams54-away | ||
| === urulama__ is now known as urulama | ||
| frankban | lazyPower: ping | 10:36 |
|---|---|---|
| lazyPower | frankban: pong | 13:30 |
| frankban | lazyPower: it seems that the services framework doesn't automatically handle setting data on established relations when a relevant config is changed on a service, correct? | 13:32 |
| lazyPower | Ah, I'm not sure. I'm not terribly familiar with the services framework. cory_fu would be a good candidate to answer that question, let me see if i can get him in here | 13:33 |
| frankban | lazyPower: FWIW I am writing a redis charm with the services framework, it would be awesome if you'll be able to take a look at it when it's ready. | 13:33 |
| lazyPower | !! | 13:34 |
| lazyPower | awesome! | 13:34 |
| lazyPower | thanks cory_fu. | 13:34 |
| cory_fu | lazyPower: np | 13:34 |
| lazyPower | repost: <frankban> lazyPower: it seems that the services framework doesn't automatically handle setting data on established relations when a relevant config is changed on a service, correct? | 13:34 |
| cory_fu | frankban: The provide_data method on relations in the provided_data block is called for every hook that is handled by manage(). As long as that function is returning data from hookenv.config() or what-have-you, and the config-changed hook is also handled by manage(), it should reflect changes on established relations | 13:36 |
| frankban | lazyPower: and also FYI, some doc improvements would help there, especially re relation contexts. The redis charm I am working on will support master-slave relations of two services deployed from the same charm: I have a solution but I am not sure if it's idiomatic | 13:36 |
| cory_fu | That said, the provides side of the framework is decidedly lacking polish, for sure. | 13:36 |
| lazyPower | frankban: charms that change behavior on role make sense. we have quite a few of those already | 13:37 |
| frankban | cory_fu: in provide_data relation_set is called only if if re.match(r'{}-relation-(joined|changed)'.format(provider.name), hook_name) | 13:37 |
| cory_fu | One issue is that it happens before the data_ready callbacks are fired, so can't react to changes caused by those callbacks. Another is that it blocks sending data if the data doesn't fulfill the relation class's required_keys. Both of those are bugs | 13:37 |
| cory_fu | frankban: Agh. Yes, you are right. That is also a bug | 13:38 |
| frankban | lazyPower: I know is idiomatic in Juju, I am not sure my implementation is idiomatic in the services framework | 13:38 |
| cory_fu | lazyPower: Personally, I despise that pattern. I feel like it makes the charms more complex and harder to understand, and it makes them more difficult to deploy, since it inherently makes the relations ambiguous 100% of the time | 13:40 |
| frankban | cory_fu: but it also avoids a lot of code duplication between very similar charms | 13:41 |
| lazyPower | cory_fu: i disagree that it makes sense to have 2 charms that duplicate the logic, when all you're doing is updating configuration 80% of the time | 13:41 |
| cory_fu | Obviously, there are some benefits, but my personal opinion is that factoring shared code into a separate, shared library is a better solution. At least, to the cases I've encountered so far. | 13:41 |
| frankban | cory_fu: in my case, for the redis charm, everything is shared, metadata, config, hooks. Establishing a master-slave relation means adding just a single line in the redis conf | 13:42 |
| hatch | what is the services framework? | 13:43 |
| cory_fu | frankban: Fair enough. That is certainly a more extreme case of overlap than what I had encountered | 13:43 |
| frankban | hatch: https://pythonhosted.org/charmhelpers/examples/services.html | 13:43 |
| hatch | frankban: so this allows people to stop using those massive 'hook.py' files | 13:44 |
| hatch | ? | 13:44 |
| frankban | cory_fu: I handle that with the services framweork by defining two services in the manager, both actually pointing to the same init service | 13:44 |
| frankban | hatch: yes, but nothing actually forced people to do that ;-) | 13:45 |
| hatch | reading this closer it almost seems like this services framework encourages putting the hooks all in the same file | 13:46 |
| cory_fu | hatch: The main benefit is that it gives a way to describe more complex cross-dependencies. For example, a service that depends on both a database and a caching service before it can start up can not meaningfully make any decisions based on a single hook invocation. It has to make decisions based on a combination of states. The services framework was the first attempt at addressing that | 13:46 |
| hatch | cory_fu: ahh that's an interesting issue which I haven't yet run into myself | 13:46 |
| lazyPower | right, the reduces a ton of the guard code i've been writing in ansible to achieve the same goal | 13:46 |
| cory_fu | However, the syntax is unwieldy and breaks down in some areas. So bcsaller and I are working on the next approach to the solution, using a more reactive pattern | 13:47 |
| hatch | you use ansible on purpose? :P | 13:47 |
| cory_fu | hatch: There's a fair chance you actually have and didn't realize it. ;) | 13:47 |
| hatch | haha | 13:47 |
| hatch | what do you mean by a more reactive pattern? | 13:47 |
| hatch | can you give me an example? | 13:47 |
| cory_fu | It can actually come up with even a single relation, if there are also config options that influence code paths as well | 13:47 |
| cory_fu | Well, the idea behind the reactive pattern is to talk about things in terms of states that can be triggered and reacted to, instead of just a list of dependencies. | 13:49 |
| cory_fu | The rough example that we've been working from looks about like this: https://gist.github.com/bcsaller/788da7aee582f5dff659 | 13:49 |
| cory_fu | With the relation being handled by something like this: https://gist.github.com/bcsaller/6fb14c5b39b2219aadf9 | 13:50 |
| hatch | ahhh interesting | 13:50 |
| cory_fu | We think that being able to define semantically relevant states (and allow the charms to define their own, for higher-order behavior and dependencies) will allow for more expressive descriptions of what is required to do a given thing | 13:51 |
| hatch | yeah that makes sense from my limited experience | 13:51 |
| cory_fu | It also gets away from having to have a big service description block that the current framework requires, and brings it back down to simpler decorators that people are more familiar with | 13:52 |
| cory_fu | I'm also doing everything I can to make this available via the CLI so that bash (and other language) charms can benefit from it directly, as well | 13:52 |
| cory_fu | For example, in bash, a similar reactive block would look something like this: http://pastebin.ubuntu.com/11245268/ | 13:53 |
| frankban | cory_fu: looks interesting | 13:54 |
| frankban | lazyPower, cory_fu: thanks for your help | 13:54 |
| cory_fu | Or, if you prefer: http://pastebin.ubuntu.com/11245287/ | 13:54 |
| cory_fu | frankban: :) I hope that it pans out as well as we're thinking it will. | 13:55 |
| lazyPower | it was all cory_fu :) | 13:55 |
| frankban | cory_fu: as I mentioned, the documentations lacks a little bit for the relations part, and I also needed to handle the relating-to-self use case, and I ended up reading the code | 13:57 |
| cory_fu | The reactive pattern is also tied tightly in with the idea of relation "stubs," which is basically our approach to codifying interface protocols in actual code that can be used directly by charms, so that charm authors don't have to reimplement the client side of the mysql relation, for example, every time, by looking at the source of the mysql charm | 13:57 |
| frankban | cory_fu: that's a great idea for not reimplementing relations over and over | 13:58 |
| cory_fu | frankban: Yeah, the framework isn't really constructed to support self-relations all that well, but I really need to fix those three issues with the provide_data methods which would help, I think | 13:58 |
| cory_fu | It is a great idea. I wish it had been mine. ;) | 13:58 |
| cory_fu | frankban: Does https://code.launchpad.net/~johnsca/charm-helpers/provide-data-fix/+merge/259630 seem like it will address some of your issues with the framework? | 14:35 |
| frankban | cory_fu: looking | 14:42 |
| frankban | cory_fu: if isinstance(provider, type): perhaps if callable(provider)? | 14:48 |
| cory_fu | Well, providers need to be RelationContext classes, so that they have the .name attribute. Before that change, I think it required that they be instantiated. I might remove that line entirely | 14:49 |
| frankban | cory_fu: also I am not sure about whether remote_service can be useful, given that the service name is arbitrary | 14:50 |
| cory_fu | The idea for that was for things like mysql, that create the database name based on the remote service name | 14:51 |
| frankban | cory_fu: I see | 14:51 |
| frankban | cory_fu: those changes look good | 14:53 |
| frankban | cory_fu: estimated release time? | 14:53 |
| cory_fu | I'm working on getting a review now | 14:54 |
| frankban | cory_fu: great ty! | 14:56 |
| cory_fu | I can't guarantee that it will be merged immediately, but I will keep pushing for it. | 14:57 |
| === kadams54 is now known as kadams54-away | ||
| === kadams54 is now known as kadams54-away | ||
| === kadams54 is now known as kadams54-away | ||
| === kadams54-away is now known as kadams54 | ||
| === kadams54 is now known as kadams54-away | ||
| === kadams54-away is now known as kadams54 | ||
| === kadams54 is now known as kadams54-away | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!