[katello-devel] Katello upgrade redesign

[Ivan Nečas]

On 10/26/2012 03:23 PM, Bryan Kearney wrote:
> On 10/26/2012 09:16 AM, Ivan Nečas wrote:
>> 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.
>
> You still need numbers in the directories, but then you dont need to 
> remember that 3000 means after engines are up, instead you could see:
>
> after_engines_are_up
That makes sense. +1
>
> -- bk
>
> _______________________________________________
> katello-devel mailing list
> katello-devel at redhat.com
> https://www.redhat.com/mailman/listinfo/katello-devel


-- 
Ivan