[katello-devel] Katello upgrade redesign

[Tom McKay]

----- Original Message -----
> From: "Ivan Nečas" <inecas at redhat.com>
> To: katello-devel at redhat.com
> Sent: Friday, October 26, 2012 9:16:36 AM
> Subject: Re: [katello-devel] Katello upgrade redesign
> 
> On 10/26/2012 03:07 PM, Bryan Kearney wrote:
> > On 10/26/2012 06:05 AM, Lukas Zapletal wrote:
> >> Hello,
> >>
> >> working on https://bugzilla.redhat.com/show_bug.cgi?id=868916 , I
> >> found we
> >> have some bugs and also design issues with katello upgrade.
> >>
> >> The current design is simple, we have two kinds of upgrade scripts
> >> which
> >> are in two directories.
> >>
> >> /usr/share/katello/install/upgrade-scripts/default/*
> >>
> >> and
> >>
> >> /usr/share/katello/install/upgrade-scripts/upgrade/*
> >>
> >> Katello-upgrade first shuts downs all the services and then starts
> >> upgrading by calling upgrade scripts in this order: default,
> >> upgrade.
> >> Default scripts are executed every katello-upgrade call, while
> >> upgrade
> >> scripts are only executed once (and then katello-upgrade "marks"
> >> them in
> >> the /var/lib/katello/upgrade-history file (just a list of files
> >> which
> >> have been already executed).
> >>
> >> Default scripts (executed every time) are:
> >>
> >> 0002_update_pulp.sh
> >>   - starts mongod
> >>   - does pulp-migrate
> >> 0003_update_candlepin.sh
> >>   - executes dpdb
> >> 0004_migrate_katello_db.s
> >>   - starts candlepin and elasticsearch
> >>   - runs katello migration
> >>
> >> Upgrade scripts (executed only once) are:
> >>
> >> (none for CFSE 1.0/1.1 - just two examples that does nothing)
> >>
> >> 0001_preallocate_mongo.sh
> >>   - prepares mongo journal for new version of mongo
> >> 0002_create_foreman_user
> >>   - creates foreman user
> >>
> >> Now there are couple of issues which are blockers for CFSE 1.1 and
> >> couple of design issues I would like to also fix for Katello.
> >>
> >> Basically katello-upgrade currently does not work in CFSE 1.1
> >> because we
> >> have some code logic in the migration scripts (filters) which
> >> require
> >> all the backend engines to be running. We are not starting pulp
> >> and also
> >> elasticsearch starts slowly and we need to wait until it is
> >> available.
> >>
> >> Also there are couple of example migration scripts which does
> >> nothing,
> >> but creating pyc/pyo bytecode files which are then added to the
> >> executed
> >> list. I will remove them and make sure python scripts does not
> >> create
> >> those.
> >>
> >> That is necessary for CFSE 1.1 upgrades, now for Katello we have a
> >> design issue. Some scripts need the services to be running (like
> >> pulp migration), others must not have services running (candlepin
> >> migration).
> >>
> >> Therefore for Katello, I plan to split our upgrade scripts into
> >> two
> >> categories (by script numbers):
> >>
> >> 0001-2999: Will be executed when backend engines are down
> >> 3000-5999: Will be executed when backend engines are up
> >> 6000-9999: Will be executed when backend engines and Katello are
> >> up
> >>
> >> This will be the same for both default and upgrade scripts. It
> >> would
> >> look (default scripts) like:
> >>
> >> 0001_stop_all_services
> >> 0010_migrate_candlepin
> >> 3000_start_backend_engines
> >> 3010_migrate_pulp
> >> 3020_migrate_katello
> >> 6000_start_katello
> >
> > I dont know if it matters.. but should we just do different
> > directories, instead of using magic numbers?
> If what this should solve is order of scripts, I can't see how
> directories help solving it, since the order in the subdirs should be
> specified as well.
> 
> -- Ivan
> >
> > -- bk
> >
> >
> >
> > _______________________________________________
> > katello-devel mailing list
> > katello-devel at redhat.com
> > https://www.redhat.com/mailman/listinfo/katello-devel
> 
> 
> --
> Ivan
> 
> _______________________________________________
> katello-devel mailing list
> katello-devel at redhat.com
> https://www.redhat.com/mailman/listinfo/katello-devel
> 

Will there never be a case where an upgrade w/o services needs to be run after an upgrade with services? Would it be simpler just to put the scripts in order in a single dir but include a meta tag in them that says what services have to be on/off?

# elasticsearch=on
# candlepin=off
# pulp=off

It may be slower overall, but I'd rather wait and know my upgrade worked. :)