VCS code duplication and subordinate

[Marco Ceppi]

You wouldn't need to have charm-helpers access relation data. Ideally, if
you wanted the ability to schedule pull/fetch updates you'd create a
ch_vcs_schedule_update function that took parameters and wrote a cron file
to do the matching bzr/git/hg/svn command. Charm Helpers is designed as
just a collection of common functions that can be used between charms, so
you'd still have to write the hooks, which would be pretty straight forward
for the most part, but the actual heavy lifting would just be in the
charm-helpers code.


On Mon, Mar 11, 2013 at 4:02 PM, Sidnei da Silva <
sidnei.da.silva at canonical.com> wrote:

> On Mon, Mar 11, 2013 at 4:49 PM, Clint Byrum <clint at ubuntu.com> wrote:
>
>> Excerpts from Sidnei da Silva's message of 2013-03-11 11:14:52 -0700:
>> > On Mon, Mar 11, 2013 at 3:01 PM, Patrick Hetu <patrick.hetu at gmail.com
>> >wrote:
>> >
>> > > > Sure, but how will it make sure that the service is restarted when
>> new
>> > > content is found?
>> > >
>> > > In the python-django charm I'm using a timestamp variable (an idea
>> > > from someone on IRC) that triggers the reloading of the wsgi server
>> > > when configuration change.
>> > >
>> > > See:
>> > >
>> http://bazaar.launchpad.net/~charmers/charms/precise/python-django/trunk/view/head:/hooks/config-changed#L133
>> > >
>> > > > It's also possible to add this to a standard library of charm tools,
>> > > rather than do it in a subordinate.
>> > >
>> > > I was thinking about one subordinate charm per vcs because I didn't
>> > > wanted to install all vcs
>> > > when I'm just using one of them. But that's a minor issue.
>> > >
>> > > > This might be a good time to mention there's a VCS Charm Helper
>> > >
>> > > Yeah, extending and using those helpers would the solve the
>> > > dependencies problem.
>> > >
>> > > I'm also copying those helpers too in all my new charms to avoid
>> repetition
>> > > and I just realized they are pretty much all in charm-tools. Maybe we
>> > > could split
>> > > the python version of those helpers in a python-charm-tools package an
>> > > make them importable
>> > > python code?
>> > >
>> > >
>> > >
>> http://bazaar.launchpad.net/~charmers/charms/precise/postgresql/trunk/view/head:/hooks/hooks.py
>> > >  (first half of the file)
>> > >
>> > >
>> http://bazaar.launchpad.net/~charmers/charms/precise/postgresql/trunk/view/head:/hooks/helpers.py
>> > >
>> > > Patrick
>> > >
>> >
>> > That would be really helpful. We're collecting some things over at
>> > https://code.launchpad.net/~charmsupport/charmsupport/trunk but it's
>> > currently a chicken-and-egg problem because you need to have
>> charmsupport
>> > installed before it can be used, so as a short-term measure we included
>> a
>> > copy of it when deploying a charm.
>> >
>>
>> This stuff should be in the python charm-helpers. Its already setup to
>> be an importable python library and its quite easy to add via the PPA
>> to any charm.
>>
>> Also, the install hook is for bootstrapping things so that the other
>> hooks can respond to orchestration events. So put uncomplicated straight
>> forward commands to apt-get/pip install in the install hook, and then
>> write the other hooks (like config-changed) with these helpers.
>>
>
> There was some discussion about this at some point, but IIRC the
> conclusion was that charm-helpers should be only for very low-level
> helpers, and not things like relation_get()/relation_set() helper
> functions. If there was some misunderstanding I'm more than happy to push
> for those helpers to land into charm-helpers.
>
> --
> Sidnei
>
> Make the most of Ubuntu with Ubuntu One
> http://one.ubuntu.com
>
> --
> Juju mailing list
> Juju at lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju/attachments/20130311/eec708e0/attachment.html>