VCS code duplication and subordinate

[Gary Poster]

On 03/11/2013 04:48 PM, Clint Byrum wrote:
> Excerpts from Sidnei da Silva's message of 2013-03-11 13:02:13 -0700:
>> 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.
>>
> 
> I don't recall the discussion, and I've not been party to more recent
> discussions.
> 
> The original idea was that charm-tools and charm helper would be for
> anything that we see getting copy/pasted/mimiced between multiple charms.
> 

That was a discussion at the beginning of February that Diogo Baeder
started. There was no conclusion, AFAIK.

I said that the idea of a framework for Python charms didn't seem
appealing to me, because I felt simple functions in the charmhelpers
library were doing well, and the charmsupport package didn't seem to
need a framework either (I haven't looked since).

I also noted that charmsupport had two kinds of code: code that helped
writing charms generically, and code that added specific functionality
(nagios support was one).  The first kind of code was already in
charmhelpers, and we should have more of that there.  The "host.py" file
in charmsupport at the time could have been happily merged with
charmhelpers code.  Sidnei's relation helpers seem like they'd be
entirely in line with what is in the Python charm helpers now (which
includes code to give you a diff of what changed within a config-changed
hook, for instance).  I'd personally be very happy to see this happen.

I'm less sure that nagios support belongs in charmhelpers, at least at
this point, and said so.  I'm happy to be wrong.  That said, it seemed
to me that adding functionality for specific software like nagios would
go in a package that depended on charmhelpers.  I suspect that this
opinion is what Sidnei is referring to when he says that charmhelpers
was supposed to be low-level.

No one replied to my message, in support or rebuttal, and no one else
replied to Diogo, at least if my mail client is to be believed.

Gary