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