Re: [389-devel] Upgrade procedures

[Nathan Kinder]

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.
> >>
> >> 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(a)redhat.com
> >> https://www.redhat.com/mailman/listinfo/fedora-directory-devel
> >
> > ------------------------------------------------------------------------
> >
> > -- 
> > 389-devel mailing list
> > 389-devel(a)redhat.com
> > https://www.redhat.com/mailman/listinfo/fedora-directory-devel
>
>  ------------------------------------------------------------------------
>
>  --
>  389-devel mailing list
>  389-devel(a)redhat.com
>  https://www.redhat.com/mailman/listinfo/fedora-directory-devel
>