[389-devel] Upgrade procedures

Wed Sep 2 15:15:13 UTC 2009

Nathan Kinder wrote:
> On 09/01/2009 03:38 PM, Rich Megginson wrote:
>> Nathan Kinder wrote:
>>> On 09/01/2009 02:23 PM, Rich Megginson wrote:
>>>> I'm envisioning something like patch files in an RPM - things that 
>>>> can easily come and go depending on what needs to be done for a 
>>>> particular release.  In this case, instead of patch files, these 
>>>> would be short perl or shell scripts.  These would be invoked once 
>>>> or once per instance.
>>>>
>>>> One way would be to have a large script which would be edited for 
>>>> each release, adding or deleting code as needed.  This is the way 
>>>> it worked in the past - the file quickly becomes "unruly".  
>>>> However, we would only have to touch Makefile.am once to add the 
>>>> upgrade script.
>>> You mean like the migrate4to6, migrate5to6, etc. stuff?
>> Sort of, but much smaller.  And not necessarily version specific - 
>> see below.
>>>>
>>>> Another way would be to have small scripts that could come and go 
>>>> with each release.  The disadvantage is that we would be constantly 
>>>> adding/deleting items from Makefile.am.  This is what I would prefer.
>>> I prefer the scriptlet approach too.
>>>
>>> How do you envision dealing with upgrading from different versions?  
>>> For example, we would need to do much different work upgrading from 
>>> 1.1 -> 1.3 than we would from 1.2 -> 1.3.  Will there be some way 
>>> for the scriptlet to specify what versions it needs to be run for?
>> I'm hoping to avoid looking at explicit versions.  Instead, I would 
>> prefer that the scriptlet would determine if the work it needed to do 
>> is already done.  For example, upgrading from 1.2.0 to 1.2.x would 
>> need to add the syntax validation plugin.  The scriptlet should check 
>> to see if the syntax validation plugin exists before adding it.  I 
>> can't really think of anything which would require an explicit version.
> That makes sense.  We may want to talk with Rob C. since I think he's 
> done something similar for FreeIPA's upgrade procedure with regards to 
> DS plug-in config.  Perhaps he has some insight.
I think they use ldif files that they either pass to ldapmodify or parse 
with python-ldap.  I think it would be useful to do that too, and 
possibly provide hooks that ipa could use.  So we can have 3 types of 
files to execute during upgrade
perl code - small perl scripts, which can be imported into the setup 
perl interpreter and executed in that context
ldif - which can be applied by the use of our current ldif code in setup
executable code - which will primarily be shell scripts, but I don't 
think there is any reason to limit it - we will need some way to pass 
the context to them, probably in the form of environment variables 
(INSTANCEDIR=/etc/dirsrv/slapd-foo ; BINDDN="cn=directory manager"; 
BINDPW="password" ; etc.)

I think there will have to some sort of manifest file (or main 
controlling script) to control the order of execution of these upgrade 
scripts/ldif.  Either that, or some sort of scheme like we use for 
schema files - name the files 00something through 99something and have 
them executed in order.  The numbering scheme might be tricky to 
manage.  The manifest/upgrade script will probably get ugly after a while.
>>>>
>>>> Before invoking the update scripts, the code would create some sort 
>>>> of context, containing information about the config directory, each 
>>>> instance, and an identity and credentials that can be used to 
>>>> manage each instance.  For example, when you run setup-ds-admin.pl 
>>>> -u, it uses the uid=admin identity and asks for the password, then 
>>>> uses that identity to manage each instance.  However, in the case 
>>>> where there is just the base ds package, we would need some way to 
>>>> ask or specify the identity for each instance.  For the UI, I don't 
>>>> think there's any way around just simply asking for the username 
>>>> and password for each instance (we can default the username to 
>>>> directory manager or the last value specified).  For .inf file 
>>>> usage, I was thinking about adding a new section - 
>>>> [slapd-instancename] - in which you could specify the RootDN and 
>>>> RootDNPwd.
>>>> ------------------------------------------------------------------------ 
>>>>
>>>>
>>>> -- 
>>>> 389-devel mailing list
>>>> 389-devel at redhat.com
>>>> https://www.redhat.com/mailman/listinfo/fedora-directory-devel
>>>>   
>>>
>>> ------------------------------------------------------------------------ 
>>>
>>>
>>> -- 
>>> 389-devel mailing list
>>> 389-devel at redhat.com
>>> https://www.redhat.com/mailman/listinfo/fedora-directory-devel
>>>   
>>
>> ------------------------------------------------------------------------
>>
>> --
>> 389-devel mailing list
>> 389-devel at redhat.com
>> https://www.redhat.com/mailman/listinfo/fedora-directory-devel
>>   
>
> ------------------------------------------------------------------------
>
> --
> 389-devel mailing list
> 389-devel at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-directory-devel
>   

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3258 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://listman.redhat.com/archives/fedora-directory-devel/attachments/20090902/dcec6c3b/attachment.bin>