Code review comment for lp:~thedac/charms/precise/postgresql/package-holding

Revision history for this message
David Ames (thedac) wrote :

> On 18 April 2014 22:51, James Troup <email address hidden> wrote:
>
> > So, to be clear this is not about trying to handle upgrades within the
> > charm. What we're trying to do is prevent a Landscape auto-upgrade
> > profile from upgrading postgres and taking down a production service
> > as a result). Landscape will respect package holds, so it seems like
> > (being able to) set package holds within the charm is the logical
> > place to do so.
>
> This makes me wonder if it would be better to add a list of held
> packages to the Landscape subordinate charm where all services can
> make use of it. This would be a little awkward, as it requires the
> operator to specify the primary PostgreSQL package name, whereas the
> PostgreSQL charm knows the package name to hold.
>
> (I'm not blocking on any of this - worst case is we document the
> feature as experimental if we are not sure we want to support it in
> its current form)

So again, this is pretty standard for IS charms (apache, haproxy, canonical-is-charms/postgresql) and we are just trying to bring postgres up to that standard.

I have

Check pagack_state with validate_config
Moved ensure_package_status to update_repos_and_packages()
Handled when postgres is not yet installed

Please take another look

« Back to merge proposal