VCS code duplication and subordinate

Tue Mar 12 13:34:03 UTC 2013

On Tue, Mar 12, 2013 at 10:24 AM, Gary Poster <gary.poster at canonical.com>wrote:

> 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.
>

Seems like there was some miscommunication indeed. Thanks for clarifying
Gary.

Personally I think the nagios support could happily live in charmhelpers.
"If it's not monitored, it's not in production" [1] :)

[1]
http://agiletesting.blogspot.com.br/2012/08/10-things-to-know-when-starting-out-as.html

-- 
Sidnei

Make the most of Ubuntu with Ubuntu One
http://one.ubuntu.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju/attachments/20130312/ffa98db1/attachment.html>